[U-Boot] [PATCH 20/20] tegra: config: nyan-big: Add options required by Chrome OS boot

[Stephen Warren <swarren@wwwdotorg.org>]

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?