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

[Stephen Warren <swarren@wwwdotorg.org>]

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.