The C ellipses parameters are passed to functions differently
by default with GCC 4.4. To make sure they are properly sent to
VariableGetBestLanguage, we add 'EFIAPI' to this function.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11119 6f19259b-4bc3-4df7-8a09-765794883524
1. EFI_INVALID_PARAMETER as a return value of SetVariable() to indicate it does not support this feature.
2. EFI_NOT_FOUND will be a return value of QueryVariableInfo() to indicate it does not support this feature.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10281 6f19259b-4bc3-4df7-8a09-765794883524
1. Rename EFI_PEI_NEXT_VARIABLE_NAME2 to EFI_PEI_GET_NEXT_VARIABLE_NAME2, as PI 1.2 specifies.
2. Add return status description for PEI Service FfsGetVolumeInfo.
3. Update parameter description for EFI_PEI_READ_ONLY_VARIABLE2_PPI.NextVariableName().
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9438 6f19259b-4bc3-4df7-8a09-765794883524
Add PcdEmuVariableNvStoreReserved which allows a platform to declare a
memory address for the EMU Variable driver to use for the NV variable
store. The EMU Variable driver will look to see if the contents of
this memory range appear to be a valid variable store, and if so
the EMU driver will use the variables.
If a platform can preserve a memory range across system resets, this
feature can allow the EMU Variable driver's NV variable store to be
preserved across a system reset.
In the default case this PCD will be set as a fixed PCD with a value
of 0. In this case this new feature should have minimal impact on
the EMU Variable driver. (Perhaps a slight increase in code size,
but no functional difference is expected.)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9240 6f19259b-4bc3-4df7-8a09-765794883524
1. record the distance of two neighboring VAR_ADDED type variables rather than the offset of each variable. As the field recording this info is UINT16 width, the latter causes in IA32/X64 platform, it can only cache those variables from offset 0 to offset 2^16; in IPF platform, from offset 0 to offset 2^18(extend the scope by left-shift the offset two bits).
when taking the former algorithm, the max range of caching variable is from offset 0 to offset 122*(2^16)
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8625 6f19259b-4bc3-4df7-8a09-765794883524
In UpdateVariableInfo(), the code incorrectly allocate a small memory, whose size equate with the number of Unicode name.
Should change it to be equal to the byte length of this Unicode name.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8457 6f19259b-4bc3-4df7-8a09-765794883524
routines similar to MdeModulePkg/Universal/Variable/RuntimeDxe.
When the Acquire was in the FindVariable routine, is was
being called by both EmuSetVariable and again in
AutoUpdateLangVariable, which caused an ASSERT to fail.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8205 6f19259b-4bc3-4df7-8a09-765794883524
2. Boot time variable reclaim issue is caused by incorrect flash layout. Platform integrator should ensure that the size of variable region must less than FTW spare space size.
3. Per UEFI Specification, variables of attribute HARDWARE_ERROR_RECORD are guaranteed to have its own storage space size.original implementation doesn’t meet this requirement
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8029 6f19259b-4bc3-4df7-8a09-765794883524
[Root Cause]
The root cause is that in FindVariable function, original code logic will traverse all variable stored in variable volatile/non-volatile area. If the non-variable area is full and Linux sets a new variable, the caller of GetNextVariablePtr will get the address of next memory block, but this block doesn't be reserved as RUNTIME attribute. Therefore its corresponding page translation table doesn't exist and causes linux kernel panic.
Note that, Variable Pei driver has not such issue as the flash area is accessed in pre-os environment.All page table entries are filled. The access to next memory block will not cause such issue.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7910 6f19259b-4bc3-4df7-8a09-765794883524
[Root Cause]
The root cause is that in FindVariable function, original code logic will traverse all variable stored in variable volatile/non-volatile area. If the non-variable area is full and Linux sets a new variable, the caller of GetNextVariablePtr will get the address of next memory block, but this block doesn't be reserved as RUNTIME attribute. Therefore its corresponding page translation table doesn't exist and causes linux kernel panic.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7890 6f19259b-4bc3-4df7-8a09-765794883524
2. modify the method of getting right FVB protocol interface. move the notification event of FVB installation into variable driver. and also move ExitBootService event into variable driver.
3. use EFI_FVB2_WRITE_STATUS flag to distinct whether the FVB protocol supports writing operation or not.Currently, DxeCore installs FVB which has ~EFI_FVB2_WRITE_STATUS(that is, disable write) attrbiute. FvbRuntimeDxe driver should provide a full FVB protocol, which returns EFI_FVB2_WRITE_STATUS attribute to signify itself provide writable FVB protocol. So other modules which need write data by FVB protocol can locate it correctly.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7835 6f19259b-4bc3-4df7-8a09-765794883524
2. when variable store header is invalid status, we will return EFI_VOLUME_CORRUPTED to let code assert, which is helpful to find root cause quickly.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7804 6f19259b-4bc3-4df7-8a09-765794883524
gdong1
jljusten
niruiyu
andrewfish
erictian
hhtian
xli24
lgao4
mdkinney
rsun3
eric_tian
qhuang8
gikidy