Hi Tom, On Mon, 29 Jul 2013, Tom Rini wrote: > On 07/29/2013 04:29 AM, Paul Walmsley wrote: > > On Wed, 26 Jun 2013, Tom Rini wrote: > >> > >> 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. It doesn't have to be this way :-) IMHO the only thing that the bootloader should be responsible for is the minimum that's needed to get the kernel started. Setting up RAM, maybe a handful of critical system clocks, and that's basically it. In fact it would be great if there was a bootloader option where it would return the rest of the bits on the chip that it tweaked to power-on reset status. That would let you guys off the hook for everything that we don't set up correctly in the kernel. And it would allow the kernel folks to see where the problems really are. And then for customer-targeted images, that bootloader option could be kept off so management doesn't freak out. You might not believe this, but we went to great pain on the OMAP Linux kernel to reset as much as we could, as early as possible. This was partially so that if kernel device driver authors assumed that the bootloader would configure their device, it would show up as a bug that would need to be fixed. We were even resetting and reprogramming the SDRAM controller for a while. Unfortunately we weren't able to reset the clocks... > 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... I've always wanted to switch most of the devices in my test platform over to serial-booted bootloaders and MLOs/X-loaders/SPLs. That way any bootloader could be booted during automated test. This is what's happening now on the BeagleBone-black here; that's really easy to cold-boot from serial due to the Xmodem download code implemented in the ROM, plus the lack of flash: http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/boot/am335xbonelt/am335x-bone/ Do you know if anyone ever got serial cold-booting working well for, say, OMAP3 and OMAP4 chips? > 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. OK I would love it if you would add a bootloader option "ASSUME_WORKING_KERNEL" that would reset every non-essential device on the board to power-on reset, and reset any non-essential clock register bits etc. to their POR values. Unlock the USB DPLL, etc. To start with, you'd need to leave that disabled for shipping customer images, but we could start testing with it and prevent patches from going upstream that implicitly rely on the bootloader settings. - Paul -- 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
