| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CP_FULL_ACCESS is a misnomer, we only enable access to SIMD/FP state,
and although the register's mnemonic is CPACR_EL1, its full name is
"Architectural Feature Access Control Register", with AArch64 having no
coprocessors like AArch32 did, so the "CP" is also not appropriate.
Rename it to show it's the default value we use on entry, and define it
in terms of the existing CPACR_FPEN_FULL rather than a magic constant
with the same value to more clearly document that fact. Also update
comments to reflect all this (including the CPTR_EL2 case).
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code here predates its existence as it's assuming that
CPTR_EL2 has the traditional layout rather than being like CPACR_EL1
(likely also true elsewhere for other registers), and the UEFI spec has
nothing to say on the matter. One assumes the intent is that if you're
in EL2 you're in EL2 proper, and it would be very strange to enter EDK2
with E2H set. Document this existing assumption.
Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
|
|
|
|
|
|
|
|
|
|
| |
Then we can use correct TimerLib in another code,
such as dpDynamicCommand(PerformanceLib).
These API are from profileapi.h header and can refer to the link:
https://learn.microsoft.com/en-us/windows/win32/api/profileapi/
Signed-off-by: Yang Gang <yanggang@byosoft.com.cn>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4860
- The condition of GPT header checking is mismatched between PEI FatPei
module in FatPkg and DXE PartitionDxe module in MdeModulePkg.
- This patch is intended to simplify the checking condition within
FatPei module to align with PartitionDxe module to reduce code flow gap
between both of them.
- Below of condition would be checked on GPT header,
1. GPT header signature value
2. GPT header CRC value
3. GPT header LBA value
4. GPT header size of partition entry
Signed-off-by: Jason1 Lin <jason1.lin@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that the ResetVectors are USER_DEFINED modules, they will not
be linked against StackCheckLibNull, which were the only modules
causing issues. So, we can now remove the kludge we had before
and the requirement for every DSC to include StackCheckLibNull
for SEC modules and just apply StackCheckLibNull globally.
This also changes every DSC to drop the SEC definition of
StackCheckLibNull.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
|
|
|
|
|
|
|
|
| |
Following the change in UefiCpuPkg, this moves OvmfPkg's
ResetVectors to USER_DEFINED modules to prevent any
NULL libraries from being linked against them, allowing
for expected behavior from the ResetVector and for
simpler implementation of NULL libraries applied globally.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The x86 reset vector is the initial FW code to run on an
AP. It should not link to any libraries and is implemented
entirely in assembly. This module is currently labled as
SEC, because it runs during the SEC phase, but by having it
SEC, it will be linked to all NULL libraries linked globally.
This causes issue with StackCheckLib (though any NULL
library being applied globally has the same issue) because
BaseTools will attempt to link the library and add an
extern to _ModuleEntryPoint, which does not exist for this
module.
Moving this module to USER_DEFINED instructs BaseTools to
not link any NULL libraries to it, which is the desired
behavior, and leads to a much cleaner global NULL library
implementation, in this case for StackCheckLib.
This change was tested on OVMF IA32/X64 and proved to work
as before.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
|
|
|
|
|
| |
I intend to assist with the maintenance of the UefiPayloadPkg
directories.
Signed-off-by: Linus Liu <linus.liu@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In PcRtcInit(), it always read RTC time and then write it back. It could
potentially cause two issues:
1) There is time gap between read RTC and write RTC, writing RTC time on
every boot could cause RTC time drift after many reboot cycles
2) Writing RTC registers on every boot could cause some unnecessary delay,
slightly impact the boot performance.
The change is only writing RTC time when 1) the current RTC time is not
valid or 2) the RegisterB value is changed.
Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
Legacy BIOS design sets only the Update Cycle Inhibit (SET) bit when
changing the RTC time. Update Cycle Inhibit Bit may not be supported
by the backend device (Common I2C RTC device). It could add Division
Chain Select (DV) bit to stop the RTC first (Write to 0x07), Changing
the RTC time and then Set the DV bit back.
Signed-off-by: Di Zhang <di.zhang@intel.com>
|
|
|
|
|
|
| |
Replaced local Msr defines with inclusion of Register/Amd/Msr.h.
Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
|
|
|
|
|
|
|
| |
Replaced local Msr defines with inclusion of Register/Amd/Msr.h in Amd
libraries.
Signed-off-by: Vivian Nowka-Keane <vnowkakeane@linux.microsoft.com>
|
|
|
|
|
|
|
|
|
| |
Added definition of AMD specific public MSRs:
1. SMBASE
2. SMM_ADDR
3. SMM_MASK
Signed-off-by: Kun Qin <kuqin@microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes the following types from the memory type information HOB
produced:
- `EfiBootServicesCode`
- `EfiBootServicesData`
- `EfiLoaderCode`
- `EfiLoaderData`
This follows the guidance in the whitepaper "A Tour Beyond BIOS
Memory Map and Practices in UEFI BIOS".
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
"NOTE: We recommend a platform only define the ReservedMemory,
ACPINvs, ACPIReclaim, RuntimeCode, RuntimeData in Memory Type
Information table, because OSes only request these regions to be
consistent. There is no need to add BootServicesCode,
BootServicesData, LoaderCode, LoaderData in memory type information
table, because these regions will not be reserved during S4 resume."
Since these memory types are not tracked in memory type information
any longer it also reduces the number of resets that may need to
occur to update memory type buckets that are not needed.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes the following types from the memory type information HOBs
produced in the MemoryInitPei PEIM:
- `EfiBootServicesCode`
- `EfiBootServicesData`
- `EfiLoaderCode`
- `EfiLoaderData`
Our platform has a memory type information validation routine that
currently expects those types to be excluded as they would not impact
the UEFI memory map since they are not runtime memory types.
This follows the guidance in the whitepaper "A Tour Beyond BIOS
Memory Map and Practices in UEFI BIOS".
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
"NOTE: We recommend a platform only define the ReservedMemory,
ACPINvs, ACPIReclaim, RuntimeCode, RuntimeData in Memory Type
Information table, because OSes only request these regions to be
consistent. There is no need to add BootServicesCode,
BootServicesData, LoaderCode, LoaderData in memory type information
table, because these regions will not be reserved during S4 resume."
Since these memory types are not tracked in memory type information
any longer it also reduces the number of resets that may need to
occur to update memory type buckets that are not needed.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removes the following types from the memory type information HOBs
produced in the MemoryInitPei code:
- `EfiBootServicesCode`
- `EfiBootServicesData`
- `EfiLoaderCode`
- `EfiLoaderData`
Our platform has a memory type information validation routine that
currently expects those types to be excluded as they would not impact
the UEFI memory map since they are not runtime memory types.
This follows the guidance in the whitepaper "A Tour Beyond BIOS
Memory Map and Practices in UEFI BIOS".
https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Memory_Map_And_Practices_in_UEFI_BIOS_V2.pdf
"NOTE: We recommend a platform only define the ReservedMemory,
ACPINvs, ACPIReclaim, RuntimeCode, RuntimeData in Memory Type
Information table, because OSes only request these regions to be
consistent. There is no need to add BootServicesCode,
BootServicesData, LoaderCode, LoaderData in memory type information
table, because these regions will not be reserved during S4 resume."
Since these memory types are not tracked in memory type information
any longer it also reduces the number of resets that may need to
occur to update memory type buckets that are not needed.
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
|
|
|
|
|
|
|
|
|
|
| |
Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with
dynamic PCDs.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with
dynamic PCDs
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jianyong Wu <jianyong.wu@arm.com>
Cc: Anatol Belski <anbelski@linux.microsoft.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Chao Li <lichao@loongson.cn>
Cc: Bibo Mao <maobibo@loongson.cn>
Cc: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
| |
Rename `NetworkPcds` to `NetworkFixedPcds` to avoid confusion with
dynamic PCDs. The next patches in the chain will update all references
across the codebase to use the new name.
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Start using the include file in the ArmVirtPkg package to manage
dynamic network-related PCDs. This change removes the manual addition
of `PcdIPv4PXESupport` and `PcdIPv6PXESupport` from the DSC file,
relying instead on the centralized include file introduced in
NetworkPkg.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Start using the include file in the OvmfPkg package to manage dynamic
network-related PCDs. This change removes the manual addition of
`PcdIPv4PXESupport` and `PcdIPv6PXESupport` from the DSC file,
relying instead on the centralized include file introduced in
NetworkPkg.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jianyong Wu <jianyong.wu@arm.com>
Cc: Anatol Belski <anbelski@linux.microsoft.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Chao Li <lichao@loongson.cn>
Cc: Bibo Mao <maobibo@loongson.cn>
Cc: Xianglai Li <lixianglai@loongson.cn>
Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce an include file with dynamic PCDs to simplify the usage of
the network stage. This allows us to stop manually adding
`PcdIPv4PXESupport` and `PcdIPv6PXESupport` to the DSC file.
`NETWORK_IP4_ENABLE` and `NETWORK_IP6_ENABLE` are not used because
PXEv4 and PXEv6 boot support can be controlled from the QEMU command
line.
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>
Cc: Zachary Clark-williams <zachary.clark-williams@intel.com>
Signed-off-by: Aleksandr Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* EFI_DHCP6_DUID structure declares Duid[1], so the size
of that structure is not large enough to hold an entire
Duid. Instead, compute the correct size to allocate an
EFI_DHCP6_DUID structure.
* Dhcp6AppendOption() takes a length parameter that in
network order. Update test cases to make sure a network
order length is passed in. A value of 0x0004 was being
passed in and was then converted to 0x0400 length and
buffer overflow was detected.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
|
|
|
|
|
| |
Change conditional check to check the array index before
reading the array member to prevent read past end of buffer.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
|
|
|
|
|
|
| |
Unit test checks if AppendDevicePathInstance() returns NULL.
In those cases, AppendDevicePathInstance() does not allocate
a device path, so the call to FreePool() must not be performed.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
|
|
| |
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Consume PcdMaxMappingAddressBeforeTempRamExit for page table creation in
permanent memory before Temp Ram Exit.
This patch will create the full page table in two steps:
Step 1: Create the max address in page table before the Temporary RAM exit.
Step 2: Create the full range page table after the Temporary RAM exit.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is made for boot performance considerations.
Before the Temporary RAM is disabled, the permanent memory is in UC
state, causing the creation of the page table in
permanent memory to take more time with larger page table sizes.
Therefore, this patch adds the PcdMaxMappingAddressBeforeTempRamExit
to provide the platform with the capability to control the max
mapping address in page table before Temp Ram Exit. The value of
0xFFFFFFFFFFFFFFFF, then firmware will map entire physical address
space.
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove unnecessary check in API MmIsBufferOutsideMmValid of
StandaloneMmMemLib.
The API is used to check if a input buffer is outside MMRAM and
inside a valid non-MMRAM range. Previously, the API only checks
if the input buffer is
overlapped with MMRAM range. In the last
commit, we add logic to check if the input buffer is inside valid
non-MMRAM
ranges reported by the resource HOB. Since the resource
HOB only covers valid non-MMRAM ranges, we doesn't need to check
if the input buffer is inside the MMRAM anymore.
Signed-off-by: Dun Tan <dun.tan@intel.com>
|
|
|
|
|
|
|
|
|
| |
Check if the all the resource HOB in the input HOB list of
MmCore entry only covers non-Mmram ranges. The Resource HOB
is to describe the accessible non-Mmram range. All Resource
HOB should not overlap with any Mmram range.
Signed-off-by: Dun Tan <dun.tan@intel.com>
|
|
|
|
|
|
|
|
| |
Separate a function called InitializeMmHobList() to gather
all the operations related to initializing HOB. It doesn't
change any code logic.
Signed-off-by: Dun Tan <dun.tan@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check if the non-MMRAM buffer is inside valid non-mmram
range in API MmIsBufferOutsideMmValid of StandaloneMmMemLib.
Previously, the API only checks if the input buffer is
overlapped with MMRAM range. Currently, in the new standalone
MM infrastructure, we limit the non-MMRAM access to the ranges
reported by the resource HOB. To meet the new design, in this
API, we cache all the memory ranges reported by the resource
HOB and check if the input buffer is inside valid non-MMRAM
ranges reported by the resource HOB.
Signed-off-by: Dun Tan <dun.tan@intel.com>
|
|
|
|
|
|
|
|
| |
Add a internal header file for StandaloneMmMemLib.
Move some common reference and declaration into
StandaloneMmMemLibInternal.h.
Signed-off-by: Dun Tan <dun.tan@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove unneeded check MmIsBufferOutsideMmValid() when
StandaloneMmCore checks if the BS data memory described
by a memory allocation HOB needs to be migrated to Mmram.
Currently, the API MmIsBufferOutsideMmValid() return TRUE
when input memory range belongs to non-Mmram memory. Now
the API will be changed in following 5 commits to return
TRUE when a memory range belongs to non-Mmram memroy and
the memory is inside a range described by resource HOB.
This may cause PF when some SMI handler access the memory
from a memory allocation HOB that is not migrated.
To solve this issue, we can directly remove the check
MmIsBufferOutsideMmValid() and always migrate the BS data
memory described by a memory allocation HOB to Mmram.
Signed-off-by: Dun Tan <dun.tan@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang compile will optimize undefined behavior (UB)
like a pointer with NULL + size, so it is better to
check the pointer before using it.
Signed-off-by: Hongbin1 Zhang <hongbin1.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
|
|
|
|
|
|
|
|
| |
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4867
Added MM_STANDALONE support in Driver and BaseCryptLibOnProtocolPpi.
Signed-off-by: Kanagavel S <kanagavels@ami.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Openssl 3.0.15 has a larger memory footprint.
Updating from EDK 2022.2 (openssl 1.1.j) to 2024.2 (openssl 3.0.15)
causes our EFI provisioning application[1] to fail due to an out of
memory condition.
On inspection, at the time of that fault, 2022.2 had an additional 900
pages. This is why this patch proposes the increase of the ScratchMemory
buffer by that same ammount.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
Signed-off-by: Jorge Ramirez-Ortiz <jorge@foundries.io>
|
|
|
|
|
|
|
|
|
|
| |
Change subhook url from https://github.com/Zeex/subhook to
https://github.com/tianocore/edk2-subhook because old url is
no longer available.
Also align .gitmodules file to use consistent LF line endings.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
|
|
|
|
|
|
| |
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4838
Updated the missed architectures in PeiCryptLib.inf file.
Signed-off-by: Kanagavel S <kanagavels@ami.com>
|
|
|
|
|
|
|
|
|
|
| |
Per AMD64 Architecture Programmer's Manual Volume 2: System
Programming - 10.2.3 SMRAM State-Save Area (Rev 24593), the AMD64
architecture does not use the legacy SMM state-save area format
(Table 10-2) for 32-bit SMRAM save state map. Clean up codes for the
invalid save state map.
Signed-off-by: Phil Noh <Phil.Noh@amd.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Includes changes across the repo for the following CodeQL rules:
- cpp/comparison-with-wider-type
- cpp/overflow-buffer
- cpp/redundant-null-check-param
- cpp/uselesstest
Co-authored-by: Taylor Beebe <tabeebe@microsoft.com>
Co-authored-by: kenlautner <85201046+kenlautner@users.noreply.github.com>
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=4858
Ph52a PCIE to SATA card inserted on Intel MTL/ARL causes system hanged.
Root cause of this issue is because Ph52a's driver only uses DevicePath
protocol alone and EDK2 driver only uses PciIo protocol alone. Both
drivers start and try to manage SATA controller.
Signed-off-by: Paul Chang <paulchang@ami.com>
|
|
|
|
|
|
|
|
|
| |
There are couples of gUniversalPayloadAcpiTableGuid in
payload , only build one
gUniversalPayloadAcpiTableGuid hob and acpi memory hob.
when the reserved memory address matched the rsdp.
Signed-off-by: Linus Liu <linus.liu@intel.com>
|
|
|
|
|
|
|
| |
Per other platform request , need to add SMBIOS device node into FDT.
In the current phase(1) , only supporting SM3EntryPoint structure.
Signed-off-by: Linus Liu <linus.liu@intel.com>
|
|
|
|
|
|
|
| |
Per Spec updated , update DMA Reg property filed
with each root bridge bus base and its bus limit.
Signed-off-by: Linus Liu <linus.liu@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4-level paging supports translating 48-bit linear addresses to 52-bit
physical addresses. Since linear addresses are sign-extended,
the linear-address space of 4-level paging is: [0, 2^47-1] and
[0xffff8000_00000000, 0xffffffff_ffffffff]. So only [0, 2^47-1]
linear-address range maps to the identical physical-address range
when 5-Level paging is disabled.
Signed-off-by: Hongbin1 Zhang <hongbin1.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Wei6 Xu <wei6.xu@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
|
|
|
|
|
|
|
|
|
|
| |
Makes changes to comply with alerts raised by CodeQL.
The issues here fall into the following category:
1. comparison-with-wider-type
Signed-off-by: Eeshan Londhe <eeshanlondhe@microsoft.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang build for ArmVirtPkg/ArmVirtKvmTool.dsc fails with the below
warning:
| ld.lld: error: duplicate symbol: PciExpressRegisterForRuntimeAccess
| ld.lld: error: duplicate symbol: GetPciExpressBaseAddress
| ld.lld: error: duplicate symbol: PciExpressRead8
| ld.lld: error: duplicate symbol: PciExpressWrite8
| ld.lld: error: duplicate symbol: PciExpressOr8
| ld.lld: error: duplicate symbol: PciExpressAnd8
| ld.lld: error: duplicate symbol: PciExpressAndThenOr8
| ld.lld: error: duplicate symbol: PciExpressBitFieldRead8
| ld.lld: error: duplicate symbol: PciExpressBitFieldWrite8
| ld.lld: error: duplicate symbol: PciExpressBitFieldOr8
| ld.lld: error: duplicate symbol: PciExpressBitFieldAnd8
| ld.lld: error: duplicate symbol: PciExpressBitFieldAndThenOr8
| ld.lld: error: duplicate symbol: PciExpressRead16
| ld.lld: error: duplicate symbol: PciExpressWrite16
| ld.lld: error: duplicate symbol: PciExpressOr16
| ld.lld: error: duplicate symbol: PciExpressAnd16
| ld.lld: error: duplicate symbol: PciExpressAndThenOr16
| ld.lld: error: duplicate symbol: PciExpressBitFieldRead16
| ld.lld: error: duplicate symbol: PciExpressBitFieldWrite16
| ld.lld: error: duplicate symbol: PciExpressBitFieldOr16
| >>> defined in MdePkg/Library/BasePciExpressLib/BasePciExpressLib/OUTPUT/BasePciExpressLib.lib(PciExpressLib.obj)
| >>> defined in OvmfPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib/OUTPUT/BaseCachingPciExpressLib.lib(PciExpressLib.obj)
|
| ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)
| clang: error: linker command failed with exit code 1 (use -v to see invocation)
OvmfPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf is
getting linked as NULL library in these pacakges:
1. UefiCpuPkg/CpuMmio2Dxe/CpuMmio2Dxe.inf
2. MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
3. MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
which results in duplicate symbols shown in the warning above as
MdePkg/Library/BasePciExpressLib/BasePciExpressLib.inf is not properly replaced
by OvmfPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf
as PciExpressLib library.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
|
|
| |
Signed-off-by: TsunFeng <v-tshuang@microsoft.com>
|
|
|
|
|
|
|
| |
As discussed with the stewards, I have decided to resume my role as a
maintainer in the Tianocore project (if they will have me, of course)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|