[RFC] U-Boot Recipes

[RFC] U-Boot Recipes

[Jack Mitchell]

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.

When I submit a patch to get 2013.01 supported, that would make 4 
different releases of u-boot; which seems a bit excessive.

Thoughts?

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: [RFC] U-Boot Recipes

[Bruce Ashfield]

On Fri, Mar 1, 2013 at 6:47 AM, Jack Mitchell <ml@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.

Cheers,

Bruce

>
> Thoughts?
>
> --
>
>   Jack Mitchell (jack@embed.me.uk)
>   Embedded Systems Engineer
>   http://www.embed.me.uk
>
> --
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



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

Re: [RFC] U-Boot Recipes

[Richard Purdie]

On Fri, 2013-03-01 at 08:33 -0500, Bruce Ashfield wrote:
> On Fri, Mar 1, 2013 at 6:47 AM, Jack Mitchell <ml@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...

Cheers,

Richard

Re: [RFC] U-Boot Recipes

[Bruce Ashfield]

On Fri, Mar 1, 2013 at 9:42 AM, Richard Purdie
<richard.purdie@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@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"