question on meta-ti for yocto

question on meta-ti for yocto

[Marco Monguzzi]

[-- Attachment #1: Type: text/plain, Size: 1226 bytes --]

Dear Sirs,

I am dumping this mail to ask for some clarifications. I am looking closely
to yocto as environment for
building embedded linux distro for omap based boards.

In particular, I do have AM3517 and DM3730 custom boards to support.

I am seeing that TI has made available meta-ti on yocto git that looks like
a good starting point for me.

But at same time the readme.txt does spot incompatibilities with the
current yocto structure and points
to open embeded and angstron layers.

I am confused. When do you plan full compatibility with yocto?

Would the gcc-4.5 toolchain grant full compatibility with neon?

I am asking this because other players such as Denx (with its own ELDK
www.denx.de) are providing an armv7a based on gcc-4.6
that I could test with "CFLAGS= -march=armv7-a -fno-tree-vectorize
-mthumb-interwork -mfloat-abi=softfp -mfpu=neon"
and observe operating fine on AM3517.

I am wondering what is the best way to go:

- attempt integrating meta-ti with yocto for portions I need (davinci
support for sure on DM3730)
- or stick with meta-ti as it is and develop my own recipes for custom hw
as meta-ti bsp.

Thanks in advance for your time.

Regards,
Marco Monguzzi

[-- Attachment #2: Type: text/html, Size: 1551 bytes --]

Re: question on meta-ti for yocto

[Koen Kooi]

Op 21 mrt. 2012, om 15:58 heeft Marco Monguzzi het volgende geschreven:

> Dear Sirs,
> 
> I am dumping this mail to ask for some clarifications. I am looking closely to yocto as environment for 
> building embedded linux distro for omap based boards.

Yocto or poky? If you're after yocto, just follow the instructions in the README, that will get you that using the yocto framework. If you're after poky, that's something completely different.

regards,

Koen

Re: question on meta-ti for yocto

[Russell Senior]

>>>>> "Koen" == Koen Kooi <koen@dominion.thruhere.net> writes:

>> I am dumping this mail to ask for some clarifications. I am looking
>> closely to yocto as environment for building embedded linux distro
>> for omap based boards.

Koen> Yocto or poky? If you're after yocto, just follow the
Koen> instructions in the README, that will get you that using the
Koen> yocto framework. If you're after poky, that's something
Koen> completely different.

A yocto guy I was recently talking to implied that yocto more or less
equal'd poky.  Frankly, I find these code words baffling.  Can you
explain or point me at an explanation of the distinction between OE,
yocto and poky?

http://www.yoctoproject.org/projects/poky

http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html
  "The Yocto Project through the Poky build system provides an open
   source development environment targeting [...]"


-- 
Russell Senior, President
russell@personaltelco.net

Re: question on meta-ti for yocto

[Denys Dmytriyenko]

On Wed, Mar 21, 2012 at 01:42:12PM -0700, Russell Senior wrote:
> >>>>> "Koen" == Koen Kooi <koen@dominion.thruhere.net> writes:
> 
> >> I am dumping this mail to ask for some clarifications. I am looking
> >> closely to yocto as environment for building embedded linux distro
> >> for omap based boards.
> 
> Koen> Yocto or poky? If you're after yocto, just follow the
> Koen> instructions in the README, that will get you that using the
> Koen> yocto framework. If you're after poky, that's something
> Koen> completely different.
> 
> A yocto guy I was recently talking to implied that yocto more or less
> equal'd poky.  Frankly, I find these code words baffling.  Can you
> explain or point me at an explanation of the distinction between OE,
> yocto and poky?
> 
> http://www.yoctoproject.org/projects/poky
> 
> http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html
>   "The Yocto Project through the Poky build system provides an open
>    source development environment targeting [...]"

https://lists.yoctoproject.org/pipermail/meta-ti/2012-February/000498.html

-- 
Denys

Re: question on meta-ti for yocto

[Koen Kooi]

Op 21 mrt. 2012, om 21:42 heeft Russell Senior het volgende geschreven:

>>>>>> "Koen" == Koen Kooi <koen@dominion.thruhere.net> writes:
> 
>>> I am dumping this mail to ask for some clarifications. I am looking
>>> closely to yocto as environment for building embedded linux distro
>>> for omap based boards.
> 
> Koen> Yocto or poky? If you're after yocto, just follow the
> Koen> instructions in the README, that will get you that using the
> Koen> yocto framework. If you're after poky, that's something
> Koen> completely different.
> 
> A yocto guy I was recently talking to implied that yocto more or less
> equal'd poky.  

Yes, they tend to do that a lot, don't they?

> Frankly, I find these code words baffling.  Can you
> explain or point me at an explanation of the distinction between OE,
> yocto and poky?

Poky used to be a fork of OE that got picked up when the yocto project was founded. After yocto was announced we all agreed they would drop the 'poky'  name and bits and continue together as 'oe-core'. 
What is happening is that some yocto marketing folks are a bit too attached to the poky name and want to muddy the waters. The more confusion, the more business for yocto certified consultants.

regards,

Koen

Re: question on meta-ti for yocto

[Richard Purdie]

On Wed, 2012-03-21 at 21:48 +0100, Koen Kooi wrote:
> Op 21 mrt. 2012, om 21:42 heeft Russell Senior het volgende
> geschreven:
> >>>>>> "Koen" == Koen Kooi <koen@dominion.thruhere.net> writes:
> > 
> >>> I am dumping this mail to ask for some clarifications. I am
> looking
> >>> closely to yocto as environment for building embedded linux distro
> >>> for omap based boards.
> > 
> > Koen> Yocto or poky? If you're after yocto, just follow the
> > Koen> instructions in the README, that will get you that using the
> > Koen> yocto framework. If you're after poky, that's something
> > Koen> completely different.
> > 
> > A yocto guy I was recently talking to implied that yocto more or
> less
> > equal'd poky.  
> 
> Yes, they tend to do that a lot, don't they?
> 
> > Frankly, I find these code words baffling.  Can you
> > explain or point me at an explanation of the distinction between OE,
> > yocto and poky?
> 
> Poky used to be a fork of OE that got picked up when the yocto project
> was founded. After yocto was announced we all agreed they would drop
> the 'poky'  name and bits and continue together as 'oe-core'. 
> What is happening is that some yocto marketing folks are a bit too
> attached to the poky name and want to muddy the waters. The more
> confusion, the more business for yocto certified consultants.

I've really just about had enough of this since the descriptions you
give out don't exactly help much and its a game of deflection.

Yocto is the overall project which is aiming to make embedded Linux
easier and improve the tooling. Yocto and OpenEmbedded agreed to work on
and share OpenEmbedded-Core. It was agreed that Poky would continue as a
sub-project of Yocto which was there to test and demonstrate OE-Core on
real hardware and give people something they could pick up and get
started with in a simple "one stop" single checkout manner.

Poky is living true to that agreement.

What I really find *extremely* distasteful is that despite repeated
requests, meta-ti still has hard dependencies on meta-oe and worse,
meta-angstrom and is not following the spirit of the agreements made
about working together on OE-Core. The idea was to better separate out
hardware from distribution policy and give people clear guidance over
layers. To put it simply, meta-ti has yet to do this. I cannot take
meta-ti and have it work against oe-core alone, or against poky.

The amount of confusion this is causing users is immense as we see from
new users and experienced ones alike. Whilst I know people have nodded
and agreed they're going to fix it, time goes on and we don't seem to
make much progress.

The biggest confusion factor out there at the moment is meta-ti, not
poky and I'd like to ask politely for people to get their act together.

Cheers,

Richard

Re: question on meta-ti for yocto

[Denys Dmytriyenko]

On Wed, Mar 21, 2012 at 09:27:26PM +0000, Richard Purdie wrote:
> On Wed, 2012-03-21 at 21:48 +0100, Koen Kooi wrote:
> > Op 21 mrt. 2012, om 21:42 heeft Russell Senior het volgende
> > geschreven:
> > >>>>>> "Koen" == Koen Kooi <koen@dominion.thruhere.net> writes:
> > > 
> > >>> I am dumping this mail to ask for some clarifications. I am
> > looking
> > >>> closely to yocto as environment for building embedded linux distro
> > >>> for omap based boards.
> > > 
> > > Koen> Yocto or poky? If you're after yocto, just follow the
> > > Koen> instructions in the README, that will get you that using the
> > > Koen> yocto framework. If you're after poky, that's something
> > > Koen> completely different.
> > > 
> > > A yocto guy I was recently talking to implied that yocto more or
> > less
> > > equal'd poky.  
> > 
> > Yes, they tend to do that a lot, don't they?
> > 
> > > Frankly, I find these code words baffling.  Can you
> > > explain or point me at an explanation of the distinction between OE,
> > > yocto and poky?
> > 
> > Poky used to be a fork of OE that got picked up when the yocto project
> > was founded. After yocto was announced we all agreed they would drop
> > the 'poky'  name and bits and continue together as 'oe-core'. 
> > What is happening is that some yocto marketing folks are a bit too
> > attached to the poky name and want to muddy the waters. The more
> > confusion, the more business for yocto certified consultants.
> 
> I've really just about had enough of this since the descriptions you
> give out don't exactly help much and its a game of deflection.
> 
> Yocto is the overall project which is aiming to make embedded Linux
> easier and improve the tooling. Yocto and OpenEmbedded agreed to work on
> and share OpenEmbedded-Core. It was agreed that Poky would continue as a
> sub-project of Yocto which was there to test and demonstrate OE-Core on
> real hardware and give people something they could pick up and get
> started with in a simple "one stop" single checkout manner.
> 
> Poky is living true to that agreement.
> 
> What I really find *extremely* distasteful is that despite repeated
> requests, meta-ti still has hard dependencies on meta-oe and worse,
> meta-angstrom and is not following the spirit of the agreements made
> about working together on OE-Core. The idea was to better separate out
> hardware from distribution policy and give people clear guidance over
> layers. To put it simply, meta-ti has yet to do this. I cannot take
> meta-ti and have it work against oe-core alone, or against poky.

Richard,

That's not true. There are no hard dependencies on meta-angstrom any more. And 
meta-oe is only needed to supply gcc-4.5 for now, until all the issues are 
ironed out.

I've been making numerous builds past few weeks with different combination of 
layers and besides few bugs I need to fix for the distro-less configuration, 
was quite successful getting meta-ti work with oe-core WITHOUT meta-angstrom!

There are some systemd dependencies, but they are no longer hard ones. There 
was discussion about moving beagle payload stuff off of meta-ti. But it should 
no longer break things.

> The amount of confusion this is causing users is immense as we see from
> new users and experienced ones alike. Whilst I know people have nodded
> and agreed they're going to fix it, time goes on and we don't seem to
> make much progress.
> 
> The biggest confusion factor out there at the moment is meta-ti, not
> poky and I'd like to ask politely for people to get their act together.

See above, the work is being done. The first wave of people who complained 
about those dependencies are now building their images. There are still 
confused people, but we'll clear the message once all obstacles are resolved.

Richard, Koen, please take your word-fight and name-calling offline! It's not 
a proper place here. Thank you.

-- 
Denys

Re: question on meta-ti for yocto

[Richard Purdie]

On Wed, 2012-03-21 at 17:45 -0400, Denys Dmytriyenko wrote:
> That's not true. There are no hard dependencies on meta-angstrom any more. And 
> meta-oe is only needed to supply gcc-4.5 for now, until all the issues are 
> ironed out.
> 
> I've been making numerous builds past few weeks with different combination of 
> layers and besides few bugs I need to fix for the distro-less configuration, 
> was quite successful getting meta-ti work with oe-core WITHOUT meta-angstrom!
> 
> There are some systemd dependencies, but they are no longer hard ones. There 
> was discussion about moving beagle payload stuff off of meta-ti. But it should 
> no longer break things.

I've been going by the information I see and the contents of the meta-ti
README. Reading the above it looks like much progress is being made,
things are changing and I really do appreciate that happening!

> > The amount of confusion this is causing users is immense as we see from
> > new users and experienced ones alike. Whilst I know people have nodded
> > and agreed they're going to fix it, time goes on and we don't seem to
> > make much progress.
> > 
> > The biggest confusion factor out there at the moment is meta-ti, not
> > poky and I'd like to ask politely for people to get their act together.
> 
> See above, the work is being done. The first wave of people who complained 
> about those dependencies are now building their images. There are still 
> confused people, but we'll clear the message once all obstacles are resolved.

Great, thanks!

> Richard, Koen, please take your word-fight and name-calling offline! It's not 
> a proper place here. Thank you.

Well said and I agree with you! :)

The trouble is Koen keeps doing this and nobody in general replies. The
lack of a reply can be seen as to condone what was said and its
certainly leading to people getting more confused. I think a response
was appropriate.

I also do not mean to undermine the progress being made on meta-ti. I
hadn't heard much for a while but it looks like things are moving
forward and that is great to see.

Cheers,

Richard

Re: question on meta-ti for yocto

[Denys Dmytriyenko]

On Wed, Mar 21, 2012 at 03:58:44PM +0100, Marco Monguzzi wrote:
> Dear Sirs,
> 
> I am dumping this mail to ask for some clarifications. I am looking closely

First of all, _dumping_ here is a very correct word, as you neglected 
subscribing to the mailing list, check the past archives and see if your 
question was previously answered, as required by Netiquette.


> to yocto as environment for
> building embedded linux distro for omap based boards.
> 
> In particular, I do have AM3517 and DM3730 custom boards to support.
> 
> I am seeing that TI has made available meta-ti on yocto git that looks like
> a good starting point for me.
> 
> But at same time the readme.txt does spot incompatibilities with the
> current yocto structure and points
> to open embeded and angstron layers.

I'm finishing my testing cycle to confirm that Angstrom layer is no longer 
mandated. I should have edited the README right after the hard dependency was 
removed, but I wanted first to do the extensive testing against oe-core, 
meta-arago and then meta-yocto. Unfortunately, meta-yocto testing is lagging 
behind. But it works fine with oe-core WITHOUT meta-angstrom and also I'm 
working on bringing up our own meta-arago. Working with oe-core in a 
distro-less configuration should qualify as being Yocto-compatible!


> I am confused. When do you plan full compatibility with yocto?
> 
> Would the gcc-4.5 toolchain grant full compatibility with neon?

Yes.


> I am asking this because other players such as Denx (with its own ELDK
> www.denx.de) are providing an armv7a based on gcc-4.6
> that I could test with "CFLAGS= -march=armv7-a -fno-tree-vectorize
> -mthumb-interwork -mfloat-abi=softfp -mfpu=neon"
> and observe operating fine on AM3517.

We have some build issues with gcc-4.6, hence sticking to 4.5 for a while 
longer. In most cases, especially for base BSP, gcc-4.6 should work just fine 
though.


> I am wondering what is the best way to go:
> 
> - attempt integrating meta-ti with yocto for portions I need (davinci
> support for sure on DM3730)

DM3730 is not davinci, it's "OMAP". So it's linux-omap kernel tree and not 
linux-davinci. If you are talking about DSP side, that's different, while uses 
some of the same components, like dsplink/syslink, xdc etc. I have on my TODO 
list to extract those from base BSP support into something called "extras", so 
it won't impede people trying to start with the base BSP...


> - or stick with meta-ti as it is and develop my own recipes for custom hw
> as meta-ti bsp.

Either way is fine at this point. Please note, that I only tested meta-ti 
against oe-core as of now, my testing of it against meta-yocto is not 
finished. And, here's the confusion that Koen implied and Richard didn't like:

Yocto = oe-core
Poky = meta-yocto

Our goal is to support using meta-ti with any OE distro - meta-angstrom, 
meta-arago and meta-yocto/poky, as well as in a distro-less environment, i.e. 
with oe-core only.

-- 
Denys

Re: question on meta-ti for yocto

[Philip Balister]

On 03/21/2012 03:27 PM, Richard Purdie wrote:
> 
> The biggest confusion factor out there at the moment is meta-ti, not
> poky and I'd like to ask politely for people to get their act together.

Richard,

meta-ti is the focus of the confusion at the moment because it is trying
to support several different use cases.

The confusion about poky, yocto, oe is widespread. At an SDR related
conference earlier this month, I was asked by some of the grad student
types what all these words mean. And I gave about the same answer as
Koen, but worded a little more diplomatically,

Even people that should know better are making statements that add to
the confusion. I am 99% certain Saul used the phrase "Poky build system"
at the Yocto developer day. We laughed about it afterwards, but this
shows how deep the confusion is.

I know you are trying to help solve the confusion problem. But I feel
Koen should not take all the heat for expressing his frustration. We, as
in the Yocto Advisory Board should do a better job communicating how all
the pieces fit together,

Philip

Re: question on meta-ti for yocto

[Koen Kooi]

Op 21 mrt. 2012, om 23:10 heeft Richard Purdie het volgende geschreven:

> On Wed, 2012-03-21 at 17:45 -0400, Denys Dmytriyenko wrote:
>> That's not true. There are no hard dependencies on meta-angstrom any more. And 
>> meta-oe is only needed to supply gcc-4.5 for now, until all the issues are 
>> ironed out.
>> 
>> I've been making numerous builds past few weeks with different combination of 
>> layers and besides few bugs I need to fix for the distro-less configuration, 
>> was quite successful getting meta-ti work with oe-core WITHOUT meta-angstrom!
>> 
>> There are some systemd dependencies, but they are no longer hard ones. There 
>> was discussion about moving beagle payload stuff off of meta-ti. But it should 
>> no longer break things.
> 
> I've been going by the information I see and the contents of the meta-ti
> README. Reading the above it looks like much progress is being made,
> things are changing and I really do appreciate that happening!
> 
>>> The amount of confusion this is causing users is immense as we see from
>>> new users and experienced ones alike. Whilst I know people have nodded
>>> and agreed they're going to fix it, time goes on and we don't seem to
>>> make much progress.
>>> 
>>> The biggest confusion factor out there at the moment is meta-ti, not
>>> poky and I'd like to ask politely for people to get their act together.
>> 
>> See above, the work is being done. The first wave of people who complained 
>> about those dependencies are now building their images. There are still 
>> confused people, but we'll clear the message once all obstacles are resolved.
> 
> Great, thanks!
> 
>> Richard, Koen, please take your word-fight and name-calling offline! It's not 
>> a proper place here. Thank you.
> 
> Well said and I agree with you! :)
> 
> The trouble is Koen keeps doing this and nobody in general replies. The
> lack of a reply can be seen as to condone what was said and its
> certainly leading to people getting more confused. I think a response
> was appropriate.
> 
> I also do not mean to undermine the progress being made on meta-ti. I
> hadn't heard much for a while but it looks like things are moving
> forward and that is great to see.

And for the record, I have been the *only* one so far sending patches to break that dependency and I don't even work for TI anymore!

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=0d4418518a05b8f47697aa69a18a832d90eb8d87
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=17600a532e574ec9e09a18a9cb6197b73331c3df
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=e31722adc42ef202ae273571ce19a7ac304e5eb6

regards,

Koen

Re: question on meta-ti for yocto

[Marco Monguzzi]

[-- Attachment #1: Type: text/plain, Size: 170 bytes --]

Good morning. I would like to thank everyone for the help in understanding
the terminology
and how meta-ti relates to various oe-core based distro.

Regards,
Marco

[-- Attachment #2: Type: text/html, Size: 218 bytes --]

Re: question on meta-ti for yocto

[Denys Dmytriyenko]

On Thu, Mar 22, 2012 at 07:31:00AM +0100, Koen Kooi wrote:
> 
> Op 21 mrt. 2012, om 23:10 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2012-03-21 at 17:45 -0400, Denys Dmytriyenko wrote:
> >> That's not true. There are no hard dependencies on meta-angstrom any more. And 
> >> meta-oe is only needed to supply gcc-4.5 for now, until all the issues are 
> >> ironed out.
> >> 
> >> I've been making numerous builds past few weeks with different combination of 
> >> layers and besides few bugs I need to fix for the distro-less configuration, 
> >> was quite successful getting meta-ti work with oe-core WITHOUT meta-angstrom!
> >> 
> >> There are some systemd dependencies, but they are no longer hard ones. There 
> >> was discussion about moving beagle payload stuff off of meta-ti. But it should 
> >> no longer break things.
> > 
> > I've been going by the information I see and the contents of the meta-ti
> > README. Reading the above it looks like much progress is being made,
> > things are changing and I really do appreciate that happening!
> > 
> >>> The amount of confusion this is causing users is immense as we see from
> >>> new users and experienced ones alike. Whilst I know people have nodded
> >>> and agreed they're going to fix it, time goes on and we don't seem to
> >>> make much progress.
> >>> 
> >>> The biggest confusion factor out there at the moment is meta-ti, not
> >>> poky and I'd like to ask politely for people to get their act together.
> >> 
> >> See above, the work is being done. The first wave of people who complained 
> >> about those dependencies are now building their images. There are still 
> >> confused people, but we'll clear the message once all obstacles are resolved.
> > 
> > Great, thanks!
> > 
> >> Richard, Koen, please take your word-fight and name-calling offline! It's not 
> >> a proper place here. Thank you.
> > 
> > Well said and I agree with you! :)
> > 
> > The trouble is Koen keeps doing this and nobody in general replies. The
> > lack of a reply can be seen as to condone what was said and its
> > certainly leading to people getting more confused. I think a response
> > was appropriate.
> > 
> > I also do not mean to undermine the progress being made on meta-ti. I
> > hadn't heard much for a while but it looks like things are moving
> > forward and that is great to see.
> 
> And for the record, I have been the *only* one so far sending patches to 
> break that dependency and I don't even work for TI anymore!

While your patches are always appreciated, it's still quite selfish of you to 
say that, cause a) you don't do the "Political Correctness" dance; b) you were 
the one to put those dependencies in the first place and c) if I start ripping 
out them inconsiderably, you'll be the first to scream bloody murder! :) :)

Besides, the few patches I sent out to OE-Core were related to these efforts 
and to enable meta-ti to work with other distros reliably - pushing your 
SOC_FAMILY upstream, enabling DISTRO-less OVERRIDES and even fixing 
virtual/libc in rt-tests was needed for our own upcoming meta-arago distro 
with external toolchain. I do have few more fixes pending in my local queue, 
that I'll be pushing to meta-ti and sending out to other layers...

-- 
Denys

Re: question on meta-ti for yocto

[William Mills]

>> Op 21 mrt. 2012, om 23:10 heeft Richard Purdie het volgende geschreven:
>>> The trouble is Koen keeps doing this and nobody in general replies. The
>>> lack of a reply can be seen as to condone what was said and its
>>> certainly leading to people getting more confused. I think a response
>>> was appropriate.

For the record I will try to speak for the official TI position on this.
-------------------

1) Koen speaks for himself.  He does not speak for TI.  He is not a TI 
employee any longer but he remains a valuable contributor to 
beagleboard, angstrom, oe-core, meta-oe, and meta-ti among many others. 
  I think we all benefit from his [ code :) ] contributions.

2) When people ask about building for "yocto" we (TI) assume they mean 
building using the poky component of yocto.

3) Angstrom is a valuable member of the openembedded eco system and 
enables much progress in oe-core and other areas.  Angstrom is based on 
oe-core, as is poky.  Angstrom is not an official yocto project. 
Therefore TI believes that when people are building based on Angstrom, 
they are NOT building "yocto".

4) Denys, Koen, and others are working to ensure that meta-ti can be 
used with just oe-core or just poky.

5) meta-ti will be able to be used in an Angstrom configuration but 
(now) does not, and will not, require it.

6) Although we plan to support base oe-core and poky configurations, 
they will *not* be recommended configurations for several reasons:
6.1) oe-core and poky ignore ~ 12 month of toolchain improvements made 
by Linaro.
6.2) At this time, all of the internal and customer validation of TI 
BSPs has been done with a gcc 4.5 based toolchain that includes the 
linaro patches.

As stated in #6, TI will continue to recommend meta-oe in the layer 
stack to get the toolchain that TI tests with.  We hope, as work with 
linaro continues to switch that to an official meta-linaro layer.

TI will continue to test with and recommend a toolchain that is closely 
aligned with Linaro.  We see no reason customers should have to misalign 
themselves with the ARM ecosystem just to align with poky.

---------------------------------
[speaking for myself now]

I fully support base poky testing but I think we are getting dangerously 
close to a defacto statement that the only real yocto based distro is 
one that _only_ uses poky + a BSP layer.  I am not aligned with that 
view.  I think oe-core and poky are a fine base but many customers will 
need to expand on what is there with more layers.

Richard,

You seem to take offense at Koen's claim that Angstrom is Yocto.  As I 
stated above I don't think Angstrom _is_ yocto but how do we refer to 
distributions that are based off of oe-core or even poky that include 
other layers.  Are they "Yocto based" or "Yocto aligned"?  How about 
"Yocto adjacent" :) ?

Koen,

The next time someone asks how to build "yocto" can you let Denys answer 
please :)

Thanks,
Bill

Re: question on meta-ti for yocto

[Koen Kooi]

Op 22 mrt. 2012, om 17:48 heeft William Mills het volgende geschreven:
> ---------------------------------
> [speaking for myself now]
> 
> I fully support base poky testing but I think we are getting dangerously close to a defacto statement that the only real yocto based distro is one that _only_ uses poky + a BSP layer.  I am not aligned with that view.  I think oe-core and poky are a fine base but many customers will need to expand on what is there with more layers.

I have sent multiple emails to the oe-core/poky/yocto lists and bothered people in person about this, but the result is no answer at all (emails) or "Yes, we need to address the confusion" in person, but no action at all. I've found that the most successful way to get a clarifying statement is to be a giant troll and send flames like I did this week and in the past.

Specific example of getting no answer: https://lists.yoctoproject.org/pipermail/yocto/2012-March/007309.html

> Richard,
> 
> You seem to take offense at Koen's claim that Angstrom is Yocto.  As I stated above I don't think Angstrom _is_ yocto but how do we refer to distributions that are based off of oe-core or even poky that include other layers.  Are they "Yocto based" or "Yocto aligned"?  How about "Yocto adjacent" :) ?

Yoctogenerian? And related to the email linked to above, what's the route to move a yoctogenerian distro under the yocto banner?

> Koen,
> 
> The next time someone asks how to build "yocto" can you let Denys answer please :)

Sure, will do.

regards,

Koen

Re: question on meta-ti for yocto

[Richard Purdie]

On Thu, 2012-03-22 at 12:48 -0400, William Mills wrote:
> >> Op 21 mrt. 2012, om 23:10 heeft Richard Purdie het volgende geschreven:
> >>> The trouble is Koen keeps doing this and nobody in general replies. The
> >>> lack of a reply can be seen as to condone what was said and its
> >>> certainly leading to people getting more confused. I think a response
> >>> was appropriate.
> 
> For the record I will try to speak for the official TI position on this.

Thanks!

> 6) Although we plan to support base oe-core and poky configurations, 
> they will *not* be recommended configurations for several reasons:
> 6.1) oe-core and poky ignore ~ 12 month of toolchain improvements made 
> by Linaro.
> 6.2) At this time, all of the internal and customer validation of TI 
> BSPs has been done with a gcc 4.5 based toolchain that includes the 
> linaro patches.
>
> As stated in #6, TI will continue to recommend meta-oe in the layer 
> stack to get the toolchain that TI tests with.  We hope, as work with 
> linaro continues to switch that to an official meta-linaro layer.

I think there could be better integration with Linaro and I know work is
being done in this area so I'm hoping this situation will improve.

I know Bill understands this but just to be clear for the record, the
only scalable way OE-Core can work is to embrace upstream latest
releases as much as is practicable which is why 4.6 is currently used.
If people need something different *and* step up with resources to
maintain/test it, we can talk about other versions but for anything like
an extra toolchain, we need people to help support it.

Just to illistrate this, making a release of OE-Core/Poky currently
involves testing on 5 'architectures' on virtual and real hardware with
about 8 different images to test along with features like sstate,
sdk/toolchain, no-gplv3, multilib and tiny. This gives a staggering test
matrix.

> TI will continue to test with and recommend a toolchain that is closely 
> aligned with Linaro.  We see no reason customers should have to misalign 
> themselves with the ARM ecosystem just to align with poky.

s/poky/upstream/

and with 4.7 (out today), we should have a lot of the Linaro fixes,
right so this problem should start solving itself when we update to
4.7? :)

The layer model should make this less of an issue if we can have a
strong layer containing that toolchain. I know progress is being made in
splitting this from meta-oe so that should simplify the problem.

> ---------------------------------
> [speaking for myself now]
> 
> I fully support base poky testing but I think we are getting dangerously 
> close to a defacto statement that the only real yocto based distro is 
> one that _only_ uses poky + a BSP layer.  I am not aligned with that 
> view.

FWIW I'm not aligned with that view either!

>   I think oe-core and poky are a fine base but many customers will 
> need to expand on what is there with more layers.

I think its fine to say poky is the way Yocto tests and validates
OE-Core and is something it can release as a tested know to work base
people can build off. As such, pointing people to poky as a way of
testing and getting started is reasonable.

I also think its fine to say that poky + a BSP layer should work without
anything else.

Its perfectly reasonable for people to add in other layers on top of
that.

> Richard,
> 
> You seem to take offense at Koen's claim that Angstrom is Yocto.  As I 
> stated above I don't think Angstrom _is_ yocto but how do we refer to 
> distributions that are based off of oe-core or even poky that include 
> other layers.

I'm not sure I took offence, I was just trying to clearly position
things. Poky isn't Yocto either in the strict sense, its a component of
it. 

>   Are they "Yocto based" or "Yocto aligned"?  How about 
> "Yocto adjacent" :) ?

That is a good question and I don't have the answer. I think I like
"Yocto aligned" as it implies its sharing the objectives of Yocto,
particularly around layers, OE-COre and BSPs which I believe Angstrom
is.

I'd suggest on this detail, it gets raised with the Yocto AB and
Advocacy people and we should document what "Yocto alignment" means
somewhere.

Cheers,

Richard

Re: question on meta-ti for yocto

[William Mills]

On 03/22/2012 01:34 PM, Richard Purdie wrote:
> On Thu, 2012-03-22 at 12:48 -0400, William Mills wrote:
>>>> Op 21 mrt. 2012, om 23:10 heeft Richard Purdie het volgende geschreven:
>>>>> The trouble is Koen keeps doing this and nobody in general replies. The
>>>>> lack of a reply can be seen as to condone what was said and its
>>>>> certainly leading to people getting more confused. I think a response
>>>>> was appropriate.
>>
>> For the record I will try to speak for the official TI position on this.
>
> Thanks!
>
>> 6) Although we plan to support base oe-core and poky configurations,
>> they will *not* be recommended configurations for several reasons:
>> 6.1) oe-core and poky ignore ~ 12 month of toolchain improvements made
>> by Linaro.
>> 6.2) At this time, all of the internal and customer validation of TI
>> BSPs has been done with a gcc 4.5 based toolchain that includes the
>> linaro patches.
>>
>> As stated in #6, TI will continue to recommend meta-oe in the layer
>> stack to get the toolchain that TI tests with.  We hope, as work with
>> linaro continues to switch that to an official meta-linaro layer.
>
> I think there could be better integration with Linaro and I know work is
> being done in this area so I'm hoping this situation will improve.

Yes, we are encouraging this as well.

>
> I know Bill understands this but just to be clear for the record, the
> only scalable way OE-Core can work is to embrace upstream latest
> releases as much as is practicable which is why 4.6 is currently used.
> If people need something different *and* step up with resources to
> maintain/test it, we can talk about other versions but for anything like
> an extra toolchain, we need people to help support it.
>
> Just to illistrate this, making a release of OE-Core/Poky currently
> involves testing on 5 'architectures' on virtual and real hardware with
> about 8 different images to test along with features like sstate,
> sdk/toolchain, no-gplv3, multilib and tiny. This gives a staggering test
> matrix.

Well, the test matrix would not get *any* bigger if a Linaro aligned 
tool chain were used for *all* ARM architecture builds.  Yes, there is 
work to maintain a separate toolchain recipe but we covered that above. 
  Sure we could not support a different toolchain per BSP or Si vendor 
but I think if all ARM providers were aligned on one toolchain it would 
make sense to support it.  In fact there is an organization to get 
alignment of different ARM vendors: Linaro.  We even have participation 
of ARM vendors that are not officially part of Linaro.

>
>> TI will continue to test with and recommend a toolchain that is closely
>> aligned with Linaro.  We see no reason customers should have to misalign
>> themselves with the ARM ecosystem just to align with poky.
>
> s/poky/upstream/

The point is to align with the most number of test hours and test cases 
run.  I still maintain that on ARM hardware the Linaro toolchain has 
more test hours than a plain vanilla upstream toolchain.

>
> and with 4.7 (out today), we should have a lot of the Linaro fixes,
> right so this problem should start solving itself when we update to
> 4.7? :)

Yes at this instant in time and the divergence also starts today 
(actually a while back due to code freeze etc.)  That is why poky and 
any plain upstream toolchain will be an average of 6 to 12 months behind 
the current Linaro "best".

> The layer model should make this less of an issue if we can have a
> strong layer containing that toolchain. I know progress is being made in
> splitting this from meta-oe so that should simplify the problem.
>

Agreed.

>> ---------------------------------
>> [speaking for myself now]
>>
>> I fully support base poky testing but I think we are getting dangerously
>> close to a defacto statement that the only real yocto based distro is
>> one that _only_ uses poky + a BSP layer.  I am not aligned with that
>> view.
>
> FWIW I'm not aligned with that view either!
>
>>    I think oe-core and poky are a fine base but many customers will
>> need to expand on what is there with more layers.
>
> I think its fine to say poky is the way Yocto tests and validates
> OE-Core and is something it can release as a tested know to work base
> people can build off. As such, pointing people to poky as a way of
> testing and getting started is reasonable.
>
> I also think its fine to say that poky + a BSP layer should work without
> anything else.

We all agree and we are are getting close.

There is still a difference between a baseline and a recommendation.

Maintaining this status may be challenging.  I am going to have 0 buy-in 
from the developers to add workarounds into the kernel for bugs in GCC 
that are already fixed in the Linaro toolchain.

>
> Its perfectly reasonable for people to add in other layers on top of
> that.
>
>> Richard,
>>
>> You seem to take offense at Koen's claim that Angstrom is Yocto.  As I
>> stated above I don't think Angstrom _is_ yocto but how do we refer to
>> distributions that are based off of oe-core or even poky that include
>> other layers.
>
> I'm not sure I took offence, I was just trying to clearly position
> things. Poky isn't Yocto either in the strict sense, its a component of
> it.
>
>>    Are they "Yocto based" or "Yocto aligned"?  How about
>> "Yocto adjacent" :) ?
>
> That is a good question and I don't have the answer. I think I like
> "Yocto aligned" as it implies its sharing the objectives of Yocto,
> particularly around layers, OE-COre and BSPs which I believe Angstrom
> is.
>
> I'd suggest on this detail, it gets raised with the Yocto AB and
> Advocacy people and we should document what "Yocto alignment" means
> somewhere.

Agreed.  I also like "Yocto aligned" and it is how I have been 
describing the new Arago. (No its not ready yet.)

Agreed.  We should discuss it in AB & Advocacy.

Bill

Re: question on meta-ti for yocto

[Richard Purdie]

On Thu, 2012-03-22 at 14:28 -0400, William Mills wrote:
> On 03/22/2012 01:34 PM, Richard Purdie wrote:
> > I know Bill understands this but just to be clear for the record, the
> > only scalable way OE-Core can work is to embrace upstream latest
> > releases as much as is practicable which is why 4.6 is currently used.
> > If people need something different *and* step up with resources to
> > maintain/test it, we can talk about other versions but for anything like
> > an extra toolchain, we need people to help support it.
> >
> > Just to illistrate this, making a release of OE-Core/Poky currently
> > involves testing on 5 'architectures' on virtual and real hardware with
> > about 8 different images to test along with features like sstate,
> > sdk/toolchain, no-gplv3, multilib and tiny. This gives a staggering test
> > matrix.
> 
> Well, the test matrix would not get *any* bigger if a Linaro aligned 
> tool chain were used for *all* ARM architecture builds.  Yes, there is 
> work to maintain a separate toolchain recipe but we covered that above. 
>   Sure we could not support a different toolchain per BSP or Si vendor 
> but I think if all ARM providers were aligned on one toolchain it would 
> make sense to support it.  In fact there is an organization to get 
> alignment of different ARM vendors: Linaro.  We even have participation 
> of ARM vendors that are not officially part of Linaro.

I can see where you're coming from but I'd really prefer to have one
toolchain version and patchset for OE-Core. 

I'm sure if ARM changes, we'd then get requests for other patchsets for
other platforms. It also penalises ARM vendors (or whoever) who did the
right thing and got their code into the recent gcc.

> >> TI will continue to test with and recommend a toolchain that is closely
> >> aligned with Linaro.  We see no reason customers should have to misalign
> >> themselves with the ARM ecosystem just to align with poky.
> >
> > s/poky/upstream/
> 
> The point is to align with the most number of test hours and test cases 
> run.  I still maintain that on ARM hardware the Linaro toolchain has 
> more test hours than a plain vanilla upstream toolchain.

How about using the CodeSorcery monster toolchain patches for example? I
suspect they get more test hours too.

My point is I doubt we can find a solution that everyone will be happy
with and an upstream baseline with appropriate patches seems to be the
best middle ground we can find.

> > and with 4.7 (out today), we should have a lot of the Linaro fixes,
> > right so this problem should start solving itself when we update to
> > 4.7? :)
> 
> Yes at this instant in time and the divergence also starts today 
> (actually a while back due to code freeze etc.)  That is why poky and 
> any plain upstream toolchain will be an average of 6 to 12 months behind 
> the current Linaro "best".

s/poky/oe-core/

I'd hope that over time, ARM can get its support for new features into
gcc in a sensible time frame so that the current gcc works well with
production silicon and isn't 6-12 months behind. I'd like to think the
current situation will therefore correct itself and not be a permanent
state.

> >>    I think oe-core and poky are a fine base but many customers will
> >> need to expand on what is there with more layers.
> >
> > I think its fine to say poky is the way Yocto tests and validates
> > OE-Core and is something it can release as a tested know to work base
> > people can build off. As such, pointing people to poky as a way of
> > testing and getting started is reasonable.
> >
> > I also think its fine to say that poky + a BSP layer should work without
> > anything else.
> 
> We all agree and we are are getting close.
> 
> There is still a difference between a baseline and a recommendation.
> 
> Maintaining this status may be challenging.  I am going to have 0 buy-in 
> from the developers to add workarounds into the kernel for bugs in GCC 
> that are already fixed in the Linaro toolchain.

In those cases I'd be happy to see gcc patches applied to the OE-Core
toolchain to address the issues. We already have a pretty good track
record of dealing with this as far as I know.

Cheers,

Richard

Re: question on meta-ti for yocto

[Richard Purdie]

On Thu, 2012-03-22 at 18:23 +0100, Koen Kooi wrote:
> Op 22 mrt. 2012, om 17:48 heeft William Mills het volgende geschreven:
> > ---------------------------------
> > [speaking for myself now]
> > 
> > I fully support base poky testing but I think we are getting
> dangerously close to a defacto statement that the only real yocto
> based distro is one that _only_ uses poky + a BSP layer.  I am not
> aligned with that view.  I think oe-core and poky are a fine base but
> many customers will need to expand on what is there with more layers.
> 
> I have sent multiple emails to the oe-core/poky/yocto lists and
> bothered people in person about this, but the result is no answer at
> all (emails) or "Yes, we need to address the confusion" in person, but
> no action at all. I've found that the most successful way to get a
> clarifying statement is to be a giant troll and send flames like I did
> this week and in the past.
>
> Specific example of getting no answer:
> https://lists.yoctoproject.org/pipermail/yocto/2012-March/007309.html

Your approach can also counterproductive as if it looks like blatant
trolling, I try not to reply to it and I suspect others might do the
same. You run the risk of alienating and confusing people rather than
educating them and improving things.

Whilst it might not look like much happens, I have talked with various
people, I've also stressed the new website for Yocto needs to do a
better job on the positioning and when I review the site content I'll be
looking out for that. The people doing it are aware of the issues.

I'd really love to have a magic switch I could flick where everyone
suddenly understand things. I'm personally doing what I can and will
continue to do so.

You can see in this thread I've been trying to explain the positioning
and terms and at least one thing looks like it should go to the AB and
Advocacy people to try and move things forward. What else would you like
to see happen?

> Yoctogenerian? And related to the email linked to above, what's the
> route to move a yoctogenerian distro under the yocto banner?

A good start would be a discussion on the general yocto list. I'm not
sure we have a procedure but if we discuss it, I can raise this at the
Yocto AB meeting in a couple of weeks and hopefully make some kind of a
decision and move forward.

/me hopes Jefro is taking notes of the above! ;-)

Cheers,

Richard

Re: question on meta-ti for yocto

[Denys Dmytriyenko]

On Thu, Mar 22, 2012 at 07:14:01PM +0000, Richard Purdie wrote:
> On Thu, 2012-03-22 at 14:28 -0400, William Mills wrote:
> > On 03/22/2012 01:34 PM, Richard Purdie wrote:
> > > I know Bill understands this but just to be clear for the record, the
> > > only scalable way OE-Core can work is to embrace upstream latest
> > > releases as much as is practicable which is why 4.6 is currently used.
> > > If people need something different *and* step up with resources to
> > > maintain/test it, we can talk about other versions but for anything like
> > > an extra toolchain, we need people to help support it.
> 
> > >> TI will continue to test with and recommend a toolchain that is closely
> > >> aligned with Linaro.  We see no reason customers should have to misalign
> > >> themselves with the ARM ecosystem just to align with poky.
> > 
> > The point is to align with the most number of test hours and test cases 
> > run.  I still maintain that on ARM hardware the Linaro toolchain has 
> > more test hours than a plain vanilla upstream toolchain.
> 
> > > and with 4.7 (out today), we should have a lot of the Linaro fixes,
> > > right so this problem should start solving itself when we update to
> > > 4.7? :)
> > 
> > Yes at this instant in time and the divergence also starts today 
> > (actually a while back due to code freeze etc.)  That is why poky and 
> > any plain upstream toolchain will be an average of 6 to 12 months behind 
> > the current Linaro "best".
> 
> I'd hope that over time, ARM can get its support for new features into
> gcc in a sensible time frame so that the current gcc works well with
> production silicon and isn't 6-12 months behind. I'd like to think the
> current situation will therefore correct itself and not be a permanent
> state.
> 
> In those cases I'd be happy to see gcc patches applied to the OE-Core
> toolchain to address the issues. We already have a pretty good track
> record of dealing with this as far as I know.

Well, in this discussion we keep forgetting that a toolchain is not just gcc, 
it also contains binutils (for things like linker and assembler) as well as 
libc (but this one tends to give some other non-technical issues... :) and I 
know - I spent last 9 months rebuilding, repackaging and otherwise supporting 
our internal build of gcc+linaro based toolchain)

For example, here's what happens when one of our 3.2-based kernels is being 
built with the latest binutils-2.22 from OE-Core:

==================================================
ERROR: Function failed: do_compile (see /OE/yocto/build/arago-tmp-eglibc/work/beaglebone-oe-linux-gnueabi/linux-ti33x-psp-3.2-r0/temp/log.do_compile.430 for further information)
ERROR: Logfile of failure stored in: /OE/yocto/build/arago-tmp-eglibc/work/beaglebone-oe-linux-gnueabi/linux-ti33x-psp-3.2-r0/temp/log.do_compile.430
Log data follows:
| ERROR: Function failed: do_compile (see /OE/yocto/build/arago-tmp-eglibc/work/beaglebone-oe-linux-gnueabi/linux-ti33x-psp-3.2-r0/temp/log.do_compile.430 for further information)
| NOTE: make -j 16 -j 16 include/linux/version.h CC=arm-oe-linux-gnueabi-gcc  -mno-thumb-interwork -marm --sysroot=/OE/yocto/build/arago-tmp-eglibc/sysroots/beaglebone LD=arm-oe-linux-gnueabi-ld  --sysroot=/OE/yocto/build/arago-tmp-eglibc/sysroots/beaglebone
|   CHK     include/linux/version.h
| NOTE: make -j 16 -j 16 uImage CC=arm-oe-linux-gnueabi-gcc  -mno-thumb-interwork -marm --sysroot=/OE/yocto/build/arago-tmp-eglibc/sysroots/beaglebone LD=arm-oe-linux-gnueabi-ld  --sysroot=/OE/yocto/build/arago-tmp-eglibc/sysroots/beaglebone
|   CHK     include/linux/version.h
|   CHK     include/generated/utsrelease.h
| make[1]: `include/generated/mach-types.h' is up to date.
|   CALL    scripts/checksyscalls.sh
|   CHK     include/generated/compile.h
|   CHK     kernel/config_data.h
|   Kernel: arch/arm/boot/Image is ready
|   AS      arch/arm/boot/compressed/head.o
|   AS      arch/arm/boot/compressed/piggy.lzo.o
|   AS      arch/arm/boot/compressed/lib1funcs.o
| arch/arm/boot/compressed/head.S: Assembler messages:
| arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr'
| arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr'
| arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2'
| make[2]: *** [arch/arm/boot/compressed/head.o] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
| make: *** [uImage] Error 2
| ERROR: oe_runmake failed
NOTE: package linux-ti33x-psp-3.2-r0: task do_compile: Failed
ERROR: Task 407 (/OE/yocto/sources/meta-ti/recipes-kernel/linux/linux-ti33x-psp_3.2.bb, do_compile) failed with exit code '1'
==================================================

Works fine when rolled back to binutils-2.20.1 from meta-oe. Something else in 
our components is picky about the version of binutils...


As Bill mentioned earlier, we closely watch Linaro's progress on creating the 
official meta-linaro layer with their latest toolchain for ARM architecture, 
which can be used with OE-Core/Yocto setups.

But they only started this work last month, they only seem to test against 
qemuarm targets, while at the same time being very "aggressive" - i.e. they 
only support ARMv7+ architecture (Cortex-A8/A9/A15), plus with the release of 
gcc-4.7 they plan to switch to that right away, moving 4.6 into maintenance 
mode and dropping support for 4.5...

So, all in all, all current work will end up being supported upstream, as 
that's everyone's goal, but when it gets there, there will always be the next 
big thing that everyone's working on, but it's not yet available upstream...

-- 
Denys