h2: capture boot registers and forward a DTB address to the Linux guest#72
Open
Brian Cain (androm3da) wants to merge 2 commits into
Open
h2: capture boot registers and forward a DTB address to the Linux guest#72Brian Cain (androm3da) wants to merge 2 commits into
Brian Cain (androm3da) wants to merge 2 commits into
Conversation
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. Signed-off-by: Brian Cain <brian.cain@oss.qualcomm.com>
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
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.