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
---
SecurityPkg/Tcg/Opal/OpalPasswordDx
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 a/SecurityPkg/Tcg/Opal/OpalPasswordSmm/OpalPasswordSmm.inf
b/SecurityPkg/Tcg/Opal/OpalP
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 TcgStorageOpalLib:
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
Cc: Feng Tian
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 Dong
Hi, Jiaxin
We assume the Uri should never be NULL pointer returned from the HII interface,
so the ASSERT is to help to catch the exception case in DEBUG build, for
example, possible HII interface change.
In release build the ASSERT will be removed so the if condition will return an
error.
Siyu
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 before use.
>
> Cc: Ye Ting
> Cc: Wu Jiaxin
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)
• AtRateTime
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 a/NetworkPkg/HttpBootDxe/HttpBootConfig.c
b/NetworkPkg/HttpBootDxe/HttpBootConfig.c
index
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 c
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 Contribution Agreement 1.0
Signed-off-by:
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
Cc: Ye, Ting; Wu, J
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
> Subject: [Patch 0/2] Check received packet size before use it
>
> Arbitrary
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 description for
PcdUartD
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 100644
--- a/MdePkg/MdePkg.uni
+++ b/MdePkg/
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
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
>
> Subject: Re: [edk2] [patch V3] MdeModulePkg: Fix Me
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: F
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 provi
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, Patrick
Cc: David Van Arnem
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 anothe
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 b
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.
What
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: https://github.com/jljusten/edk2.git
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 h
On 03/31/16 17:10, Zeng, Star wrote:
> On 2016/3/31 19:47, Laszlo Ersek wrote:
>> Therefore, if this subsystem in edk2 is being reworked, my preference
>> would be the following:
>>
>> (1) Please fix the DepEx bug in BootScriptExecutorDxe first, if
>> possible. Instead, BootScriptExecutorDxe shoul
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 contro
Thanks Ray. We will address the feedback and resubmit a new patch.
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ruiyu
Sent: Wednesday, March 30, 2016 7:39 PM
To: El-Haj-Mahmoud, Samer ; Palmer, Thomas
; edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star
Subject: Re
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 //
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 wrote:
From: Leendert van Doorn
Contributed-under: TianoCore Contribution Agreement 1.
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
Subject: Re: [edk2] [Patch v2 2/3] MdeModu
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
Subject: [edk2] [Patch v3 1/3] MdeModulePkg/Bds:
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 share it via email.
>
I
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
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Leo Duran
>>
>> Looking in more det
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
>
> Looking in more detail at this patch, I am a bit puzzled so please see below
>
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 Conf/tools_def.txt to BaseTools/Conf/tools_def.t
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 below
> ---
> MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
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, 2016 5:42 PM
To: edk2-devel@lists.01.org
Subject: Re: [edk
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 pr
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:
RcvString
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
>>>
>>> ArmVirtPkg/ArmVirtQemu: gate FDT config table instal
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=&NAME=&PATH=> hex number>&=&=&...&=
>>
>> In a nutshell, I think iPXE should:
>> - reflect the GUID / NAME / PATH triplet from the input to the output
>>
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 have a EFI System disk, under QEMU, that has the
\Efi\StdLib
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: Ard
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] MdeModulePkg: Check recei
On 31/03/16 11:13, Laszlo Ersek wrote:
Which translates to the following response string:
GUID=&NAME=&PATH=&=&=&...&=
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
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, that is for old properti
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 03/31/16 13:20, Ard Bieshe
> -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, Mi
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 写道：
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
>> recommended.
>> A new
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 introduces the .DSC define 'P
(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 introduces the .DSC define 'PURE_ACPI_BOOT_ENABLE', defaulting to
> FALSE, which control
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 was added and
>> Mde
(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 FD
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
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) Wh
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 th
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
Signed-of
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 configur
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 tabl
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
>>
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 off of a RAM disk is not supported by
>> IntelFra
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 issue. This properties table is collected at
>> EndO
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 installed from the shell as we
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 you please send me more
Correct typo. meat->meet
I just thought one possible issue. This properties table is collected at
EndOfDxe.
If there is any RT data allocate after that event, they will not be included.
Would you please check where these 2 RT_data regions are allocated?
> -Original Message-
> From: Y
BTW: I found below 2 entries are missing in properties table.
[0.00] 0xf5a1-0xf5a7 [Runtime Data |RUN| | |
| | | | |WB|WT|WC|UC]*
[0.00] 0xf5b7-0xf5b7 [Runtime Data |RUN| | |
| | | | |WB|WT|WC|UC]*
Is that the probl
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 d
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: Thursday
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 RTCode.
>
> This patch fixe
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: [e
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 the DHCP
> server, which is
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 t
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 it from the Shell?
>
> Curre
MdeModulePkg/IntelFrameworkModulePkg reviewed by: jiewen@intel.com
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Star Zeng
> Sent: Thursday, March 31, 2016 11:02 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Yao, Jiewen
> Subje
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 bel
77 matches
Mail list logo
