Hi Stephen, On 15 May 2015 at 09:34, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 05/13/2015 07:56 AM, Simon Glass wrote: >> >> Hi Stephen, >> >> On 25 February 2015 at 16:31, Stephen Warren <swar...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
