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

[Simon Glass]

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
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.

U-Boot has a mechanism to select the correct DT based on the model of
the board it is running on.

Then I asked if we could go a step further and use FIT compression (it
can specify an algorithm to use) instead of bzImage so that all the
'loading' happens in the boot loader. The problem of the kernel load
address came up, as below. I believe that (ARM-specific problem?) can
be solved by perhaps placing the kernel at address 0x8000 in physical
memory, for example, something the boot loader can do. But that is yet
to be tested and might be an addition to FIT.

>
>>>> 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.

It does support that. I believe that was one of the design goals,
albeit for PowerPC at the time. There is also CONFIG_FIT_BEST_MATCH in
U-Boot which can select the correct DT for the board.

You could try this - the verified boot part of it is documented also:

http://git.denx.de/?p=u-boot.git;a=tree;f=doc/uImage.FIT;hb=HEAD

While you are here, what boot loaders do people mostly use with Fedora on ARM?

Regards,
Simon