Want to run L4Re on Raspberry PI.
paul at boddie.org.uk
Mon Jun 24 20:03:26 CEST 2019
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:
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
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.
More information about the l4-hackers