Re: Want to run L4Re on Raspberry PI.

Adam Lackorzynski <[email protected]>
Newsgroups gmane.comp.micro-kernel.l4.devel
Message-ID <[email protected]>
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 
> configurations.
> 
> Some pertinent settings:
> 
> BR2_GCC_TARGET_ABI="aapcs-linux"
> BR2_GCC_TARGET_CPU="arm1176jzf-s"
> BR2_GCC_TARGET_FPU="vfp"
> BR2_GCC_TARGET_FLOAT_ABI="hard"
> BR2_GCC_TARGET_MODE="arm"
> BR2_ARM_CPU_HAS_FPU=y
> BR2_ARM_CPU_HAS_VFPV2=y
> BR2_ARM_CPU_HAS_ARM=y
> BR2_ARM_CPU_HAS_THUMB=y
> BR2_ARM_CPU_ARMV6=y
> BR2_arm1176jzf_s=y
> BR2_ARM_EABIHF=y
> BR2_ARM_FPU_VFPV2=y
> 
> Then, I built Fiasco with the Raspberry Pi Zero W selected:
> 
> CONFIG_PF_BCM283X=y
> CONFIG_BSP_NAME="bcm283x"
> CONFIG_CAN_ARM_CPU_1176=y
> CONFIG_ARM_V6=y
> CONFIG_ARM_V6PLUS=y
> CONFIG_PF_BCM283X_RPIZW=y   
> CONFIG_ABI_VF=y 
> CONFIG_ARM_1176=y
> CONFIG_FPU=y 
> CONFIG_LAZY_FPU=y
> CONFIG_ARM_1176_CACHE_ALIAS_FIX=y
> CONFIG_ARM_CPU_ERRATA=y
> 
> 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:
> 
> CONFIG_CPU_ARM_ARMV6ZK=y
> CONFIG_CPU="armv6zk"
> CONFIG_PLATFORM_TYPE="rpi_b"
> CONFIG_CPU_ARMV6KPLUS=y
> CONFIG_CPU_ARMV6PLUS=y
> CONFIG_PLATFORM_TYPE_rpi_b=y
> 
> 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 
> kernel...
> 
> kernel=hello.raw
> 
> ...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 
> L4Re.

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
branched away. 


Adam
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.