diff options
| author | Laszlo Ersek <lersek@redhat.com> | 2017-03-17 15:47:35 +0300 |
|---|---|---|
| committer | Laszlo Ersek <lersek@redhat.com> | 2017-03-28 15:10:46 +0300 |
| commit | 65a69b21484056794165e5a884e3142120ad61fc (patch) | |
| tree | d8a86fa6bd9a0aa21a0a6bd6475a095caa216639 /BaseTools/Source/Python/Workspace/MetaFileParser.py | |
| parent | 786f476323a6795354aa3269c556c8c234525052 (diff) | |
| download | edk2-65a69b21484056794165e5a884e3142120ad61fc.tar.xz | |
EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID
The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with a Device
Tree-based hardware description. This is not necessarily exclusive with
other types of hardware description (for example, an ACPI-based one).
A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.
In the DXE phase, the protocol is meant to be consumed by the platform
driver that
- owns the Device Tree description of the hardware, and
- is responsible for installing it as a system configuration table.
Said FDT-owner driver can wait for the protocol via DEPEX or protocol
notify.
Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere (for example in MdeModulePkg and SecurityPkg).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@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>
Diffstat (limited to 'BaseTools/Source/Python/Workspace/MetaFileParser.py')
0 files changed, 0 insertions, 0 deletions
