[U-Boot] FIT image without relocation

[Stefan Agner]

Hi All,

Just learn the hard way that avoiding relocation (using
fdt_high=0xffffffff and initrd_high=0xffffffff) can be rather dangerous.

My setup: Linux Kernel, Device Tree plus SquashFS used via RAM block
device (BLK_DEV_RAM).

Downloading the files individually worked, so I knew my setup is good.

However, with the FIT image mounting Rootfs failed:

RAMDISK: Couldn't find valid RAM disk image starting at 0.
...
No filesystem could mount root, tried:  squashfs

Something destroyed my SquashFS superblock. I figured it must be the
device tree, since that gets resized by U-Boot on startup. I enabled
device tree relocation (cleared fdt_high) and it worked.

I then moved the device tree to the end of the FIT image, and disabled
device tree relocation. With that, the boot failed in a new mysterious
way:

prom_parse: Bad cell count for /soc
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at arch/arm/mach-imx/busfreq_ddr3.c:558
init_mmdc_ddr3_settings_imx6q+0x568/0x6d0()
...

Crashing later on somewhere in init_mmdc_ddr3_settings_imx6q. Something
seems to ruin my device tree...

I noticed that the problems start right after the RAM block device gets
initialized:
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like
an initrd
Freeing initrd memory: 17180K (8549c000 - 86563000)


I am not sure what exactly happens, device tree seems to be really after
RAM disk...

Kernel image @ 0x150000dc [ 0x000000 - 0x49b960 ]                       
                                                                   
*  ramdisk: subimage '0x10C8000' from image at 0x1549bb24
   ramdisk start = 0x1549bb24, ramdisk end = 0x16563b24
## Flattened Device Tree blob at 16563bec
   Booting using the fdt blob at 0x16563bec
## initrd_high = 0xffffffff, copy_to_ram = 0
   in-place initrd
   ramdisk load start = 0x1549bb24, ramdisk load end = 0x16563b24
   Using Device Tree in place at 16563bec, end 16571738

When adding a "spacing" device tree between the RAM disk image and the
device tree, it works, hence it must be an issue triggered by the close
proximity of the two. Ideas?

--
Stefan