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

[Simon Glass]

Hi Stephen,

On 15 May 2015 at 09:34, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 05/13/2015 07:56 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 25 February 2015 at 16:31, Stephen Warren <swarren at wwwdotorg.org>
>> wrote:
>>>
>>> On 02/17/2015 03:29 PM, Simon Glass wrote:
>>>>
>>>>
>>>> We need to match the device tree in the FIT with the U-Boot model so we
>>>> can automatically select the right device tree. Also adjust the load
>>>> address
>>>> so that the device tree is not in the way when a zImage kernel tries to
>>>> extract itself.
>>>
>>>
>>>
>>> We don't tend to use LOADADDR in any of the default boot scripts any
>>> more.
>>> Rather, we explicitly load files to a "semantic" location indicated by
>>> one
>>> of the following variables in tegra124-common.h:
>>>
>>> #define MEM_LAYOUT_ENV_SETTINGS \
>>>          "scriptaddr=0x90000000\0" \
>>>          "pxefile_addr_r=0x90100000\0" \
>>>          "kernel_addr_r=0x81000000\0" \
>>>          "fdt_addr_r=0x82000000\0" \
>>>          "ramdisk_addr_r=0x82100000\0"
>>>
>>> Perhaps the ChromeOS boot scripts could be adjusted to use one/some of
>>> those
>>> variables?
>>>
>>> If the value of CONFIG_LOADADDR isn't appropriate, perhaps we should fix
>>> it
>>> for all Tegra SoCs/boards?
>>
>>
>> I forgot about this comment sorry. I had problems with the image
>> overwriting itself. It is a bzImage inside a FIT so doesn't use the
>> proper FIT decompression.
>>
>> Anyway I'd like to clarify what is meant by kernel_addr_r. Is that
>> where the FIT is loaded or where the kernel will decompress to, or
>> something else?
>
>
> kernel_addr_r is the address in RAM at which a kernel zImage is loaded by
> config_distro_bootcmd.h scripts (and likely other scripts too). It's usually
> deliberately chosen to be a fair way into RAM, so that when the zImage
> decompresses (to approx the start of RAM), the decompressed image doesn't
> overlap the compressed image at kernel_addr_r. This avoids the kernel
> decompressor having to move/copy the zImage somewhere else before copying to
> avoid any overlap during decompression.
>
> config_distro_bootcmd.h doesn't support FIT, so I haven't tried out loading
> FIT images. That said, if U-Boot simply jumps to the location of the kernel
> in the FIT image itself without any copying, I would expect everything to
> work fine if you loaded a FIT image to kernel_addr_r. However, if the
> processing of the FIT image requires the kernel to be copied out of the FIT
> image to some other location, you'd have to carefully choose that location
> so it didn't overlap anything. I'd strongly recommend avoiding any
> unnecessary copies like that though, if at all possible, from the
> perspective of both pointlessly wasted execution time and simplicity of the
> boot process. Perhaps storing a a kernel_noload image type inside the FIT
> rather than a kernel image type might help there? Perhaps you want to
> introduce a new standard variable that defines where FIT images are loaded.

I wonder what would be involved in adjusting config_distro_bootcmd to
support 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.

Anyway, normally FIT has a compressed kernel (e.g. with LZO), not a
bzImage. 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?

Regards,
Simon