u-boot.git/boot, branch v2025.01-rc1

Merge patch series "Implement ACPI on aarch64"

2024-10-28T00:44:13+00:00

Patrick Rudolph  says:

Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.

The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.

The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.

The changes were tested on real hardware as well on QEMU v9.0:

qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
                    -pflash secure-world.rom \
                    -pflash unsecure-world.rom

qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic

Tested against FWTS V24.03.00.

Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
  USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
  cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
  Linux kernel module doesn't support ACPI yet.

Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com

serial: serial_pl01x: Implement .getinfo() for PL01

2024-10-27T23:24:12+00:00

When ACPI is enabled on arm it will use the getinfo function to fill
the SPCR ACPI table.

Signed-off-by: Maximilian Brune 
Reviewed-by: Simon Glass 
Cc: Simon Glass 
Cc: Tom Rini 
Reviewed-by: Moritz Fischer

Merge tag 'u-boot-imx-master-20241025a' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx

2024-10-26T00:51:05+00:00

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/22989

- Remove unneeded USB board code and fix reset on mx6ul_14x14_evk.
- Update fastboot buffer size/address for verdin-imx8m{m|p}.
- Fix imxrt1050-evk boot and convert it to standard boot.
- Fix imx8qxp-mek and imx8qm-mek boot.
- Add support for the i.MX93 9X9 QSB board.
- Make livetree API to work on i.MX.
- Set sane default value for i.MX8M SPL_LOAD_FIT_ADDRESS.
- Deduplicate DH i.MX8MP/i.MX6 DHSOM defconfigs.
- Select default TEXT_BASE for i.MX6/i.MX7.
- Several updates for DH i.MX8MP DRC02.

Merge tag 'u-boot-dfu-20241025' of https://source.denx.de/u-boot/custodians/u-boot-dfu

2024-10-25T14:35:56+00:00

CI: https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/22962

Dfu:
- Rely on device tree for spi speed/mode on spi flash

Android Image:
- Fix booting on platforms having > 4GiB of memory
- Decompress boot image to kernel_addr_r when compression is enabled
- Honor CONFIG_SYS_LOAD_ADDR when mkbootimg uses default address

Bcb:
- Rework bcb command to use U_BOOT_LONGHELP
- Move ab_select cmd to bcb cmd
- Implement ab_dump command in bcb
- bcb: Write '_' instead of '' to misc partition

imx8m: set sane default value for SPL_LOAD_FIT_ADDRESS

2024-10-25T12:07:48+00:00

I enabled IMX_HAB on an imx8mp board, but even though I knew about the
implementation, I forgot that I had to provide a sane value for
SPL_LOAD_FIT_ADDRESS. The help text for IMX_HAB doesn't mention this
implicit requirement, and there's no build-time warning; the default
0x0 value just ends up being returned from
board_spl_fit_buffer_addr(), obviously resulting in a non-booting
board.

The existing imx8m* board configs that set a non-zero value currently
all use 0x44000000. The actual value doesn't matter too much, but 0 is
always wrong for imx8m platforms. So just use 0x44000000 as default
for those platforms.

Signed-off-by: Rasmus Villemoes

boot: Introduce BOOTSTD_MENU to control bootflow menu build

2024-10-24T17:19:55+00:00

The bootflow_menu.c code depends on e.g. scene_txt_set_font(),
which is only built when CONFIG_EXPO is enabled. Introduce new
Kconfig symbol BOOTSTD_MENU which depends on EXPO to prevent
triggering errors like these in case e.g. CONFIG_VIDEO=n :

"
boot/bootflow_menu.c:158:(.text+0x8851): undefined reference to `scene_txt_set_font'
"

Make the symbol depend on BOOTSTD_FULL as well to get rid of
the Makefile dependency workaround. Since BOOTSTD_FULL is not
available in SPL, do not define SPL variant of BOOTSTD_MENU.

Fix up bootflow test accordingly.

Signed-off-by: Marek Vasut 
Reviewed-by: Simon Glass

image: android: handle ramdisk default address

2024-10-24T07:48:14+00:00

The two tools that create android boot images, mkbootimg and the fastboot
client, set the kernel address by default to 0x11008000.

U-boot always honors this field, and will try to copy the ramdisk to
whatever value is set in the header, which won't be mapped to the actual
RAM on most platforms, resulting in the kernel obviously not booting.

All the targets in U-Boot right now will download the android boot image
to CONFIG_SYS_LOAD_ADDR, which means that it will already have been
downloaded to some location that is suitable to use the ramdisk in-place
for header version 0 to 2. For header version 3 and later, the ramdisk
can't be used in-place to use ramdisk_addr_r in this case.

Signed-off-by: Neil Armstrong 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Guillaume La Roque 
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-3-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek

image: android: do not boot XIP when kernel is compressed

2024-10-24T07:48:14+00:00

When trying to boot an android boot image with a compressed
kernel, if the kernel is used in-place because it was created
with mkbootimg, the space will be too small to properly
uncompress.

Take in account the compressed state, and if compressed
use the kernel_addr_r which should be big enough.

Signed-off-by: Neil Armstrong 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Guillaume La Roque 
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-2-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek

image: android: use ulong for kernel address

2024-10-24T07:48:14+00:00

When booting with platforms having > 4GiB of memory,
the kernel physical address can be more than 32bits.

Use ulong like all the other addresses, and fix the
print to show the > 32bits address numbers.

Signed-off-by: Neil Armstrong 
Reviewed-by: Mattijs Korpershoek 
Tested-by: Guillaume La Roque 
Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-1-c3927102d931@linaro.org
Signed-off-by: Mattijs Korpershoek

common: android_ab: fix slot suffix for abc block

2024-10-24T07:45:55+00:00

To align with the official Android BCB (Bootloader Control Block)
specifications, it's important to note that the slot_suffix should start
with an underscore symbol.

For a comprehensive understanding of the expected slot_suffix format in
userspace, please refer to the provided reference [1].

Links:
[1] - https://source.android.com/docs/core/architecture/bootloader/updating#slots

Based-on: https://android-review.googlesource.com/c/platform/external/u-boot/+/1446439
Reviewed-by: Mattijs Korpershoek 
Reviewed-by: Simon Glass 
Tested-by: Guillaume La Roque 
Signed-off-by: Dmitry Rokosov 
Tested-by: Mattijs Korpershoek  # vim3_android
Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-6-43bfcc096d95@salutedevices.com
Signed-off-by: Mattijs Korpershoek