u-boot.git/board/raspberrypi, branch next

rpi: Fix DRAM size reporting to show total RAM

2025-11-28T13:50:51+00:00

The VideoCore mailbox GET_ARM_MEMORY only reports the size of the
first accessible memory region (~947 MiB on RPi4 with 8GB), not the
total RAM. This causes U-Boot to display "DRAM: 947 MiB (total 7.9 GiB)"
instead of "DRAM: 7.9 GiB".

On Raspberry Pi 4 with 8GB RAM, the memory is split across multiple
non-contiguous banks. The dram_init() function only sets gd->ram_size
to the first bank size reported by the VideoCore firmware, while
fdtdec_setup_memory_banksize() correctly populates all memory banks
from the device tree.

Fix this by updating gd->ram_size after dram_init_banksize() has
populated all memory banks, so it reflects the actual total RAM
across all banks.

Signed-off-by: Anders Roxell 
Reviewed-by: Peter Robinson

rpi: Use the U-Boot control FDT for fdt_addr

2025-11-25T09:22:12+00:00

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 
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard  # CM4 1G

rpi: Fix compilation with larger configs

2025-11-25T09:22:12+00:00

Tom reports that adding more Kconfig options fails with
board/raspberrypi/rpi/lowlevel_init.o: in function `save_boot_params':
board/raspberrypi/rpi/lowlevel_init.S:20:(.text+0x0):
relocation truncated to fit: R_AARCH64_ADR_PREL_LO21
against symbol `fw_dtb_pointer' defined in .data section
in board/raspberrypi/rpi/rpi.o
make: *** [Makefile:2029: u-boot] Error 1

Since fw_dtb_pointer lives in .data it might end up above the
+-1MB that adr can reach.
So switch over to adrp+add which has a +-4gb reach.

Reported-by: Tom Rini 
Closes: https://source.denx.de/u-boot/custodians/u-boot-raspberrypi/-/issues/2
Signed-off-by: Ilias Apalodimas 
Reviewed-by: Peter Robinson

rpi: Update environment to support booti and large initrd

2025-04-16T10:00:50+00:00

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 
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard  # CM4 1G
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard  # CM4 1G

rpi: Drop fdt_high and initrd_high

2025-04-16T10:00:50+00:00

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 
Reviewed-by: Tom Rini 
Suggested-by: Tom Rini 
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard  # CM4 1G
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard  # CM4 1G

rpi: Set bootm_size to 512MB

2025-04-16T10:00:49+00:00

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 
Reviewed-by: Tom Rini 
Suggested-by: Tom Rini 
Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard  # CM4 1G

rpi: always set fdt_addr with firmware-provided FDT address

2025-04-16T10:00:49+00:00

Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.

When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error

libfdt fdt_check_header(): FDT_ERR_BADMAGIC

Removing the fdt_addr variable in saved environment allows to boot.

With this patch set_fdt_addr() function always overwrite fdt_addr value.

[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018

Signed-off-by: Mauro Salvini 
Cc: Cédric Schieli 
Cc: Matthias Brugger

rpi: copy over uart clock-frequency in DT

2025-04-16T10:00:49+00:00

rpi5 firmware sets uart_clk clock-frequency in
the firmware and patches it to the DT, copy it
over when loading a new DT.

Signed-off-by: Bruno Leite 
Reviewed-by: Peter Robinson 
Tested-by: Peter Robinson

arm: simplify updating ACPI table header checksum

2025-04-08T21:22:56+00:00

Use acpi_update_checksum() to update table header.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Ilias Apalodimas 
Reviewed-by: Matthias Brugger

Raspberry Pi: Copy Bluetooth device address in DT

2025-03-13T11:06:16+00:00

The firmware sets local-bd-address, copy it when loading a new DT.

Signed-off-by: Fiona Klute 
Signed-off-by: Peter Robinson