Hello build bot (Jenkins),
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/80322?usp=email
to look at the new patch set (#3).
The following approvals got outdated and were removed: Verified-1 by build bot (Jenkins)
Change subject: device_tree: Add function to get top of memory from a FDT blob ......................................................................
device_tree: Add function to get top of memory from a FDT blob
coreboot needs to figure out top of memory to place CBMEM data. On some non-x86 QEMU virtual machines, this is achieved by probing the RAM space to find where the VM starts discarding data since it's not backed by actual RAM. This behaviour seems to have changed on the QEMU side since then, VMs using the "virt" model have started raising exceptions/errors instead of silently discarding data (likely [1] for example) which has broken coreboot on these emulation boards.
The qemu-aarch64 mainboard is intended for the "virt" model and had this issue, which was fixed by using exception handlers in the RAM detection process [2].
The qemu-riscv mainboard is also for "virt" and still has this issue. There is a potential fix based on the exception handler approach [3], but it fails to build for 32-bit RISC-V. There's also a WIP attempt on parsing the in-memory device-tree that QEMU provides us [4], but it relies on unflattening which wouldn't work on romstage.
The qemu-armv7 mainboard code is intended for the "vexpress-a9" model VM which doesn't appear to suffer from this issue. Still, the issue can be observed on the ARMv7 "virt" model via a port based on qemu-aarch64.
QEMU docs for ARM and RISC-V "virt" models [5][6] recommend reading the device tree blob it provides for device information (incl. RAM size). Implement a function that parses the device tree blob to find the top of memory in order to use it in mainboard code as an alternative to probing RAM space. ARM64 code initializes CBMEM in romstage where malloc isn't available, so take care to do parsing without unflattening the blob and make the code available in romstage as well.
This assumes a single memory node with a single reg range which seems to be enough for what QEMU provides for now, support for more complex device-trees (as supported by specification) is left as future work.
[1] https://lore.kernel.org/qemu-devel/1504626814-23124-1-git-send-email-peter.m... [2] https://review.coreboot.org/c/coreboot/+/34774 [3] https://review.coreboot.org/c/coreboot/+/36486 [4] https://review.coreboot.org/c/coreboot/+/78981 [5] https://qemu-project.gitlab.io/qemu/system/arm/virt.html [6] https://qemu-project.gitlab.io/qemu/system/riscv/virt.html
Change-Id: I8bef09bc1bc4e324ebeaa37f78d67d3aa315f52c Signed-off-by: Alper Nebi Yasak alpernebiyasak@gmail.com --- M src/include/device_tree.h M src/lib/Makefile.mk M src/lib/device_tree.c 3 files changed, 102 insertions(+), 1 deletion(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/22/80322/3