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