Want to run L4Re on Raspberry PI.

[Paul Boddie]

On Monday 24. June 2019 14.14.46 Christian Pötzsch wrote:
> 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.

For me, it was just a speculative test, having already assumed that the 
toolchain wouldn't produce usable code anyway. (Matthias gave the impression 
that such distribution toolchains wouldn't be suitable.)

> My only solution was to create a cross compiler myself and configure it with
> armv6 support.
> 
> Here are (maybe incomplete) instructions for doing that:

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

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.

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

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.

Paul