Back in May 2023, when we were handling versioning changes, I added set
of SMC calls between TF-A and EDK2 to share hardware details (instead of
parsing DeviceTree in EDK2).
I think that it is time to move forward and drop DeviceTree support from
EDK2 completely.
# what for we use DT now?
There are few things we read from DT in EDK2 now:
- cpu count
- cpu mpidr value
- cpu numa node id
- memory nodes (with numa node ids)
# initial code
I took a look at it, created some tickets [1] in Linaro Jira and wrote
some initial code for checking cpu count (will send to ML).
1. https://linaro.atlassian.net/browse/SRCPC-156
# ideas for next steps
For mpidr/numa I have some ideas. I was thinking of adding function in
sbsa_sip_svc.c which would count cpus (using code I already have) and
then malloc() memory for cpu struct { id, mpidr, node_id } for each cpu.
And similar for memory nodes: read DT, alloc structures, fill them.
When EDK2 does SMC call to get cpu data like mpidr/node_id code will go
through allocated structures and return single data. Again, similar for
memory nodes.
The funny part: DT is somewhere in memory during BL3*, we provide it for
EDK2 at start of memory but I probably do something wrong when trying to
access it during BL3*.
Current data gathering reads DT from BL2 memory before MMU kicks in.
# things for the future
Adding SPM would require additional calls. So far I only created ticket
[2] for it without looking into details.
2. https://linaro.atlassian.net/browse/SRCPC-165
# call for opinions
What are your opinions about it? Ideas? Someone maybe already considered it?
When SaSbQemu platform is configured with multi memory nodes,like numa architecture, os will ignore any memory node in the device tree except the first one.The kernel reads UEFI memory map for memory information when booting via UEFI.However UEFI only allocates the first memory node memory space for SbsaQemu platform, in this scenario we can full use of HighMemDxe to add memory spaces for other memory nodes.
Changes in V2:
- Modify the the execution order of PlatformPeiLib moodule after memory initialization
xiongyining1480 (3):
SbsaQemu: Use HighMemDxe provided by OvmfPkg
SbsaQemu: Use FdtClientDxe provided by EmbeddedPkg
SbsaQemu: Add PlatformPeiLib library
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 8 ++-
Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 2 +
.../Library/PlatformPeiLib/PlatformPeiLib.c | 63 +++++++++++++++++++
.../Library/PlatformPeiLib/PlatformPeiLib.inf | 41 ++++++++++++
4 files changed, 113 insertions(+), 1 deletion(-)
create mode 100644 Silicon/Qemu/SbsaQemu/Library/PlatformPeiLib/PlatformPeiLib.c
create mode 100644 Silicon/Qemu/SbsaQemu/Library/PlatformPeiLib/PlatformPeiLib.inf
--
2.34.1
