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

[Peter Robinson]

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.

>>> Would it make it simpler or harder? To me, we should be
>>> moving to using FIT with U-Boot as it is much more flexible and better
>>> designed from the ground up to provide the required features.
>>
>>
>> I disagree that FIT is a good idea, but that's a separate topic.
>>
>>> Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a
>>> bzImage.
>>
>>
>> Do you mean FIT normally contains an originally uncompressed kernel (i.e. an
>> Image file in ARM land at least), but then compresses it itself as part of
>> FIT image generation? A bzImage is also a "compressed kernel".
>
> That's right, that's what I mean.
>
>>
>>> So it seems like we need an additional decompression address.
>>>
>>> I suppose we could always use malloc() instead... But perhaps a FIT
>>> load address makes sense. But then we don't really need a kernel load
>>> address do we? Shouldn't that be specified in the FIT itself?
>>
>>
>> A FIT load address does sound like it makes sense.
>>
>> If U-Boot copies the kernel image out of the FIT image to somewhere else,
>> the FIT image shouldn't specify the address to copy it to. This varies per
>> SoC, so if this address is hard-coded into FIT, it means the FIT image can't
>> be used on different SoCs (or perhaps even different boards, depending on
>> how differing RAM sizes work on various HW). This is why with
>> config_distro_bootcmd, all the addresses come from the U-Boot environment,
>> not hard-coded into a file on the disk. That way, the files are all generic
>> and can be used on various different systems that require different
>> addresses. It possibly makes sense for kernel_addr_r to be the destination
>> of that copy?

The above it what Fedora does, this is why we assisted in the
implementation of config_distro_bootcmd so we could have a single
kernel for all devices.

> Doesn't the kernel know where the kernel needs to be loaded / copied
> as part of the bzImage stuff? From what I see at present this is
> hard-coded into the code in the kernel. So we need to put this correct
> address in the FIT, is that right? Are you thinking we should allow
> FIT to take an environment variable as a load address?
>
> If so, I feel it would make a lot of sense for the kernel to package
> up the FIT to avoid these issues.

Is there an overview of a FIT image somewhere, does it only contain a
single DT or does it package up a single one for the device? Currently
in Fedora we're shipping 283 DTs for a single 4.0.3 multiplatform
kernel. For the images we ship we can for example just plug a generic
image into a Jetson TK1 board and have it boot without any device
specific configuration.

Peter