[OE-core] [RFC] U-Boot Recipes

Bruce Ashfield bruce.ashfield at gmail.com
Fri Mar 1 14:53:54 UTC 2013


On Fri, Mar 1, 2013 at 9:42 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Fri, 2013-03-01 at 08:33 -0500, Bruce Ashfield wrote:
>> On Fri, Mar 1, 2013 at 6:47 AM, Jack Mitchell <ml at communistcode.co.uk> wrote:
>> > Today I was building an image for the beaglebone with oe-core +
>> > meta-beagleboard. meta-beagleboard pretty much provides the machine
>> > definition and the kernel. In order to build the correct u-boot (2013.01+) I
>> > had to add u-boot 2013.01 to oe-core. Whilst during this I noticed the mess
>> > that the u-boot directory had become, I think we need to have a show of
>> > hands who uses what u-boot recipes and can they migrate to newer (common)
>> > versions.
>>
>> The mpc8315e-rdb reference uses v2012.04, and a quick survey didn't turn up
>> any other explicit preferred versions in the layers that I have around my
>> development machine.
>>
>> So for now v2012.04 needs to stay, but as we bump that board to the 3.8 kernel,
>> we can give another bootloader a test run.
>>
>> >
>> > When I submit a patch to get 2013.01 supported, that would make 4 different
>> > releases of u-boot; which seems a bit excessive.
>>
>> Most releases that I've ever used have kept compatibility fairly well, so I'm
>> all for keeping the number of active versions to a minimum. I'd say three is
>> a good number, since that matches the number of active kernel versions in
>> oe-core as well.
>
> I think one u-boot would be nice. Lets see if we can bump up the
> mpc8315e-rdb version...

That's always the goal, but time and effort comes into play .. I've got
my hands full with my current items and won't commit to a bump, since
I won't commit .. and then miss.

If someone else does the bump, that's an option .. but I have no idea
who that someone else would be.

One random thought (for no real reson is that this is one particular area that
commercial and upstream differ .. we almost never bump our u-boot versions
once they work, since there's no benefit and only risk to updating the firmware
and reflashing the board (heck, even *building* uboot) when it is  older and
doesn't have any missing functionality.

That being said, I'll see what I can do, but no promises. In the mean time, the
version called out in the reference board should stay around.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"




More information about the Openembedded-core mailing list