REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3683



TCG specification says BIOS should extend measurement of microcode to TPM.
However, reference BIOS is not doing this. BIOS shall extend measurement of
microcode to TPM.

Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min M Xu <min.m.xu@intel.com>
Cc: Qi Zhang <qi1.zhang@intel.com>
Signed-off-by: Longlong Yang <longlong.yang@intel.com>

The Ssdt.asl file isn't used, so delete it.

Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Peter Grehan <grehan@freebsd.org>

gcc-11 (fedora 35):

/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c: In function ?UsbIoBulkTransfer?:
/home/kraxel/projects/edk2/MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBus.c:277:12: error: ?UsbHcBulkTransfer? accessing 80 bytes in a region of size 8 [-Werror=stringop-overflow=]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642



Local functions do not need EFIAPI.

Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Ashraf Ali S <ashraf.ali.s@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642


when the module is not building in IA32 mode which will lead to building
error. when a module built-in X64 function pointer will be the size of
64bit width which cannot be fit in 32bit address which will lead to
error. to overcome this issue introducing the 2 new PCD's for the 64bit
modules can consume it. based on the which pcd platform set, use that.

Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Kuo Ted <ted.kuo@intel.com>
Cc: Duggapu Chinni B <chinni.b.duggapu@intel.com>
Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Cc: Digant H Solanki <digant.h.solanki@intel.com>
Cc: Sangeetha V <sangeetha.v@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>

For GPU passthrough support we have to initialize the console after
EfiBootManagerDispatchDeferredImages() has loaded ROMs, so call it after
this. This was the calling order before the TCG physical presence support
had to be moved and the console initialized earlier so user interaction
could be supported before processing TCG physical presence opcodes.

Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Shivanshu Goyal <shivanshu3@gmail.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>

Path doesn't exist below OvmfPkg/Bhyve, use the OvmfPkg version
instead.  Fixes build with -D NETWORK_TLS_ENABLE.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

This adds more helper functions that assist in calculating the checksum,
locating an ACPI table by signature, and updating an AML integer object.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Abner Chang <abner.chang@hpe.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3463



In V2: Fixed patch format and uncrustify cleanup

In V1: To follow the TCG CRB protocol specification, on every CRB TPM
 command completion the TPM should return to Idle state, regardless of
the CRB Idle Bypass capability reported by the TPM device.

See: TCG PC Client Device Driver Design Principles for TPM 2.0,
Version 1.0, Rev 0.27

Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3515



In V4: Fixed patch format and uncrustify cleanup

In V3: Cleaned up comments, debug prints and updated patch to use the
new debug ENUM definitions.

- Replaced EFI_D_INFO with DEBUG_INFO.
- Replaced EFI_D_VERBOSE with DEBUG_VERBOSE.

In V2: Add case to RegisterHashInterfaceLib logic

RegisterHashInterfaceLib needs to correctly handle registering the HashLib
instance supported algorithm bitmap when PcdTpm2HashMask is set to zero.

The current implementation of SyncPcrAllocationsAndPcrMask() triggers
PCR bank reallocation only based on the intersection between
TpmActivePcrBanks and PcdTpm2HashMask.

When the software HashLibBaseCryptoRouter solution is used, no PCR bank
reallocation is occurring based on the supported hashing algorithms
registered by the HashLib instances.

Need to have an additional check for the intersection between the
TpmActivePcrBanks and the PcdTcg2HashAlgorithmBitmap populated by the
HashLib instances present on the platform's BIOS.

Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2858



In V2: Fixed patch format and uncrustify cleanup

In V1: Add debug functionality to examine TPM extend operations
performed by BIOS and inspect the PCR 00 value prior to
any BIOS measurements.

Signed-off-by: Rodrigo Gonzalez del Cueto <rodrigo.gonzalez.del.cueto@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

Currently, the serial and part number of a processor are filled with
fixed PCDs. However, they may be updated dynamically according to the
information being passed from a the pre-UEFI firmware during booting.
So, this patch is to support updating these string fields from
OemMiscLib if the PCDs are empty.

Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

Typically, the information of the SMBIOS type 1/2/3 is fetched from an
FRU device during UEFI booting intead of fixed PCDs. Therefore, this
patch is to add more HII string fields in the OemMiscLib and support
updating these SMBIOS types with the strings provided by the OemMiscLib
if the PCDs are empty.

Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

This patch removes duplicate HII string definition in the
MiscSystemManufacturer.uni.

Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

This reverts commit 41d8bb30

, as it
breaks Cloud Hypervisor.

Reported-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Rename TPM_ENABLE to TPM2_ENABLE so naming is in line with the
ArmVirtPkg config option name.

Add separate TPM1_ENABLE option for TPM 1.2 support.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>

Split Tcg2ConfigPei.inf into two variants: Tcg12ConfigPei.inf with
TPM 1.2 support included and Tcg2ConfigPei.inf supporting TPM 2.0 only.
This allows x86 builds to choose whenever TPM 1.2 support should be
included or not by picking the one or the other inf file.

Switch x86 builds to Tcg12ConfigPei.inf, so they continue to
have TPM 1.2 support.

No functional change.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>

Drop TPM_CONFIG_ENABLE config option.  Including TPM support in the
build without also including the TPM configuration menu is not useful.

Suggested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>

With this in place the tpm configuration is not duplicated for each of
our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is
easier to keep them all in sync when updating the tpm configuration.

No functional change.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3769



Current FvLib will hit parse issue when encountering LARGE file, then
ignore latter ffs/section, thus causing required drivers not being
dispatched. Therefore, need to add support for EFI_FFS_FILE_HEADER2
and EFI_COMMON_SECTION_HEADER2 in FvLib to fix this issue.

Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
    Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
    Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the inf file of the module and the main module
functionnalities and update the dsc file of the package.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
    Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
    Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the TokenMapper files, allowing to retrieve a CmObj
from a token/CmObjId couple.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
    Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
    Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the TokenFixer files, allowing to update the
self-token some CmObj have.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The DynamicPlatRepo library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
    Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
    Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to retrieve
dynamic CmObjs among all CmObj (static CmObj for instance).

This patch add the TokenGenerator files.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The DynamicPlatRepoLib library allows to handle dynamically created
CmObj. The dynamic platform repository can be in the following states:
1 - Non-initialised
2 - Transient:
    Possibility to add CmObj to the platform, but not to query them.
3 - Finalised:
    Possibility to query CmObj, but not to add new.

A token is allocated to each CmObj added to the dynamic platform
repository (except for reference tokens CmObj). This allows to
retrieve dynamic CmObjs among all CmObj (static CmObj for instance).

This patch defines the library interface of the DynamicPlatRepo.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

Handle the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
id when generating an AML description of a serial port. The same
_HID/_CID as the EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550
are generated.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

Hardware information parser is an optional module defined
by the Dynamic Tables Framework. It can either parse an
XML, a Device Tree or a Json file containing the platform
hardware information to populate the platform information
repository.

FdtHwInfoParser library is an instance of a HwInfoParser
that parses a Device Tree and populates the Configuration
Manager Platform information repository.

FdtHwInfoParser library is aimed at providing a solution
for generating ACPI tables for Guest Partitions launched
by virtual machine managers (VMMs). One such use case is
Kvmtool where the Device Tree for the Guest is passed on
to the firmware by Kvmtool. The Configuration Manager for
Kvmtool firmware shall invoke the FdtHwInfoParser to parse
the Device Tree to populate the hardware information in
the Platform Info Repository. The Kvmtool Configuration
Manager can the process this information to generate the
required ACPI tables for the Guest VM.

This approach also scales well if the number of CPUs or
if the hardware configuration of the Guest partition is
varied.

FdtHwInfoParser thereby introduces 'Dynamic Tables for
Virtual Machines'.

Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=3741


Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

On platforms that implement PCIe, the PCIe configuration space
information must be described to a standards-based operating
system in the Memory mapped configuration space base address
Description (MCFG) table.

The PCIe information is described in the platform Device Tree,
the bindings for which can be found at:
- linux/Documentation/devicetree/bindings/pci/
  host-generic-pci.yaml

The FdtHwInfoParser implements a PCI configuration space Parser
that parses the platform Device Tree to create
CM_ARM_PCI_CONFIG_SPACE_INFO objects which are encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.

The platform Configuration Manager can then utilise this
information when generating the MCFG table.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The GIC Dispatcher is the top-level component that is responsible
for invoking the respective parsers for GICC, GICD, GIC MSI Frame,
GIC ITS and the GICR.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The GIC Redistributor (GICR) structure is part of the Multiple
APIC Description Table (MADT) that enables the discovery of
GIC Redistributor base addresses by providing the Physical Base
Address of a page range containing the GIC Redistributors. More
than one GICR Structure may be presented in the MADT. The GICR
structures should only be used when describing GIC version 3 or
higher.

The GIC Redistributor information is described in the platform
Device Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC Redistributor Parser that
parses the platform Device Tree to create CM_ARM_GIC_REDIST_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT table.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

Arm GIC v3/v4 optionally includes support for GIC Interrupt
Translation Service (ITS). The GIC ITS Structure is part of
the Multiple APIC Description Table (MADT) that describes
the GIC Interrupt Translation service to the OS.

The GIC Interrupt Translation Service information is described
in the platform Device Tree, the bindings for which can be
found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC ITS Parser that parses the
platform Device Tree to create CM_ARM_GIC_ITS_INFO objects which
are encapsulated in a Configuration Manager descriptor object and
added to the platform information repository.

The platform Configuration Manager can then utilise this information
when generating the MADT table.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

Arm GIC version 2 systems that support Message Signalled Interrupts
implement GICv2m MSI frame(s). Each GICv2m MSI frame consists of a
4k page which includes registers to generate message signalled
interrupts to an associated GIC distributor. The frame also includes
registers to discover the set of distributor lines which may be
signalled by MSIs from that frame. A system may have multiple MSI
frames, and separate frames may be defined for secure and non-secure
access.

A MSI Frame structure is part of the Multiple APIC Description Table
(MADT) and must only be used to describe non-secure MSI frames.

The MSI Frame information is described in the platform Device Tree,
the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a MSI Frame Parser that parses
the platform Device Tree to create CM_ARM_GIC_MSI_FRAME_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT table.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

On ARM-based systems the Generic Interrupt Controller (GIC)
manages interrupts on the system. Each interrupt is identified
in the GIC by an interrupt identifier (INTID). ACPI GSIVs map
one to one to GIC INTIDs for peripheral interrupts, whether
shared (SPI) or private (PPI). The GIC distributor provides
the routing configuration for the interrupts.

The GIC Distributor (GICD) structure is part of the Multiple
APIC Description Table (MADT) that describes the GIC
distributor to the OS. The MADT table is a mandatory table
required for booting a standards-based operating system.

The GIC Distributor information is described in the platform
Device Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC Distributor Parser that
parses the platform Device Tree to create CM_ARM_GICD_INFO
object which is encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT table.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The GIC CPU Interface (GICC) structure is part of the Multiple
APIC Description Table (MADT) that describes the interrupt model
for the platform. The MADT table is a mandatory table required
for booting a standards-based operating system.

Arm requires the GIC interrupt model, in which the logical
processors are required to have a Processor Device object in
the DSDT, and must convey each processor's GIC information to
the OS using the GICC structure.

The CPU and GIC information is described in the platform Device
Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/arm/cpus.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic.yaml
 - linux/Documentation/devicetree/bindings/interrupt-controller/
   arm,gic-v3.yaml

The FdtHwInfoParser implements a GIC CPU Interface Parser that
parses the platform Device Tree to create CM_ARM_GICC_INFO
objects which are encapsulated in a Configuration Manager
descriptor object and added to the platform information
repository.

The platform Configuration Manager can then utilise this
information when generating the MADT and the SSDT CPU
information tables.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The Microsoft Debug Port Table 2 (DBG2), the Serial Port Console
Redirector (SPCR) table are mandatory tables required for booting
a standards-based operating system. The DBG2 table is used by the
OS debugger while the SPCR table is used to configure the serial
terminal. Additionally, the serial ports available on a platform
for generic use also need to be described in DSDT/SSDT for an OS
to be able to use the serial ports.

The Arm Base System Architecture 1.0 specification a lists of
supported serial port hardware for Arm Platforms. This list
includes the following serial port UARTs:
 - SBSA/Generic UART
 - a fully 16550 compatible UART.
Along, with these the PL011 UART is the most commonly used serial
port hardware on Arm platforms.

The serial port hardware information is described in the platform
Device Tree, the bindings for which can be found at:
 - linux/Documentation/devicetree/bindings/serial/serial.yaml
 - linux/Documentation/devicetree/bindings/serial/8250.txt
 - linux/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt
 - linux/Documentation/devicetree/bindings/serial/pl011.yaml

The FdtHwInfoParser implements a Serial Port Parser that parses
the platform Device Tree to create CM_ARM_SERIAL_PORT_INFO objects
with the following IDs:
 - EArmObjSerialConsolePortInfo (for use by SPCR)
 - EArmObjSerialDebugPortInfo (for use by DBG2)
 - EArmObjSerialPortInfo (for use as generic Serial Ports)

The Serial Port for use by SPCR is selected by parsing the Device
Tree for the '/chosen' node with the 'stdout-path' property. The
next Serial Port is selected for use as the Debug Serial Port and
the remaining serial ports are used as generic serial ports.

The CM_ARM_SERIAL_PORT_INFO objects are encapsulated in Configuration
Manager descriptor objects with the respective IDs and are added to
the platform information repository.

The platform Configuration Manager can then utilise this information
when generating the DBG2, SPCR and the SSDT serial port tables.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The Generic Timer Description Table (GTDT) is a mandatory table
required for booting a standards-based operating system. It
provides an OSPM with information about a system's Generic Timer
configuration. The Generic Timer (GT) is a standard timer interface
implemented on ARM processor-based systems. The GTDT provides OSPM
with information about a system's GT interrupt configurations, for
both per-processor timers, and platform (memory-mapped) timers.

The Generic Timer information is described in the platform Device
Tree. The Device Tree bindings for the Generic timers can be found
at:
 - linux/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml

The FdtHwInfoParser implements a Generic Timer Parser that parses
the platform Device Tree to create a CM_ARM_GENERIC_TIMER_INFO
object. The CM_ARM_GENERIC_TIMER_INFO object is encapsulated in a
Configuration Manager descriptor object and added to the platform
information repository.

The platform Configuration Manager can then utilise this information
when generating the GTDT table.

Note: The Generic Timer Parser currently does not support parsing
of memory-mapped platform timers.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The Fixed ACPI Description Table (FADT) is a mandatory table
required for booting a standards-based operating system. The
FADT table has an 'ARM Boot Architecture Flags' field that is
used by an OS at boot time to determine the code path during
boot. This field is used to specify if the platform complies
with the PSCI specification. It is also used to describe the
conduit (SMC/HVC) to be used for PSCI.

The PSCI compliance information for a platform is described
in the platform Device Tree, the bindings for which can be
found at:
 - linux/Documentation/devicetree/bindings/arm/psci.yaml

The FdtHwInfoParser implements a Boot Arch Parser that parses
the platform Device Tree to create a CM_ARM_BOOT_ARCH_INFO
object. The CM_ARM_BOOT_ARCH_INFO object is encapsulated in
a Configuration Manager descriptor object and added to the
platform information repository.

The platform Configuration Manager can then utilise this
information when generating the FADT table.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

The FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration Manager
objects.

Therefore, add a set of helper functions to simplify parsing of
the platform Device Tree.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>

FdtHwInfoParserLib is an instance of the HwInfoParser. The
FdtHwInfoParser parses a platform Device Tree and populates
the Platform Information repository with Configuration
Manager objects that describe the platform hardware.
These Configuration Manager objects are encapsulated in
Configuration Manager Object Descriptors.

Therefore, add helper functions to create and free the
Configuration Manager Object descriptors.

Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>