Want to run L4Re on Raspberry PI.

[Paul Boddie]

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