Hi Gerd,
Part 2 has been be merged, I'm separating this Lib into two serve the PEI stage and DXE stage.
Currently, This DXE library uses three global
variables, and when I simulate the no-mmio version: MmioLib.c +
Dxe.c + Pei.c, I can abstract some helper functions as the
public functions in Mmio version.
Do you mind if I replace these three vaiables with
three dynamically typed PCDs? If so, the PEI and DXE stage
libraries can using some of the same APIs.
Hi Gerd,
On 2024/3/21 19:39, Gerd Hoffmann wrote:
OK, I'm going to do the plan B next and commit it with the next version, which will probably be called "Part 3 patch set, enable LoongArchVirtQemu in OvmfPkg".Hi,QemuFwCfgLibMmio.inf is looks like a DXE stage library, while this patch is the PEI stage library we are dicussing. I have tow plans: *Plan A:* Keep this library under LoongArchQemuVirt. *Plan B:* Create a new INF named QemuFwCfgPeiLibMmio.inf under OvmfPkg/Library/QemuFwCfgLib/, which will obtain the resources from FDT, and store them in the HOB or dynamic PCD. Which one do you like? I'm leaning toward B because more people will be served if it's under OvmfPkg/Library.Yes, Plan (b) is better. Also try avoid code duplication. The existing code can be splitted into two files. Move the code which works in DXE only (i.e. the bits using FdtClientProtocol to find the fw_cfg mmio address, maybe more) to QemuFwCfgLibMmioDxe.c, keep the code which can work for both PEI and DXE in QemuFwCfgLibMmio.c. Add QemuFwCfgLibMmioPei.c for the PEI-specific code. The ioport version of the library uses the same approach with QemuFwCfgLib.c + QemuFwCfgDxe.c + QemuFwCfgPei.c
take care, Gerd