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