h2: capture boot registers and forward a DTB address to the Linux guest - #72
Open
Brian Cain (androm3da) wants to merge 1 commit into
Open
h2: capture boot registers and forward a DTB address to the Linux guest#72Brian Cain (androm3da) wants to merge 1 commit into
Brian Cain (androm3da) wants to merge 1 commit into
Conversation
| } | ||
| r10 = add(PC,##h2_boot_params@PCREL) | ||
| memd(r10+#0) = r1:0 | ||
| dccleana(r10) // reach memory before the cache kill below |
Contributor
There was a problem hiding this comment.
Caches should be off at this point. Guess this can't hurt.
Bryan Bayerdorffer (bryanb-h2)
requested changes
Jul 28, 2026
Bryan Bayerdorffer (bryanb-h2)
left a comment
Bryan Bayerdorffer (bryanb-h2)
left a comment
Contributor
There was a problem hiding this comment.
Ok, but check failing tests.
| * boot stub. | ||
| */ | ||
| .p2align 3 | ||
| .globl h2_boot_params |
Contributor
There was a problem hiding this comment.
Rename to H2K_boot_params.
Brian Cain (androm3da)
force-pushed
the
bcain/qemu_boot-2
branch
2 times, most recently
from
August 6, 2026 15:45
b42c7ac to
70bb60e
Compare
Platform boot firmware may hand the kernel boot parameters in r1:0 at reset; a bootloader passes the generated device tree blob's physical address there. Those registers were clobbered during early init, so guests could never see them and fell back to built-in device trees. Reserve a boot parameter block at a fixed offset in the entry page -- alongside the angel mailbox area, and patchable by external tooling -- and capture r1:0 into it on the boot thread before anything clobbers them. Publish the captured words into kernel globals as boot_r0/boot_r1 once H2K_kg_init() has zeroed them, and expose those through two new info-trap operations, INFO_BOOT_R00 and INFO_BOOT_R01, appended to the enum to preserve the existing ABI. Routing through globals rather than having info.ref.c read H2K_boot_params directly keeps boot.ref.o out of the link. Referencing it there would add an archive edge that drags in globals.ref.o, create.ref.o, fatal.ref.o and vmint, which collide with the local stubs in STANDALONE tests such as kernel/vm/vmfuncs/test. loadlinux reads them, validates the address (alignment plus FDT magic), and passes it as the vmboot argument, which lands in the guest's r1:0 per the existing thread-create convention. The Linux kernel's RISC-V style boot protocol picks the DTB address up from there and adopts the generated device tree. Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
Brian Cain (androm3da)
force-pushed
the
bcain/qemu_boot-2
branch
from
August 22, 2026 15:36
70bb60e to
dede4bd
Compare
Member
Author
yeah, sorry about that - fixed now. |
Contributor
|
Please move this PR to the internal repo. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Platform boot firmware may hand the kernel boot parameters in r1:0 at reset; a bootloader passes the generated device tree blob's physical address there. Those registers were clobbered during early init, so guests could never see them and fell back to built-in device trees.
Reserve a boot parameter block at a fixed offset in the entry page -- alongside the angel mailbox area, and patchable by external tooling -- and capture r1:0 into it on the boot thread before anything clobbers them. Expose the captured values through two new info-trap operations, INFO_BOOT_R00 and INFO_BOOT_R01, appended to the enum to preserve the existing ABI.
loadlinux reads them, validates the address (alignment plus FDT magic), and passes it as the vmboot argument, which lands in the guest's r1:0 per the existing thread-create convention. The Linux kernel's RISC-V style boot protocol picks the DTB address up from there and adopts the generated device tree.