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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
