On Fri, Aug 03, 2018 at 11:26:41AM +0200, Ard Biesheuvel wrote: > On 3 August 2018 at 11:23, Peter Maydell <[email protected]> wrote: > > On 3 August 2018 at 10:21, Hongbo Zhang <[email protected]> wrote: > >> The 'sbsa' machine won't consume QEMU generated ACPI, so it won't > >> touch or add new ACPI tables. > >> > >> UEFI relies on its ACPI to load OS, but currently it still needs DT > >> from QEMU to pass some info, one example is CPU number. > >> > >> So, the 'sbsa' code implementation should be like this: > >> A separate file, no ACPI codes, a little necessary DT codes. > >> > >> "Necessary DT codes" doesn't include so many peripheral devices nodes, > >> so the code overlap with virt won't be so much (contrary to sbsa.c > >> with all the DT codes), then no need to separate the common part to a > >> third file, and virt.c can be untouched or only a minor change with > >> few lines. > > > > Would the real hardware you are trying to be an example > > for use DT for this? It seems a bit unlikely to me. > > > > Yes, as a matter of fact. There is work underway both on the EDK2 and > the ARM-TF side to rely less on static descriptions, and more on DT to > instantiate drivers and ACPI tables at runtime rather than at build > time.
Hi Ard, (A bit off-topic, but related to your comment above.) I started poking at teaching ArmVirtQemu how to get the base of RAM from the DTB, where the DTB is passed to it through x1 (QEMU needed a few new lines to ensure x1 had it in the firmware=y,-kernel=no case too). I have the assembler written, but I got hung up on the integration with edk2, because I don't understand the build files well enough yet to swap in ArmVirtPkg/PrePi/AArch64/ModuleEntryPoint.S for the ArmVirtQemu platform. I would also need to clean up the assembler a bit before posting. I'll be out-of-office for all next week, but if you send me some edk2 pointers in the meantime, then I should be able to post an RFC the following week. Thanks, drew
