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