Updating u-boot for oe-core or meta-yocto

Updating u-boot for oe-core or meta-yocto

[Darren Hart]

I've started pulling in the 15 or so patches to u-boot from meta-ti. In
doing so I've come across some questions I'd like you thoughts on.
Specifically, where to put these changes. Some points of context:

1) oe-core is intended to support emulated machines only
2) oe-core has a "virgin" u-boot recipe (no patches)
3) meta-yocto does not have a u-boot recipe (no bbappend either)
4) meta-ti has it's own u-boot recipe with per-machine patches

A stated goal was to bring the Yocto Project's u-boot support for the
Beagleboard in line with that in meta-ti. There are several ways I can
go about this.

a) create a bbappend in meta-yocto and duplicate the meta-ti
   modifications in bbappend form.
b) Modify the oe-core recipe directly

While a) is the most direct approach to accomplish our goal, it requires
continual maintenance and duplicates effort. I don't care for this
approach. b) has the potential to consolidate all beagleboard u-boot
recipe work into a single place. It could simplify the meta-ti and
eliminate the need for a bbappend in the meta-yocto layer.

The question of whether bootloaders have a place in oe-core should
probably be addressed. While they aren't needed for the emulated
machines, they are a highly reusable component for real systems, and
that seems justify keeping them in oe-core. Does anyone disagree with
this assessment?

I propose pulling the necessary changes to u-boot from meta-ti into
oe-core. My initial scan suggested the beagleboard patches are mostly
contained to beagle specific source files. I would prefer to pull in all
the patches for all machines into the SRC_URI, rather than divide them
up by machine. This reduces complexity considerably. For the couple of
patches that collide, we would keep those as machine specific.

As a final part of the work, I would include my beagleboard patch status
audit in the included patches and continue to work on reducing the
patches in the recipe for the beagleboard.

Thoughts?

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

Re: Updating u-boot for oe-core or meta-yocto

[Koen Kooi]

Op 24 mei 2011, om 18:36 heeft Darren Hart het volgende geschreven:

> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> doing so I've come across some questions I'd like you thoughts on.
> Specifically, where to put these changes. Some points of context:
> 
> 1) oe-core is intended to support emulated machines only
> 2) oe-core has a "virgin" u-boot recipe (no patches)
> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
> 4) meta-ti has it's own u-boot recipe with per-machine patches
> 
> A stated goal was to bring the Yocto Project's u-boot support for the
> Beagleboard in line with that in meta-ti. There are several ways I can
> go about this.
> 
> a) create a bbappend in meta-yocto and duplicate the meta-ti
>   modifications in bbappend form.
> b) Modify the oe-core recipe directly

You're forgetting:

c) Have yocto use meta-ti for beagleboard. 

TI is actively participating in yocto and it's getting way too weird that you yocto guys keep refusing to use the meta-ti layer. I've heard the arguments why you refuse it, but at this point this is becoming a farce.

> 
> While a) is the most direct approach to accomplish our goal, it requires
> continual maintenance and duplicates effort. I don't care for this
> approach. b) has the potential to consolidate all beagleboard u-boot
> recipe work into a single place. It could simplify the meta-ti and
> eliminate the need for a bbappend in the meta-yocto layer.
> 
> The question of whether bootloaders have a place in oe-core should
> probably be addressed. While they aren't needed for the emulated
> machines, they are a highly reusable component for real systems, and
> that seems justify keeping them in oe-core. Does anyone disagree with
> this assessment?
> 
> I propose pulling the necessary changes to u-boot from meta-ti into
> oe-core. 

I most strongly object to that. But given that you are still refusing to use meta-ti, I suspect it doesn't matter what I say as the maintainer for beagleboard.

Re: Updating u-boot for oe-core or meta-yocto

[Khem Raj]

On (24/05/11 09:36), Darren Hart wrote:
> I've started pulling in the 15 or so patches to u-boot from meta-ti. In

why ? its a BSP recipe and bsp layer is best place for it IMO unless you
want to have some of those machines in a different layer.

> doing so I've come across some questions I'd like you thoughts on.
> Specifically, where to put these changes. Some points of context:
> 
> 1) oe-core is intended to support emulated machines only
> 2) oe-core has a "virgin" u-boot recipe (no patches)
> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
> 4) meta-ti has it's own u-boot recipe with per-machine patches
> 
> A stated goal was to bring the Yocto Project's u-boot support for the
> Beagleboard in line with that in meta-ti. There are several ways I can
> go about this.
> 
> a) create a bbappend in meta-yocto and duplicate the meta-ti
>    modifications in bbappend form.
> b) Modify the oe-core recipe directly
> 
> While a) is the most direct approach to accomplish our goal, it requires
> continual maintenance and duplicates effort. I don't care for this
> approach. b) has the potential to consolidate all beagleboard u-boot
> recipe work into a single place. It could simplify the meta-ti and
> eliminate the need for a bbappend in the meta-yocto layer.
> 
> The question of whether bootloaders have a place in oe-core should
> probably be addressed. While they aren't needed for the emulated
> machines, they are a highly reusable component for real systems, and
> that seems justify keeping them in oe-core. Does anyone disagree with
> this assessment?
> 
> I propose pulling the necessary changes to u-boot from meta-ti into
> oe-core. My initial scan suggested the beagleboard patches are mostly
> contained to beagle specific source files. I would prefer to pull in all
> the patches for all machines into the SRC_URI, rather than divide them
> up by machine. This reduces complexity considerably. For the couple of
> patches that collide, we would keep those as machine specific.
> 
> As a final part of the work, I would include my beagleboard patch status
> audit in the included patches and continue to work on reducing the
> patches in the recipe for the beagleboard.
> 
> Thoughts?

Well I am in similar boat where I wanted to build atom-pc for angstrom
but I was thinking using meta-intel layer instead of pulling stuff out
and stuffing it elsewhere and certainly not oe-core

> 
> -- 
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem

Re: Updating u-boot for oe-core or meta-yocto

[Martin Jansa]

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

On Tue, May 24, 2011 at 09:36:45AM -0700, Darren Hart wrote:
> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> doing so I've come across some questions I'd like you thoughts on.
> Specifically, where to put these changes. Some points of context:
> 
> 1) oe-core is intended to support emulated machines only
> 2) oe-core has a "virgin" u-boot recipe (no patches)
> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
> 4) meta-ti has it's own u-boot recipe with per-machine patches
> 
> A stated goal was to bring the Yocto Project's u-boot support for the
> Beagleboard in line with that in meta-ti. There are several ways I can
> go about this.
> 
> a) create a bbappend in meta-yocto and duplicate the meta-ti
>    modifications in bbappend form.
> b) Modify the oe-core recipe directly

From my understanding what BSP layers are for:
c) use meta-ti BSP in meta-yocto

and if something in meta-ti is not good enough for meta-yocto, then
alter it with .bbappend or work with meta-ti folks to improve it in
meta-ti directly.

> While a) is the most direct approach to accomplish our goal, it requires
> continual maintenance and duplicates effort. I don't care for this
> approach. b) has the potential to consolidate all beagleboard u-boot
> recipe work into a single place. It could simplify the meta-ti and
> eliminate the need for a bbappend in the meta-yocto layer.
> 
> The question of whether bootloaders have a place in oe-core should
> probably be addressed. While they aren't needed for the emulated
> machines, they are a highly reusable component for real systems, and
> that seems justify keeping them in oe-core. Does anyone disagree with
> this assessment?
> 
> I propose pulling the necessary changes to u-boot from meta-ti into
> oe-core. My initial scan suggested the beagleboard patches are mostly
> contained to beagle specific source files. I would prefer to pull in all
> the patches for all machines into the SRC_URI, rather than divide them
> up by machine. This reduces complexity considerably. For the couple of
> patches that collide, we would keep those as machine specific.
> 
> As a final part of the work, I would include my beagleboard patch status
> audit in the included patches and continue to work on reducing the
> patches in the recipe for the beagleboard.
> 
> Thoughts?
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Koen Kooi]

Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:

> On (24/05/11 09:36), Darren Hart wrote:
>> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> 
> why ? its a BSP recipe and bsp layer is best place for it IMO unless you
> want to have some of those machines in a different layer.
> 
>> doing so I've come across some questions I'd like you thoughts on.
>> Specifically, where to put these changes. Some points of context:
>> 
>> 1) oe-core is intended to support emulated machines only
>> 2) oe-core has a "virgin" u-boot recipe (no patches)
>> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
>> 4) meta-ti has it's own u-boot recipe with per-machine patches
>> 
>> A stated goal was to bring the Yocto Project's u-boot support for the
>> Beagleboard in line with that in meta-ti. There are several ways I can
>> go about this.
>> 
>> a) create a bbappend in meta-yocto and duplicate the meta-ti
>>   modifications in bbappend form.
>> b) Modify the oe-core recipe directly
>> 
>> While a) is the most direct approach to accomplish our goal, it requires
>> continual maintenance and duplicates effort. I don't care for this
>> approach. b) has the potential to consolidate all beagleboard u-boot
>> recipe work into a single place. It could simplify the meta-ti and
>> eliminate the need for a bbappend in the meta-yocto layer.
>> 
>> The question of whether bootloaders have a place in oe-core should
>> probably be addressed. While they aren't needed for the emulated
>> machines, they are a highly reusable component for real systems, and
>> that seems justify keeping them in oe-core. Does anyone disagree with
>> this assessment?
>> 
>> I propose pulling the necessary changes to u-boot from meta-ti into
>> oe-core. My initial scan suggested the beagleboard patches are mostly
>> contained to beagle specific source files. I would prefer to pull in all
>> the patches for all machines into the SRC_URI, rather than divide them
>> up by machine. This reduces complexity considerably. For the couple of
>> patches that collide, we would keep those as machine specific.
>> 
>> As a final part of the work, I would include my beagleboard patch status
>> audit in the included patches and continue to work on reducing the
>> patches in the recipe for the beagleboard.
>> 
>> Thoughts?
> 
> Well I am in similar boat where I wanted to build atom-pc for angstrom
> but I was thinking using meta-intel layer instead of pulling stuff out
> and stuffing it elsewhere and certainly not oe-core

Speaking of meta-intel layers, when I add them to bblayer.conf I get:

ERROR: Error parsing /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux/linux-yocto-stable_git.bb: Failure expanding variable FILESEXTRAPATHS, expression was ${FILESEXTRAPATHS}:/OE/tentacle/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-stable which triggered exception Exception: variable FILESEXTRAPATHS references itself!

Same for jasperforest, emenlow, fishriver and crownbay. The only intel layer I can add without breaking the parsing step is sugarbay :(

Same goes for meta-xilinx, that breaks in the uboot recipe with some NoneType and string errors.

regards,

Koen

Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/24/2011 10:13 AM, Koen Kooi wrote:
> 
> Op 24 mei 2011, om 18:36 heeft Darren Hart het volgende geschreven:
> 
>> I've started pulling in the 15 or so patches to u-boot from
>> meta-ti. In doing so I've come across some questions I'd like you
>> thoughts on. Specifically, where to put these changes. Some points
>> of context:
>> 
>> 1) oe-core is intended to support emulated machines only 2) oe-core
>> has a "virgin" u-boot recipe (no patches) 3) meta-yocto does not
>> have a u-boot recipe (no bbappend either) 4) meta-ti has it's own
>> u-boot recipe with per-machine patches
>> 
>> A stated goal was to bring the Yocto Project's u-boot support for
>> the Beagleboard in line with that in meta-ti. There are several
>> ways I can go about this.
>> 
>> a) create a bbappend in meta-yocto and duplicate the meta-ti 
>> modifications in bbappend form. b) Modify the oe-core recipe
>> directly
> 
> You're forgetting:
> 
> c) Have yocto use meta-ti for beagleboard.

Per our discussion at ELC, according to the notes I took anyway, we
agreed that in order for meta-yocto to support the Beagleboard we would
have a two stage effort.

The first would be to update the meta-yocto uboot and kernel recipes
(and this meant the linux-yocto*.git kernel repositories and meta data)
with the meta-ti recipes. This is the aspect I'm working on now.

Second would be to work with meta-ti through the layer tooling which is
being actively discussed on the lists.


> TI is actively participating in yocto and it's getting way too weird
> that you yocto guys keep refusing to use the meta-ti layer. I've
> heard the arguments why you refuse it, but at this point this is
> becoming a farce.


Your approach here is not conducive to arriving at a mutually acceptable
solution, neither is it in keeping with the plan laid out at ELC with
your input.


>> 
>> While a) is the most direct approach to accomplish our goal, it
>> requires continual maintenance and duplicates effort. I don't care
>> for this approach. b) has the potential to consolidate all
>> beagleboard u-boot recipe work into a single place. It could
>> simplify the meta-ti and eliminate the need for a bbappend in the
>> meta-yocto layer.
>> 
>> The question of whether bootloaders have a place in oe-core should 
>> probably be addressed. While they aren't needed for the emulated 
>> machines, they are a highly reusable component for real systems,
>> and that seems justify keeping them in oe-core. Does anyone
>> disagree with this assessment?
>> 
>> I propose pulling the necessary changes to u-boot from meta-ti
>> into oe-core.
> 
> I most strongly object to that.


You object to moving the changes into oe-core? Or you object to any
changes to a u-boot recipe that don't involve simply referencing
meta-ti? If the latter, we need to revisit our previously agreed upon
course of action because we seem to have different views of what that is.


> But given that you are still refusing
> to use meta-ti, I suspect it doesn't matter what I say as the
> maintainer for beagleboard. 


I asked for your opinion by Cc'ing you Koen.


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

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Tom Zanussi]

On Tue, 2011-05-24 at 10:51 -0700, Koen Kooi wrote:
> Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
> 
> > On (24/05/11 09:36), Darren Hart wrote:
> >> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> > 
> > why ? its a BSP recipe and bsp layer is best place for it IMO unless you
> > want to have some of those machines in a different layer.
> > 
> >> doing so I've come across some questions I'd like you thoughts on.
> >> Specifically, where to put these changes. Some points of context:
> >> 
> >> 1) oe-core is intended to support emulated machines only
> >> 2) oe-core has a "virgin" u-boot recipe (no patches)
> >> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
> >> 4) meta-ti has it's own u-boot recipe with per-machine patches
> >> 
> >> A stated goal was to bring the Yocto Project's u-boot support for the
> >> Beagleboard in line with that in meta-ti. There are several ways I can
> >> go about this.
> >> 
> >> a) create a bbappend in meta-yocto and duplicate the meta-ti
> >>   modifications in bbappend form.
> >> b) Modify the oe-core recipe directly
> >> 
> >> While a) is the most direct approach to accomplish our goal, it requires
> >> continual maintenance and duplicates effort. I don't care for this
> >> approach. b) has the potential to consolidate all beagleboard u-boot
> >> recipe work into a single place. It could simplify the meta-ti and
> >> eliminate the need for a bbappend in the meta-yocto layer.
> >> 
> >> The question of whether bootloaders have a place in oe-core should
> >> probably be addressed. While they aren't needed for the emulated
> >> machines, they are a highly reusable component for real systems, and
> >> that seems justify keeping them in oe-core. Does anyone disagree with
> >> this assessment?
> >> 
> >> I propose pulling the necessary changes to u-boot from meta-ti into
> >> oe-core. My initial scan suggested the beagleboard patches are mostly
> >> contained to beagle specific source files. I would prefer to pull in all
> >> the patches for all machines into the SRC_URI, rather than divide them
> >> up by machine. This reduces complexity considerably. For the couple of
> >> patches that collide, we would keep those as machine specific.
> >> 
> >> As a final part of the work, I would include my beagleboard patch status
> >> audit in the included patches and continue to work on reducing the
> >> patches in the recipe for the beagleboard.
> >> 
> >> Thoughts?
> > 
> > Well I am in similar boat where I wanted to build atom-pc for angstrom
> > but I was thinking using meta-intel layer instead of pulling stuff out
> > and stuffing it elsewhere and certainly not oe-core
> 
> Speaking of meta-intel layers, when I add them to bblayer.conf I get:
> 
> ERROR: Error parsing /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux/linux-yocto-stable_git.bb: Failure expanding variable FILESEXTRAPATHS, expression was ${FILESEXTRAPATHS}:/OE/tentacle/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-stable which triggered exception Exception: variable FILESEXTRAPATHS references itself!
> 
> Same for jasperforest, emenlow, fishriver and crownbay. The only intel layer I can add without breaking the parsing step is sugarbay :(
> 

Must be something recent - I've built several of those successfully over
the past few days, will take a look though...

Tom

> Same goes for meta-xilinx, that breaks in the uboot recipe with some NoneType and string errors.
> 
> regards,
> 
> Koen
> 

Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/24/2011 10:23 AM, Khem Raj wrote:
> On (24/05/11 09:36), Darren Hart wrote:
>> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> 
> why ? its a BSP recipe and bsp layer is best place for it IMO unless you
> want to have some of those machines in a different layer.


The underlying goal here is to improve the Beagleboard support in
meta-yocto, without unnecessarily duplicating work. It was suggested at
ELC that we modify the u-boot and linux-yocto recipes/sources to include
the beagleboard specific changes from meta-ti. Once the boot loader and
kernel were in place, we would look to using the still-under-discussion
layer tooling to integrate the rest of meta-ti.


> 
>> doing so I've come across some questions I'd like you thoughts on.
>> Specifically, where to put these changes. Some points of context:
>>
>> 1) oe-core is intended to support emulated machines only
>> 2) oe-core has a "virgin" u-boot recipe (no patches)
>> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
>> 4) meta-ti has it's own u-boot recipe with per-machine patches
>>
>> A stated goal was to bring the Yocto Project's u-boot support for the
>> Beagleboard in line with that in meta-ti. There are several ways I can
>> go about this.
>>
>> a) create a bbappend in meta-yocto and duplicate the meta-ti
>>    modifications in bbappend form.
>> b) Modify the oe-core recipe directly
>>
>> While a) is the most direct approach to accomplish our goal, it requires
>> continual maintenance and duplicates effort. I don't care for this
>> approach. b) has the potential to consolidate all beagleboard u-boot
>> recipe work into a single place. It could simplify the meta-ti and
>> eliminate the need for a bbappend in the meta-yocto layer.
>>
>> The question of whether bootloaders have a place in oe-core should
>> probably be addressed. While they aren't needed for the emulated
>> machines, they are a highly reusable component for real systems, and
>> that seems justify keeping them in oe-core. Does anyone disagree with
>> this assessment?
>>
>> I propose pulling the necessary changes to u-boot from meta-ti into
>> oe-core. My initial scan suggested the beagleboard patches are mostly
>> contained to beagle specific source files. I would prefer to pull in all
>> the patches for all machines into the SRC_URI, rather than divide them
>> up by machine. This reduces complexity considerably. For the couple of
>> patches that collide, we would keep those as machine specific.
>>
>> As a final part of the work, I would include my beagleboard patch status
>> audit in the included patches and continue to work on reducing the
>> patches in the recipe for the beagleboard.
>>
>> Thoughts?
> 
> Well I am in similar boat where I wanted to build atom-pc for angstrom
> but I was thinking using meta-intel layer instead of pulling stuff out
> and stuffing it elsewhere and certainly not oe-core


I think the difference I'm seeing is that u-boot is a common recipe (it
exists in oe-core) and ideally it would track the upstream git
repository. If the recipe in oe-core is not intended to be used for any
real machines and isn't used as a base for bbappends in layers like
meta-ti (meta-ti has a complete uboot_git.bb), then it should just be
removed entirely.

I believe that there is value in not duplicating this recipe and
consolidating the modifications to it in a single place makes sense. The
fact that it needs so many non-upstream patches I think is something
that also needs to be addressed.

The second part is that we want to ensure the linux-yocto recipe and
kernel have complete support for the Beagleboard. This isn't something
we can do by just reusing a layer. The linux-yocto recipe takes a
different approach to managing BSP specific source and config changes. I
believe it reduces duplication of effort for things like bug fixing,
security fixes, and config fragment management.

Thanks,

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

Re: Updating u-boot for oe-core or meta-yocto

[Khem Raj]

On (24/05/11 11:23), Darren Hart wrote:
> On 05/24/2011 10:23 AM, Khem Raj wrote:
> > On (24/05/11 09:36), Darren Hart wrote:
> >> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> > 
> > why ? its a BSP recipe and bsp layer is best place for it IMO unless you
> > want to have some of those machines in a different layer.
> 
> 
> The underlying goal here is to improve the Beagleboard support in
> meta-yocto, without unnecessarily duplicating work. 

so essentially you are interested in maintaining this board in
meta-yocto and not use meta-ti as long as you have a process to sync
your changes in a sane manner between two layers I think it should be
ok. However we have to make clear if someone uses both meta-ti and meta-yocto
and he should be absolutely clear about what recipes and configurations
he/she ends up picking.

It was suggested at
> ELC that we modify the u-boot and linux-yocto recipes/sources to include
> the beagleboard specific changes from meta-ti. Once the boot loader and
> kernel were in place, we would look to using the still-under-discussion
> layer tooling to integrate the rest of meta-ti.
> 
> 
> > 
> >> doing so I've come across some questions I'd like you thoughts on.
> >> Specifically, where to put these changes. Some points of context:
> >>
> >> 1) oe-core is intended to support emulated machines only
> >> 2) oe-core has a "virgin" u-boot recipe (no patches)
> >> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
> >> 4) meta-ti has it's own u-boot recipe with per-machine patches
> >>
> >> A stated goal was to bring the Yocto Project's u-boot support for the
> >> Beagleboard in line with that in meta-ti. There are several ways I can
> >> go about this.
> >>
> >> a) create a bbappend in meta-yocto and duplicate the meta-ti
> >>    modifications in bbappend form.
> >> b) Modify the oe-core recipe directly
> >>
> >> While a) is the most direct approach to accomplish our goal, it requires
> >> continual maintenance and duplicates effort. I don't care for this
> >> approach. b) has the potential to consolidate all beagleboard u-boot
> >> recipe work into a single place. It could simplify the meta-ti and
> >> eliminate the need for a bbappend in the meta-yocto layer.
> >>
> >> The question of whether bootloaders have a place in oe-core should
> >> probably be addressed. While they aren't needed for the emulated
> >> machines, they are a highly reusable component for real systems, and
> >> that seems justify keeping them in oe-core. Does anyone disagree with
> >> this assessment?
> >>
> >> I propose pulling the necessary changes to u-boot from meta-ti into
> >> oe-core. My initial scan suggested the beagleboard patches are mostly
> >> contained to beagle specific source files. I would prefer to pull in all
> >> the patches for all machines into the SRC_URI, rather than divide them
> >> up by machine. This reduces complexity considerably. For the couple of
> >> patches that collide, we would keep those as machine specific.
> >>
> >> As a final part of the work, I would include my beagleboard patch status
> >> audit in the included patches and continue to work on reducing the
> >> patches in the recipe for the beagleboard.
> >>
> >> Thoughts?
> > 
> > Well I am in similar boat where I wanted to build atom-pc for angstrom
> > but I was thinking using meta-intel layer instead of pulling stuff out
> > and stuffing it elsewhere and certainly not oe-core
> 
> 
> I think the difference I'm seeing is that u-boot is a common recipe (it
> exists in oe-core) and ideally it would track the upstream git
> repository. If the recipe in oe-core is not intended to be used for any
> real machines and isn't used as a base for bbappends in layers like
> meta-ti (meta-ti has a complete uboot_git.bb), then it should just be
> removed entirely.


I would agree on removing them from oe-core yes

> 
> I believe that there is value in not duplicating this recipe and
> consolidating the modifications to it in a single place makes sense. The
> fact that it needs so many non-upstream patches I think is something
> that also needs to be addressed.

u-boot and any other bootloader for that matter are machine specific
and its very hard to have a common recipe serving needs of all machines

best it could do is abstract out common parts which wont be many in
u-boot case since it just have many differences so having it in bsp
layer is probably the best

> 
> The second part is that we want to ensure the linux-yocto recipe and
> kernel have complete support for the Beagleboard. This isn't something
> we can do by just reusing a layer. The linux-yocto recipe takes a
> different approach to managing BSP specific source and config changes. I
> believe it reduces duplication of effort for things like bug fixing,
> security fixes, and config fragment management.
> 

but linux-yocto have different recipes. Does it also cover u-boot ?
in oe-core we would be able to live without linux-yocto having
beagleboard support since oe-core it should only build qemu
machines

> Thanks,
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel

-- 
-Khem

Re: Updating u-boot for oe-core or meta-yocto

[Phil Blundell]

On Tue, 2011-05-24 at 11:35 -0700, Khem Raj wrote:
> so essentially you are interested in maintaining this board in
> meta-yocto and not use meta-ti as long as you have a process to sync
> your changes in a sane manner between two layers I think it should be
> ok. However we have to make clear if someone uses both meta-ti and meta-yocto
> and he should be absolutely clear about what recipes and configurations
> he/she ends up picking.

That should be fine, it'll be taken care of by the relative layer
priorities.  It doesn't sound as though this is any different to the
current situation with oe-core and meta-ti each having a different
u-boot recipe.

> u-boot and any other bootloader for that matter are machine specific
> and its very hard to have a common recipe serving needs of all machines
> 
> best it could do is abstract out common parts which wont be many in
> u-boot case since it just have many differences so having it in bsp
> layer is probably the best

Well, u-boot does have a unified upstream tree, and presumably that
works for at least some boards without major modification.  I can see
some merit in having that in oe-core for folks to use, either directly
or by patching. 

It is a bit of a shame that the necessary patches for beagleboard
haven't just been landed in u-boot upstream, since it sounds like this
would have avoided the whole issue.

p.

Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/24/2011 11:35 AM, Khem Raj wrote:
> On (24/05/11 11:23), Darren Hart wrote:
>> On 05/24/2011 10:23 AM, Khem Raj wrote:
>>> On (24/05/11 09:36), Darren Hart wrote:
>>>> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
>>>
>>> why ? its a BSP recipe and bsp layer is best place for it IMO unless you
>>> want to have some of those machines in a different layer.
>>
>>
>> The underlying goal here is to improve the Beagleboard support in
>> meta-yocto, without unnecessarily duplicating work. 
> 
> so essentially you are interested in maintaining this board in
> meta-yocto and not use meta-ti as long as you have a process to sync
> your changes in a sane manner between two layers I think it should be
> ok.


Ideally the only beagleboard specific recipe we would be linux-yocto*.
However, if there is objection to updating the oe-core u-boot recipe,
then we'll need to add u-boot to the list.


> However we have to make clear if someone uses both meta-ti and meta-yocto
> and he should be absolutely clear about what recipes and configurations
> he/she ends up picking.


Perhaps ensuring meta-ti layer priority is above that of meta-yocto
would be adequate? Not something I have tried yet.


> 
> It was suggested at
>> ELC that we modify the u-boot and linux-yocto recipes/sources to include
>> the beagleboard specific changes from meta-ti. Once the boot loader and
>> kernel were in place, we would look to using the still-under-discussion
>> layer tooling to integrate the rest of meta-ti.
>>
>>
>>>
>>>> doing so I've come across some questions I'd like you thoughts on.
>>>> Specifically, where to put these changes. Some points of context:
>>>>
>>>> 1) oe-core is intended to support emulated machines only
>>>> 2) oe-core has a "virgin" u-boot recipe (no patches)
>>>> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
>>>> 4) meta-ti has it's own u-boot recipe with per-machine patches
>>>>
>>>> A stated goal was to bring the Yocto Project's u-boot support for the
>>>> Beagleboard in line with that in meta-ti. There are several ways I can
>>>> go about this.
>>>>
>>>> a) create a bbappend in meta-yocto and duplicate the meta-ti
>>>>    modifications in bbappend form.
>>>> b) Modify the oe-core recipe directly
>>>>
>>>> While a) is the most direct approach to accomplish our goal, it requires
>>>> continual maintenance and duplicates effort. I don't care for this
>>>> approach. b) has the potential to consolidate all beagleboard u-boot
>>>> recipe work into a single place. It could simplify the meta-ti and
>>>> eliminate the need for a bbappend in the meta-yocto layer.
>>>>
>>>> The question of whether bootloaders have a place in oe-core should
>>>> probably be addressed. While they aren't needed for the emulated
>>>> machines, they are a highly reusable component for real systems, and
>>>> that seems justify keeping them in oe-core. Does anyone disagree with
>>>> this assessment?
>>>>
>>>> I propose pulling the necessary changes to u-boot from meta-ti into
>>>> oe-core. My initial scan suggested the beagleboard patches are mostly
>>>> contained to beagle specific source files. I would prefer to pull in all
>>>> the patches for all machines into the SRC_URI, rather than divide them
>>>> up by machine. This reduces complexity considerably. For the couple of
>>>> patches that collide, we would keep those as machine specific.
>>>>
>>>> As a final part of the work, I would include my beagleboard patch status
>>>> audit in the included patches and continue to work on reducing the
>>>> patches in the recipe for the beagleboard.
>>>>
>>>> Thoughts?
>>>
>>> Well I am in similar boat where I wanted to build atom-pc for angstrom
>>> but I was thinking using meta-intel layer instead of pulling stuff out
>>> and stuffing it elsewhere and certainly not oe-core
>>
>>
>> I think the difference I'm seeing is that u-boot is a common recipe (it
>> exists in oe-core) and ideally it would track the upstream git
>> repository. If the recipe in oe-core is not intended to be used for any
>> real machines and isn't used as a base for bbappends in layers like
>> meta-ti (meta-ti has a complete uboot_git.bb), then it should just be
>> removed entirely.
> 
> 
> I would agree on removing them from oe-core yes


I guess it comes down to the question of which is our priority:

1) Only including packages in support of emulated targets
2) Providing a common base which multiple layers can build from

I was under the impression that #2 took precedence. Am I wrong here?


>> I believe that there is value in not duplicating this recipe and
>> consolidating the modifications to it in a single place makes sense. The
>> fact that it needs so many non-upstream patches I think is something
>> that also needs to be addressed.
> 
> u-boot and any other bootloader for that matter are machine specific
> and its very hard to have a common recipe serving needs of all machines
> 
> best it could do is abstract out common parts which wont be many in
> u-boot case since it just have many differences so having it in bsp
> layer is probably the best


I confess to being relatively new to u-boot. That said, the current
2011.03 release builds and works on the beagleboard C4 and xM without
modification. The changes I was proposing to pull in are 1/3 upstream
already, some pending, and some not sent upstream yet. Some of these are
purely cosmetic, none are critical for basic functionality.

However, I haven't tried to use it with other boards, if I can't do that
without modifying it in such a way that breaks it for other boards, then
I would agree with you.


> 
>>
>> The second part is that we want to ensure the linux-yocto recipe and
>> kernel have complete support for the Beagleboard. This isn't something
>> we can do by just reusing a layer. The linux-yocto recipe takes a
>> different approach to managing BSP specific source and config changes. I
>> believe it reduces duplication of effort for things like bug fixing,
>> security fixes, and config fragment management.
>>
> 
> but linux-yocto have different recipes. Does it also cover u-boot ?
> in oe-core we would be able to live without linux-yocto having
> beagleboard support since oe-core it should only build qemu
> machines

It does not cover u-boot. In the strictest sense, we do not have
beagleboard support for linux-yocto in oe-core - because the machine is
not defined, so the kernel would never be configured and built for it -
but the bsp layers and meta data are present in the linux-yocto*.git
repository all the same.


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

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Tom Zanussi]

On Tue, 2011-05-24 at 13:07 -0500, Tom Zanussi wrote:
> On Tue, 2011-05-24 at 10:51 -0700, Koen Kooi wrote:
> > Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
> > 
> > > On (24/05/11 09:36), Darren Hart wrote:
> > >> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
> > > 
> > > why ? its a BSP recipe and bsp layer is best place for it IMO unless you
> > > want to have some of those machines in a different layer.
> > > 
> > >> doing so I've come across some questions I'd like you thoughts on.
> > >> Specifically, where to put these changes. Some points of context:
> > >> 
> > >> 1) oe-core is intended to support emulated machines only
> > >> 2) oe-core has a "virgin" u-boot recipe (no patches)
> > >> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
> > >> 4) meta-ti has it's own u-boot recipe with per-machine patches
> > >> 
> > >> A stated goal was to bring the Yocto Project's u-boot support for the
> > >> Beagleboard in line with that in meta-ti. There are several ways I can
> > >> go about this.
> > >> 
> > >> a) create a bbappend in meta-yocto and duplicate the meta-ti
> > >>   modifications in bbappend form.
> > >> b) Modify the oe-core recipe directly
> > >> 
> > >> While a) is the most direct approach to accomplish our goal, it requires
> > >> continual maintenance and duplicates effort. I don't care for this
> > >> approach. b) has the potential to consolidate all beagleboard u-boot
> > >> recipe work into a single place. It could simplify the meta-ti and
> > >> eliminate the need for a bbappend in the meta-yocto layer.
> > >> 
> > >> The question of whether bootloaders have a place in oe-core should
> > >> probably be addressed. While they aren't needed for the emulated
> > >> machines, they are a highly reusable component for real systems, and
> > >> that seems justify keeping them in oe-core. Does anyone disagree with
> > >> this assessment?
> > >> 
> > >> I propose pulling the necessary changes to u-boot from meta-ti into
> > >> oe-core. My initial scan suggested the beagleboard patches are mostly
> > >> contained to beagle specific source files. I would prefer to pull in all
> > >> the patches for all machines into the SRC_URI, rather than divide them
> > >> up by machine. This reduces complexity considerably. For the couple of
> > >> patches that collide, we would keep those as machine specific.
> > >> 
> > >> As a final part of the work, I would include my beagleboard patch status
> > >> audit in the included patches and continue to work on reducing the
> > >> patches in the recipe for the beagleboard.
> > >> 
> > >> Thoughts?
> > > 
> > > Well I am in similar boat where I wanted to build atom-pc for angstrom
> > > but I was thinking using meta-intel layer instead of pulling stuff out
> > > and stuffing it elsewhere and certainly not oe-core
> > 
> > Speaking of meta-intel layers, when I add them to bblayer.conf I get:
> > 
> > ERROR: Error parsing /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux/linux-yocto-stable_git.bb: Failure expanding variable FILESEXTRAPATHS, expression was ${FILESEXTRAPATHS}:/OE/tentacle/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-stable which triggered exception Exception: variable FILESEXTRAPATHS references itself!
> > 
> > Same for jasperforest, emenlow, fishriver and crownbay. The only intel layer I can add without breaking the parsing step is sugarbay :(
> > 
> 
> Must be something recent - I've built several of those successfully over
> the past few days, will take a look though...
> 

I just finished building all of the above successfully using the latest
(as of yesterday) poky/master and meta-intel/master.

Not sure why you're seeing parsing errors, none here...

Tom

> Tom
> 
> > Same goes for meta-xilinx, that breaks in the uboot recipe with some NoneType and string errors.
> > 
> > regards,
> > 
> > Koen
> > 
> 

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Koen Kooi]

Op 25 mei 2011, om 16:28 heeft Tom Zanussi het volgende geschreven:

> On Tue, 2011-05-24 at 13:07 -0500, Tom Zanussi wrote:
>> On Tue, 2011-05-24 at 10:51 -0700, Koen Kooi wrote:
>>> Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
>>> 
>>>> On (24/05/11 09:36), Darren Hart wrote:
>>>>> I've started pulling in the 15 or so patches to u-boot from meta-ti. In
>>>> 
>>>> why ? its a BSP recipe and bsp layer is best place for it IMO unless you
>>>> want to have some of those machines in a different layer.
>>>> 
>>>>> doing so I've come across some questions I'd like you thoughts on.
>>>>> Specifically, where to put these changes. Some points of context:
>>>>> 
>>>>> 1) oe-core is intended to support emulated machines only
>>>>> 2) oe-core has a "virgin" u-boot recipe (no patches)
>>>>> 3) meta-yocto does not have a u-boot recipe (no bbappend either)
>>>>> 4) meta-ti has it's own u-boot recipe with per-machine patches
>>>>> 
>>>>> A stated goal was to bring the Yocto Project's u-boot support for the
>>>>> Beagleboard in line with that in meta-ti. There are several ways I can
>>>>> go about this.
>>>>> 
>>>>> a) create a bbappend in meta-yocto and duplicate the meta-ti
>>>>>  modifications in bbappend form.
>>>>> b) Modify the oe-core recipe directly
>>>>> 
>>>>> While a) is the most direct approach to accomplish our goal, it requires
>>>>> continual maintenance and duplicates effort. I don't care for this
>>>>> approach. b) has the potential to consolidate all beagleboard u-boot
>>>>> recipe work into a single place. It could simplify the meta-ti and
>>>>> eliminate the need for a bbappend in the meta-yocto layer.
>>>>> 
>>>>> The question of whether bootloaders have a place in oe-core should
>>>>> probably be addressed. While they aren't needed for the emulated
>>>>> machines, they are a highly reusable component for real systems, and
>>>>> that seems justify keeping them in oe-core. Does anyone disagree with
>>>>> this assessment?
>>>>> 
>>>>> I propose pulling the necessary changes to u-boot from meta-ti into
>>>>> oe-core. My initial scan suggested the beagleboard patches are mostly
>>>>> contained to beagle specific source files. I would prefer to pull in all
>>>>> the patches for all machines into the SRC_URI, rather than divide them
>>>>> up by machine. This reduces complexity considerably. For the couple of
>>>>> patches that collide, we would keep those as machine specific.
>>>>> 
>>>>> As a final part of the work, I would include my beagleboard patch status
>>>>> audit in the included patches and continue to work on reducing the
>>>>> patches in the recipe for the beagleboard.
>>>>> 
>>>>> Thoughts?
>>>> 
>>>> Well I am in similar boat where I wanted to build atom-pc for angstrom
>>>> but I was thinking using meta-intel layer instead of pulling stuff out
>>>> and stuffing it elsewhere and certainly not oe-core
>>> 
>>> Speaking of meta-intel layers, when I add them to bblayer.conf I get:
>>> 
>>> ERROR: Error parsing /OE/tentacle/sources/openembedded-core/meta/recipes-kernel/linux/linux-yocto-stable_git.bb: Failure expanding variable FILESEXTRAPATHS, expression was ${FILESEXTRAPATHS}:/OE/tentacle/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-stable which triggered exception Exception: variable FILESEXTRAPATHS references itself!
>>> 
>>> Same for jasperforest, emenlow, fishriver and crownbay. The only intel layer I can add without breaking the parsing step is sugarbay :(
>>> 
>> 
>> Must be something recent - I've built several of those successfully over
>> the past few days, will take a look though...
>> 
> 
> I just finished building all of the above successfully using the latest
> (as of yesterday) poky/master and meta-intel/master.
> 
> Not sure why you're seeing parsing errors, none here...

Did you add all the layers to bblayers.conf? Having one isn't a problem, but adding them all seems to trigger the bug.

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Phil Blundell]

On Wed, 2011-05-25 at 09:28 -0500, Tom Zanussi wrote:
> I just finished building all of the above successfully using the latest
> (as of yesterday) poky/master and meta-intel/master.
> 
> Not sure why you're seeing parsing errors, none here...

The way meta-intel is using FILESEXTRAPATHS does look a bit dubious to
me.  Your kernel .bbappend files seem to be doing:

FILESEXTRAPATHS := "${FILESEXTRAPATHS}:${THISDIR}/${PN}"

which seems wrong for two reasons: firstly it will lose if
FILESEXTRAPATHS wasn't previously set (in which case you'll get a
circular reference within the value, since bitbake won't expand that
part of the rvalue during the assignment); and secondly, as far as I can
tell from looking at utils.bbclass, FILESEXTRAPATHS isn't actually
supposed to be colon separated in the first place.

(Also, as a tangential matter, this FILESEXTRAPATHS setting isn't going
to be producing any useful effect since none of the meta-intel layers
actually have any files in their recipes-kernel/linux directory.)

p.

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Tom Zanussi]

On Wed, 2011-05-25 at 07:38 -0700, Phil Blundell wrote:
> On Wed, 2011-05-25 at 09:28 -0500, Tom Zanussi wrote:
> > I just finished building all of the above successfully using the latest
> > (as of yesterday) poky/master and meta-intel/master.
> > 
> > Not sure why you're seeing parsing errors, none here...
> 
> The way meta-intel is using FILESEXTRAPATHS does look a bit dubious to
> me.  Your kernel .bbappend files seem to be doing:
> 
> FILESEXTRAPATHS := "${FILESEXTRAPATHS}:${THISDIR}/${PN}"
> 
> which seems wrong for two reasons: firstly it will lose if
> FILESEXTRAPATHS wasn't previously set (in which case you'll get a
> circular reference within the value, since bitbake won't expand that
> part of the rvalue during the assignment); and secondly, as far as I can
> tell from looking at utils.bbclass, FILESEXTRAPATHS isn't actually
> supposed to be colon separated in the first place.
> 
> (Also, as a tangential matter, this FILESEXTRAPATHS setting isn't going
> to be producing any useful effect since none of the meta-intel layers
> actually have any files in their recipes-kernel/linux directory.)
> 

Yeah, that was a recent change attempting to fix a different problem.  I
need to take a better look at both...

Thanks for your detailed comments.

Tom

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Updating u-boot for oe-core or meta-yocto

[Richard Purdie]

I did a little research and I'd like to try and help us move forward.

The "problem" at the moment is both oe-core and meta-ti have u-boot
recipes. If Yocto were to merge in the meta-ti recipe to meta-yocto it
would overshadow the oe-core recipe. I believe Yocto wants to encourage
sharing a core on codebases like u-boot which are receptive and working
to facilitate collaboration (not unlike Yocto itself).

Valid questions are therefore:

a) What can we do to the u-boot recipe in core to make it customisable
from layers like meta-ti

b) Is it possible for the u-boot recipe in meta-ti to be a .bbappend
rather than a recipe which overwrites the default.

For a), I know Darren has some patches which drop the COMPATIBLE_MACHINE
usage for example and instead raise the skip parsing exception when
UBOOT_MACHINE isn't set which is a step in the right direction. If we
find other issues, lets fix them.

For b), I talked to Koen and he's going to see how feasible this is
although as always with this kind of issue there are various
complicating factors.

Hopefully if we work both sides of the problem we can get this resolved.
Darren, if you could send out some of your patches so far (e.g. for
COMPATIBLE_MACHINE) that might be helpful.

If the ultimate answer is that no, meta-ti has so many changes or
specific requirements that mean it needs to stay a .bb file then lets
cross that bridge if we come to it but I think this discussion makes
sense before reaching that conclusion. Its possible the last release of
u-boot has sufficient beagle support for yocto's needs and we could use
that instead.

Just on a more general note, the agreement on resolving the beagleboard
issue stands as is. The plan is to make beagleboard support in
meta-yocto as near a copy of the meta-ti pieces as possible with the
exception of the kernel where linux-yocto will import the needed patches
to demo the kernel tooling functionality. The layer tooling under
development will automate the process of syncing those pieces. I think
everyone is happy with the agreement and we just need to address some
corner cases like u-boot.

Cheers,

Richard

Re: Updating u-boot for oe-core or meta-yocto

[Khem Raj]

On Wed, May 25, 2011 at 8:51 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I did a little research and I'd like to try and help us move forward.
>
> The "problem" at the moment is both oe-core and meta-ti have u-boot
> recipes. If Yocto were to merge in the meta-ti recipe to meta-yocto it
> would overshadow the oe-core recipe. I believe Yocto wants to encourage
> sharing a core on codebases like u-boot which are receptive and working
> to facilitate collaboration (not unlike Yocto itself).
>
> Valid questions are therefore:
>
> a) What can we do to the u-boot recipe in core to make it customisable
> from layers like meta-ti
>
> b) Is it possible for the u-boot recipe in meta-ti to be a .bbappend
> rather than a recipe which overwrites the default.
>
> For a), I know Darren has some patches which drop the COMPATIBLE_MACHINE
> usage for example and instead raise the skip parsing exception when
> UBOOT_MACHINE isn't set which is a step in the right direction. If we
> find other issues, lets fix them.
>
> For b), I talked to Koen and he's going to see how feasible this is
> although as always with this kind of issue there are various
> complicating factors.
>
> Hopefully if we work both sides of the problem we can get this resolved.
> Darren, if you could send out some of your patches so far (e.g. for
> COMPATIBLE_MACHINE) that might be helpful.
>
> If the ultimate answer is that no, meta-ti has so many changes or
> specific requirements that mean it needs to stay a .bb file then lets
> cross that bridge if we come to it but I think this discussion makes
> sense before reaching that conclusion. Its possible the last release of
> u-boot has sufficient beagle support for yocto's needs and we could use
> that instead.
>
> Just on a more general note, the agreement on resolving the beagleboard
> issue stands as is. The plan is to make beagleboard support in
> meta-yocto as near a copy of the meta-ti pieces as possible with the
> exception of the kernel where linux-yocto will import the needed patches
> to demo the kernel tooling functionality. The layer tooling under
> development will automate the process of syncing those pieces. I think
> everyone is happy with the agreement and we just need to address some
> corner cases like u-boot.
>

so is it just a question of beagleboard support or a broader support
for all machines ?
I know various boards use very different versions
of u-boot so is oe-core going to bring that support
to u-boot in oe-core and maintain that ?

IMO keeping oe-core relatively free of machine dependent stuff would be better.

Re: Updating u-boot for oe-core or meta-yocto

[Henning Heinold]

Hi,

I agree with khem, each machine should maintain it's bootloader in his bsp
or layer.

Bye Henning

Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/25/2011 09:49 AM, Henning Heinold wrote:
> Hi,
> 
> I agree with khem, each machine should maintain it's bootloader in his bsp
> or layer.

I'm leaning this way as well. I think oe-core should remain at an
official u-boot tagged release, like 2011.03 and layers can then extend
that with a proper .bbappend file. Then we can share the u-boot core
recipe and just add backported patches in the layers as needed.

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

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/25/2011 07:38 AM, Phil Blundell wrote:
> On Wed, 2011-05-25 at 09:28 -0500, Tom Zanussi wrote:
>> I just finished building all of the above successfully using the latest
>> (as of yesterday) poky/master and meta-intel/master.
>>
>> Not sure why you're seeing parsing errors, none here...
> 
> The way meta-intel is using FILESEXTRAPATHS does look a bit dubious to
> me.  Your kernel .bbappend files seem to be doing:
> 
> FILESEXTRAPATHS := "${FILESEXTRAPATHS}:${THISDIR}/${PN}"
> 
> which seems wrong for two reasons: firstly it will lose if
> FILESEXTRAPATHS wasn't previously set (in which case you'll get a
> circular reference within the value, since bitbake won't expand that
> part of the rvalue during the assignment);

So the reason I had made this change was to allow for multiple layers to
aggregate their bbappends. As it was previously, the meta-intel layer
prevented other layers from working by clobbering the FILESEXTRAPATHS
rather than appending to it.

> and secondly, as far as I can
> tell from looking at utils.bbclass, FILESEXTRAPATHS isn't actually
> supposed to be colon separated in the first place.

Doh. My original patch was space separated and someone suggested colons
and I didn't see a build failure in my testing so I left it. Bad testing
methodology apparently.

If it is indeed space separated then I should be able to remedy both
issues by simply using the append operator and not self-referencing.
Correct?

> 
> (Also, as a tangential matter, this FILESEXTRAPATHS setting isn't going
> to be producing any useful effect since none of the meta-intel layers
> actually have any files in their recipes-kernel/linux directory.)

We do want it in place so these can be easily added for development
purposes, even though the ultimate goal would be to include such changes
in the kernel source repository.

> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Phil Blundell]

On Wed, 2011-05-25 at 11:56 -0700, Darren Hart wrote:
> If it is indeed space separated then I should be able to remedy both
> issues by simply using the append operator and not self-referencing.
> Correct?

I think that's true, yes.  But, space separation is fairly undesirable
for anything involving paths (particularly absolute ones) and it is
tempting to say that we should change that variable to have a different
separator. 

p.

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/25/2011 12:11 PM, Phil Blundell wrote:
> On Wed, 2011-05-25 at 11:56 -0700, Darren Hart wrote:
>> If it is indeed space separated then I should be able to remedy both
>> issues by simply using the append operator and not self-referencing.
>> Correct?
> 
> I think that's true, yes.  But, space separation is fairly undesirable
> for anything involving paths (particularly absolute ones) and it is
> tempting to say that we should change that variable to have a different
> separator. 
> 

The only example I see of concatenating this variable is a prepend which
uses colons. RP also mentioned he was pretty sure it should be colons.
I'll figure it out for certain and fix the path assignments in meta-intel.


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

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Richard Purdie]

On Wed, 2011-05-25 at 13:04 -0700, Darren Hart wrote:
> 
> On 05/25/2011 12:11 PM, Phil Blundell wrote:
> > On Wed, 2011-05-25 at 11:56 -0700, Darren Hart wrote:
> >> If it is indeed space separated then I should be able to remedy both
> >> issues by simply using the append operator and not self-referencing.
> >> Correct?
> > 
> > I think that's true, yes.  But, space separation is fairly undesirable
> > for anything involving paths (particularly absolute ones) and it is
> > tempting to say that we should change that variable to have a different
> > separator. 
> > 
> 
> The only example I see of concatenating this variable is a prepend which
> uses colons. RP also mentioned he was pretty sure it should be colons.
> I'll figure it out for certain and fix the path assignments in meta-intel.

I checked the code and it is currently setup to use spaces but all the
users I've seen use colons.

There is significant precedent for *PATH* variables (FILESPATH, BBPATH,
PATH) being colon delimited so I'm tempted to say the utils.bbclass code
handling this should be fixed for EXTRAFILESPATH.

Also, the self referencing of that variable is correct. What is missing
is a default value for it, again that needs fixing in the core...

Cheers,

Richard



 

Re: Updating u-boot for oe-core or meta-yocto

[Richard Purdie]

On Wed, 2011-05-25 at 09:36 -0700, Khem Raj wrote:
> On Wed, May 25, 2011 at 8:51 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > I did a little research and I'd like to try and help us move forward.
> >
> > The "problem" at the moment is both oe-core and meta-ti have u-boot
> > recipes. If Yocto were to merge in the meta-ti recipe to meta-yocto it
> > would overshadow the oe-core recipe. I believe Yocto wants to encourage
> > sharing a core on codebases like u-boot which are receptive and working
> > to facilitate collaboration (not unlike Yocto itself).
> >
> > Valid questions are therefore:
> >
> > a) What can we do to the u-boot recipe in core to make it customisable
> > from layers like meta-ti
> >
> > b) Is it possible for the u-boot recipe in meta-ti to be a .bbappend
> > rather than a recipe which overwrites the default.
> >
> > For a), I know Darren has some patches which drop the COMPATIBLE_MACHINE
> > usage for example and instead raise the skip parsing exception when
> > UBOOT_MACHINE isn't set which is a step in the right direction. If we
> > find other issues, lets fix them.
> >
> > For b), I talked to Koen and he's going to see how feasible this is
> > although as always with this kind of issue there are various
> > complicating factors.
> >
> > Hopefully if we work both sides of the problem we can get this resolved.
> > Darren, if you could send out some of your patches so far (e.g. for
> > COMPATIBLE_MACHINE) that might be helpful.
> >
> > If the ultimate answer is that no, meta-ti has so many changes or
> > specific requirements that mean it needs to stay a .bb file then lets
> > cross that bridge if we come to it but I think this discussion makes
> > sense before reaching that conclusion. Its possible the last release of
> > u-boot has sufficient beagle support for yocto's needs and we could use
> > that instead.
> >
> > Just on a more general note, the agreement on resolving the beagleboard
> > issue stands as is. The plan is to make beagleboard support in
> > meta-yocto as near a copy of the meta-ti pieces as possible with the
> > exception of the kernel where linux-yocto will import the needed patches
> > to demo the kernel tooling functionality. The layer tooling under
> > development will automate the process of syncing those pieces. I think
> > everyone is happy with the agreement and we just need to address some
> > corner cases like u-boot.
> >
> 
> so is it just a question of beagleboard support or a broader support
> for all machines ?

I'm hoping there are some machines out there which have merged support
into the upstream so simply setting UBOOT_MACHINE = "xxx" in the machine
config file is enough to get them working.

Basing the system on the premise that every bootloader needs to be
custom isn't really where we want to be :/.

> I know various boards use very different versions
> of u-boot so is oe-core going to bring that support
> to u-boot in oe-core and maintain that ?

No, the idea would be to make it easy to add missing pieces in
a .bbappend though.

> IMO keeping oe-core relatively free of machine dependent stuff would be better.

I'm still in agreement with this.

Cheers,

Richard

Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/25/2011 02:31 PM, Richard Purdie wrote:
> On Wed, 2011-05-25 at 13:04 -0700, Darren Hart wrote:
>>
>> On 05/25/2011 12:11 PM, Phil Blundell wrote:
>>> On Wed, 2011-05-25 at 11:56 -0700, Darren Hart wrote:
>>>> If it is indeed space separated then I should be able to remedy both
>>>> issues by simply using the append operator and not self-referencing.
>>>> Correct?
>>>
>>> I think that's true, yes.  But, space separation is fairly undesirable
>>> for anything involving paths (particularly absolute ones) and it is
>>> tempting to say that we should change that variable to have a different
>>> separator. 
>>>
>>
>> The only example I see of concatenating this variable is a prepend which
>> uses colons. RP also mentioned he was pretty sure it should be colons.
>> I'll figure it out for certain and fix the path assignments in meta-intel.
> 
> I checked the code and it is currently setup to use spaces but all the
> users I've seen use colons.
> 
> There is significant precedent for *PATH* variables (FILESPATH, BBPATH,
> PATH) being colon delimited so I'm tempted to say the utils.bbclass code
> handling this should be fixed for EXTRAFILESPATH.
> 
> Also, the self referencing of that variable is correct. What is missing
> is a default value for it, again that needs fixing in the core...

I've sent a patch that I believe works.
http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/003145.html

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

Re: Updating u-boot for oe-core or meta-yocto

[Jason Kridner]

This thread got pretty long pretty fast, but I am imagining there is some
place still here for me to chime in and build my own understanding of what
we are doing...

On Wed, May 25, 2011 at 5:51 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2011-05-25 at 09:36 -0700, Khem Raj wrote:
> > On Wed, May 25, 2011 at 8:51 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > I did a little research and I'd like to try and help us move forward.
> > >
> > > The "problem" at the moment is both oe-core and meta-ti have u-boot
> > > recipes. If Yocto were to merge in the meta-ti recipe to meta-yocto it
> > > would overshadow the oe-core recipe. I believe Yocto wants to encourage
> > > sharing a core on codebases like u-boot which are receptive and working
> > > to facilitate collaboration (not unlike Yocto itself).
>

I like the bootloader living in the BSP layer, but if the mainline recipe is
something we can all build upon in a reasonable fashion, I can see value in
having it in oe-core.  It would seem an ugly duplicate to put it in
meta-yocto and I'm still quite confused on what is meant to live there.
What is done across the other ISAs?  Are they all living in meta-yocto or do
they pull in from their own BSP layers?

> >
> > > Valid questions are therefore:
> > >
> > > a) What can we do to the u-boot recipe in core to make it customisable
> > > from layers like meta-ti
>

To confirm, this means that building Yocto for BeagleBoard including meta-ti
is *not* an issue outside of the conflicting recipes?  This was something
we'd have needed to resolve anyway, no?


> > >
> > > b) Is it possible for the u-boot recipe in meta-ti to be a .bbappend
> > > rather than a recipe which overwrites the default.
>

You said this recipe is an unpatched mainline, correct?  Creating BSPs with
.bbappend on top of mainline recipes in oe-core seems like a nice approach
from my perspective.  Is that what is being suggested here?  Will all 4
non-qemu BSPs in Yocto's core validation take this approach?


> > >
> > > For a), I know Darren has some patches which drop the
> COMPATIBLE_MACHINE
> > > usage for example and instead raise the skip parsing exception when
> > > UBOOT_MACHINE isn't set which is a step in the right direction. If we
> > > find other issues, lets fix them.
> > >
> > > For b), I talked to Koen and he's going to see how feasible this is
> > > although as always with this kind of issue there are various
> > > complicating factors.
>
> >
> > > Hopefully if we work both sides of the problem we can get this
> resolved.
> > > Darren, if you could send out some of your patches so far (e.g. for
> > > COMPATIBLE_MACHINE) that might be helpful.
> > >
> > > If the ultimate answer is that no, meta-ti has so many changes or
> > > specific requirements that mean it needs to stay a .bb file then lets
> > > cross that bridge if we come to it but I think this discussion makes
> > > sense before reaching that conclusion. Its possible the last release of
> > > u-boot has sufficient beagle support for yocto's needs and we could use
> > > that instead.
>

The mainline u-boot works pretty well for Beagle, as Darren has confirmed,
but I think there are a few useful patches as part of the validation image
for BeagleBoard that have yet to make it upstream due to their platform
specificity.  I am working those as I have time, but I think it is
reasonable to have an approach BSP-specific patches temporarily, no?  I'd
hate to get in a situation where we cannot produce the BeagleBoard
experience that we want.


> > >
> > > Just on a more general note, the agreement on resolving the beagleboard
> > > issue stands as is. The plan is to make beagleboard support in
> > > meta-yocto as near a copy of the meta-ti pieces as possible with the
> > > exception of the kernel where linux-yocto will import the needed
> patches
> > > to demo the kernel tooling functionality. The layer tooling under
> > > development will automate the process of syncing those pieces. I think
> > > everyone is happy with the agreement and we just need to address some
> > > corner cases like u-boot.
> > >
> >
> > so is it just a question of beagleboard support or a broader support
> > for all machines ?
>
> I'm hoping there are some machines out there which have merged support
> into the upstream so simply setting UBOOT_MACHINE = "xxx" in the machine
> config file is enough to get them working.
>

I've used mainline with the BeagleBoard, but I'd prefer if we kept control
over the experience on our platforms and welcome regular encouragement to
eliminate patches.


>
> Basing the system on the premise that every bootloader needs to be
> custom isn't really where we want to be :/.
>

Agreed, but what is "the system" in this respect?  I believe "the system" is
meant to simplify creation of BSPs for every new platform under the sun, so
having a way to work with these customizations seems to be a critical part
of what the system should be.  That said, I take it seriously that after all
this time there are still out-of-tree patches to u-boot that we are using to
support the BeagleBoard and that needs to be resolved ASAP.


>
> > I know various boards use very different versions
> > of u-boot so is oe-core going to bring that support
> > to u-boot in oe-core and maintain that ?
>
> No, the idea would be to make it easy to add missing pieces in
> a .bbappend though.
>
> > IMO keeping oe-core relatively free of machine dependent stuff would be
> better.
>
> I'm still in agreement with this.
>

What confuses me is that this seemed more directed at using meta-yocto or
meta-ti for support of the BeagleBoard, not if we wanted to put
board-dependent stuff in oe-core where I think we all agreed we want to keep
it clean of machine dependent stuff, unless I missed something.  I still
wonder if BeagleBoard doesn't belong in a less vendor-specific repository to
make sure that community developers can adjust it as necessary outside of
TI.  Though, as long as Koen is happy with it living in meta-ti for
Angstrom, it seems suitable to me.


>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: Updating u-boot for oe-core or meta-yocto

[Anders Darander]

On Wed, May 25, 2011 at 20:40, Darren Hart <dvhart@linux.intel.com> wrote:
> On 05/25/2011 09:49 AM, Henning Heinold wrote:
>> I agree with khem, each machine should maintain it's bootloader in his bsp
>> or layer.
>
> I'm leaning this way as well. I think oe-core should remain at an
> official u-boot tagged release, like 2011.03 and layers can then extend
> that with a proper .bbappend file. Then we can share the u-boot core
> recipe and just add backported patches in the layers as needed.

This definitely seems like the best solution.

BSP specific patches and modifications can normally easily be handled
in a .bbappend file. Together with the suggestion in another e-mail
(or even thread) to keep one old u-boot version around in oe-core, to
ease the transition to a new version in the BSP layers, this should be
no real problem.

If a machine for some reason needs a specific custom version, then it
might be necessary for that particular BSP layer to carry a complete
u-boot recipe. But this shouldn't be a common situation. (And if it
happens frequently, then the machine specific patches really has to be
submitted to upstream u-boot.).

Regards,
Anders

-- 
Anders Darander

Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

On 05/25/2011 11:12 PM, Anders Darander wrote:
> On Wed, May 25, 2011 at 20:40, Darren Hart <dvhart@linux.intel.com> wrote:
>> On 05/25/2011 09:49 AM, Henning Heinold wrote:
>>> I agree with khem, each machine should maintain it's bootloader in his bsp
>>> or layer.
>>
>> I'm leaning this way as well. I think oe-core should remain at an
>> official u-boot tagged release, like 2011.03 and layers can then extend
>> that with a proper .bbappend file. Then we can share the u-boot core
>> recipe and just add backported patches in the layers as needed.
> 
> This definitely seems like the best solution.
> 
> BSP specific patches and modifications can normally easily be handled
> in a .bbappend file. Together with the suggestion in another e-mail
> (or even thread) to keep one old u-boot version around in oe-core, to
> ease the transition to a new version in the BSP layers, this should be
> no real problem.
> 
> If a machine for some reason needs a specific custom version, then it
> might be necessary for that particular BSP layer to carry a complete
> u-boot recipe.

Even then they should usually be able to just override the SRCREV. But
yes, I agree.

> But this shouldn't be a common situation. (And if it
> happens frequently, then the machine specific patches really has to be
> submitted to upstream u-boot.).




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

Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart]

Hi Jason,

On 05/25/2011 04:31 PM, Jason Kridner wrote:
> This thread got pretty long pretty fast, but I am imagining there is some
> place still here for me to chime in and build my own understanding of what
> we are doing...

Of course, thanks for the input...

> 
> On Wed, May 25, 2011 at 5:51 PM, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
> 
>> On Wed, 2011-05-25 at 09:36 -0700, Khem Raj wrote:
>>> On Wed, May 25, 2011 at 8:51 AM, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>> I did a little research and I'd like to try and help us move forward.
>>>>
>>>> The "problem" at the moment is both oe-core and meta-ti have u-boot
>>>> recipes. If Yocto were to merge in the meta-ti recipe to meta-yocto it
>>>> would overshadow the oe-core recipe. I believe Yocto wants to encourage
>>>> sharing a core on codebases like u-boot which are receptive and working
>>>> to facilitate collaboration (not unlike Yocto itself).
>>
> 
> I like the bootloader living in the BSP layer, but if the mainline recipe is
> something we can all build upon in a reasonable fashion, I can see value in
> having it in oe-core.  It would seem an ugly duplicate to put it in
> meta-yocto and I'm still quite confused on what is meant to live there.
> What is done across the other ISAs?  Are they all living in meta-yocto or do
> they pull in from their own BSP layers?


AFAIK, meta-yocto should only contain support for 4 example hardware
platforms, one for each architecure (arm, mips, ppc, x86). What we're
running into here, I think, is that the board we've selected for arm
also has a mature BSP in meta-ti.


>>>
>>>> Valid questions are therefore:
>>>>
>>>> a) What can we do to the u-boot recipe in core to make it customisable
>>>> from layers like meta-ti
>>
> 
> To confirm, this means that building Yocto for BeagleBoard including meta-ti
> is *not* an issue outside of the conflicting recipes?  This was something
> we'd have needed to resolve anyway, no?


My current thinking on this is that for meta-yocto we want to have a
reasonably functional self-contained example BSP for ARM. Beagleboard
was the board selected for that. meta-yocto should be able to build the
core-image-* images and have them work on Beagleboard without needing to
pull in the meta-ti layer.

For additional Beagleboard support and perhaps more state-of-the-art
features, people looking to develop for the Beagleboard should also
include the meta-ti layer.

Having said this, I'm leaning toward just using the oe-core virgin uboot
recipe in meta-yocto as it is adequate to boot the Beagleboard. Then the
meta-ti layer provides the backports that provide some polish and usability.

Does anyone disagree with my thinking outlined here?


> 
> 
>>>>
>>>> b) Is it possible for the u-boot recipe in meta-ti to be a .bbappend
>>>> rather than a recipe which overwrites the default.
>>
> 
> You said this recipe is an unpatched mainline, correct?  Creating BSPs with
> .bbappend on top of mainline recipes in oe-core seems like a nice approach
> from my perspective.  Is that what is being suggested here?  Will all 4
> non-qemu BSPs in Yocto's core validation take this approach?


Currently Beagleboard is the only one that uses u-boot. The MPC8315E
could use it... but we're "having technical difficulties" with that at
the moment, so we're using the factory u-boot for the time being. Once
that is resolved, my goal would be for both Beagleboard and the MPC8315
to boot using a stock u-boot if at all possible.


> 
> 
>>>>
>>>> For a), I know Darren has some patches which drop the
>> COMPATIBLE_MACHINE
>>>> usage for example and instead raise the skip parsing exception when
>>>> UBOOT_MACHINE isn't set which is a step in the right direction. If we
>>>> find other issues, lets fix them.
>>>>
>>>> For b), I talked to Koen and he's going to see how feasible this is
>>>> although as always with this kind of issue there are various
>>>> complicating factors.
>>
>>>
>>>> Hopefully if we work both sides of the problem we can get this
>> resolved.
>>>> Darren, if you could send out some of your patches so far (e.g. for
>>>> COMPATIBLE_MACHINE) that might be helpful.
>>>>
>>>> If the ultimate answer is that no, meta-ti has so many changes or
>>>> specific requirements that mean it needs to stay a .bb file then lets
>>>> cross that bridge if we come to it but I think this discussion makes
>>>> sense before reaching that conclusion. Its possible the last release of
>>>> u-boot has sufficient beagle support for yocto's needs and we could use
>>>> that instead.
>>
> 
> The mainline u-boot works pretty well for Beagle, as Darren has confirmed,
> but I think there are a few useful patches as part of the validation image
> for BeagleBoard that have yet to make it upstream due to their platform
> specificity.  I am working those as I have time, but I think it is
> reasonable to have an approach BSP-specific patches temporarily, no?


Agreed.


>  I'd
> hate to get in a situation where we cannot produce the BeagleBoard
> experience that we want.


I think this is consistent with my approach outlined above, meta-yocto
uses oe-core's recipe for a functional bootloader and meta-ti improves
upon that experience via a bbappend.


>>>>
>>>> Just on a more general note, the agreement on resolving the beagleboard
>>>> issue stands as is. The plan is to make beagleboard support in
>>>> meta-yocto as near a copy of the meta-ti pieces as possible with the
>>>> exception of the kernel where linux-yocto will import the needed
>> patches
>>>> to demo the kernel tooling functionality. The layer tooling under
>>>> development will automate the process of syncing those pieces. I think
>>>> everyone is happy with the agreement and we just need to address some
>>>> corner cases like u-boot.
>>>>
>>>
>>> so is it just a question of beagleboard support or a broader support
>>> for all machines ?
>>
>> I'm hoping there are some machines out there which have merged support
>> into the upstream so simply setting UBOOT_MACHINE = "xxx" in the machine
>> config file is enough to get them working.
>>
> 
> I've used mainline with the BeagleBoard, but I'd prefer if we kept control
> over the experience on our platforms and welcome regular encouragement to
> eliminate patches.


nod


>>
>> Basing the system on the premise that every bootloader needs to be
>> custom isn't really where we want to be :/.
>>
> 
> Agreed, but what is "the system" in this respect?  I believe "the system" is
> meant to simplify creation of BSPs for every new platform under the sun, so
> having a way to work with these customizations seems to be a critical part
> of what the system should be.  That said, I take it seriously that after all
> this time there are still out-of-tree patches to u-boot that we are using to
> support the BeagleBoard and that needs to be resolved ASAP.
> 
> 
>>
>>> I know various boards use very different versions
>>> of u-boot so is oe-core going to bring that support
>>> to u-boot in oe-core and maintain that ?
>>
>> No, the idea would be to make it easy to add missing pieces in
>> a .bbappend though.
>>
>>> IMO keeping oe-core relatively free of machine dependent stuff would be
>> better.
>>
>> I'm still in agreement with this.
>>
> 
> What confuses me is that this seemed more directed at using meta-yocto or
> meta-ti for support of the BeagleBoard, not if we wanted to put
> board-dependent stuff in oe-core where I think we all agreed we want to keep
> it clean of machine dependent stuff, unless I missed something.  I still
> wonder if BeagleBoard doesn't belong in a less vendor-specific repository to
> make sure that community developers can adjust it as necessary outside of
> TI.  Though, as long as Koen is happy with it living in meta-ti for
> Angstrom, it seems suitable to me.


I've sent an initial set of u-boot recipe patches that work toward the
approach I've described above. I'll address the points raised and send
out V2 soon.

Thanks!

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

Re: Updating u-boot for oe-core or meta-yocto

[Anders Darander]

On Thu, May 26, 2011 at 20:07, Darren Hart <dvhart@linux.intel.com> wrote:
> My current thinking on this is that for meta-yocto we want to have a
> reasonably functional self-contained example BSP for ARM. Beagleboard
> was the board selected for that. meta-yocto should be able to build the
> core-image-* images and have them work on Beagleboard without needing to
> pull in the meta-ti layer.

Sounds like a good idea (and one that has been previously agreed upon,
as I understand it). It's always good with a self-contained example
BSP in meta-yocto.

> For additional Beagleboard support and perhaps more state-of-the-art
> features, people looking to develop for the Beagleboard should also
> include the meta-ti layer.
>
> Having said this, I'm leaning toward just using the oe-core virgin uboot
> recipe in meta-yocto as it is adequate to boot the Beagleboard. Then the
> meta-ti layer provides the backports that provide some polish and usability.
>
> Does anyone disagree with my thinking outlined here?

No, you have my vote for this.

Doing it this way will, in my opinion, reduce the u-boot .bbappend's
in the BSP layer as much as possible. In most cases the bbappends
needed should just be patches with some extra features and configs.

Regards,
Anders