On Apr 2, 2013, at 2:56 PM, Tom Rini <tr...@ti.com> wrote:

> On 04/02/2013 02:41 PM, Michael Cashwell wrote:
> 
>> I'm currently using 3.0.8. That version most assuredly fails miserably 
>> without defining CONFIG_SYS_(CLOCKS|PADS)_ENABLE_ALL in 
>> u-boot. That kernel is part of the 3.0.x longterm lineage which as I write 
>> this is at 3.0.71.
> 
> You're on a 3.0.8 from somewhere-within-TI, that's not getting regular 
> updates (or it would be on 3.0.71 or close-to), yes?

It's an Android-related project and the kernel is what was current for Ice 
Cream Sandwich at the time the development started. Being Anddroid-related I 
expect you can appreciate why kernel updates are not trivial undertakings.

Would 3.0.71 not need the legacy support? I could likely update to 3.0.71 but 
going to 3.4.x or 3.8.x would have a large ripple effect to the rest of the 
system.

>> ... forcing an update to 3.4.x, 3.8.x or even later just to keep current 
>> with u-boot is an entirely different thing.
>> 
>> I'm very worried if that's what's being proposed here as it would be very 
>> user unfriendly.
> 
> What I'm saying is that once either mainline, or another TI-provided tree 
> exists and doesn't need these options set, they can go away.

IMO, that's overly dismissive of the collateral impact of making such a large 
kernel change. As noted, there are many cases where users can update to the 
latest patch level but more than that is too invasive.

One could argue that no one's being forced. If a user's kernel is stuck then 
having their boot loader also be stuck is OK. Perhaps, but it seems a bit 
artificial.

I want several new u-boot features (DFU, USB host Ethernet, GPT support, etc.) 
but cannot casually update my Linux kernel. These feature sets are clearly 
orthogonal and I would lament an all-or-nothing binding that wasn't technically 
necessary.

-Mike

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to