diff options
author | Tom Rini <trini@konsulko.com> | 2018-05-24 09:54:14 -0400 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2018-05-24 09:54:14 -0400 |
commit | 7049f620002b18eef4ffc6512efafac4177e1b01 (patch) | |
tree | e777adbab75f5276feb81113e4539edd79c28acd /include | |
parent | 8a9dc16e4d07d29fff08b7caca36f0865065f7f7 (diff) | |
parent | 385cbe298a6ddcab2d6cc21fb6a549152572957b (diff) | |
download | u-boot-7049f620002b18eef4ffc6512efafac4177e1b01.zip u-boot-7049f620002b18eef4ffc6512efafac4177e1b01.tar.gz u-boot-7049f620002b18eef4ffc6512efafac4177e1b01.tar.bz2 |
Merge tag 'signed-rpi-next' of git://github.com/agraf/u-boot
Patch queue for rpi - 2018-05-24
Some minor fixes for the Raspberry Pi:
- Fix SD writes on new sdhost controller
- Sanitize default load addresses, allowing for better payload placement
Diffstat (limited to 'include')
-rw-r--r-- | include/configs/rpi.h | 61 |
1 files changed, 36 insertions, 25 deletions
diff --git a/include/configs/rpi.h b/include/configs/rpi.h index 69a22e1..649a425 100644 --- a/include/configs/rpi.h +++ b/include/configs/rpi.h @@ -95,39 +95,50 @@ * * 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 - * binary firmware loads a DT to address 0x100, so we choose this address to - * match it. This allows custom boot scripts to pass this DT on to Linux - * simply by not over-writing the data at this address. When using U-Boot, - * U-Boot (and scripts it executes) typicaly ignore the DT loaded by the FW - * and loads its own DT from disk (triggered by boot.scr or extlinux.conf). + * Older versions of the boot firmware place the firmware-loaded DTB at 0x100, + * newer versions place it in high memory. So prevent U-Boot from doing its own + * DTB + initrd relocation so that we won't accidentally relocate the initrd + * over the firmware-loaded DTB and generally try to lay out things starting + * from the bottom of RAM. * - * pxefile_addr_r can be pretty much anywhere that doesn't conflict with - * something else. Put it low in memory to avoid conflicts. + * kernel_addr_r has different constraints on ARM and Aarch64. For 32-bit ARM, + * 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 - * kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will - * decompress itself to 0x8000 after the start of RAM, kernel_addr_r - * should not overlap that area, or the kernel will have to copy itself - * somewhere else before decompression. Similarly, the address of any other - * data passed to the kernel shouldn't overlap the start of RAM. Pushing - * this up to 16M allows for a sizable kernel to be decompressed below the - * compressed load address. + * For Aarch64, the kernel image is uncompressed and must be loaded at + * text_offset bytes (specified in the header of the Image) into a 2MB + * boundary. The 'booti' command relocates the image if necessary. Linux uses + * a default text_offset of 0x80000. In summary, loading at 0x80000 + * satisfies all these constraints and reserving memory up to 0x02400000 + * permits fairly large (roughly 36M) kernels. * - * scriptaddr can be pretty much anywhere that doesn't conflict with something - * else. Choosing 32M allows for the compressed kernel to be up to 16M. + * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't + * 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 - * for any boot script to be up to 1M, which is hopefully plenty. + * On ARM, both the DTB and any possible initrd must be loaded such that they + * 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 \ "fdt_high=ffffffff\0" \ "initrd_high=ffffffff\0" \ - "fdt_addr_r=0x00000100\0" \ - "pxefile_addr_r=0x00100000\0" \ - "kernel_addr_r=0x01000000\0" \ - "scriptaddr=0x02000000\0" \ - "ramdisk_addr_r=0x02100000\0" \ + "kernel_addr_r=0x00080000\0" \ + "scriptaddr=0x02400000\0" \ + "pxefile_addr_r=0x02500000\0" \ + "fdt_addr_r=0x02600000\0" \ + "ramdisk_addr_r=0x02700000\0" #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ |