Re: Updating u-boot for oe-core or meta-yocto

[Darren Hart <dvhart@linux.intel.com>]

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