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 _______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
