Updating u-boot for oe-core or meta-yocto
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?
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Op 24 mei 2011, om 18:36 heeft Darren Hart het volgende geschreven:
Quoted 9 lines
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
Quoted 7 lines
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.
Quoted 7 lines
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.
Quoted 8 lines
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.
Quoted 1 line · Darren Hart
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.
Quoted 35 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
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
Quoted 10 lines
Signature · 9 lines
-- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
-Khem
Quoted 9 lines · 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
Quoted 7 lines
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.
Quoted 34 lines
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?
Signature · 8 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto
In reply to Khem RajOp 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
Quoted 45 lines · Darren Hart
Quoted 1 line
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.
Quoted 39 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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
Quoted 17 lines · Koen Kooi
Op 24 mei 2011, om 18:36 heeft Darren Hart het volgende geschreven:
Quoted 14 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 14 lines
Quoted 14 lines
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?
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Signature · 3 lines
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
In reply to Koen KooiQuoted 53 lines · Koen Kooi
Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
Quoted 45 lines · Darren Hart
Quoted 1 line
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.
Quoted 39 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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
Quoted 6 lines
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
Quoted 6 lines
Same goes for meta-xilinx, that breaks in the uboot recipe with some NoneType and string errors.
regards,
Koen
Quoted 5 lines · Khem Raj
Quoted 1 line · Darren Hart
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.
Quoted 40 lines
Quoted 40 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 10 lines · Darren Hart
Quoted 5 lines · Khem Raj
Quoted 1 line · Darren Hart
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
Quoted 53 lines
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.
Quoted 40 lines
Quoted 40 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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
Quoted 6 lines
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
Quoted 5 lines
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
Quoted 8 lines
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
Quoted 6 lines
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Signature · 1 line
-Khem
Quoted 6 lines · Khem Raj
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.
Quoted 6 lines
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.
Quoted 9 lines · Khem Raj
Quoted 8 lines · Darren Hart
Quoted 5 lines · Khem Raj
Quoted 1 line · Darren Hart
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 63 lines
It was suggested at
Quoted 53 lines
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.
Quoted 40 lines
Quoted 40 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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
Quoted 6 lines
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.
Quoted 1 line
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?
Quoted 11 lines
Quoted 4 lines
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.
Quoted 10 lines
Quoted 9 lines
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.
Quoted 4 lines
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.
Signature · 3 lines
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
In reply to Tom ZanussiQuoted 56 lines · Tom Zanussi
Quoted 55 lines · Koen Kooi
Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
Quoted 45 lines · Darren Hart
Quoted 1 line
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.
Quoted 39 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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:
Quoted 8 lines
Quoted 4 lines
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
Quoted 9 lines
Tom
Quoted 6 lines
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
Op 25 mei 2011, om 16:28 heeft Tom Zanussi het volgende geschreven:
Quoted 62 lines · Tom Zanussi
Quoted 61 lines · Koen Kooi
Quoted 59 lines
Op 24 mei 2011, om 19:23 heeft Khem Raj het volgende geschreven:
Quoted 45 lines · Darren Hart
Quoted 1 line
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.
Quoted 39 lines
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 patchesA 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 directlyWhile 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.
Quoted 5 lines
Quoted 1 line
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 :(
Quoted 8 lines
Quoted 3 lines
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
In reply to Tom ZanussiQuoted 4 lines · Tom Zanussi
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
Quoted 18 lines · Phil Blundell
Quoted 4 lines · Tom Zanussi
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.
Quoted 4 lines
(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
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
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
Quoted 36 lines · 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_MACHINEusage for example and instead raise the skip parsing exception whenUBOOT_MACHINEisn'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.
Quoted 9 lines
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.
Hi,
I agree with khem, each machine should maintain it's bootloader in his bsp or layer.
Bye Henning
Quoted 4 lines · Henning Heinold
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.
Signature · 3 lines
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
In reply to Phil BlundellQuoted 9 lines · Phil Blundell
Quoted 4 lines · Tom Zanussi
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:
Quoted 6 lines
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.
Quoted 3 lines
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?
Quoted 4 lines
(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.
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 3 lines
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
Quoted 3 lines · Darren Hart
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
Quoted 10 lines · Phil Blundell
Quoted 3 lines · Darren Hart
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.
Signature · 3 lines
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
Quoted 13 lines · Darren Hart
Quoted 10 lines · Phil Blundell
Quoted 3 lines · Darren Hart
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.
Quoted 3 lines
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
Quoted 48 lines · Khem Raj
Quoted 36 lines · 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_MACHINEusage for example and instead raise the skip parsing exception whenUBOOT_MACHINEisn'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.
Quoted 9 lines
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.
Quoted 2 lines
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 :/.
Quoted 3 lines
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.
Quoted 1 line
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
In reply to Richard PurdieQuoted 21 lines · Richard Purdie
Quoted 13 lines · Darren Hart
Quoted 10 lines · Phil Blundell
Quoted 3 lines · Darren Hart
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.
Quoted 3 lines
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.
Quoted 6 lines
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
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
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...
Quoted 11 lines · Richard Purdie
Quoted 9 lines · Khem Raj
Quoted 7 lines · 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).
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?
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
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?
Quoted 4 lines
Quoted 3 lines
Quoted 3 lines
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?
Quoted 7 lines
Quoted 2 lines
Quoted 2 lines
For a), I know Darren has some patches which drop the
COMPATIBLE_MACHINEQuoted 4 lines
Quoted 4 lines
usage for example and instead raise the skip parsing exception when
UBOOT_MACHINEisn't set which is a step in the right direction. If we find other issues, lets fix them.
Quoted 17 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 12 lines
Quoted 5 lines
Quoted 5 lines
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
Quoted 6 lines
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 5 lines
Quoted 4 lines
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 ?
Quoted 8 lines
No, the idea would be to make it easy to add missing pieces in a .bbappend though.
Quoted 1 line
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.
Quoted 11 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 8 lines · Darren Hart
Quoted 2 lines · Henning Heinold
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
Signature · 1 line
Anders Darander
Quoted 18 lines · Anders Darander
Quoted 8 lines · Darren Hart
Quoted 2 lines · Henning Heinold
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.
Quoted 3 lines
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.
Quoted 3 lines
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.).
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Hi Jason,
Quoted 3 lines · 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...
Of course, thanks for the input...
Quoted 16 lines
Quoted 11 lines · Richard Purdie
Quoted 9 lines · Khem Raj
Quoted 7 lines · 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).
Quoted 6 lines
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.
Quoted 10 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
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?
Quoted 11 lines
Quoted 6 lines
Quoted 5 lines
Quoted 5 lines
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.
Quoted 27 lines
Quoted 9 lines
Quoted 4 lines
Quoted 4 lines
For a), I know Darren has some patches which drop the
COMPATIBLE_MACHINEQuoted 4 lines
Quoted 4 lines
usage for example and instead raise the skip parsing exception when
UBOOT_MACHINEisn't set which is a step in the right direction. If we find other issues, lets fix them.Quoted 17 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 9 lines
Quoted 9 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 15 lines
Quoted 15 lines
Quoted 5 lines
Quoted 5 lines
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
Quoted 8 lines
Quoted 5 lines
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 ?
Quoted 8 lines
Quoted 4 lines
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
Quoted 27 lines
Quoted 4 lines
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.
Quoted 5 lines
Quoted 4 lines
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 ?
Quoted 8 lines
No, the idea would be to make it easy to add missing pieces in a .bbappend though.
Quoted 1 line
IMO keeping oe-core relatively free of machine dependent stuff would be
better.
I'm still in agreement with this.
Quoted 8 lines
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!
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Quoted 5 lines · Darren Hart
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.
Quoted 9 lines
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