On Wed, Jun 22, 2016 at 02:34:19PM +0800, Gary Lin wrote:
> On Wed, Jun 22, 2016 at 12:49:03AM +0200, Laszlo Ersek wrote:
> > On 06/21/16 23:34, Laszlo Ersek wrote:
> >
> > > I believe that iPXE installs a HII formset that for some reason
> > > confuses this logic. I'll have to investigate more (e
On Wed, Jun 22, 2016 at 12:49:03AM +0200, Laszlo Ersek wrote:
> On 06/21/16 23:34, Laszlo Ersek wrote:
>
> > I believe that iPXE installs a HII formset that for some reason
> > confuses this logic. I'll have to investigate more (e.g., write some
> > debug code...) for a better understanding.
>
>
Jan,
I will help to add my RB and push the patch to git repo.
Thanks
Feng
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jan
Dabros
Sent: Tuesday, June 21, 2016 10:39 PM
To: Tian, Feng
Cc: ha...@marvell.com; edk2-devel@lists.01.org; leif.lindh
On 6/19/16 9:21 PM, Zeng, Star wrote:
1. The memory allocate and free in PiSmmCore are SMRAM that is not related to
UEFI memory map.
2. According to UEFI 2.6 spec page 222 below, the UEFI OS loader should have
got the memory map before ExitBootServices.
That means the memory free should not im
On 06/22/16 03:44, Laszlo Ersek wrote:
> I wrote an iPXE patch for this, but the issue persists. So it's
> something else.
I found the bug. Well, the first bug. It is so obscure that I'll have a
very hard time describing it.
The short version is that it is a buffer overflow in iPXE that confuses
Hi Ryan,
I can reproduce the issue on my real platform now, thank you for your
reporting. I will find the root cause and fix it. If have any process, I will
inform you.
Thanks again.
Jiaxin
> -Original Message-
> From: Wu, Jiaxin
> Sent: Wednesday, June 22, 2016 10:41 AM
> To: Ryan Hark
Laszlo:
I don't find any other case. I have integrated your patches into
https://github.com/lgao4/edk2.git branch nasm-v2. Please help check.
Thanks
Liming
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, June 21, 2016 10:37 AM
To: Gao, Liming ; Kinney, Michael D
; Justen, Jordan L
Reviewed-by: Liming Gao
> -Original Message-
> From: Qiu, Shumin
> Sent: Tuesday, June 21, 2016 4:21 PM
> To: edk2-devel@lists.01.org
> Cc: Qiu, Shumin ; Gao, Liming
> ; Ni, Ruiyu
> Subject: [PATCH] MdePkg: Fix 'cd ..\..' go up only 1 level.
>
> When we try to cd up two levels using the
Ryan,
> There could be a bug here, I suppose. Why is NetLibCreateServiceChild
> returning EFI_UNSUPPORTED? I guess I need to investigate this some more.
>
> Continuing, at this point Status is still EFI_UNSUPPORTED, so this is caught
> line 958 and we return from the function. That looks like
Initialize the variable that holds the return from SSL_do_handshake.
When the handshake function is not called it will be uninitialized.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer
---
CryptoPkg/Library/TlsLib/TlsLib.c | 1 +
1 file changed, 1 insertion(+
On 06/22/16 00:49, Laszlo Ersek wrote:
> Now compare it against the case when the iPXE oprom is enabled:
>
>> CreateDeviceManagerForm:
>> DevicePathStr=PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400938342,0x1)
>> FormSetGuid=ACF511E7-6578-C7A8-5C48-2B536DDC8B68 Index=9
>> CreateDeviceManagerForm:
>> Dev
On 06/21/16 23:34, Laszlo Ersek wrote:
> I believe that iPXE installs a HII formset that for some reason
> confuses this logic. I'll have to investigate more (e.g., write some
> debug code...) for a better understanding.
Yeah. I added the following DEBUG to the code:
> diff --git a/MdeModulePkg/
Reviewed-by: Michael Kinney
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Saturday, June 18, 2016 6:30 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
>
> Subject: [PATCH v2 2/4] MdePkg/DebugLib: Flag post-_ASSERT() as unrea
Reviewed-by: Michael Kinney
> -Original Message-
> From: Marvin Häuser [mailto:marvin.haeu...@outlook.com]
> Sent: Saturday, June 18, 2016 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
>
> Subject: [PATCH v2 1/4] MdePkg: Add NORETURN attribute and UNREACHAB
On 06/21/16 10:37, Gary Lin wrote:
> Hi,
>
> When I booted latest OVMF with iPXE(*), none of the options under the
> network device menu worked. To be precise, when I chose the following
> options, instead of going to the configuration UI, it just jumped back
> to the main UI, i.e. the UI shows "D
Tim,
Thanks. The example really helps. I find the syntax for tags a bit difficult
to read, but makes sense what it is doing. Maybe consider defining a
LABEL(LabelName) macro and OFFSET_OF(LabelName) macro to make it more readable?
It looks like you already have an implementation of a pre-pro
> On Jun 20, 2016, at 5:58 PM, Jordan Justen wrote:
>
> On 2016-06-20 17:08:58, Kinney, Michael D wrote:
>> Jordan,
>>
>> There is a "Driver" directory in the proposal and the types of
>> components you refer to would go into packages under "Driver".
>>
>> An OS does not need to initialize th
Hi Jiaxin,
On 21 June 2016 at 12:20, Ryan Harkin wrote:
> Hi Jiaxin,
>
> On 21 June 2016 at 12:10, Wu, Jiaxin wrote:
>> Hi Ryan,
>>
>> I can't reproduce your issue on NT32, I will try it in a real platform later.
>>
>
> I am unable to reproduce the problem on my "FVP models" (a type of
> emulato
On 21 June 2016 at 17:43, Laszlo Ersek wrote:
> On 06/21/16 12:30, Ard Biesheuvel wrote:
>> Similar to how OVMF implements this, add a FD definition for the varstore
>> firmware volume and the FTW areas. This can be used by host side tooling
>> to manipulate a pristine varstore before presenting i
On 06/21/16 12:30, Ard Biesheuvel wrote:
> Similar to how OVMF implements this, add a FD definition for the varstore
> firmware volume and the FTW areas. This can be used by host side tooling
> to manipulate a pristine varstore before presenting it to the guest.
Side question: what host side tooli
On 17 June 2016 at 12:32, Leif Lindholm wrote:
> On Thu, Jun 16, 2016 at 12:29:30PM +0200, Ard Biesheuvel wrote:
>> This introduces a special version of ArmMmuLib for PEIMs that takes care
>> only to perform cache maintenance on the live entry replacement routine
>> if the module is not executing
It should be available to any command. Remember that other people may make
custom commands that could make use of this. Or dynamic commands.
-Jaben
On Jun 21, 2016, at 8:02 AM, Qiu, Shumin
mailto:shumin@intel.com>> wrote:
OK. May be we can add special handle in ParseCommandLineToArgs for
Why? What are we losing in conversion to argc/argv... I thought maybe we
should skip the Lib-based parsing of the parameters?
Why does this not work:
for (x=1;xArgc,x++) // skip 0 which is "echo"
{
print ShellParametersProtocol->Argv[x];
}
From: Qiu, Shumin
Sent: Tuesday, June 21, 2016 7:47 AM
OK. May be we can add special handle in ParseCommandLineToArgs for 'echo'
command.
-Shumin
From: Carsey, Jaben
Sent: Tuesday, June 21, 2016 10:56 PM
To: Qiu, Shumin; edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Carsey, Jaben
Subject: RE: [PATCH] ShellPkg: Fix 'echo' cannot display the special characte
The space char around the argv is striped.
> echo Hello World
Would be
>echo HelloWorld
-Shumin
From: Carsey, Jaben
Sent: Tuesday, June 21, 2016 10:50 PM
To: Qiu, Shumin; edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Carsey, Jaben
Subject: RE: [PATCH] ShellPkg: Fix 'echo' cannot display t
Maybe then we should add an API to ShellCommandLib to get the raw command line?
From: Qiu, Shumin
Sent: Tuesday, June 21, 2016 7:55 AM
To: Carsey, Jaben ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu
Subject: RE: [PATCH] ShellPkg: Fix 'echo' cannot display the special characters
correctly.
Importance:
> echo Hello World
Would be
> HelloWorld
From: Qiu, Shumin
Sent: Tuesday, June 21, 2016 10:55 PM
To: Carsey, Jaben; edk2-devel@lists.01.org
Cc: Ni, Ruiyu
Subject: RE: [PATCH] ShellPkg: Fix 'echo' cannot display the special characters
correctly.
The space char around the argv is st
Hi Jaben,
'echo' should not use ShellParameterProtocol to pass the parameters. It prints
out the string following 'echo' literally. So we need pass the 'CmdLine'
directly.
-Shumin
From: Carsey, Jaben
Sent: Tuesday, June 21, 2016 10:14 PM
To: Qiu, Shumin; edk2-devel@lists.01.org
Cc: Ni, Ruiyu; C
Hi Feng,
Thanks for understanding. Should I resend this patch with your
"Reviewed-by" or rather wait for merge to edk2 tree?
Best Regards,
Jan
2016-06-21 16:30 GMT+02:00 Tian, Feng :
> Hi, Jan
>
> Why I added this check is purely because of this sentence "When PxCMD.FRE is
> set (causing PxCMD.
Thanks for your details, Jan.
If we can find another way to avoid introducing a new interface, that is PCD, I
would vote it. Your new solution makes more sense for me:-).
Best Regards
Feng
-Original Message-
From: Jan Dąbroś [mailto:j...@semihalf.com]
Sent: Tuesday, June 21, 2016 6:12
Hi, Jan
Why I added this check is purely because of this sentence "When PxCMD.FRE is
set (causing PxCMD.FR to be set to ‘1’)" in AHCI spec. And except this, no
other places in AHCI speak about the behavior of PxCMD.FR being 1.
Literally, your controller doesn't follow this single sentence. But
I don't think that means we are not carrying around the size of the echo code.
It looks like we still call the echo API directly through the
RunInternalCommand() API. (copied below)
Can you explain what was the change that required the function had to move to
Shell.c from the Echo.c ?
> @@ -
On 06/21/16 12:30, Ard Biesheuvel wrote:
> This module is now identical in functionality to NorFlashDxe, and is no
> longer used, so remove it altogether.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFla
On 06/21/16 12:30, Ard Biesheuvel wrote:
> There is no longer a reason to use a different implementation of
> NorFlashDxe for secure boot builds now that the varstore FV header can
> carry either gEfiVariableGuid or gEfiAuthenticatedVariableGuid, and the
> dependent code has been updated to deal wi
On 06/21/16 12:30, Ard Biesheuvel wrote:
> Now that the generic Variable Runtime DXE code no longer distinguishes
> between gEfiVariableGuid and gEfiAuthenticatedVariableGuid in the varstore
> FV header, we can relax the check in the NOR flash driver to accept either
> GUID regardless of whether we
On 06/21/16 12:30, Ard Biesheuvel wrote:
> This series refactors some of the NOR flash code in ArmPlatformPkg and
> ArmVirtPkg so that we can add an empty varstore definition to the
> ArmVirtQemu amd ArmVirtQemuKernel FDFs. The refactoring is necessary to make
> NorFlashDxe deal with either of the
Hi Jiaxin,
On 21 June 2016 at 12:10, Wu, Jiaxin wrote:
> Hi Ryan,
>
> I can't reproduce your issue on NT32, I will try it in a real platform later.
>
I am unable to reproduce the problem on my "FVP models" (a type of
emulator) either. The models use a different ethernet device than my
hardware.
Hi Ryan,
I can't reproduce your issue on NT32, I will try it in a real platform later.
> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s
> eth0 dhcp" works. On reboot, policy is dhcp, PXE changes it a couple
> of times, then drops to the shell with is set to static again
There is no longer a reason to use a different implementation of
NorFlashDxe for secure boot builds now that the varstore FV header can
carry either gEfiVariableGuid or gEfiAuthenticatedVariableGuid, and the
dependent code has been updated to deal with that. So move the secure
boot capable builds t
Now that the generic Variable Runtime DXE code no longer distinguishes
between gEfiVariableGuid and gEfiAuthenticatedVariableGuid in the varstore
FV header, we can relax the check in the NOR flash driver to accept either
GUID regardless of whether we are running a secure boot capable build or not.
This series refactors some of the NOR flash code in ArmPlatformPkg and
ArmVirtPkg so that we can add an empty varstore definition to the
ArmVirtQemu amd ArmVirtQemuKernel FDFs. The refactoring is necessary to make
NorFlashDxe deal with either of the GUIDs gEfiAuthenticatedVariableGuid and
gEfiVaria
Similar to how OVMF implements this, add a FD definition for the varstore
firmware volume and the FTW areas. This can be used by host side tooling
to manipulate a pristine varstore before presenting it to the guest.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheu
This module is now identical in functionality to NorFlashDxe, and is no
longer used, so remove it altogether.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashAuthenticatedDxe.inf | 77
1 fi
Hi Feng,
1. In the same chapter of AHCI spec, there is sentence "When this bit
is cleared to ‘0’, software *must* first wait for PxCMD.FR to clear to
‘0’, indicating that the DMA engine for FIS reception is in an idle
condition.". I wanted to emphasize in commit log, that there is no
need to poll
Hi Feng,
> I have comments on other patches.
> 1. Patch 1 is correct fix. But could you also help fix the problem in
> EmmcPeimSetBusMode(), which also pass down a wrong argument order to
> EmmcPeimSwitchToHighSpeed()?
Ok, we will add this change also.
> 2. Other patches are all related with P
Okay, I will update the information.
Thanks for your comment.
Best regards
Lubo
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hegde,
Nagaraj P
Sent: Tuesday, June 21, 2016 6:00 PM
To: Subramanian, Sriram (EG Servers Platform SW) ; Fu, Siyuan
Hi Lubo,
I see this patch is not committed yet. Can you please add the following #define
into IndustryStandard/Dhcp.h during your commit?
#define DHCP4_TAG_USER_CLASS_ID 77 /// User class identifier
Also, I think it would be good to rename the following #define
#define DHCP4_TAG_CLASS_I
Hi Jiaxin,
Thanks for spending time investigating this, I appreciate it.
On 21 June 2016 at 09:46, Wu, Jiaxin wrote:
> Hi Ryan,
>
> First, I want confirm with you that which version code do you used? Edk2
> latest one? If not, I strongly recommend to update it.
> https://github.com/tianocore/e
Hi Ryan,
First, I want confirm with you that which version code do you used? Edk2 latest
one? If not, I strongly recommend to update it.
https://github.com/tianocore/edk2.git
Based on the latest edk2 code, the IPv4 address used in PXE (got from DHCP
process) won't be assigned to NIC interface a
Hi,
When I booted latest OVMF with iPXE(*), none of the options under the
network device menu worked. To be precise, when I chose the following
options, instead of going to the configuration UI, it just jumped back
to the main UI, i.e. the UI shows "Device Manger", "Boot Manager", and
"Boot Mainte
When we try to cd up two levels using the "../.." notation we
only go up one level. This patch fix this bug.
Cc: Liming Gao
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin
---
MdePkg/Library/BaseLib/FilePaths.c | 6 --
1 file changed, 4 insert
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex
---
Vlv2TbltDevicePkg/PlatformPkg.fdf | 5 ++---
Vlv2TbltDevicePkg/PlatformPkgGcc.fdf| 5 ++---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 6 --
Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 6 --
Vlv2Tbl
Let data of DXE memory status code can be used by other modules.
1. Add a dynamic PCD to save the address of DXE memory status code table.
2. Move RUNTIME_MEMORY_STATUSCODE_HEADER to its public header file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia
---
53 matches
Mail list logo
