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

[Simon Glass]

Hi Stephen,

On 20 May 2015 at 08:04, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 05/20/2015 07:40 AM, Simon Glass wrote:
>>
>> Hi Peter,
>>
>> On 20 May 2015 at 04:21, Peter Robinson <pbrobinson at 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