Device Tree Creation and Support between OpenSBI, Boot, and Linux

Our open source project, GitHub - IBM/ACE-RISCV: Assured confidential execution (ACE) implements VM-based trusted execution environment (TEE) for RISC-V with focus on a formally verified and auditable security monitor., is developing a provable security monitor for RISC-V with hypervisor mode, that support confidential computing. This is a proof of concept for part of the CoVE spec that is currently in the approval process. The monitor runs in M-mode, (we compile it with OpenSBI). It must physically partition the system memory into confidential and non-confidential memory. We are currently using PMP (as has been done by other researchers). The general challenge we have is that we do not understand how the device tree is used by OpenBMC and Uboot, and how it is passed between them and the Kernel. Note, we made various modifications to the Device tree in OpenBMC and noticed that they were not observed by Uboot. Similarly, modifications made in Uboot were not observed by the Linux kernel.
Q: Is there any documentation on the device tree interfaces between OpenBMC and Uboot and between Uboot and the Kernal? Thanks

I assume you are talking about OpenSBI, not OpenBMC. Every vendor/board has different boot flow. I’m not sure if you are talking specifically about P550 or riscv boards in general. The following are all based on my current understanding, and I’m not a Sifive developer.

For P550, there’s no uboot SPL, and there’s a single binary generated with OpenSBI build that carries the uboot dtb + uboot.bin as the dtb and payload. OpenSBI and uboot both carry its own dtb. (They can be using the same dtb, but this is how uboot on Premier P550 is configured now). The reason uboot knows about OpenSBI memory reservation is due to uboot’s CONFIG_OF_BOARD_FIXUP, which copies the memory reservation entries from the dtb OpenSBI passed to uboot to the one uboot’s using. Kernel dtbs are on disk, and when uboot loads the kernel dtb, again it can fixes up kernel dtb by copies over the reservations. Basically you just need to ensure uboot picks up the dtb fixups/reservations done by OpenSBI. Check uboot build config. I think the following option should do the right thing:
CONFIG_OF_SEPARATE=y + CONFIG_OF_BOARD_FIXUP=y or
CONFIG_OF_BOARD=y

Ganboing, Thanks for your response. You are correct, I was talking about OpenSBI. We will check this out.

Hi Bo Gan,

We were debugging the execution of Uboot and memory access to the memory region restricted with PMP occurred in this piece of code [1] invoked by [2]. Please note that we defined an additional custom PMP rule in OpenSBI to cover a memory region crucial for our firmware.

[1] iterates over memory range defined as RAM base and RAM size. The code reads/writes memory addresses across the whole memory range. The memory range is defined in eic7700 specific code, see [2]. The DRAM size is hardcoded:
#define DDR_SIZE_MAX 0x800000000

After we changed the DDR_SIZE_MAX to a lower number, such that it does not cover our memory range restricted with PMP, the get_ram_size() did no longer triggered a problem.

What I would expect is that the code iterates rather over ranges of memory that are not defined as restricted in FDT. We were using refs/heads/u-boot-2024.01-EIC7X in GitHub - eswincomputing/u-boot

[1]: long get_ram_size(long *base, long maxsize) function located in common/memsize.c.
[2]: int dram_init() function locates in arch/riscv/cpu/eic7700/dram.c