Hi Stephen, On 20 May 2015 at 08:04, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 05/20/2015 07:40 AM, Simon Glass wrote: >> >> Hi Peter, >> >> On 20 May 2015 at 04:21, Peter Robinson <pbrobin...@gmail.com> wrote: >>> >>> Hi Simon, >>> >>>>>> I wonder what would be involved in adjusting config_distro_bootcmd to >>>>>> support FIT? >>>>> >>>>> >>>>> >>>>> Well, it goes against the very idea of config_distro_bootcmd, which is >>>>> to >>>>> provide a single standard mechanism that doesn't rely on any >>>>> bootloader-specific file formats etc. That mechanism is a raw zImage, a >>>>> raw >>>>> initrd, and a plain text extlinux.cfg file to specify things like file >>>>> paths/names, command-line, etc. >>>>> >>>>> The boot.scr support there is legacy, and not something that should be >>>>> built >>>>> upon going forward. So, that's not an argument for adding support for a >>>>> third mechanism! >>>> >>>> >>>> Do we need to adjust the mechanism? The only difference I see is that >>>> FIT brings the files together. >>> >>> >>> Speaking as one of the ARM maintainers that's not what we want. We >>> want to be able to use the standard kernel, initrd and then a DT so we >>> can boot a single image across any device that the kernel supports. >>> >>> In Fedora at the moment we can boot around a 100 odd devices off a >>> single kernel by specifying the DT separately. I've not looked at FIT >>> closely but I don't believe it provides us that. >> >> >> My comment was not to adjust the standard mechanism, but to adjust the >> internal details of how U-Boot implements it such that FIT could be >> supported. I reviewed the U-Boot config_distro implementation at the >> time - I was careful to confirm that the mechanism itself was defined >> separately from U-Boot's implementation. >> >> From my understanding we could package the bzImage kernel and all the > > > Nit: On ARM there's an Image (I think that's the uncompressed kernel build > output) and a zImage (that is the compressed kernel build output). bzImage > is x86-specific. > >> DTs/ramdisk into the FIT and make it work. This is what Chrome OS >> does, for example. Actually this all came up after Stephen asked how >> to make U-Boot's Chrome OS boot scripts look more like config_distro. >> >> It may actually be simpler for U-Boot to implement I think, since it >> would be using pre-wired feature. But that needs to be looked at with >> config_distro. > > > The main thing I asked was for the ChromeOS stuff to re-use existing > environment variables rather than re-inventing its own for the same purpose. > > I'm not sure whether there could be much more unification than that, since > the model that ChromeOS and config_distro_bootcmd use to select the boot > device and partition probably vary quite a bit?
Chrome OS keeps its script in a funny place, or we can use the A/B flag directly with a lot more code. But to boot partition A is not too far away - I had it finding and starting the kernel (but with the wrong bootargs). It needs more work though. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
