Add LOONGARCH64 support to DynamicTablesPkg by adding it to the existing
common component build list, adding the LoongArch64 DynamicTableManagerDxe
source, and enabling the SMBIOS generators used by current LoongArch
platforms.
Keep DynamicTableFactoryDxe generator registration architecture-specific.
The LoongArch64 factory instance links selected NULL generator libraries so
their constructors register the generators at runtime.
LoongArch64-specific tables can use AcpiRawLib initially and move to
dedicated LoongArch64 generators in follow-up patches.
Signed-off-by: Dongyan Qian <qiandongyan@loongson.cn>
BuildSmbiosTable() and BuildSmbiosTableEx() callback are called
with uninitialized pointers which might contain garbage data. If
one of these function fails, the exit handler uses these
uninitialized fields.
Set these uninitialized pointers in the caller function.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Direct dependency to AcpiTableDxe and was replaced with
EfiCreateProtocolNotifyEvent and later the same approach was followed
for SmbiosDxe. The callback function is called at least once even if the
protocol is not available at the event installation time and in such
case module just proceeds to build tables/records and fails due to
missing dependency. Handle this situation correctly by not treating
AcpiTableProtocol or SmbiosProtocol availability as an error in event
callbacks.
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
Fixes: Fixes: a4492241a7 ("DynamicTablesPkg: Move ACPI building & change DEPEX on protocol")
Replace traditional `#ifndef`/`#define`/`#endif` include guards with
`#pragma` once.
`#pragma once` is a widely supported preprocessor directive that
prevents header files from being included multiple times. It is
supported by all toolchains used to build edk2: GCC, Clang/LLVM, and
MSVC.
Compared to macro-based include guards, `#pragma once`:
- Eliminates the risk of macro name collisions or copy/paste errors
where two headers inadvertently use the same guard macro.
- Eliminate inconsistency in the way include guard macros are named
(e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.).
- Reduces boilerplate (three lines replaced by one).
- Avoids polluting the macro namespace with guard symbols.
- Can improve build times as the preprocessor can skip re-opening the
file entirely, rather than re-reading it to find the matching
`#endif` ("multiple-include optimization").
- Note that some compilers may already optimize traditional include
guards, by recognzining the idiomatic pattern.
This change is made acknowledging that overall portability of the
code will technically be reduced, as `#pragma once` is not part of the
C/C++ standards.
However, this is considered acceptable given:
1. edk2 already defines a subset of supported compilers in
BaseTools/Conf/tools_def.template, all of which have supported
`#pragma once` for over two decades.
2. There have been concerns raised to the project about inconsistent
include guard naming and potential macro collisions.
Approximate compiler support dates:
- MSVC: Supported since Visual C++ 4.2 (1996)
- GCC: Supported since 3.4 (2004)
(http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html)
- Clang (LLVM based): Since initial release in 2007
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Add RISC-V-specific mAcpiVerifyTables entries to enable verification of
RISC-V ACPI tables during Dynamic Table Manager execution.
This ensures that RISC-V ACPI tables such as MADT, RHCT, and others are
properly validated and integrated at runtime.
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
BuildAndInstallMultipleSmbiosTables() can dereference a NULL pointer if the
SMBIOS table builder returns a NULL CmObjToken array.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
Add the SMBIOS Table generator code to the DynamicTablesPkg.
This change includes adding new logic to the DynamicTableManager
to process and add SMBIOS tables and augmenting the existing SMBIOS
Factory generator to include installing multiple SMBIOS tables.
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>
In preparation to introduce Dynamic SMBIOS support the
following 2 changes are required:
1. Use ProtocolNotify Event for generating the ACPI tables
and don't include the ACPI protocol in the Depex section
for DynamicTableManagerDxe Driver.
This is because if a platforms doesn't do ACPI based boot or if
doesn't want to install SMBIOS tables we still want the
DynamicTableManager to be dispatched to install the SMBIOS or ACPI
tables respectively.
2. Split the logic for building the ACPI tables to a separate file.
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>
Some SMBIOS tables do not have a fixed dependency and can depend on any
other SMBIOS tables. Therefore, the SMBIOS dispatcher cannot define a
fixed sequence for dispatching these tables. A possible solution is to
defer the dispatch of such SMBIOS tables towards the end, assuming that
the dependent SMBIOS tables would have been dispatched by then.
Therefore, introduce a dispatch order attribute such that SMBIOS tables
that have a fixed dependency sequence are configured as Default Ordered,
and the SMBIOS tables that do not have a fixed dependency have an Order
attribute specifying an Order Level. An Order Level is used to sequence
the dispatch of Ordered SMBIOS tables.
The Default Ordered SMBIOS tables are dispatched first and a dependency
walk is performed to dispatch the dependent tables by iterating through
the SMBIOS_TABLE_DISPATCHER.Dependency[].
Once all Default ordered SMBIOS tables have been dispatched, the Ordered
SMBIOS tables would be scheduled for dispatch in increasing order as of
the Order Level, e.g. OrderL1, OrderL2, ...
Note: The dispatcher does not perform a dependency walk for the Ordered
SMBIOS tables as the expectation is that the dependent SMBIOS tables
would be already dispatched.
A top level dispatch function DispatchSmbiosTables() has been introduced
to schedule the dispatch of Default Ordered and Ordered SMBIOS tables.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jose Marinho <Jose.Marinho@arm.com>
Update the SMBIOS table dispatcher dependency table to add the
table dependencies for SMBIOS table Type 19, Type 20, Type 27,
Type 35 and Type 37.
The SMBIOS table Type 35 can have dependency on 6 other SMBIOS
tables. Therefore, increase the MAX_SMBIOS_DEPENDENCY to 6, and
also update the SMBIOS table dispatcher table accordingly.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jose Marinho <Jose.Marinho@arm.com>
Some SMBIOS structure/table fields have dependency on other SMBIOS
structures/tables. These dependencies are established using handles
pointing to the dependent tables.
A SMBIOS table handle can be obtained by either installing a SMBIOS
table or by allocating a handle, which requires complex management
to avoid any clashes.
Obtaining a SMBIOS handle by installation requires that the dependent
table is installed before the parent SMBIOS table can be installed.
Therefore, introduce a SMBIOS table dispatcher that walks the SMBIOS
dependency list and schedules the dependent tables to be installed
before the parent table is installed.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Cc: Girish Mahadevan <gmahadevan@nvidia.com>
Cc: Jeff Brasen <jbrasen@nvidia.com>
Cc: Ashish Singhal <ashishsingha@nvidia.com>
Cc: Nick Ramirez <nramirez@nvidia.com>
Cc: William Watson <wwatson@nvidia.com>
Cc: Abner Chang <abner.chang@amd.com>
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jose Marinho <Jose.Marinho@arm.com>
edk2 is dropping support for the ARM32 architecture. This
commit removes ARM32 code from DynamicTablesPkg. This also
drops irrelevant VALID_ARCHITECTURES comments from infs that
are not arch specific.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
All DynamicTablesPkg libraries and drivers execute in the DXE phase,
where both AMD and Intel platforms operate in X64 (64-bit) mode.
Therefore, IA32 (32-bit) support is no longer required for DynamicTablesPkg.
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
The newly added MetadataObjLib allows to store information either:
- generated by the DynamictTablesPkg framework
- provided by a ConfigurationManager
- parsed from another source of information
This information might be subject to validation/verification.
This step can only be done once the firmware tables generated
by the DynamictTablesPkg have been generated.
Add a new GetMetadataRoot() callback to the
EDKII_DYNAMIC_TABLE_FACTORY_PROTOCOL. This callback allows
to fetch the Metadata Root, allowing to access all the Metadata
information generated. This Metadata is then validated by the
DynamicTableManagerDxe.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Adds X64 specific GetAcpiTablePresenceInfo() function,
which checks for mandatory ACPI tables.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Mandatory ACPI tables depend on the architectures.
Different architectures might also want to check other tables.
Move mAcpiVerifyTables containing the list of ACPI tables to check
to an arch specific file and introduce GetAcpiTablePresenceInfo()
to get get the relevant information from the array.
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3997
This change added an extra step to allow check for installed ACPI tables.
For FADT, MADT, GTDT, DSDT, DBG2 and SPCR tables, either pre-installed or
supplied through AcpiTableInfo can be accepted.
An extra check for FADT ACPI table existence during installation step is
also added.
Cc: Sami Mujawar <Sami.Mujawar@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Co-authored-by: Joe Lopez <joelopez@microsoft.com>
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@Arm.com>
Tested-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the DynamicTablesPkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The edk2 BaseTools report a warning if a local header file
is not listed under the [Sources] section in the INF file.
Add header files to the [Sources] section in the respective
INF files to fix the warnings.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
VS2017 reports 'warning C4028: formal parameter 2 different
from declaration' for the library constructor and destructor
interfaces for the Generator modules. VS2017 compiler also
reports similar warnings for the DXE entry points.
Remove the CONST qualifier for the SystemTable pointer (the
second parameter to the constructor/destructor/DXE Entry
point) to make it compatible with the formal declaration.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
This patch was originally merged in edk2 master at
bde673b2dc. However, this was
later reverted at 7d180efeaa
as it was merged during the Soft Feature Freeze for
edk2-stable201903.
Resubmitting this patch as the edk2 merge window is now open.
Updated the Protocols section to reflect the protocols
that are produced or consumed.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Alexei Fedorov <alexei.fedorov@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
This reverts commit bde673b2dc.
Reverting this patch as Soft Feature Freeze for
edk2-stable201903 started on 22 Feb 2019.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Alexei Fedorov <alexei.fedorov@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
Updated the Protocols section to reflect the protocols
that are produced or consumed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The dynamic table manager implements the top level component
that drives the table generation and installation process.
It uses the configuration manager protocol to get the list
of tables to be installed from the configuration manager.
It iterates through the list of tables, requests the table
factories for corresponding generators and invokes the
generator interface to build the tables.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
The dynamic table factory dxe implements the dynamic table
factory protocol. It also implements the ACPI, SMBIOS and
DT table factories. The table generators register themselves
with the respective table factories and the factories are
responsible for instantiating instances of the generators
to build the firmware tables.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <alexei.fedorov@arm.com>
