Want to run L4Re on Raspberry PI.

[Paul Boddie]

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