* [PATCH v5 17/25] arm: qemu: Add an SPL build
2025-05-28 12:32 [PATCH v5 00/25] passage: Define a standard for firmware data flow Simon Glass
@ 2025-05-28 12:32 ` Simon Glass
2025-05-28 12:32 ` [PATCH v5 18/25] arm: qemu: Add a 64-bit " Simon Glass
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2025-05-28 12:32 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: François Ozog, Tom Rini, Ilias Apalodimas, Bill Mills,
Raymond Mao, Heinrich Schuchardt, Andrew Phelps, Simon Glass,
Albert Aribaud, Jerome Forissier, Matthias Brugger,
Patrice Chotard, Patrick Delaunay, Patrick Rudolph, Peter Maydell,
Tuomas Tynkkynen, Vincent Stehlé, qemu-devel
Add an SPL build for qemu so we can test the standard passage feature.
Include a binman definition so that SPL and U-Boot are in the same image.
This requires adding a proper devicetree file for qemu_arm. It is only
used for the SPL build.
Avoid using the QEMU devicetree in U-Boot proper, so we can obtain it
from standard passage.
For now this just boots and hangs in SPL as there is no bloblist.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Drop common.h
- Refresh the U-Boot output in the documentation
- Use bootph tags
arch/arm/dts/qemu-arm-u-boot.dtsi | 22 ++
arch/arm/dts/qemu-arm.dts | 393 ++++++++++++++++++++++++++-
arch/arm/mach-qemu/Kconfig | 12 +-
board/emulation/qemu-arm/Kconfig | 26 +-
board/emulation/qemu-arm/MAINTAINERS | 13 +-
board/emulation/qemu-arm/Makefile | 1 +
board/emulation/qemu-arm/qemu-arm.c | 3 +
board/emulation/qemu-arm/spl.c | 26 ++
configs/qemu_arm_spl_defconfig | 82 ++++++
doc/board/emulation/qemu-arm.rst | 47 ++++
10 files changed, 617 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi
create mode 100644 board/emulation/qemu-arm/spl.c
create mode 100644 configs/qemu_arm_spl_defconfig
diff --git a/arch/arm/dts/qemu-arm-u-boot.dtsi b/arch/arm/dts/qemu-arm-u-boot.dtsi
new file mode 100644
index 00000000000..abf69272afb
--- /dev/null
+++ b/arch/arm/dts/qemu-arm-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/ {
+ binman {
+ u-boot-spl {
+ size = <0x10000>;
+ };
+
+ u-boot {
+ };
+ };
+
+ pl011@9000000 {
+ bootph,pre-ram;
+ };
+
+};
diff --git a/arch/arm/dts/qemu-arm.dts b/arch/arm/dts/qemu-arm.dts
index 230c630f04f..5743902b41b 100644
--- a/arch/arm/dts/qemu-arm.dts
+++ b/arch/arm/dts/qemu-arm.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+ OR MIT
/*
- * Empty device tree for qemu_arm
+ * Sample device tree for qemu_arm
* Copyright 2021 Google LLC
*/
@@ -8,4 +8,395 @@
/dts-v1/;
/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0x84000005>;
+ cpu_on = <0x84000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0x84000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ gpio-keys {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ compatible = "gpio-keys";
+
+ poweroff {
+ gpios = <0x8003 0x03 0x00>;
+ linux,code = <0x74>;
+ label = "GPIO Key Poweroff";
+ };
+ };
+
+ pl061@9030000 {
+ phandle = <0x8003>;
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x07 0x04>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x00 0x9030000 0x00 0x1000>;
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x00000000 0x3f000000 0x00000000 0x01000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0x0f>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031", "arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk", "apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011", "arm,primecell";
+ };
+
+ pmu {
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a15";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
};
diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
index 9c06c6a3a5c..292c5f65c8e 100644
--- a/arch/arm/mach-qemu/Kconfig
+++ b/arch/arm/mach-qemu/Kconfig
@@ -14,6 +14,15 @@ config TARGET_QEMU_ARM_32BIT
select CPU_V7A
select SYS_ARCH_TIMER
+config TARGET_QEMU_ARM_32BIT_SPL
+ bool "ARMv7-A, 32bit with SPL"
+ select ARCH_SUPPORT_PSCI
+ select BOARD_LATE_INIT
+ select CPU_V7A
+ select SYS_ARCH_TIMER
+ select SPL
+ select BINMAN
+
config TARGET_QEMU_ARM_64BIT
bool "ARMv8, 64bit"
select ARM64
@@ -26,9 +35,10 @@ config TARGET_QEMU_ARM_SBSA
select BOARD_LATE_INIT
select ENABLE_ARM_SOC_BOOT0_HOOK
select MISC_INIT_R
+
endchoice
-if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
+if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT || TARGET_QEMU_ARM_32BIT_SPL
config SYS_BOARD
default "qemu-arm"
diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index 80ab9d8e1c3..2a8f052c0da 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -1,7 +1,4 @@
-if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
-
-config TEXT_BASE
- default 0x00000000
+if ARCH_QEMU && !TARGET_QEMU_ARM_SBSA
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
@@ -12,6 +9,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply VIRTIO_PCI
imply VIRTIO_NET
imply VIRTIO_BLK
+ select SUPPORT_SPL
config PRE_CON_BUF_ADDR
hex
@@ -19,10 +17,28 @@ config PRE_CON_BUF_ADDR
endif
+if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
+
+config TEXT_BASE
+ default 0x00000000
+
+endif
+
if TARGET_QEMU_ARM_64BIT && !TFABOOT
config BOARD_SPECIFIC_OPTIONS
imply SYS_MTDPARTS_RUNTIME
imply SET_DFU_ALT_INFO
-source "board/emulation/common/Kconfig"
endif
+
+if TARGET_QEMU_ARM_32BIT_SPL
+
+config SPL_TEXT_BASE
+ default 0x00000000
+
+config TEXT_BASE
+ default 0x00010000
+
+endif
+
+source "board/emulation/common/Kconfig"
diff --git a/board/emulation/qemu-arm/MAINTAINERS b/board/emulation/qemu-arm/MAINTAINERS
index 538769f8040..54682d6c0af 100644
--- a/board/emulation/qemu-arm/MAINTAINERS
+++ b/board/emulation/qemu-arm/MAINTAINERS
@@ -5,5 +5,16 @@ F: board/emulation/qemu-arm/
F: board/emulation/common/
F: include/configs/qemu-arm.h
F: include/configs/qemu-sbsa.h
-F: configs/qemu_arm*
+F: configs/qemu_arm_defconfig
+F: configs/qemu_arm64_acpi_defconfig
+F: configs/qemu_arm64_defconfig
F: configs/qemu-arm-sbsa_defconfig
+
+QEMU ARM 'VIRT' BOARD
+M: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
+S: Maintained
+F: board/emulation/qemu-arm/
+F: board/emulation/common/
+F: include/configs/qemu-arm.h
+F: include/configs/qemu-sbsa.h
+F: configs/qemu_arm_spl_defconfig
diff --git a/board/emulation/qemu-arm/Makefile b/board/emulation/qemu-arm/Makefile
index a22d1237ff4..54635646e07 100644
--- a/board/emulation/qemu-arm/Makefile
+++ b/board/emulation/qemu-arm/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += qemu-arm.o
+obj-$(CONFIG_SPL_BUILD) += spl.o
diff --git a/board/emulation/qemu-arm/qemu-arm.c b/board/emulation/qemu-arm/qemu-arm.c
index 31f5a775137..5d73d02bee2 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -152,6 +152,9 @@ int dram_init_banksize(void)
int board_fdt_blob_setup(void **fdtp)
{
/* QEMU loads a generated DTB for us at the start of RAM. */
+ if (CONFIG_IS_ENABLED(OF_PASSAGE))
+ return -EEXIST;
+
*fdtp = (void *)CFG_SYS_SDRAM_BASE;
return 0;
diff --git a/board/emulation/qemu-arm/spl.c b/board/emulation/qemu-arm/spl.c
new file mode 100644
index 00000000000..afef76b90f2
--- /dev/null
+++ b/board/emulation/qemu-arm/spl.c
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Google LLC
+ * Written by Simon Glass <sjg@chromium.org>
+ */
+
+#include <cpu_func.h>
+#include <spl.h>
+#include <asm/spl.h>
+
+u32 spl_boot_device(void)
+{
+ return BOOT_DEVICE_BOARD;
+}
+
+static int spl_qemu_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev)
+{
+ spl_image->name = "U-Boot";
+ spl_image->load_addr = spl_get_image_pos();
+ spl_image->entry_point = spl_get_image_pos();
+ flush_cache(spl_image->load_addr, spl_get_image_size());
+
+ return 0;
+}
+SPL_LOAD_IMAGE_METHOD("QEMU", 0, BOOT_DEVICE_BOARD, spl_qemu_load_image);
diff --git a/configs/qemu_arm_spl_defconfig b/configs/qemu_arm_spl_defconfig
new file mode 100644
index 00000000000..9c4408dc73c
--- /dev/null
+++ b/configs/qemu_arm_spl_defconfig
@@ -0,0 +1,82 @@
+CONFIG_ARM=y
+CONFIG_SYS_ICACHE_OFF=y
+CONFIG_SYS_DCACHE_OFF=y
+CONFIG_ARM_SMCCC=y
+CONFIG_ARCH_QEMU=y
+CONFIG_SYS_MALLOC_LEN=0x1000000
+CONFIG_BLOBLIST_SIZE_RELOC=0x2000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x40200000
+CONFIG_ENV_SIZE=0x40000
+CONFIG_ENV_SECT_SIZE=0x40000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm"
+CONFIG_TARGET_QEMU_ARM_32BIT_SPL=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SYS_BOOTM_LEN=0x4000000
+CONFIG_SYS_LOAD_ADDR=0x40200000
+CONFIG_DEBUG_UART_BASE=0x9000000
+CONFIG_DEBUG_UART_CLOCK=0
+CONFIG_ARMV7_LPAE=y
+CONFIG_ENV_ADDR=0x4000000
+CONFIG_QEMU_MANUAL_DTB=y
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_FIT_BEST_MATCH=y
+CONFIG_BOOTSTD_FULL=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_USE_PREBOOT=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_PCI_INIT_R=y
+CONFIG_BLOBLIST=y
+CONFIG_SPL_FRAMEWORK_BOARD_INIT_F=y
+CONFIG_SPL_NO_BSS_LIMIT=y
+CONFIG_CMD_BOOTEFI_SELFTEST=y
+CONFIG_CMD_NVEDIT_EFI=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_TPM=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_BOARD=y
+CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_SPL_DM=y
+CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_DFU_TFTP=y
+CONFIG_DFU_MTD=y
+CONFIG_DFU_RAM=y
+# CONFIG_MMC is not set
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_SHOW_PROGRESS=0
+CONFIG_CFI_FLASH=y
+CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SYS_MAX_FLASH_SECT=256
+CONFIG_SYS_MAX_FLASH_BANKS=2
+CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
+CONFIG_E1000=y
+CONFIG_NVME_PCI=y
+CONFIG_PCIE_ECAM_GENERIC=y
+CONFIG_SCSI=y
+CONFIG_DEBUG_UART_PL011=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_CMD_POWEROFF=y
+CONFIG_SYSRESET_PSCI=y
+CONFIG_TPM2_MMIO=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_PCI=y
+CONFIG_TPM=y
+CONFIG_UNIT_TEST=y
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 1c91c7f3ac6..a8a1ba0e0f9 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -38,6 +38,11 @@ Set the CROSS_COMPILE environment variable as usual, and run:
make qemu_arm64_defconfig
make
+- for ARM with SPL::
+
+ make qemu_arm_spl_defconfig
+ make
+
Running U-Boot
--------------
The minimal QEMU command line to get U-Boot up and running is:
@@ -50,6 +55,10 @@ The minimal QEMU command line to get U-Boot up and running is:
qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin
+- For ARM with SPL::
+
+ qemu-system-arm -machine virt -nographic -bios image.bin
+
Note that for some odd reason qemu-system-aarch64 needs to be explicitly
told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument
ensures that output appears on the terminal. Use Ctrl-A X to quit.
@@ -191,6 +200,44 @@ Enable the TPM on U-Boot's command line with::
tpm autostart
+SPL Description
+---------------
+
+As you see above, running the SPL build is a little different, since there are
+two binaries to load into memory: SPL and U-Boot proper. Binman is used to
+produce the combined `image.bin` containing these. See
+`arch/arm/dts/qemu-arm-u-boot.dtsi` for the definition. A custom loader called
+`spl_qemu_load_image()` is used to access the U-Boot binary from within SPL.
+
+A sample run is shown below, using the build-qemu-sh script. Note that the
+devicetree is passed via standard passage::
+
+ $ ./scripts/build-qemu.sh -a arm -rsxw
+ Running qemu-system-arm -machine virt -accel tcg -display none -serial mon:stdio
+
+ U-Boot SPL 2025.04-01115-g0b14f5ab2aa1 (Apr 17 2025 - 09:39:51 -0600)
+ Trying to boot from QEMU
+
+
+ U-Boot 2025.04-01115-g0b14f5ab2aa1 (Apr 17 2025 - 09:39:51 -0600)
+
+ DRAM: 128 MiB
+ using memory 0x466aa000-0x476ea000 for malloc()
+ Core: 48 devices, 12 uclasses, devicetree: passage
+ Flash: 64 MiB
+ Loading Environment from Flash... *** Warning - bad CRC, using default environment
+
+ In: serial,usbkbd
+ Out: serial,vidconsole
+ Err: serial,vidconsole
+ No USB controllers found
+ Net: No ethernet found.
+
+ starting USB...
+ No USB controllers found
+ Hit any key to stop autoboot: 0
+ =>
+
Debug UART
----------
--
2.43.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v5 18/25] arm: qemu: Add a 64-bit SPL build
2025-05-28 12:32 [PATCH v5 00/25] passage: Define a standard for firmware data flow Simon Glass
2025-05-28 12:32 ` [PATCH v5 17/25] arm: qemu: Add an SPL build Simon Glass
@ 2025-05-28 12:32 ` Simon Glass
2025-05-28 14:25 ` [PATCH v5 00/25] passage: Define a standard for firmware data flow Tom Rini
2025-06-13 22:27 ` (subset) " Tom Rini
3 siblings, 0 replies; 9+ messages in thread
From: Simon Glass @ 2025-05-28 12:32 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: François Ozog, Tom Rini, Ilias Apalodimas, Bill Mills,
Raymond Mao, Heinrich Schuchardt, Andrew Phelps, Simon Glass,
Albert Aribaud, Jerome Forissier, Patrick Rudolph, Peter Maydell,
Tuomas Tynkkynen, qemu-devel
Add an 64-bit SPL build for qemu so we can test the standard passage
feature.
Include a binman definition so that SPL and U-Boot are in the same image.
This requires adding a proper devicetree file for qemu_arm. It is only
used for the SPL build.
Avoid using the QEMU devicetree in U-Boot proper, so we can obtain it
from standard passage.
For now this just boots and hangs in SPL as there is no bloblist.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Add a build for aarch64 as well
arch/arm/dts/qemu-arm64-u-boot.dtsi | 29 ++
arch/arm/dts/qemu-arm64.dts | 387 ++++++++++++++++++++++++++-
arch/arm/mach-qemu/Kconfig | 10 +-
board/emulation/qemu-arm/Kconfig | 5 +-
board/emulation/qemu-arm/MAINTAINERS | 1 +
configs/qemu_arm64_spl_defconfig | 90 +++++++
doc/board/emulation/qemu-arm.rst | 41 ++-
7 files changed, 558 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/dts/qemu-arm64-u-boot.dtsi
create mode 100644 configs/qemu_arm64_spl_defconfig
diff --git a/arch/arm/dts/qemu-arm64-u-boot.dtsi b/arch/arm/dts/qemu-arm64-u-boot.dtsi
new file mode 100644
index 00000000000..31847e9518e
--- /dev/null
+++ b/arch/arm/dts/qemu-arm64-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/ {
+ binman {
+ u-boot-spl {
+ size = <0x10000>;
+ };
+
+ u-boot {
+ };
+ };
+
+ pl011@9000000 {
+ bootph,pre-ram;
+ };
+
+ pl031@9010000 {
+ bootph,pre-ram;
+ };
+
+ pl061@9030000 {
+ bootph,pre-ram;
+ };
+};
diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
index 95fcf53ed74..62e29cb01fb 100644
--- a/arch/arm/dts/qemu-arm64.dts
+++ b/arch/arm/dts/qemu-arm64.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+ OR MIT
/*
- * Empty device tree for qemu_arm64
+ * Device tree for qemu_arm64
* Copyright 2021 Google LLC
*/
@@ -13,3 +13,388 @@
/ {
};
+
+#ifdef CONFIG_TARGET_QEMU_ARM_64BIT_SPL
+
+/ {
+ interrupt-parent = <0x00008002>;
+ model = "linux,dummy-virt";
+ #size-cells = <0x00000002>;
+ #address-cells = <0x00000002>;
+ compatible = "linux,dummy-virt";
+ psci {
+ migrate = <0xc4000005>;
+ cpu_on = <0xc4000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0xc4000001>;
+ method = "hvc";
+ compatible = "arm,psci-1.0", "arm,psci-0.2", "arm,psci";
+ };
+ memory@40000000 {
+ reg = <0x00000000 0x40000000 0x00000000 0x08000000>;
+ device_type = "memory";
+ };
+ platform-bus@c000000 {
+ interrupt-parent = <0x00008002>;
+ ranges = <0x00000000 0x00000000 0x0c000000 0x02000000>;
+ #address-cells = <0x00000001>;
+ #size-cells = <0x00000001>;
+ compatible = "qemu,platform", "simple-bus";
+ };
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00000000 0x09020000 0x00000000 0x00000018>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000010 0x00000001>;
+ reg = <0x00000000 0x0a000000 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000011 0x00000001>;
+ reg = <0x00000000 0x0a000200 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000012 0x00000001>;
+ reg = <0x00000000 0x0a000400 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000013 0x00000001>;
+ reg = <0x00000000 0x0a000600 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000014 0x00000001>;
+ reg = <0x00000000 0x0a000800 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000015 0x00000001>;
+ reg = <0x00000000 0x0a000a00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000016 0x00000001>;
+ reg = <0x00000000 0x0a000c00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000017 0x00000001>;
+ reg = <0x00000000 0x0a000e00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000018 0x00000001>;
+ reg = <0x00000000 0x0a001000 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001200 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000019 0x00000001>;
+ reg = <0x00000000 0x0a001200 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000001a 0x00000001>;
+ reg = <0x00000000 0x0a001400 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000001b 0x00000001>;
+ reg = <0x00000000 0x0a001600 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000001c 0x00000001>;
+ reg = <0x00000000 0x0a001800 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000001d 0x00000001>;
+ reg = <0x00000000 0x0a001a00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000001e 0x00000001>;
+ reg = <0x00000000 0x0a001c00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000001f 0x00000001>;
+ reg = <0x00000000 0x0a001e00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000020 0x00000001>;
+ reg = <0x00000000 0x0a002000 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000021 0x00000001>;
+ reg = <0x00000000 0x0a002200 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000022 0x00000001>;
+ reg = <0x00000000 0x0a002400 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000023 0x00000001>;
+ reg = <0x00000000 0x0a002600 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000024 0x00000001>;
+ reg = <0x00000000 0x0a002800 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000025 0x00000001>;
+ reg = <0x00000000 0x0a002a00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000026 0x00000001>;
+ reg = <0x00000000 0x0a002c00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000027 0x00000001>;
+ reg = <0x00000000 0x0a002e00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000028 0x00000001>;
+ reg = <0x00000000 0x0a003000 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00000000 0x00000029 0x00000001>;
+ reg = <0x00000000 0x0a003200 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000002a 0x00000001>;
+ reg = <0x00000000 0x0a003400 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000002b 0x00000001>;
+ reg = <0x00000000 0x0a003600 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000002c 0x00000001>;
+ reg = <0x00000000 0x0a003800 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000002d 0x00000001>;
+ reg = <0x00000000 0x0a003a00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000002e 0x00000001>;
+ reg = <0x00000000 0x0a003c00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00000000 0x0000002f 0x00000001>;
+ reg = <0x00000000 0x0a003e00 0x00000000 0x00000200>;
+ compatible = "virtio,mmio";
+ };
+ gpio-keys {
+ compatible = "gpio-keys";
+ poweroff {
+ gpios = <0x00008004 0x00000003 0x00000000>;
+ linux,code = <0x00000074>;
+ label = "GPIO Key Poweroff";
+ };
+ };
+ pl061@9030000 {
+ phandle = <0x00008004>;
+ clock-names = "apb_pclk";
+ clocks = <0x00008000>;
+ interrupts = <0x00000000 0x00000007 0x00000004>;
+ gpio-controller;
+ #gpio-cells = <0x00000002>;
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x00000000 0x09030000 0x00000000 0x00001000>;
+ };
+ pcie@10000000 {
+ interrupt-map-mask = <0x00001800 0x00000000 0x00000000 0x00000007>;
+ interrupt-map = <0x00000000 0x00000000 0x00000000 0x00000001
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000003 0x00000004 0x00000000 0x00000000
+ 0x00000000 0x00000002 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000004 0x00000004
+ 0x00000000 0x00000000 0x00000000 0x00000003
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000005 0x00000004 0x00000000 0x00000000
+ 0x00000000 0x00000004 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000006 0x00000004
+ 0x00000800 0x00000000 0x00000000 0x00000001
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000004 0x00000004 0x00000800 0x00000000
+ 0x00000000 0x00000002 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000005 0x00000004
+ 0x00000800 0x00000000 0x00000000 0x00000003
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000006 0x00000004 0x00000800 0x00000000
+ 0x00000000 0x00000004 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000003 0x00000004
+ 0x00001000 0x00000000 0x00000000 0x00000001
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000005 0x00000004 0x00001000 0x00000000
+ 0x00000000 0x00000002 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000006 0x00000004
+ 0x00001000 0x00000000 0x00000000 0x00000003
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000003 0x00000004 0x00001000 0x00000000
+ 0x00000000 0x00000004 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000004 0x00000004
+ 0x00001800 0x00000000 0x00000000 0x00000001
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000006 0x00000004 0x00001800 0x00000000
+ 0x00000000 0x00000002 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000003 0x00000004
+ 0x00001800 0x00000000 0x00000000 0x00000003
+ 0x00008002 0x00000000 0x00000000 0x00000000
+ 0x00000004 0x00000004 0x00001800 0x00000000
+ 0x00000000 0x00000004 0x00008002 0x00000000
+ 0x00000000 0x00000000 0x00000005 0x00000004>;
+ #interrupt-cells = <0x00000001>;
+ ranges = <0x01000000 0x00000000
+ 0x00000000 0x00000000 0x3eff0000 0x00000000
+ 0x00010000 0x02000000 0x00000000 0x10000000
+ 0x00000000 0x10000000 0x00000000 0x2eff0000
+ 0x03000000 0x00000080 0x00000000 0x00000080
+ 0x00000000 0x00000080 0x00000000>;
+ reg = <0x00000040 0x10000000 0x00000000 0x10000000>;
+ msi-map = <0x00000000 0x00008003 0x00000000 0x00010000>;
+ dma-coherent;
+ bus-range = <0x00000000 0x000000ff>;
+ linux,pci-domain = <0x00000000>;
+ #size-cells = <0x00000002>;
+ #address-cells = <0x00000003>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x00008000>;
+ interrupts = <0x00000000 0x00000002 0x00000004>;
+ reg = <0x00000000 0x09010000 0x00000000 0x00001000>;
+ compatible = "arm,pl031", "arm,primecell";
+ };
+ pl011@9000000 {
+ clock-names = "uartclk", "apb_pclk";
+ clocks = <0x00008000 0x00008000>;
+ interrupts = <0x00000000 0x00000001 0x00000004>;
+ reg = <0x00000000 0x09000000 0x00000000 0x00001000>;
+ compatible = "arm,pl011", "arm,primecell";
+ };
+ pmu {
+ interrupts = <0x00000001 0x00000007 0x00000104>;
+ compatible = "arm,armv8-pmuv3";
+ };
+ intc@8000000 {
+ phandle = <0x00008002>;
+ reg = <0x00000000 0x08000000 0x00000000 0x00010000
+ 0x00000000 0x08010000 0x00000000 0x00010000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x00000002>;
+ #address-cells = <0x00000002>;
+ interrupt-controller;
+ #interrupt-cells = <0x00000003>;
+ v2m@8020000 {
+ phandle = <0x00008003>;
+ reg = <0x00000000 0x08020000 0x00000000 0x00001000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+ flash@0 {
+ bank-width = <0x00000004>;
+ reg = <0x00000000 0x00000000 0x00000000 0x04000000
+ 0x00000000 0x04000000 0x00000000 0x04000000>;
+ compatible = "cfi-flash";
+ };
+ cpus {
+ #size-cells = <0x00000000>;
+ #address-cells = <0x00000001>;
+ cpu-map {
+ socket0 {
+ cluster0 {
+ core0 {
+ cpu = <0x00008001>;
+ };
+ };
+ };
+ };
+ cpu@0 {
+ phandle = <0x00008001>;
+ reg = <0x00000000>;
+ compatible = "arm,cortex-a57";
+ device_type = "cpu";
+ };
+ };
+ timer {
+ interrupts = <0x00000001 0x0000000d 0x00000104 0x00000001
+ 0x0000000e 0x00000104 0x00000001 0x0000000b
+ 0x00000104 0x00000001 0x0000000a 0x00000104>;
+ always-on;
+ compatible = "arm,armv8-timer", "arm,armv7-timer";
+ };
+ apb-pclk {
+ phandle = <0x00008000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x016e3600>;
+ #clock-cells = <0x00000000>;
+ compatible = "fixed-clock";
+ };
+ chosen {
+ stdout-path = "/pl011@9000000";
+ rng-seed = <0x5c62d159 0x4f1ac320 0x51089618 0xfa6e4367
+ 0x5cb012b5 0xfe4e6a54 0x8c970c5d 0xeb9bec3c>;
+ kaslr-seed = <0x358a89d6 0x32217e8d>;
+ };
+};
+
+#endif
diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
index 292c5f65c8e..1aea7205da4 100644
--- a/arch/arm/mach-qemu/Kconfig
+++ b/arch/arm/mach-qemu/Kconfig
@@ -36,9 +36,17 @@ config TARGET_QEMU_ARM_SBSA
select ENABLE_ARM_SOC_BOOT0_HOOK
select MISC_INIT_R
+config TARGET_QEMU_ARM_64BIT_SPL
+ bool "ARMv8, 64bit with SPL"
+ select ARM64
+ select BOARD_LATE_INIT
+ select SPL
+ select BINMAN
+
endchoice
-if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT || TARGET_QEMU_ARM_32BIT_SPL
+if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT || \
+ TARGET_QEMU_ARM_32BIT_SPL || TARGET_QEMU_ARM_64BIT_SPL
config SYS_BOARD
default "qemu-arm"
diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index 2a8f052c0da..d35caa16d8f 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -31,7 +31,7 @@ config BOARD_SPECIFIC_OPTIONS
endif
-if TARGET_QEMU_ARM_32BIT_SPL
+if TARGET_QEMU_ARM_32BIT_SPL || TARGET_QEMU_ARM_64BIT_SPL
config SPL_TEXT_BASE
default 0x00000000
@@ -39,6 +39,9 @@ config SPL_TEXT_BASE
config TEXT_BASE
default 0x00010000
+config SPL_MAX_SIZE
+ default 0x00010000
+
endif
source "board/emulation/common/Kconfig"
diff --git a/board/emulation/qemu-arm/MAINTAINERS b/board/emulation/qemu-arm/MAINTAINERS
index 54682d6c0af..bb3168d47a7 100644
--- a/board/emulation/qemu-arm/MAINTAINERS
+++ b/board/emulation/qemu-arm/MAINTAINERS
@@ -8,6 +8,7 @@ F: include/configs/qemu-sbsa.h
F: configs/qemu_arm_defconfig
F: configs/qemu_arm64_acpi_defconfig
F: configs/qemu_arm64_defconfig
+F: configs/qemu_arm64_spl_defconfig
F: configs/qemu-arm-sbsa_defconfig
QEMU ARM 'VIRT' BOARD
diff --git a/configs/qemu_arm64_spl_defconfig b/configs/qemu_arm64_spl_defconfig
new file mode 100644
index 00000000000..a9ed47c8d3b
--- /dev/null
+++ b/configs/qemu_arm64_spl_defconfig
@@ -0,0 +1,90 @@
+CONFIG_ARM=y
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_ARCH_QEMU=y
+CONFIG_SYS_MALLOC_LEN=0x1000000
+CONFIG_BLOBLIST_SIZE_RELOC=0x2000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x40200000
+CONFIG_ENV_SIZE=0x40000
+CONFIG_ENV_SECT_SIZE=0x40000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64"
+CONFIG_TARGET_QEMU_ARM_64BIT_SPL=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x9000
+CONFIG_SYS_LOAD_ADDR=0x40200000
+CONFIG_DEBUG_UART_BASE=0x9000000
+CONFIG_DEBUG_UART_CLOCK=0
+CONFIG_ARMV8_CRYPTO=y
+CONFIG_ENV_ADDR=0x4000000
+CONFIG_QEMU_MANUAL_DTB=y
+CONFIG_PCI=y
+CONFIG_DEBUG_UART=y
+CONFIG_AHCI=y
+CONFIG_EFI_HTTP_BOOT=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_FIT_BEST_MATCH=y
+CONFIG_BOOTSTD_FULL=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_USE_PREBOOT=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_PCI_INIT_R=y
+CONFIG_BLOBLIST=y
+CONFIG_SPL_FRAMEWORK_BOARD_INIT_F=y
+CONFIG_SPL_NO_BSS_LIMIT=y
+# CONFIG_SPL_SEPARATE_BSS is not set
+CONFIG_CMD_SMBIOS=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_BOOTEFI_SELFTEST=y
+CONFIG_CMD_NVEDIT_EFI=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_MTD=y
+CONFIG_CMD_PCI=y
+CONFIG_CMD_EFIDEBUG=y
+CONFIG_CMD_TPM=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_BOARD=y
+CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_SPL_DM=y
+CONFIG_SCSI_AHCI=y
+CONFIG_AHCI_PCI=y
+CONFIG_DFU_TFTP=y
+CONFIG_DFU_MTD=y
+CONFIG_DFU_RAM=y
+# CONFIG_MMC is not set
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_SHOW_PROGRESS=0
+CONFIG_CFI_FLASH=y
+CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_SYS_MAX_FLASH_SECT=256
+CONFIG_SYS_MAX_FLASH_BANKS=2
+CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y
+CONFIG_E1000=y
+CONFIG_NVME_PCI=y
+CONFIG_PCIE_ECAM_GENERIC=y
+CONFIG_SCSI=y
+CONFIG_DEBUG_UART_PL011=y
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSINFO=y
+CONFIG_SYSINFO_SMBIOS=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_CMD_POWEROFF=y
+CONFIG_SYSRESET_PSCI=y
+CONFIG_TPM2_MMIO=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_PCI=y
+CONFIG_SEMIHOSTING=y
+CONFIG_MBEDTLS_LIB=y
+CONFIG_TPM=y
+CONFIG_TPM_PCR_ALLOCATE=y
+CONFIG_GENERATE_SMBIOS_TABLE_VERBOSE=y
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index a8a1ba0e0f9..b03cb882c86 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -43,6 +43,11 @@ Set the CROSS_COMPILE environment variable as usual, and run:
make qemu_arm_spl_defconfig
make
+- for AArch64 with SPL::
+
+ make qemu_arm64_spl_defconfig
+ make
+
Running U-Boot
--------------
The minimal QEMU command line to get U-Boot up and running is:
@@ -59,6 +64,10 @@ The minimal QEMU command line to get U-Boot up and running is:
qemu-system-arm -machine virt -nographic -bios image.bin
+- For AArch64 with SPL::
+
+ qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios image.bin
+
Note that for some odd reason qemu-system-aarch64 needs to be explicitly
told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument
ensures that output appears on the terminal. Use Ctrl-A X to quit.
@@ -215,11 +224,39 @@ devicetree is passed via standard passage::
$ ./scripts/build-qemu.sh -a arm -rsxw
Running qemu-system-arm -machine virt -accel tcg -display none -serial mon:stdio
- U-Boot SPL 2025.04-01115-g0b14f5ab2aa1 (Apr 17 2025 - 09:39:51 -0600)
+ U-Boot SPL 2025.04-01115-g0b14f5ab2aa1 (Apr 17 2025 - 06:39:51 -0600)
+ Trying to boot from QEMU
+
+
+ U-Boot 2025.04-01115-g0b14f5ab2aa1 (Apr 17 2025 - 06:39:51 -0600)
+
+ DRAM: 128 MiB
+ using memory 0x466aa000-0x476ea000 for malloc()
+ Core: 48 devices, 12 uclasses, devicetree: passage
+ Flash: 64 MiB
+ Loading Environment from Flash... *** Warning - bad CRC, using default environment
+
+ In: serial,usbkbd
+ Out: serial,vidconsole
+ Err: serial,vidconsole
+ No USB controllers found
+ Net: No ethernet found.
+
+ starting USB...
+ No USB controllers found
+ Hit any key to stop autoboot: 0
+ =>
+
+The aarch64 build is similar::
+
+ $ ./scripts/build-qemu.sh -a arm -rsxw
+ Running qemu-system-arm -machine virt -accel tcg -display none -serial mon:stdio
+
+ U-Boot SPL 2025.04-01115-g38a16f456571 (Apr 17 2025 - 06:43:50 -0600)
Trying to boot from QEMU
- U-Boot 2025.04-01115-g0b14f5ab2aa1 (Apr 17 2025 - 09:39:51 -0600)
+ U-Boot 2025.04-01115-g38a16f456571 (Apr 17 2025 - 06:43:50 -0600)
DRAM: 128 MiB
using memory 0x466aa000-0x476ea000 for malloc()
--
2.43.0
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
2025-05-28 12:32 [PATCH v5 00/25] passage: Define a standard for firmware data flow Simon Glass
2025-05-28 12:32 ` [PATCH v5 17/25] arm: qemu: Add an SPL build Simon Glass
2025-05-28 12:32 ` [PATCH v5 18/25] arm: qemu: Add a 64-bit " Simon Glass
@ 2025-05-28 14:25 ` Tom Rini
2025-05-28 14:32 ` Simon Glass
2025-06-13 22:27 ` (subset) " Tom Rini
3 siblings, 1 reply; 9+ messages in thread
From: Tom Rini @ 2025-05-28 14:25 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas,
Bill Mills, Raymond Mao, Heinrich Schuchardt, Andrew Phelps,
Alexander Graf, Boyan Karatotev, Evgeny Bachinin, Fabio Estevam,
Harrison Mutai, Jonas Karlman, Liviu Dudau, Liya Huang,
Marek Behún, Marek Mojík, Marek Vasut, Matthias Brugger,
Max Filippov, Nathan Barrett-Morrison, Nobuhiro Iwamatsu,
Patrick Delaunay, Patrick Rudolph, Peter Maydell,
Rasmus Villemoes, Rayagonda Kokatanur, Sean Anderson,
Stefan Roese, Stefano Babic, Sughosh Ganu, Svyatoslav Ryhel,
Tuomas Tynkkynen, Vincent Stehlé, Xu Zhang, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote:
>
> This series adds a standard way of passing information between different
> firmware phases. This already exists in U-Boot at a very basic level, in
> the form of a bloblist containing an spl_handoff structure, but the intent
> here is to define something useful across projects.
>
> The need for this is growing as firmware fragments into multiple binaries
> each with its own purpose. Without any run-time connection, we must rely
> on build-time settings which are brittle and painful to keep in sync.
>
> This feature is named 'standard passage' since the name is more unique
> than many others that could be chosen, it is a passage in the sense that
> information is flowing from one place to another and it is standard,
> because that is what we want to create.
>
> The implementation is mostly a pointer to a bloblist in a register, with
> an extra register to point to a devicetree, for more complex data. This
> should cover all cases (small memory footprint as well as complex data
> flow) and be easy enough to implement on all architectures.
>
> The emphasis is on enabling open communcation between binaries, not
> enabling passage of secret, undocumented data, although this is possible
> in a private environment.
>
> To try this out:
>
> $ ./scripts/build-qemu -a arm -rsx
>
> This will build and run QEMU for arm64 and you should see the standdard
> passage working:
>
> Core: 49 devices, 13 uclasses, devicetree: passage
>
> This series is available at u-boot-dm/pass-working
>
> Changes in v5:
> - Add RFC for test script
And this is why I question if you are working in good faith. I've
rejected this countless times. I'm still rejecting it. Stop including
it. Point at the version you could easily be maintaining in the contrib
repository where you have write access and no one will be telling you to
not do something. People would even review the patches since it would be
against mainline.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
2025-05-28 14:25 ` [PATCH v5 00/25] passage: Define a standard for firmware data flow Tom Rini
@ 2025-05-28 14:32 ` Simon Glass
2025-05-28 15:19 ` Tom Rini
0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2025-05-28 14:32 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas,
Bill Mills, Raymond Mao, Heinrich Schuchardt, Andrew Phelps,
Alexander Graf, Boyan Karatotev, Evgeny Bachinin, Fabio Estevam,
Harrison Mutai, Jonas Karlman, Liviu Dudau, Liya Huang,
Marek Behún, Marek Mojík, Marek Vasut, Matthias Brugger,
Max Filippov, Nathan Barrett-Morrison, Nobuhiro Iwamatsu,
Patrick Delaunay, Patrick Rudolph, Peter Maydell,
Rasmus Villemoes, Rayagonda Kokatanur, Sean Anderson,
Stefan Roese, Stefano Babic, Sughosh Ganu, Svyatoslav Ryhel,
Tuomas Tynkkynen, Vincent Stehlé, Xu Zhang, qemu-devel
Hi Tom,
On Wed, 28 May 2025 at 15:25, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote:
> >
> > This series adds a standard way of passing information between different
> > firmware phases. This already exists in U-Boot at a very basic level, in
> > the form of a bloblist containing an spl_handoff structure, but the intent
> > here is to define something useful across projects.
> >
> > The need for this is growing as firmware fragments into multiple binaries
> > each with its own purpose. Without any run-time connection, we must rely
> > on build-time settings which are brittle and painful to keep in sync.
> >
> > This feature is named 'standard passage' since the name is more unique
> > than many others that could be chosen, it is a passage in the sense that
> > information is flowing from one place to another and it is standard,
> > because that is what we want to create.
> >
> > The implementation is mostly a pointer to a bloblist in a register, with
> > an extra register to point to a devicetree, for more complex data. This
> > should cover all cases (small memory footprint as well as complex data
> > flow) and be easy enough to implement on all architectures.
> >
> > The emphasis is on enabling open communcation between binaries, not
> > enabling passage of secret, undocumented data, although this is possible
> > in a private environment.
> >
> > To try this out:
> >
> > $ ./scripts/build-qemu -a arm -rsx
> >
> > This will build and run QEMU for arm64 and you should see the standdard
> > passage working:
> >
> > Core: 49 devices, 13 uclasses, devicetree: passage
> >
> > This series is available at u-boot-dm/pass-working
> >
> > Changes in v5:
> > - Add RFC for test script
>
> And this is why I question if you are working in good faith. I've
> rejected this countless times. I'm still rejecting it. Stop including
> it. Point at the version you could easily be maintaining in the contrib
> repository where you have write access and no one will be telling you to
> not do something. People would even review the patches since it would be
> against mainline.
I fully understand that you don't want the script and I'm only
including (as an RFC) so people can actually try this series out. I
didn't want to point to my tree as I thought that would annoy you. I
already went through why the contrib tree is not suitable for me.
Please just ignore that patch. I've marked it as rejected in patchwork
and if I send a v6, I'll drop it.
Regards,
Simon
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
2025-05-28 14:32 ` Simon Glass
@ 2025-05-28 15:19 ` Tom Rini
2025-05-28 16:08 ` Simon Glass
0 siblings, 1 reply; 9+ messages in thread
From: Tom Rini @ 2025-05-28 15:19 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas,
Bill Mills, Raymond Mao, Heinrich Schuchardt, Andrew Phelps,
Alexander Graf, Boyan Karatotev, Evgeny Bachinin, Fabio Estevam,
Harrison Mutai, Jonas Karlman, Liviu Dudau, Liya Huang,
Marek Behún, Marek Mojík, Marek Vasut, Matthias Brugger,
Max Filippov, Nathan Barrett-Morrison, Nobuhiro Iwamatsu,
Patrick Delaunay, Patrick Rudolph, Peter Maydell,
Rasmus Villemoes, Rayagonda Kokatanur, Sean Anderson,
Stefan Roese, Stefano Babic, Sughosh Ganu, Svyatoslav Ryhel,
Tuomas Tynkkynen, Vincent Stehlé, Xu Zhang, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]
On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 28 May 2025 at 15:25, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote:
> > >
> > > This series adds a standard way of passing information between different
> > > firmware phases. This already exists in U-Boot at a very basic level, in
> > > the form of a bloblist containing an spl_handoff structure, but the intent
> > > here is to define something useful across projects.
> > >
> > > The need for this is growing as firmware fragments into multiple binaries
> > > each with its own purpose. Without any run-time connection, we must rely
> > > on build-time settings which are brittle and painful to keep in sync.
> > >
> > > This feature is named 'standard passage' since the name is more unique
> > > than many others that could be chosen, it is a passage in the sense that
> > > information is flowing from one place to another and it is standard,
> > > because that is what we want to create.
> > >
> > > The implementation is mostly a pointer to a bloblist in a register, with
> > > an extra register to point to a devicetree, for more complex data. This
> > > should cover all cases (small memory footprint as well as complex data
> > > flow) and be easy enough to implement on all architectures.
> > >
> > > The emphasis is on enabling open communcation between binaries, not
> > > enabling passage of secret, undocumented data, although this is possible
> > > in a private environment.
> > >
> > > To try this out:
> > >
> > > $ ./scripts/build-qemu -a arm -rsx
> > >
> > > This will build and run QEMU for arm64 and you should see the standdard
> > > passage working:
> > >
> > > Core: 49 devices, 13 uclasses, devicetree: passage
> > >
> > > This series is available at u-boot-dm/pass-working
> > >
> > > Changes in v5:
> > > - Add RFC for test script
> >
> > And this is why I question if you are working in good faith. I've
> > rejected this countless times. I'm still rejecting it. Stop including
> > it. Point at the version you could easily be maintaining in the contrib
> > repository where you have write access and no one will be telling you to
> > not do something. People would even review the patches since it would be
> > against mainline.
>
> I fully understand that you don't want the script and I'm only
> including (as an RFC) so people can actually try this series out. I
> didn't want to point to my tree as I thought that would annoy you. I
> already went through why the contrib tree is not suitable for me.
So I have to take changes that I disagree with, but you can't work with
a tree for your tooling where the community would be happy to provide
feedback? That does not sound like compromise. Again, I have trouble
believing that you are working in good faith to resolve the differences
here.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
2025-05-28 15:19 ` Tom Rini
@ 2025-05-28 16:08 ` Simon Glass
2025-05-28 17:05 ` Tom Rini
0 siblings, 1 reply; 9+ messages in thread
From: Simon Glass @ 2025-05-28 16:08 UTC (permalink / raw)
To: Tom Rini
Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas,
Bill Mills, Raymond Mao, Heinrich Schuchardt, Andrew Phelps,
Alexander Graf, Boyan Karatotev, Evgeny Bachinin, Fabio Estevam,
Harrison Mutai, Jonas Karlman, Liviu Dudau, Liya Huang,
Marek Behún, Marek Mojík, Marek Vasut, Matthias Brugger,
Max Filippov, Nathan Barrett-Morrison, Nobuhiro Iwamatsu,
Patrick Delaunay, Patrick Rudolph, Peter Maydell,
Rasmus Villemoes, Rayagonda Kokatanur, Sean Anderson,
Stefan Roese, Stefano Babic, Sughosh Ganu, Svyatoslav Ryhel,
Tuomas Tynkkynen, Vincent Stehlé, Xu Zhang, qemu-devel
Hi Tom,
On Wed, 28 May 2025 at 16:19, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote:
> > Hi Tom,
> >
> > On Wed, 28 May 2025 at 15:25, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote:
> > > >
> > > > This series adds a standard way of passing information between different
> > > > firmware phases. This already exists in U-Boot at a very basic level, in
> > > > the form of a bloblist containing an spl_handoff structure, but the intent
> > > > here is to define something useful across projects.
> > > >
> > > > The need for this is growing as firmware fragments into multiple binaries
> > > > each with its own purpose. Without any run-time connection, we must rely
> > > > on build-time settings which are brittle and painful to keep in sync.
> > > >
> > > > This feature is named 'standard passage' since the name is more unique
> > > > than many others that could be chosen, it is a passage in the sense that
> > > > information is flowing from one place to another and it is standard,
> > > > because that is what we want to create.
> > > >
> > > > The implementation is mostly a pointer to a bloblist in a register, with
> > > > an extra register to point to a devicetree, for more complex data. This
> > > > should cover all cases (small memory footprint as well as complex data
> > > > flow) and be easy enough to implement on all architectures.
> > > >
> > > > The emphasis is on enabling open communcation between binaries, not
> > > > enabling passage of secret, undocumented data, although this is possible
> > > > in a private environment.
> > > >
> > > > To try this out:
> > > >
> > > > $ ./scripts/build-qemu -a arm -rsx
> > > >
> > > > This will build and run QEMU for arm64 and you should see the standdard
> > > > passage working:
> > > >
> > > > Core: 49 devices, 13 uclasses, devicetree: passage
> > > >
> > > > This series is available at u-boot-dm/pass-working
> > > >
> > > > Changes in v5:
> > > > - Add RFC for test script
> > >
> > > And this is why I question if you are working in good faith. I've
> > > rejected this countless times. I'm still rejecting it. Stop including
> > > it. Point at the version you could easily be maintaining in the contrib
> > > repository where you have write access and no one will be telling you to
> > > not do something. People would even review the patches since it would be
> > > against mainline.
> >
> > I fully understand that you don't want the script and I'm only
> > including (as an RFC) so people can actually try this series out. I
> > didn't want to point to my tree as I thought that would annoy you. I
> > already went through why the contrib tree is not suitable for me.
>
> So I have to take changes that I disagree with, but you can't work with
> a tree for your tooling where the community would be happy to provide
> feedback? That does not sound like compromise. Again, I have trouble
> believing that you are working in good faith to resolve the differences
> here.
Yes, as mentioned before I would like you to take changes you disagree
with, at least once we have discussed alternatives and I'm sure that's
the way I want to go. It would save a lot of grief if you could do
that.
I could use your contrib/ repo but there isn't a lot of point, since I
have to have my own tree anyway, due to rejected / changes-requested
patches. It's just lots of fiddling around for no gain. I'm fine with
your not having the scripts in your tree and I'm fine with maintaining
the Python tools in my tree. Basically it seems my tree is the dumping
ground for the stuff you don't want in 'pure U-Boot', or don't want
yet. If you would like me to sync my scripts to the contrib/ tree
every now and then, yes I can do that. I don't see much point since we
can't reference them in docs or test them in CI, but I'm willing to do
it.
But I do want to post patches so I can get feedback from people who
are interested. Perhaps we could set up an 'experimental' mailing list
for that, since you seem really unhappy when I send them to the U-Boot
mailing list?
Re your 'good faith' thing, I'm really just trying to make progress
and I wish there was less 'email overhead' and more action. If you
have concerns, it would be better to discuss a resolution f2f or on a
VC, not endless email threads which don't relate to the patches I'm
sending. The series we are discussing here was sent in 2021 based on
bloblist from 2018! [1]. It is why Firmware Handoff happened. Give me
some credit for foresight, at least.
Regards,
Simon
[1] https://patchwork.ozlabs.org/project/uboot/cover/20211101011734.1614781-1-sjg@chromium.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v5 00/25] passage: Define a standard for firmware data flow
2025-05-28 16:08 ` Simon Glass
@ 2025-05-28 17:05 ` Tom Rini
0 siblings, 0 replies; 9+ messages in thread
From: Tom Rini @ 2025-05-28 17:05 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas,
Bill Mills, Raymond Mao, Heinrich Schuchardt, Andrew Phelps,
Alexander Graf, Boyan Karatotev, Evgeny Bachinin, Fabio Estevam,
Harrison Mutai, Jonas Karlman, Liviu Dudau, Liya Huang,
Marek Behún, Marek Mojík, Marek Vasut, Matthias Brugger,
Max Filippov, Nathan Barrett-Morrison, Nobuhiro Iwamatsu,
Patrick Delaunay, Patrick Rudolph, Peter Maydell,
Rasmus Villemoes, Rayagonda Kokatanur, Sean Anderson,
Stefan Roese, Stefano Babic, Sughosh Ganu, Svyatoslav Ryhel,
Tuomas Tynkkynen, Vincent Stehlé, Xu Zhang, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 5486 bytes --]
On Wed, May 28, 2025 at 05:08:38PM +0100, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 28 May 2025 at 16:19, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 28 May 2025 at 15:25, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote:
> > > > >
> > > > > This series adds a standard way of passing information between different
> > > > > firmware phases. This already exists in U-Boot at a very basic level, in
> > > > > the form of a bloblist containing an spl_handoff structure, but the intent
> > > > > here is to define something useful across projects.
> > > > >
> > > > > The need for this is growing as firmware fragments into multiple binaries
> > > > > each with its own purpose. Without any run-time connection, we must rely
> > > > > on build-time settings which are brittle and painful to keep in sync.
> > > > >
> > > > > This feature is named 'standard passage' since the name is more unique
> > > > > than many others that could be chosen, it is a passage in the sense that
> > > > > information is flowing from one place to another and it is standard,
> > > > > because that is what we want to create.
> > > > >
> > > > > The implementation is mostly a pointer to a bloblist in a register, with
> > > > > an extra register to point to a devicetree, for more complex data. This
> > > > > should cover all cases (small memory footprint as well as complex data
> > > > > flow) and be easy enough to implement on all architectures.
> > > > >
> > > > > The emphasis is on enabling open communcation between binaries, not
> > > > > enabling passage of secret, undocumented data, although this is possible
> > > > > in a private environment.
> > > > >
> > > > > To try this out:
> > > > >
> > > > > $ ./scripts/build-qemu -a arm -rsx
> > > > >
> > > > > This will build and run QEMU for arm64 and you should see the standdard
> > > > > passage working:
> > > > >
> > > > > Core: 49 devices, 13 uclasses, devicetree: passage
> > > > >
> > > > > This series is available at u-boot-dm/pass-working
> > > > >
> > > > > Changes in v5:
> > > > > - Add RFC for test script
> > > >
> > > > And this is why I question if you are working in good faith. I've
> > > > rejected this countless times. I'm still rejecting it. Stop including
> > > > it. Point at the version you could easily be maintaining in the contrib
> > > > repository where you have write access and no one will be telling you to
> > > > not do something. People would even review the patches since it would be
> > > > against mainline.
> > >
> > > I fully understand that you don't want the script and I'm only
> > > including (as an RFC) so people can actually try this series out. I
> > > didn't want to point to my tree as I thought that would annoy you. I
> > > already went through why the contrib tree is not suitable for me.
> >
> > So I have to take changes that I disagree with, but you can't work with
> > a tree for your tooling where the community would be happy to provide
> > feedback? That does not sound like compromise. Again, I have trouble
> > believing that you are working in good faith to resolve the differences
> > here.
>
> Yes, as mentioned before I would like you to take changes you disagree
> with, at least once we have discussed alternatives and I'm sure that's
> the way I want to go. It would save a lot of grief if you could do
> that.
>
> I could use your contrib/ repo but there isn't a lot of point, since I
> have to have my own tree anyway, due to rejected / changes-requested
> patches. It's just lots of fiddling around for no gain. I'm fine with
> your not having the scripts in your tree and I'm fine with maintaining
> the Python tools in my tree. Basically it seems my tree is the dumping
> ground for the stuff you don't want in 'pure U-Boot', or don't want
> yet. If you would like me to sync my scripts to the contrib/ tree
> every now and then, yes I can do that. I don't see much point since we
> can't reference them in docs or test them in CI, but I'm willing to do
> it.
>
> But I do want to post patches so I can get feedback from people who
> are interested. Perhaps we could set up an 'experimental' mailing list
> for that, since you seem really unhappy when I send them to the U-Boot
> mailing list?
>
> Re your 'good faith' thing, I'm really just trying to make progress
> and I wish there was less 'email overhead' and more action. If you
> have concerns, it would be better to discuss a resolution f2f or on a
> VC, not endless email threads which don't relate to the patches I'm
> sending. The series we are discussing here was sent in 2021 based on
> bloblist from 2018! [1]. It is why Firmware Handoff happened. Give me
> some credit for foresight, at least.
You need to decide if it's more important to work with the community or
have your way every time. You cannot have both. You need to accept that
some things you think are good ideas have been rejected or you need to
fork off from U-Boot. Or you can ask the community to take over as the
project head. If the community wants you to run things, I will step
down and just be an individual contributor again. Five months of this
experiment shows me that it's not working at all and will only be a
bigger problem as time goes on.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: (subset) [PATCH v5 00/25] passage: Define a standard for firmware data flow
2025-05-28 12:32 [PATCH v5 00/25] passage: Define a standard for firmware data flow Simon Glass
` (2 preceding siblings ...)
2025-05-28 14:25 ` [PATCH v5 00/25] passage: Define a standard for firmware data flow Tom Rini
@ 2025-06-13 22:27 ` Tom Rini
3 siblings, 0 replies; 9+ messages in thread
From: Tom Rini @ 2025-06-13 22:27 UTC (permalink / raw)
To: U-Boot Mailing List, Simon Glass
Cc: François Ozog, Ilias Apalodimas, Bill Mills, Raymond Mao,
Heinrich Schuchardt, Andrew Phelps, Alexander Graf,
Boyan Karatotev, Evgeny Bachinin, Fabio Estevam, Harrison Mutai,
Jonas Karlman, Liviu Dudau, Liya Huang, Marek Behún,
Marek Mojík, Marek Vasut, Matthias Brugger, Max Filippov,
Nathan Barrett-Morrison, Nobuhiro Iwamatsu, Patrick Delaunay,
Patrick Rudolph, Peter Maydell, Rasmus Villemoes,
Rayagonda Kokatanur, Sean Anderson, Stefan Roese, Stefano Babic,
Sughosh Ganu, Svyatoslav Ryhel, Tuomas Tynkkynen,
Vincent Stehlé, Xu Zhang, qemu-devel
On Wed, 28 May 2025 06:32:02 -0600, Simon Glass wrote:
> This series adds a standard way of passing information between different
> firmware phases. This already exists in U-Boot at a very basic level, in
> the form of a bloblist containing an spl_handoff structure, but the intent
> here is to define something useful across projects.
>
> The need for this is growing as firmware fragments into multiple binaries
> each with its own purpose. Without any run-time connection, we must rely
> on build-time settings which are brittle and painful to keep in sync.
>
> [...]
Applied to u-boot/next, thanks!
[06/25] spl: Rename jump_to_image_no_args()
commit: f73450918d66565c5efacf2bb57227ba94bdaa40
--
Tom
^ permalink raw reply [flat|nested] 9+ messages in thread