Want to run L4Re on Raspberry PI.
paul at boddie.org.uk
Mon Jun 17 23:37:14 CEST 2019
On Monday 17. June 2019 00.08.27 Adam Lackorzynski wrote:
> I do not see anything particular special either. The floating point
> instructions are in the libc/*printf, so are not affected here.
> I could only continue with a binary search style of looking where it
> breaks, with "while(1);" as printfs do seems to change too much as you
> already found out.
Well, I also tried with the Debian ARM cross-toolchains (GCC 7.4.0), just to
see whether they might produce differently-behaving code. The boot process
only gets this far with the generated code...
## Booting kernel from Legacy Image at 00080000 ...
Image Name: L4 Image #2
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1226456 Bytes = 1.2 MiB
Load Address: 01000000
Entry Point: 01000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
Starting kernel ...
However, I do wonder whether the compiler options might be inappropriate. I
had assumed that some CPU-specific options may have been introduced into the
compiler invocations, but the Raspberry Pi configuration options in L4Re don't
seem to have any such effect (these presumably being in mk/platform).
Meanwhile, Fiasco introduces -mcpu=arm1176jzf-s as an option (in
src/Makeconf.arm) thanks to the Raspberry Pi definitions (in
src/kern/arm/bsp/bcm283x/Kconfig) setting CAN_ARM_CPU_1176 and thus ARM_1176
then being set (in src/kern/arm/Kconfig).
Presumably, the -march=armv6zk option set within L4Re (in
mk/arch/Makeconf.arm) thanks to CPU_ARM_ARMV6ZK (in mk/arch/Kconfig.arm.inc)
is supposed to cover the Broadcom 2835 in the Raspberry Pi Zero.
Looking for guidance on this, I found the following:
Here, the following options are suggested:
-march=armv6zk -mcpu=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp
To investigate, I changed CARCHFLAGS_arm_armv6zk (in mk/arch/Makeconf.arm) to
incorporate these extra options and rebuilt L4Re. The resulting code is
different, with various tables containing somewhat different values, and with
some small additions and relocations amongst the routines.
Since this exercise involved the Debian toolchain, the resulting output did
not indicate any more progress through the bootstrapping process than before,
but I do wonder if things might change more substantially by using these flags
with the "clean" Buildroot toolchain I prepared earlier.
I guess trying to build everything as soft-float might also be worthwhile, but
I do doubt that floating point instructions are the real problem here. The odd
behaviour obtained by placing printf statements in the failing routines almost
suggests some kind of initialisation or referencing issue, perhaps linker-
More information about the l4-hackers