Figure out a better way to pass the device tree

riscvarchive / riscv-edk2-platforms

Port of EDK2 implementation of UEFI to RISC-V. See documentation at:

https://github.com/riscv/riscv-uefi-edk2-docs

Other

18 stars 7 forks source link

Figure out a better way to pass the device tree #18

Closed JohnAZoidberg closed 2 years ago

JohnAZoidberg commented 3 years ago

It can't be in Platform/RISC-V/PlatformPkg/Universal/Sec/Riscv64/SecEntry.S because that's shared between platforms.
~Should we really embed it in the FW vol and passed through from SEC to the EFI config table? U-Boot also embeds it. It has to come from somewhere. And OpenSBI might want to fix it up during sbi_init~
OpenSBI definitely needs it during sbi_init, so we must have access to it in SEC

JohnAZoidberg commented 3 years ago

Need to figure out that soon because I split the platforms into their own files but Platform/RISC-V/PlatformPkg/Universal/Sec/Riscv64/SecEntry.S is shared between them all. That's why U540 can't boot here: https://github.com/riscv/riscv-edk2-platforms/actions/runs/813246401

JohnAZoidberg commented 3 years ago

It would probably also be good not to commit the DTB in the repo but build it from source.

JohnAZoidberg commented 3 years ago

OpenSBI has three options:

Takes the device tree path during build and embeds it into the binary, like we do
Gets it in arg0 from the previous stage (how we give the DT to it)
Read it from a predefined address somewhere in memory

JohnAZoidberg commented 3 years ago

Will do it just like ARM: Platform/AMD/OverdriveBoard/DeviceTree/. Build infrastructure is already there.

Put device tree sources in module that compiles it
Put it either on separate FV or in existing one

JohnAZoidberg commented 2 years ago

Will do it just like ARM: Platform/AMD/OverdriveBoard/DeviceTree/. Build infrastructure is already there.
* Put device tree sources in module that compiles it

* Put it either on separate FV or in existing one

Done. Put in separate FV.