Re: Want to run L4Re on Raspberry PI.

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


L4 Bootstrapper
----

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:

https://raspberrypi.stackexchange.com/questions/2046/which-cpu-flags-are-suitable-for-gcc-on-raspberry-pi

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-
related.

Paul