[edk2] [PATCH] EmulatorPkg/MpService: Read/Write processor State should hold mutex lock
Add mutex protect when manipulate processor State.
and fix some wrong Lock's usage in where using the addressof StateLock's
address.
gThread->MutexLock (&gMPSystem.ProcessorData[NextNumber].StateLock);
=>
gThread->MutexLock (gMPSystem.ProcessorData[NextNumber].StateLock);
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen Fan
---
EmulatorPkg/CpuRuntimeDxe/MpService.c | 37 ++-
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/EmulatorPkg/CpuRuntimeDxe/MpService.c
b/EmulatorPkg/CpuRuntimeDxe/MpService.c
index 9d67b86..0b5fcbd 100644
--- a/EmulatorPkg/CpuRuntimeDxe/MpService.c
+++ b/EmulatorPkg/CpuRuntimeDxe/MpService.c
@@ -437,17 +437,17 @@ CpuMpServicesStartupAllAps (
// state 1 by 1, until the previous 1 finished its task
// if not "SingleThread", all APs are put to ready state from the beginning
//
+gThread->MutexLock(ProcessorData->StateLock);
if (ProcessorData->State == CPU_STATE_IDLE) {
- gMPSystem.StartCount++;
-
- gThread->MutexLock (&ProcessorData->StateLock);
ProcessorData->State = APInitialState;
- gThread->MutexUnlock (&ProcessorData->StateLock);
+ gThread->MutexUnlock (ProcessorData->StateLock);
+ gMPSystem.StartCount++;
if (SingleThread) {
APInitialState = CPU_STATE_BLOCKED;
}
} else {
+ gThread->MutexUnlock (ProcessorData->StateLock);
return EFI_NOT_READY;
}
}
@@ -512,9 +512,9 @@ CpuMpServicesStartupAllAps (
if (SingleThread) {
Status = GetNextBlockedNumber (&NextNumber);
if (!EFI_ERROR (Status)) {
-gThread->MutexLock
(&gMPSystem.ProcessorData[NextNumber].StateLock);
+gThread->MutexLock (gMPSystem.ProcessorData[NextNumber].StateLock);
gMPSystem.ProcessorData[NextNumber].State = CPU_STATE_READY;
-gThread->MutexUnlock
(&gMPSystem.ProcessorData[NextNumber].StateLock);
+gThread->MutexUnlock
(gMPSystem.ProcessorData[NextNumber].StateLock);
}
}
@@ -671,9 +671,12 @@ CpuMpServicesStartupThisAP (
return EFI_INVALID_PARAMETER;
}
+ gThread->MutexLock(gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if (gMPSystem.ProcessorData[ProcessorNumber].State != CPU_STATE_IDLE) {
+gThread->MutexUnlock(gMPSystem.ProcessorData[ProcessorNumber].StateLock);
return EFI_NOT_READY;
}
+ gThread->MutexUnlock(gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if ((WaitEvent != NULL) && gReadToBoot) {
return EFI_UNSUPPORTED;
@@ -699,14 +702,14 @@ CpuMpServicesStartupThisAP (
// Blocking
while (TRUE) {
-gThread->MutexLock (&gMPSystem.ProcessorData[ProcessorNumber].StateLock);
+gThread->MutexLock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if (gMPSystem.ProcessorData[ProcessorNumber].State == CPU_STATE_FINISHED) {
gMPSystem.ProcessorData[ProcessorNumber].State = CPU_STATE_IDLE;
- gThread->MutexUnlock
(&gMPSystem.ProcessorData[ProcessorNumber].StateLock);
+ gThread->MutexUnlock
(gMPSystem.ProcessorData[ProcessorNumber].StateLock);
break;
}
-gThread->MutexUnlock (&gMPSystem.ProcessorData[ProcessorNumber].StateLock);
+gThread->MutexUnlock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if ((TimeoutInMicroseconds != 0) && (Timeout < 0)) {
return EFI_TIMEOUT;
@@ -789,10 +792,14 @@ CpuMpServicesSwitchBSP (
}
ASSERT (Index != gMPSystem.NumberOfProcessors);
+ gThread->MutexLock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if (gMPSystem.ProcessorData[ProcessorNumber].State != CPU_STATE_IDLE) {
+gThread->MutexUnlock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
return EFI_NOT_READY;
}
+ gThread->MutexUnlock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
+
// Skip for now as we need switch a bunch of stack stuff around and it's
complex
// May not be worth it?
return EFI_NOT_READY;
@@ -861,11 +868,13 @@ CpuMpServicesEnableDisableAP (
return EFI_INVALID_PARAMETER;
}
+ gThread->MutexLock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if (gMPSystem.ProcessorData[ProcessorNumber].State != CPU_STATE_IDLE) {
+gThread->MutexUnlock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
return EFI_UNSUPPORTED;
}
- gThread->MutexLock (&gMPSystem.ProcessorData[ProcessorNumber].StateLock);
+ gThread->MutexUnlock (gMPSystem.ProcessorData[ProcessorNumber].StateLock);
if (EnableAP) {
if ((gMPSystem.ProcessorData[ProcessorNumber].Info.StatusFlag &
PROCESSOR_ENABLED_BIT) == 0 ) {
@@ -884,8 +893,6 @@ CpuMpServicesEnableDisableAP (
gMPSystem.ProcessorData[ProcessorNumber].Info.StatusFlag |= (*HealthFlag &
PROCESSOR_HEALTH_STATUS_BIT);
}
- gThread->MutexUnlock (&gMPSystem.ProcessorData[ProcessorNumber].StateLock);
-
return EFI_SUCCESS;
}
@@ -1015,15 +1022,17 @@ CpuCheckAllAPsStatus (
if (!EFI_ERROR
[edk2] [CryptoPkg][StdLib] Ia32 calling convention question
CryptoPkg & StdLib maintainers, It looks to me like some of the IA32 *.S files are using __stdcall (Pascal calling convention) and this will not work correctly with EFI? It seems like this will mess up the stack? If it is dead code what is the point of checking it in? ~/work/src/edk2(master)>git grep ret -- *.S | grep '\$' CryptoPkg/Library/BaseCryptLib/SysCall/Ia32/MathDivU64x64.S:83:ret $16 CryptoPkg/Library/BaseCryptLib/SysCall/Ia32/MathMultS64x64.S:77:ret $16 CryptoPkg/Library/BaseCryptLib/SysCall/Ia32/MathReminderU64x64.S:89:ret $16 ... StdLib/LibC/CRT/Ia32/mulll.S:77:ret $16 StdLib/LibC/CRT/Ia32/udivdi3.S:83:ret $16 StdLib/LibC/CRT/Ia32/umoddi3.S:89:ret $16 Thanks, Andrew Fish -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH] OvmfPkg/Csm/CsmSupportLib: fix "missing braces around initializer"
Recent BaseTools changes trigger this gcc warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c
b/OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c
index af8896a..867b128 100644
--- a/OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c
+++ b/OvmfPkg/Csm/CsmSupportLib/LegacyPlatform.c
@@ -30,10 +30,10 @@ EFI_SETUP_BBS_MAP mSetupBbsMap[] = {
// Global variables for System ROMs
//
#define SYSTEM_ROM_FILE_GUID \
-{ 0x1547B4F3, 0x3E8A, 0x4FEF, 0x81, 0xC8, 0x32, 0x8E, 0xD6, 0x47, 0xAB, 0x1A }
+{ 0x1547B4F3, 0x3E8A, 0x4FEF, { 0x81, 0xC8, 0x32, 0x8E, 0xD6, 0x47, 0xAB, 0x1A
} }
#define NULL_ROM_FILE_GUID \
-{ 0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
+{ 0x, 0x, 0x, { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
} }
SYSTEM_ROM_TABLE mSystemRomTable[] = {
{ SYSTEM_ROM_FILE_GUID, 1 },
@@ -82,12 +82,12 @@ EFI_LEGACY_PIRQ_TABLE PirqTableHead = {
// -- Pin 1 -- -- Pin 2 -- -- Pin 3 -- -- Pin 4 --
// Bus Dev Reg Map Reg Map Reg Map Reg Map
-0x00,0x08,0x60,0xDEB8,0x61,0xDEB8,0x62,0xDEB8,0x63,0xDEB8,0x00,0x00,
-0x00,0x10,0x61,0xDEB8,0x62,0xDEB8,0x63,0xDEB8,0x60,0xDEB8,0x01,0x00,
-0x00,0x18,0x62,0xDEB8,0x63,0xDEB8,0x60,0xDEB8,0x61,0xDEB8,0x02,0x00,
-0x00,0x20,0x63,0xDEB8,0x60,0xDEB8,0x61,0xDEB8,0x62,0xDEB8,0x03,0x00,
-0x00,0x28,0x60,0xDEB8,0x61,0xDEB8,0x62,0xDEB8,0x63,0xDEB8,0x04,0x00,
-0x00,0x30,0x61,0xDEB8,0x62,0xDEB8,0x63,0xDEB8,0x60,0xDEB8,0x05,0x00,
+
{0x00,0x08,{{0x60,0xDEB8},{0x61,0xDEB8},{0x62,0xDEB8},{0x63,0xDEB8}},0x00,0x00},
+
{0x00,0x10,{{0x61,0xDEB8},{0x62,0xDEB8},{0x63,0xDEB8},{0x60,0xDEB8}},0x01,0x00},
+
{0x00,0x18,{{0x62,0xDEB8},{0x63,0xDEB8},{0x60,0xDEB8},{0x61,0xDEB8}},0x02,0x00},
+
{0x00,0x20,{{0x63,0xDEB8},{0x60,0xDEB8},{0x61,0xDEB8},{0x62,0xDEB8}},0x03,0x00},
+
{0x00,0x28,{{0x60,0xDEB8},{0x61,0xDEB8},{0x62,0xDEB8},{0x63,0xDEB8}},0x04,0x00},
+
{0x00,0x30,{{0x61,0xDEB8},{0x62,0xDEB8},{0x63,0xDEB8},{0x60,0xDEB8}},0x05,0x00},
}
};
--
1.8.3.1
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] VFR Expression Grammar Issues
The current VFR Grammar, as expressed in section 2.12 of the VFR specification, does not seem to be viable. Take the following piece: 2.12.1: [cid:image001.png@01CFA5C4.78ADC1A0] But imagine the following grammar: 5 OR 3 OR 2 This will go andTerm (returning 5) then "OR" but then it will have andTerm again, so the 2nd "OR" will not ever be processed. I believe that this should be: andTerm ( "OR" vfrStatementExpression) Likewise, each of the following sections (2.12.2 and following), seems to suffer from the same issue. Tim -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] Recommended EDK2 release for building for older UEFI specification versions
What's the recommended EDK2 release to use when building binaries for UEFI 2.3.1? I know the UDK2014 supports 2.4, but is it recommended to use the older UDK2010 or upgrade to 2014? Related to this, is there any mechanism similar to _WIN32_WINNT in userspace Windows applications for restricting the use of features to those available in earlier specification versions? I found the INF UEFI_SPECIFICATION_VERSION setting, but it wasn't clear to me how it's used. -- Bruce -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v3 0/2] OvmfPkg: split the variable store to a separate file
Reviewed-by: Jordan Justen and committed in r15670. Thanks! On Tue, Jul 22, 2014 at 3:36 AM, Laszlo Ersek wrote: > In v2 I did notice that some further simplification would be possible by > curtailing the remaining ifdeffery. However I didn't believe (and the > FDF spec didn't say) that one could use macros in the FD Layout Regions > too (ie. for offset and size). Jordan has made me aware of that > possibility, so patch #2 now introduces three more macros, and removes > the remaining FD_SIZE_1MB-dependent branching in the FDF files. > > https://github.com/lersek/edk2/commits/split_varstore_v3 > > Laszlo Ersek (2): > OvmfPkg: extract varstore-related FD Layout Regions to an include file > OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd > > OvmfPkg/OvmfPkg.fdf.inc| 63 > OvmfPkg/OvmfPkgIa32.fdf| 119 > + > OvmfPkg/OvmfPkgIa32X64.fdf | 119 > + > OvmfPkg/OvmfPkgX64.fdf | 119 > + > OvmfPkg/VarStore.fdf.inc | 80 ++ > 5 files changed, 245 insertions(+), 255 deletions(-) > create mode 100644 OvmfPkg/OvmfPkg.fdf.inc > create mode 100644 OvmfPkg/VarStore.fdf.inc > > -- > 1.8.3.1 > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] FwVol.c:FindFileEx: Getting EFI_FIRMWARE_VOLUME_HEADER
On Jul 22, 2014, at 1:07 PM, Varad Gautam wrote:
> Hi,
>
> I'm tracing the execution of PrePiLib:LoadDxeFromFv() and have a few
> questions.
>
> After getting VolumeHandle from the Hob in FfsFindNextVolume(), it is casted
> to
> `EFI_FIRMWARE_VOLUME_HEADER*` in FindFileEx() [1]. How does this work?
> I could not find `EFI_PEI_FV_HANDLE` being populated anywhere with fields in a
> `EFI_FIRMWARE_VOLUME_HEADER*`, and so for me, the FvLength [2] gets set
> to 0.
>
> Also, the call to PlatformPeim() at [3] appends a single PCD-specified
> FV to the Hob list.
My guess is the PCD is pointing to the wrong place in your port.
The best way to debug this is to generate a build report. You just need to add
-y REPORTFILE to the build command.
-y REPORTFILE, --report-file=REPORTFILE
Create/overwrite the report to the specified filename.
-Y REPORTTYPE, --report-type=REPORTTYPE
Flags that control the type of build report to
generate. Must be one of: [PCD, LIBRARY, FLASH,
DEPEX, BUILD_FLAGS, FIXED_ADDRESS, EXECUTION_ORDER].
To specify more than one flag, repeat this option on
the command line and the default flag set is [PCD,
LIBRARY, FLASH, DEPEX, BUILD_FLAGS, FIXED_ADDRESS]
> So, I figure, this approach would not work if there are multiple
> non-nested FVs placed
> into an FD with DxeCore being in a separate FV from PrePi?
>
The FV HOB(s) (you can have more than one) only point to memory mapped FVs, and
this generally maps to your FLASH layout. So it is legal to have as many as you
want.
The “nested” FVs are not reported via the FV HOB, since they are discoverable
in a reported FV.
>
> [1]
> https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Library/PrePiLib/FwVol.c#L181
The EFI_PEI_FV_HANDLE exists to abstract the implementation of the file system
from the API. Thus it is possible for the PEI Core to support a 3rd party file
system vi a PPI plug in.
When the file system is the PI defined one, then it is legal to make the
EFI_PEI_FV_HANDLE a pointer to the EFI_FIRMWARE_VOLUME_HEADER. The PEI Core has
used this scheme in the past.
By definition the FV Header is at the beginning of the FV.
> [2]
> https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Library/PrePiLib/FwVol.c#L184
The start of the Volume should be a header. It would probably be a good idea to
add a check of the FwVolHeader->Signature == EFI_FVH_SIGNATURE at the start of
the function.
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Pi/PiFirmwareVolume.h
///
/// Describes the features and layout of the firmware volume.
///
typedef struct {
///
/// The first 16 bytes are reserved to allow for the reset vector of
/// processors whose reset vector is at address 0.
///
UINT8 ZeroVector[16];
///
/// Declares the file system with which the firmware volume is formatted.
///
EFI_GUID FileSystemGuid;
///
/// Length in bytes of the complete firmware volume, including the header.
///
UINT64FvLength;
///
/// Set to EFI_FVH_SIGNATURE
///
UINT32Signature;
///
/// Declares capabilities and power-on defaults for the firmware volume.
///
EFI_FVB_ATTRIBUTES_2 Attributes;
///
/// Length in bytes of the complete firmware volume header.
///
UINT16HeaderLength;
///
/// A 16-bit checksum of the firmware volume header. A valid header sums to
zero.
///
UINT16Checksum;
///
/// Offset, relative to the start of the header, of the extended header
/// (EFI_FIRMWARE_VOLUME_EXT_HEADER) or zero if there is no extended header.
///
UINT16ExtHeaderOffset;
///
/// This field must always be set to zero.
///
UINT8 Reserved[1];
///
/// Set to 2. Future versions of this specification may define new header
fields and will
/// increment the Revision field accordingly.
///
UINT8 Revision;
///
/// An array of run-length encoded FvBlockMapEntry structures. The array is
/// terminated with an entry of {0,0}.
///
EFI_FV_BLOCK_MAP_ENTRYBlockMap[1];
} EFI_FIRMWARE_VOLUME_HEADER;
#define EFI_FVH_SIGNATURE SIGNATURE_32 ('_', 'F', 'V', 'H')
Thanks,
Andrew Fish
> [3]
> https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/PrePi/PrePi.c#L175
>
> Thanks,
> Varad
>
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> ed
[edk2] FwVol.c:FindFileEx: Getting EFI_FIRMWARE_VOLUME_HEADER
Hi, I'm tracing the execution of PrePiLib:LoadDxeFromFv() and have a few questions. After getting VolumeHandle from the Hob in FfsFindNextVolume(), it is casted to `EFI_FIRMWARE_VOLUME_HEADER*` in FindFileEx() [1]. How does this work? I could not find `EFI_PEI_FV_HANDLE` being populated anywhere with fields in a `EFI_FIRMWARE_VOLUME_HEADER*`, and so for me, the FvLength [2] gets set to 0. Also, the call to PlatformPeim() at [3] appends a single PCD-specified FV to the Hob list. So, I figure, this approach would not work if there are multiple non-nested FVs placed into an FD with DxeCore being in a separate FV from PrePi? [1] https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Library/PrePiLib/FwVol.c#L181 [2] https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Library/PrePiLib/FwVol.c#L184 [3] https://github.com/tianocore/edk2/blob/master/ArmPlatformPkg/PrePi/PrePi.c#L175 Thanks, Varad -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg
chen.fan.f...@cn.fujitsu.com [mailto:chen.fan.f...@cn.fujitsu.com] wrote: ]On Tue, 2014-07-22 at 01:32 +, Fan, Jeff wrote: ]> Fan, ]> ]> If you want to promote this feature into EDKII UefiCpuPkg, please re-create the ]patch based on the current revision of EDK2 like Scott said. Then we could give ]further comments based on the new patch. Thanks your contribution! ]> ] ]OK, I will re-create the patch and send them in the near future. ]Thanks for your suggestion. ]Chen One more thing to consider. Jordan's ap-startup-example adds some gnu gas syntax assembly language files. To support building with Microsoft tools, corresponding masm syntax files need to be added. So you need to add: UefiCpuPkg\CpuDxe\Ia32\MpAsm.asm UefiCpuPkg\CpuDxe\X64\MpAsm.asm and update UefiCpuPkg\CpuDxe\CpuDxe.inf to match. Thanks, Scott > Jeff > -Original Message- > From: Scott Duplichan [mailto:sc...@notabs.org] > Sent: Tuesday, July 22, 2014 12:16 AM > To: edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [RFC 0/2] Introduce Mp Service protocol to UefiCpuPkg > > Chen Fan [mailto:chen.fan.f...@cn.fujitsu.com] wrote: > > ]This series patches is base on Jljusten's tree: > ]https://github.com/jljusten/edk2/tree/ap-startup-example > > ]this patches tried to implement Mp Service protocol in UefiCpuPkg, ]there > was only startup APs in previous code, so add some initialization ]to let all APs work up, this Mp Service protocol's implementation ]use EmulatorPkg/Mp service for reference. > ] > ]and I used Ovmf and StartCorePkg to test this Mp Service protocol, ]it > seemed good. > > Hello Chen Fan, > > It looks like this patch is for application to Jljustin's branch > of EDK2. Shouldn't the patch be formatted so that it can apply to a recent > revision of the official EDK2 tree instead? > > Thanks, > Scott -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] PrePi.c:DecompressFirstFv() Use Conditions
On Jul 21, 2014, at 10:48 PM, Varad Gautam wrote: > Hi, I'm working on the BeagleBoneBlack port for UEFI. I am using the > PrePi as the entry point, and need some help with the call to > DecompressFirstFv(). > > I figure that FwVol.c:FfsAnyFvFindFirstFile() loops through each FV it > gets from the FV HOB and searches for > `EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE`, but I don't understand the > difference between searching for 'Next Volume' and 'Next File of the > type FIRMWARE_VOLUME_IMAGE'. > > Are we assuming a definite layout of the FD for this to work? > The lingo is: FD - This is the FLASH Device and can include a set of FVs and other data regions. FV - A simple Flash File system that contains files, but no directories. File - A file has a name (GUID), a well known type, and consists of a collection of sections. A section can encapsulate other sections. Section extraction is the process used to unwrap the encapsulate sections. So the Next Volume is looking for another FV. One of the supported file types in an FV is EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE. So an FV can contain a file that is an FV. It is not uncommon for an FV to contain a compressed FV as a file. The code to turn on memory and do the decompression is in the outer FV and the FV in the file is decompressed and copied into memory. This is just following the FV architecture defined in the PI 1.3 spec (http://www.uefi.org/specsandtesttools) https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/Include/Pi/PiFirmwareFile.h /// /// File Types Definitions /// #define EFI_FV_FILETYPE_ALL 0x00 #define EFI_FV_FILETYPE_RAW 0x01 #define EFI_FV_FILETYPE_FREEFORM 0x02 #define EFI_FV_FILETYPE_SECURITY_CORE 0x03 #define EFI_FV_FILETYPE_PEI_CORE 0x04 #define EFI_FV_FILETYPE_DXE_CORE 0x05 #define EFI_FV_FILETYPE_PEIM 0x06 #define EFI_FV_FILETYPE_DRIVER0x07 #define EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08 #define EFI_FV_FILETYPE_APPLICATION 0x09 #define EFI_FV_FILETYPE_SMM 0x0A #define EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B #define EFI_FV_FILETYPE_COMBINED_SMM_DXE 0x0C #define EFI_FV_FILETYPE_SMM_CORE 0x0D #define EFI_FV_FILETYPE_OEM_MIN 0xc0 #define EFI_FV_FILETYPE_OEM_MAX 0xdf #define EFI_FV_FILETYPE_DEBUG_MIN 0xe0 #define EFI_FV_FILETYPE_DEBUG_MAX 0xef #define EFI_FV_FILETYPE_FFS_MIN 0xf0 #define EFI_FV_FILETYPE_FFS_MAX 0xff #define EFI_FV_FILETYPE_FFS_PAD 0xf0 Thanks, Andrew Fish PS Another example of this logic is the DXE Dispatcher that can load EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE from an FV that it discovers. The file can even have a Depex, so the FV is not dispatched until the dependencies are met. https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c search for EFI_SECTION_DXE_DEPEX. > Thanks, > Varad > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
[edk2] [PATCH v3 2/2] OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd
OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware code in separate files. The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. With the split files, it must be ensured on the QEMU command line that OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). In this patch we must take care to assign each PCD only once. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- Notes: v3: - introduce FVMAIN_SIZE, SECFV_OFFSET, and SECFV_SIZE macros in order to collapse remaining ifdef $(FD_SIZE_1MB) chunks OvmfPkg/OvmfPkg.fdf.inc| 63 ++ OvmfPkg/OvmfPkgIa32.fdf| 54 --- OvmfPkg/OvmfPkgIa32X64.fdf | 54 --- OvmfPkg/OvmfPkgX64.fdf | 54 --- OvmfPkg/VarStore.fdf.inc | 5 5 files changed, 165 insertions(+), 65 deletions(-) create mode 100644 OvmfPkg/OvmfPkg.fdf.inc diff --git a/OvmfPkg/OvmfPkg.fdf.inc b/OvmfPkg/OvmfPkg.fdf.inc new file mode 100644 index 000..6c0dc54 --- /dev/null +++ b/OvmfPkg/OvmfPkg.fdf.inc @@ -0,0 +1,63 @@ +## @file +# FDF include file that defines the main macros and sets the dependent PCDs. +# +# Copyright (C) 2014, Red Hat, Inc. +# +# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved. +# +# This program and the accompanying materials are licensed and made available +# under the terms and conditions of the BSD License which accompanies this +# distribution. The full text of the license may be found at +# http://opensource.org/licenses/bsd-license.php +# +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR +# IMPLIED. +# +## + +DEFINE BLOCK_SIZE= 0x1000 +DEFINE VARS_SIZE = 0x2 +DEFINE VARS_BLOCKS = 0x20 + +!ifdef $(FD_SIZE_1MB) + +DEFINE FW_BASE_ADDRESS = 0xFFF0 +DEFINE FW_SIZE = 0x0010 +DEFINE FW_BLOCKS = 0x100 +DEFINE CODE_BASE_ADDRESS = 0xFFF2 +DEFINE CODE_SIZE = 0x000E +DEFINE CODE_BLOCKS = 0xE0 +DEFINE FVMAIN_SIZE = 0x000CC000 +DEFINE SECFV_OFFSET = 0x000EC000 +DEFINE SECFV_SIZE= 0x14000 + +!else + +DEFINE FW_BASE_ADDRESS = 0xFFE0 +DEFINE FW_SIZE = 0x0020 +DEFINE FW_BLOCKS = 0x200 +DEFINE CODE_BASE_ADDRESS = 0xFFE2 +DEFINE CODE_SIZE = 0x001E +DEFINE CODE_BLOCKS = 0x1E0 +DEFINE FVMAIN_SIZE = 0x001AC000 +DEFINE SECFV_OFFSET = 0x001CC000 +DEFINE SECFV_SIZE= 0x34000 + +!endif + +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS) +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize= $(FW_SIZE) +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE) + +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase = $(FW_BASE_ADDRESS) +SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize = 0xE000 + +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize = $(BLOCK_SIZE) + +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase + gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize +SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize = $(BLOCK_SIZE) + +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase = gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase + gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize +SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize = 0x1 diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index f47655c..243cff3 100644 --- a/OvmfPkg/OvmfPkgIa32.fdf +++ b/OvmfPkg/OvmfPkgIa32.fdf @@ -28,38 +28,52 @@ DEFINE FD_SIZE_1MB= !endif !endif -!ifdef $(FD_SIZE_1MB) -[FD.OVMF] -BaseAddress = 0xFFF0|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress -Size = 0x0010|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize -ErasePolarity = 1 -BlockSize = 0x1000|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize -NumBlocks = 0x100 -!else +!include OvmfPkg.fdf.inc + +# +# Build the variable store and the firmware code as one unified flash device +# image. +# [FD.OVMF] -BaseAddress = 0xFFE0|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress -Size = 0x0020|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize +BaseAddress = $(FW_BASE_ADDRESS) +Size = $(FW_SIZE) ErasePolarity = 1 -BlockSize = 0x1000|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize -NumBlocks = 0x200 -!endif +BlockSize
[edk2] [PATCH v3 1/2] OvmfPkg: extract varstore-related FD Layout Regions to an include file
This saves code duplication between the Ia32, Ia32X64, and X64 flavors,
and enables the next patch to include the varstore in new FD files by
reference.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Jordan Justen
Signed-off-by: Laszlo Ersek
---
OvmfPkg/OvmfPkgIa32.fdf| 67 +---
OvmfPkg/OvmfPkgIa32X64.fdf | 67 +---
OvmfPkg/OvmfPkgX64.fdf | 67 +---
OvmfPkg/VarStore.fdf.inc | 85 ++
4 files changed, 88 insertions(+), 198 deletions(-)
create mode 100644 OvmfPkg/VarStore.fdf.inc
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 76b868d..f47655c 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -44,72 +44,7 @@ BlockSize =
0x1000|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize
NumBlocks = 0x200
!endif
-0x|0xe000
-gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-#NV_VARIABLE_STORE
-DATA = {
- ## This is the EFI_FIRMWARE_VOLUME_HEADER
- # ZeroVector []
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- # FileSystemGuid: gEfiSystemNvDataFvGuid =
- # { 0xFFF12B8D, 0x7696, 0x4C8B,
- # { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
- 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
- 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
- # FvLength: 0x2
- 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
- # Signature "_FVH" # Attributes
- 0x5f, 0x46, 0x56, 0x48, 0xff, 0xfe, 0x04, 0x00,
- # HeaderLength # CheckSum # ExtHeaderOffset #Reserved #Revision
- 0x48, 0x00, 0x19, 0xF9, 0x00, 0x00, 0x00, 0x02,
- # Blockmap[0]: 0x20 Blocks * 0x1000 Bytes / Block
- 0x20, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00,
- # Blockmap[1]: End
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- ## This is the VARIABLE_STORE_HEADER
-!if $(SECURE_BOOT_ENABLE) == TRUE
- # Signature: gEfiAuthenticatedVariableGuid =
- # { 0xaaf32c78, 0x947b, 0x439a,
- # { 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92 }}
- 0x78, 0x2c, 0xf3, 0xaa, 0x7b, 0x94, 0x9a, 0x43,
- 0xa1, 0x80, 0x2e, 0x14, 0x4e, 0xc3, 0x77, 0x92,
-!else
- # Signature: gEfiVariableGuid =
- # { 0xddcf3616, 0x3275, 0x4164,
- # { 0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d }}
- 0x16, 0x36, 0xcf, 0xdd, 0x75, 0x32, 0x64, 0x41,
- 0x98, 0xb6, 0xfe, 0x85, 0x70, 0x7f, 0xfe, 0x7d,
-!endif
- # Size: 0xe000
(gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) -
- # 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0xdfb8
- # This can speed up the Variable Dispatch a bit.
- 0xB8, 0xDF, 0x00, 0x00,
- # FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
- 0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-}
-
-0xe000|0x1000
-#NV_EVENT_LOG
-gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize
-
-0xf000|0x1000
-gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
-#NV_FTW_WORKING
-DATA = {
- # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature =
gEdkiiWorkingBlockSignatureGuid =
- # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b,
0x95 }}
- 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
- 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95,
- # Crc:UINT32#WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
- 0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
- # WriteQueueSize: UINT64
- 0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-}
-
-0x0001|0x0001
-#NV_FTW_SPARE
-gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
+!include VarStore.fdf.inc
!ifdef $(FD_SIZE_1MB)
0x0002|0x000CC000
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index e037b72..dd705a8 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -44,72 +44,7 @@ BlockSize =
0x1000|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize
NumBlocks = 0x200
!endif
-0x|0xe000
-gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-#NV_VARIABLE_STORE
-DATA = {
- ## This is the EFI_FIRMWARE_VOLUME_HEADER
- # ZeroVector []
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
- # FileSystemGuid: gEfiSystemNvDataFvGuid =
- # { 0xFFF12B8D, 0x7696, 0x4C8B,
- # { 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50 }}
- 0x8D, 0x2B, 0xF1, 0xFF, 0x96, 0x76, 0x8B, 0x4C,
- 0xA9, 0x85, 0x27, 0x47, 0x07, 0x5B, 0x4F, 0x50,
- # FvLength: 0x2
- 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00,
- # Signature "_FVH"
[edk2] [PATCH v3 0/2] OvmfPkg: split the variable store to a separate file
In v2 I did notice that some further simplification would be possible by curtailing the remaining ifdeffery. However I didn't believe (and the FDF spec didn't say) that one could use macros in the FD Layout Regions too (ie. for offset and size). Jordan has made me aware of that possibility, so patch #2 now introduces three more macros, and removes the remaining FD_SIZE_1MB-dependent branching in the FDF files. https://github.com/lersek/edk2/commits/split_varstore_v3 Laszlo Ersek (2): OvmfPkg: extract varstore-related FD Layout Regions to an include file OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd OvmfPkg/OvmfPkg.fdf.inc| 63 OvmfPkg/OvmfPkgIa32.fdf| 119 + OvmfPkg/OvmfPkgIa32X64.fdf | 119 + OvmfPkg/OvmfPkgX64.fdf | 119 + OvmfPkg/VarStore.fdf.inc | 80 ++ 5 files changed, 245 insertions(+), 255 deletions(-) create mode 100644 OvmfPkg/OvmfPkg.fdf.inc create mode 100644 OvmfPkg/VarStore.fdf.inc -- 1.8.3.1 -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/2] OvmfPkg: build OVMF_VARS.fd, OVMF_CODE.fd, OVMF.fd
On Fri, Jul 18, 2014 at 6:28 PM, Laszlo Ersek wrote: > OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware > code in separate files. > > The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB. > With the split files, it must be ensured on the QEMU command line that > OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end > exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0). > > In this patch we must take care to assign each PCD only once. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek > --- > OvmfPkg/OvmfPkg.fdf.inc| 57 > OvmfPkg/OvmfPkgIa32.fdf| 59 > -- > OvmfPkg/OvmfPkgIa32X64.fdf | 59 > -- > OvmfPkg/OvmfPkgX64.fdf | 59 > -- > OvmfPkg/VarStore.fdf.inc | 5 > 5 files changed, 195 insertions(+), 44 deletions(-) > create mode 100644 OvmfPkg/OvmfPkg.fdf.inc > > diff --git a/OvmfPkg/OvmfPkg.fdf.inc b/OvmfPkg/OvmfPkg.fdf.inc > new file mode 100644 > index 000..6cc810e > --- /dev/null > +++ b/OvmfPkg/OvmfPkg.fdf.inc > @@ -0,0 +1,57 @@ > +## @file > +# FDF include file that defines the main macros and sets the dependent PCDs. > +# > +# Copyright (C) 2014, Red Hat, Inc. > +# > +# Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved. > +# > +# This program and the accompanying materials are licensed and made > available > +# under the terms and conditions of the BSD License which accompanies this > +# distribution. The full text of the license may be found at > +# http://opensource.org/licenses/bsd-license.php > +# > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR > +# IMPLIED. > +# > +## > + > +DEFINE BLOCK_SIZE= 0x1000 > +DEFINE VARS_SIZE = 0x2 > +DEFINE VARS_BLOCKS = 0x20 > + > +!ifdef $(FD_SIZE_1MB) > + > +DEFINE FW_BASE_ADDRESS = 0xFFF0 > +DEFINE FW_SIZE = 0x0010 > +DEFINE FW_BLOCKS = 0x100 > +DEFINE CODE_BASE_ADDRESS = 0xFFF2 > +DEFINE CODE_SIZE = 0x000E > +DEFINE CODE_BLOCKS = 0xE0 > + > +!else > + > +DEFINE FW_BASE_ADDRESS = 0xFFE0 > +DEFINE FW_SIZE = 0x0020 > +DEFINE FW_BLOCKS = 0x200 > +DEFINE CODE_BASE_ADDRESS = 0xFFE2 > +DEFINE CODE_SIZE = 0x001E > +DEFINE CODE_BLOCKS = 0x1E0 > + > +!endif > + > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS) > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize= $(FW_SIZE) > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE) > + > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase = > $(FW_BASE_ADDRESS) > +SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize = 0xE000 > + > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase = > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageVariableBase + > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize = > $(BLOCK_SIZE) > + > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase = > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogBase + > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageEventLogSize > +SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize = > $(BLOCK_SIZE) > + > +SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwSpareBase = > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashNvStorageFtwWorkingBase + > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize > +SET gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize = 0x1 > diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf > index f47655c..cd0e9cc 100644 > --- a/OvmfPkg/OvmfPkgIa32.fdf > +++ b/OvmfPkg/OvmfPkgIa32.fdf > @@ -28,21 +28,18 @@ DEFINE FD_SIZE_1MB= > !endif > !endif > > -!ifdef $(FD_SIZE_1MB) > +!include OvmfPkg.fdf.inc > + > +# > +# Build the variable store and the firmware code as one unified flash device > +# image. > +# > [FD.OVMF] > -BaseAddress = 0xFFF0|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress > -Size = 0x0010|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize > +BaseAddress = $(FW_BASE_ADDRESS) > +Size = $(FW_SIZE) > ErasePolarity = 1 > -BlockSize = 0x1000|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize > -NumBlocks = 0x100 > -!else > -[FD.OVMF] > -BaseAddress = 0xFFE0|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress > -Size = 0x0020|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize > -ErasePolarity = 1 > -BlockSize = 0x1000|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize > -NumBlocks = 0x200 > -!endif > +BlockSize = $(BLOCK_SIZE) > +NumBlocks = $(FW_BLOCK
Re: [edk2] [PATCH] EmulatorPkg/MpService: modify AP state should hold a mutex
Reviewed-by: Jordan Justen
By the way, I noticed in CpuCheckAllAPsStatus we lock ProcedureLock
when setting State.
CpuMpServicesEnableDisableAP's usage of StateLock looks a bit sketchy too.
On Thu, Jul 17, 2014 at 8:11 PM, Chen Fan wrote:
> Add mutex when change AP state.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chen Fan
> ---
> EmulatorPkg/CpuRuntimeDxe/MpService.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/EmulatorPkg/CpuRuntimeDxe/MpService.c
> b/EmulatorPkg/CpuRuntimeDxe/MpService.c
> index 792d0e4..9d67b86 100644
> --- a/EmulatorPkg/CpuRuntimeDxe/MpService.c
> +++ b/EmulatorPkg/CpuRuntimeDxe/MpService.c
> @@ -512,11 +512,16 @@ CpuMpServicesStartupAllAps (
> if (SingleThread) {
>Status = GetNextBlockedNumber (&NextNumber);
>if (!EFI_ERROR (Status)) {
> +gThread->MutexLock
> (&gMPSystem.ProcessorData[NextNumber].StateLock);
> gMPSystem.ProcessorData[NextNumber].State = CPU_STATE_READY;
> +gThread->MutexUnlock
> (&gMPSystem.ProcessorData[NextNumber].StateLock);
>}
> }
>
> +gThread->MutexLock (ProcessorData->StateLock);
> ProcessorData->State = CPU_STATE_IDLE;
> +gThread->MutexUnlock (ProcessorData->StateLock);
> +
> break;
>
>default:
> --
> 1.9.3
>
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
