yocto beagleboard.conf -- should it not go away?

yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

Hi,

I am wondering why yocto includes a beagleboard.conf when it is unable
to support much of the board's features, and there is a dedicated layer
for TI stuff that defines the beagleboard machine properly.

I actually have a fairly practical gripe here: it is currently not
possible to include both meta-yocto and meta-ti, and have it use the
correct beagleboard.conf from meta-ti! The meta-yocto layer prepends
itself to the BBPATH while meta-ti appends itself, so regarless the
layer arrangement, the (not-much-useful) yocto beagleboard.conf is
always used, and everything is broken. The only way to work around this
that I can think of is to provide yet another beagleboard.conf from a
custom layer that also preppends itself to the BBPATH, which feels like
three sides of a square route.

So, is there a good reason not to get rid of yocto beagleboard.conf?

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Bruce Ashfield]

On Mon, Sep 3, 2012 at 4:06 PM, Tomas Frydrych
<tf+lists.yocto@r-finger.com> wrote:
>
> Hi,
>
> I am wondering why yocto includes a beagleboard.conf when it is unable
> to support much of the board's features, and there is a dedicated layer
> for TI stuff that defines the beagleboard machine properly.
>
> I actually have a fairly practical gripe here: it is currently not
> possible to include both meta-yocto and meta-ti, and have it use the
> correct beagleboard.conf from meta-ti! The meta-yocto layer prepends
> itself to the BBPATH while meta-ti appends itself, so regarless the
> layer arrangement, the (not-much-useful) yocto beagleboard.conf is
> always used, and everything is broken. The only way to work around this
> that I can think of is to provide yet another beagleboard.conf from a
> custom layer that also preppends itself to the BBPATH, which feels like
> three sides of a square route.

So we fix the configuration of the layers .. and meta-ti was supposed to
work properly with meta-yocto last I heard.

>
> So, is there a good reason not to get rid of yocto beagleboard.conf?

The meta-yocto layer beagleboard configuration is a hardware ARM reference, that
uses the linux-yocto kernel (policy and version) and is used for the
project QA on
hardware.

The meta-ti layer, which no one argues has more hardware functionality and
support, doesn't hit those other three elements.

The beagleboard in meta-yocto will be bumped shortly to match the 3.4 configs
and policy of the rest of the reference boards.

If I make the statement that we need a ARM hardware reference, that uses only
meta-yocto (linux-yocto + config + tools), the choices are limited.
Any board that
I select, is followed by an series of comments about how other layers,
other places,
other <something> has that board. So there's no right choice, including dropping
it completely, since the requirements that I've listed above are
equally not met by
any other layer configurations.

Cheers,

Bruce

>
> Tomas
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

Hi,

On 03/09/12 21:15, Bruce Ashfield wrote:
> On Mon, Sep 3, 2012 at 4:06 PM, Tomas Frydrych
> So we fix the configuration of the layers .. 

I expect this is not actually that trivial. I think the only way to do
this is properly is for the layer priorities to be respected by all
files in the layer, not just the bb files. No idea how involved that
change would be, or what the side effects would be.


> and meta-ti was supposed to work properly with meta-yocto last I heard.

If properly means 'out of the box', then no; the two layers can be made
to work together, but it's fairly clear that nobody comprehensively
tests that combination at the moment.


> The meta-yocto layer beagleboard configuration is a hardware ARM reference, that
> uses the linux-yocto kernel (policy and version) and is used for the
> project QA on hardware.

I am all for QA, but in this instance your QA procedure breaks things
for the end user. Could you not just call it something else, e.g.,
yocto-qa-arm-reference.conf?

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Bruce Ashfield]

On Mon, Sep 3, 2012 at 4:55 PM, Tomas Frydrych
<tf+lists.yocto@r-finger.com> wrote:
> Hi,
>
> On 03/09/12 21:15, Bruce Ashfield wrote:
>> On Mon, Sep 3, 2012 at 4:06 PM, Tomas Frydrych
>> So we fix the configuration of the layers ..
>
> I expect this is not actually that trivial. I think the only way to do
> this is properly is for the layer priorities to be respected by all
> files in the layer, not just the bb files. No idea how involved that
> change would be, or what the side effects would be.

This is a very common layering scenario, so if the system as a whole can't
handle it, that's a bigger problem. If two layers can't have a board with the
same name, and there's no way for them to work together without tweaking
multiple files in the layer, I'd say that's a problem and one that should
be fixed. Otherwise, a OSV (or someone else) can never hope to extend
anything from a yocto layer.

That being said, taking a step back, what are you trying to get out of
meta-yocto in this scenario ? oe-core + meta-ti is probably what you
should be using.

>
>
>> and meta-ti was supposed to work properly with meta-yocto last I heard.
>
> If properly means 'out of the box', then no; the two layers can be made
> to work together, but it's fairly clear that nobody comprehensively
> tests that combination at the moment.

see above. I misspoke. I don't think there's an intent to make meta-yocto
and meta-ti work together, but oe-core + meta-ti, that's the combo that
makes sense.

>
>
>> The meta-yocto layer beagleboard configuration is a hardware ARM reference, that
>> uses the linux-yocto kernel (policy and version) and is used for the
>> project QA on hardware.
>
> I am all for QA, but in this instance your QA procedure breaks things
> for the end user. Could you not just call it something else, e.g.,
> yocto-qa-arm-reference.conf?

Hmmm. I'd say no to that, because the system should handle something like this,
and dancing around the real problem with varying names of BSPs outside of the
name of the board they actually support, isn't a solution.

Cheers,

Bruce

>
> Tomas
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: yocto beagleboard.conf -- should it not go away?

[Jack Mitchell]

On 03/09/12 22:08, Bruce Ashfield wrote:
> On Mon, Sep 3, 2012 at 4:55 PM, Tomas Frydrych
> <tf+lists.yocto@r-finger.com> wrote:
>> snip...
>>
>>
>>
>> That being said, taking a step back, what are you trying to get out of
>> meta-yocto in this scenario ? oe-core + meta-ti is probably what you
>> should be using.
>>

Sorry to jump in here, but this is actually a very interesting point. 
 From coming to OpenEmbedded through Yocto and subsequently learning 
about the ecosystem as a whole, I have always considered meta-yocto to 
be providing a sane distro configuration. This implies that I believe 
the oe-core default distro configuration, even though it will build, the 
result won't be very satisfying - or maybe a bit disjointed.

You seem to be saying above that the meta-yocto layer is only any good 
for providing the kernel framework, and as he is not using the framework 
(i.e. using meta-ti) then there is no point in using the meta-yocto 
layer? So does the Poky distro config only really slap a name on the 
oe-core default distro policy - or does it have some added value?

I'm not trying to rile anyone up here, just trying to put the jigsaw 
together as the picture looks different every time I revisit it!!

Regards,

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

Hi Bruce,

On 03/09/12 22:08, Bruce Ashfield wrote:
> That being said, taking a step back, what are you trying to get out of
> meta-yocto in this scenario ? 

a) I am targeting multiple chips, including TI Omap and Intel Atom.
meta-yocto is a prerequisite for the various machines in meta-intel, so
I have to include meta-yocto if I want to build images for an Intel
chip. Nothing unusual here.

b) meta-yocto is the Poky distro layer; if you want to use Poky, then
you need meta-yocto.

> see above. I misspoke. I don't think there's an intent to make meta-yocto
> and meta-ti work together, but oe-core + meta-ti, that's the combo that
> makes sense.

See (b) above; you are not saying that Poky is only meant for Intel HW,
are you?

The basic problem with meta-yocto is that it combines BSP stuff
(meta-intel prerequisite, Atom & Beagle config) with distro stuff (Poky,
Yocto branding). That's convenient for doing QA on a limited set of HW,
but suboptimal for real use; BSP layers simply should not be dependent
on distro layers, it largely defeats the purpose of having layers.

Splitting out the minimal beagle config into a layer of its own would
improve things quite a bit.

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Bruce Ashfield]

On Tue, Sep 4, 2012 at 4:58 AM, Tomas Frydrych
<tf+lists.yocto@r-finger.com> wrote:
> Hi Bruce,
>
> On 03/09/12 22:08, Bruce Ashfield wrote:
>> That being said, taking a step back, what are you trying to get out of
>> meta-yocto in this scenario ?
>
> a) I am targeting multiple chips, including TI Omap and Intel Atom.
> meta-yocto is a prerequisite for the various machines in meta-intel, so
> I have to include meta-yocto if I want to build images for an Intel
> chip. Nothing unusual here.
>
> b) meta-yocto is the Poky distro layer; if you want to use Poky, then
> you need meta-yocto.
>
>> see above. I misspoke. I don't think there's an intent to make meta-yocto
>> and meta-ti work together, but oe-core + meta-ti, that's the combo that
>> makes sense.
>
> See (b) above; you are not saying that Poky is only meant for Intel HW,
> are you?

Definitely not. But I'm not familiar with anyone's (outside of the
weekly meetings
that I attend) plans for meta-yocto, so I'm commenting on what I see. You'd need
someone from TI to comment on their meta-yocto compatibility. And that person
definitely is not me :)

>
> The basic problem with meta-yocto is that it combines BSP stuff
> (meta-intel prerequisite, Atom & Beagle config) with distro stuff (Poky,
> Yocto branding). That's convenient for doing QA on a limited set of HW,
> but suboptimal for real use; BSP layers simply should not be dependent
> on distro layers, it largely defeats the purpose of having layers.
>
> Splitting out the minimal beagle config into a layer of its own would
> improve things quite a bit.

All of the above are things that Richard would need to comment on, the yocto
layering and maintenance is not something that I have control over :)

Cheers,

Bruce

>
> Tomas
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: yocto beagleboard.conf -- should it not go away?

[Bruce Ashfield]

On Tue, Sep 4, 2012 at 4:21 AM, Jack Mitchell <ml@communistcode.co.uk> wrote:
> On 03/09/12 22:08, Bruce Ashfield wrote:
>>
>> On Mon, Sep 3, 2012 at 4:55 PM, Tomas Frydrych
>> <tf+lists.yocto@r-finger.com> wrote:
>>>
>>> snip...
>>>
>>>
>>>
>>>
>>> That being said, taking a step back, what are you trying to get out of
>>> meta-yocto in this scenario ? oe-core + meta-ti is probably what you
>>> should be using.
>>>
>
> Sorry to jump in here, but this is actually a very interesting point. From
> coming to OpenEmbedded through Yocto and subsequently learning about the
> ecosystem as a whole, I have always considered meta-yocto to be providing a
> sane distro configuration. This implies that I believe the oe-core default
> distro configuration, even though it will build, the result won't be very
> satisfying - or maybe a bit disjointed.

No worries. Take everything that I say as observations from a arms length
distance to how things are maintained and the plans about compatibility,
evolution, etc. So what I say, may not reflect reality :)

>
> You seem to be saying above that the meta-yocto layer is only any good for
> providing the kernel framework, and as he is not using the framework (i.e.
> using meta-ti) then there is no point in using the meta-yocto layer? So does
> the Poky distro config only really slap a name on the oe-core default distro
> policy - or does it have some added value?

There's value, and Richard has covered it a few times on the mailing list. I
probably wouldn't do it justice, so I'll wait to see if others with a better
articulated description jump in.

The linux-yocto kernel itself can work without any build system at all, so my
point of view is different :)

Cheers,

Bruce

>
> I'm not trying to rile anyone up here, just trying to put the jigsaw
> together as the picture looks different every time I revisit it!!
>
> Regards,
>
> --
>
>   Jack Mitchell (jack@embed.me.uk)
>   Embedded Systems Engineer
>   http://www.embed.me.uk
>
> --
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: yocto beagleboard.conf -- should it not go away?

[Darren Hart]

On 09/04/2012 05:20 AM, Bruce Ashfield wrote:
> On Tue, Sep 4, 2012 at 4:58 AM, Tomas Frydrych
> <tf+lists.yocto@r-finger.com> wrote:
>> Hi Bruce,
>>
>> On 03/09/12 22:08, Bruce Ashfield wrote:
>>> That being said, taking a step back, what are you trying to get out of
>>> meta-yocto in this scenario ?
>>
>> a) I am targeting multiple chips, including TI Omap and Intel Atom.
>> meta-yocto is a prerequisite for the various machines in meta-intel, so
>> I have to include meta-yocto if I want to build images for an Intel
>> chip. Nothing unusual here.
>>
>> b) meta-yocto is the Poky distro layer; if you want to use Poky, then
>> you need meta-yocto.
>>
>>> see above. I misspoke. I don't think there's an intent to make meta-yocto
>>> and meta-ti work together, but oe-core + meta-ti, that's the combo that
>>> makes sense.
>>
>> See (b) above; you are not saying that Poky is only meant for Intel HW,
>> are you?
> 
> Definitely not. But I'm not familiar with anyone's (outside of the
> weekly meetings
> that I attend) plans for meta-yocto, so I'm commenting on what I see. You'd need
> someone from TI to comment on their meta-yocto compatibility. And that person
> definitely is not me :)
> 
>>
>> The basic problem with meta-yocto is that it combines BSP stuff
>> (meta-intel prerequisite, Atom & Beagle config) with distro stuff (Poky,
>> Yocto branding). That's convenient for doing QA on a limited set of HW,
>> but suboptimal for real use; BSP layers simply should not be dependent
>> on distro layers, it largely defeats the purpose of having layers.
>>
>> Splitting out the minimal beagle config into a layer of its own would
>> improve things quite a bit.
> 
> All of the above are things that Richard would need to comment on, the yocto
> layering and maintenance is not something that I have control over :)
> 

As far as I understand it, meta-yocto and meta-ti should be able to work
together. If they don't, it's a bug in one or the other or both and we
should work to address it.

The machine namespace collision could be an example of something we need
to fix.

--
Darren

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: yocto beagleboard.conf -- should it not go away?

[William Mills]

On 09/04/2012 01:18 PM, Darren Hart wrote:
>
>
> On 09/04/2012 05:20 AM, Bruce Ashfield wrote:
>> On Tue, Sep 4, 2012 at 4:58 AM, Tomas Frydrych
>> <tf+lists.yocto@r-finger.com>  wrote:
>>> Hi Bruce,
>>>
>>> On 03/09/12 22:08, Bruce Ashfield wrote:
>>>> That being said, taking a step back, what are you trying to get out of
>>>> meta-yocto in this scenario ?
>>>
>>> a) I am targeting multiple chips, including TI Omap and Intel Atom.
>>> meta-yocto is a prerequisite for the various machines in meta-intel, so
>>> I have to include meta-yocto if I want to build images for an Intel
>>> chip. Nothing unusual here.
>>>
>>> b) meta-yocto is the Poky distro layer; if you want to use Poky, then
>>> you need meta-yocto.
>>>
>>>> see above. I misspoke. I don't think there's an intent to make meta-yocto
>>>> and meta-ti work together, but oe-core + meta-ti, that's the combo that
>>>> makes sense.

oe-core + meta-ti should work or it needs to get fixed.
poky + meta-ti should work or it needs to get fixed.

However I suspect the 2nd is not in the nightly builds yet.

Denys is out for the next few days.  He can comment more when he gets back.

It has been our assumption that there is enough functionality in the 
layer mechanisms that any of the "light weight" BSPs in yocto layer 
could be completely overridden by a more complete layer (meta-ti in this 
example).  In addition the end system integrator should be able to 
override definitions in any BSP layer.

I suspect the current issue is just growing pains for a case that has 
not been tested.  Lets prove that false before taking more drastic action.

>>>
>>> The basic problem with meta-yocto is that it combines BSP stuff
>>> (meta-intel prerequisite, Atom&  Beagle config) with distro stuff (Poky,
>>> Yocto branding). That's convenient for doing QA on a limited set of HW,
>>> but suboptimal for real use; BSP layers simply should not be dependent
>>> on distro layers, it largely defeats the purpose of having layers.

Darren: Is it true you can't get @ the Intel BSP's w/o also getting the 
poky distro defs?  That does seem to mixing things a bit.  (I am not 
claiming meta-ti is clean yet but I want to understand the Intel examples.)

Re: yocto beagleboard.conf -- should it not go away?

[Darren Hart]

On 09/04/2012 01:25 PM, William Mills wrote:

> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the 
> poky distro defs?  That does seem to mixing things a bit.  (I am not 
> claiming meta-ti is clean yet but I want to understand the Intel examples.)
> 

It isn't something we test as part of the QA that we perform. I mostly
expect people building meta-intel to be building with meta-yocto
(although I wouldn't take a hard line on requiring it). That said, I
removed meta-yocto from a meta-intel/meta-fri2 build and removed
DISTRO=poky from my local.conf and successfully built and booted a
core-image-minimal build on an FRI2 this afternoon without any changes.

This was with latest master of both poky and meta-intel. I have not
tried this with oe-core and bitbake pulled down separately, I'll leave
that as an exercise for the reader.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 04/09/12 21:25, William Mills wrote:
> I suspect the current issue is just growing pains for a case that has
> not been tested.

The simplest fix would be for meta-ti to preppend itself to the path the
same way meta-yocto does, i.e., in the layer.conf

  BBPATH := "${LAYERDIR}:${BBPATH}"

In fact, this is the *only* way that a layer can override any conf files
in oe-core, which is probably what you always want in a BSP layer?

Just quickly scanning yocto git, there are a number of BSP layers that
are configured the same way as meta-ti, so potentially have the same
problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
layers configured this way too, but I think it's only a big issue for
BSP layers and distro layers.)

As long as we are mixing layers that do both prepend and append, the
layering will continue to be broken in subtle and hard to identify ways.
I can't think of a practical use case where a layer other than oe-core
might need to append itself to the BBPATH? If there were no genuine need
for layers to append to the path, the BBPATH extension could be done
automatically when including the layer, instead doing manually in each
layer.conf, giving us some consistency.


> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
> poky distro defs?  That does seem to mixing things a bit.  (I am not
> claiming meta-ti is clean yet but I want to understand the Intel examples.)

I apologize for getting this wrong, meta-intel is not dependent on
meta-yocto (the meta-yocto bbappends are only apply to the machines
meta-yocto itself contains configs for). But you do need meta-yocto for
the atom-pc machine, because meta-yocto is the BSP layer for that (and
should Intel decide to add an atom-pc to meta-intel, it will be broken
exactly the same as the beagleboard machine is just now).

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Paul Eggleton]

On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> The simplest fix would be for meta-ti to preppend itself to the path the
> same way meta-yocto does, i.e., in the layer.conf
> 
>   BBPATH := "${LAYERDIR}:${BBPATH}"
> 
> In fact, this is the *only* way that a layer can override any conf files
> in oe-core, which is probably what you always want in a BSP layer?
> 
> Just quickly scanning yocto git, there are a number of BSP layers that
> are configured the same way as meta-ti, so potentially have the same
> problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
> layers configured this way too, but I think it's only a big issue for
> BSP layers and distro layers.)
> 
> As long as we are mixing layers that do both prepend and append, the
> layering will continue to be broken in subtle and hard to identify ways.
> I can't think of a practical use case where a layer other than oe-core
> might need to append itself to the BBPATH? If there were no genuine need
> for layers to append to the path, the BBPATH extension could be done
> automatically when including the layer, instead doing manually in each
> layer.conf, giving us some consistency.

It has been considered witin OE to be best practice to append to BBPATH and 
not prepend, the thinking being that then the search path matches the order of 
the layers listed in bblayers.conf rather than the reverse. I'm not sure I 
agree with it (I tend to prefer to list OE-Core first), but that's the 
convention adopted there.

Quite a few people have asked for the items which BBPATH controls (classes, 
conf files) to instead be found in layer priority order. If bitbake took over 
managing BBPATH, that would be a possibility, and as you say it would improve 
consistency at the expense of a little flexibility.

> But you do need meta-yocto for the atom-pc machine, because meta-yocto is
> the BSP layer for that (and should Intel decide to add an atom-pc to 
> meta-intel, it will be broken exactly the same as the beagleboard machine is
> just now).

Some time ago we discussed the possibility of moving the atom-pc BSP to meta-
intel and then copying it back into meta-yocto, once the layer tooling allowed 
for that to be done dynamically. Since the layer tooling is now in place that 
is at least a practical possibility, but I'm not sure if it's still on the 
cards - it still makes sense to me at any rate.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 05/09/12 10:15, Paul Eggleton wrote:
> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> It has been considered witin OE to be best practice to append to BBPATH and 
> not prepend, the thinking being that then the search path matches the order of 
> the layers listed in bblayers.conf rather than the reverse.

Then meta-yocto should follow that convention ... and it needs to be
well documented, with the consequence of breaking that convention
explained, and the terrible punishments to come described in great and
sordid detail. Because this needs to be more than a convention, it needs
to be an article of faith.

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie]

On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote:
> On 05/09/12 10:15, Paul Eggleton wrote:
> > On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> > It has been considered witin OE to be best practice to append to BBPATH and 
> > not prepend, the thinking being that then the search path matches the order of 
> > the layers listed in bblayers.conf rather than the reverse.
> 
> Then meta-yocto should follow that convention ... and it needs to be
> well documented, with the consequence of breaking that convention
> explained, and the terrible punishments to come described in great and
> sordid detail. Because this needs to be more than a convention, it needs
> to be an article of faith.

I just want to clarify something here.

Its accepted that most layers will append to BBPATH. I do think its
acceptable for a distro policy layer to prepend though and this is why
meta-yocto does this. I don't remember the exact reason right now but
the principle stands.

The root of the problem is that meta-yocto mixes up policy and hardware
support which is bad. It also means its not compliant with the new Yocto
Project compliance criteria and hence is not Yocto Project Compatible.

Now we've got the compliance criteria sorted out there are some
adjustments that need to be made and I will shortly be cleaving
meta-yocto into two pieces to resolve this. I hadn't looked at this
until now mainly in case there were changes to the criteria.

FWIW I think this shows the strength of those criteria as by following
them, we'd avoid a real world problem here.

Cheers,

Richard

Re: yocto beagleboard.conf -- should it not go away?

[William Mills]

On 09/04/2012 07:23 PM, Darren Hart wrote:
>
>
> On 09/04/2012 01:25 PM, William Mills wrote:
>
>> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
>> poky distro defs?  That does seem to mixing things a bit.  (I am not
>> claiming meta-ti is clean yet but I want to understand the Intel examples.)
>>
>
> It isn't something we test as part of the QA that we perform. I mostly
> expect people building meta-intel to be building with meta-yocto
> (although I wouldn't take a hard line on requiring it). That said, I
> removed meta-yocto from a meta-intel/meta-fri2 build and removed
> DISTRO=poky from my local.conf and successfully built and booted a
> core-image-minimal build on an FRI2 this afternoon without any changes.
>

Thanks!  My confidence is restored.

As long as including meta-yocto does not interfere with other BSPs or 
distros etc then there should be no harm in your assumption.

I would be interested to know what Mentor Graphics and Wind River do on 
their products.  Do they include meta-yocto? (YP is not all about 
comercial OS support but I know these orginatations have done the due 
diligence on layer compatibility for a non-poky distro.)

Re: yocto beagleboard.conf -- should it not go away?

[Darren Hart]

On 09/05/2012 02:15 AM, Paul Eggleton wrote:
> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
>> The simplest fix would be for meta-ti to preppend itself to the path the
>> same way meta-yocto does, i.e., in the layer.conf
>>
>>   BBPATH := "${LAYERDIR}:${BBPATH}"
>>
>> In fact, this is the *only* way that a layer can override any conf files
>> in oe-core, which is probably what you always want in a BSP layer?
>>
>> Just quickly scanning yocto git, there are a number of BSP layers that
>> are configured the same way as meta-ti, so potentially have the same
>> problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
>> layers configured this way too, but I think it's only a big issue for
>> BSP layers and distro layers.)
>>
>> As long as we are mixing layers that do both prepend and append, the
>> layering will continue to be broken in subtle and hard to identify ways.
>> I can't think of a practical use case where a layer other than oe-core
>> might need to append itself to the BBPATH? If there were no genuine need
>> for layers to append to the path, the BBPATH extension could be done
>> automatically when including the layer, instead doing manually in each
>> layer.conf, giving us some consistency.
> 
> It has been considered witin OE to be best practice to append to BBPATH and 
> not prepend, the thinking being that then the search path matches the order of 
> the layers listed in bblayers.conf rather than the reverse. I'm not sure I 
> agree with it (I tend to prefer to list OE-Core first), but that's the 
> convention adopted there.
> 
> Quite a few people have asked for the items which BBPATH controls (classes, 
> conf files) to instead be found in layer priority order. If bitbake took over 
> managing BBPATH, that would be a possibility, and as you say it would improve 
> consistency at the expense of a little flexibility.
> 
>> But you do need meta-yocto for the atom-pc machine, because meta-yocto is
>> the BSP layer for that (and should Intel decide to add an atom-pc to 
>> meta-intel, it will be broken exactly the same as the beagleboard machine is
>> just now).
> 
> Some time ago we discussed the possibility of moving the atom-pc BSP to meta-
> intel and then copying it back into meta-yocto, once the layer tooling allowed 
> for that to be done dynamically. Since the layer tooling is now in place that 
> is at least a practical possibility, but I'm not sure if it's still on the 
> cards - it still makes sense to me at any rate.

A case can be made, but in my opinion, atom-pc is a generic BSP (not
machine specific) and doesn't really fit with the other BSPs within
meta-intel. I believe we should have an Intel BSP in meta-yocto, but I
don't like the idea of duplicating a BSP in meta-yocto and meta-intel.
atom-pc seems like a reasonable candidate to leave in meta-yocto to me.

I could probably be convinced otherwise, but that's my current thinking.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: yocto beagleboard.conf -- should it not go away?

[Darren Hart]

On 09/05/2012 07:20 AM, William Mills wrote:
> On 09/04/2012 07:23 PM, Darren Hart wrote:
>>
>>
>> On 09/04/2012 01:25 PM, William Mills wrote:
>>
>>> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
>>> poky distro defs?  That does seem to mixing things a bit.  (I am not
>>> claiming meta-ti is clean yet but I want to understand the Intel examples.)
>>>
>>
>> It isn't something we test as part of the QA that we perform. I mostly
>> expect people building meta-intel to be building with meta-yocto
>> (although I wouldn't take a hard line on requiring it). That said, I
>> removed meta-yocto from a meta-intel/meta-fri2 build and removed
>> DISTRO=poky from my local.conf and successfully built and booted a
>> core-image-minimal build on an FRI2 this afternoon without any changes.
>>
> 
> Thanks!  My confidence is restored.
> 
> As long as including meta-yocto does not interfere with other BSPs or 
> distros etc then there should be no harm in your assumption.
> 
> I would be interested to know what Mentor Graphics and Wind River do on 
> their products.  Do they include meta-yocto? (YP is not all about 
> comercial OS support but I know these orginatations have done the due 
> diligence on layer compatibility for a non-poky distro.)

I haven't heard one way or the other, but perhaps Bruce, Sean, and
Matthew could comment on that.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: yocto beagleboard.conf -- should it not go away?

[William Mills]

On 09/05/2012 08:48 AM, Richard Purdie wrote:
> On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote:
>> On 05/09/12 10:15, Paul Eggleton wrote:
>>> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
>>> It has been considered witin OE to be best practice to append to BBPATH and
>>> not prepend, the thinking being that then the search path matches the order of
>>> the layers listed in bblayers.conf rather than the reverse.
>>
>> Then meta-yocto should follow that convention ... and it needs to be
>> well documented, with the consequence of breaking that convention
>> explained, and the terrible punishments to come described in great and
>> sordid detail. Because this needs to be more than a convention, it needs
>> to be an article of faith.
>
> I just want to clarify something here.
>
> Its accepted that most layers will append to BBPATH. I do think its
> acceptable for a distro policy layer to prepend though and this is why
> meta-yocto does this. I don't remember the exact reason right now but
> the principle stands.

So how should we resolve the issue in meta-ti for the denzil/1.2 branch?

I think the expediency of prepending sounds right to me.  We can shoot 
for a better fix in 1.3.

>
> The root of the problem is that meta-yocto mixes up policy and hardware
> support which is bad. It also means its not compliant with the new Yocto
> Project compliance criteria and hence is not Yocto Project Compatible.
>
> Now we've got the compliance criteria sorted out there are some
> adjustments that need to be made and I will shortly be cleaving
> meta-yocto into two pieces to resolve this. I hadn't looked at this
> until now mainly in case there were changes to the criteria.
>
> FWIW I think this shows the strength of those criteria as by following
> them, we'd avoid a real world problem here.

I'm glad you are thinking of doing this.  I think it sets a good example 
and is cleaner.

However we will still need priority or namespace to override the 
beagleboard definition in the meta-yocto-bsp (or whatever) layer if it 
contains both the beagleboard reference and the atom-pc.

Re: yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 05/09/12 15:45, William Mills wrote:
>> Its accepted that most layers will append to BBPATH. I do think its
>> acceptable for a distro policy layer to prepend though and this is why
>> meta-yocto does this. I don't remember the exact reason right now but
>> the principle stands.
> 
> So how should we resolve the issue in meta-ti for the denzil/1.2 branch?
> 
> I think the expediency of prepending sounds right to me.  We can shoot
> for a better fix in 1.3.

I think in the light of what Paul said, the meta-ti behaviour is what is
expected and changing will potentially complicate things for other
meta-ti consumers who follow the convention; the problem is in
meta-yocto, not meta-ti.

The current problem can be worked around; it requires a custom layer
that also prepends itself to the path in front of meta-yocto, and then
provides a beagleboard.conf of it's own (which can simply 'include' or
'require' the beagleboard.conf from meta-ti). I think if Richard is
working on a solution in meta-yocto, it might be enough to document this
somewhere until it is ready.

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Bruce Ashfield]

On 12-09-05 10:20 AM, William Mills wrote:
> On 09/04/2012 07:23 PM, Darren Hart wrote:
>>
>>
>> On 09/04/2012 01:25 PM, William Mills wrote:
>>
>>> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
>>> poky distro defs? That does seem to mixing things a bit. (I am not
>>> claiming meta-ti is clean yet but I want to understand the Intel
>>> examples.)
>>>
>>
>> It isn't something we test as part of the QA that we perform. I mostly
>> expect people building meta-intel to be building with meta-yocto
>> (although I wouldn't take a hard line on requiring it). That said, I
>> removed meta-yocto from a meta-intel/meta-fri2 build and removed
>> DISTRO=poky from my local.conf and successfully built and booted a
>> core-image-minimal build on an FRI2 this afternoon without any changes.
>>
>
> Thanks! My confidence is restored.
>
> As long as including meta-yocto does not interfere with other BSPs or
> distros etc then there should be no harm in your assumption.
>
> I would be interested to know what Mentor Graphics and Wind River do on
> their products. Do they include meta-yocto? (YP is not all about
> comercial OS support but I know these orginatations have done the due
> diligence on layer compatibility for a non-poky distro.)

Layering flexibility is important, so we work largely on oe-core
vs meta-yocto. That being said, there are elements in meta-yocto that
are of interest, so it can be included in used, but with layers that
get the ordering and priority correct to override/preserve appropriately.

But sorting out exactly what we are talking about in this thread, would
make using meta-yocto (or whatever the elements of it become), that much
easier to do.

Cheers,

Bruce

>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie]

On Wed, 2012-09-05 at 10:45 -0400, William Mills wrote:
> 
> On 09/05/2012 08:48 AM, Richard Purdie wrote:
> > On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote:
> >> On 05/09/12 10:15, Paul Eggleton wrote:
> >>> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> >>> It has been considered witin OE to be best practice to append to BBPATH and
> >>> not prepend, the thinking being that then the search path matches the order of
> >>> the layers listed in bblayers.conf rather than the reverse.
> >>
> >> Then meta-yocto should follow that convention ... and it needs to be
> >> well documented, with the consequence of breaking that convention
> >> explained, and the terrible punishments to come described in great and
> >> sordid detail. Because this needs to be more than a convention, it needs
> >> to be an article of faith.
> >
> > I just want to clarify something here.
> >
> > Its accepted that most layers will append to BBPATH. I do think its
> > acceptable for a distro policy layer to prepend though and this is why
> > meta-yocto does this. I don't remember the exact reason right now but
> > the principle stands.
> 
> So how should we resolve the issue in meta-ti for the denzil/1.2 branch?
> 
> I think the expediency of prepending sounds right to me.  We can shoot 
> for a better fix in 1.3.

I think the problem is in meta-yocto and is hitting a particular subset
of users where people combine meta-yocto and meta-ti.

I'm not sure this can easily be fixed in meta-ti, or that we currently
have a high volume of users mixing those two.

> > The root of the problem is that meta-yocto mixes up policy and hardware
> > support which is bad. It also means its not compliant with the new Yocto
> > Project compliance criteria and hence is not Yocto Project Compatible.
> >
> > Now we've got the compliance criteria sorted out there are some
> > adjustments that need to be made and I will shortly be cleaving
> > meta-yocto into two pieces to resolve this. I hadn't looked at this
> > until now mainly in case there were changes to the criteria.
> >
> > FWIW I think this shows the strength of those criteria as by following
> > them, we'd avoid a real world problem here.
> 
> I'm glad you are thinking of doing this.  I think it sets a good example 
> and is cleaner.
> 
> However we will still need priority or namespace to override the 
> beagleboard definition in the meta-yocto-bsp (or whatever) layer if it 
> contains both the beagleboard reference and the atom-pc.

With the solution, you can just order the meta-ti and meta-yocto-bsp
layers such that the TI layer "wins" and no extra configuration is
necessary. The trouble is that the meta-yocto doesn't allow this at the
moment as things stand.

In many ways this is just part of the learning experience of how to use
and how not to use layers...

Despite the fact we just passed the feature freeze point, I'm going to
ensure we get this fixed for 1.3.

Cheers,

Richard

Re: yocto beagleboard.conf -- should it not go away?

[Martin Jansa]

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

On Wed, Sep 05, 2012 at 01:48:23PM +0100, Richard Purdie wrote:
> On Wed, 2012-09-05 at 10:43 +0100, Tomas Frydrych wrote:
> > On 05/09/12 10:15, Paul Eggleton wrote:
> > > On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> > > It has been considered witin OE to be best practice to append to BBPATH and 
> > > not prepend, the thinking being that then the search path matches the order of 
> > > the layers listed in bblayers.conf rather than the reverse.
> > 
> > Then meta-yocto should follow that convention ... and it needs to be
> > well documented, with the consequence of breaking that convention
> > explained, and the terrible punishments to come described in great and
> > sordid detail. Because this needs to be more than a convention, it needs
> > to be an article of faith.
> 
> I just want to clarify something here.
> 
> Its accepted that most layers will append to BBPATH. I do think its
> acceptable for a distro policy layer to prepend though and this is why
> meta-yocto does this. I don't remember the exact reason right now but
> the principle stands.

Then the reason should be documented in layer's README file with warning
that this layer wants to be first or last in BBPATH so whoever is
setting BBLAYERS can decide where to put it.

> The root of the problem is that meta-yocto mixes up policy and hardware
> support which is bad. It also means its not compliant with the new Yocto
> Project compliance criteria and hence is not Yocto Project Compatible.
> 
> Now we've got the compliance criteria sorted out there are some
> adjustments that need to be made and I will shortly be cleaving
> meta-yocto into two pieces to resolve this. I hadn't looked at this
> until now mainly in case there were changes to the criteria.
> 
> FWIW I think this shows the strength of those criteria as by following
> them, we'd avoid a real world problem here.
> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie]

On Wed, 2012-09-05 at 13:48 +0100, Richard Purdie wrote:
> The root of the problem is that meta-yocto mixes up policy and hardware
> support which is bad. It also means its not compliant with the new Yocto
> Project compliance criteria and hence is not Yocto Project Compatible.
> 
> Now we've got the compliance criteria sorted out there are some
> adjustments that need to be made and I will shortly be cleaving
> meta-yocto into two pieces to resolve this. I hadn't looked at this
> until now mainly in case there were changes to the criteria.

This has now been fixed in:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=2000698b17011bbde1c3e5bb01a7d6763316db5a

Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie]

On Tue, 2012-09-04 at 09:58 +0100, Tomas Frydrych wrote:
> Hi Bruce,
> 
> On 03/09/12 22:08, Bruce Ashfield wrote:
> > That being said, taking a step back, what are you trying to get out of
> > meta-yocto in this scenario ? 
> 
> a) I am targeting multiple chips, including TI Omap and Intel Atom.
> meta-yocto is a prerequisite for the various machines in meta-intel, so
> I have to include meta-yocto if I want to build images for an Intel
> chip. Nothing unusual here.

Is that really true? What in meta-intel depends on meta-yocto?

This certainly isn't intentional so I'd like to understand more.

> b) meta-yocto is the Poky distro layer; if you want to use Poky, then
> you need meta-yocto.
>
> > see above. I misspoke. I don't think there's an intent to make meta-yocto
> > and meta-ti work together, but oe-core + meta-ti, that's the combo that
> > makes sense.
> 
> See (b) above; you are not saying that Poky is only meant for Intel HW,
> are you?
> 
> The basic problem with meta-yocto is that it combines BSP stuff
> (meta-intel prerequisite, Atom & Beagle config) with distro stuff (Poky,
> Yocto branding). That's convenient for doing QA on a limited set of HW,
> but suboptimal for real use; BSP layers simply should not be dependent
> on distro layers, it largely defeats the purpose of having layers.
> 
> Splitting out the minimal beagle config into a layer of its own would
> improve things quite a bit.

Effectively this is what we've now done and was always the intention
(see the Yocto Project compatible criteria).

Cheers,

Richard

Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie]

On Wed, 2012-09-05 at 10:20 -0400, William Mills wrote:
> On 09/04/2012 07:23 PM, Darren Hart wrote:
> >
> >
> > On 09/04/2012 01:25 PM, William Mills wrote:
> >
> >> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
> >> poky distro defs?  That does seem to mixing things a bit.  (I am not
> >> claiming meta-ti is clean yet but I want to understand the Intel examples.)
> >>
> >
> > It isn't something we test as part of the QA that we perform. I mostly
> > expect people building meta-intel to be building with meta-yocto
> > (although I wouldn't take a hard line on requiring it). That said, I
> > removed meta-yocto from a meta-intel/meta-fri2 build and removed
> > DISTRO=poky from my local.conf and successfully built and booted a
> > core-image-minimal build on an FRI2 this afternoon without any changes.
> >
> 
> Thanks!  My confidence is restored.
> 
> As long as including meta-yocto does not interfere with other BSPs or 
> distros etc then there should be no harm in your assumption.
> 
> I would be interested to know what Mentor Graphics and Wind River do on 
> their products.  Do they include meta-yocto? (YP is not all about 
> comercial OS support but I know these orginatations have done the due 
> diligence on layer compatibility for a non-poky distro.)

Commercial OS support usually involves some of your own policy so
meta-yocto is interesting as an example to them but they'd probably only
use it as inspiration to write their own. That was always expected and
meta-yocto is extremely thin deliberately.

Having said that, what meta-yocto was doing was wrong, it wasn't
intentional, the implications not fully realised and is hopefully now
fixed with the split :).

Cheers,

Richard

Re: yocto beagleboard.conf -- should it not go away?

[Richard Purdie]

On Tue, 2012-09-04 at 09:21 +0100, Jack Mitchell wrote:
> On 03/09/12 22:08, Bruce Ashfield wrote:
> > On Mon, Sep 3, 2012 at 4:55 PM, Tomas Frydrych
> > <tf+lists.yocto@r-finger.com> wrote:
> >> snip...
> >>
> >>
> >>
> >> That being said, taking a step back, what are you trying to get out of
> >> meta-yocto in this scenario ? oe-core + meta-ti is probably what you
> >> should be using.
> >>
> 
> Sorry to jump in here, but this is actually a very interesting point. 
>  From coming to OpenEmbedded through Yocto and subsequently learning 
> about the ecosystem as a whole, I have always considered meta-yocto to 
> be providing a sane distro configuration. This implies that I believe 
> the oe-core default distro configuration, even though it will build, the 
> result won't be very satisfying - or maybe a bit disjointed.
>
> You seem to be saying above that the meta-yocto layer is only any good 
> for providing the kernel framework, and as he is not using the framework 
> (i.e. using meta-ti) then there is no point in using the meta-yocto 
> layer? So does the Poky distro config only really slap a name on the 
> oe-core default distro policy - or does it have some added value?

In the old days, there was no default distro config. OE-Core changed
that as an experiment which IMO has been relatively successful. The Poky
distro config inherits as much as possible from the core defaults. The
extras are (reading poky.conf):

* Example of Distro Branding
* Ensuring some particular kernel versions
* Particular SDK layout
* Minor tweaks to basic images/qemu images
* Mirror Setup (although OE-Core has these now too iirc)
* Sets connectivity check
* Sets list of compatible/tested distros
* Some signature stuff (now OE-Core default)
* Sets more stringent package sanity checks that OE-Core

So at least some of the above moved into the core as default although we
still need to remove the remnants from the poky.conf file. Others will
likely move in future too.

There isn't anything major above but there are several smaller usability
tweaks/optimisations and I'd argue there is some added value.

There are also example LSB and "tiny" profiles showing how to take the
system and customise it in different ways which I'd argue have value
too.

> I'm not trying to rile anyone up here, just trying to put the jigsaw 
> together as the picture looks different every time I revisit it!!

Its an evolving picture, hopefully in a good way :)

Cheers,

Richard

Re: yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 05/09/12 22:46, Richard Purdie wrote:
> On Tue, 2012-09-04 at 09:58 +0100, Tomas Frydrych wrote:
>> Hi Bruce,
>>
>> On 03/09/12 22:08, Bruce Ashfield wrote:
>>> That being said, taking a step back, what are you trying to get out of
>>> meta-yocto in this scenario ? 
>>
>> a) I am targeting multiple chips, including TI Omap and Intel Atom.
>> meta-yocto is a prerequisite for the various machines in meta-intel, so
>> I have to include meta-yocto if I want to build images for an Intel
>> chip. Nothing unusual here.
> 
> Is that really true? What in meta-intel depends on meta-yocto?

No, it is not true; I corrected that erroneous statement earlier in this
thread.


> Effectively this is what we've now done and was always the intention
> (see the Yocto Project compatible criteria).

Yes, that looks like it solves the problem neatly. Now I should be able
to include both meta-yocto and meta-yocto-bsb if I want to.

Tomas

Re: yocto beagleboard.conf -- should it not go away?

[Khem Raj]

On (04/09/12 16:25), William Mills wrote:
> On 09/04/2012 01:18 PM, Darren Hart wrote:
> >
> >
> >On 09/04/2012 05:20 AM, Bruce Ashfield wrote:
> >>On Tue, Sep 4, 2012 at 4:58 AM, Tomas Frydrych
> >><tf+lists.yocto@r-finger.com>  wrote:
> >>>Hi Bruce,
> >>>
> >>>On 03/09/12 22:08, Bruce Ashfield wrote:
> >>>>That being said, taking a step back, what are you trying to get out of
> >>>>meta-yocto in this scenario ?
> >>>
> >>>a) I am targeting multiple chips, including TI Omap and Intel Atom.
> >>>meta-yocto is a prerequisite for the various machines in meta-intel, so
> >>>I have to include meta-yocto if I want to build images for an Intel
> >>>chip. Nothing unusual here.
> >>>
> >>>b) meta-yocto is the Poky distro layer; if you want to use Poky, then
> >>>you need meta-yocto.
> >>>
> >>>>see above. I misspoke. I don't think there's an intent to make meta-yocto
> >>>>and meta-ti work together, but oe-core + meta-ti, that's the combo that
> >>>>makes sense.
> 
> oe-core + meta-ti should work or it needs to get fixed.
> poky + meta-ti should work or it needs to get fixed.
> 
> However I suspect the 2nd is not in the nightly builds yet.
> 
> Denys is out for the next few days.  He can comment more when he gets back.
> 
> It has been our assumption that there is enough functionality in the
> layer mechanisms that any of the "light weight" BSPs in yocto layer
> could be completely overridden by a more complete layer (meta-ti in
> this example).  In addition the end system integrator should be able
> to override definitions in any BSP layer.
> 
> I suspect the current issue is just growing pains for a case that
> has not been tested.  Lets prove that false before taking more
> drastic action.
> 
> >>>
> >>>The basic problem with meta-yocto is that it combines BSP stuff
> >>>(meta-intel prerequisite, Atom&  Beagle config) with distro stuff (Poky,
> >>>Yocto branding). That's convenient for doing QA on a limited set of HW,
> >>>but suboptimal for real use; BSP layers simply should not be dependent
> >>>on distro layers, it largely defeats the purpose of having layers.
> 
> Darren: Is it true you can't get @ the Intel BSP's w/o also getting
> the poky distro defs?  That does seem to mixing things a bit.  (I am
> not claiming meta-ti is clean yet but I want to understand the Intel
> examples.)
> 

angstrom used meta-intel and it does not have meta-yocto that said I
have not built for Intel machines using Angstrom so there might be
issues but it parses fine for me so far.

> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
-Khem