On Monday 24. June 2019 20.03.26 Paul Boddie wrote:
[Crosstool-NG instructions]
Thanks for the instructions! As you may have seen, I did use Buildroot to make a comparable toolchain, but maybe I need to investigate whether the two different systems produce toolchains with differing characteristics. A few aspects come to mind.
A quick look at the latest Crosstool-NG seemed to indicate that the expected compiler/linker options would be set (in samples/armv6-rpi-linux- gnueabi/crosstool.config):
CT_ARCH_CPU="arm1176jzf-s" CT_ARCH_SUFFIX="v6" CT_ARCH_FPU="vfp"
This shouldn't be different from what Buildroot seems to set up (in configs/raspberrypi0_defconfig):
BR2_arm1176jzf_s=y BR2_ARM_EABIHF=y
I did wonder if Crosstool-NG might drop the floating point support and generate soft-float code in its toolchain output, but I guess it doesn't. Unfortunately, I didn't manage to finish building the toolchain yesterday (after ct-ng pegged my CPU and disk for several hours, helpfully assisted occasionally by Firefox and Akonadi/MySQL), and attempting to restart the build today caused it to throw away the build results from yesterday and start again. (Not exactly what you would expect from a Makefile-based system.)
GCC versions and regressions with regard to the kind of code they generate. If the Debian compiler ignores the architecture option due to an upstream issue, this might also explain why your Crosstool-NG toolchain (GCC 5.4) works but the toolchain produced by Buildroot (GCC 7.4) does not.
I still wonder about this, but only slightly. One thing I did notice is that the latest Crosstool-NG does not offer the Linaro compiler variant, although my impression is that the Linaro toolchain is largely obsolete.
Configuration differences: I would assume that the Buildroot compiler would actually work with the Raspberry Pi Zero given the presence of a suitable "defconfig" file, but maybe it is broken and nobody is testing it any more.
L4Re versions and regressions: presumably L4Re has worked on the original Raspberry Pi and on the Raspberry Pi Zero W, given that the latter appears in the Fiasco configuration menus. Maybe I should rewind to some earlier L4Re (and Fiasco) repository version and try the result.
I tried to do this, but version 76 of L4Re was the earliest that would cross- build from my MIPS-based computer. Versions 69 and 74 experienced the issues with "make B=mybuild" that I described recently, but I couldn't work around them within a reasonable amount of time.
I was also told about floating point instruction choices with regard to the Inferno toolchain output, these causing problems when someone ported Inferno to the Raspberry Pi. Obviously, the exact problems would be specific to Inferno, but I can imagine "bad" instructions leaking out from some kind of GCC regression.
One thing I did discover about this was the apparent need to enable the floating point unit explicitly. There are various articles mentioning this such as...
http://cholla.mmto.org/arm/assembly/float.html
Adding the mrc...mcr instruction block to the crt0.S file didn't help, however, making me think that this isn't completely related to floating point instructions.
Sadly, U-Boot doesn't seem to play along by setting a trap handler, but perhaps I can install one in the initialisation of the bootstrap module. Alternatively, I could build a soft-float toolchain and try and see if that makes any difference.
So I suppose that there are a few things to look at here, but I appreciate the suggestion of trying a different toolchain system, and maybe that's the first thing I will look at.
Well, I may get back to this, but what seemed like a interesting diversion has turned into a larger and less rewarding exercise. As I experienced with the MIPS-related parts of L4Re, there seems to be a gap between claimed and actual support for hardware that, in this case, may only be a matter of documentation. However, I rather feel that L4Re has a broader reproducibility problem.
Paul