On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > Hi, > > On Sat, 2014-12-20 at 14:43 +0000, Peter Saunderson wrote: >> I have seen a brief IRC chat >> (https://www.yoctoproject.org/irc/%23yocto.2013-09-23.log.html talking >> about https://github.com/nathanrossi/meta-parallella) about this >> question but nothing much else so this is an attempt to get more public >> feedback on this request.
That was me, as you might have noticed I ended up for now just using a pre-built toolchain that was copied into the system image with a recipe. This works but its not ideal. There have been a few threads recently regarding similar functionality desires: * https://lists.yoctoproject.org/pipermail/yocto/2014-December/022751.html * https://lists.yoctoproject.org/pipermail/yocto/2014-December/022653.html (this one is more about multi-machine builds, but still relevant) >> >> I am trying to build a cross compiler that runs on the target processor >> and a cross compiler that runs on the host processor so that I can build >> code for a third processor (Epiphany). If you want examples of the >> traditional way to build this compiler look at >> https://github.com/adapteva/epiphany-sdk epiphany-gcc epiphany-newlib >> epiphany-binutils... The end result would be a set of recipes that run >> on a pc build machine that build both arm code for the interim target >> and epiphany code for the final target and provides an SDK for the pc >> that enables you to cross compile for both arm and epiphany. I have been interested in this myself for the epiphany case as well as a few additional cases (from a personal interest as well as for Xilinx/meta-xilinx): * epiphany native, nativesdk and target cross compilers * baremetal toolchain (using newlib) * canadian-cross arch baremetal (e.g. arm host building for microblaze baremetal) * and also (canadian-)cross arch linux >> >> As I am just starting to look at this I would like to know what size of >> task I am up against! My initial efforts based on review of >> poky/meta/recipes-devtools/binutils etc seem to suggest that I have to >> modify at least ${HOST_PREFIX}, ${TARGET_PREFIX}, ${TARGET_ARCH} etc for >> my epiphany-??? recipes so that the I can install the compiler in a >> suitable location with a suitable prefix, the IRC chat indicates that >> there are more things to consider also. >> >> The question I have is about how easy it will be to use existing recipes >> for existing compiler / binutils etc... or is this likely to end up as a >> completely new set of recipes from the ground up because the existing >> recipes cant cope with building cross / cross compilers where there are >> three processors to consider (host (intel based pc), interim target >> (arm) and final target (epiphany)), or at least a lot of changes in the >> existing recipes to cope with something like TARGET_TARGET_ARCH = >> ${TARGET_ARCH}_${FINAL_TARGET_ARCH}?? > > Funnily enough I've a similar need to do something like this for a > personal project but targeting AVR. > > Certainly OE has the power and capability to do something like this, I'm > not sure its straightforward though, at least generically, and I say > that as one of the people with pretty intimate knowledge of the > toolchain recipes. > > The easy parts are creating recipes for binutils and gcc to run on the > target, targeting a third arch. This is like cross-canadian but built to > run on MACHINE instead of SDKMACHINE and taretting a new arch (probably > 'target-cross-canadian'). The massively harder part is the libc for gcc > to build against and any other libs for the system. > > The issue is that bitbake.conf locks the choice of MACHINE early in the > configuration stage. We added SDKMACHINE as a way of letting us build > SDKs and we have multilib and BBCLASSEXTEND but these all only target a > single arch. > > Part of me tries to ensure whatever solution we come up with can scale. > This means I'd like my arm target to be able to build compilers > targetting x86, mips and ppc as well as arm, all in one build. The > question then comes to libc and whether you'd rebuild libc each time, > whether you'd reuse the same libc package as a standard build or whether > you'd have a special version of the libc for the 'target-cross-canadian' > toolchain. There is definitely quite a bit of madness in getting oe to build additional toolchains even for the same architecture, let alone different architectures. ;) I have been playing around with getting a baremetal toolchain to build alongside the linux one, it seemed like a good place to start before diving into additional arch, cross-canadian builds. With the BBCLASSEXTEND stuff, I have gotten a fair way into the process of having a class providing overrides to the gcc-*/binutils-* recipes to allow for bitbake to build a secondary baremetal (with newlib) toolchain alongside the default machine/target toolchain. There are however changes that I needed to make to the recipes to make them more friendly within the tmp/sysroot/* structure during the intial and main pass builds of the toolchain, there is also the whole issue of dependency naming and virtual/* providers which works reasonably due to the virtual/${TARGET_PREFIX} being used. For now I have been overriding TARGET_OS/TCLIBC/etc with the use of _class-* overrides in local.conf. However the multilib setup relies on the use of DEFAULTTUNE for the setup of additional configurations, with some reworking of the tune-*.inc it would be possible to include multiple architecture types and rely on the DEFAULTTUNE to setup TUNE_*/TARGET_* with class overrides. It does seem like it would possible to handle all the cases I am after (at least) using BBCLASSEXTEND and some dynamic classes in the same way multilib works. I imagine support for heterogeneous builds could be a real good selling point for yocto/oe, especially with the large volume of modern SoC's having some form of mixed architectures these days :). Regards, Nathan > > Stepping back from that craziness, I suspect some specialist recipes for > avr/epiphany would probably be easiest right now, albeit less > satisfying. > > Cheers, > > Richard > > > > -- > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto