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