A) Assign a new file GUID;
B) Consume the PCDs duplicated in OvmfPkg DEC file;
C) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of LegacyBiosDxe in IntelFrameworkModulePkg with the one
copied in OvmfPkg within DSC/FDF files.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
A) Assign a new file GUID;
B) Consume the PCDs duplicated in OvmfPkg DEC file;
C) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of VideoDxe in IntelFrameworkModulePkg with the one copied
in OvmfPkg within DSC/FDF files.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This commit will add the PCD definitions consumed by the duplicated
drivers:
* VideoDxe
* LegacyBiosDxe
into the OvmfPkg DEC file.
Please note that, instead of adding these PCDs under section:
[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]
as in IntelFrameworkModulePkg.dec file, they are added in section:
[PcdsFixedAtBuild]
in OvmfPkg.dec instead.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The previous file-duplication commit has put all the CSM related header
files within folder: OvmfPkg/Csm/Inclue.
This commit will update the DEC file to add that folder under the
'[Include]' section.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This commit will add the Guid definitions of the duplicated CSM-related
Guids and Protocols from IntelFramework[Module]Pkg.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
from IntelFramework[Module]Pkg to OvmfPkg/Csm/ folder.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Hao A Wu [Fri, 24 May 2019 00:26:40 +0000 (08:26 +0800)]
Maintainers.txt: Add maintainer for CSM components in OvmfPkg
According to the discussion at:
https://edk2.groups.io/g/devel/topic/31627718#40659
(Request by Laszlo to find proper maintainer for to-be-duplicated CSM
components in OvmfPkg.)
and:
https://edk2.groups.io/g/devel/topic/31682287#40996
(Confirmation with David Woodhouse as the maintainer for the
to-be-duplicated CSM components in OvmfPkg.)
This commit will add David Woodhouse as the maintainer for the CSM
modules under OvmfPkg.
Please note that the duplication of the required CSM modules from
framework packages to OvmfPkg will be done in subsequent commits.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Original logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(Mode = -1, invalid) -> connect it
as console spliter and add the device to the list(use SetMode to
set mode to the user defined mode or the best mode the devices
supported if the mode is invalid. *clear the screen at this phase*)
Changed logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(initialize the mode to the user
defined mode or the best mode. *directly set the mode value without
using SetMode, that would not clear the screen) -> connect it as
console spliter and add the device to the list(use SetMode to set
mode to the user defined mode or the best mode the devices supported
if the mode is invalid. *now the mode is already set, so it would
not clear the screen*).
Also remove the section of SetMode for debug version.
Impact: as the text mode may not be an invalid value, the SetMode
may have no chance to be called during reconnect the graphics device.
That means the screen may not be cleaned after finishing reconnect
operation. There is one common condition: shell command "recoonect -r".
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
For Console Out device, it would always set all present devices'
text out mode again through ConSplitterTextOutSetMode while adding
devices. That may cause the screen cleared for serval times.
So add a BOOLEAN to judge if it is adding device then we will not
set the same text mode again for same console out device.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
This patch fix following bugs in func DisplaySysEventLogData:
1. Log increment (Log = (LOG_RECORD_FORMAT *) (LogData + Offset);)
should happened in the end of while loop, not in the very beginning.
2. DisplaySELTypes function should be used in while loop instead of
DisplaySELVarDataFormatType.
Cc: Jaben Carsey <jaben.carsey@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zhichao Gao <zhichao.gao@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Leif Lindholm [Mon, 10 Jun 2019 11:54:10 +0000 (19:54 +0800)]
BaseTools: add script to configure local git options
Patch contribution and review is greatly simplified by following the
steps described in "Laszlo's unkempt guide":
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
but there are a lot of tedious manual steps in there, so here is a
python script that configures all options I am aware of
*for the repository the script is executed from*.
Chu, Maggie [Mon, 10 Jun 2019 10:19:27 +0000 (18:19 +0800)]
SecurityPkg/HddPassword: Add a PCD to skip Hdd password prompt
https://bugzilla.tianocore.org/show_bug.cgi?id=1876
Add a PCD for skipping Hdd password prompt.
If device is in the locked status while attempting to skip
password prompt, device will keep locked and system
continue to boot.
If device is in the unlocked status while attempting to skip
password prompt, system will be forced shutdown.
Signed-off-by: Maggie Chu <maggie.chu@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Laszlo Ersek [Tue, 4 Jun 2019 19:42:56 +0000 (21:42 +0200)]
MdeModulePkg/PciBusDxe: catch unimplemented extended config space reads
When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
find that the extended config space is not (fully) implemented. In
LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
0xFFFF_FFFF at a given config space offset, after which the loop gets
stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
0xFFFF_FFFF most likely as well).
Another scenario (not related to virtualization) for triggering the above
is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
topology -- intervenes between a PCI Express Root Port and a PCI Express
Endpoint. The Conventional PCI bus limits the accessible config space of
the PCI Express Endpoint, even though the endpoint advertizes the PCI
Express capability. Here's a diagram, courtesy of Alex Williamson:
[PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
->| |<- Conventional PCI bus
Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and
break out of the scan with a warning message. The function will return
EFI_NOT_FOUND.
Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Since there are V2 FSP packages (IntelFsp2Pkg, IntelFsp2WrapperPkg),
this patch removes IntelFspPkg, IntelFspWrapperPkg to remove obsolete
code in edk2 repo.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Krzysztof Koch [Fri, 22 Feb 2019 17:42:27 +0000 (17:42 +0000)]
DynamicTablesPkg: Add dynamic PPTT table generation support
The PPTT generator uses the configuration manager protocol to
obtain information about platform's processor topology and caches.
This data is then used to generate the PPTT table.
The table generator supports ACPI 6.3, PPTT table revision 2.
The dynamic PPTT generator also carries out extensive input
validation which includes cycle detection and MADT-PPTT
cross-validation. A number of architectural compliance checks
are also performed.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Support rebasing FSP 1.x binary.
FSP 1.x has single component in binary so not supported
by split command and rebase can be done with the same
command for rebasing FSP-T component in FSP 2.x image.
Test: both FSP 2.x (Kabylake) and FSP 1.x (BroadwellDE) binary
can be rebased successfully.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
According to the discussion at:
https://edk2.groups.io/g/devel/topic/30918343#38093
For OVMF, we keep both ISA stacks:
* The legacy one in PcAtChipsetPkg/IntelFrameworkModulePkg
* The Sio bus based OVMF-specified one introduced by commit a5cc178aeb
for a period of time (includes 1 stable tag: edk2-stable201905). And we
also keep the Sio bus based OVMF-specified stack as the default one (via a
build option 'USE_LEGACY_ISA_STACK') to validate its stability.
This commit will propose to drop the legacy ISA stack from OVMF and remove
the usage of the build flag 'USE_LEGACY_ISA_STACK' at the same time. This
is considered as a preparation for the removal of
PcAtChipsetPkg/IsaAcpiDxe & IntelFrameworkModulePkg.
Cc: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Krzysztof Koch [Tue, 9 Apr 2019 13:44:37 +0000 (14:44 +0100)]
DynamicTablesPkg: Add ACPI 6.3 SPE support to MADT generator
The Dynamic Tables Framework now supports generating Multiple APIC
Description Table (MADT) revision 5 for ARM platforms while maintaining
backward-compatibility with ACPI 6.2.
The relevant change is the enablement of the Statistical Profiling
Extension (SPE).
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com> Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Pierre Gondois [Tue, 19 Mar 2019 16:58:17 +0000 (16:58 +0000)]
ShellPkg/acpiview: GTDT updates for ACPI 6.3
The ACPI 6.3 specification introduces support to describe
the ARMv8.1 virtual EL2 timers. This patch updates the GTDT parser
of acpiview to decode the EL2 virtual timer fields.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com> Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
After adding a check to see if [Sources] section lists all the header
type files of a module, track module and library hashes for --hash
feature. If above check is not in compilance for a library or module,
force hash invalidation on that library or module.
Signed-off-by: Christian Rodriguez <christian.rodriguez@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Add a check to see if [Sources] section lists all the header type
files of a module. Performance impact should be minimal with this patch
since information is already being fetched for Makefile purposes. All
other information is already cached in memory. No extra IO time is needed.
Signed-off-by: Christian Rodriguez <christian.rodriguez@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Chu, Maggie [Wed, 22 May 2019 07:04:43 +0000 (15:04 +0800)]
SecurityPkg/OpalPassword: Add PCD to skip password prompt
https://bugzilla.tianocore.org/show_bug.cgi?id=1801
Add a PCD for skipping password prompt in device unlocked status.
Previous change only support if storage device is in locked status.
This change is added to support the case that security status of the
storage device is unlocked.
Signed-off-by: Maggie Chu <maggie.chu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Ray Ni [Fri, 31 May 2019 09:42:09 +0000 (17:42 +0800)]
UefiCpuPkg/MpInitLib: Decrease NumApsExecuting only for ApInitConfig
The patch fixes the bug that the memory under 1MB is modified by
firmware in S3 boot.
Root cause is a racing condition in MpInitLib:
1. BSP: WakeUpByInitSipiSipi is set by NotifyOnS3SmmInitDonePpi()
2. BSP: WakeUpAP() wakes all APs to run certain procedure.
2.1. AllocateResetVector() uses <1MB memory for wake up vector.
2.1. FillExchangeInfoData() resets NumApsExecuting to 0.
2.2. WaitApWakeup() waits AP to clear WAKEUP_AP_SIGNAL.
3. AP: ApWakeupFunction() clears WAKEUP_AP_SIGNAL to inform BSP.
5. BSP: FreeResetVector() restores the <1MB memory
4. AP: ApWakeupFunction() calls the certain procedure.
4.1. NumApsExecuting is decreased.
#4.1 happens after the 1MB memory is restored so the result is
memory below 1MB is changed by #4.1
It happens only when the AP executes procedure a bit longer.
AP returns back to ApWakeupFunction() from procedure after
BSP restores the <1MB memory.
Since NumApsExecuting is only used when InitFlag == ApInitConfig
for counting the processor count.
The patch moves the NumApsExecuting decrease to the path when
InitFlag == ApInitConfig.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Nandagopal Sathyanarayanan <nandagopal.sathyanarayanan@intel.com>
Ray Ni [Tue, 4 Jun 2019 10:49:25 +0000 (18:49 +0800)]
UefiCpuPkg/MpInitLib: increase NumApsExecuting only for ApInitConfig
NumApsExecuting is only used when InitFlag == ApInitConfig for
counting the processor count.
The patch changes Ia32 version of waking up vector assembly code
to align to x64 version of waking up vector assembly code.
After the change both versions of waking up vector increase
NumApsExecuting when InitFlag == ApInitConfig.
Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
1. Current code gets CPUID_THERMAL_POWER_MANAGEMENT in
ClockModulationInitialize() and uses its ECMD bit for all processors.
But ClockModulationInitialize() is only executed by BSP, that means
the bit is just for BSP.
It may have no functionality issue as all processors may have same
bit value in a great possibility. But for good practice, the code
should get CPUID_THERMAL_POWER_MANAGEMENT in ClockModulationSupport
(executed by all processors), and then use them in
ClockModulationInitialize() for all processors.
We can see that Aesni.c (and others) have used this good practice.
2. Current code uses 3 CPU_REGISTER_TABLE_WRITE_FIELD for
MSR_IA32_CLOCK_MODULATION in ClockModulationInitialize(), they can
be reduced to 1 CPU_REGISTER_TABLE_WRITE64 by getting
MSR_IA32_CLOCK_MODULATION for all processors in
ClockModulationSupport() and then update fields for register table
write in ClockModulationInitialize().
We may argue that there may be more times of MSR_IA32_CLOCK_MODULATION
getting. But actually the times of MSR_IA32_CLOCK_MODULATION getting
could be also reduced.
The reason is in ProgramProcessorRegister() of CpuFeaturesInitialize.c,
AsmMsrBitFieldWrite64 (AsmReadMsr64 + AsmWriteMsr64) will be used for
CPU_REGISTER_TABLE_WRITE_FIELD, and AsmWriteMsr64 will be used for
CPU_REGISTER_TABLE_WRITE64.
The times of MSR accessing could be reduced with this patch.
Without the patch:
3 CPU_REGISTER_TABLE_WRITE_FIELD (in ClockModulationInitialize)
==> 3 AsmMsrBitFieldWrite64
==> 3 AsmReadMsr64 + 3 AsmWriteMsr64
With the patch:
1 AsmReadMsr64 (in ClockModulationSupport) +
1 CPU_REGISTER_TABLE_WRITE64 (in ClockModulationInitialize)
==> 1 AsmWriteMsr64
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
There will be ASSERT if LMCE is supported as below.
DXE_ASSERT!: [CpuFeaturesDxe]
XXX\UefiCpuPkg\Library\CpuCommonFeaturesLib\MachineCheck.c (342):
ConfigData != ((void *) 0)
The code should get Config Data and FeatureControlGetConfigData
could be used.
This issue is there since the code was added at the commit below.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
In current code, the values of TopaEntryPtr->Uint64 for TopaTable
and the values of OutputBaseReg.Uint64 and OutputMaskPtrsReg.Uint64
to register table write for RTIT_OUTPUT_BASE and RTIT_OUTPUT_MASK_PTRS
are not been initialized in whole. For example, the reserved bits in
OutputBaseReg.Uint64 are random that will cause GP fault like below
when SetProcessorRegister (in CpuFeaturesInitialize.c) sets register
based on register table.
And current code gets MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_OUTPUT_BASE and
MSR_IA32_RTIT_OUTPUT_MASK_PTRS in ProcTraceInitialize() and uses their
values for all processors. But ProcTraceInitialize() is only executed
by BSP, that means the values just for BSP. For good practice, the code
should get MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_OUTPUT_BASE and
MSR_IA32_RTIT_OUTPUT_MASK_PTRS in ProcTraceSupport (executed by all
processors), and then use them in ProcTraceInitialize() for all
processors. This can also resolve the issue that the values of
OutputBaseReg.Uint64 and OutputMaskPtrsReg.Uint64 are not been
initialized in whole.
For TopaEntryPtr->Uint64, this patch updates code to initialize it
in whole explicitly by TopaEntryPtr->Uint64 = 0 before updating its
fields.
At the same time, this patch also eliminates the ProcTraceSupported
field in PROC_TRACE_PROCESSOR_DATA and the TopaMemArrayCount field in
PROC_TRACE_DATA.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Current code disables TraceEn at the end of ProcTraceInitialize(),
then there will be much memory allocated even when ProcTrace feature
is disabled.
This patch updates code to disable TraceEn and return at the beginning
of ProcTraceInitialize() when when ProcTrace feature is disabled.
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chandana Kumar <chandana.c.kumar@intel.com> Cc: Kevin Li <kevin.y.li@intel.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Marc W Chen [Thu, 6 Jun 2019 07:42:37 +0000 (15:42 +0800)]
OvmfPkg/QemuVideoDxe: Shouldn't assume system in VGA alias mode.
Query the supported attributes firstly, then bitwise AND (&) both VGA_IO
and VGA_IO_16. Since the supported attributes should only have one of
VGA_IO or VGA_IO_16 set, the result of bitwise AND (&) is either VGA_IO
or IO_16. Then the result can be passed to PciIo->Attributes() to set the
attributes.
Device driver should consider both since the mReserveVgaAliases in
PciBusDxe driver is default FALSE(implies that device driver can only set
VGA_IO_16 to PCI_ROOT_BRIDGE), and Platform code may not return
EFI_RESERVE_VGA_IO_ALIAS in GetPlatformPolicy of PciPlatformProtocol to
make mReserveVgaAliases become TRUE(implies that device driver can only
set VGA_IO to PCI_ROOT_BRIDGE), Currently OvmfPkg doesn't have problem
due to it has hard code value for PCI_ROOT_BRIDGE's attributes field, so
an IO access by PciIoProtocol will be successed due to
RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get pass
result for legacy IO access.
Usually the attributes field of PCI_ROOT_BRIDGE should be 0, in that case
it will have issue since the VGA_IO may not be able to be enabled, then
IO access by PciIoProtocol will be failed, hence the QemuVideoDxe driver
will not work fine.
CryptoPkg/OpensslLib: fix build break caused by missing library
CryptoPkg\Library\Include\CrtLibSupport.h maps strxxxx interfaces to
edk2 PrintLib interfaces but related module inf file don't claim the
use of it. This will cause unresolved symbol issue with VS2017 build
which has enabled strict symbol check. This patch resolves the problem
by adding PrintLib to inf files.
Cc: Liming Gao <liming.gao@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Guo Dong <guo.dong@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com>
Xiaoyu Lu [Wed, 5 Jun 2019 05:24:55 +0000 (13:24 +0800)]
CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem
When use clang-3.8 to build the NetworkPkg, compiler optimization
may use memcpy for memory copy. For example:
CryptoPkg/Library/OpensslLib/openssl/ssl/ssl_rsa.c:918: undefined
reference to `memcpy'`
Compiler optimization is sophisticated, but we can work around it
use __attribute__((__used__)) to informs the compiler that symbol
should be retained in the object file, even if it may be
unreferenced.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Update the list of additional licenses in Readme.md. For additional
licenses from a git submodule, provide a link to the license file
in the remote git repository. This makes the links in Readme.md
when viewed from the edk2 repository GitHub landing page
https://github.com/tianocore/edk2/ functional from a web browser.
* Remove references EdkCompatibilityPkg
* Update link to OpenSSL to license file in the git submodule link
to https://github.com/openssl/openssl
* Add link to license file in the git submodule like to
https://github.com/ucb-bar/berkeley-softfloat-3 for
ArmSoftFloatLib
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Because OPENSSL_NO_ERR and OPENSSL_NO_AUTOERRINIT are not defined by
default, err_load_crypto_strings_int() will not be actually referenced
by ossl_init_load_crypto_strings().
Since err_load_crypto_strings_int() is not actually referenced at all,
the fix can be done simply by removing crypto/err/err_all.c from build.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Xiaoyu Lu <xiaoyux.lu@intel.com> Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Said commit was not suitable for pushing during the edk2-stable201905 hard
feature freeze; it was pushed only by mistake. The subject line referenced
EmulatorPkg, but the patch changed MdeModulePkg/UiApp, regressing the
display of the CPU speed from SMBIOS in multiple platforms.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1877 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Dong, Guo [Wed, 29 May 2019 18:52:20 +0000 (11:52 -0700)]
UefiPayloadPkg: Remove legacy PIC 8259 driver
Since legacy PIC 8259 driver would be removed from edk2,
update UEFI payload to remove 8259 driver.
If required, bootloader could disable 8259.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
The bug reporter wish to display nothing as the CPU is virtual
Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
FmpDevicePkg use OpensslLib and when OpenSSL upgrade to 1.1.1b,
TimerLib is required by OpensslLib in CryptoPkg(commit 456dd8b99f,
CryptoPkg: Upgrade OpenSSL to 1.1.1b)
So add TimerLib to DSC file.
Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
When building CryptoPkg with XCODE, blow error may result
* usr/lib/clang/9.0.0/include/stdatomic.h:105:17:
error: unknown type name 'wchar_t'
Since the C native atomics are C11 feature we can explicitly
use C99 to work around it.
add -std=c99 to avoid it
* openssl/crypto/conf/conf_sap.c:71:12: error: variable 'ret' is
uninitialized
when used here [-Werror,-Wuninitialized]
Suppress warnings in OpenSSL so we don't break the build with -Werror.
add -Wno-error=uninitialized to disalbe this warning
Cc: Jian Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Laszlo Ersek [Wed, 29 May 2019 12:49:55 +0000 (14:49 +0200)]
OvmfPkg/PlatformPei: set 32-bit UC area at PciBase / PciExBarBase (pc/q35)
(This is a replacement for commit 39b9a5ffe661 ("OvmfPkg/PlatformPei: fix
MTRR for low-RAM sizes that have many bits clear", 2019-05-16).)
Reintroduce the same logic as seen in commit 39b9a5ffe661 for the pc
(i440fx) board type.
For q35, the same approach doesn't work any longer, given that (a) we'd
like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and
(b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit
PCI MMIO aperture.
Therefore, introduce a helper function for determining the 32-bit
"uncacheable" (MMIO) area base address:
- On q35, this function behaves statically. Furthermore, the MTRR setup
exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with
just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at
0xC000_0000 (size 1GB)).
- On pc (i440fx), the function behaves dynamically, implementing the same
logic as commit 39b9a5ffe661 did. The PciBase value is adjusted to the
value calculated, similarly to commit 39b9a5ffe661. A further
simplification is that we show that the UC32 area size truncation to a
whole power of two automatically guarantees a >=2GB base address.
On Q35 machine types that QEMU intends to support in the long term, QEMU
never lets the RAM below 4 GB exceed 2 GB.
Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).
In turn, such a RAM size (justifiedly) triggers
ASSERT (TopOfLowRam <= PciExBarBase);
in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)
In order to fix this, place the PCIEXBAR at 2816MB (0xB000_0000), and
start the 32-bit PCI window at 3 GB (0xC000_0000). This shrinks the 32-bit
PCI window to
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
Ard Biesheuvel [Mon, 3 Jun 2019 16:19:41 +0000 (18:19 +0200)]
CryptoPkg CLANG35: add -std=c99 to dodge OpenSSL C atomics issue
Commit c51f8bae7cabe ("CryptoPkg: Fix possible build problem with
Clang") added -std=c99 to the CLANG38 compiler command line of
packages that incorporate parts of OpenSSL, to ensure that the new
C atomics code used by OpenSSL for refcounting (which we don't care
about) does not pull in system C library headers, which we cannot
rely on when (cross)building EDK2 code.
Unsurprisingly, CLANG35 (which is only defined for ARM and AARCH64)
suffers from the exact same issue, so let's add the same flags
there as well.
OpenSSL internally redefines the size of HMAC_CTX at
crypto/hmac/hmac_lcl.h(OpenSSL commit e0810e35).
Ref: https://github.com/openssl/openssl/pull/4338
We should not use it directly and should remove relevant
functions(Hmac*GetContextSize).
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1792
But for compatiblility, temporarily change these definition
of HMAC_*_CTX_SIZE.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* Run process_files.pl script to regenerate OpensslLib[Crypto].inf
and opensslconf.h
* Remove -DNO_SYSLOG from OPENSSL_FLAGS in OpensslLib[Crypto].inf,
due to upstream OpenSSL commit cff55b90e95e("Cleaning UEFI
Build with additional OPENSSL_SYS_UEFI flags", 2017-03-29),
which was first released as part of OpenSSL_1_1_1.
* Starting with OpenSSL commit 8a8d9e1905(first release in
OpenSSL_1_1_1), the OpenSSL_version() function can no longer
return a pointer to the string literal "compiler: information
not available", in the case CFLAGS macro is not defined.
Instead, the function now has a hard dependency on the global
variable 'compiler_flags'. This variable is normally placed
by "util/mkbuildinf.pl" into "buildinf.h". In edk2 we don't
run that script whenever we build OpenSSL, therefore we
must provide our own dummy 'compiler_flags'.
* BUFSIZ is used by crypto/evp/evp_key.c(OpenSSL_1_1_1b)
And it is declared in stdio.h. So add it to CrtLibSupport.h.
Here's a discussion about this.
Ref: https://github.com/openssl/openssl/issues/8904
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Since OpenSSL_1_1_1b doesn't fully implement rand pool functions
for UEFI. We must provide a method to implenet these method.
TSC is used as first entropy source if it's availabe otherwise
fallback to TimerLib. But we are not sure the amount of randomness
they provide. If you really care about the security, one choice is
overrided it with hardware generator.
Add rand_pool.c to implement these functions required by OpenSSL
rand_pool_acquire_entropy
rand_pool_add_nonce_data
rand_pool_add_additional_data
rand_pool_init
rand_pool_cleanup
rand_pool_keep_random_devices_open
And add rand_pool_noise.* for getting entropy noise from different
architecture.
* We don't need ossl_store functions. We exclude relative files
through process_files.pl. And ossl_store_cleanup_int was first
added in crypto/init.c OpenSSL_1_1_1(71a5516d).
So add a new file(ossl_store.c) to implement ossl_store_cleanup_int
function.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
When building CryptoPkg with Clang, blow error may result
* /usr/lib/llvm-3.8/lib/clang/3.8.0/include/stdatomic.h:105:17: error:
unknown type name 'wchar_t'
Since the C native atomics are C11 feature we can explicitly
use C99 to work around it.
add -std=c99 to avoid it
* openssl/crypto/conf/conf_sap.c:71:12: error: variable 'ret' is
uninitialized
when used here [-Werror,-Wuninitialized]
Suppress warnings in OpenSSL so we don't break the build with -Werror.
add -Wno-error=uninitialized to disalbe this warning
Cc: Ting Ye <ting.ye@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
add /wd4132 /wd4700 /wd4310 for Visual Studio in OpensslLib[Crypto].inf
add -Wno-error=unused-but-set-variable for GCC in OpensslLib[Crypto].inf
Although this option is set in some build environments by default.
But this is only for OpenSSL compilation, no matter how the
default options change.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
This is for the upcoming upgrade to OpenSSL_1_1_1b
Compiler optimization(Visual Studio) may automatically use _ftol2
instead of some type conversion. For example:
OpensslLib.lib(drbg_lib.obj) : error LNK2001:
unresolved external symbol __ftol2
This patch add _ftol2 function for the compiler intrinsic.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
When running process_files.py to configure OpenSSL, we can exclude
some unnecessary files. This can reduce porting time, compiling
time and library size.
Upstream OpenSSL commit 71a5516dcc8a which was as part of
OpenSSL_1_1_1b, Add the STORE module(crypto/store/*).
But UEFI don't use them. So exclude these files.
Functions in crypto/rand/randfile.c OpenSSL and edk2 don't
call them. And it requires more crt runtime support.
So exclude it.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
This OpenSSL change was introduced in commit 8389ec4b4950 ("Add --with-rand-seed", 2017-07-22).
So add --with-rand-seed=none to process_files.pl.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ting Ye <ting.ye@intel.com> Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gary Lin <glin@suse.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Ard Biesheuvel [Fri, 31 May 2019 20:46:30 +0000 (22:46 +0200)]
ArmPkg/ArmSoftFloatLib GCC4x: fix build failure
The upstream SoftFloat code that was recently incorporated into
ArmSoftFloatLib uses some parameterization to tweak the inlining
and optimization behavior for different compilers.
The custom platform.h file that sets these parameters is based on
the upstream version for Linux/ARM, but was updated to include the
'always_inline' GCC attribute into the INLINE macro, to ensure that
all definitions that are marked as inline are not only inlined into
their callers, but also to ensure that no version of the function is
ever emitted into the object file.
This works fine on recent GCC and Clang, but the latter part turns
out to break on GCC 4.x, resulting duplicate definition linker errors.
Fortunately, the synticatically more appriopriate 'static inline'
works fine on both the recent and the older compilers, so let's switch
to that instead.
Ard Biesheuvel [Thu, 20 Dec 2018 19:16:53 +0000 (20:16 +0100)]
ArmPkg/ArmLib ARM: set .fpu to let Clang 7 assemble ArmV7Support.S
Clang 7 complains about the vmsr instruction in ArmV7Support.S,
which is only available on cores that implement some flavour of
VFP. So set the .fpu to NEON like we do in some other places.
Ard Biesheuvel [Fri, 24 May 2019 14:58:40 +0000 (16:58 +0200)]
ArmPkg/ArmSoftFloatLib: remove source files that are no longer used
Now that we have switched to a new version of the SoftFloat code,
remove the source files that make up the old implementation, and
are no longer referenced.
Ard Biesheuvel [Fri, 24 May 2019 14:52:13 +0000 (16:52 +0200)]
ArmPkg/ArmSoftFloatLib: switch to new version of softfloat library
Update the INF description and the top level .c files in order to
switch to the new version of the SoftFloat library imported as a
Git submodule in the previous patch.
Note that we no longer use the code that travelled a long way from
the 2002 version of the softfloat library via NetBsd and the StdLib
package. Instead, we are using the upstream version unmodified, with
the glue .c file adopted from the OP-TEE project. This approach is
much cleaner and much more maintainable.
Note that support for the RVCT toolchains is being dropped at the same
time. RVCT is mostly untested, and planned to be removed, and so it
makes little sense to go to the trouble of upgrading this library for
RVCT as well.
Ard Biesheuvel [Fri, 24 May 2019 14:05:02 +0000 (16:05 +0200)]
ArmPkg: import Berkeley Softfloat library as git submodule
In preparation of bringing ArmSoftFloatLib up to date in order
to provide some missing routines, import the Berkely SoftFloat
library into the tree as a git submodule.
Current Binary Cache doesn't update the restored file
creation and modification times to the current time.
Preserve the new restored file creation time as old
cached time might has potential issue to block the make
to build updated files based on the time stamp.
Enhance to update the restored file creation time to
current time.
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Zhiju Fan <zhijux.fan@intel.com> Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Current binary cache doesn't support to save and restore
the library module. If a driver module cache miss happen,
all its dependency library modules need rebuild which
is very time-consuming. This patch is to extend the binary
cache to support library.
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Christian Rodriguez <christian.rodriguez@intel.com> Signed-off-by: Steven Shi <steven.shi@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Current implementation of function AhciModeInitialization() has an
incorrect assumption that the value in the CAP (offset 00h) register will
always be greater than the highest bit set for the value in the PI (offset
0Ch) register.
This will lead to an issue that hard disk devices may not be found in the
non-S3 boot path for some AHCI controller capabilities.
More specifically, variable 'PortInitializeBitMap' will have the value
from 'Private->PortBitMap', which will be 0xFFFFFFFF in non-S3 boot path.
When the CAP register is of value 0x1 and PI register with value 0x4
(meaning port 2 is available), the current logic will only enumerate port
0. And the device attached behind port 2 will not be enumerated.
To address this issue, variable 'PortInitializeBitMap' will now take the
bitwise and result between 'Private->PortBitMap' and the value read from
the PI register.
Please note that there will be no function impact for S3 path, since in
this case, the bits being set in 'Private->PortBitMap' will be a subset
of the bits being set in the PI register. Their bitwise and operation will
still be the value of 'Private->PortBitMap'.
Cc: Maggie Chu <maggie.chu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Signed-off-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
Support rebasing FSP 1.x binary.
FSP 1.x has single component in binary so not supported
by split command and rebase can be done with the same
command for rebasing FSP-T component in FSP 2.x image.
Test: both FSP 2.x (Kabylake) and FSP 1.x (BroadwellDE) binary
can be rebased successfully.
Cc: Maurice Ma <maurice.ma@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Guo Dong [Wed, 29 May 2019 19:07:29 +0000 (03:07 +0800)]
Maintainers.txt: update UEFI payload information
Remove CorebootModulePkg and CorebootPayloadPkg, and add
UefiPayloadPkg to reflect recently change in UEFI payload.
wiki link for UefiPayloadPkg would be available soon.
Signed-off-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com>
Current Binary Cache use the PlatformInfo.Name to distinguish
the different platform cache paths in the database folder.
But the different platforms might use the same PLATFORM_NAME
in the DSC files. Different platform caches might overlay each
other inside Binary Cache database if they use same platform name
Use the PlatformInfo.Platform.OutputDirectory instead of the
PlatformInfo.Name can solve the problem.
This patch is going to fix that issue.
Cc: Liming Gao <liming.gao@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Steven Shi <steven.shi@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
This patch is related to commit 9ca1f1
It's to remove the second .SecMain call from 'run' target.
Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
There is a bug to use AsciiStrCpyS to copy a truncated
string. If would cause an assert because the truncated
length is always less than the source string length. It
should use the AsciiStrnCpyS instead.
When a target of 'run' is passed into build.py,
BaseTools unconditionally attempts to execute the
application called './SecMain' in the build output directory.
This behavior applies to the Nt32Pkg which is being
replaced with features in the EmulatorPkg.
Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
The edk2 source tree contains four instances of the outdated mailing
list address "edk2-devel@lists.01.org".
I created a new variable, MSG_EDKII_MAIL_ADDR, to receive the
new email address and replaced the old one with this variable
Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
In V3: Must generate hashes before attempting to copy from cache for
hash verifcation
In V2: Build failure caused by passing incorrect boolean parameter to
SaveFileOnChange(). Fixed for patch instances.
Library hashing is now supported by the --hash feature. The --hash
feature implementation assumed that the hashing could be done in
place once per module, but that isn't true for libraries due to the
fact that they are built as dependencies. So on a clean build, we now
generate the .hash after the library dependencies are complete.
Added early escape as optimization, if hash already exists in memory.
Signed-off-by: Christian Rodriguez <christian.rodriguez@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
When a module in a DSC file uses a FILE_GUID override in the
module scoped <Defines> section, a copy of the modified INF file
is placed in the Conf/.cache directory. The check for private
includes uses the INF path to determine if the module is allowed
to use the private includes. Since the INF path in this case is
not in any package, this check always fails, and no private
include paths are possible.
The fix is to keep both the OriginalPath and the new Path in
the PathClass object, and always use the OriginalPath to see if
the module INF is in the package with private includes.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Liming Gao [Mon, 20 May 2019 12:06:43 +0000 (20:06 +0800)]
EmulatorPkg: Add NetworkPkg/NetworkPkg.dec as the package dependency
NetLib will be moved from MdeModulePkg and NetworkPkg.
So, the module that consumes NetLib need to depend on NetworkPkg.dec.
Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
projects / mirror_edk2.git / log