Cross compiler which runs on the target architecture.

Cross compiler which runs on the target architecture.

[Peter Saunderson]

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.

Re: Cross compiler which runs on the target architecture.

[Richard Purdie]

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

Re: Cross compiler which runs on the target architecture.

[Richard Purdie]

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")
+}

Re: Cross compiler which runs on the target architecture.

[Nathan Rossi]

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

Re: Cross compiler which runs on the target architecture.

[Peter Saunderson]

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

Re: Cross compiler which runs on the target architecture.

[Peter Saunderson]

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
>

Re: [yocto] Cross compiler which runs on the target architecture

[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

Re: [yocto] Cross compiler which runs on the target architecture

[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,

> Kind regards
>    Stefan
> 
> 
> 
> 
> 

Re: [yocto] Cross compiler which runs on the target architecture

[Stefan Herbrechtsmeier]

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
>      >
>      >
>      > 
>      >
> 

Re: [yocto] Cross compiler which runs on the target architecture

[Stefan Herbrechtsmeier]

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

Re: Cross compiler which runs on the target architecture

[Peter]

[-- 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 --]

Re: [yocto] Cross compiler which runs on the target architecture

[Stefan Herbrechtsmeier]

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

Re: Cross compiler which runs on the target architecture

[Peter]

[-- 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 --]