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?
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
