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-version: 2
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>

MAINTAINERS

@@ -210,6 +210,7 @@ N:	aspeed
 ARM BROADCOM BCM283X / BCM27XX
 M:	Matthias Brugger <mbrugger@suse.com>
 M:	Peter Robinson <pbrobinson@gmail.com>
+M:	Simon Glass <sjg@chromium.org>
 S:	Maintained
 F:	arch/arm/dts/bcm283*
 F:	arch/arm/mach-bcm283x/

board/raspberrypi/rpi/rpi.env

@@ -61,13 +61,13 @@ dfu_alt_info+=zImage fat 0 1
  * only 64M, the remaining 25M starting at 0x02700000 should allow quite
  * large initrds before they start colliding with U-Boot.
  */
-#ifdef CONFIG_ARM64
-fdt_high=ffffffffffffffff
-initrd_high=ffffffffffffffff
-#else
-fdt_high=ffffffff
-initrd_high=ffffffff
-#endif
+
+/*
+ * limit bootm_size to 512MB so that all boot images stay within the bottom
+ * 512MB of memory
+ */
+bootm_size=0x20000000
+
 kernel_addr_r=0x00080000
 kernel_comp_addr_r=0x02000000
 kernel_comp_size=0x02000000

common/board_f.c

@@ -553,10 +553,8 @@ static int reserve_fdt(void)
 		 * section, then it will be relocated with other data.
 		 */
 		if (gd->fdt_blob) {
-			int size = fdt_totalsize(gd->fdt_blob);
-
-			gd->boardf->fdt_size = ALIGN(size + CONFIG_OF_EXPAND,
-						     32);
+			gd->boardf->fdt_size =
+				ALIGN(fdt_totalsize(gd->fdt_blob), 32);
 
 			gd->start_addr_sp = reserve_stack_aligned(
 				gd->boardf->fdt_size);

dts/Kconfig

@@ -219,17 +219,6 @@ config OF_OMIT_DTB
 	  This is used for boards which normally provide a devicetree via a
 	  runtime mechanism (such as OF_BOARD), to avoid confusion.
 
-config OF_EXPAND
-	hex # "Amount to allow the control FDT to expand"
-	default SYS_FDT_PAD if OF_LIBFDT
-	default 0
-	help
-	  Some boards make use of the control FDT to boot an OS, thus when
-	  image_setup_libfdt() adds extra things to the end of the FDT, there
-	  needs to be enough space.
-
-	  Set this to the number of bytes of extra space required for the FDT.
-
 config DEFAULT_DEVICE_TREE
 	string "Default Device Tree for DT control"
 	depends on OF_CONTROL