ARM expections for location of kernel, ramdisk and dtb

From: Chris Packham
Date: Wed Nov 27 2019 - 03:20:19 EST


Hi All,

We're updating our systems to use the latest kernel. For many of them
this is a fairly large leap. One problem we've hit is that durng boot
the dtb is clobbered by the uncompressed kernel.

Here's a snippet of output from u-boot

## Loading kernel from FIT Image at 62000000 ...
Using 'XS916MXS@2' configuration
Trying 'kernel@1' kernel subimage
Description: linux
Created: 2019-11-27 6:53:48 UTC
Type: Kernel Image
Compression: uncompressed
Data Start: 0x62000174
Data Size: 3495432 Bytes = 3.3 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00800000
Entry Point: 0x60800000
...
Booting using the fdt blob at 0x63b90f6c
Loading Kernel Image ... OK
Loading Ramdisk to 6e7c6000, end 70000000 ... OK
Loading Device Tree to 607fb000, end 607fffd8 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: invalid dtb and unrecognized/unsupported machine ID
r1=0x0000206e, r2=0x00000000

Between old and new the location of the devicetree hasn't actually
changed. But what has changed is the size of the kernel the self
extracting kernel unpacks to 0x60008000 and with our current
configuration extends into where the dtb is located.

Documentation/arm/booting.rst says that "The dtb must be placed in a
region of memory where the kernel decompressor will not overwrite it".

This suggests that the problem is with our u-boot configuration, but
how is u-boot supposed to know where the self-extracting kernel is
going to place things? As far as I can tell u-boot is doing a
reasonable job of finding a place to put the dtb which it thinks is
unused. I'm not sure why it's picked 0x607fb000 instead of putting it
just under the ramdisk but regardless with the information u-boot has
that address is up for grabs.

Has this come up before? The self-extraction code is fairly careful not
to overwrite itself but doesn't seem to pay any attention to the dtb
which surprised me. So I wonder if I'm missing something?

Thanks,
Chris