Want to run L4Re on Raspberry PI.
adam at os.inf.tu-dresden.de
Tue Jun 11 00:08:59 CEST 2019
On Mon Jun 10, 2019 at 20:16:55 +0200, Paul Boddie wrote:
> On Wednesday 29. May 2019 18.27.03 Paul Boddie wrote:
> > P.S. I have a selfish interest in following this as I could imagine also
> > trying out L4Re on the Raspberry Pi at some point. I guess that the
> > framebuffer isn't currently supported though.
> Well, I got round to trying this, but it hasn't been entirely successful.
> First of all, I made a toolchain using Buildroot 2019.02.2 and what are
> effectively the raspberrypi0_defconfig settings. The generated gcc is version
> 7.4.0, ld is version 2.29.1.
> Note that I am using the Zero, not the Zero-W, model. This doesn't appear to
> have any real toolchain implications, as far as I can tell from looking at the
> Some pertinent settings:
> Then, I built Fiasco with the Raspberry Pi Zero W selected:
> In this configuration, I also selected things that appeared useful, such as
> FPU support and the fixes/errata, which might not have been appropriate.
> Finally, I built L4Re with the Raspberry Pi Model B selected as platform:
> Having built the "hello" example, deploying the bootstrap_hello.raw file to
> the microSD card as hello.raw, alongside the extra files that the Raspberry
> Pi's proprietary bootloader uses, with a config.txt file that indicates the
> ...I see the payload starting over the UART connection, but it appears that
> the board keeps restarting, meaning that I just see the following over and
> over again:
> L4 Bootstrapper
> Build: #8 Mon Jun 10 19:44:17 CEST 2019, 7.4.0
> Scanning up to 512 MB RAM, starting at offset 32MB
> Memory size is 512MB (00000000 - 1fffffff)
> RAM: 0000000000000000 - 000000001fffffff: 524288kB
> Total RAM: 512MB
> Scanning fiasco
> Scanning sigma0
> Scanning moe
> Moving up to 5 modules behind 1100000
> Instrumenting the boot_modules.cc file in the bootstrap package, I see that
> the Boot_modules::move_modules is not completed. Generally, modules appear to
> be identified, but some other operation is causing a problem that appears to
> cause the board to reset.
> I have also tried building Fiasco for first generation Raspberry Pi devices
> along with the FPU support and other special options. And I have tried
> building for the Pi Zero-W without these extra options. The result seems to be
> the same, so I suspect that the kernel plays no role here, particularly since
> the problem appears to lie in the bootstrap code.
> I wonder if others who have looked at Raspberry Pi hardware might be able to
> share their experiences. It is rather frustrating to have to piece together
> the details of building and deploying for hardware ostensibly supported by
If it just reboots in the middle of a rather normal C function, then
it's likely some instruction that has been generated there and not
understood by the CPU. Could you maybe use u-boot as it shows a register
dump when something like this happens, allowing to know where it
More information about the l4-hackers