rpi: Use the U-Boot control FDT for fdt_addr

The fdt_addr variable is used in extlinux as a fallback devicetree if
none is provided by the boot command.

The existing mechanism uses the devicetree provided to U-Boot, but in
its original, unrelocated position. For the rpi_4 I am using, this is
at 2b35ef00 which is not a convenient place in memory, if the ramdisk
is large.

U-Boot already deals with this sort of problem by relocating the FDT
to a safe address.

So use the control-FDT address instead.

Remove the existing comment, which is confusing, since the FDT is not
actually passed unmodified to the kernel: U-Boot adds various things
using its FDT-fixup mechanism.

Note that board_get_usable_ram_top() reduces the RAM top for boards with
less RAM. This behaviour is left unchanged as there is no other
mechanism for U-Boot to handle this.

In version 2, it incorporates some changes to fdt_addr, etc. suggested
by Tom, as well as adding myself as a maintainer.

Series-to: u-boot
Series-cc: trini, rpi
Series-version: 3
Series-links: 435918
Series-changes: 2
- Drop patch to allow expanding the devicetree during relocation

Cover-letter:
rpi: Tidy up booting
This series allows rpi to boot a compressed Ubuntu kernel with ~100MB
ramdisk, by expanding the available space.

It also tidies up some strange behaviour with the provided FDT, where a
separate pointer is maintained to it, even though U-Boot has copied it
and placed it in its own space. This avoids strange bugs where it
accidentally gets overwritten when loading a file into memory.

The patch to expand the devicetree was dropped, meaning that people
should be careful to unset fdt_addr in the environment.
END

Signed-off-by: Simon Glass <sjg@chromium.org>

board/raspberrypi/rpi/rpi.env

@@ -48,21 +48,22 @@ dfu_alt_info+=zImage fat 0 1
  *
  * 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.
+ * 0x05400000-0x05500000 and 0x05500000-0x05600000 should be 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.
- */
-
-/*
+ * satisfies this constraint again. Reserving 1M at 0x05600000-0x05700000 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x05700000.
+ * This means that the board must have at least 128MB of RAM available to
+ * U-Boot, more if the initrd is large.
+ *
+ * For compressed kernels, the maximum size is just under 32MB, with an area for
+ * decompression at 0x02000000 with space for 52MB, which is plenty for current
+ * kernels.
+ *
  * limit bootm_size to 512MB so that all boot images stay within the bottom
  * 512MB of memory
  */
@@ -70,7 +71,7 @@ bootm_size=0x20000000
 
 kernel_addr_r=0x00080000
 kernel_comp_addr_r=0x02000000
-kernel_comp_size=0x02000000
+kernel_comp_size=0x03400000
 scriptaddr=0x05400000
 pxefile_addr_r=0x05500000
 fdt_addr_r=0x05600000