On 07/29/2013 04:29 AM, Paul Walmsley wrote: > Hi > > On Wed, 26 Jun 2013, Tom Rini wrote: > >> On 06/26/2013 01:19 PM, Paul Walmsley wrote: >>> On Tue, 25 Jun 2013, Tom Rini wrote: >>> >>>> On 06/25/2013 02:20 PM, Paul Walmsley wrote: >>>> >>>>> BeagleBone-white has the additional complication that it is not easy >>>>> to automate, due to the way that power is delivered to the board, so >>>>> there is an extra dimension of difficulty there. >>>> >>>> Ah-ha, I reproduced your failure. If I make up a concat uImage + DTB, >>>> rather than pass them separately, it fails to boot. If you switch to >>>> mainline U-Boot (v2012.10 or later) you get support for separate image + >>>> dtb (v2013.04 gives you bootz and zImage support). >>> >>> Yeah, I've tried to keep the original bootloader that came on the first SD >>> card image that was used on that device. But am starting to think that >>> it's time to stop my bootloader independence jihad, since appended DTB >>> booting is so broken - have seen similar problems on SoCs from other >>> vendors as well :-( >> >> Well, me? I'm all in favor of people using latest release of U-Boot for >> their board and yelling and screaming (or just reporting bugs) when >> things don't work. I'm biased of course. > > That's exactly how bootloader developers should be testing their changes. > But most of the rest of us kernel folks don't want to deal with constantly > replacing bootloaders, and then dealing with the inevitable bootloader > regressions, when what we're really trying to test is the kernel... > The kernel should be completely independent of the bootloader used. And thus the chicken and egg problems we have today. The kernel should be independent, but unless someone is also testing more recent U-Boots as well, we may or may not have more hidden clock problems. Or if there is a bug in the bootloader for some particular use case, we don't find out until a new device ships out with broken code for that case, and now we're stuck for "forever". I don't suspect what I'm going to say now will have a lot of traction, but I really think that much like user space, every once in a while (6 months? year?) one ought to update their environment and make sure things are still working too. You folks don't need to test ever rev of U-Boot (that's my job), but it often feels like there's this cycle of "U-Boot sucks and can't do ... !" "We've had that fixed / improved / changed for years now, upgrade?" "No, can't / won't!". And... >> And assuming rmk answers the way I expect he will, like it or not, the >> version(s) we kit up and get in the box need to be factored into our >> test system setup so if folks don't want to avail themselves of >> improvements, they still get a functional system too. > > Yep seems like a good idea from a customer service point of view. Also > most OMAP devices out there probably have locked bootloaders, so replacing > the bootloader is often not an option. For shipping consumer product, or however you want to call those kind of devices, yes, appended dtb needs to work since the bootloader is locked, and making that boot something else to boot the kernel is an exercise for us oddballs :) But the boards which are designed as reference platform, we can make your lives easier, if you let us help. If something is a pain to do, give us feedback. -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
