Re: Cross compiler which runs on the target architecture.

[Peter Saunderson <peteasa@gmail.com>]

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
>