* Updating u-boot for oe-core or meta-yocto @ 2011-05-24 16:36 Darren Hart 2011-05-24 17:13 ` Koen Kooi ` (3 more replies) 0 siblings, 4 replies; 30+ messages in thread From: Darren Hart @ 2011-05-24 16:36 UTC (permalink / raw) To: Patches and discussions about the oe-core layer, Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 16:36 Updating u-boot for oe-core or meta-yocto Darren Hart @ 2011-05-24 17:13 ` Koen Kooi 2011-05-24 18:04 ` Darren Hart 2011-05-24 17:23 ` Khem Raj ` (2 subsequent siblings) 3 siblings, 1 reply; 30+ messages in thread From: Koen Kooi @ 2011-05-24 17:13 UTC (permalink / raw) To: Darren Hart; +Cc: Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 17:13 ` Koen Kooi @ 2011-05-24 18:04 ` Darren Hart 0 siblings, 0 replies; 30+ messages in thread From: Darren Hart @ 2011-05-24 18:04 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 16:36 Updating u-boot for oe-core or meta-yocto Darren Hart 2011-05-24 17:13 ` Koen Kooi @ 2011-05-24 17:23 ` Khem Raj 2011-05-24 17:51 ` adding meta-intel layers breaks parsing, was " Koen Kooi 2011-05-24 18:23 ` Darren Hart 2011-05-24 17:33 ` Martin Jansa 2011-05-25 15:51 ` Richard Purdie 3 siblings, 2 replies; 30+ messages in thread From: Khem Raj @ 2011-05-24 17:23 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 17:23 ` Khem Raj @ 2011-05-24 17:51 ` Koen Kooi 2011-05-24 18:07 ` Tom Zanussi 2011-05-24 18:23 ` Darren Hart 1 sibling, 1 reply; 30+ messages in thread From: Koen Kooi @ 2011-05-24 17:51 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 17:51 ` adding meta-intel layers breaks parsing, was " Koen Kooi @ 2011-05-24 18:07 ` Tom Zanussi 2011-05-25 14:28 ` Tom Zanussi 0 siblings, 1 reply; 30+ messages in thread From: Tom Zanussi @ 2011-05-24 18:07 UTC (permalink / raw) To: Koen Kooi; +Cc: Patches and discussions about the oe-core layer 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 18:07 ` Tom Zanussi @ 2011-05-25 14:28 ` Tom Zanussi 2011-05-25 14:31 ` Koen Kooi 2011-05-25 14:38 ` Phil Blundell 0 siblings, 2 replies; 30+ messages in thread From: Tom Zanussi @ 2011-05-25 14:28 UTC (permalink / raw) To: Koen Kooi; +Cc: Patches and discussions about the oe-core layer 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 > > > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 14:28 ` Tom Zanussi @ 2011-05-25 14:31 ` Koen Kooi 2011-05-25 14:38 ` Phil Blundell 1 sibling, 0 replies; 30+ messages in thread From: Koen Kooi @ 2011-05-25 14:31 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 14:28 ` Tom Zanussi 2011-05-25 14:31 ` Koen Kooi @ 2011-05-25 14:38 ` Phil Blundell 2011-05-25 14:52 ` Tom Zanussi 2011-05-25 18:56 ` Darren Hart 1 sibling, 2 replies; 30+ messages in thread From: Phil Blundell @ 2011-05-25 14:38 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 14:38 ` Phil Blundell @ 2011-05-25 14:52 ` Tom Zanussi 2011-05-25 18:56 ` Darren Hart 1 sibling, 0 replies; 30+ messages in thread From: Tom Zanussi @ 2011-05-25 14:52 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 14:38 ` Phil Blundell 2011-05-25 14:52 ` Tom Zanussi @ 2011-05-25 18:56 ` Darren Hart 2011-05-25 19:11 ` Phil Blundell 1 sibling, 1 reply; 30+ messages in thread From: Darren Hart @ 2011-05-25 18:56 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 18:56 ` Darren Hart @ 2011-05-25 19:11 ` Phil Blundell 2011-05-25 20:04 ` Darren Hart 0 siblings, 1 reply; 30+ messages in thread From: Phil Blundell @ 2011-05-25 19:11 UTC (permalink / raw) To: Darren Hart; +Cc: Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 19:11 ` Phil Blundell @ 2011-05-25 20:04 ` Darren Hart 2011-05-25 21:31 ` Richard Purdie 0 siblings, 1 reply; 30+ messages in thread From: Darren Hart @ 2011-05-25 20:04 UTC (permalink / raw) To: Phil Blundell; +Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 20:04 ` Darren Hart @ 2011-05-25 21:31 ` Richard Purdie 2011-05-25 23:18 ` Darren Hart 0 siblings, 1 reply; 30+ messages in thread From: Richard Purdie @ 2011-05-25 21:31 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: adding meta-intel layers breaks parsing, was Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 21:31 ` Richard Purdie @ 2011-05-25 23:18 ` Darren Hart 0 siblings, 0 replies; 30+ messages in thread From: Darren Hart @ 2011-05-25 23:18 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 17:23 ` Khem Raj 2011-05-24 17:51 ` adding meta-intel layers breaks parsing, was " Koen Kooi @ 2011-05-24 18:23 ` Darren Hart 2011-05-24 18:35 ` Khem Raj 1 sibling, 1 reply; 30+ messages in thread From: Darren Hart @ 2011-05-24 18:23 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 18:23 ` Darren Hart @ 2011-05-24 18:35 ` Khem Raj 2011-05-24 18:48 ` Phil Blundell 2011-05-24 19:33 ` Darren Hart 0 siblings, 2 replies; 30+ messages in thread From: Khem Raj @ 2011-05-24 18:35 UTC (permalink / raw) To: Darren Hart; +Cc: Koen Kooi, Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 18:35 ` Khem Raj @ 2011-05-24 18:48 ` Phil Blundell 2011-05-24 19:33 ` Darren Hart 1 sibling, 0 replies; 30+ messages in thread From: Phil Blundell @ 2011-05-24 18:48 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 18:35 ` Khem Raj 2011-05-24 18:48 ` Phil Blundell @ 2011-05-24 19:33 ` Darren Hart 1 sibling, 0 replies; 30+ messages in thread From: Darren Hart @ 2011-05-24 19:33 UTC (permalink / raw) To: Khem Raj; +Cc: Koen Kooi, Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 16:36 Updating u-boot for oe-core or meta-yocto Darren Hart 2011-05-24 17:13 ` Koen Kooi 2011-05-24 17:23 ` Khem Raj @ 2011-05-24 17:33 ` Martin Jansa 2011-05-25 15:51 ` Richard Purdie 3 siblings, 0 replies; 30+ messages in thread From: Martin Jansa @ 2011-05-24 17:33 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi [-- 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-24 16:36 Updating u-boot for oe-core or meta-yocto Darren Hart ` (2 preceding siblings ...) 2011-05-24 17:33 ` Martin Jansa @ 2011-05-25 15:51 ` Richard Purdie 2011-05-25 16:36 ` Khem Raj 3 siblings, 1 reply; 30+ messages in thread From: Richard Purdie @ 2011-05-25 15:51 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 15:51 ` Richard Purdie @ 2011-05-25 16:36 ` Khem Raj 2011-05-25 16:49 ` Henning Heinold 2011-05-25 21:51 ` Richard Purdie 0 siblings, 2 replies; 30+ messages in thread From: Khem Raj @ 2011-05-25 16:36 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 16:36 ` Khem Raj @ 2011-05-25 16:49 ` Henning Heinold 2011-05-25 18:40 ` Darren Hart 2011-05-25 21:51 ` Richard Purdie 1 sibling, 1 reply; 30+ messages in thread From: Henning Heinold @ 2011-05-25 16:49 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi Hi, I agree with khem, each machine should maintain it's bootloader in his bsp or layer. Bye Henning ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 16:49 ` Henning Heinold @ 2011-05-25 18:40 ` Darren Hart 2011-05-26 6:12 ` Anders Darander 0 siblings, 1 reply; 30+ messages in thread From: Darren Hart @ 2011-05-25 18:40 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 18:40 ` Darren Hart @ 2011-05-26 6:12 ` Anders Darander 2011-05-26 13:54 ` Darren Hart 0 siblings, 1 reply; 30+ messages in thread From: Anders Darander @ 2011-05-26 6:12 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-26 6:12 ` Anders Darander @ 2011-05-26 13:54 ` Darren Hart 0 siblings, 0 replies; 30+ messages in thread From: Darren Hart @ 2011-05-26 13:54 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 16:36 ` Khem Raj 2011-05-25 16:49 ` Henning Heinold @ 2011-05-25 21:51 ` Richard Purdie 2011-05-25 23:31 ` Jason Kridner 1 sibling, 1 reply; 30+ messages in thread From: Richard Purdie @ 2011-05-25 21:51 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 21:51 ` Richard Purdie @ 2011-05-25 23:31 ` Jason Kridner 2011-05-26 18:07 ` Darren Hart 0 siblings, 1 reply; 30+ messages in thread From: Jason Kridner @ 2011-05-25 23:31 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-25 23:31 ` Jason Kridner @ 2011-05-26 18:07 ` Darren Hart 2011-05-27 5:36 ` Anders Darander 0 siblings, 1 reply; 30+ messages in thread From: Darren Hart @ 2011-05-26 18:07 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Updating u-boot for oe-core or meta-yocto 2011-05-26 18:07 ` Darren Hart @ 2011-05-27 5:36 ` Anders Darander 0 siblings, 0 replies; 30+ messages in thread From: Anders Darander @ 2011-05-27 5:36 UTC (permalink / raw) To: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2011-05-27 5:39 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-05-24 16:36 Updating u-boot for oe-core or meta-yocto Darren Hart 2011-05-24 17:13 ` Koen Kooi 2011-05-24 18:04 ` Darren Hart 2011-05-24 17:23 ` Khem Raj 2011-05-24 17:51 ` adding meta-intel layers breaks parsing, was " Koen Kooi 2011-05-24 18:07 ` Tom Zanussi 2011-05-25 14:28 ` Tom Zanussi 2011-05-25 14:31 ` Koen Kooi 2011-05-25 14:38 ` Phil Blundell 2011-05-25 14:52 ` Tom Zanussi 2011-05-25 18:56 ` Darren Hart 2011-05-25 19:11 ` Phil Blundell 2011-05-25 20:04 ` Darren Hart 2011-05-25 21:31 ` Richard Purdie 2011-05-25 23:18 ` Darren Hart 2011-05-24 18:23 ` Darren Hart 2011-05-24 18:35 ` Khem Raj 2011-05-24 18:48 ` Phil Blundell 2011-05-24 19:33 ` Darren Hart 2011-05-24 17:33 ` Martin Jansa 2011-05-25 15:51 ` Richard Purdie 2011-05-25 16:36 ` Khem Raj 2011-05-25 16:49 ` Henning Heinold 2011-05-25 18:40 ` Darren Hart 2011-05-26 6:12 ` Anders Darander 2011-05-26 13:54 ` Darren Hart 2011-05-25 21:51 ` Richard Purdie 2011-05-25 23:31 ` Jason Kridner 2011-05-26 18:07 ` Darren Hart 2011-05-27 5:36 ` Anders Darander
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.