Want to run L4Re on Raspberry PI.
adam at os.inf.tu-dresden.de
Thu Jun 13 17:48:59 CEST 2019
On Wed Jun 12, 2019 at 00:34:02 +0200, Paul Boddie wrote:
> On Tuesday 11. June 2019 23.32.43 Adam Lackorzynski wrote:
> > On Tue Jun 11, 2019 at 02:00:00 +0200, Paul Boddie wrote:
> > > 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
> > 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:
I see a couple of floating point instructions and it would be
interesting to know whether one of those triggers it. Sorry for not
saying this earlier, but could you place a version with debugging
symbols (of bootstrap) online, i.e. one where I could see where
> 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
More information about the l4-hackers