Re: question on meta-ti for yocto

[William Mills <wmills@ti.com>]

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