I thought I had replied to this, but I don't see it in my email right now.
On Tue, Apr 02, 2013 at 11:16:43PM -0400, Michael Cashwell wrote:
On Apr 2, 2013, at 2:56 PM, Tom Rini trini@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.
No, 3.0.x is 3.0.x, and quite old.
... 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.
Right. By v2012.07 you ought to be able to find an Android tree based on a newer kernel rev, that works without all of these being enabled in U-Boot. Or you start paying more of the costs of needing to stay with legacy software, either backporting further changes, or holding a local undo of the removal of the pads/conf bits.