Re: Cross-compiling L4Re for MIPS32

On Mon Jun 13, 2016 at 12:50:07 +0200, Paul Boddie wrote:
> On Monday 13. June 2016 00.41.12 Adam Lackorzynski wrote:
> > Hi Paul,
> > 
> > On Sun Jun 12, 2016 at 01:19:26 +0200, Paul Boddie wrote:
> > > ...I have been attempting to cross-compile Fiasco and L4Re using the
> > > l4re.org sources. Getting Fiasco to cross-compile was mostly a matter of
> > > repeating the same procedure as last time:
> > > 
> > > cd src/kernel/fiasco
> > > make BUILDDIR=mybuild
> > > cd mybuild/
> > > make config
> > > make
> > > 
> > > However, I needed to edit src/kernel/fiasco/src/Makeconf.mips32 to change
> > > the compiler settings. I'm using the toolchains in Debian unstable:
> > > 
> > > CROSS_COMPILE             ?= mipsel-linux-gnu-
> > > 
> > > Previously, I used a Makeconf.local file to set the following:
> > > 
> > > SYSTEM_TARGET=mipsel-linux-gnu-
> > 
> > Please use CROSS_COMPILE=mipsel-linux-gnu- here.
> > 
> > > SHARED_FLAGS=-mips32r2 -EL -msoft-float -mno-abicalls -fno-pic
> > 
> > Setting SHARED_FLAGS flags is not required (actually must not, otherwise
> > I'd regard this as a bug).
> 
> OK. CROSS_COMPILE did work, but I thought I'd mention that the SYSTEM_TARGET 
> variable was apparently what the fiasco-l4re documentation was suggesting. 
> Given that nobody involved in doing that work seems to have anything to say 
> about it, I thought I'd mention it here.
> 
> (I'd have more confidence in the things Imagination Technologies produce - or 
> commission for their use - if they gave more of an indication that they 
> support those things, particularly over a reasonable timeframe.)

Even better, the code has been merged and life went on. Since then we
have changed to use CROSS_COMPILE and deprecated SYSTEM_TARGET
(unfortunately the compat code and the deprecation message are placed
before Makeconf.local files are included, thus that does not work in
your case).
 
> > > Maybe the previous work used some different mechanisms to those used by
> > > the more general source distribution, but this trick didn't seem to
> > > influence the build successfully this time around. However, the build
> > > did complete successfully with the toolchain set appropriately.
> > > 
> > > Meanwhile, I had more problems with the L4Re part. I had expected to be
> > > able to do the following:
> > > 
> > > cd src/l4
> > > make B=mybuild
> > > make O=mybuild config
> > > make O=mybuild E=mips-fbspectrum
> > > 
> > > (The target was something that I had managed to build previously after
> > > some messing around with packages and configuration files. I'd managed
> > > to build the fbspectrum example for Fiasco.OC-UX, as the list archives
> > > will attest.)
> > > 
> > > However, I also had to change the compiler settings (as done above) in
> > > src/l4/mk/arch/Makeconf.mips, instead of using src/l4/Makeconf.local (as
> > > done previously). Again, maybe the way of doing things was different in
> > > the previous incarnation of this port.
> > 
> > Also use CROSS_COMPILE here.
> 
> Right. That would be consistent with the above and with the Makeconf files. I 
> guess Makeconf.local might be supported, given that there did seem to be a 
> mention of extra files in the configuration system, but in a version 
> controlled environment it is just as easy to modify the distributed 
> configuration, anyway.

Sure, but Makeconf.local will also work.

> > > I also needed to edit src/l4/tool/gendep/syscall.c to add a definition
> > > before unistd.h gets included:
> > > 
> > > #define __ARCH_WANT_SYSCALL_NO_AT
> > > 
> > > I can't remember if I or anyone else has mentioned this before now, but
> > > without it, things like __NR_open are not defined.
> > 
> > On which system are you compiling this? This doesn't happen for us, so
> > I'm wondering.
> 
> I'm compiling in a Debian unstable chroot on i386. Are you still using i386 to 
> build with? Recent experiences with other projects indicate that support for 
> i386 sometimes falls behind amd64, although I have no idea or immediate 
> recollection why the unistd.h behaviour changed as indicated above.

Although amd64 is in the majority, i386 is still in the game, and I've
never seen this before. Also, __NR_open is not used directly, thus my
question, where is it missing?

> > > Unfortunately, I haven't yet reached a satisfactory conclusion in this
> > > latter exercise. Looking back at my previous messages, it seems that a
> > > bit more work might be needed to configure and build a suitable target,
> > > and so I was wondering if anyone had done this (and written it up) for
> > > any of the MIPS boards, perhaps the CI20. Indeed, I wonder if things
> > > like the framebuffer are even supported for the CI20 or other MIPS
> > > boards.
> > 
> > We do not have any support for framebuffers on MIPS targets yet.
> 
> OK. This gets me back to the point I was before, but since then I've gained a 
> bit more experience with the hardware involved, which isn't the CI20 but does 
> feature a related Ingenic jz47xx-series CPU.

Ok.


Adam