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

Stephen Warren
2015-05-15T15:34:51Z

On 05/13/2015 07:56 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 25 February 2015 at 16:31, Stephen Warren <swarren@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.