[edk2] [Patch 3/4] SecurityPkg OpalPasswordDxe: Enhance code to make it more safely.

Patched fixed some small issue for this library: 1. Remove the hard code debug build option in inf. 2. Check the pointer before use it to make code more safely. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Cc: Feng Tian

[edk2] [Patch 4/4] SecurityPkg TcgStorageOpalLib: Remove the hard code debug build option.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong Cc: Feng Tian --- SecurityPkg/Tcg/Opal/OpalPasswordSmm/OpalPasswordSmm.inf | 3 --- 1 file changed, 3 deletions(-) diff --git

[edk2] [Patch 0/4] Enhance the code of Opal Password solution.

Do the misc update for the code. Eric Dong (4): SecurityPkg OpalPasswordSupportLib: Fixed GCC build failure and misc changes. SecurityPkg TcgStorageOpalLib: Fixed GCC and EBC build failure. SecurityPkg OpalPasswordDxe: Enhance code to make it more safely. SecurityPkg

[edk2] [Patch 1/4] SecurityPkg OpalPasswordSupportLib: Fixed GCC build failure and misc changes.

Patched fixed some small issue for this library: 1. Remove the hard code debug build option in inf. 2. Add comments for the used protocol in inf. 3. Fixed Gcc build error in the OpalPasswordSupportLib.c Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong

[edk2] [Patch 2/4] SecurityPkg TcgStorageOpalLib: Fixed GCC and EBC build failure.

Patched fixed some small issue for this library: 1. Remove the hard code debug build option in inf. 2. Fixed EBC arch build error in the TcgStorageOpalUtil.c 3. Fixed Gcc build error caused by writing error file name. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric

Re: [edk2] [Patch] NetworkPkg: Check pointer for NULL before use.

ASSERT should be removed since it will checked later. > -Original Message- > From: Fu, Siyuan > Sent: Friday, April 1, 2016 1:16 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Wu, Jiaxin > Subject: [Patch] NetworkPkg: Check pointer for NULL

[edk2] Smart Battery Info

Hello All, Am trying to Retrieve the below values for laptop battery, Any pointers would be helpful For Smart Battery: • ManufacturerAccess() (0x00) • RemainingCapacityAlarm() (0x01) • RemainingTimeAlarm() (0x02) • BatteryMode() (0x03) • AtRate() (0x04) • AtRateTimeToFull() (0x05) •

[edk2] [Patch] NetworkPkg: Check pointer for NULL before use.

Cc: Ye Ting Cc: Wu Jiaxin Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan --- NetworkPkg/HttpBootDxe/HttpBootConfig.c | 4 1 file changed, 4 insertions(+) diff --git

[edk2] [Patch] UefiCpuPkg/CpuMpPei: Fix potential AP mwait wakeup issue

If ApLoopMode is set to ApInMwaitLoop, AP will be placed into C-State by mwait instruction. BSP will wakeup AP by write start-up signal in monitor address. However, AP maybe waken by SMI/NMI/MCE and other condition. On this case, AP will check if BSP wants to wakeup itself really. If not, AP will

[edk2] [Patch] SourceLevelDebugPkg/SmmDebugAgent: mMailboxPointer is used before set

mMailboxPointer is used before it is initialization. This issue only happens when SmmDebugAgent is initialized without PeiDebugAgent or DxeDebugAgent initialization. The fix is to use Mailbox instead. Cc: Ruiyu Ni Cc: Hao Wu Contributed-under: TianoCore

Re: [edk2] [Patch 2/2] NetworkPkg: Check received packet size before use it.

Thanks Siyuan. With this change, looks ok. Reviewed-by: Sriram Subramanian Thanks, Sriram. -Original Message- From: Fu, Siyuan [mailto:siyuan...@intel.com] Sent: Friday, April 1, 2016 6:20 AM To: Subramanian, Sriram (EG Servers Platform SW); edk2-devel@lists.01.org

Re: [edk2] [Patch 0/2] Check received packet size before use it

It's good to me. Series reviewed-by: Jiaxin Wu > -Original Message- > From: Fu, Siyuan > Sent: Monday, March 28, 2016 11:16 AM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Wu, Jiaxin ; > Subramanian Sriram

Re: [edk2] [Patch] MdePkg/MdePkg.uni: Add description for PcdUartDefaultReceiveFifoDepth

Reviewed-by: Qiu Shumin -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Friday, April 01, 2016 11:23 AM To: edk2-devel@lists.01.org Cc: Ni, Ruiyu; Qiu, Shumin Subject: [edk2] [Patch] MdePkg/MdePkg.uni: Add

[edk2] [Patch] MdePkg/MdePkg.uni: Add description for PcdUartDefaultReceiveFifoDepth

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Shumin Qiu --- MdePkg/MdePkg.uni | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/MdePkg/MdePkg.uni b/MdePkg/MdePkg.uni index 6c9ddad..a110e45

Re: [edk2] [Patch v2] Revert "TerminalDxe: select the UART's default receive FIFO depth"

On 2016/3/31 8:48, Ruiyu Ni wrote: This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413. Changing the receive FIFO depth in Terminal driver Start() is not recommended. A new PCD PcdUartDefaultReceiveFifoDepth was added and MdeModulePkg/SerialDxe driver uses the PCD as the default receive

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

Glad to know BIOS is good. :-) Thank you Yao Jiewen > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, April 1, 2016 12:08 AM > To: Yao, Jiewen > Cc: Gao, Liming ; edk2-devel@lists.01.org >

Re: [edk2] [Patch 2/2] NetworkPkg: Check received packet size before use it.

Sriram, You are right, I missed this case. Will correct it when commit the patch, thanks. Siyuan > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Subramanian, Sriram (EG Servers Platform SW) > Sent: Thursday, March 31, 2016 10:55 PM > To:

Re: [edk2] [Patch] NetworkPkg: Add RAM disk boot support to HTTP Boot driver.

Hi, Samer Does the "Provisional Standard Media Type Registry" means the type has been finalized by IANA? I see the web has below declaration, says its " for development and test purposes only". That's why I temporarily put it in the HTTP boot driver. Note This registry, unlike some other

Re: [edk2] Building the ShellPkg

Ard, I thought of that, but was a bit nervous about symlinking stuff here. But it is a good suggestion and I will do this to avoid future issues. Patrick From: Ard Biesheuvel Sent: Thursday, March 31, 2016 8:47 AM To: Mahan,

Re: [edk2] Recommend platforms for doing Intel UEFI driver development

Laszlo, What is FLR, I must admit my ignorance to that acronym. I'm not fully up on using a VM as s development environment. Does the NIC need to have it's linux driver loaded on the linux hypervisor? Or can the VM access the PCIe directly? Can VirtualBox be used (I already have it for

Re: [edk2] Recommend platforms for doing Intel UEFI driver development

On 03/31/16 20:52, Mahan, Patrick wrote: > I believe I have seen this mentioned here before, but I cannot find the > answer via google or gmane. But > there was a developer package that consisted of an Intel motherboard and > software that allowed you to > do UEFI Driver development. Not sure

[edk2] Recommend platforms for doing Intel UEFI driver development

I believe I have seen this mentioned here before, but I cannot find the answer via google or gmane. But there was a developer package that consisted of an Intel motherboard and software that allowed you to do UEFI Driver development. Not sure but I seem to recall it was some third-party.

Re: [edk2] [PATCH 00/62] Add FatPkg with 2-clause BSD license

On 03/30/16 03:10, Jordan Justen wrote: > I don't think sending all 62 patches will be useful (but, I can easily > send them out if requested). Instead, the patches are available at: > > web: https://github.com/jljusten/edk2/tree/fatpkg-open-source-v1 > > git:

Re: [edk2] EDK2 Python issue with QEMU

On 03/31/16 16:09, Daryl McDaniel wrote: > OK. Let’s see how much, if any, of Python might be working. > > Try: > > python –h > python –V > python –E –S –c print “It’s alive.” > > If those three commands work, next try: > > python –E –S > > Sorry, but I have to ask this: > > Do you

Re: [edk2] [PATCH] MdeModulePkg: support AHCI controller using PCI emulation

Part of the answers below... > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, March 31, 2016 11:25 AM > To: Duran, Leo; Tian, Feng > Cc: edk2-devel-01; Leif Lindholm; Leendert van Doorn > Subject: Re: [PATCH] MdeModulePkg: support AHCI

Re: [edk2] [Patch] NetworkPkg: Add RAM disk boot support to HTTP Boot driver.

Since this is industry standard, it should be moved to MdePkg/IndustryStandard/Http11.h, next to the similarly defined content types, like HTTP_CONTENT_TYPE_APP_JSON, HTTP_CONTENT_TYPE_APP_OCTET_STREAM, HTTP_CONTENT_TYPE_IMAGE_JPEG, etc... // +// Provisional Standard Media Types defined in //

Re: [edk2] [PATCH] MdeModulePkg: support AHCI controller using PCI emulation

On 31 March 2016 at 17:58, Ard Biesheuvel wrote: > On 31 March 2016 at 17:56, Ard Biesheuvel wrote: >> On 31 March 2016 at 17:45, Ard Biesheuvel wrote: >>> On 24 March 2016 at 21:30, Leo Duran

Re: [edk2] [Patch v2 2/3] MdeModulePkg/Bds: Free resources after ram disk boot finishes

Looks good... Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu, Siyuan Sent: Wednesday, March 30, 2016 9:32 PM To: Ni, Ruiyu ; edk2-devel@lists.01.org Cc: Tian, Feng

Re: [edk2] [Patch v3 1/3] MdeModulePkg/Bds: Allocate reserved memory for RAM Disk boot media

Looks good. Reviewed-by: Samer El-Haj-Mahmoud -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni Sent: Wednesday, March 30, 2016 9:37 PM To: edk2-devel@lists.01.org Cc: Ruiyu Ni ; Siyuan Fu

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 31 March 2016 at 16:09, Yao, Jiewen wrote: > Thanks for your quick response. > > Then I will be waiting for your investigation result. > > If you see the value to have this dump tool check in, maybe we can put to > MdeModulePkg/Application. > Next time, we do not need

Re: [edk2] [PATCH] MdeModulePkg: support AHCI controller using PCI emulation

On 31 March 2016 at 17:56, Ard Biesheuvel wrote: > On 31 March 2016 at 17:45, Ard Biesheuvel wrote: >> On 24 March 2016 at 21:30, Leo Duran wrote: >>> From: Leendert van Doorn >>> >>>

Re: [edk2] [PATCH] MdeModulePkg: support AHCI controller using PCI emulation

On 31 March 2016 at 17:45, Ard Biesheuvel wrote: > On 24 March 2016 at 21:30, Leo Duran wrote: >> From: Leendert van Doorn >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Leo Duran

Re: [edk2] Building the ShellPkg

On 31 March 2016 at 17:39, Mahan, Patrick wrote: > David, > > Thanks, that is exactly what was needed. > > (Writing that one down in my tips and tricks for UEFI) > Hi Patrick, If you are on Linux, the simplest way to work around this is to symlink

Re: [edk2] [PATCH] MdeModulePkg: support AHCI controller using PCI emulation

On 24 March 2016 at 21:30, Leo Duran wrote: > From: Leendert van Doorn > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Leo Duran Looking in more detail at this patch, I am a bit puzzled so please see

Re: [edk2] Building the ShellPkg

David, Thanks, that is exactly what was needed. (Writing that one down in my tips and tricks for UEFI) Thanks, Patrick From: edk2-devel on behalf of David Van Arnem Sent: Wednesday, March 30,

Re: [edk2] [PATCH 0/4] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

Laszlo, Try to solve your concern below. On 2016/3/31 19:47, Laszlo Ersek wrote: Star, On 03/31/16 05:01, Star Zeng wrote: The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg is to do ACPI S3 Context save. In fact, that is not really related to Intel framework ACPI S3

Re: [edk2] [Patch 2/2] NetworkPkg: Check received packet size before use it.

Hi Siyuan, For the below case: + + if (Packet->TotalSize < sizeof (DNS_HEADER)) { +goto ON_EXIT; + } We may also need to handle the case of TotalSize == sizeof (HEADER), which indicates the payload for these packets is 0. For example in the code that follows the above check:

Re: [edk2] [PATCH 2/2] ArmVirtPkg/ArmVirtQemu: allow firmware to be built in ACPI-only mode

On 31 March 2016 at 15:11, Laszlo Ersek wrote: > On 03/31/16 14:53, Ard Biesheuvel wrote: >> On 31 March 2016 at 14:48, Laszlo Ersek wrote: >>> (4) for the subject of this patch, I would prefer something less >>> sensational :), such as >>> >>>

Re: [edk2] HII incompatibility between edk2 and iPXE?

On 03/31/16 15:37, Michael Brown wrote: > On 31/03/16 11:13, Laszlo Ersek wrote: >> Which translates to the following response string: >> >> GUID===> hex number>&=&=&...&= >> >> In a nutshell, I think iPXE should: >> - reflect the GUID / NAME / PATH triplet from the input to the output >>

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

Thanks for your quick response. Then I will be waiting for your investigation result. If you see the value to have this dump tool check in, maybe we can put to MdeModulePkg/Application. Next time, we do not need share it via email. Thank you Yao Jiewen > -Original Message- > From:

Re: [edk2] [Patch 1/2] MdeModulePkg: Check received packet size before use it.

Looks good. Reviewed-by: Sriram Subramanian -Original Message- From: Fu Siyuan [mailto:siyuan...@intel.com] Sent: Monday, March 28, 2016 8:47 AM To: edk2-devel@lists.01.org Cc: Ye Ting; Wu Jiaxin; Subramanian, Sriram (EG Servers Platform SW) Subject: [Patch 1/2]

Re: [edk2] HII incompatibility between edk2 and iPXE?

On 31/03/16 11:13, Laszlo Ersek wrote: Which translates to the following response string: GUID===&=&=&...&= In a nutshell, I think iPXE should: - reflect the GUID / NAME / PATH triplet from the input to the output verbatim, - for each config knob requested, respond with =. (See also: "if a

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 31 March 2016 at 15:20, Yao, Jiewen wrote: > Hi Ard > Thanks for your log. Yes, it seems new issue, I have never encountered before. > > Here is what I found: > > 1) MemoryAttributeTable is always installed in ReadyToBoot event. (Sorry, I > gave wrong info on EndOfDxe,

Re: [edk2] [PATCH 2/2] ArmVirtPkg/ArmVirtQemu: allow firmware to be built in ACPI-only mode

On 03/31/16 14:53, Ard Biesheuvel wrote: > On 31 March 2016 at 14:48, Laszlo Ersek wrote: >> (4) for the subject of this patch, I would prefer something less >> sensational :), such as >> >> ArmVirtPkg/ArmVirtQemu: gate FDT config table install with build option >> >> On

Re: [edk2] HII incompatibility between edk2 and iPXE?

> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, March 31, 2016 6:14 PM > To: Michael Brown; Dong, Eric; Bi, Dandan > Cc: edk2-devel-01; Justen, Jordan L; Ard Biesheuvel > Subject: Re: HII incompatibility between edk2 and iPXE? > > On 03/31/16 06:43,

Re: [edk2] [Patch v2] Revert "TerminalDxe: select the UART's default receive FIFO depth"

On 03/31/16 15:00, Ni, Ruiyu wrote: > Can I take this as the approval of check in? Yes. All three of us (Ard, Ryan, and myself) are okay with this patch. Please make sure you pick up my Acked-by and Ryan's Tested-by. Thanks! Laszlo > > Thanks, > Ray > >> 在 2016年3月31日，下午8:30，Laszlo Ersek

Re: [edk2] [Patch v2] Revert "TerminalDxe: select the UART's default receive FIFO depth"

Can I take this as the approval of check in? Thanks, Ray > 在 2016年3月31日，下午8:30，Laszlo Ersek 写道： > >> On 03/31/16 02:48, Ruiyu Ni wrote: >> This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413. >> Changing the receive FIFO depth in Terminal driver Start() is not >>

Re: [edk2] [PATCH 2/2] ArmVirtPkg/ArmVirtQemu: allow firmware to be built in ACPI-only mode

On 31 March 2016 at 14:48, Laszlo Ersek wrote: > (4) for the subject of this patch, I would prefer something less > sensational :), such as > > ArmVirtPkg/ArmVirtQemu: gate FDT config table install with build option > > On 03/31/16 13:20, Ard Biesheuvel wrote: >> This

Re: [edk2] [Patch v2] Revert "TerminalDxe: select the UART's default receive FIFO depth"

On 31 March 2016 at 13:30, Laszlo Ersek wrote: > On 03/31/16 02:48, Ruiyu Ni wrote: >> This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413. >> Changing the receive FIFO depth in Terminal driver Start() is not >> recommended. >> A new PCD PcdUartDefaultReceiveFifoDepth

Re: [edk2] [PATCH 1/2] ArmVirtPkg/VirtFdtDxe: make installation of FDT as config table option

(1) please replace the word "option" with "optional" in the subject On 03/31/16 13:20, Ard Biesheuvel wrote: > The arm64 kernel is hardwired to prefer DT over ACPI, unless 'acpi=force' > is passed on the kernel command line. The only other way to force the > kernel to use ACPI is not to pass an

Re: [edk2] [Patch v2] Revert "TerminalDxe: select the UART's default receive FIFO depth"

On 03/31/16 02:48, Ruiyu Ni wrote: > This reverts commit 31ae446b1a039a55d0336f2201d77d1032533413. > Changing the receive FIFO depth in Terminal driver Start() is not > recommended. > A new PCD PcdUartDefaultReceiveFifoDepth was added and > MdeModulePkg/SerialDxe driver uses the PCD as the default

[edk2] Using multiple SNP drivers on Shell

Hi EDK2 experts, We are facing an issue when we enable two SNP (Simple Network) drivers in our EDK2 setup over a ARMv8 based SoC - NXP LS2080A. Here, I have two Ethernet interfaces - one is a MAC on SoC + Phy chip interface, while the other is a E1000 NIC card connected over a PCIe slot. A)

Re: [edk2] [PATCH 0/4] Move S3Ready() functional code from AcpiS3SaveDxe to S3SaveStateDxe

Star, On 03/31/16 05:01, Star Zeng wrote: > The S3Ready() functional code in AcpiS3SaveDxe of IntelFrameworkModulePkg > is to do ACPI S3 Context save. In fact, that is not really related to > Intel framework ACPI S3 protocol. > > IntelFrameworkModulePkg will be deprecated step by step, so move

[edk2] [PATCH 2/2] ArmVirtPkg/ArmVirtQemu: allow firmware to be built in ACPI-only mode

This introduces the .DSC define 'PURE_ACPI_BOOT_ENABLE', defaulting to FALSE, which controls the value of the feature PCD 'PcdPureAcpiBoot'. This allows a ArmVirtQemu image to be built that restricts the OS to booting in ACPI mode. Contributed-under: TianoCore Contribution Agreement 1.0

[edk2] [PATCH 1/2] ArmVirtPkg/VirtFdtDxe: make installation of FDT as config table option

The arm64 kernel is hardwired to prefer DT over ACPI, unless 'acpi=force' is passed on the kernel command line. The only other way to force the kernel to use ACPI is not to pass an FDT to it in the first place. So introduce a PCD that inhibits the installation of the QEMU supplied FDT as a

[edk2] [PATCH 0/2] ArmVirtPkg/ArmVirtQemu: add ACPI-only support

The default ArmVirtQemu build leaves it up to the OS whether it prefers DT over ACPI, since it always present both descriptions. This may not always be desirable, so allow ArmVirtQemu to be built in ACPI-only mode Ard Biesheuvel (2): ArmVirtPkg/VirtFdtDxe: make installation of FDT as config

Re: [edk2] HII incompatibility between edk2 and iPXE?

On 03/31/16 06:43, Michael Brown wrote: > On 31/03/16 02:17, Dong, Eric wrote: >>> Those sections of the UEFI spec are so badly written that I cannot begin >>> to guess what might count as either correct or incorrect. >>> >>> Could you please give a concrete example of what you think iPXE should

Re: [edk2] [PATCH v3] OvmfPkg: Add RAM disk support

On 03/31/16 00:28, Jordan Justen wrote: > Reviewed-by: Jordan Justen by me too: Reviewed-by: Laszlo Ersek Jordan, can you please commit this patch for Paulo? Thanks Laszlo > On 2016-03-30 14:49:37, Alcantara, Paulo wrote: >> Currently booting

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

Full log attached. I have confirmed that the issue also occurs on this DEBUG build On 31 March 2016 at 10:57, Ard Biesheuvel wrote: > On 31 March 2016 at 10:54, Yao, Jiewen wrote: >> Correct typo. meat->meet >> >> I just thought one possible

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 31 March 2016 at 10:54, Yao, Jiewen wrote: > Correct typo. meat->meet > > I just thought one possible issue. This properties table is collected at > EndOfDxe. > Hmm, perhaps that is too early then, since the implementation allows DXE_RUNTIME_DRIVER modules to be

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 31 March 2016 at 10:48, Yao, Jiewen wrote: > Hi Ard > I think you replied mail say this patch works fine at Wednesday, February 24, > 2016 4:15 PM. > > May I know if this is new issue or old issue? > This is a new issue. > > Also, in order to narrow down issue, would

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

Hi Ard I think you replied mail say this patch works fine at Wednesday, February 24, 2016 4:15 PM. May I know if this is new issue or old issue? Also, in order to narrow down issue, would you please send me more detail log? 1) Would you please enable VERBOSE for DxeCore and send a serial

Re: [edk2] 答复: [EDK2]an issue that PXE boot failed when received a NACK from the DHCP server

Hi, Xilong That’s really weird case, could you provide a capture file of the network traffic on the DHCP side, and also the network topology to help understand the problem? Best Regards Siyuan From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liuxilong (A) Sent:

Re: [edk2] [patch V3] MdeModulePkg: Fix Memory Attributes table type issue

On 23 February 2016 at 05:46, Jiewen Yao wrote: > According to the spec, each entry in the Memory > Attributes table shall have the same type as > the region it was carved out of in the UEFI memory map. > The current attribute uses RTData for PE Data, but > it should be

[edk2] 答复: [EDK2]an issue that PXE boot failed when received a NACK from the DHCP server

Hi Ard: I am sure of it. The offer and NAK is from the same DHCP server. Best regards Liu Xilong -邮件原件- 发件人: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 发送时间: 2016年3月31日 15:43 收件人: Liuxilong (A) 抄送: edk2-devel@lists.01.org; feng.t...@intel.com; star.z...@intel.com 主题: Re:

Re: [edk2] [EDK2]an issue that PXE boot failed when received a NACK from the DHCP server

On 31 March 2016 at 08:40, Liuxilong (A) wrote: > Hi Folks: > > Recently, we used our board to do some tests about PXE booting and > encountered an issue . Sometimes the PXE booting would fail when the PXE > client sent a request to confirm IP but received the NACK from

[edk2] [PATCH] ArmPlatformPkg/DS-5: fix 64-bit PE/COFF header parsing bug

The 64-bit version of the DS-5 debug script that retrieves the debug file path from the PE/COFF image in memory assumes that the PE/COFF header is packed, and that the debug directory entry in the optional header appears at a fixed offset into file. This is no longer true, now that we pad between

Re: [edk2] EDK2 Python

I am running it from the Shell. I have read about the STDERR issue but this doesnt seem to be the case - python just returns immediately, it doesn't hang. 2016-03-31 4:41 GMT+02:00 Daryl McDaniel : > Hello, > > > > When you try to run Python in QEMU, are you launching

Re: [edk2] [EDK2]an issue that PXE boot failed when received a NACK from the DHCP server

On 31/03/16 07:40, Liuxilong (A) wrote: Recently, we used our board to do some tests about PXE booting and encountered an issue . Sometimes the PXE booting would fail when*the PXE client sent a request to confirm IP but received the NACK from the DHCP server*, which is displayed in the figure

[edk2] [EDK2]an issue that PXE boot failed when received a NACK from the DHCP server

Hi Folks: Recently, we used our board to do some tests about PXE booting and encountered an issue . Sometimes the PXE booting would fail when the PXE client sent a request to confirm IP but received the NACK from the DHCP server, which is displayed in the figure below.