Want to run L4Re on Raspberry PI.

[Christian Pötzsch]

Hi Paul,

the cross compiler shipped with Debian silently produce code for armv7, 
even if you specify -march=armv6zk. It just ignores that. I also had to 
find this out the hard way. My only solution was to create a cross 
compiler myself and configure it with armv6 support.

Here are (maybe incomplete) instructions for doing that:

Note:

gcc 6.4 has a bug which means it will not build on latest Debian 
(​https://github.com/crosstool-ng/crosstool-ng/issues/992). This is why 
we select the gcc 5.4 version below.

Install all the requirements::

$ sudo apt-get install bison cvs flex gperf texinfo automake libtool 
html2man
Download and unpack crosstool-ng:

$ wget 
http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.23.0.tar.bz2
$ tar -xjvf crosstool-ng-1.23.0.tar.bz2
$ cd crosstool-ng-1.23.0
Configure and build it:

$ ./configure --prefix=$PWD/../crosstool-ng
$ make
$ make install
$ export PATH=$PATH:$PWD/../crosstool-ng
$ cd ..
$ mkdir raspi
$ cd raspi
$ ct-ng armv6-rpi-linux-gnueabi
$ ct-ng menuconfig
Now change some options which are still not right:

Path and misc options:
   -> Render the toolchain read-only: OFF
C-Library:
   -> Build and install locales: OFF
C Compiler:
   -> gcc version: linaro-5.4-2017.01
Debug facilities:
   -> gdb: OFF
Build it:

$ ct-ng build
The result will be stored in 
${HOME}/x-tools/x-tools/armv6-rpi-linux-gnueabi.

To build l4re/fiasco you need to refer to the new cross compiler:

$ export 
CROSS_COMPILE=${HOME}/x-tools/x-tools/armv6-rpi-linux-gnueabi/bin/armv6-rpi-linux-gnueabi-

Chris


On 6/17/19 11:37 PM, Paul Boddie wrote:
> 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
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
> 

-- 
Kernkonzept GmbH.  Sitz: Dresden.  Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth