Re: ARM expections for location of kernel, ramdisk and dtb

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Wed, Nov 27, 2019 at 08:20:12AM +0000, Chris Packham wrote:
> 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?

The self-extraction hasn't changed much over the years, and basically
follows the same method which has worked for the vast majority of
platforms.

Where things fall down is where things are placed too close, and yes,
as the kernel grows, what was reasonable years ago becomes too close
with modern kernels.

The problem has been compounded by the various different compression
algorithms that can now be used for the compressed kernel.

kexec also ran into this problem, and there is now enough information
in a modern kernel to calculate how much space the decompressor is
going to require.  Have a look at the current kexec sources for how
it is done.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel