Re: [edk2] [Patch v3] NetworkPkg: Add old IPv4_DEVICE_PATH and IPv6_DEVICE_PATH support
Reviewed-by: Ye Ting ting...@intel.com
-Original Message-
From: Wang, Fan
Sent: Wednesday, July 22, 2015 8:57 AM
To: Ye, Ting; Fu, Siyuan; Wu, Jiaxin; edk2-de...@lists.sourceforge.net;
edk2-devel@lists.01.org
Cc: Tian, Hot; Ni, Ruiyu
Subject: [Patch v3] NetworkPkg: Add old IPv4_DEVICE_PATH and IPv6_DEVICE_PATH
support
v3:
* Update the macro of Ip4 device path node length and Ip6 device path node
length.
GatewayIpAddress and SubnetMask do not exist in old IPv4_DEVICE_PATH,
IPAddressOrigin, PrefixLength and GatewayIPAddress do not exist in old
IPv6_DEVICE_PATH. This will lead new IScsiDxe to error without updating
IPv4_DEVICE_PATH and IPv6_DEVICE_PATH in system.
Following UEFI2.5 spec of IPv4_DEVICE_PATH do a check before accessing fields
only defined in new version's IPv4_DEVICE_PATH, and revise the same issue for
IPv6_DEVICE_PATH in Iscsi driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: fanwang2 fan.w...@intel.com
---
NetworkPkg/IScsiDxe/IScsiMisc.c | 62 +
NetworkPkg/IScsiDxe/IScsiMisc.h | 18 +++-
2 files changed, 67 insertions(+), 13 deletions(-)
diff --git a/NetworkPkg/IScsiDxe/IScsiMisc.c b/NetworkPkg/IScsiDxe/IScsiMisc.c
index aeb99e5..010d2a4 100644
--- a/NetworkPkg/IScsiDxe/IScsiMisc.c
+++ b/NetworkPkg/IScsiDxe/IScsiMisc.c
@@ -1,9 +1,9 @@
/** @file
Miscellaneous routines for iSCSI driver.
-Copyright (c) 2004 - 2014, Intel Corporation. All rights reserved.BR
+Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.BR
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
@@ -1350,10 +1350,11 @@ IScsiGetTcpConnDevicePath (
{
ISCSI_CONNECTION *Conn;
EFI_DEVICE_PATH_PROTOCOL *DevicePath;
EFI_STATUSStatus;
EFI_DEV_PATH *DPathNode;
+ UINTN PathLen;
if (Session-State != SESSION_STATE_LOGGED_IN) {
return NULL;
}
@@ -1388,25 +1389,62 @@ IScsiGetTcpConnDevicePath (
DPathNode-Ipv4.LocalPort = 0;
DPathNode-Ipv4.StaticIpAddress =
(BOOLEAN)
(!Session-ConfigData-SessionConfigData.InitiatorInfoFromDhcp);
-IP4_COPY_ADDRESS (
- DPathNode-Ipv4.GatewayIpAddress,
- Session-ConfigData-SessionConfigData.Gateway
- );
+//
+// Add a judgement here to support previous versions of
IPv4_DEVICE_PATH.
+// In previous versions of IPv4_DEVICE_PATH, GatewayIpAddress and
SubnetMask
+// do not exist.
+// In new version of IPv4_DEVICE_PATH, structcure length is 27.
+//
-IP4_COPY_ADDRESS (
- DPathNode-Ipv4.SubnetMask,
- Session-ConfigData-SessionConfigData.SubnetMask
- );
+PathLen = DevicePathNodeLength (DPathNode-Ipv4);
+
+if (PathLen == IPv4_NODE_LEN_NEW_VERSIONS) {
+
+ IP4_COPY_ADDRESS (
+DPathNode-Ipv4.GatewayIpAddress,
+Session-ConfigData-SessionConfigData.Gateway
+);
+
+ IP4_COPY_ADDRESS (
+DPathNode-Ipv4.SubnetMask,
+Session-ConfigData-SessionConfigData.SubnetMask
+);
+}
+
break;
} else if (Conn-Ipv6Flag DevicePathSubType (DPathNode-DevPath) ==
MSG_IPv6_DP) {
DPathNode-Ipv6.LocalPort = 0;
-DPathNode-Ipv6.IpAddressOrigin = 0;
-DPathNode-Ipv6.PrefixLength= IP6_PREFIX_LENGTH;
-ZeroMem (DPathNode-Ipv6.GatewayIpAddress, sizeof (EFI_IPv6_ADDRESS));
+
+//
+// Add a judgement here to support previous versions of
IPv6_DEVICE_PATH.
+// In previous versions of IPv6_DEVICE_PATH, IpAddressOrigin,
PrefixLength
+// and GatewayIpAddress do not exist.
+// In new version of IPv6_DEVICE_PATH, structure length is 60, while
in
+// old versions, the length is 43.
+//
+
+PathLen = DevicePathNodeLength (DPathNode-Ipv6);
+
+if (PathLen == IPv6_NODE_LEN_NEW_VERSIONS ) {
+
+ DPathNode-Ipv6.IpAddressOrigin = 0;
+ DPathNode-Ipv6.PrefixLength= IP6_PREFIX_LENGTH;
+ ZeroMem (DPathNode-Ipv6.GatewayIpAddress, sizeof
(EFI_IPv6_ADDRESS));
+}
+else if (PathLen == IPv6_NODE_LEN_OLD_VERSIONS) {
+
+ //
+ // StaticIPAddress is a field in old versions of IPv6_DEVICE_PATH,
while ignored in new
+ // version. Set StaticIPAddress through its' offset in old
IPv6_DEVICE_PATH.
+ //
+ *((UINT8 *)(DPathNode-Ipv6) + IPv6_OLD_IPADDRESS_OFFSET) =
+(BOOLEAN)
(!Session-ConfigData-SessionConfigData.InitiatorInfoFromDhcp);
+}
+
break;
}
}
DPathNode = (EFI_DEV_PATH *)
Re: [edk2] [PATCH 2/2] SecurityPkg AuthVariableLib: Correct address pointers data
Reviewed by: Yao, Jiewen jiewen@intel.com
-Original Message-
From: Zeng, Star
Sent: Tuesday, July 21, 2015 5:02 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen
Subject: [PATCH 2/2] SecurityPkg AuthVariableLib: Correct address pointers data
Originally, the double pointer (VOID **) is not correct for convert address
pointers, and also some address pointers were missing.
Cc: Jiewen Yao jiewen@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
index 02df309..d102219 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
@@ -101,7 +101,7 @@ VARIABLE_ENTRY_PROPERTY mAuthVarEntry[] = {
},
};
-VOID *mAddressPointer[3];
+VOID **mAuthVarAddressPointer[10];
AUTH_VAR_LIB_CONTEXT_IN *mAuthVarLibContextIn = NULL;
@@ -406,11 +406,18 @@ AuthVariableLibInitialize (
AuthVarLibContextOut-StructSize = sizeof (AUTH_VAR_LIB_CONTEXT_OUT);
AuthVarLibContextOut-AuthVarEntry = mAuthVarEntry;
AuthVarLibContextOut-AuthVarEntryCount = sizeof (mAuthVarEntry) / sizeof
(mAuthVarEntry[0]);
- mAddressPointer[0] = mHashCtx;
- mAddressPointer[1] = mPubKeyStore;
- mAddressPointer[2] = mCertDbStore;
- AuthVarLibContextOut-AddressPointer = mAddressPointer;
- AuthVarLibContextOut-AddressPointerCount = sizeof (mAddressPointer) /
sizeof (mAddressPointer[0]);
+ mAuthVarAddressPointer[0] = mPubKeyStore; mAuthVarAddressPointer[1]
+ = mCertDbStore; mAuthVarAddressPointer[2] = mHashCtx;
+ mAuthVarAddressPointer[3] = mAuthVarLibContextIn;
+ mAuthVarAddressPointer[4] = (VOID **)
+ (mAuthVarLibContextIn-FindVariable),
+ mAuthVarAddressPointer[5] = (VOID **)
+ (mAuthVarLibContextIn-FindNextVariable),
+ mAuthVarAddressPointer[6] = (VOID **)
+ (mAuthVarLibContextIn-UpdateVariable),
+ mAuthVarAddressPointer[7] = (VOID **)
+ (mAuthVarLibContextIn-GetScratchBuffer),
+ mAuthVarAddressPointer[8] = (VOID **)
+ (mAuthVarLibContextIn-CheckRemainingSpaceForConsistency),
+ mAuthVarAddressPointer[9] = (VOID **)
+ (mAuthVarLibContextIn-AtRuntime),
+ AuthVarLibContextOut-AddressPointer = mAuthVarAddressPointer;
+ AuthVarLibContextOut-AddressPointerCount = sizeof
+ (mAuthVarAddressPointer) / sizeof (mAuthVarAddressPointer[0]);
return Status;
}
--
1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Simple text protocol- Help
In case you are using events for registering your callback. make sure your
TPL levels are at correct levels.
pBS-CreateEvent(
EVT_NOTIFY_WAIT,
TPL_NOTIFY,
YOUR_FUNCTION
Context,
WaitForKey);
VOID
YOUR_FUNCTION(
EFI_EVENT Event,
VOID*Context )
{
// process event
.
pBS-SignalEvent(Event);
}
On Tue, Jul 21, 2015 at 5:52 PM, Saiprasad Chavali s...@marvell.com wrote:
Hi Andrew,
I do install the device path protocol. What I am trying is, to install the
Text Protocol Interface at later stage rather during Start routine.
The Question I have is WaitForKey is triggered when I call during start
routine, not at a later stage. So wondering all has to be initialized
inside the start routine.
Thanks
Sai
-Original Message-
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, July 21, 2015 5:43 PM
To: Saiprasad Chavali
Cc: edk2-de...@ml01.01.org
Subject: Re: [edk2] Simple text protocol- Help
On Jul 21, 2015, at 5:28 PM, Saiprasad Chavali s...@marvell.com wrote:
Hi,
I am facing an issue while installing the Simple text protocol (or)
Simple text ex protocol outside the DriverBindingStart routine? The API
InstallMultipleProtocolInterfaces succeeds but there is no call to the
WaitForKey Event routine.
Did you install a device path protocol on the handle? Did you update the
BDS to list that device path as an active console?
Any idea what could be the cause? (Or) it is mandatory we have to
install all the protocols in the driver start routine.
In general it is better to use the EFI Driver Binding protocol so that you
only have to connect the devices involved in booting. Also if your down
stream hardware device is following the driver binding module, you have to
follow it. Thus most things PC are children of the PCI bus driver.
Thanks,
Andrew Fish
Thanks
Sai
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
--
Thanks
Neeraj
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/7] MdePkg: Add missing PCD usage information in UNI files.
Reviewed-by: Liming Gao liming@intel.com
-Original Message-
From: Qiu, Shumin
Sent: Tuesday, July 21, 2015 8:50 PM
To: edk2-devel@lists.01.org
Cc: Qiu, Shumin; Gao, Liming
Subject: [PATCH 1/7] MdePkg: Add missing PCD usage information in UNI files.
Cc: Liming Gao liming@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin shumin@intel.com
---
MdePkg/MdePkg.uni | Bin 66564 - 69572 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
diff --git a/MdePkg/MdePkg.uni b/MdePkg/MdePkg.uni index
893e62c2663a6385e62920d51f24aa11b1758a8e..431226c1e8555cd9074ba5a6ad96d56c50f5c8e3
100644 GIT binary patch delta 1372
zcmb7EO=}ZT6unAlVi8eDlq`goh^Qd;L)^F#l@#HtFbGUcG5}Gkt7Y1M5~)9xDa=G
ze}GHTRc)*2sxEZzKXBo~bysdZ=em38tWHB$b0wQch0%z-kHZwQlDO=9YYQrF8AX
zoHn;I`DqEHE)}^Vo;1a`siFgdV9U3d*5aC9arKS(b4g;qFnWQWq0Gg6dMEQ0*
z*4D@$aSHl$WAb@=WFf#c1At{f7-0}0BHy7vUH`2htS4~XiCjy8bnuY^tVzWrZ*?
zx_#%Ze!027RFvIv=LUQ%unDe{atds1gl8ZAl$?;0hU%zgi(8bA2E=y9THl64
z`%1@YVF(NF+5d`6VHaBM*MYEPSHAXEFHFTJMrLt#7r#2#r~8!-BN5`AUCwugL7;+
zGe%C{7;xyD0~0fGjnLk9Bmj_WYs8|b}k7y8@Uu$Djfa6?AcGWL!?`!slGg
zMWpXCRXfn8yPJ;?il^w}(~NG8n{(^(#Lsc24fp;zn@$)%x##crhPwm`cmthn
zfa59{Iy!OqT)Kav*WTySZFHX_jQfSZ-dAtztggMzXtkE@aU$4HzA({5vyOPSt6bn
z9nFHliZ2?w%vfNv%fNA(=^N*X@xa#NrYlCIX94C7@$*O^kZ-ShD6Zazb7j+L4irTa
zjzXiBJ*PvT9k{pootyiew-roQR7HXEFc7!!n#DD?np`!-e5xvayD3jgNe?QSW`k
zsns0BMOR8fwl024_1u?ZH|eW*d)yOw1|YcmFMWt6ziW--7l`h+I5k)x|FwDC(Sj;
Ij-ZUnPcTFvX#fBK
delta 11
ScmXypQWXPrC|#r3kv`oAOp1k
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Simple text protocol- Help
On Jul 21, 2015, at 6:59 PM, Saiprasad Chavali s...@marvell.com wrote:
Comments Inline
From: Andrew Fish [mailto:af...@apple.com mailto:af...@apple.com]
Sent: Tuesday, July 21, 2015 6:49 PM
To: Saiprasad Chavali
Cc: edk2-de...@ml01.01.org mailto:edk2-de...@ml01.01.org
Subject: Re: [edk2] Simple text protocol- Help
On Jul 21, 2015, at 6:29 PM, Saiprasad Chavali s...@marvell.com
mailto:s...@marvell.com wrote:
Thanks Andrew, sorry to say this I am not confused, as well understood the
role of events.
(OR) I am not properly communicating,.
1) Installing the driver as a standalone, not attached to any device.
What is the difference between installing the driver and Load the driver? We
don’t install drivers, we load drivers. We install protocols.
[SAI] Yes it is Load:
load “XX_DXE.efi”
2) Installed the app protocol interface for an app to call the custom
routines defined
You are talking about standard routines, this is the 1s mention of custom
stuff so it just makes things more confusing.
[SAI] Custom Routines inside the Dxe driver, not the standard EFI call.
3) Load the driver.
What driver?
[SAI] Same driver as in point 1).
Ø load “XX_DXE.efi”
4) Initiate the app to call the custom routines for example: start,
connect, stop etc..
No one EVER calls Start()/Stop() directly. The code calls gBS-
ConnectConrtoller() or gBS-DIsconnectController()? What is this code doing?
[SAI] Custom Routines inside the Dxe driver, not the standard EFI call.
“XX_start”., “ XX_Connect” etc …
Test Application calls these routines, after loading the driver.
5) If I Install the “Simple Text” inside a routine say “connect”, I
don’t see the event (“WaitForKey”) or not breakpoint inside the associated
event routine irrespective of whether you hit the key or not.
What is a connect routine? That is not part of the EFI driver model?
[SAI] The routine is NOT part of the standard API. It is a custom routine I
defined for the test application to call.
6) Instead If I Install the “Simple Text” from the Driver start routine,
as soon as I load the driver,
I forgot to mention that hot plug devices are different. Is this a USB
device? If so then you need to gBS-ConnectController() to have the console
splitter driver bind on the device.
[SAI] yes it is a hot plug device, USB.
7) I hit the breakpoint inside the “WaitForKey” event routine. Doesn’t
have to press any key.
That is how WaitForKey works? WaitForKey is the event that gets signaled when
a key is pressed. As I corrected in the other mail you only signal the event
when a key is pressed. Thus it is your code that signals the event.
I am trying to understand the behavior and accordingly change my design. I
hope I am clear. If the behavior has to be consistent, there should not be
any variations between point 5 6, will investigate.
[SAI] Is a USB device.
If this is a USB device you have to follow the EFI driver model to make it
work.
Yea so you should just follow the EFI driver model and it will work. If you
make up your own driver model things like xx_start() xx_connect() lots of stuff
is going to break, as you found out the hard way.
FYI if you are a USB Device this code can get you added in without the
variables. For example this make the hot plug of a USB keyboard work:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatform.c
/**
Check if the device supports hot-plug through its device path.
This function could be updated to check more types of Hot Plug devices.
Currently, it checks USB and PCCard device.
@param DevicePathPointer to device's device path.
@retval TRUE The devcie is a hot-plug device
@retval FALSE The devcie is not a hot-plug device.
**/
BOOLEAN
IsHotPlugDevice (
IN EFI_DEVICE_PATH_PROTOCOL*DevicePath
)
{
EFI_DEVICE_PATH_PROTOCOL *CheckDevicePath;
CheckDevicePath = DevicePath;
while (!IsDevicePathEnd (CheckDevicePath)) {
//
// Check device whether is hot plug device or not throught Device Path
//
if ((DevicePathType (CheckDevicePath) == MESSAGING_DEVICE_PATH)
(DevicePathSubType (CheckDevicePath) == MSG_USB_DP ||
DevicePathSubType (CheckDevicePath) == MSG_USB_CLASS_DP ||
DevicePathSubType (CheckDevicePath) == MSG_USB_WWID_DP)) {
//
// If Device is USB device
//
return TRUE;
}
if ((DevicePathType (CheckDevicePath) == HARDWARE_DEVICE_PATH)
(DevicePathSubType (CheckDevicePath) == HW_PCCARD_DP)) {
//
// If Device is PCCard
//
return TRUE;
}
CheckDevicePath = NextDevicePathNode (CheckDevicePath);
}
return FALSE;
}
Thanks,
Andrew Fish
Thanks
Sai
From: Andrew Fish
Re: [edk2] [PATCH v2 3/6] MdeModulePkg: SmbiosDxe: ARM and AARCH64 are VALID_ARCHITECTURES
Reviewed-by: Feng Tian feng.t...@intel.com -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Tuesday, July 21, 2015 7:10 PM To: edk2-de...@ml01.01.org Cc: Tian, Feng; Elvin Li; Zeng, Star Subject: [edk2] [PATCH v2 3/6] MdeModulePkg: SmbiosDxe: ARM and AARCH64 are VALID_ARCHITECTURES This driver is soon going to be built by ArmVirtPkg/ArmVirtQemu.dsc (without any changes). Although VALID_ARCHITECTURES is not used by the build system (it is just a comment), it is best kept up-to-date for human readers' sake. Cc: Feng Tian feng.t...@intel.com Cc: Elvin Li elvin...@intel.com Cc: Star Zeng star.z...@intel.com Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek ler...@redhat.com Reviewed-by: Star Zeng star.z...@intel.com Reviewed-by: Feng Tian feng.t...@intel.com --- MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf b/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf index cabc9d7..4fd6b97 100644 --- a/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf +++ b/MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf @@ -26,7 +26,7 @@ [Defines] # # The following information is for reference only and not required by the build tools. # -# VALID_ARCHITECTURES = IA32 X64 IPF EBC +# VALID_ARCHITECTURES = IA32 X64 IPF EBC ARM AARCH64 # [Sources] -- 1.8.3.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] SecurityPkg AuthVariableLib: Correct address pointers data
Good comments and sure to add (VOID **) cast. Thanks for your Tested-by.
Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, July 21, 2015 8:39 PM
To: Zeng, Star; edk2-de...@ml01.01.org
Cc: Yao, Jiewen; Alex Williamson
Subject: Re: [edk2] [PATCH 2/2] SecurityPkg AuthVariableLib: Correct address
pointers data
Indeed, this bug breaks the installation of Windows 8.1 guests on top of OVMF.
(The installer crashes while copying files.)
Alex (Cc'd) reported this to me in private. I bisected the issue to the
variable driver unification patches, and then found this new series on the list.
One comment below:
On 07/21/15 11:01, Star Zeng wrote:
Originally, the double pointer (VOID **) is not correct for convert
address pointers, and also some address pointers were missing.
Cc: Jiewen Yao jiewen@intel.com
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng star.z...@intel.com
---
SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c | 19
+--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
index 02df309..d102219 100644
--- a/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
+++ b/SecurityPkg/Library/AuthVariableLib/AuthVariableLib.c
@@ -101,7 +101,7 @@ VARIABLE_ENTRY_PROPERTY mAuthVarEntry[] = {
},
};
-VOID *mAddressPointer[3];
+VOID **mAuthVarAddressPointer[10];
AUTH_VAR_LIB_CONTEXT_IN *mAuthVarLibContextIn = NULL;
@@ -406,11 +406,18 @@ AuthVariableLibInitialize (
AuthVarLibContextOut-StructSize = sizeof (AUTH_VAR_LIB_CONTEXT_OUT);
AuthVarLibContextOut-AuthVarEntry = mAuthVarEntry;
AuthVarLibContextOut-AuthVarEntryCount = sizeof (mAuthVarEntry) /
sizeof (mAuthVarEntry[0]);
- mAddressPointer[0] = mHashCtx;
- mAddressPointer[1] = mPubKeyStore;
- mAddressPointer[2] = mCertDbStore;
- AuthVarLibContextOut-AddressPointer = mAddressPointer;
- AuthVarLibContextOut-AddressPointerCount = sizeof
(mAddressPointer) / sizeof (mAddressPointer[0]);
+ mAuthVarAddressPointer[0] = mPubKeyStore;
+ mAuthVarAddressPointer[1] = mCertDbStore;
+ mAuthVarAddressPointer[2] = mHashCtx; mAuthVarAddressPointer[3] =
+ mAuthVarLibContextIn;
Please cast all of these to (VOID **), same as below; otherwise gcc complains
with:
assignment from incompatible pointer type
If you fix that up, you can add my:
Tested-by: Laszlo Ersek ler...@redhat.com
to both patches in this series.
Thanks
Laszlo
+ mAuthVarAddressPointer[4] = (VOID **)
+ (mAuthVarLibContextIn-FindVariable),
+ mAuthVarAddressPointer[5] = (VOID **)
+ (mAuthVarLibContextIn-FindNextVariable),
+ mAuthVarAddressPointer[6] = (VOID **)
+ (mAuthVarLibContextIn-UpdateVariable),
+ mAuthVarAddressPointer[7] = (VOID **)
+ (mAuthVarLibContextIn-GetScratchBuffer),
+ mAuthVarAddressPointer[8] = (VOID **)
+ (mAuthVarLibContextIn-CheckRemainingSpaceForConsistency),
+ mAuthVarAddressPointer[9] = (VOID **)
+ (mAuthVarLibContextIn-AtRuntime),
+ AuthVarLibContextOut-AddressPointer = mAuthVarAddressPointer;
+ AuthVarLibContextOut-AddressPointerCount = sizeof
+ (mAuthVarAddressPointer) / sizeof (mAuthVarAddressPointer[0]);
return Status;
}
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 3/7] IntelFrameworkModulePkg: Add missing PCD usage information in UNI and DEC files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin shumin@intel.com
Signed-off-by: Jeff Fan jeff@intel.com
---
IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec | 4
IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni | Bin 33748 - 37454 bytes
2 files changed, 4 insertions(+)
diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
index 19a5790..66310e6 100644
--- a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
+++ b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
@@ -231,11 +231,15 @@
# The value should be a multiple of 4KB.
# The range should be below the EBDA reserved range from
# (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
CONVENTIONAL_MEMORY_TOP.
+ # @Prompt Reserved Memory Base Address for OPROM
+ # @Expression 0x8001 |
(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemoryBase =
0x2) AND
((gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemoryBase
0x1000) == 0)
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemoryBase|0x6|UINT32|0x300c
## Specify memory size with bytes for OPROM to find free memory.
# The value should be a multiple of 4KB. And the range should be below the
EBDA reserved range from
# (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
CONVENTIONAL_MEMORY_TOP.
+ # @Prompt Reserved Memory Size for OPROM
+ # @Expression 0x8001 |
(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemorySize
0x8) AND
((gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemorySize
0x1000) == 0)
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemorySize|0x28000|UINT32|0x300d
## Specify memory size with page number for a pre-allocated reserved memory
to be used
diff --git a/IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni
b/IntelFrameworkModulePkg/IntelFrameworkModulePkg.uni
index
8c70b7a0733e529eee3d6275a6a10065a9d5be10..5331cedfd2816ae1840e4aefab2c98bfec712787
100644
GIT binary patch
delta 968
zcmd5)%`Ssc5IrR#S}74FjgXHG5dOWrBG!-v=thOkVsJ_Q9o6oHpQlEnLQgz658K
z1K98+p1_$~TEYe!x%uv$``t6=%$?~vFh=%gL?x2;EcLZ{;PW$WVDK^EJ{$hE({
zb`(kMAtjxjkX#KmxuQrR!`CeGvfyc#2fL}d3r@MM+y9(dV=~33QElGa4buq#jEH6
z3pwUnSi=Ukuxg?#SyPNM6?WKIa?K#G(Ht(wH||rV;VDvBg(2QW-HSc_Z-iCt(50D
zMlpskBdyb7MwIJaH;GNIZLF}f+!s}?tCY3DSJfb^o6t0eU*}0wfH?lkTgx?uueo?
zPFxD47$VGo(iSRj7_yuyDjbYOe|zn;H3VhyeG}`p~$X4o}sTZDds4U2h6s;A{_
z*xR;DK5gfKJf#}S2FPx}9)*tRZ%Q6hI$a8nK8`Kv=|bYFt;$Kutdwo`Ne7XJZ}j`
z)8y!fC6WH%P_NO`K7PhvGXR`mYbn~4w$?Qw#dER{OwQ`=C$O?GUM#UW;Q8oGC{
N{(+YxfASJeyaM!g$KC({
delta 16
YcmX@Ngy~8(}sDBj3%4sGnzI506cXDU;qFB
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
