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