[edk2] [Patch] Nt32Pkg: Fix PlatformBootManagerLib to respect PcdShellFile.

Fix the code to use PcdShellFile instead of using hard code GUID which always points to new UEFI shell. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Eric Jin --- Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c | 5 + Nt32Pkg/Library/P

[edk2] [PATCH] ShellPkg: Fix Shell fail when execute command in ShellProtocol.Execute().

When execute a command with tailing blank spaces in ShellProtocol.Execute() Shell will fail. This patch move the TrimSpaces operation into ParseCommandLineToArgs function to fix the problem. Cc: Ruiyu Ni Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ya

Re: [edk2] [PATCH v4 07/10] MdeModulePkg: AtaAtapiPassThru: select master/slave around DIAG command

Reviewed-by: Feng Tian -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Wednesday, September 16, 2015 10:57 To: edk2-de...@ml01.01.org Cc: Alexander Graf; Reza Jelveh; Justen, Jordan L; Hannes Reinecke; Gabriel L. Somlo; Tian, Feng Subject: [PATCH v4 07/10] MdeModu

[edk2] [PATCH v4 10/10] OvmfPkg: enable SATA controller

From: Reza Jelveh In this patch, we replace the traditional IDE driver stack that comes from PcAtChipsetPkg and IntelFrameworkModulePkg with more featureful drivers from OvmfPkg and MdeModulePkg. The resultant driver stack is compatible with the previous one, but provides more protocols, on more

[edk2] [PATCH v4 07/10] MdeModulePkg: AtaAtapiPassThru: select master/slave around DIAG command

From: Reza Jelveh Some IDE controllers only update ID fields such as sector information on specific commands such as the DIAG command. The master/slave device is therefore selected both before and after sending the DIAG command; otherwise reading the IDE registers yields the master's ID fields.

[edk2] [PATCH v4 09/10] OvmfPkg: QemuBootOrderLib: recognize Q35 SATA disks / CD-ROMs

The OpenFirmware device paths that QEMU generates for these disks and CD-ROMs are very similar to those generated for the i440fx IDE disks and CD-ROMs (including the same number of devpath nodes necessary for unique parsing). The interpretations and the translation to UEFI devpath fragments are dif

[edk2] [PATCH v4 08/10] PcAtChipsetPkg: IdeControllerDxe: fix protocol usage hints in the INF file

IdeControllerDxe installs EFI_IDE_CONTROLLER_INIT_PROTOCOL interface(s), and consumes PciIo. The comments in the INF file state the opposite at the moment, fix them. Cc: Alexander Graf Cc: Reza Jelveh Cc: Jordan Justen Cc: Ruiyu Ni Cc: Hannes Reinecke Cc: Gabriel L. Somlo Contributed-under:

[edk2] [PATCH v4 04/10] OvmfPkg: SataControllerDxe: add cascading error handling to Start()

In the next patch we'll add another PCI operation to SataControllerStart(), which, on error, has to be rolled back similarly to other actions already being done in SataControllerStart(). Since that PCI operation won't provide a non-NULL pointer on success, its rollback isn't really suitable for the

[edk2] [PATCH v4 05/10] OvmfPkg: SataControllerDxe: enable IO / mem access and DMA when binding

When we bind the SATA controller in SataControllerStart(), we read the NP ("Number of Ports") bitfield from the CAP ("HBA Capabilities") register of the controller. (See the AHCI 1.3.1 spec.) This register is memory mapped. If we'd like to access it, we must at least enable memory space access for

[edk2] [PATCH v4 03/10] OvmfPkg: copy SataControllerDxe from DuetPkg

From: Reza Jelveh Edk2 maintainers reached the consensus that SataControllerDxe was inherently platform specific, for which reason it was not appropriate for either PcAtChipsetPkg nor MdeModulePkg. Hence, if OvmfPkg wanted to use it, it should either reference it directly from under DuetPkg, or c

[edk2] [PATCH v4 06/10] OvmfPkg: SataControllerDxe: enable AHCI mode if IS_PCI_SATADPA()

The location of the Global HBA Control register, and the AHCI Enable bit value come from the AHCI 1.3.1 spec. They are kept together with the existing macros in the header file. This patch completes the implementation of the ideas that Feng shared in

[edk2] [PATCH v4 00/10] OvmfPkg: support for Q35 SATA

I've gone through Reza's v3 posting with extreme care, and also through the feedback that series elicited. http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10545 Ultimately I've preserved the mostly uncontested patches (v3 1/5, v3 2/5, v3 5/5), although I placed them in a more logical / bi

[edk2] [PATCH v4 02/10] DuetPkg: SataControllerDxe: fix private array subscripting

Each one of the DisqualifiedModes, IdentifyData and IdentifyValid arrays in the EFI_SATA_CONTROLLER_PRIVATE_DATA structure is a matrix, represented as a flat array. The code currently uses the incorrect formula Channel * Device to index them. The right formula is [Channel][Device] which ca

[edk2] [PATCH v4 01/10] DuetPkg: SataControllerDxe: fix typo in "DisqulifiedModes"

Cc: Alexander Graf Cc: Reza Jelveh Cc: Jordan Justen Cc: Ruiyu Ni Cc: Hannes Reinecke Cc: Gabriel L. Somlo Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- DuetPkg/SataControllerDxe/SataController.h | 2 +- DuetPkg/SataControllerDxe/SataController.c |

Re: [edk2] [Patch 0/3] Update the keyword handler protocol to follow

Reviewed-by: Liming Gao -Original Message- From: Dong, Eric Sent: Wednesday, September 16, 2015 10:20 AM To: edk2-devel@lists.01.org; Gao, Liming Subject: [Patch 0/3] Update the keyword handler protocol to follow New SCT test case report some error for this protocol, update the code to

[edk2] [Patch 3/3] Refine SetData function to follow spec requirement.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong --- .../Universal/HiiDatabaseDxe/ConfigKeywordHandler.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c b/MdeMo

[edk2] [Patch 1/3] Update Progress to point to the correct return position.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong --- MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c b/MdeModul

[edk2] [Patch 0/3] Update the keyword handler protocol to follow

New SCT test case report some error for this protocol, update the code to fix these issues. Eric Dong (3): Update Progress to point to the correct return position. Refine GetData function to follow spec requirement. Refine SetData function to follow spec requirement. .../HiiDatabaseDxe/Co

[edk2] [Patch 2/3] Refine GetData function to follow spec requirement.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong --- .../HiiDatabaseDxe/ConfigKeywordHandler.c | 23 +++--- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c b/MdeMo

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

Including Rothman Mike. -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, Jaben Sent: Wednesday, September 16, 2015 1:48 AM To: Andrew Fish ; jim_dai...@dell.com Cc: Carsey, Jaben ; edk2-devel@lists.01.org Subject: Re: [edk2] Proposal to let

Re: [edk2] VS tools version and code size

Hi Matthew, I am not seeing large differences in size using the default flags from tools_def.txt. Here are some measurements of the DxeCore.efi module in MdeModulePkg/Core/Dxe. I have included the LZMA compressed size too because that the most common compression for FVs/Modules. TARGET T

[edk2] VS tools version and code size

I have noticed that while compiling using Visual Studio 2008 the code size is much smaller compared to using a later version of Visual Studio, like 2012. Does anyone have any experience as to why that is? Are there any recommended configurations or changes needed when using a later version of Vi

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Andrew Fish > Sent: Tuesday, September 15, 2015 8:33 AM > To: jim_dai...@dell.com > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Proposal to let standalone UEFI shell application carry > he

Re: [edk2] Listing files in a directory

> On Sep 15, 2015, at 10:10 AM, Michael Zimmermann > wrote: > > Hi, > > this sound somewhat trivial but I can't find a way to list the files of a > directory. > the EFI_FILE_PROTOCOL just allows to open a (sub-) file/directory but not > to get a list of all child nodes. > Michael, This is a

Re: [edk2] Listing files in a directory

Hi Michael, You should be able to use the Read function to retrieve the FileInfo for the files contained in the directory pointed to by the current EFI_FILE_PROTOCOL. An example code snippet is below: EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *SimpleFs = NULL; EFI_FILE_PROTOCOL *RootFs = NULL;

[edk2] Listing files in a directory

Hi, this sound somewhat trivial but I can't find a way to list the files of a directory. the EFI_FILE_PROTOCOL just allows to open a (sub-) file/directory but not to get a list of all child nodes. Michael ___ edk2-devel mailing list edk2-devel@lists.01.

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

> On Sep 15, 2015, at 8:27 AM, jim_dai...@dell.com wrote: > > I understand. I have always believed the spec was wrong to try and take over > "-?" from apps. What it wants to do for internal command help is certainly > something that it should specify, but it should not fail to execute an > a

Re: [edk2] ShellPkg: Build errors with ARM64-GCC

On 15 September 2015 at 10:51, Sharma Bhupesh wrote: >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Monday, September 14, 2015 8:41 PM >> On 14 September 2015 at 17:08, Sharma Bhupesh >> wrote: >> > The error message changes to: >> > >> > WriteSections64(): >> /../DEBUG_GCC48

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

I understand. I have always believed the spec was wrong to try and take over "-?" from apps. What it wants to do for internal command help is certainly something that it should specify, but it should not fail to execute an application due to the arguments that are being passed to the app. Bec

Re: [edk2] [Patch V2] * ShellPkg: Add a simple case to test shell parameter parsing logic

Reviewed-by: Jaben Carsey > -Original Message- > From: Ni, Ruiyu > Sent: Monday, September 14, 2015 8:48 PM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu ; Carsey, Jaben > Subject: [Patch V2] * ShellPkg: Add a simple case to test shell parameter > parsing logic > Importance: High > > Te

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

Jim, Currently the shell spec requires a man file and dictates that the shell API GetHelp() be used for help processing. This is a case where if that current usage would fail, can we have a fallback that extends beyond the behavior in the spec. I do not think this violates the spec, but simpl

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

On 09/15/15 15:45, Moore, Robert wrote: > I can't speak to the MS interpreter, but the iASL compiler does > indeed support DataTableRegion Yes, that was the very first thing I tested. That was a prerequisite for writing the design doc (which contained ASL code). > (as well as the ACPICA interpret

Re: [edk2] Proposal to let standalone UEFI shell application carry help inside .EFI instead of in .MAN file

Yes, except if the shell can't find the man file (or it is invalid), then the shell should simply execute the .efi and let it handle the command line (regardless of EFI_HII_PACKAGE_LIST_PROTOCOL_GUID, etc.). Regards, Jim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lis

Re: [edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Remove a hidden assumption.

On 09/15/15 11:38, Zeng, Star wrote: > On 2015/9/15 17:28, Laszlo Ersek wrote: >> On 09/14/15 15:58, Star Zeng wrote: >>> What to do: >>> 1. Remove a hidden assumption "No SMM driver writes BootScript between >>> SmmReadyToLock and S3SleepEntryCallback". >>> 1.1. Use SmmExitBootServices and SmmLe

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

On 09/14/15 19:23, Walz, Michael C wrote: > Who are the Microsoft representatives in the ASWG? Shouldn't this > conversation be happening with them? I asked my colleague Al Stone @RH for help; he said he'd bring this up at the next ASWG meeting. Thank you Al, and thank you Michael for the suggest

Re: [edk2] [Qemu-devel] Windows does not support DataTableRegion at all [was: docs: describe QEMU's VMGenID design]

On 09/14/15 23:12, Bill Paul wrote: [snip -- see my other email too] > Also, if you want to talk business cases, I'm assuming that somewhere > Microsoft claims ACPI compliance. Correct; this page: states

Re: [edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Remove a hidden assumption.

On 2015/9/15 17:28, Laszlo Ersek wrote: On 09/14/15 15:58, Star Zeng wrote: What to do: 1. Remove a hidden assumption "No SMM driver writes BootScript between SmmReadyToLock and S3SleepEntryCallback". 1.1. Use SmmExitBootServices and SmmLegacyBoot notification to record AtRuntime flag.

Re: [edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Remove a hidden assumption.

On 09/14/15 15:58, Star Zeng wrote: > What to do: > 1. Remove a hidden assumption "No SMM driver writes BootScript between > SmmReadyToLock and S3SleepEntryCallback". > 1.1. Use SmmExitBootServices and SmmLegacyBoot notification to record > AtRuntime flag. > 1.2. Use mBootScriptDataBootTime

Re: [edk2] ShellPkg: Build errors with ARM64-GCC

> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, September 14, 2015 8:41 PM > On 14 September 2015 at 17:08, Sharma Bhupesh > wrote: > > The error message changes to: > > > > WriteSections64(): > /../DEBUG_GCC48/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll > AA

Re: [edk2] [PATCH 4/4] OvmfPkg: PlatformPei: take no-exec DXE settings from the QEMU command line

On 09/15/15 01:51, Jordan Justen wrote: > On 2015-09-11 08:15:53, Laszlo Ersek wrote: >> Control them with: >> >> -fw_cfg name=opt/ovmf/PcdPropertiesTableEnable,file=no.txt \ >> -fw_cfg name=opt/ovmf/PcdSetNxForStack,file=yes.txt > > It seems like a -fw_cfg name=foo,content=string form could b

Re: [edk2] [Patch] MdeModulePkg: Enhance PCI capability looking up logic to avoid hang

Looks good to me Reviewed-by: Feng Tian -Original Message- From: Ni, Ruiyu Sent: Tuesday, September 15, 2015 15:34 To: edk2-devel@lists.01.org Cc: Ni, Ruiyu; Tian, Feng Subject: [Patch] MdeModulePkg: Enhance PCI capability looking up logic to avoid hang Certain PCI device may have cap

[edk2] [Patch] MdeModulePkg: Enhance PCI capability looking up logic to avoid hang

Certain PCI device may have capability pointing to itself. Update LocateCapabilityRegBlock() to break when detecting such loop. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Feng Tian --- MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 8 1 file chan

Re: [edk2] [Patch] NetworkPkg: TrafficDirection not saved in IPsecConfig.

Reviewed-by: Ye Ting -Original Message- From: Fu, Siyuan Sent: Tuesday, September 15, 2015 11:10 AM To: edk2-devel@lists.01.org Cc: Wu, Jiaxin; Ye, Ting Subject: [Patch] NetworkPkg: TrafficDirection not saved in IPsecConfig. Fix a bug that the TrafficDirection field is not saved in IPs