qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v5 00/25] passage: Define a standard for firmware data flow
@ 2025-05-28 12:32 Simon Glass
  2025-05-28 12:32 ` [PATCH v5 17/25] arm: qemu: Add an SPL build Simon Glass
                   ` (3 more replies)
  0 siblings, 4 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,
	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


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
- Add new patch to drop bloblist_maybe_init()
- Enable the test for any board which uses OF_PASSAGE
- Use OF_PASSAGE here instead of OF_BLOBLIST

Changes in v4:
- Add new patch to update vexpress_fvp to use the new Kconfig options
- Drop now-unused label
- Fix 'to' typo
- Update commit message to indicate this can only be for ARM at present
- Update commit message to mention why save_boot_params() is not used

Changes in v3:
- Add a build for aarch64 as well
- Add conditions to avoid enaling the test on qemu_arm_sbsa
- Add mention of QEMU_MANUAL_DTB in doc/
- Add new patch to adjust how the bloblist is received from stdpass
- Add new patch to redo how a devicetree is set up
- Add passage_valid() to decide if stdpass was provided
- Add support for a 64-bit test also
- Add support for aarch64 also
- Add test for aarch64
- Add tests for azure
- Drop common.h
- Fix 'that' typo
- Fix 'usiing' typo
- Make the global_data fields present only when needed
- Move arch_passage_entry() into this patch
- Move passage.h into this patch
- Rebase to -master
- Refresh the U-Boot output in the documentation
- Update docs for the various code changes
- Update registers to match the Firmware Handoff protocol
- Use bootph tags

Changes in v2:
- Add a devicetree for qemu-arm so that qemu_arm_spl can work
- Add a new QEMU-specific Kconfig instead
- Add comments about how to pass standard passage to EFI
- Add comments about passing a bloblist to Linux
- Add detailed arch-specific information
- Add new patch with the arm-specific standard passage implementation
- Fix 'it' typo
- Make the stdpass calling standard arch-specific
- Move patch into the standard-passage series
- Rebase on -master
- Rebase to master
- Rebase to master (dropping bloblist patches already applied)
- Rework global_data for new stdpass convention
- Split the jump_to_image_no_args() change into its own patch
- Update the commit message to mention the long lines
- Use three registers instead of two for the entry

Simon Glass (25):
  RFC: scripts: Add scripts for running QEMU
  RFC: scripts: build-qemu: Support xPL with ARM
  emulation: fdt: Allow using U-Boot's device tree with QEMU
  spl: Tidy up the header includes
  x86: Move Intel GNVS file into the common include directory
  spl: Rename jump_to_image_no_args()
  passage: Support an incoming passage
  fdt: Redo devicetree setup
  fdt: Support reading FDT from standard passage
  bloblist: Adjust how the bloblist is received from passage
  bloblist: Drop bloblist_maybe_init()
  passage: arm: Accept a passage from the previous phase
  passage: spl: Support adding the dtb to the passage bloblist
  passage: spl: Support passing the passage to U-Boot
  passage: arm: Add the arch-specific standard passage impl
  vexpress_fvp: Update to use the new Kconfig options
  arm: qemu: Add an SPL build
  arm: qemu: Add a 64-bit SPL build
  xferlist: Drop old xferlist code
  passage: Add a qemu test for ARM
  sandbox: Add a way of checking structs for standard passage
  passage: Add documentation
  passage: Add docs for spl_handoff
  passage: Add checks for pre-existing blobs
  CI: Add tests for gitlab and azure

 .azure-pipelines.yml                          |   6 +
 .gitlab-ci.yml                                |  12 +
 MAINTAINERS                                   |  10 +
 Makefile                                      |   2 +-
 arch/arm/Kconfig                              |   2 +-
 arch/arm/cpu/armv7/cpu.c                      |  18 +
 arch/arm/cpu/armv7/start.S                    |  10 +-
 arch/arm/cpu/armv8/cpu.c                      |  19 +
 arch/arm/cpu/armv8/start.S                    |  12 +
 arch/arm/dts/qemu-arm-u-boot.dtsi             |  22 +
 arch/arm/dts/qemu-arm.dts                     | 393 +++++++++++++++-
 arch/arm/dts/qemu-arm64-u-boot.dtsi           |  29 ++
 arch/arm/dts/qemu-arm64.dts                   | 387 +++++++++++++++-
 arch/arm/lib/Makefile                         |   1 -
 arch/arm/lib/crt0.S                           |   6 +
 arch/arm/lib/crt0_64.S                        |   6 +
 arch/arm/lib/xferlist.c                       |  23 -
 arch/arm/lib/xferlist.h                       |  19 -
 arch/arm/mach-imx/imx8ulp/soc.c               |   2 +-
 arch/arm/mach-imx/spl.c                       |   2 +-
 arch/arm/mach-omap2/boot-common.c             |   2 +-
 arch/arm/mach-qemu/Kconfig                    |  20 +-
 arch/arm/mach-tegra/spl.c                     |   2 +-
 arch/mips/lib/spl.c                           |   2 +-
 arch/riscv/lib/spl.c                          |   2 +-
 arch/sandbox/cpu/spl.c                        |   4 +-
 arch/x86/cpu/apollolake/acpi.c                |   2 +-
 arch/x86/cpu/intel_common/acpi.c              |   2 +-
 .../include/asm/arch-apollolake/global_nvs.h  |   2 +-
 arch/x86/lib/spl.c                            |   2 +-
 arch/x86/lib/tpl.c                            |   2 +-
 board/emulation/common/Kconfig                |  12 +
 board/emulation/qemu-arm/Kconfig              |  29 +-
 board/emulation/qemu-arm/MAINTAINERS          |  14 +-
 board/emulation/qemu-arm/Makefile             |   1 +
 board/emulation/qemu-arm/qemu-arm.c           |   3 +
 board/emulation/qemu-arm/spl.c                |  26 ++
 board/freescale/common/fsl_chain_of_trust.c   |   2 +-
 board/google/chromebook_coral/coral.c         |   2 +-
 board/renesas/common/rcar64-spl.c             |   2 +-
 board/sandbox/Makefile                        |   3 +-
 board/sandbox/stdpass_check.c                 | 104 +++++
 common/Kconfig                                |  58 ++-
 common/bloblist.c                             | 116 ++---
 common/board_f.c                              |  17 +-
 common/spl/spl.c                              | 112 +++--
 configs/qemu_arm64_spl_defconfig              |  95 ++++
 configs/qemu_arm_spl_defconfig                |  88 ++++
 configs/vexpress_fvp_bloblist_defconfig       |   4 +-
 doc/board/armltd/vexpress64.rst               |   2 +-
 doc/board/emulation/qemu-arm.rst              |  84 ++++
 doc/develop/bloblist.rst                      |   4 +-
 doc/develop/devicetree/dt_qemu.rst            |   8 +
 doc/develop/index.rst                         |   1 +
 doc/develop/std_passage.rst                   | 384 ++++++++++++++++
 drivers/usb/gadget/f_sdp.c                    |   2 +-
 dts/Kconfig                                   |  17 +-
 env/common.c                                  |   2 +-
 include/asm-generic/global_data.h             |  37 ++
 include/bloblist.h                            |  42 +-
 include/fdtdec.h                              |   4 +-
 include/handoff.h                             |  10 +-
 .../x86/include/asm => include}/intel_gnvs.h  |   0
 include/passage.h                             |  53 +++
 include/spl.h                                 |   4 +-
 include/stdpass/README                        |   4 +
 include/stdpass/tpm2_eventlog.h               |  42 ++
 include/stdpass/vboot_ctx.h                   | 267 +++++++++++
 lib/asm-offsets.c                             |   8 +
 lib/fdtdec.c                                  |  43 +-
 scripts/Makefile.xpl                          |   2 +-
 scripts/build-efi                             | 173 +++++++
 scripts/build-qemu                            | 424 ++++++++++++++++++
 scripts/build_helper.py                       | 126 ++++++
 test/py/tests/test_passage.py                 |  11 +
 75 files changed, 3179 insertions(+), 286 deletions(-)
 create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi
 create mode 100644 arch/arm/dts/qemu-arm64-u-boot.dtsi
 delete mode 100644 arch/arm/lib/xferlist.c
 delete mode 100644 arch/arm/lib/xferlist.h
 create mode 100644 board/emulation/qemu-arm/spl.c
 create mode 100644 board/sandbox/stdpass_check.c
 create mode 100644 configs/qemu_arm64_spl_defconfig
 create mode 100644 configs/qemu_arm_spl_defconfig
 create mode 100644 doc/develop/std_passage.rst
 rename {arch/x86/include/asm => include}/intel_gnvs.h (100%)
 create mode 100644 include/passage.h
 create mode 100644 include/stdpass/README
 create mode 100644 include/stdpass/tpm2_eventlog.h
 create mode 100644 include/stdpass/vboot_ctx.h
 create mode 100755 scripts/build-efi
 create mode 100755 scripts/build-qemu
 create mode 100644 scripts/build_helper.py
 create mode 100644 test/py/tests/test_passage.py

-- 
2.43.0

base-commit: 2f3766949bbea7aa5a472157561d387fd94205d2
branch: pass5


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [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

end of thread, other threads:[~2025-06-13 22:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 ` [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
2025-05-28 16:08       ` Simon Glass
2025-05-28 17:05         ` Tom Rini
2025-06-13 22:27 ` (subset) " Tom Rini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).