brain-hackers_pepepper-mirror/u-boot-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/u-boot-brain synced 2024-10-04 10:30:50 +09:00
Code Issues Projects Releases Wiki Activity

rpi: Change load addresses to make more room for the kernel & DTB

Browse Source 
As of Linux 4.16, a multiplatform AArch64 kernel with our distro config
takes 26M. The current space reservation leaves only 17M for the kernel
and if it goes over it, the initrd gets overwritten when loading the
kernel from the filesystem.

A similar problem happens on ARMv7 with the DTBs taken from the
downstream Raspberry Pi foundation kernel. I guess they compile them
with DT overlay support enabled which grows them just enough.

Fix both of these problems by rewriting the memory map, which now allows
kernels to be up to 36M and DTBs up to 1M. Also the comment block was
kind of obsolete ever since the introduction of AArch64 support and the
firmware-loaded DTB doesn't get placed at 0x100 anymore either, so that
is fixed as well.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
This commit is contained in:
Tuomas Tynkkynen 2018-04-20 13:03:49 +03:00 committed by Alexander Graf
parent 79fd08f745
commit 385cbe298a
1 changed files with 36 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
include/configs/rpi.h
View File

@ -95,39 +95,50 @@
* *
* I suspect address 0 is used as the SMP pen on the RPi2, so avoid this. * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
* *
* fdt_addr_r simply shouldn't overlap anything else. However, the RPi's * Older versions of the boot firmware place the firmware-loaded DTB at 0x100,
* binary firmware loads a DT to address 0x100, so we choose this address to * newer versions place it in high memory. So prevent U-Boot from doing its own
* match it. This allows custom boot scripts to pass this DT on to Linux * DTB + initrd relocation so that we won't accidentally relocate the initrd
* simply by not over-writing the data at this address. When using U-Boot, * over the firmware-loaded DTB and generally try to lay out things starting
* U-Boot (and scripts it executes) typicaly ignore the DT loaded by the FW * from the bottom of RAM.
* and loads its own DT from disk (triggered by boot.scr or extlinux.conf).
* *
* pxefile_addr_r can be pretty much anywhere that doesn't conflict with * kernel_addr_r has different constraints on ARM and Aarch64. For 32-bit ARM,
* something else. Put it low in memory to avoid conflicts. * it must be within the first 128M of RAM in order for the kernel's
* CONFIG_AUTO_ZRELADDR option to work. The kernel itself will be decompressed
* to 0x8000 but the decompressor clobbers 0x4000-0x8000 as well. The
* decompressor also likes to relocate itself to right past the end of the
* decompressed kernel, so in total the sum of the compressed and and
* decompressed kernel needs to be reserved.
* *
* kernel_addr_r must be within the first 128M of RAM in order for the * For Aarch64, the kernel image is uncompressed and must be loaded at
* kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will * text_offset bytes (specified in the header of the Image) into a 2MB
* decompress itself to 0x8000 after the start of RAM, kernel_addr_r * boundary. The 'booti' command relocates the image if necessary. Linux uses
* should not overlap that area, or the kernel will have to copy itself * a default text_offset of 0x80000. In summary, loading at 0x80000
* somewhere else before decompression. Similarly, the address of any other * satisfies all these constraints and reserving memory up to 0x02400000
* data passed to the kernel shouldn't overlap the start of RAM. Pushing * permits fairly large (roughly 36M) kernels.
* this up to 16M allows for a sizable kernel to be decompressed below the
* compressed load address.
* *
* scriptaddr can be pretty much anywhere that doesn't conflict with something * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
* else. Choosing 32M allows for the compressed kernel to be up to 16M. * conflict with something else. Reserving 1M for each of them at
* 0x02400000-0x02500000 and 0x02500000-0x02600000 should be plenty.
* *
* ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows * On ARM, both the DTB and any possible initrd must be loaded such that they
* for any boot script to be up to 1M, which is hopefully plenty. * fit inside the lowmem mapping in Linux. In practice, this usually means not
* more than ~700M away from the start of the kernel image but this number can
* be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
* parameter given to the kernel. So reserving memory from low to high
* satisfies this constraint again. Reserving 1M at 0x02600000-0x02700000 for
* the DTB leaves rest of the free RAM to the initrd starting at 0x02700000.
* Even with the smallest possible CPU-GPU memory split of the CPU getting
* only 64M, the remaining 25M starting at 0x02700000 should allow quite
* large initrds before they start colliding with U-Boot.
*/ */
#define ENV_MEM_LAYOUT_SETTINGS \ #define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=ffffffff\0" \ "fdt_high=ffffffff\0" \
"initrd_high=ffffffff\0" \ "initrd_high=ffffffff\0" \
"fdt_addr_r=0x01f00000\0" \ "kernel_addr_r=0x00080000\0" \
"pxefile_addr_r=0x00100000\0" \ "scriptaddr=0x02400000\0" \
"kernel_addr_r=0x01000000\0" \ "pxefile_addr_r=0x02500000\0" \
"scriptaddr=0x02000000\0" \ "fdt_addr_r=0x02600000\0" \
"ramdisk_addr_r=0x02100000\0" \ "ramdisk_addr_r=0x02700000\0"
#define BOOT_TARGET_DEVICES(func) \ #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \ func(MMC, mmc, 0) \