* Cross compiler which runs on the target architecture. @ 2014-12-20 14:43 Peter Saunderson 2014-12-22 14:53 ` Richard Purdie 2014-12-23 9:08 ` Richard Purdie 0 siblings, 2 replies; 13+ messages in thread From: Peter Saunderson @ 2014-12-20 14:43 UTC (permalink / raw) To: yocto Hi, 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. 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. 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}?? Thanks in advance for any comments. Peter. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture. 2014-12-20 14:43 Cross compiler which runs on the target architecture Peter Saunderson @ 2014-12-22 14:53 ` Richard Purdie 2014-12-23 12:49 ` Nathan Rossi 2014-12-23 9:08 ` Richard Purdie 1 sibling, 1 reply; 13+ messages in thread From: Richard Purdie @ 2014-12-22 14:53 UTC (permalink / raw) To: Peter Saunderson; +Cc: yocto 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. > > 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. > > 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. Stepping back from that craziness, I suspect some specialist recipes for avr/epiphany would probably be easiest right now, albeit less satisfying. Cheers, Richard ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture. 2014-12-22 14:53 ` Richard Purdie @ 2014-12-23 12:49 ` Nathan Rossi 2014-12-23 13:13 ` Peter Saunderson 0 siblings, 1 reply; 13+ messages in thread From: Nathan Rossi @ 2014-12-23 12:49 UTC (permalink / raw) To: Richard Purdie; +Cc: yocto, Peter Saunderson On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie <richard.purdie@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture. 2014-12-23 12:49 ` Nathan Rossi @ 2014-12-23 13:13 ` Peter Saunderson 2015-01-11 15:23 ` Peter Saunderson 0 siblings, 1 reply; 13+ messages in thread From: Peter Saunderson @ 2014-12-23 13:13 UTC (permalink / raw) To: Nathan Rossi, Richard Purdie; +Cc: yocto Hi Richard, Thanks for the samples. I have been taking a slightly different approach. It seems to me that poky/cross-canadian.bbclass is very specific to SDK generation, and could almost be called cross-canadian-sdk.bbclass where the sdk reflects the choice of host architecture. There are four architectures to consider (build, host, target and crosstarget) so my cross-canadian-target.bbclass is intended to have build set to the build machine, host set to the target and then target set to whatever crosstarget is configured with. Not got very far with this yet but that is the plan and I await with interest to see what problems I get when cross compiling the version of gcc! I guess the problem is that so many of the scripts like autotools.bbclass use variables specific to a particular configuration (--target=${TARGET_SYS}) rather than using internal generic variables that are assigned by the layer that uses the class. Thus autotools.bbclass could use autotools_target_sys that gets configured by the calling layer and thus avoiding having to apply replace patches like: replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr', d) or HOST_SYS := "${TARGET_SYS}" TARGET_SYS = "avr" Far better if the layers were based on a four architecture model (build, host, target and crosstarget) with at least some of the core classes avoiding specific configurations. Anyway as I said thank you for your input and have a good Christmas and New Year! Peter On 23/12/14 12:49, Nathan Rossi wrote: > On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie > <richard.purdie@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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture. 2014-12-23 13:13 ` Peter Saunderson @ 2015-01-11 15:23 ` Peter Saunderson 0 siblings, 0 replies; 13+ messages in thread From: Peter Saunderson @ 2015-01-11 15:23 UTC (permalink / raw) To: Nathan Rossi, Richard Purdie; +Cc: yocto Hi Richard, As you can see from https://github.com/peteasa/meta-epiphany I have been busy and am now getting closer to my specialist recipes for the Epiphany processor where I create a cross compiler that runs on the target arm processor that will enable development of Epiphany code in the embedded arm environment and later will move onto creating a Yocto SDK that provides the environment to build Epiphany code on the build machine. I created super project https://github.com/peteasa/parallella-yoctobuild that pulls the various bits together if anyone is interested in helping out! There are a number of issues that I have yet to solve and wonder if there is a suitable Yocto list to discuss these issues on? Building a cross compiler for a third processor type to run on the target seems to be an obvious requirement for Yocto moving forward. It seemed too complicated to inherit or include poky/meta/recipes-devtools/gcc and much easier to create a completely new layer to create the epiphany-elf version of the compiler. Obviously the simplest approach was taken by Nathan with his attempts, however these do not help with aim of creating a Yocto SDK that enables build of Epiphany code on the build machine. Perhaps there is a way to inherit or include poky/meta/recipes-devtools/gcc .. that I have missed? Because I have used poky/meta/recipes-devtools/gcc as a basis (but changed target to epiphany-elf from --build=x86_64-linux --host=arm-poky-linux-gnueabi --target=arm-poky-linux-gnueabi -> --build=x86_64-linux --host=arm-poky-linux-gnueabi --target=epiphany-elf) I am using work folders in tmp/work/x86_64-poky-linux-gnueabi.. perhaps I should be creating a new work directory for cross compiler generation? I have tried to package the newlib and libgcc components but for some reason the packaging fails and I get for example: error: packagegroup-epiphany-elf-buildessentialfromsource-1.0-r0 requires epiphany-elf-newlib. I can copy the generated files by hand to the target and they work. I am sure that I will be able to find how to get this packaged correctly by yocto, but its not obvious at the moment how to do that when the epiphany-elf-gcc and epiphany-elf-binutils seem to package ok.. its not obvious to me what the differences are apart from newlib and libgcc both being built with --build=x86_64-linux --host=epiphany-elf --target=epiphany-elf. Any thoughts on these questions would be most welcome. Peter. On 23/12/14 13:13, Peter Saunderson wrote: > Hi Richard, > > Thanks for the samples. > > I have been taking a slightly different approach. It seems to me that > poky/cross-canadian.bbclass is very specific to SDK generation, and > could almost be called cross-canadian-sdk.bbclass where the sdk > reflects the choice of host architecture. There are four > architectures to consider (build, host, target and crosstarget) so my > cross-canadian-target.bbclass is intended to have build set to the > build machine, host set to the target and then target set to whatever > crosstarget is configured with. Not got very far with this yet but > that is the plan and I await with interest to see what problems I get > when cross compiling the version of gcc! > > I guess the problem is that so many of the scripts like > autotools.bbclass use variables specific to a particular configuration > (--target=${TARGET_SYS}) rather than using internal generic variables > that are assigned by the layer that uses the class. Thus > autotools.bbclass could use autotools_target_sys that gets configured > by the calling layer and thus avoiding having to apply replace patches > like: > > replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr', d) > > or > > HOST_SYS := "${TARGET_SYS}" > TARGET_SYS = "avr" > > Far better if the layers were based on a four architecture model > (build, host, target and crosstarget) with at least some of the core > classes avoiding specific configurations. > > Anyway as I said thank you for your input and have a good Christmas > and New Year! > > Peter > > > On 23/12/14 12:49, Nathan Rossi wrote: >> On Tue, Dec 23, 2014 at 12:53 AM, Richard Purdie >> <richard.purdie@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 > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture. 2014-12-20 14:43 Cross compiler which runs on the target architecture Peter Saunderson 2014-12-22 14:53 ` Richard Purdie @ 2014-12-23 9:08 ` Richard Purdie 2020-12-09 12:38 ` [yocto] " Stefan Herbrechtsmeier [not found] ` <164F0CAF395EE75B.22015@lists.yoctoproject.org> 1 sibling, 2 replies; 13+ messages in thread From: Richard Purdie @ 2014-12-23 9:08 UTC (permalink / raw) To: Peter Saunderson; +Cc: yocto 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. > > 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. > > 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}?? As mentioned, I had need to do something like this for an avr target. I've created some *extremely* hacky recipes which do this and the resulting toolchain does actually work, much to my surprise. I've included the recipes I created below, warts and all in case it helps. Basically, its all a bit of a hack, the trouble is the system is very much tuned to have TARGET pointed at HOST for standard recipes. In the end I found it easier to 'sed' in the right target values into configure and then 'sed' other variables to change TARGET_PREFIX/TARGET_SYS where needed. Ultimately if we were doing a lot of this, we may be able to use a different variable name to make the recipes a lot neater. Cheers, Richard From f58f90257a5af3e6b6974090e62cad9d90d53ae5 Mon Sep 17 00:00:00 2001 From: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Tue, 23 Dec 2014 09:01:34 +0000 Subject: Add target avr support Known issues: * dependencies between the recipes is missing/incorrect * on target avr libgcc isn't installed Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> diff --git a/meta/recipes-devtools/avr-libc/avr-libc_1.8.1.bb b/meta/recipes-devtools/avr-libc/avr-libc_1.8.1.bb new file mode 100644 index 0000000..81481ba --- /dev/null +++ b/meta/recipes-devtools/avr-libc/avr-libc_1.8.1.bb @@ -0,0 +1,31 @@ +SRC_URI = "http://download.savannah.gnu.org/releases/avr-libc/avr-libc-1.8.1.tar.bz2" +LICENSE = "BSD" +LIC_FILES_CHKSUM = "file://LICENSE;md5=8d91a8f153d3de715f67a5df0d841c43" + +SRC_URI[md5sum] = "0caccead59eaaa61ac3f060ca3a803ef" +SRC_URI[sha256sum] = "c3062a481b6b2c6959dc708571c00b0e26301897ba21171ed92acd0af7c4a969" + +inherit autotools + +TOOLCHAIN_OPTIONS = "" + +TARGET_CFLAGS = "" +TARGET_LDFLAGS = "" + +export CC = "avr-gcc" +export AS = "avr-as" +export RANLIB = "avr-ranlib" +export AR = "avr-ar" + +FILES_${PN} += "${exec_prefix}/avr" +INSANE_SKIP_${PN} = "arch staticdev" + +python () { + def replace(var, x, y): + d.setVar(var, d.getVar(var, True).replace(d.expand(x),y)) + + replace('CONFIGUREOPTS', '--host=${HOST_SYS}','--host=avr') + replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr') +} + + diff --git a/meta/recipes-devtools/binutils/binutils-cross-target-avr_2.24.bb b/meta/recipes-devtools/binutils/binutils-cross-target-avr_2.24.bb new file mode 100644 index 0000000..e19cf54 --- /dev/null +++ b/meta/recipes-devtools/binutils/binutils-cross-target-avr_2.24.bb @@ -0,0 +1,37 @@ +require binutils.inc +require binutils-${PV}.inc +require binutils-cross.inc + +DEPENDS += "flex bison zlib" +PROVIDES = "virtual/binutils-target-avr" + +BPN = "binutils" + + + +python () { + def replace(var, x, y): + d.setVar(var, d.getVar(var, True).replace(d.expand(x),y)) + + replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr') + replace('EXTRA_OECONF', '--program-prefix=${TARGET_PREFIX}' ,'--program-prefix=avr-') + replace('do_install', '${TARGET_PREFIX}' ,'avr-') + replace('do_install', '${TARGET_SYS}' ,'avr') +} + +EXTRA_OECONF += "--with-sysroot=/ \ + --enable-install-libbfd \ + --enable-install-libiberty \ + --enable-shared \ + " + +do_install () { + oe_runmake 'DESTDIR=${D}' install +} + +sysroot_stage_all() { + sysroot_stage_dirs ${D} ${SYSROOT_DESTDIR} + sysroot_stage_dir ${D}${STAGING_DIR_NATIVE}${prefix_native}/avr ${SYSROOT_DESTDIR}${STAGING_DIR_NATIVE}${prefix_native}/avr + sysroot_stage_dir ${D}${STAGING_DIR_NATIVE}${prefix_native}/${BUILD_SYS} ${SYSROOT_DESTDIR}${STAGING_DIR_NATIVE}${prefix_native}/${BUILD_SYS} +} + diff --git a/meta/recipes-devtools/binutils/binutils-target-avr_2.24.bb b/meta/recipes-devtools/binutils/binutils-target-avr_2.24.bb new file mode 100644 index 0000000..66a899c --- /dev/null +++ b/meta/recipes-devtools/binutils/binutils-target-avr_2.24.bb @@ -0,0 +1,57 @@ +require binutils.inc +require binutils-${PV}.inc + +DEPENDS += "flex bison zlib" + +BPN = "binutils" + +FILES_${PN}-dev += " \ + ${exec_prefix}/${HOST_SYS}/avr/lib/lib*.la \ + ${exec_prefix}/${HOST_SYS}/avr/lib/libopcodes.so \ + ${exec_prefix}/${HOST_SYS}/avr/lib/libbfd.so \ + ${exec_prefix}/${HOST_SYS}/avr/include \ +" +FILES_${PN}-staticdev += " \ + ${exec_prefix}/${HOST_SYS}/avr/lib/lib*.a \ +" + +USE_ALTERNATIVES_FOR = "" + +python () { + def replace(var, x, y): + d.setVar(var, d.getVar(var, True).replace(d.expand(x),y)) + + replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr') + replace('EXTRA_OECONF', '--program-prefix=${TARGET_PREFIX}' ,'--program-prefix=avr-') + replace('do_install', '${TARGET_PREFIX}' ,'avr-') + replace('do_install', '${TARGET_SYS}' ,'avr') + replace(d.expand('FILES_${PN}'), '${TARGET_PREFIX}' ,'avr-') + replace(d.expand('FILES_${PN}'), '${TARGET_SYS}' ,'avr') + d.appendVar(d.expand('FILES_${PN}'), " ${exec_prefix}/${HOST_SYS}/avr/lib/*-*.so ${libdir}/ldscripts") + d.appendVar(d.expand('FILES_${PN}-dbg'), " ${exec_prefix}/${HOST_SYS}/avr/lib/.debug") +} + +EXTRA_OECONF += "--with-sysroot=/ \ + --enable-install-libbfd \ + --enable-install-libiberty \ + --enable-shared \ + " + +#do_install_append() { +# # Remove symlinks created by do_install +# for p in ${TARGET_PREFIX}* ; do +# rm `echo $p | sed -e s,${TARGET_PREFIX},,` +# done +#} + +do_install () { + autotools_do_install + + # Fix the /usr/${TARGET_SYS}/bin/* links + for l in ${D}${prefix}/${TARGET_SYS}/bin/*; do + rm -f $l + ln -sf `echo ${prefix}/${TARGET_SYS}/bin \ + | tr -s / \ + | sed -e 's,^/,,' -e 's,[^/]*,..,g'`${bindir}/${TARGET_PREFIX}`basename $l` $l + done +} \ No newline at end of file diff --git a/meta/recipes-devtools/gcc/gcc-cross-target-avr_4.8.bb b/meta/recipes-devtools/gcc/gcc-cross-target-avr_4.8.bb new file mode 100644 index 0000000..aa5c469 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-cross-target-avr_4.8.bb @@ -0,0 +1,41 @@ +require recipes-devtools/gcc/gcc-${PV}.inc +require gcc-cross.inc + +BPN = "gcc" +PROVIDES = "virtual/gcc-target-avr" + +ARCH_FLAGS_FOR_TARGET = "" +TARGET_CFLAGS = "" + +EXTRA_OECONF = "${@['--enable-clocale=generic', ''][d.getVar('USE_NLS', True) != 'no']} \ + --with-gnu-ld \ + --enable-languages=c \ + ${GCCMULTILIB} \ + --disable-libssp \ + --program-prefix=avr- \ + --without-local-prefix \ + ${OPTSPACE} \ + --enable-lto \ + --disable-bootstrap \ + --disable-libmudflap \ + --with-system-zlib \ + --enable-linker-build-id \ + --with-ppl=no \ + --with-cloog=no \ + --enable-checking=release \ + ${EXTRA_OECONF_PATHS}" + +python () { + def replace(var, x, y): + #bb.warn(x) + #bb.warn(d.expand(x)) + #bb.warn(d.getVar(var)) + #bb.warn(d.getVar(var, True).replace(d.expand(x),y)) + d.setVar(var, d.getVar(var, True).replace(d.expand(x),y)) + + replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr') + #replace('do_configure', '${HOST_PREFIX}' ,'avr-') + replace('do_install', '${TARGET_PREFIX}' ,'avr-') + replace('do_install', '${TARGET_SYS}' ,'avr') +} + diff --git a/meta/recipes-devtools/gcc/gcc-target-avr_4.8.bb b/meta/recipes-devtools/gcc/gcc-target-avr_4.8.bb new file mode 100644 index 0000000..b2be069 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc-target-avr_4.8.bb @@ -0,0 +1,50 @@ +require recipes-devtools/gcc/gcc-${PV}.inc +require gcc-target.inc + +BPN = "gcc" + +ARCH_FLAGS_FOR_TARGET = "" + +EXTRA_OECONF = "${@['--enable-clocale=generic', ''][d.getVar('USE_NLS', True) != 'no']} \ + --with-gnu-ld \ + --enable-languages=c \ + ${GCCMULTILIB} \ + --disable-libssp \ + --program-prefix=avr- \ + --without-local-prefix \ + ${OPTSPACE} \ + --enable-lto \ + --disable-bootstrap \ + --disable-libmudflap \ + --with-system-zlib \ + --with-ppl=no \ + --with-cloog=no \ + --enable-checking=release \ + ${EXTRA_OECONF_PATHS}" + + +python () { + def replace(var, x, y, d): + d.setVar(var, d.getVar(var, True).replace(d.expand(x),y)) + + ld = bb.data.createCopy(d) + ld.setVar("TARGET_CFLAGS", "") + ld.setVar("HOST_CC_ARCH", "") + ld.setVar("TOOLCHAIN_OPTIONS", "") + + replace('CONFIGUREOPTS', '--target=${TARGET_SYS}','--target=avr', d) + replace('EXTRA_OECONF', '--program-prefix=${TARGET_PREFIX}' ,'--program-prefix=avr-', d) + replace('do_configure', '${HOST_PREFIX}' ,'avr-', ld) + d.setVar('do_configure', ld.getVar('do_configure')) + replace('do_install', '${TARGET_PREFIX}' ,'avr-', d) + replace('do_install', '${TARGET_SYS}' ,'avr', d) + replace(d.expand('FILES_${PN}'), '${TARGET_PREFIX}' ,'avr-', d) + replace(d.expand('FILES_cpp'), '${TARGET_PREFIX}' ,'avr-', d) + replace(d.expand('FILES_gcov'), '${TARGET_PREFIX}' ,'avr-', d) + replace(d.expand('FILES_${PN}'), '${TARGET_SYS}' ,'avr', d) + replace(d.expand('FILES_${PN}-plugin-dev'), '${TARGET_SYS}' ,'avr', d) + replace(d.expand('FILES_${PN}-dbg'), '${TARGET_SYS}' ,'avr', d) + replace(d.expand('FILES_${PN}-dev'), '${TARGET_SYS}' ,'avr', d) + #d.appendVar(d.expand('FILES_${PN}'), " ${exec_prefix}/${HOST_SYS}/avr/lib/*-*.so") + #d.appendVar(d.expand('FILES_${PN}-dbg'), " ${exec_prefix}/${HOST_SYS}/avr/lib/.debug") +} ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [yocto] Cross compiler which runs on the target architecture 2014-12-23 9:08 ` Richard Purdie @ 2020-12-09 12:38 ` Stefan Herbrechtsmeier 2020-12-09 18:23 ` Khem Raj [not found] ` <164F0CAF395EE75B.22015@lists.yoctoproject.org> 1 sibling, 1 reply; 13+ messages in thread From: Stefan Herbrechtsmeier @ 2020-12-09 12:38 UTC (permalink / raw) To: richard.purdie, , peteasa; +Cc: yocto Hi Peter and Richard, does a follow up of this old topic (thread) regarding a cross compiler which runs on the target architecture exists? https://www.yoctoproject.org/pipermail/yocto/2014-December/022782.html Kind regards Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [yocto] Cross compiler which runs on the target architecture 2020-12-09 12:38 ` [yocto] " Stefan Herbrechtsmeier @ 2020-12-09 18:23 ` Khem Raj 2020-12-16 17:17 ` Stefan Herbrechtsmeier 0 siblings, 1 reply; 13+ messages in thread From: Khem Raj @ 2020-12-09 18:23 UTC (permalink / raw) To: yocto On 12/9/20 4:38 AM, Stefan Herbrechtsmeier wrote: > Hi Peter and Richard, > > does a follow up of this old topic (thread) regarding a cross compiler > which runs on the target architecture exists? > https://www.yoctoproject.org/pipermail/yocto/2014-December/022782.html > I dont think there were further discussions. However, I think the cross-canadian approach is perhaps step in right direction. We would need to enhance it to be able to build multiple cross-canadian tuples instead of only one that we build today which is based on SDK_MACHINE and TARGET_ARCH, > Kind regards > Stefan > > > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [yocto] Cross compiler which runs on the target architecture 2020-12-09 18:23 ` Khem Raj @ 2020-12-16 17:17 ` Stefan Herbrechtsmeier 2020-12-17 18:59 ` Peter 0 siblings, 1 reply; 13+ messages in thread From: Stefan Herbrechtsmeier @ 2020-12-16 17:17 UTC (permalink / raw) To: Khem Raj, yocto Hi Khem, Am 09.12.20 um 19:23 schrieb Khem Raj: > On 12/9/20 4:38 AM, Stefan Herbrechtsmeier wrote: >> Hi Peter and Richard, >> >> does a follow up of this old topic (thread) regarding a cross compiler >> which runs on the target architecture exists? >> https://www.yoctoproject.org/pipermail/yocto/2014-December/022782.html >> > > I dont think there were further discussions. However, I think the > cross-canadian approach is perhaps step in right direction. We would > need to enhance it to be able to build multiple cross-canadian tuples > instead of only one that we build today which is based on SDK_MACHINE > and TARGET_ARCH The cross-canadian changes the HOST variables and not the TARGET_ variables. I need to change the TARGET variables but keep the HOST variables. It looks like this isn't really intended because the HOST_PREFIX use the TARGET_PREFIX for example. Regards Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture 2020-12-16 17:17 ` Stefan Herbrechtsmeier @ 2020-12-17 18:59 ` Peter 2020-12-17 21:04 ` [yocto] " Stefan Herbrechtsmeier 0 siblings, 1 reply; 13+ messages in thread From: Peter @ 2020-12-17 18:59 UTC (permalink / raw) To: yocto [-- Attachment #1: Type: text/plain, Size: 3247 bytes --] > > I dont think there were further discussions. > The proof of concept layer is http://layers.openembedded.org/layerindex/branch/master/layer/meta-exotic/ - https://github.com/peteasa/meta-exotic/wiki. I created a set of cross compilers for the Epiphany processor http://www.adapteva.com/epiphanyiii/ using this layer and the layer https://github.com/peteasa/meta-epiphany that builds the specific cross compilers for that processor. It worked quite well with yocto-1.7.1 so it's quite an old bit of code, however the ideas could work in a more recent versions of Yocto. In summary the yocto-1.7.1 code had three variables of interest - BUILD: for example the system of the build machine; HOST: for example the host system on which the executable will run; TARGET: for example the system that the compiler output will be created for. The meta-exotic layer introduces a fourth EXOTIC_TARGET and this allows us to differentiate between the build machine, host system and the system that the compiled Linux kernel runs on. I called it EXOTIC because if the compiled Linux kernel and applications needs to communicate with a remote accelerator with a different system then as far as most of the Yocto build is concerned this fourth system is foreign to the embedded product (ie exotic) that the Linux kernel and applications are built on. I call it a proof of concept because at the time it seemed to me that the sensible "fix" would be to introduce these four macro's into Yocto itself so that Yocto had 4 rather than 3 selectable system (build machine, host machine, target machine and exotic machine). In the absence of full Yocto support for these 4 I used the Yocto parser rules to update the --target, --host variables in cross compilers to match the appropriate specification. See https://github.com/peteasa/meta-exotic/wiki/Introducing-EXOTIC-defines for a more detailed discussion with examples. I know that Yocto has moved on a lot since I produced the EXOTIC layer so if there is a good way to handle the creation of the various cross compilers that that is a good thing. In my case my Exotic target allowed me to create both code that ran directly on the Epiphany processor (an accelerator attached to the arm-poky-linux-gnueabi embedded system) and a cross compiler environment that allowed me to build code for both the Epiphany accelerator and the arm-poky-linux-gnueabi embedded system from the same SDK running on the SDK machine of my choice. Use of the four variables allowed me to make gcc / applications for any of the following combinations: --host=build_machine --target=build_machine --host=build_machine --target=SDK_machine --host=arm_target --target=arm_target --host=SDK_machine --target=arm_target --host=build_machine --target=Epiphany_accelerator --host=SDK_machine --target=Epiphany_accelerator --host=arm_target --target= Epiphany_accelerator Yes it complex, but these are the necessary combinations if you want to create a complete system that provides support for an embedded product with an accelerator and provides an SDK environment so that you can build locally and then download the binary to the embedded systems. All I can say is it worked for me! [-- Attachment #2: Type: text/html, Size: 6373 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [yocto] Cross compiler which runs on the target architecture 2020-12-17 18:59 ` Peter @ 2020-12-17 21:04 ` Stefan Herbrechtsmeier 2020-12-18 11:10 ` Peter 0 siblings, 1 reply; 13+ messages in thread From: Stefan Herbrechtsmeier @ 2020-12-17 21:04 UTC (permalink / raw) To: Peter, yocto Hi Peter, Am 17.12.20 um 19:59 schrieb Peter: > I dont think there were further discussions. > > The proof of concept layer is > http://layers.openembedded.org/layerindex/branch/master/layer/meta-exotic/ > - https://github.com/peteasa/meta-exotic/wiki. I created a set of cross > compilers for the Epiphany processor > http://www.adapteva.com/epiphanyiii/ using this layer and the layer > https://github.com/peteasa/meta-epiphany that builds the specific cross > compilers for that processor. It worked quite well with yocto-1.7.1 so > it's quite an old bit of code, however the ideas could work in a more > recent versions of Yocto. > > In summary the yocto-1.7.1 code had three variables of interest - BUILD: > for example the system of the build machine; HOST: for example the host > system on which the executable will run; TARGET: for example the system > that the compiler output will be created for. The meta-exotic layer > introduces a fourth EXOTIC_TARGET and this allows us to differentiate > between the build machine, host system and the system that the compiled > Linux kernel runs on. I called it EXOTIC because if the compiled Linux > kernel and applications needs to communicate with a remote accelerator > with a different system then as far as most of the Yocto build is > concerned this fourth system is foreign to the embedded product (ie > exotic) that the Linux kernel and applications are built on. > > I call it a proof of concept because at the time it seemed to me that > the sensible "fix" would be to introduce these four macro's into Yocto > itself so that Yocto had 4 rather than 3 selectable system (build > machine, host machine, target machine and exotic machine). In the > absence of full Yocto support for these 4 I used the Yocto parser rules > to update the --target, --host variables in cross compilers to match the > appropriate specification. See > https://github.com/peteasa/meta-exotic/wiki/Introducing-EXOTIC-defines > for a more detailed discussion with examples. > > I know that Yocto has moved on a lot since I produced the EXOTIC layer > so if there is a good way to handle the creation of the various cross > compilers that that is a good thing. In my case my Exotic target > allowed me to create both code that ran directly on the Epiphany > processor (an accelerator attached to the arm-poky-linux-gnueabi > embedded system) and a cross compiler environment that allowed me to > build code for both the Epiphany accelerator and the > arm-poky-linux-gnueabi embedded system from the same SDK running on the > SDK machine of my choice. Use of the four variables allowed me to make > gcc / applications for any of the following combinations: > > --host=build_machine --target=build_machine > > --host=build_machine --target=SDK_machine > > --host=arm_target --target=arm_target > > --host=SDK_machine --target=arm_target > > --host=build_machine --target=Epiphany_accelerator > > --host=SDK_machine --target=Epiphany_accelerator > > --host=arm_target --target=Epiphany_accelerator > > Yes it complex, but these are the necessary combinations if you want to > create a complete system that provides support for an embedded product > with an accelerator and provides an SDK environment so that you can > build locally and then download the binary to the embedded systems. > > All I can say is it worked for me! Thanks for the detail explanation of your solution. The problem I see is that your solution doesn't scale. What happens if your system have a second not Linux system beside the accelerator like a power management unit? Why you doesn't use multilib? It looks like the only missing part is the combination of host=machine and target=multilib. Regards Stefan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Cross compiler which runs on the target architecture 2020-12-17 21:04 ` [yocto] " Stefan Herbrechtsmeier @ 2020-12-18 11:10 ` Peter 0 siblings, 0 replies; 13+ messages in thread From: Peter @ 2020-12-18 11:10 UTC (permalink / raw) To: yocto [-- Attachment #1: Type: text/plain, Size: 1431 bytes --] > > Why you doesn't use multilib? Once the framework is in place adding addtional compile flags like --enable-multilib is relatively easy.. see https://github.com/peteasa/meta-exotic/blob/master/exotic-gc/exotic-gcc-configure-common.inc#L14 where I actually have used multilib. In addition it appears that this option is on by default - see https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html > > The problem I see is that your solution doesn't scale > Interesting comment. I would expect that for 2 or more exotic systems you could create a separate build environment / SDK for each of the exotic systems - not ideal but would scale because each would produce executables that are bundled into a distribution that would published and loaded in the normal way onto embedded system. Don't forget my initial challenge was that I could not easily create an build environment / SDK that would create packages for my exotic processor. My solution addressed that challenge and re-uses a lot of the code that is provided by yocto.. my intention was to find out if there was community interest in multi system building by providing a proof of concept to spark peoples interest. The proposed "specialist recipe" idea, whilst simpler, does not produce the environment that I wanted, I would not have been able to compile simple applications for my accellerator on my target arm processor for example. [-- Attachment #2: Type: text/html, Size: 1689 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <164F0CAF395EE75B.22015@lists.yoctoproject.org>]
[parent not found: <e3b2fe77-585c-51dd-b4df-7265090feb50@herbrechtsmeier.net>]
[parent not found: <CAF+qF8fNJvCRZrjhCwnAzZScGRUSbUarwi7+SYaw7Jc-Dh2W7g@mail.gmail.com>]
* Re: [yocto] Cross compiler which runs on the target architecture [not found] ` <CAF+qF8fNJvCRZrjhCwnAzZScGRUSbUarwi7+SYaw7Jc-Dh2W7g@mail.gmail.com> @ 2020-12-16 16:40 ` Stefan Herbrechtsmeier 0 siblings, 0 replies; 13+ messages in thread From: Stefan Herbrechtsmeier @ 2020-12-16 16:40 UTC (permalink / raw) To: peteasa; +Cc: Richard Purdie, yocto Hi Peter, Am 09.12.20 um 14:32 schrieb Peter Saunderson: > The proof of concept layer is > http://layers.openembedded.org/layerindex/branch/master/layer/meta-exotic/ > - https://github.com/peteasa/meta-exotic/wiki. I created a set of cross > compilers for the Epiphany processor > http://www.adapteva.com/epiphanyiii/ using this layer and the layer > https://github.com/peteasa/meta-epiphany that builds the specific cross > compilers for that processor. It worked quite well with yocto-1.7.1 so > it's quite an old bit of code, however the ideas could work in a more > recent versions of Yocto. Thanks for the links but your solution looks very complex. I will try to improve the examples from Richard. Regards Stefan > On Wed, 9 Dec 2020 at 12:43, Stefan Herbrechtsmeier > <stefan@herbrechtsmeier.net <mailto:stefan@herbrechtsmeier.net>> wrote: > > Sorry I have an error in Peter`s mail address. > > Am 09.12.2020 um 13:38 schrieb Stefan Herbrechtsmeier: > > Hi Peter and Richard, > > > > does a follow up of this old topic (thread) regarding a cross > compiler > > which runs on the target architecture exists? > > > https://www.yoctoproject.org/pipermail/yocto/2014-December/022782.html > > > > Kind regards > > Stefan > > > > > > > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-12-18 11:10 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-20 14:43 Cross compiler which runs on the target architecture Peter Saunderson 2014-12-22 14:53 ` Richard Purdie 2014-12-23 12:49 ` Nathan Rossi 2014-12-23 13:13 ` Peter Saunderson 2015-01-11 15:23 ` Peter Saunderson 2014-12-23 9:08 ` Richard Purdie 2020-12-09 12:38 ` [yocto] " Stefan Herbrechtsmeier 2020-12-09 18:23 ` Khem Raj 2020-12-16 17:17 ` Stefan Herbrechtsmeier 2020-12-17 18:59 ` Peter 2020-12-17 21:04 ` [yocto] " Stefan Herbrechtsmeier 2020-12-18 11:10 ` Peter [not found] ` <164F0CAF395EE75B.22015@lists.yoctoproject.org> [not found] ` <e3b2fe77-585c-51dd-b4df-7265090feb50@herbrechtsmeier.net> [not found] ` <CAF+qF8fNJvCRZrjhCwnAzZScGRUSbUarwi7+SYaw7Jc-Dh2W7g@mail.gmail.com> 2020-12-16 16:40 ` [yocto] " Stefan Herbrechtsmeier
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.