[PATCH v4 0/5] rpi: Tidy up booting

[PATCH v4 0/5] rpi: Tidy up booting

[Simon Glass]

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.

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

Changes in v4:
- Expand the comment on set_fdt_addr()
- Update the commit message to talk in terms of my testing

Changes in v3:
- Add to the existing comment block
- Update the comment block with the new values, including compression

Changes in v2:
- Add new patch to make myself an rpi maintainer
- Add new patch to set bootm_size
- Add new patch to drop fdt_high and initrd_high
- Drop patch to allow expanding the devicetree during relocation

Simon Glass (5):
  rpi: Add myself to the list of maintainers
  rpi: Set bootm_size to 512MB
  rpi: Drop fdt_high and initrd_high
  rpi: Update environment to support booti and large initrd
  rpi: Use the U-Boot control FDT for fdt_addr

 MAINTAINERS                   |  1 +
 board/raspberrypi/rpi/rpi.c   | 20 +++++++++----------
 board/raspberrypi/rpi/rpi.env | 37 +++++++++++++++++++----------------
 3 files changed, 31 insertions(+), 27 deletions(-)

-- 
2.34.1

[PATCH v4 1/5] rpi: Add myself to the list of maintainers

[Simon Glass]

Add my own name to the list, since existing maintainers are fairly busy.

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

(no changes since v2)

Changes in v2:
- Add new patch to make myself an rpi maintainer

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ba31f86feb6..8db1e605fc7 100644
--- a/MAINTAINERS
+++ b/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/
-- 
2.34.1

[PATCH v4 2/5] rpi: Set bootm_size to 512MB

[Simon Glass]

Set this option so that all boot images stay within the bottom 512MB of
memory. This should allow us to drop the fdt_high and initrd_high
options.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Suggested-by: Tom Rini <trini@konsulko.com>
---

(no changes since v3)

Changes in v3:
- Add to the existing comment block

Changes in v2:
- Add new patch to set bootm_size

 board/raspberrypi/rpi/rpi.env | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
index 30228285edd..a327fccc77f 100644
--- a/board/raspberrypi/rpi/rpi.env
+++ b/board/raspberrypi/rpi/rpi.env
@@ -60,7 +60,12 @@ dfu_alt_info+=zImage fat 0 1
  * 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.
+ *
+ * Limit bootm_size to 512MB so that all boot images stay within the bottom
+ * 512MB of memory
  */
+bootm_size=0x20000000
+
 #ifdef CONFIG_ARM64
 fdt_high=ffffffffffffffff
 initrd_high=ffffffffffffffff
-- 
2.34.1

[PATCH v4 3/5] rpi: Drop fdt_high and initrd_high

[Simon Glass]

These are not needed now since there is a bootm_size setting to keep
things within the lower part of memory.

Drop them.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Suggested-by: Tom Rini <trini@konsulko.com>
---

(no changes since v2)

Changes in v2:
- Add new patch to drop fdt_high and initrd_high

 board/raspberrypi/rpi/rpi.env | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
index a327fccc77f..9b9fad82828 100644
--- a/board/raspberrypi/rpi/rpi.env
+++ b/board/raspberrypi/rpi/rpi.env
@@ -66,13 +66,6 @@ dfu_alt_info+=zImage fat 0 1
  */
 bootm_size=0x20000000
 
-#ifdef CONFIG_ARM64
-fdt_high=ffffffffffffffff
-initrd_high=ffffffffffffffff
-#else
-fdt_high=ffffffff
-initrd_high=ffffffff
-#endif
 kernel_addr_r=0x00080000
 scriptaddr=0x02400000
 pxefile_addr_r=0x02500000
-- 
2.34.1

[PATCH v4 4/5] rpi: Update environment to support booti and large initrd

[Simon Glass]

The existing values don't provide for decompressing an arm64 boot-image.
Add those values and move things apart a bit so that a 50MB kernel can be
accommodated.

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

(no changes since v3)

Changes in v3:
- Update the comment block with the new values, including compression

 board/raspberrypi/rpi/rpi.env | 27 ++++++++++++++++-----------
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
index 9b9fad82828..9ac9d6768ca 100644
--- a/board/raspberrypi/rpi/rpi.env
+++ b/board/raspberrypi/rpi/rpi.env
@@ -48,28 +48,33 @@ 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.
  *
- * Limit bootm_size to 512MB so that all boot images stay within the bottom
+ * 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
  */
 bootm_size=0x20000000
 
 kernel_addr_r=0x00080000
-scriptaddr=0x02400000
-pxefile_addr_r=0x02500000
-fdt_addr_r=0x02600000
-ramdisk_addr_r=0x02700000
+kernel_comp_addr_r=0x02000000
+kernel_comp_size=0x03400000
+scriptaddr=0x05400000
+pxefile_addr_r=0x05500000
+fdt_addr_r=0x05600000
+ramdisk_addr_r=0x05700000
 
 boot_targets=mmc usb pxe dhcp
-- 
2.34.1

[PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr

[Simon Glass]

The fdt_addr variable is used in extlinux as a fallback devicetree if
none is provided by the boot command. Otherwise the only use in U-Boot
seems to me efi_install_fdt() when the internal FDT is required.

The existing mechanism uses the devicetree provided to U-Boot, but in
its original, unrelocated position. In my testing on an rpi_4, this ends
up 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.

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

Changes in v4:
- Expand the comment on set_fdt_addr()
- Update the commit message to talk in terms of my testing

Changes in v2:
- Drop patch to allow expanding the devicetree during relocation

 board/raspberrypi/rpi/rpi.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index c46fe4b2350..f74006e0968 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -3,6 +3,8 @@
  * (C) Copyright 2012-2016 Stephen Warren
  */
 
+#define LOG_CATEGORY	LOGC_BOARD
+
 #include <config.h>
 #include <dm.h>
 #include <env.h>
@@ -326,18 +328,13 @@ static void set_fdtfile(void)
 }
 
 /*
- * If the firmware provided a valid FDT at boot time, let's expose it in
- * ${fdt_addr} so it may be passed unmodified to the kernel.
+ * Allow U-Boot to use its control FDT with extlinux if one is not provided.
+ * This will then go through the usual fixups that U-Boot does, before being
+ * handed off to Linux
  */
 static void set_fdt_addr(void)
 {
-	if (env_get("fdt_addr"))
-		return;
-
-	if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
-		return;
-
-	env_set_hex("fdt_addr", fw_dtb_pointer);
+	env_set_hex("fdt_addr", (ulong)gd->fdt_blob);
 }
 
 /*
@@ -571,7 +568,10 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 {
 	int node;
 
-	update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
+	if (blob == gd->fdt_blob)
+		log_debug("Same FDT: nothing to do\n");
+	else
+		update_fdt_from_fw(blob, (void *)gd->fdt_blob);
 
 	node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
 	if (node < 0)
-- 
2.34.1

Re: [PATCH v4 0/5] rpi: Tidy up booting

[Simon Glass]

Hi,

On Thu, 19 Dec 2024 at 17:34, Simon Glass <sjg@chromium.org> wrote:
>
> 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.
>
> In version 2, it incorporates some changes to fdt_addr, etc. suggested
> by Tom, as well as adding myself as a maintainer.
>
> Changes in v4:
> - Expand the comment on set_fdt_addr()
> - Update the commit message to talk in terms of my testing
>
> Changes in v3:
> - Add to the existing comment block
> - Update the comment block with the new values, including compression
>
> Changes in v2:
> - Add new patch to make myself an rpi maintainer
> - Add new patch to set bootm_size
> - Add new patch to drop fdt_high and initrd_high
> - Drop patch to allow expanding the devicetree during relocation
>
> Simon Glass (5):
>   rpi: Add myself to the list of maintainers
>   rpi: Set bootm_size to 512MB
>   rpi: Drop fdt_high and initrd_high
>   rpi: Update environment to support booti and large initrd
>   rpi: Use the U-Boot control FDT for fdt_addr
>
>  MAINTAINERS                   |  1 +
>  board/raspberrypi/rpi/rpi.c   | 20 +++++++++----------
>  board/raspberrypi/rpi/rpi.env | 37 +++++++++++++++++++----------------
>  3 files changed, 31 insertions(+), 27 deletions(-)
>
> --
> 2.34.1
>

Are there any comments on this series, or can it be applied?

Regards,
Simon

Re: [PATCH v4 0/5] rpi: Tidy up booting

[Simon Glass]

Hi,

On Thu, 19 Dec 2024 at 17:34, Simon Glass <sjg@chromium.org> wrote:
>
> 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.
>
> In version 2, it incorporates some changes to fdt_addr, etc. suggested
> by Tom, as well as adding myself as a maintainer.
>
> Changes in v4:
> - Expand the comment on set_fdt_addr()
> - Update the commit message to talk in terms of my testing
>
> Changes in v3:
> - Add to the existing comment block
> - Update the comment block with the new values, including compression
>
> Changes in v2:
> - Add new patch to make myself an rpi maintainer
> - Add new patch to set bootm_size
> - Add new patch to drop fdt_high and initrd_high
> - Drop patch to allow expanding the devicetree during relocation
>
> Simon Glass (5):
>   rpi: Add myself to the list of maintainers
>   rpi: Set bootm_size to 512MB
>   rpi: Drop fdt_high and initrd_high
>   rpi: Update environment to support booti and large initrd
>   rpi: Use the U-Boot control FDT for fdt_addr
>
>  MAINTAINERS                   |  1 +
>  board/raspberrypi/rpi/rpi.c   | 20 +++++++++----------
>  board/raspberrypi/rpi/rpi.env | 37 +++++++++++++++++++----------------
>  3 files changed, 31 insertions(+), 27 deletions(-)
>
> --
> 2.34.1
>

We have hit rc1 now. Is there any interest in applying this series?

Regards,
Simon

Re: [PATCH v4 0/5] rpi: Tidy up booting

[Peter Robinson]

On Thu, 30 Jan 2025 at 19:55, Simon Glass <sjg@chromium.org> wrote:

> Hi,
>
> On Thu, 19 Dec 2024 at 17:34, Simon Glass <sjg@chromium.org> wrote:
> >
> > 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.
> >
> > In version 2, it incorporates some changes to fdt_addr, etc. suggested
> > by Tom, as well as adding myself as a maintainer.
> >
> > Changes in v4:
> > - Expand the comment on set_fdt_addr()
> > - Update the commit message to talk in terms of my testing
> >
> > Changes in v3:
> > - Add to the existing comment block
> > - Update the comment block with the new values, including compression
> >
> > Changes in v2:
> > - Add new patch to make myself an rpi maintainer
> > - Add new patch to set bootm_size
> > - Add new patch to drop fdt_high and initrd_high
> > - Drop patch to allow expanding the devicetree during relocation
> >
> > Simon Glass (5):
> >   rpi: Add myself to the list of maintainers
> >   rpi: Set bootm_size to 512MB
> >   rpi: Drop fdt_high and initrd_high
> >   rpi: Update environment to support booti and large initrd
> >   rpi: Use the U-Boot control FDT for fdt_addr
> >
> >  MAINTAINERS                   |  1 +
> >  board/raspberrypi/rpi/rpi.c   | 20 +++++++++----------
> >  board/raspberrypi/rpi/rpi.env | 37 +++++++++++++++++++----------------
> >  3 files changed, 31 insertions(+), 27 deletions(-)
> >
> > --
> > 2.34.1
> >
>
> We have hit rc1 now. Is there any interest in applying this series?
>

I have started testing it but I am traveling so have limited devices (and
time) to test and I want to do more thorough testing on my return later in
the week.

Re: [PATCH v4 0/5] rpi: Tidy up booting

[Christopher Obbard]

Hi Simon,

I tried to boot a mainline 6.12 kernel on a CM4 with U-Boot 2025.01;
it doesn't work without this patch series and complains that the DTB
is mangled. Not sure why, as there appears to be adequate space in
that gap.
I didn't look much further than setting alternative load addresses for
it to work (without this series). With this series it boots perfectly
out of the box!
I will add some tags to the individual commits shortly.

For reference the working addresses I used were:
setenv kernel_addr_r 0x02000000
setenv fdt_addr_r 0x10000000

Side note: It would be quite nice to add kernel_comp_addr_r and
kernel_comp_size to be able to boot compressed kernels; I will put
this on my TODO list for some day.


Cheers!

Chris

On Mon, 3 Feb 2025 at 03:41, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> On Thu, 30 Jan 2025 at 19:55, Simon Glass <sjg@chromium.org> wrote:
>
> > Hi,
> >
> > On Thu, 19 Dec 2024 at 17:34, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > 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.
> > >
> > > In version 2, it incorporates some changes to fdt_addr, etc. suggested
> > > by Tom, as well as adding myself as a maintainer.
> > >
> > > Changes in v4:
> > > - Expand the comment on set_fdt_addr()
> > > - Update the commit message to talk in terms of my testing
> > >
> > > Changes in v3:
> > > - Add to the existing comment block
> > > - Update the comment block with the new values, including compression
> > >
> > > Changes in v2:
> > > - Add new patch to make myself an rpi maintainer
> > > - Add new patch to set bootm_size
> > > - Add new patch to drop fdt_high and initrd_high
> > > - Drop patch to allow expanding the devicetree during relocation
> > >
> > > Simon Glass (5):
> > >   rpi: Add myself to the list of maintainers
> > >   rpi: Set bootm_size to 512MB
> > >   rpi: Drop fdt_high and initrd_high
> > >   rpi: Update environment to support booti and large initrd
> > >   rpi: Use the U-Boot control FDT for fdt_addr
> > >
> > >  MAINTAINERS                   |  1 +
> > >  board/raspberrypi/rpi/rpi.c   | 20 +++++++++----------
> > >  board/raspberrypi/rpi/rpi.env | 37 +++++++++++++++++++----------------
> > >  3 files changed, 31 insertions(+), 27 deletions(-)
> > >
> > > --
> > > 2.34.1
> > >
> >
> > We have hit rc1 now. Is there any interest in applying this series?
> >
>
> I have started testing it but I am traveling so have limited devices (and
> time) to test and I want to do more thorough testing on my return later in
> the week.

Re: [PATCH v4 2/5] rpi: Set bootm_size to 512MB

[Christopher Obbard]

Hi Simon,

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> Set this option so that all boot images stay within the bottom 512MB
> of
> memory. This should allow us to drop the fdt_high and initrd_high
> options.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> Suggested-by: Tom Rini <trini@konsulko.com>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Add to the existing comment block
> 
> Changes in v2:
> - Add new patch to set bootm_size
> 
>  board/raspberrypi/rpi/rpi.env | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/board/raspberrypi/rpi/rpi.env
> b/board/raspberrypi/rpi/rpi.env
> index 30228285edd..a327fccc77f 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -60,7 +60,12 @@ dfu_alt_info+=zImage fat 0 1
>   * 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.
> + *
> + * Limit bootm_size to 512MB so that all boot images stay within the
> bottom
> + * 512MB of memory
>   */
> +bootm_size=0x20000000
> +
>  #ifdef CONFIG_ARM64
>  fdt_high=ffffffffffffffff
>  initrd_high=ffffffffffffffff

Re: [PATCH v4 3/5] rpi: Drop fdt_high and initrd_high

[Christopher Obbard]

Hi Simon,

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> These are not needed now since there is a bootm_size setting to keep
> things within the lower part of memory.
> 
> Drop them.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> Suggested-by: Tom Rini <trini@konsulko.com>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> (no changes since v2)
> 
> Changes in v2:
> - Add new patch to drop fdt_high and initrd_high
> 
>  board/raspberrypi/rpi/rpi.env | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.env
> b/board/raspberrypi/rpi/rpi.env
> index a327fccc77f..9b9fad82828 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -66,13 +66,6 @@ dfu_alt_info+=zImage fat 0 1
>   */
>  bootm_size=0x20000000
>  
> -#ifdef CONFIG_ARM64
> -fdt_high=ffffffffffffffff
> -initrd_high=ffffffffffffffff
> -#else
> -fdt_high=ffffffff
> -initrd_high=ffffffff
> -#endif
>  kernel_addr_r=0x00080000
>  scriptaddr=0x02400000
>  pxefile_addr_r=0x02500000

Re: [PATCH v4 4/5] rpi: Update environment to support booti and large initrd

[Christopher Obbard]

Hi Simon,

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> The existing values don't provide for decompressing an arm64 boot-
> image.
> Add those values and move things apart a bit so that a 50MB kernel
> can be
> accommodated.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Update the comment block with the new values, including compression
> 
>  board/raspberrypi/rpi/rpi.env | 27 ++++++++++++++++-----------
>  1 file changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.env
> b/board/raspberrypi/rpi/rpi.env
> index 9b9fad82828..9ac9d6768ca 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -48,28 +48,33 @@ 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.
>   *
> - * Limit bootm_size to 512MB so that all boot images stay within the
> bottom
> + * 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
>   */
>  bootm_size=0x20000000
>  
>  kernel_addr_r=0x00080000
> -scriptaddr=0x02400000
> -pxefile_addr_r=0x02500000
> -fdt_addr_r=0x02600000
> -ramdisk_addr_r=0x02700000
> +kernel_comp_addr_r=0x02000000
> +kernel_comp_size=0x03400000
> +scriptaddr=0x05400000
> +pxefile_addr_r=0x05500000
> +fdt_addr_r=0x05600000
> +ramdisk_addr_r=0x05700000
>  
>  boot_targets=mmc usb pxe dhcp

Re: [PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr

[Christopher Obbard]

Hi Simon,

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> The fdt_addr variable is used in extlinux as a fallback devicetree if
> none is provided by the boot command. Otherwise the only use in U-
> Boot
> seems to me efi_install_fdt() when the internal FDT is required.
> 
> The existing mechanism uses the devicetree provided to U-Boot, but in
> its original, unrelocated position. In my testing on an rpi_4, this
> ends
> up 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.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> Changes in v4:
> - Expand the comment on set_fdt_addr()
> - Update the commit message to talk in terms of my testing
> 
> Changes in v2:
> - Drop patch to allow expanding the devicetree during relocation
> 
>  board/raspberrypi/rpi/rpi.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.c
> b/board/raspberrypi/rpi/rpi.c
> index c46fe4b2350..f74006e0968 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -3,6 +3,8 @@
>   * (C) Copyright 2012-2016 Stephen Warren
>   */
>  
> +#define LOG_CATEGORY	LOGC_BOARD
> +
>  #include <config.h>
>  #include <dm.h>
>  #include <env.h>
> @@ -326,18 +328,13 @@ static void set_fdtfile(void)
>  }
>  
>  /*
> - * If the firmware provided a valid FDT at boot time, let's expose
> it in
> - * ${fdt_addr} so it may be passed unmodified to the kernel.
> + * Allow U-Boot to use its control FDT with extlinux if one is not
> provided.
> + * This will then go through the usual fixups that U-Boot does,
> before being
> + * handed off to Linux
>   */
>  static void set_fdt_addr(void)
>  {
> -	if (env_get("fdt_addr"))
> -		return;
> -
> -	if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
> -		return;
> -
> -	env_set_hex("fdt_addr", fw_dtb_pointer);
> +	env_set_hex("fdt_addr", (ulong)gd->fdt_blob);
>  }
>  
>  /*
> @@ -571,7 +568,10 @@ int ft_board_setup(void *blob, struct bd_info
> *bd)
>  {
>  	int node;
>  
> -	update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
> +	if (blob == gd->fdt_blob)
> +		log_debug("Same FDT: nothing to do\n");
> +	else
> +		update_fdt_from_fw(blob, (void *)gd->fdt_blob);
>  
>  	node = fdt_node_offset_by_compatible(blob, -1, "simple-
> framebuffer");
>  	if (node < 0)

Re: [PATCH v4 1/5] rpi: Add myself to the list of maintainers

[Christopher Obbard]

Hi Simon,

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> Add my own name to the list, since existing maintainers are fairly
> busy.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

I think it would be useful to have another maintainer here. Of course,
my opinion means very little here though ;-).

> ---
> 
> (no changes since v2)
> 
> Changes in v2:
> - Add new patch to make myself an rpi maintainer
> 
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba31f86feb6..8db1e605fc7 100644
> --- a/MAINTAINERS
> +++ b/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/

Re: [PATCH v4 4/5] rpi: Update environment to support booti and large initrd

[Christopher Obbard]

Hi Simon,

[resending as I used the wrong e-mail address which isn't on the list,
oops]

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> The existing values don't provide for decompressing an arm64 boot-
> image.
> Add those values and move things apart a bit so that a 50MB kernel
> can be
> accommodated.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Update the comment block with the new values, including compression
> 
>  board/raspberrypi/rpi/rpi.env | 27 ++++++++++++++++-----------
>  1 file changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.env
> b/board/raspberrypi/rpi/rpi.env
> index 9b9fad82828..9ac9d6768ca 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -48,28 +48,33 @@ 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.
>   *
> - * Limit bootm_size to 512MB so that all boot images stay within the
> bottom
> + * 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
>   */
>  bootm_size=0x20000000
>  
>  kernel_addr_r=0x00080000
> -scriptaddr=0x02400000
> -pxefile_addr_r=0x02500000
> -fdt_addr_r=0x02600000
> -ramdisk_addr_r=0x02700000
> +kernel_comp_addr_r=0x02000000
> +kernel_comp_size=0x03400000
> +scriptaddr=0x05400000
> +pxefile_addr_r=0x05500000
> +fdt_addr_r=0x05600000
> +ramdisk_addr_r=0x05700000
>  
>  boot_targets=mmc usb pxe dhcp

Re: [PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr

[Christopher Obbard]

Hi Simon,

[resending as I used the wrong e-mail address which isn't on the list,
oops]

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> The fdt_addr variable is used in extlinux as a fallback devicetree if
> none is provided by the boot command. Otherwise the only use in U-
> Boot
> seems to me efi_install_fdt() when the internal FDT is required.
> 
> The existing mechanism uses the devicetree provided to U-Boot, but in
> its original, unrelocated position. In my testing on an rpi_4, this
> ends
> up 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.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> Changes in v4:
> - Expand the comment on set_fdt_addr()
> - Update the commit message to talk in terms of my testing
> 
> Changes in v2:
> - Drop patch to allow expanding the devicetree during relocation
> 
>  board/raspberrypi/rpi/rpi.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.c
> b/board/raspberrypi/rpi/rpi.c
> index c46fe4b2350..f74006e0968 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -3,6 +3,8 @@
>   * (C) Copyright 2012-2016 Stephen Warren
>   */
>  
> +#define LOG_CATEGORY	LOGC_BOARD
> +
>  #include <config.h>
>  #include <dm.h>
>  #include <env.h>
> @@ -326,18 +328,13 @@ static void set_fdtfile(void)
>  }
>  
>  /*
> - * If the firmware provided a valid FDT at boot time, let's expose
> it in
> - * ${fdt_addr} so it may be passed unmodified to the kernel.
> + * Allow U-Boot to use its control FDT with extlinux if one is not
> provided.
> + * This will then go through the usual fixups that U-Boot does,
> before being
> + * handed off to Linux
>   */
>  static void set_fdt_addr(void)
>  {
> -	if (env_get("fdt_addr"))
> -		return;
> -
> -	if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
> -		return;
> -
> -	env_set_hex("fdt_addr", fw_dtb_pointer);
> +	env_set_hex("fdt_addr", (ulong)gd->fdt_blob);
>  }
>  
>  /*
> @@ -571,7 +568,10 @@ int ft_board_setup(void *blob, struct bd_info
> *bd)
>  {
>  	int node;
>  
> -	update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
> +	if (blob == gd->fdt_blob)
> +		log_debug("Same FDT: nothing to do\n");
> +	else
> +		update_fdt_from_fw(blob, (void *)gd->fdt_blob);
>  
>  	node = fdt_node_offset_by_compatible(blob, -1, "simple-
> framebuffer");
>  	if (node < 0)

Re: [PATCH v4 3/5] rpi: Drop fdt_high and initrd_high

[Christopher Obbard]

Hi Simon,

[resending as I used the wrong e-mail address which isn't on the list,
oops]

On Thu, 2024-12-19 at 17:34 -0700, Simon Glass wrote:
> These are not needed now since there is a bootm_size setting to keep
> things within the lower part of memory.
> 
> Drop them.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> Suggested-by: Tom Rini <trini@konsulko.com>

Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org>
Tested-by: Christopher Obbard <christopher.obbard@linaro.org> # CM4 1G

> ---
> 
> (no changes since v2)
> 
> Changes in v2:
> - Add new patch to drop fdt_high and initrd_high
> 
>  board/raspberrypi/rpi/rpi.env | 7 -------
>  1 file changed, 7 deletions(-)
> 
> diff --git a/board/raspberrypi/rpi/rpi.env
> b/board/raspberrypi/rpi/rpi.env
> index a327fccc77f..9b9fad82828 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -66,13 +66,6 @@ dfu_alt_info+=zImage fat 0 1
>   */
>  bootm_size=0x20000000
>  
> -#ifdef CONFIG_ARM64
> -fdt_high=ffffffffffffffff
> -initrd_high=ffffffffffffffff
> -#else
> -fdt_high=ffffffff
> -initrd_high=ffffffff
> -#endif
>  kernel_addr_r=0x00080000
>  scriptaddr=0x02400000
>  pxefile_addr_r=0x02500000

Re: [PATCH v4 0/5] rpi: Tidy up booting

[Christopher Obbard]

Hi Simon,

On Sun, 30 Mar 2025 at 14:29, Christopher Obbard
<christopher.obbard@linaro.org> wrote:
> Side note: It would be quite nice to add kernel_comp_addr_r and
> kernel_comp_size to be able to boot compressed kernels; I will put
> this on my TODO list for some day.

Please disregard this false information. I looked at the diff again;
you already added it in your series. I also tested it; works well!


Thanks!

Chris

Re: [PATCH v4 0/5] rpi: Tidy up booting

[Simon Glass]

Hi Christopher,

On Mon, 31 Mar 2025 at 04:03, Christopher Obbard
<christopher.obbard@linaro.org> wrote:
>
> Hi Simon,
>
> On Sun, 30 Mar 2025 at 14:29, Christopher Obbard
> <christopher.obbard@linaro.org> wrote:
> > Side note: It would be quite nice to add kernel_comp_addr_r and
> > kernel_comp_size to be able to boot compressed kernels; I will put
> > this on my TODO list for some day.
>
> Please disregard this false information. I looked at the diff again;
> you already added it in your series. I also tested it; works well!
>

Thank you for testing it.

Regards,
Simon

Re: [PATCH v4 1/5] rpi: Add myself to the list of maintainers

[Peter Robinson]

Simon,

On Fri, 20 Dec 2024 at 00:41, Simon Glass <sjg@chromium.org> wrote:
>
> Add my own name to the list, since existing maintainers are fairly busy.

I've spoken with the other maintainer and we've decided to decline this offer.

> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Add new patch to make myself an rpi maintainer
>
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ba31f86feb6..8db1e605fc7 100644
> --- a/MAINTAINERS
> +++ b/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/
> --
> 2.34.1
>

Re: [PATCH v4 2/5] rpi: Set bootm_size to 512MB

[Peter Robinson]

Applied

On Fri, 20 Dec 2024 at 00:34, Simon Glass <sjg@chromium.org> wrote:
>
> Set this option so that all boot images stay within the bottom 512MB of
> memory. This should allow us to drop the fdt_high and initrd_high
> options.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> Suggested-by: Tom Rini <trini@konsulko.com>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Add to the existing comment block
>
> Changes in v2:
> - Add new patch to set bootm_size
>
>  board/raspberrypi/rpi/rpi.env | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> index 30228285edd..a327fccc77f 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -60,7 +60,12 @@ dfu_alt_info+=zImage fat 0 1
>   * 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.
> + *
> + * Limit bootm_size to 512MB so that all boot images stay within the bottom
> + * 512MB of memory
>   */
> +bootm_size=0x20000000
> +
>  #ifdef CONFIG_ARM64
>  fdt_high=ffffffffffffffff
>  initrd_high=ffffffffffffffff
> --
> 2.34.1
>

Re: [PATCH v4 4/5] rpi: Update environment to support booti and large initrd

[Peter Robinson]

Applied

On Fri, 20 Dec 2024 at 00:35, Simon Glass <sjg@chromium.org> wrote:
>
> The existing values don't provide for decompressing an arm64 boot-image.
> Add those values and move things apart a bit so that a 50MB kernel can be
> accommodated.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Update the comment block with the new values, including compression
>
>  board/raspberrypi/rpi/rpi.env | 27 ++++++++++++++++-----------
>  1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> index 9b9fad82828..9ac9d6768ca 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -48,28 +48,33 @@ 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.
>   *
> - * Limit bootm_size to 512MB so that all boot images stay within the bottom
> + * 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
>   */
>  bootm_size=0x20000000
>
>  kernel_addr_r=0x00080000
> -scriptaddr=0x02400000
> -pxefile_addr_r=0x02500000
> -fdt_addr_r=0x02600000
> -ramdisk_addr_r=0x02700000
> +kernel_comp_addr_r=0x02000000
> +kernel_comp_size=0x03400000
> +scriptaddr=0x05400000
> +pxefile_addr_r=0x05500000
> +fdt_addr_r=0x05600000
> +ramdisk_addr_r=0x05700000
>
>  boot_targets=mmc usb pxe dhcp
> --
> 2.34.1
>

Re: [PATCH v4 3/5] rpi: Drop fdt_high and initrd_high

[Peter Robinson]

Applied

On Fri, 20 Dec 2024 at 00:35, Simon Glass <sjg@chromium.org> wrote:
>
> These are not needed now since there is a bootm_size setting to keep
> things within the lower part of memory.
>
> Drop them.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> Suggested-by: Tom Rini <trini@konsulko.com>
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Add new patch to drop fdt_high and initrd_high
>
>  board/raspberrypi/rpi/rpi.env | 7 -------
>  1 file changed, 7 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.env b/board/raspberrypi/rpi/rpi.env
> index a327fccc77f..9b9fad82828 100644
> --- a/board/raspberrypi/rpi/rpi.env
> +++ b/board/raspberrypi/rpi/rpi.env
> @@ -66,13 +66,6 @@ dfu_alt_info+=zImage fat 0 1
>   */
>  bootm_size=0x20000000
>
> -#ifdef CONFIG_ARM64
> -fdt_high=ffffffffffffffff
> -initrd_high=ffffffffffffffff
> -#else
> -fdt_high=ffffffff
> -initrd_high=ffffffff
> -#endif
>  kernel_addr_r=0x00080000
>  scriptaddr=0x02400000
>  pxefile_addr_r=0x02500000
> --
> 2.34.1
>

Re: [PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr

[Peter Robinson]

Hi Simon,

With the other changes in the rpi pull this no longer applies.

On Fri, 20 Dec 2024 at 00:35, Simon Glass <sjg@chromium.org> wrote:
>
> The fdt_addr variable is used in extlinux as a fallback devicetree if
> none is provided by the boot command. Otherwise the only use in U-Boot
> seems to me efi_install_fdt() when the internal FDT is required.
>
> The existing mechanism uses the devicetree provided to U-Boot, but in
> its original, unrelocated position. In my testing on an rpi_4, this ends
> up 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.

I'm not sure the context of the two paragraphs, they seem to conflict
with each other.

> So use the control-FDT address instead.

The RPi is interest as we have different DTs, the one the firmware
provides, which is useful as it deals with things like overlays, the
U-Boot one we've typically not used or one loaded from disk which is
generally the upstream Linux kernel one, how does this change address
that? I have concerns this will change the logic overall. Does it?

> 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.

Could you answer my query above and rebase?

Thanks,
Peter

> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v4:
> - Expand the comment on set_fdt_addr()
> - Update the commit message to talk in terms of my testing
>
> Changes in v2:
> - Drop patch to allow expanding the devicetree during relocation
>
>  board/raspberrypi/rpi/rpi.c | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index c46fe4b2350..f74006e0968 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -3,6 +3,8 @@
>   * (C) Copyright 2012-2016 Stephen Warren
>   */
>
> +#define LOG_CATEGORY   LOGC_BOARD
> +
>  #include <config.h>
>  #include <dm.h>
>  #include <env.h>
> @@ -326,18 +328,13 @@ static void set_fdtfile(void)
>  }
>
>  /*
> - * If the firmware provided a valid FDT at boot time, let's expose it in
> - * ${fdt_addr} so it may be passed unmodified to the kernel.
> + * Allow U-Boot to use its control FDT with extlinux if one is not provided.
> + * This will then go through the usual fixups that U-Boot does, before being
> + * handed off to Linux
>   */
>  static void set_fdt_addr(void)
>  {
> -       if (env_get("fdt_addr"))
> -               return;
> -
> -       if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
> -               return;
> -
> -       env_set_hex("fdt_addr", fw_dtb_pointer);
> +       env_set_hex("fdt_addr", (ulong)gd->fdt_blob);
>  }
>
>  /*
> @@ -571,7 +568,10 @@ int ft_board_setup(void *blob, struct bd_info *bd)
>  {
>         int node;
>
> -       update_fdt_from_fw(blob, (void *)fw_dtb_pointer);
> +       if (blob == gd->fdt_blob)
> +               log_debug("Same FDT: nothing to do\n");
> +       else
> +               update_fdt_from_fw(blob, (void *)gd->fdt_blob);
>
>         node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
>         if (node < 0)
> --
> 2.34.1
>

Re: [PATCH v4 1/5] rpi: Add myself to the list of maintainers

[Simon Glass]

Hi Peter,

On Mon, 21 Apr 2025 at 11:09, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Simon,
>
> On Fri, 20 Dec 2024 at 00:41, Simon Glass <sjg@chromium.org> wrote:
> >
> > Add my own name to the list, since existing maintainers are fairly busy.
>
> I've spoken with the other maintainer and we've decided to decline this offer.

OK, thank you for your consideration.

Regards,
Simon

Re: [PATCH v4 5/5] rpi: Use the U-Boot control FDT for fdt_addr

[Simon Glass]

Hi Peter,

On Mon, 21 Apr 2025 at 11:34, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Simon,
>
> With the other changes in the rpi pull this no longer applies.
>
> On Fri, 20 Dec 2024 at 00:35, Simon Glass <sjg@chromium.org> wrote:
> >
> > The fdt_addr variable is used in extlinux as a fallback devicetree if
> > none is provided by the boot command. Otherwise the only use in U-Boot
> > seems to me efi_install_fdt() when the internal FDT is required.
> >
> > The existing mechanism uses the devicetree provided to U-Boot, but in
> > its original, unrelocated position. In my testing on an rpi_4, this ends
> > up 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.
>
> I'm not sure the context of the two paragraphs, they seem to conflict
> with each other.
>
> > So use the control-FDT address instead.
>
> The RPi is interest as we have different DTs, the one the firmware
> provides, which is useful as it deals with things like overlays, the
> U-Boot one we've typically not used or one loaded from disk which is
> generally the upstream Linux kernel one, how does this change address
> that? I have concerns this will change the logic overall. Does it?
>
> > 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.
>
> Could you answer my query above and rebase?

Yes, I've made a note to do this and should get to it in early Sept.

Regards,
Simon