RISC-V OpenSBI FW_DYNAMIC: Pass Next-Stage Information Through the Correct Handoff ABI
An earlier loader places OpenSBI and its intended successor in memory, then jumps into an FW_DYNAMIC image. Boot stops before the successor is reached. Loading the two binaries is only part of this firmware variant's contract: the previous stage must also supply a correctly laid-out information structure through the expected register.
FW_DYNAMIC discovers the next stage at runtime. Inspect that handoff object and its lifetime before changing the successor's entry code.
Pass the information address in a2
The OpenSBI v1.9 FW_DYNAMIC guide specifies a struct fw_dynamic_info in memory, with its address passed in a2. That address must be eight-byte aligned on RV64 and four-byte aligned on RV32.
The structure describes the next stage; its own address is not the next-stage entry address. Confusing those two values can make the firmware interpret instruction bytes as header fields or later jump to a metadata buffer.
The caller must leave the information readable while the early firmware consumes it. A temporary object whose storage is overwritten by relocation or stack reuse is not a valid handoff merely because the pointer was correct at the branch instruction.
Use the target-width structure layout
The tagged FW_DYNAMIC header defines consecutive unsigned long fields: magic, version, next address, next mode, options and, for version 2, preferred boot hart. Assembly offsets scale with __SIZEOF_LONG__.
For example, the next-address field sits at byte offset 8 on RV32 and 16 on RV64. These offsets follow the selected ABI width; they are not interchangeable serialized layouts. A host tool generating this object must encode the target's layout rather than dumping its own native C structure without checking.
The header's expected magic is 0x4942534f, and v1.9 supports information versions through 2. Use a defined supported layout and the documented mode constants. A plausible address and a numerically small version do not establish that the complete input is valid.
Early checks are narrower than whole-handoff validation
In the v1.9 FW_DYNAMIC assembly, fw_boot_hart reads the magic and version directly through a2; mismatch or a version above the supported maximum branches to the hang path. Later code saves the next address, mode and options, and conditionally reads the version-2 boot-hart field.
These instructions explain an early failure before normal diagnostics are available. They are not a complete validator for arbitrary pointers, memory extents, executable destinations or trustworthy payloads. Validate the object and loaded images in the previous stage's supported boot design.
The assembly separately saves the incoming a1 as the next stage's argument. Supplying dynamic information in a2 does not replace the successor's separate argument contract, such as the platform's device-tree handoff.
Preferred boot hart affects relocation ownership
The version-2 boot_hart field exists for more than selecting a favored CPU. The header describes a case where the previous stage uses the same link address as FW_DYNAMIC: relocation can overwrite that earlier stage while other harts are still executing it.
A loader can identify the last hart that will enter FW_DYNAMIC as the preferred boot hart, avoiding that particular relocation race. Setting the field to -1UL selects the firmware's relocation lottery mechanism instead. Choose this policy from the actual multi-hart handoff, not simply the first CPU number in a board description.
A proposed inspection records the image variant, a2 address, alignment, target-width fields, successor entry and boot-hart policy before transfer. It also checks that the metadata and predecessor execution remain valid through early consumption. No OpenSBI image was built, loaded or booted here.
