[yocto] [meta-selinux][PATCH] kernel: Remove non-existing kernel option

[zhe.he]

From: He Zhe 

CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION has been remove from mainline kernel
by the commit 4c145dce2601 ("xfrm: make xfrm modes builtin").

Signed-off-by: He Zhe 
---
 recipes-kernel/linux/files/selinux.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-kernel/linux/files/selinux.cfg 
b/recipes-kernel/linux/files/selinux.cfg
index 2edd366..7d16dc5 100644
--- a/recipes-kernel/linux/files/selinux.cfg
+++ b/recipes-kernel/linux/files/selinux.cfg
@@ -23,7 +23,6 @@ CONFIG_SECURITYFS=y
 CONFIG_SECURITY_NETWORK=y
 CONFIG_SECURITY_SELINUX=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
-CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
 CONFIG_SECURITY_SELINUX_DISABLE=y
 CONFIG_SECURITY_SELINUX_DEVELOP=y
 CONFIG_SECURITY_SELINUX_AVC_STATS=y
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH] kernel: Remove non-existing kernel option

[zhe.he]

From: He Zhe 

CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION has been removed from mainline kernel
by commit 4c145dce2601 ("xfrm: make xfrm modes builtin").

Signed-off-by: He Zhe 
---
 meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg 
b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
index 1efd63e..b10b839 100644
--- a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
+++ b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
@@ -19,7 +19,6 @@ CONFIG_REISERFS_FS_SECURITY=y
 CONFIG_JFFS2_FS_SECURITY=y
 CONFIG_SECURITYFS=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
-CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
 CONFIG_SECURITY_SELINUX_DISABLE=y
 CONFIG_SECURITY_SELINUX_DEVELOP=y
 CONFIG_SECURITY_SELINUX_AVC_STATS=y
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] kernel: Remove non-existing kernel option

[He Zhe]

typo in commit log, v2 will be sent.

Zhe

On 10/24/19 4:42 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION has been remove from mainline kernel
> by the commit 4c145dce2601 ("xfrm: make xfrm modes builtin").
>
> Signed-off-by: He Zhe 
> ---
>  recipes-kernel/linux/files/selinux.cfg | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/recipes-kernel/linux/files/selinux.cfg 
> b/recipes-kernel/linux/files/selinux.cfg
> index 2edd366..7d16dc5 100644
> --- a/recipes-kernel/linux/files/selinux.cfg
> +++ b/recipes-kernel/linux/files/selinux.cfg
> @@ -23,7 +23,6 @@ CONFIG_SECURITYFS=y
>  CONFIG_SECURITY_NETWORK=y
>  CONFIG_SECURITY_SELINUX=y
>  CONFIG_SECURITY_SELINUX_BOOTPARAM=y
> -CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
>  CONFIG_SECURITY_SELINUX_DISABLE=y
>  CONFIG_SECURITY_SELINUX_DEVELOP=y
>  CONFIG_SECURITY_SELINUX_AVC_STATS=y

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH v2] kernel: Remove non-existing kernel option

[zhe.he]

From: He Zhe 

CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE has been removed from mainline kernel
by commit be6ec88f41ba ("selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE").

Signed-off-by: He Zhe 
---
 meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg 
b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
index 1efd63e..b10b839 100644
--- a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
+++ b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
@@ -19,7 +19,6 @@ CONFIG_REISERFS_FS_SECURITY=y
 CONFIG_JFFS2_FS_SECURITY=y
 CONFIG_SECURITYFS=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
-CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
 CONFIG_SECURITY_SELINUX_DISABLE=y
 CONFIG_SECURITY_SELINUX_DEVELOP=y
 CONFIG_SECURITY_SELINUX_AVC_STATS=y
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-selinux][PATCH v2] kernel: Remove non-existing kernel option

[zhe.he]

From: He Zhe 

CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE has been remove from mainline kernel
by the commit be6ec88f41ba ("selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE").

Signed-off-by: He Zhe 
---
 recipes-kernel/linux/files/selinux.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/recipes-kernel/linux/files/selinux.cfg 
b/recipes-kernel/linux/files/selinux.cfg
index 2edd366..7d16dc5 100644
--- a/recipes-kernel/linux/files/selinux.cfg
+++ b/recipes-kernel/linux/files/selinux.cfg
@@ -23,7 +23,6 @@ CONFIG_SECURITYFS=y
 CONFIG_SECURITY_NETWORK=y
 CONFIG_SECURITY_SELINUX=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
-CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
 CONFIG_SECURITY_SELINUX_DISABLE=y
 CONFIG_SECURITY_SELINUX_DEVELOP=y
 CONFIG_SECURITY_SELINUX_AVC_STATS=y
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cgl][PATCH] kernel: Remove non-existing kernel option

[He Zhe]

typo in commit log, v2 will be sent.

Zhe


On 10/24/19 4:48 PM, zhe...@windriver.com wrote:
> From: He Zhe 
>
> CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION has been removed from mainline kernel
> by commit 4c145dce2601 ("xfrm: make xfrm modes builtin").
>
> Signed-off-by: He Zhe 
> ---
>  meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg 
> b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
> index 1efd63e..b10b839 100644
> --- a/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
> +++ b/meta-cgl-common/recipes-kernel/linux/files/cfg/00014-selinux.cfg
> @@ -19,7 +19,6 @@ CONFIG_REISERFS_FS_SECURITY=y
>  CONFIG_JFFS2_FS_SECURITY=y
>  CONFIG_SECURITYFS=y
>  CONFIG_SECURITY_SELINUX_BOOTPARAM=y
> -CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
>  CONFIG_SECURITY_SELINUX_DISABLE=y
>  CONFIG_SECURITY_SELINUX_DEVELOP=y
>  CONFIG_SECURITY_SELINUX_AVC_STATS=y

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Westermann, Oliver]

>On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
>>On Wed, 2019-10-23 at 11:23 +, 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!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[richard . purdie]

On Thu, 2019-10-24 at 10:03 +, Westermann, Oliver wrote:
> > On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
> > > On Wed, 2019-10-23 at 11:23 +, 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




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[William Mills]

Hi Richard,

On 10/24/19 7:01 AM, richard.pur...@linuxfoundation.org wrote:
> On Thu, 2019-10-24 at 10:03 +, Westermann, Oliver wrote:
>>> On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
 On Wed, 2019-10-23 at 11:23 +, 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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[William Mills]

On 10/24/19 10:02 AM, richard.pur...@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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

> On Thu, 2019-10-24 at 04:01 +, 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

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Canceled event with note: Yocto Project Weekly Triage Meeting @ Thu Oct 31, 2019 7:30am - 8:30am (PDT) (yocto@yoctoproject.org)

[theyoctoproject]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:CANCEL
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/Los_Angeles:20191031T073000
DTEND;TZID=America/Los_Angeles:20191031T083000
DTSTAMP:20191024T153116Z
ORGANIZER;CN=theyoctoproj...@gmail.com:mailto:theyoctoproj...@gmail.com
UID:69b8n4lifp3et8i02e5gp0h9dk_r20190124t153...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=sj
 olley.yp...@gmail.com;X-NUM-GUESTS=0:mailto:sjolley.yp...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=theyoc
 toproj...@gmail.com;X-NUM-GUESTS=0:mailto:theyoctoproj...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=yo
 c...@yoctoproject.org;X-NUM-GUESTS=0:mailto:yocto@yoctoproject.org
RECURRENCE-ID;TZID=America/Los_Angeles:20191031T073000
CREATED:20180524T175433Z
DESCRIPTION:Yocto Project Weekly Triage Meeting Details\n\n\nWiki: https://
 wiki.yoctoproject.org/wiki/Bug_Triage\n\n\nYocto IRC: http://webchat.freeno
 de.net/?channels=#yocto - When you join state your name on the bridge or IR
 C.\n\nWe use a Zoom Bridge at: https://zoom.us/j/454367603
LAST-MODIFIED:20191024T153115Z
LOCATION:Zoom Meeting: https://zoom.us/j/454367603
SEQUENCE:1
STATUS:CANCELLED
SUMMARY:Yocto Project Weekly Triage Meeting
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H15M0S
END:VALARM
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Westermann, Oliver]

> On Thu, 2019-10-24 at 04:01 +, 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
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] kernel oops/panic stack trace decoding

[karthik poduval]

Hi All,

I was wondering if there is any yocto supplied tools/shortcuts to
changing kernel oops/panic log to line numbers in source code ?

-- 
Regards,
Karthik Poduval
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [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.pur...@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





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel oops/panic stack trace decoding

[Nicolas Dechesne]

On Thu, Oct 24, 2019 at 5:47 PM karthik poduval
 wrote:
>
> Hi All,
>
> I was wondering if there is any yocto supplied tools/shortcuts to
> changing kernel oops/panic log to line numbers in source code ?

it's not yocto specific, but i like using scripts/decode_stacktrace.sh
from the kernel source tree.

>
> --
> Regards,
> Karthik Poduval
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[richard . purdie]

On Thu, 2019-10-24 at 15:37 +, Westermann, Oliver wrote:
> > On Thu, 2019-10-24 at 04:01 +, 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





-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [PATCH][opkg] bug 13528 add SPDX id to opkg

[Alejandro Del Castillo]

Hi Yann,

Thanks again for adding the headers. Your patch looks good, except for
one line that has a duplicated header:

/core/26_prefer_arch_to_version.py
index 0a0d66b..82934c1 100755
--- a/tests/core/26_prefer_arch_to_version.py
+++ b/tests/core/26_prefer_arch_to_version.py
@@ -1,4 +1,5 @@
-#! /usr/bin/env python3
+#! /usr/bin/env python3# SPDX-License-Identifier: GPL-2.0-only
+# SPDX-License-Identifier: GPL-2.0-only
  #

could you send a v2? regarding m4 files, I looked around a bit and 
didn't find project adding SPDX identifiers to them

Cheers,

Alejandro

On 10/22/19 9:55 AM, Yann CARDAILLAC wrote:
> Hi,
> 
> I'm working on bug : 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13528 
> 
>
>  I've a first patch proposal. Note that I didn't knew what to do with
>  m4/gpgme.m4 the license header seems pretty weird to me...
> 
> Regards,
> 
> -- SMILE 
> 
>
>  20 rue des Jardins 92600 Asnières-sur-Seine
> 
>  *Yann CARDAILLAC* Ingénieur Systèmes Embarqués
> 
> email yann.cardail...@smile.fr  url
> http://www.smile.eu 
> 
> 
> 
> 
> Twitter 
> 
>  Facebook 
> 
>  LinkedIn 
> 
>  Github 
> 
> 
> 
> 
> 
> 
> eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
> 
> -- You received this message because you are subscribed to the Google
>  Groups "opkg-devel" group. To unsubscribe from this group and stop
> receiving emails from it, send an email to
> opkg-devel+unsubscr...@googlegroups.com 
> . To view this
> discussion on the web visit 
> https://groups.google.com/d/msgid/opkg-devel/CAA984JWqcX5oDhumXYBom%2BZyxD%2Bbo7oGmTzLx_tXejvPaR1UKQ%40mail.gmail.com
>  
> .

--
> 
Cheers,

Alejandro
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel oops/panic stack trace decoding

[karthik poduval]

Thanks Nicolas,

Can this be tied to a yocto command, something like by adding a new
stacktrace.bbclass (since yocto knows everything about the cross
compiler, vmlinux path, not kernel modules path though)
bitbake virtual/kernel -c decode_stacktrace < stacktrace.txt

Any thoughts or comments ?

--
Regards,
Karthik Poduval

On Thu, Oct 24, 2019 at 8:55 AM Nicolas Dechesne
 wrote:
>
> On Thu, Oct 24, 2019 at 5:47 PM karthik poduval
>  wrote:
> >
> > Hi All,
> >
> > I was wondering if there is any yocto supplied tools/shortcuts to
> > changing kernel oops/panic log to line numbers in source code ?
>
> it's not yocto specific, but i like using scripts/decode_stacktrace.sh
> from the kernel source tree.
>
> >
> > --
> > Regards,
> > Karthik Poduval
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto



-- 
Regards,
Karthik Poduval
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Openembedded-architecture] Yocto Project LTS Proposal/Discussion

[Nicholas Krause]

On 10/24/19 8:15 PM, Rich Persaud wrote:

This came directly to me -- did you mean to copy the list?

Rich


Sorry misclick on my end Rich.

Nick




On Oct 24, 2019, at 20:13, Nicholas Krause  wrote:




On 10/24/19 8:08 PM, Rich Persaud wrote:

/(adding the automated-testing list)/

On Oct 24, 2019, at 18:52, Richard Purdie 
 wrote:


I'm posting this to openembedded-architecture since it probably is the
best place for discussions about OE/Yocto planning.

The Yocto Project TSC believes one of the things needed for YP and for
OE is more information being pulled together about how an LTS release
could work. The document linked to below is the information it was able
to collate together on the subject. Its the result of some long
discussions by the TSC.
...
The key thing needed to make this happen is a resource commitment to
it. Without such a commitment it is simply not feasible.


Vendors who provide commercial support for OE/Yocto-based products 
may already be investing downstream resources for equivalent "LTS" 
support.  May be useful for the document to show the financial 
benefits of shifting a percentage of downstream LTS validation 
resources to upstream Yocto LTS.



There may be
new companies willing to join the project in order to make it happen,
if so we should talk further.

The document:

https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sUkyc/


> The project components to be covered would need to match those 
included in our standard release process and should be clearly 
defined. Those components would be:

> Bitbake
> OE-Core
> Meta-yocto
> yocto-docs
...
> For simplicity, it is also proposed that only automated testing be 
used for testing the LTS and that any current manual QA is not 
performed.

...
> Only run virtualized tests
> Only support one host distro, an Ubuntu LTS as it has right lifespan

When the first Yocto LTS release is available, could that become the 
host distro for automated testing?  That would provide Yocto 
automated testing with supply chain integrity benefits from Yocto. 
 If we take that path, with automated testing based on 
virtualization, could we add meta-virtualization to the list of 
Yocto LTS release components?


Yocto-on-Yocto automated testing could reduce risks [1] that impact 
software supply chains. A potential topic for the ATS event [2] next 
week.


Rich


One concern on the toolchain or lanuage side  is what happens if 
something like a new C++ release happens or similar. Do you plan on 
allowing toolchain migration to using the newer version of a given 
lanuage.


May be worth considering,

Nick



[1] https://www.platformsecuritysummit.com/2019/speaker/sherman/

[2] https://elinux.org/Automated_Testing_Summit_2019


___
Openembedded-architecture mailing list
openembedded-architect...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto