]> git.proxmox.com Git - mirror_edk2.git/commit
ArmVirtPkg: add QemuFwCfgToPcdDxe
authorLaszlo Ersek <lersek@redhat.com>
Sun, 26 Jul 2015 08:02:50 +0000 (08:02 +0000)
committerjljusten <jljusten@Edk2>
Sun, 26 Jul 2015 08:02:50 +0000 (08:02 +0000)
commitd2733aa95a8625ebaad9df6ae6f6430e1e97ea36
treec602ccf8a8a527916a881bfd19b16c2995f32a10
parent3413cf56dcdbc8b3f9f814fe34dd37e7bc9a94bb
ArmVirtPkg: add QemuFwCfgToPcdDxe

Many universal DXE drivers in edk2 can be controlled by setting dynamic
PCDs. Such a PCD must be set before the consumer DXE driver is dispatched.

(In general we assume that the DXE driver will consume the PCD in its
entry point, or in the constructor of a library instance it links against.
In special cases this requirement can be relaxed a bit, if we know that
the DXE driver accesses the PCD only in a protocol member function that it
exports.)

On the QEMU platform, the PCD values to be set for the universal drivers
are frequently derived from fw_cfg files that QEMU exports.

In OvmfPkg we tend to handle this in the following way:

- For IA32 and X64, OvmfPkg provides a QemuFwCfgLib instance that is
  usable in PEI.

- In PlatformPei, fw_cfg files can be loaded and transformed to PCD
  values.

- Any DXE driver is bound to be dispatched after the PEI phase is done.

(In specific cases other ordering solutions might be possible, via Depex
or protocol notify, etc.)

In ArmVirtPkg/ArmVirtQemu, things differ a bit:

- We don't have an ArmVirtPkg-specific ("Platform") PEIM. This is actually
  a good thing for now, so let's not introduce one just for this purpose.

- Even if we had such a PEIM, it could not easily access fw_cfg: the MMIO
  addresses of the fw_cfg device are available only in the DTB that QEMU
  exports.

  (Accordingly, our QemuFwCfgLib instance is restricted to DXE_DRIVER
  modules: VirtFdtDxe parses the DTB, stores the fw_cfg addresses in PCDs,
  and then QemuFwCfgLib's constructor fetches those PCDs.)

  There are some examples in ArmVirtPkg where early code is forced to
  parse the DTB manually, but those examples are all painful, and our goal
  here (controlling universal DXE drivers) doesn't justify more of that
  pain.

Therefore, introduce a separate, minimal DXE driver that is dispatched
strictly after VirtFdtDxe (so that it can use QemuFwCfgLib), and strictly
before other DXE drivers (so that it can set dynamic PCDs for them).
Because VirtFdtDxe is already ordered with the APRIORI DXE file, it is
simplest to do the same for the new driver.

Actual fw_cfg files and PCDs shall be accessed in future patches.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18042 6f19259b-4bc3-4df7-8a09-765794883524
ArmVirtPkg/ArmVirtQemu.dsc
ArmVirtPkg/ArmVirtQemu.fdf
ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c [new file with mode: 0644]
ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf [new file with mode: 0644]