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