On 05/20/2015 07:40 AM, Simon Glass wrote:
Hi Peter,
On 20 May 2015 at 04:21, Peter Robinson pbrobinson@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?