On Tuesday 11. June 2019 23.32.43 Adam Lackorzynski wrote:
On Tue Jun 11, 2019 at 02:00:00 +0200, Paul Boddie wrote:
U-Boot> mmc dev 0 switch to partitions #0, OK mmc0 is current device U-Boot> fatload mmc 0:1 ${kernel_addr_r} hello.raw 1209560 bytes read in 91 ms (12.7 MiB/s) U-Boot> bootz ${kernel_addr_r} Kernel image @ 0x080000 [ 0x1000000 - 0x11274d8 ]
Interesting way of doing it, i.e. good that our bootstrap image also looks like a Linux image. I'd typically do something like this using the uimage: fatload mmc 0:1 0x0ffffc0 hello.uimage bootm 0x0ffffc0
But in the end it should not make a difference.
Yes, I wasn't really thinking very hard about it. And using a uImage file with bootm doesn't change the outcome.
[...]
Unfortunately, nothing more is shown and there is no register dump. Maybe I have to compile in some kind of exception handler or something.
No, it's built-in. So my suggestion would be to narrow it down by putting some more printfs etc. in the code so see where it diverts. But understandably this is pretty cumbersome with the SD card.
Indeed, but it was more cumbersome blitting patterns to the display on the Ben NanoNote to trace progress through the bootstrap code and kernel. :-)
Previously, I did generate debugging statements, and initially it seemed that the code didn't get beyond calc_modules_size, seemingly failing to loop over more than one module. However, splitting up the following statement...
s += l4_round_size(mbi->module(i).size(), p2align);
...and inserting other debugging statements did seem to persuade the code to proceed until move_module was called. Thus, output like this can be generated:
Counting 5 modules... Module 0... Size: 648904... Module 1... Size: 41840... Module 2... Size: 218336... Module 3... Size: 87208... Module 4... Size: 132812... Total: 1142784
In fact, this is from my most recent attempt at instrumenting the code in this way.
Could you put the hello.elf online so that I could have a look to check for the assumption with the wrong instruction?
Perhaps take a look at the following:
http://www.boddie.org.uk/downloads/armv6_hello.elf http://www.boddie.org.uk/downloads/armv6zk_hello.elf
I rebuilt the toolchain using the raspberrypi0_defconfig instead of manually selecting Raspberry Pi Zero in the configuration menu, just to make sure that there wasn't some important difference.
Then, I rebuilt Fiasco and L4Re. The ARMv6 and ARMv6zK payloads were generated from separate ARMv6 and ARMv6zK builds of L4Re.
The result is unchanged from before, meaning that either the generated code has no influence on the result - it does differ slightly, but mostly involves the usual reordering done when such settings are altered - or "bad" instructions are somehow being generated anyway.
Thanks for taking an interest in this! I imagine that I am probably doing something wrong, but hopefully my mistakes can be used to teach others what to do.
Paul