Issues adding bare meta toolchain to yocto build

Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

Hey,

I'm having issues adding a build for a bare metal target to my yocto toolchain. I've a NXP SoC with a M4 core and I would like to integrate the M4 binary build into yocto.
My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to locate the toolchain and everything works fine locally.

I've create a recipe for the toolchain that is heavily inspired by a TI recipe for the gcc-arm-none-eabi (available here: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master).
I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.

After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete toolchain.

My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):

inherit pkgconfig cmake
DEPENDS = "gcc-arm-none-eabi-native"

S = "${WORKDIR}/git "

EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
                 -G "Unix Makefiles" \
                 -DCMAKE_BUILD_TYPE=release'

From my understanding depending on gcc-arm-none-eabi-native should result in the native toolchain being installed into the m4's recipe-sysroot-native folder.
The sysroot-providers in the recipe-sysroot-native folder does list gcc-arm-none-eabi-native, but I don't get the files and therefore have no toolchain.

Any suggestions on what I'm doing wrong or how to debug this further?

Best regards, Olli

Re: Issues adding bare meta toolchain to yocto build

[Richard Purdie]

On Wed, 2019-10-23 at 11:23 +0000, Westermann, Oliver wrote:
> Hey,
> 
> I'm having issues adding a build for a bare metal target to my yocto
> toolchain. I've a NXP SoC with a M4 core and I would like to
> integrate the M4 binary build into yocto.
> My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to
> locate the toolchain and everything works fine locally.
> 
> I've create a recipe for the toolchain that is heavily inspired by a
> TI recipe for the gcc-arm-none-eabi (available here: 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master
> ).
> I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.
> 
> After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the
> image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete
> toolchain.
> 
> My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):
> 
> inherit pkgconfig cmake
> DEPENDS = "gcc-arm-none-eabi-native"
> 
> S = "${WORKDIR}/git "
> 
> EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
>                  -G "Unix Makefiles" \
>                  -DCMAKE_BUILD_TYPE=release'
> 
> From my understanding depending on gcc-arm-none-eabi-native should
> result in the native toolchain being installed into the m4's recipe-
> sysroot-native folder.
> The sysroot-providers in the recipe-sysroot-native folder does list
> gcc-arm-none-eabi-native, but I don't get the files and therefore
> have no toolchain.
> 
> Any suggestions on what I'm doing wrong or how to debug this further?

Sounds like the sysroot filtering code doesn't know about this
directory and therefore doesn't pass it through to the recipe sysroot?

The recipe you link to is for an on target compiler, not one in the
sysroot.

I'm actually a little surprised you can't use our standard cross
compiler assuming this M4 core is on an ARM chip? It should be a case
of passing the right options to the compiler to target the M4?

Cheers,

Richard

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

>On Wed, 2019-10-23 at 15:34 +0000, Richard Purdie wrote:
>>On Wed, 2019-10-23 at 11:23 +0000, Westermann, Oliver wrote:
>> Hey,
>> [...]
>> Any suggestions on what I'm doing wrong or how to debug this further?
>Sounds like the sysroot filtering code doesn't know about this
>directory and therefore doesn't pass it through to the recipe sysroot?

Sorry to ask dumb questions, but what do you mean by "this directory"?
The toolchain directory created by the TI recipe? Shouldn't that be handled
by FILES_${PN}?

>The recipe you link to is for an on target compiler, not one in the
>sysroot.

Again, might be a stupid missunderstanding on my side: The recipe I linked
extracts a precompiled toolchain that is suitable only for x86_64 systems and 
allows a "native" package. From my current understanding, a native package is
to be used on the build host, which is what I'm intending to do here.

I managed to sucessfully add a native recipe for the NXP code signing tool
(which is only provided as a precompiled binary as well) which works as expected.

>I'm actually a little surprised you can't use our standard cross
>compiler assuming this M4 core is on an ARM chip? It should be a case
>of passing the right options to the compiler to target the M4?

I'm totally up for any infos on how to do this! I did google around for recipes
or examples that build a non-linux binary using yocto, but I couldn't really find
anything or any documentation. But maybe my searchterms (along "build baremetal 
arm binary using yocto") were off target. Can you point me at documentation, examples,
searchterms..?

>Cheers,
>
>Richard

Thanks for the help!

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard.purdie]

On Thu, 2019-10-24 at 10:03 +0000, Westermann, Oliver wrote:
> > On Wed, 2019-10-23 at 15:34 +0000, Richard Purdie wrote:
> > > On Wed, 2019-10-23 at 11:23 +0000, Westermann, Oliver wrote:
> > > Hey,
> > > [...]
> > > Any suggestions on what I'm doing wrong or how to debug this
> > > further?
> > Sounds like the sysroot filtering code doesn't know about this
> > directory and therefore doesn't pass it through to the recipe
> > sysroot?
> 
> Sorry to ask dumb questions, but what do you mean by "this
> directory"?
> The toolchain directory created by the TI recipe? Shouldn't that be
> handled by FILES_${PN}?

If its a target recipe, FILES makes sense.

If its a native recipe, there are no packages and therefore FILES
doesn't make sense.

> > The recipe you link to is for an on target compiler, not one in the
> > sysroot.
> 
> Again, might be a stupid missunderstanding on my side: The recipe I
> linked extracts a precompiled toolchain that is suitable only for
> x86_64 systems and  allows a "native" package. From my current
> understanding, a native package is to be used on the build host,
> which is what I'm intending to do here.

You are correct, that recipe disables the target version and appears to
provide a native binary. I can't actually see how it can work though.
Can you confirm that recipe does work?

> I managed to sucessfully add a native recipe for the NXP code signing
> tool (which is only provided as a precompiled binary as well) which
> works as expected.

If you install the binaries into ${bindir} they will. If you place them
somewhere else which the system doesn't know about, they probably
won't.

There are ways to make alternative locations work but I don't see any
of that in the above recipe.

> > I'm actually a little surprised you can't use our standard cross
> > compiler assuming this M4 core is on an ARM chip? It should be a
> > case
> > of passing the right options to the compiler to target the M4?
> 
> I'm totally up for any infos on how to do this! I did google around
> for recipes for examples that build a non-linux binary using yocto,
> but I couldn't really find anything or any documentation. But maybe
> my searchterms (along "build baremetal  arm binary using yocto") were
> off target. Can you point me at documentation, examples,
> searchterms..?

I'm saying I don't think you need a second toolchain. I think you could
use your existing arm toolchain with the right compiler options.

See https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special

So you'd just add the right flags to the compiler, something like:

XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib -nostdinc

i.e. tell it which processor to target and not to use standard
libraries/includes.

There isn't anything that special about a baremetal compiler except it
sets some different default flags and is missing the library support.

Cheers,

Richard

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[William Mills]

Hi Richard,

On 10/24/19 7:01 AM, richard.purdie@linuxfoundation.org wrote:
> On Thu, 2019-10-24 at 10:03 +0000, Westermann, Oliver wrote:
>>> On Wed, 2019-10-23 at 15:34 +0000, Richard Purdie wrote:
>>>> On Wed, 2019-10-23 at 11:23 +0000, Westermann, Oliver wrote:
>>>> Hey,
>>>> [...]
>>>> Any suggestions on what I'm doing wrong or how to debug this
>>>> further?
>>> Sounds like the sysroot filtering code doesn't know about this
>>> directory and therefore doesn't pass it through to the recipe
>>> sysroot?
>>
>> Sorry to ask dumb questions, but what do you mean by "this
>> directory"?
>> The toolchain directory created by the TI recipe? Shouldn't that be
>> handled by FILES_${PN}?
> 
> If its a target recipe, FILES makes sense.
> 
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.
> 
>>> The recipe you link to is for an on target compiler, not one in the
>>> sysroot.
>>
>> Again, might be a stupid missunderstanding on my side: The recipe I
>> linked extracts a precompiled toolchain that is suitable only for
>> x86_64 systems and  allows a "native" package. From my current
>> understanding, a native package is to be used on the build host,
>> which is what I'm intending to do here.
> 
> You are correct, that recipe disables the target version and appears to
> provide a native binary. I can't actually see how it can work though.
> Can you confirm that recipe does work?
> 

Denys can you confirm or add context?

>> I managed to sucessfully add a native recipe for the NXP code signing
>> tool (which is only provided as a precompiled binary as well) which
>> works as expected.
> 
> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
> 
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.
> 
>>> I'm actually a little surprised you can't use our standard cross
>>> compiler assuming this M4 core is on an ARM chip? It should be a
>>> case
>>> of passing the right options to the compiler to target the M4?
>>
>> I'm totally up for any infos on how to do this! I did google around
>> for recipes for examples that build a non-linux binary using yocto,
>> but I couldn't really find anything or any documentation. But maybe
>> my searchterms (along "build baremetal  arm binary using yocto") were
>> off target. Can you point me at documentation, examples,
>> searchterms..?

I started looking at this thread because I had the same questions.  Is
it possible to make a recipe depend on another version of GCC and
restart the whole GCC build process again with a different config.

Or does this need multi-config?

This is the question I was trying to ask the other day.

> 
> I'm saying I don't think you need a second toolchain. I think you could
> use your existing arm toolchain with the right compiler options.
> 
> See https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
> 
> So you'd just add the right flags to the compiler, something like:
> 
> XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib -nostdinc
> 
> i.e. tell it which processor to target and not to use standard
> libraries/includes.
> 
> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.
> 

Really??

Lets start with the fact that the ARM binary toolchain has been tested
with M4 cores.

Then understand that you will need to supply your own gcc compiler
helpers and all stdc functions even the ones that port well like strlen
and memcpy.  (Because everyone should embedded their own unoptimized
memcpy in their projects.)

This works for the kernel and u-boot but they were designed for this and
have many eyes on their version of memcpy etc.  They are also running on
the same CPU core as the Linux user space.

Given this I can believe this would work for CLang/LLVM if M4 support
was enabled at build time.  I am not convinced for GCC.

If the above really works then why does gcc insist on being compiled
again after the c library has been compiled?  I have asked and never got
an answer that I understood.  I have been told that it looks at the c
library headers and changes what it builds into the compiler.  Does all
that magic go away with just -nostdinc and -nostdlib?

I know this works for the kernel but targeting an RTOS or bare-metal for
a very different core would make me nervous.  Especially true if the M4
would need to link libraries that were built outside of OE.

I know I am pushing back hard but I am also hoping you will convince me
I am wrong.

Thanks,
Bill

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard.purdie]

Hi Bill,

On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
> I started looking at this thread because I had the same
> questions.  Is it possible to make a recipe depend on another version
> of GCC and restart the whole GCC build process again with a different
> config.
> 
> Or does this need multi-config?

A different version of gcc would be most easily handled with
multiconfig, yes.

> This is the question I was trying to ask the other day.
> 
> > I'm saying I don't think you need a second toolchain. I think you
> > could
> > use your existing arm toolchain with the right compiler options.
> > 
> > See 
> > https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
> > 
> > So you'd just add the right flags to the compiler, something like:
> > 
> > XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib
> > -nostdinc
> > 
> > i.e. tell it which processor to target and not to use standard
> > libraries/includes.
> > 
> > There isn't anything that special about a baremetal compiler except
> > it
> > sets some different default flags and is missing the library
> > support.
> > 
> 
> Really??

As I understand it. I'm by no means an expert but I do my best with the
OE toolchain recipes.

> Lets start with the fact that the ARM binary toolchain has been
> tested with M4 cores.

Sure, I'm not claiming this is a well travelled path. I don't see why
it shouldn't work though, or why it makes much difference with the
right compiler options.

> Then understand that you will need to supply your own gcc compiler
> helpers and all stdc functions even the ones that port well like
> strlen and memcpy.  (Because everyone should embedded their own
> unoptimized memcpy in their projects.)

Right, that is by definition baremetal.

> This works for the kernel and u-boot but they were designed for this
> and have many eyes on their version of memcpy etc.  They are also
> running on the same CPU core as the Linux user space.
> 
> Given this I can believe this would work for CLang/LLVM if M4 support
> was enabled at build time.  I am not convinced for GCC.
> 
> If the above really works then why does gcc insist on being compiled
> again after the c library has been compiled?  I have asked and never
> got an answer that I understood.  I have been told that it looks at
> the c library headers and changes what it builds into the compiler.

I've never understood that either and looked into it. Back in December
last year, we dropped gcc-cross-initial:

http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc?id=0afd3ac3ada35dd986aaf3be41d7177dc6b71ade

After that, YP does no longer rebuild gcc after building the c library,
there is one cross toolchain. That one toolchain is used for all
different arm targets, its only architecture specific.

The only thing we do rebuild is libgcc, which is why there is still a
libgcc-initial and a libgcc, the latter being built after libc. That
much kind of makes sense.

>   Does all that magic go away with just -nostdinc and -nostdlib?

I believe so, yes.

> I know this works for the kernel but targeting an RTOS or bare-metal
> for a very different core would make me nervous.  Especially true if
> the M4 would need to link libraries that were built outside of OE.
> 
> I know I am pushing back hard but I am also hoping you will convince
> me I am wrong.

You're probably right to have some concerns in that its not a well
travelled path. There are libc specifics encoded into libgcc but I
can't quite see where they change how gcc behaves other that the
default option selection.

Equally there may be something I'm missing.

For full disclosure, gcc is built against linux-libc-headers wherease
with baremetal it would be built without headers. I believe that
changes the default options gcc uses for compiling but not the way the
compiler itself works.

Cheers,

Richard

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[William Mills]

On 10/24/19 10:02 AM, richard.purdie@linuxfoundation.org wrote:
> Hi Bill,
> 
> On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
>> I started looking at this thread because I had the same
>> questions.  Is it possible to make a recipe depend on another version
>> of GCC and restart the whole GCC build process again with a different
>> config.
>>
>> Or does this need multi-config?
> 
> A different version of gcc would be most easily handled with
> multiconfig, yes.
> 
>> This is the question I was trying to ask the other day.
>>
>>> I'm saying I don't think you need a second toolchain. I think you
>>> could
>>> use your existing arm toolchain with the right compiler options.
>>>
>>> See 
>>> https://stackoverflow.com/questions/28514507/what-makes-bare-metal-tool-chains-special
>>>
>>> So you'd just add the right flags to the compiler, something like:
>>>
>>> XXX-gcc -mcpu=cortex-m4 -march=armv7e-m -ffreestanding -nostdlib
>>> -nostdinc
>>>
>>> i.e. tell it which processor to target and not to use standard
>>> libraries/includes.
>>>
>>> There isn't anything that special about a baremetal compiler except
>>> it
>>> sets some different default flags and is missing the library
>>> support.
>>>
>>
>> Really??
> 
> As I understand it. I'm by no means an expert but I do my best with the
> OE toolchain recipes.
> 
>> Lets start with the fact that the ARM binary toolchain has been
>> tested with M4 cores.
> 
> Sure, I'm not claiming this is a well travelled path. I don't see why
> it shouldn't work though, or why it makes much difference with the
> right compiler options.
> 
>> Then understand that you will need to supply your own gcc compiler
>> helpers and all stdc functions even the ones that port well like
>> strlen and memcpy.  (Because everyone should embedded their own
>> unoptimized memcpy in their projects.)
> 
> Right, that is by definition baremetal.
> 

Well not really.  All the "bare-metal" toolchains I have used come with
a proper libgcc and some conig of newlib that at least gets you usable
strlen and memcpy etc.  How much of the rest of it is usable on your
platform is variable.

This is true of the toolchain Oliver is pointing at and has been true
back to 2007 when I was using codesourcery releases.

>> This works for the kernel and u-boot but they were designed for this
>> and have many eyes on their version of memcpy etc.  They are also
>> running on the same CPU core as the Linux user space.
>>
>> Given this I can believe this would work for CLang/LLVM if M4 support
>> was enabled at build time.  I am not convinced for GCC.
>>
>> If the above really works then why does gcc insist on being compiled
>> again after the c library has been compiled?  I have asked and never
>> got an answer that I understood.  I have been told that it looks at
>> the c library headers and changes what it builds into the compiler.
> 
> I've never understood that either and looked into it. Back in December
> last year, we dropped gcc-cross-initial:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/recipes-devtools/gcc?id=0afd3ac3ada35dd986aaf3be41d7177dc6b71ade
> 

Cool, good to know.

> After that, YP does no longer rebuild gcc after building the c library,
> there is one cross toolchain. That one toolchain is used for all
> different arm targets, its only architecture specific.
> 
> The only thing we do rebuild is libgcc, which is why there is still a
> libgcc-initial and a libgcc, the latter being built after libc. That
> much kind of makes sense.
> 
>>   Does all that magic go away with just -nostdinc and -nostdlib?
> 
> I believe so, yes.
> 
>> I know this works for the kernel but targeting an RTOS or bare-metal
>> for a very different core would make me nervous.  Especially true if
>> the M4 would need to link libraries that were built outside of OE.
>>
>> I know I am pushing back hard but I am also hoping you will convince
>> me I am wrong.
> 
> You're probably right to have some concerns in that its not a well
> travelled path. There are libc specifics encoded into libgcc but I
> can't quite see where they change how gcc behaves other that the
> default option selection.
> 
> Equally there may be something I'm missing.
> 
> For full disclosure, gcc is built against linux-libc-headers wherease
> with baremetal it would be built without headers. I believe that
> changes the default options gcc uses for compiling but not the way the
> compiler itself works.

"baremetal" would be compiled against some config of newlib headers.
newlib has its own issues and many config choices (you get to pick your
threading model: none, bad, or hacky).  For TI-RTOS I think we rebuild
it with a different thread model.

Thanks,
Bill

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

> On Thu, 2019-10-24 at 04:01 +0000, Richard Purdie wrote:
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.

Oh, I have to admit I'm pretty new to the concept of the native packages.
Where can I find the list of files that are considered to be installed into
a "native" packages sysroot?

An good option for me would be to eg. install the toolchain into the native
sysroots /opt/ dir for usage by other recipes.

> Can you confirm that recipe does work?

For the TI recipe, no, I can't. I found it online and used it as a guide for
my first steps on the topic.


> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
> 
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.

Can you point me to these ways? :)

> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.

I agree, though using linaro has the benefit that we would use the same
toolchain in yocto as in "regular development" of the m4 functionality.

Best regards, Olli

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard.purdie]

On Thu, 2019-10-24 at 15:37 +0000, Westermann, Oliver wrote:
> > On Thu, 2019-10-24 at 04:01 +0000, Richard Purdie wrote:
> > If its a native recipe, there are no packages and therefore FILES
> > doesn't make sense.
> 
> Oh, I have to admit I'm pretty new to the concept of the native
> packages.
> Where can I find the list of files that are considered to be
> installed into a "native" packages sysroot?

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/staging.bbclass

SYSROOT_DIRS_NATIVE vs. just SYSROOT_DIRS
(at the top of the file)

The code which uses these is below in that file and handles which files
get "staged". We stage a different set for native and target.

> An good option for me would be to eg. install the toolchain into the
> native sysroots /opt/ dir for usage by other recipes.

You can probably do that by extending SYSROOT_DIRS in the recipe.

> > Can you confirm that recipe does work?
> 
> For the TI recipe, no, I can't. I found it online and used it as a
> guide for my first steps on the topic.
>
> 
> > If you install the binaries into ${bindir} they will. If you place
> > them
> > somewhere else which the system doesn't know about, they probably
> > won't.
> > 
> > There are ways to make alternative locations work but I don't see
> > any
> > of that in the above recipe.
> 
> Can you point me to these ways? :)

See above, easiest is extending SYSROOT_DIRS.

> > There isn't anything that special about a baremetal compiler except
> > it sets some different default flags and is missing the library
> > support.
> 
> I agree, though using linaro has the benefit that we would use the
> same toolchain in yocto as in "regular development" of the m4
> functionality.

Agreed. If you want a newlib compiler (which is a bit more than
baremetal as I understand the term) you'd need a multiconfig build to
generate one too as discussed in the other part of the thread.

Cheers,

Richard

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

Thanks for all the help so far, I have a working recipe which installs the whole
toolchain to /usr/bin and uses that from another recipe :)

> On Thu, 2019-10-24 at 08:55 +0000, Richard Purdie wrote:
> You can probably do that by extending SYSROOT_DIRS in the recipe.

I'm still having issues here: I've tried to extend SYSROOOT_DIRS and even used a
path relative to the existing entrys (so I don't get caught by some hidden
extension mechanism), but my files still don't end up in the sysroot.
I've also tried both, SYSROOOT_DIRS and SYSROOT_DIRS_NATIVE, with the same result.

A (hopefully) last tip would be appreciated to make a nice recipe from a working one.

GCC_ARM_NONE_EXTRA_PATH="/${PN}"
SYSROOOT_DIRS += "${bindir}/../opt"

do_install() {
    # old and working to install to /usr/bin/
    # install -d ${D}${bindir}${GCC_ARM_NONE_EXTRA_PATH}
    # cp -r ${S}/* ${D}${bindir}${GCC_ARM_NONE_EXTRA_PATH}
    
    # new, but no files in the sysroots of recipes using the toolchain
    install -d ${D}${bindir}/../opt${GCC_ARM_NONE_EXTRA_PATH}
    cp -r ${S}/* ${D}${bindir}/../opt${GCC_ARM_NONE_EXTRA_PATH}
}

Best regards, Olli

Re: [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[richard.purdie]

On Thu, 2019-10-24 at 10:30 -0400, William Mills wrote:
> On 10/24/19 10:02 AM, richard.purdie@linuxfoundation.org wrote:
> > On Thu, 2019-10-24 at 09:43 -0400, William Mills wrote:
> > > Then understand that you will need to supply your own gcc
> > > compiler
> > > helpers and all stdc functions even the ones that port well like
> > > strlen and memcpy.  (Because everyone should embedded their own
> > > unoptimized memcpy in their projects.)
> > 
> > Right, that is by definition baremetal.
> > 
> 
> Well not really.  All the "bare-metal" toolchains I have used come
> with a proper libgcc and some conig of newlib that at least gets you
> usable strlen and memcpy etc.  How much of the rest of it is usable
> on your platform is variable.
> 
> This is true of the toolchain Oliver is pointing at and has been true
> back to 2007 when I was using codesourcery releases.

The baremetal libgcc would be libgcc-initial in OE terms. As for
"baremetal", OE defines that as no library. You can see the options in
this listing:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include

tclibc-baremetal.inc
tclibc-glibc.inc
tclibc-musl.inc
tclibc-newlib.inc

So we support newlib builds but that is different to our definition of
baremetal. So we conflicting usage of terms.

> > You're probably right to have some concerns in that its not a well
> > travelled path. There are libc specifics encoded into libgcc but I
> > can't quite see where they change how gcc behaves other that the
> > default option selection.
> > 
> > Equally there may be something I'm missing.
> > 
> > For full disclosure, gcc is built against linux-libc-headers
> > wherease
> > with baremetal it would be built without headers. I believe that
> > changes the default options gcc uses for compiling but not the way
> > the
> > compiler itself works.
> 
> "baremetal" would be compiled against some config of newlib headers.
> newlib has its own issues and many config choices (you get to pick
> your threading model: none, bad, or hacky).  For TI-RTOS I think we
> rebuild it with a different thread model.

Our baremetal is compiled with no headers. Newlib is effectively like
choosing a different C library, and yes, gcc would be built against its
headers and use it to link against. You would need multiconfig to mix a
newlib and musl/glibc toolchain.

Sorry for the confusion over the terms.

Cheers,

Richard