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 _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
