Re: [edk2] [PATCH v3 0/4] Add BlockIO2 support for UFS
Sorry for typo, 'a.' should be "ScsiDiskDxe" instead of "ScsiBusDxe" > -----Original Message- > From: Wu, Hao A > Sent: Tuesday, December 08, 2015 2:54 PM > To: edk2-devel@lists.01.org; Tian, Feng > Cc: Wu, Hao A > Subject: [PATCH v3 0/4] Add BlockIO2 support for UFS > > Compared with v2, the following modifications have been made: > a. ScsiBusDxe > 1. For functions ScsiDiskReadBlocksEx() and ScsiDiskWriteBlocksEx(), > signal 'Token->Event' when 'BufferSize' is zero. > 2. For functions ScsiDiskReadBlocksEx() and ScsiDiskWriteBlocksEx(), > add support for 'Token' or 'Token->Event' is NULL. In this case, > non-blocking I/O request will be sent. > 3. The function ScsiDiskDriverBindingStop() will wait until all BlockIO2 > requests have been finished. > > b. UfsPassThruDxe > 1. Now the function UfsPassThruDriverBindingStop() will cancel all the > I/O requests in the async I/O queue and cleanup resources allocated > by those requests. > > > Hao Wu (4): > MdePkg UefiScsiLib: Add non-blocking support for SCSI Read/Write > command > MdeModulePkg ScsiDiskDxe: Add BlockIO2 Support > MdeModulePkg UfsPassThruDxe: Add Non-blocking I/O Support > MdeModulePkg ScsiBusDxe: Fix caller event may nerver be signaled > > MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c | 46 +- > MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ComponentName.c |4 +- > MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 1436 > +++- > MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h | 335 - > MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |6 +- > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 70 +- > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 75 +- > .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 288 +++- > MdePkg/Include/Library/UefiScsiLib.h | 360 + > MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 776 +++ > MdePkg/Library/UefiScsiLib/UefiScsiLib.inf |4 +- > 11 files changed, 3336 insertions(+), 64 deletions(-) > > -- > 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] Raise Tpl to TPL_NOTIFY when dealing SCSI async I/O
Thanks for the feedback. I will update the codes before committing the patches. Best Regards, Hao Wu > -Original Message- > From: Tian, Feng > Sent: Tuesday, December 22, 2015 3:06 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Wu, Hao A; Tian, Feng > Subject: RE: [edk2] [PATCH 0/4] Raise Tpl to TPL_NOTIFY when dealing SCSI > async I/O > > I think as you raise notify event from callback to notify you have to protect > critical data, mainly the transfer queue, by raising TPL to NOTIFY at > accessing > code as well. > > Others look good to me. > > Reviewed-by: Feng Tian > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Hao Wu > Sent: Tuesday, December 22, 2015 00:15 > To: edk2-devel@lists.01.org; Tian, Feng > Cc: Wu, Hao A > Subject: [edk2] [PATCH 0/4] Raise Tpl to TPL_NOTIFY when dealing SCSI async > I/O > > When reading data from non-blockingly from a CD-ROM logic partition, the > procedure can be shown by the following call stack: > (The write process is similar) > > |---| > | DiskIoDxe (logic) |<---Raise Tpl to TPL_CALLBACK > |---| > | > | Sub-task 1 (UnderRun) succeeds > | > ||-| |-| |-| > +--->| PartitionDxe |>| DiskIoDxe (Phy) |>| ScsiDiskDxe | > ||-| |-| |-| > | > | Sub-task 2 (OverRun) fails > | > ||-| |-| |-| > +--->| PartitionDxe |>| DiskIoDxe (Phy) |>| ScsiDiskDxe | > ||-| |-| |-| > | ^ > | | > More subtasks... Wait indefinitely > | > |<---Restore Tpl > | > Completes > > In PartitionDxe, if the 'Lba' and 'BufferSize' parameters passed to function > PartitionReadBlocksEx() are invalid, the function will issue a blocking > ReadDisk call (in function ProbeMediaStatusEx()). > > In DiskIoDxe, blocking I/O request will wait for all the non-blocking I/O > requests to complete first before sending down the blocking request. > > If the Tpl of the async I/O callback in ScsiDiskDxe is TPL_CALLBACK and Sub- > task 1 (UnderRun) succeeds but Sub-task 2 (OverRun) fails with an invalid > parameter, DiskIoDxe will wait indefinitely for the event created by > ScsiDiskDxe of Sub-task 1 to signal. > > Therefore, the async I/O callback functions in ScsiDiskDxe, ScsiBusDxe and > UefiScsiLib need to raise Tpl to TPL_NOTIFY to avoid the above-mentioned > indefinite wait. Plus, the UFS PassThru driver also needs to raise Tpl to > TPL_NOTIFY when processing async SCSI task list. > > Hao Wu (4): > MdeModulePkg ScsiDiskDxe: Raise the Tpl of async IO callback to > TPL_NOTIFY > MdePkg UefiScsiLib: Raise the Tpl of async IO callback to TPL_NOTIFY > MdeModulePkg ScsiBusDxe: Raise the Tpl of async IO callback to > TPL_NOTIFY > MdeModulePkg UfsPassThruDxe: Raise to TPL_NOTIFY when dealing async > task > > MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c | 2 +- > MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 59 > ++ > MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h | 8 ++- > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 2 +- > .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 2 +- > MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 8 +-- > 6 files changed, 62 insertions(+), 19 deletions(-) > > -- > 1.9.5.msysgit.0 > > ___ > 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 0/2] Fix MS tool chain 32bit /Od build failure
Patch series are good to me. Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Tian, Feng > Sent: Thursday, January 07, 2016 10:56 AM > To: Wu, Hao A; Zeng, Star > Cc: edk2-devel@lists.01.org > Subject: [patch 0/2] Fix MS tool chain 32bit /Od build failure > > Two drivers are involved: > 1. UfsBlockIoPei > 2. NvmExpressDxe > > Tian Feng (2): > MdeModulePkg/UfsBlockIoPei: Fix MS toolchain /Od 32bit build failure > MdeModulePkg/NvmExpressDxe: Fix MS toolchain /Od 32bit build failure > > MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressBlockIo.c | 6 +++--- > MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 12 +--- > > MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h | 11 ++ > - > MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c | 4 ++-- > 4 files changed, 12 insertions(+), 21 deletions(-) > > -- > 1.9.5.msysgit.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch 0/5] fixes several issues in EDKII SD stack
The series is good to me. Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Tian, Feng > Sent: Wednesday, May 04, 2016 1:12 PM > To: Wu, Hao A > Cc: edk2-devel@lists.01.org > Subject: [patch 0/5] fixes several issues in EDKII SD stack > > The fixed issues include: > 1. break cmd exec earlier if the card isn't identified successfully > 2. Use BaseClk if the target clock is larger than BaseClk > 3. Use PIO rather DMA mode for sample clock tuning to strictly >follow SD HC spec. > 4. Enhance error handling of tuning procedure > 5. Check supported bus mode before switch > > Feng Tian (5): > MdeModulePkg/SdMmcPciHcDxe: break cmd exec if the card isn't > identified > MdeModulePkg/SdMmcPciHcDxe: Use BaseClk if the target clock is larger > MdeModulePkg/SdMmcPciHcDxe: Using PIO rather than DMA for clock tuning > MdeModulePkg/SdMmcPciHcDxe: Error handling enhance on tuning > procedure > MdeModulePkg/SdMmcPciHcDxe: Check SD's supported bus mode before > switch > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 22 +++- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c | 73 +++ > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 33 - > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 1 + > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 127 ++- > --- > MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHci.c | 96 ++ > MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHci.c | 146 ++- > -- > MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHci.h | 14 +- > 8 files changed, 344 insertions(+), 168 deletions(-) > > -- > 2.7.1.windows.2 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 0/2] Report ACPI NFIT for reserved memory RAM disks
Hi Laszlo, Since the v4 1/2 patch is the same as the v3 1/2 one, so I skipped sending this patch. Sorry for the confusion, I will send the missing patch later. Best Regards, Hao Wu > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, May 06, 2016 11:57 PM > To: El-Haj-Mahmoud, Samer; edk2-devel@lists.01.org; Justen, Jordan L; Wu, > Hao A > Cc: Hsiung, Harry L > Subject: Re: [edk2] [PATCH v4 0/2] Report ACPI NFIT for reserved memory RAM > disks > > On 05/06/16 17:41, El-Haj-Mahmoud, Samer wrote: > > What is the status of this series? It got reviewed a while ago, > > Where? > > I can only find my own review for v4 2/2, and your review for v4 0/2. > > But, patch #1 doesn't even seem to be part of the v4 posting (!), plus I > can't find reviews from MdeModulePkg maintainers for patch #1. > > Thanks > Laszlo > > > > but it still not committed. > > > > From: El-Haj-Mahmoud, Samer > > Sent: Thursday, April 28, 2016 10:30 PM > > To: edk2-devel@lists.01.org; ler...@redhat.com; jordan.l.jus...@intel.com; > hao.a...@intel.com > > Cc: hao.a...@intel.com > > Subject: RE: [edk2] [PATCH v4 0/2] Report ACPI NFIT for reserved memory > RAM disks > > > > Series Reviewed-By: Samer El-Haj-Mahmoud > mailto:el...@hpe.com>> > > > > > > > > -Original Message- > > From: Hao Wu [hao.a...@intel.com] > > Received: Thursday, 28 Apr 2016, 9:23PM > > To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> [edk2- > de...@lists.01.org]; ler...@redhat.com<mailto:ler...@redhat.com> > [ler...@redhat.com]; > jordan.l.jus...@intel.com<mailto:jordan.l.jus...@intel.com> > [jordan.l.jus...@intel.com] > > CC: Hao Wu [hao.a...@intel.com] > > Subject: [edk2] [PATCH v4 0/2] Report ACPI NFIT for reserved memory RAM > disks > > Since the RamDiskDxe part in MdeModulePkg has not been changed, this > > series only contains the patch for changes made in OvmfPkg. > > > > Changes compared with V3: > > 1. Set Pcd 'PcdInstallAcpiSdtProtocol' to TURE in OVMF DSC files. > > > > Changes compared with V2: > > 1. RamDiskDxe driver now will register an EFI event in the Ready To Boot > >Event Group to a). detect whether EFI_ACPI_TABLE_PROTOCOL and > >EFI_ACPI_SDT_PROTOCOL are both produced; b). publish all the reserved > >memory type RAM disks registered at this point to the NFIT if both > >protocols are produced. > > > > 2. The RamDiskUnpublishNfit() now will uninstall NFIT and SSDT that is > >used to report the NVDIMM root device from the ACPI table when there is > >no NFIT structure in NFIT after removing a RAM disk. > > > > 3. Instead of adding a new rule in OvmfPkg FDF files, the patch now lists > >the asl and aml options in the main [Rule.Common.DXE_DRIVER] field. > > > > > > Changes compared with V1: > > 1. Instead of creating a new NFIT for each registered reserved memory RAM > >disk, new cotent of the NFIT is appended to the existing one. > > > > 2. Report an NVDIMM root device in the \SB scope if there is no NFIT in > >the ACPI table. > > > > 3. Modify FDF files in OvmfPkg to make sure the report of the NVDIMM root > >device will be done correctly. > > > > > > Hao Wu (2): > > MdeModulePkg RamDiskDxe: Report ACPI NFIT for reserved memory RAM > > disks > > OvmfPkg: Modify FDF/DSC files for RamDiskDxe's adding NFIT report > > feature > > > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDisk.asl | 44 ++ > > .../Universal/Disk/RamDiskDxe/RamDiskDriver.c | 80 > > .../Universal/Disk/RamDiskDxe/RamDiskDxe.inf | 12 + > > .../Universal/Disk/RamDiskDxe/RamDiskImpl.h| 28 ++ > > .../Universal/Disk/RamDiskDxe/RamDiskProtocol.c| 494 > + > > OvmfPkg/OvmfPkgIa32.dsc| 1 + > > OvmfPkg/OvmfPkgIa32.fdf| 2 + > > OvmfPkg/OvmfPkgIa32X64.dsc | 1 + > > OvmfPkg/OvmfPkgIa32X64.fdf | 2 + > > OvmfPkg/OvmfPkgX64.dsc | 1 + > > OvmfPkg/OvmfPkgX64.fdf | 2 + > > 11 files changed, 667 insertions(+) > > create mode 100644 > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDisk.asl > > > > -- > > 1.9.5.msysgit.0 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org<mailto: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 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] MdeModulePkg/Sd: add Erase Block support on sd/emmc device
One comment below.
And with that solved, Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Tian, Feng
> Sent: Wednesday, May 04, 2016 1:30 PM
> To: Wu, Hao A
> Cc: edk2-devel@lists.01.org; Wu
> Subject: [patch] MdeModulePkg/Sd: add Erase Block support on sd/emmc
> device
>
> It's done by producing EFI_ERASE_BLOCK_PROTOCOL protocol instance.
>
> Cc: Wu, Hao A
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian
> ---
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 411
> ++
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.h | 39 ++-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 74 +-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.h | 5 +
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.inf | 3 +-
> MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 384
>
> MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.h | 39 ++-
> MdeModulePkg/Bus/Sd/SdDxe/SdDxe.c | 15 ++
> MdeModulePkg/Bus/Sd/SdDxe/SdDxe.h | 7 +-
> MdeModulePkg/Bus/Sd/SdDxe/SdDxe.inf | 3 +-
> 10 files changed, 974 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> index edb438b..a12cd63 100644
> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> @@ -47,6 +47,8 @@ AsyncIoCallback (
>
>if (EFI_ERROR (Request->Packet.TransactionStatus)) {
> Request->Token->TransactionStatus = Request->Packet.TransactionStatus;
> + } else {
> +Request->Token->TransactionStatus = EFI_SUCCESS;
I think the 'TransactionStatus' cannot be set to EFI_SUCCESS upon every
successful async I/O completion. If a previous subtask of an async I/O
request fails, the 'TransactionStatus' should be an error status
regardless of the execution status of subsequent subtasks.
Similar issue also exists in SdBlockIo.c.
>}
>
>RemoveEntryList (&Request->Link);
> @@ -1589,3 +1591,412 @@ EmmcSecurityProtocolOut (
>return Status;
> }
>
> +/**
> + Set the erase start address through sync or async I/O request.
> +
> + @param[in] Partition A pointer to the EMMC_PARTITION instance.
> + @param[in] StartLba The starting logical block address to be
> erased.
> + @param[in] Token A pointer to the token associated with the
> transaction.
> + @param[in] IsEnd A boolean to show whether it's the last cmd
> in a
> series of cmds.
> +This parameter is only meaningful in async
> I/O request.
> +
> + @retval EFI_SUCCESS The request is executed successfully.
> + @retval EFI_OUT_OF_RESOURCES The request could not be executed due to
> a lack of resources.
> + @retval OthersThe request could not be executed
> successfully.
> +
> +**/
> +EFI_STATUS
> +EmmcEraseBlockStart (
> + IN EMMC_PARTITION*Partition,
> + IN EFI_LBA StartLba,
> + IN EFI_BLOCK_IO2_TOKEN *Token,
> + IN BOOLEAN IsEnd
> + )
> +{
> + EFI_STATUS Status;
> + EFI_SD_MMC_PASS_THRU_PROTOCOL*PassThru;
> + EMMC_DEVICE *Device;
> + EMMC_REQUEST *EraseBlockStart;
> + EFI_TPL OldTpl;
> +
> + EraseBlockStart = NULL;
> +
> + Device = Partition->Device;
> + PassThru = Device->Private->PassThru;
> +
> + EraseBlockStart = AllocateZeroPool (sizeof (EMMC_REQUEST));
> + if (EraseBlockStart == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Error;
> + }
> +
> + EraseBlockStart->Signature = EMMC_REQUEST_SIGNATURE;
> + OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> + InsertTailList (&Partition->Queue, &EraseBlockStart->Link);
> + gBS->RestoreTPL (OldTpl);
> + EraseBlockStart->Packet.SdMmcCmdBlk= &EraseBlockStart-
> >SdMmcCmdBlk;
> + EraseBlockStart->Packet.SdMmcStatusBlk = &EraseBlockStart-
> >SdMmcStatusBlk;
> + EraseBlockStart->Packet.Timeout= EMMC_GENERIC_TIMEOUT;
> +
> + EraseBlockStart->SdMmcCmdBlk.CommandIndex =
> EMMC_ERASE_GROUP_START;
> + EraseBlockStart->SdMmcCmdBlk.CommandType = SdMmcCommandTypeAc;
> + EraseBlockStart->SdMmcCmdBlk.ResponseType = SdMmcResponseTypeR1;
> +
> + if (Device->SectorAddressing) {
> +EraseBlockStart->SdMmcCmdBlk.CommandArgument = (UINT32)StartLba;
> + } else {
> +EraseBlockStart->SdMmcCmdBlk.CommandArgument =
> (UINT32)MultU64x32 (StartLba, Partitio
Re: [edk2] [PATCH 0/4] ATA PassThru & SATA device path PortMultiplier update
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, May 09, 2016 7:18 PM > To: Wu, Hao A; edk2-de...@ml01.01.org; Tian, Feng; Justen, Jordan L > Subject: Re: [edk2] [PATCH 0/4] ATA PassThru & SATA device path > PortMultiplier update > > Hello Hao, > > On 05/09/16 05:17, Hao Wu wrote: > > The UEFI 2.6 spec updated the description of the port multiplier port > > number parameter in SATA Device Path Node and ATA Pass-Through Protocol. > > (1) > > It seems to me that this spec update was part of release 2.5, not 2.6; > namely for Mantis ticket 1353: > <https://mantis.uefi.org/mantis/view.php?id=1353>. > > The changelog at the beginning of the spec states: > > Revision Revision History (numbers = Mantis ticket numbers) Date > -- --- > 2.5 1353 SATA Device Path Node Errata April, 2015 > > Can you update the spec version in the first three patches? (Maybe > reference the mantis ticket as well.) Yes. Thanks for catching that. I will update the log of the first three commits. > > (2) > > This patch series breaks the following two library instances: > > OvmfPkg/Library/QemuBootOrderLib > OvmfPkg/Library/QemuNewBootOrderLib > > Namely, on the Q35 machine type of QEMU, there is no port multiplier, > hence the middle number (the Port Multiplier Port Number) in the Sata() > device path node changes from 0x0 to 0x. > > For Qemu[New]BootOrderLib, this is not hard to fix. I will post two > additional patches, appended to your series, that should be please > reviewed (by Jordan) and committed (by you) together with the rest of > your patches. If you have to submit a v2 of the series, please don't > forget to preserve my patches as well. > > Please confirm that you can pick up my patches with "git am", from the > list / your inbox. Yes, I can apply the patches. I will add those two commits in my v2 series. > > (3) > > This change will also break boot options for preexistent OVMF virtual > machines that use the Sata() device path node (i.e., non-short-form SATA > boot options). This is independent of point (2) above: the matching in > question is performed by the boot manager. > > I don't have a good idea how to deal with this; we probably can't, and > users will have to update their boot options manually. Agree. Best Regards, Hao Wu > > Thanks > Laszlo > > > > > > Now, this parameter should be set to 0x instead of 0 to indicate that > > an ATA device is directly attached on the controller port. > > > > > > Hao Wu (4): > > MdePkg Protocol/DevicePath.h: Update SATA Device Path comments > > MdePkg Protocol/AtaPassThru.h: Update PortMultiplierPort related > > comments > > MdeModulePkg AtaAtapiPassThru: Use the new PortMultiplierPort > > semantics > > MdeModulePkg AtaAtapiPassThru: Fix incorrect parameter description > > comment > > > > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 14 ++-- > > .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c| 75 > +- > > .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h| 12 ++-- > > MdePkg/Include/Protocol/AtaPassThru.h | 8 +-- > > MdePkg/Include/Protocol/DevicePath.h | 4 +- > > 5 files changed, 78 insertions(+), 35 deletions(-) > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] ATA PassThru & SATA device path PortMultiplier update
OK. I will update the log message title as well. Best Regards, Hao Wu > -Original Message- > From: Tian, Feng > Sent: Tuesday, May 10, 2016 9:49 AM > To: Wu, Hao A; Laszlo Ersek; edk2-de...@ml01.01.org; Justen, Jordan L > Cc: Tian, Feng > Subject: RE: [edk2] [PATCH 0/4] ATA PassThru & SATA device path > PortMultiplier update > > Hi, Hao > > Besides Laszlo's comment, I would suggest you update the commit log title to > highlight the fact that this is an "incompatible" semantic change and the > consumer of SATA device path or ATA_PASS_THRU would have to re-examine > its usage to follow UEFI 2.5 mantis 1353 and 1472. > > Thanks > Feng > > -Original Message- > From: Wu, Hao A > Sent: Tuesday, May 10, 2016 9:37 AM > To: Laszlo Ersek ; edk2-de...@ml01.01.org; Tian, Feng > ; Justen, Jordan L > Subject: RE: [edk2] [PATCH 0/4] ATA PassThru & SATA device path > PortMultiplier update > > > -Original Message----- > > From: Laszlo Ersek [mailto:ler...@redhat.com] > > Sent: Monday, May 09, 2016 7:18 PM > > To: Wu, Hao A; edk2-de...@ml01.01.org; Tian, Feng; Justen, Jordan L > > Subject: Re: [edk2] [PATCH 0/4] ATA PassThru & SATA device path > > PortMultiplier update > > > > Hello Hao, > > > > On 05/09/16 05:17, Hao Wu wrote: > > > The UEFI 2.6 spec updated the description of the port multiplier > > > port number parameter in SATA Device Path Node and ATA Pass-Through > Protocol. > > > > (1) > > > > It seems to me that this spec update was part of release 2.5, not 2.6; > > namely for Mantis ticket 1353: > > <https://mantis.uefi.org/mantis/view.php?id=1353>. > > > > The changelog at the beginning of the spec states: > > > > Revision Revision History (numbers = Mantis ticket numbers) Date > > -- --- > > 2.5 1353 SATA Device Path Node Errata April, 2015 > > > > Can you update the spec version in the first three patches? (Maybe > > reference the mantis ticket as well.) > > Yes. Thanks for catching that. I will update the log of the first three > commits. > > > > > (2) > > > > This patch series breaks the following two library instances: > > > > OvmfPkg/Library/QemuBootOrderLib > > OvmfPkg/Library/QemuNewBootOrderLib > > > > Namely, on the Q35 machine type of QEMU, there is no port multiplier, > > hence the middle number (the Port Multiplier Port Number) in the > > Sata() device path node changes from 0x0 to 0x. > > > > For Qemu[New]BootOrderLib, this is not hard to fix. I will post two > > additional patches, appended to your series, that should be please > > reviewed (by Jordan) and committed (by you) together with the rest of > > your patches. If you have to submit a v2 of the series, please don't > > forget to preserve my patches as well. > > > > Please confirm that you can pick up my patches with "git am", from the > > list / your inbox. > > Yes, I can apply the patches. I will add those two commits in my v2 series. > > > > > (3) > > > > This change will also break boot options for preexistent OVMF virtual > > machines that use the Sata() device path node (i.e., non-short-form > > SATA boot options). This is independent of point (2) above: the > > matching in question is performed by the boot manager. > > > > I don't have a good idea how to deal with this; we probably can't, and > > users will have to update their boot options manually. > > Agree. > > Best Regards, > Hao Wu > > > > > Thanks > > Laszlo > > > > > > > > > > Now, this parameter should be set to 0x instead of 0 to indicate > > > that an ATA device is directly attached on the controller port. > > > > > > > > > Hao Wu (4): > > > MdePkg Protocol/DevicePath.h: Update SATA Device Path comments > > > MdePkg Protocol/AtaPassThru.h: Update PortMultiplierPort related > > > comments > > > MdeModulePkg AtaAtapiPassThru: Use the new PortMultiplierPort > > > semantics > > > MdeModulePkg AtaAtapiPassThru: Fix incorrect parameter description > > > comment > > > > > > MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 14 ++-- > > > .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.c| 75 > > +- > > > .../Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.h| 12 ++-- > > > MdePkg/Include/Protocol/AtaPassThru.h | 8 +-- > > > MdePkg/Include/Protocol/DevicePath.h | 4 +- > > > 5 files changed, 78 insertions(+), 35 deletions(-) > > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg NvmExpressDxe: Add check before creating an aync IO queue
I will update the commit subject to:
MdeModulePkg NvmExpressDxe: Fix invalid queue size when creating IO queues
when committing the patch.
Best Regards,
Hao Wu
> -Original Message-
> From: Tian, Feng
> Sent: Thursday, June 02, 2016 9:58 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Tian, Feng
> Subject: RE: [PATCH] MdeModulePkg NvmExpressDxe: Add check before
> creating an aync IO queue
>
> Sorry, I have an additional comment about the commit log title.
>
> I would suggest you to describe the problem you solved rather than the action
> you made. It would be more straightforward for others.
>
> If you refine the log title like this, you have my R-b.
>
> Reviewed-by: Feng Tian
>
> Thanks
> Feng
>
> -Original Message-
> From: Tian, Feng
> Sent: Wednesday, June 1, 2016 4:53 PM
> To: Wu, Hao A ; edk2-devel@lists.01.org
> Cc: Tian, Feng
> Subject: RE: [PATCH] MdeModulePkg NvmExpressDxe: Add check before
> creating an aync IO queue
>
> Reviewed-by: Feng Tian
>
> Thanks
> Feng
>
> -Original Message-----
> From: Wu, Hao A
> Sent: Wednesday, June 1, 2016 4:48 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Tian, Feng
> Subject: [PATCH] MdeModulePkg NvmExpressDxe: Add check before creating
> an aync IO queue
>
> The Maximum Queue Entries Supported (MQES) field in the CAP (Controller
> Capabilities) register for a NVMe controller restrict the maximum individual
> queue size that the controller supports.
>
> The origin code does not check this value and always uses a hardcode value
> when creating I/O submission/completion queues for asynchronous
> transmission. The hardcode value might be larger than the MQES field, this
> will
> lead to an 'Invalid Queue Size' error when creating I/O submission/completion
> queues.
>
> The patch will add checks to make sure proper queue size is passed when
> creating I/O submission/completion queues.
>
> Cc: Feng Tian
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c | 26
> --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> index 4f83a92..a173504 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.c
> @@ -683,6 +683,7 @@ NvmeCreateIoCompletionQueue (
>EFI_STATUS Status;
>NVME_ADMIN_CRIOCQCrIoCq;
>UINT32 Index;
> + UINT16 QueueSize;
>
>Status = EFI_SUCCESS;
>
> @@ -701,8 +702,18 @@ NvmeCreateIoCompletionQueue (
> CommandPacket.CommandTimeout = NVME_GENERIC_TIMEOUT;
> CommandPacket.QueueType = NVME_ADMIN_QUEUE;
>
> +if (Index == 1) {
> + QueueSize = NVME_CCQ_SIZE;
> +} else {
> + if (Private->Cap.Mqes > NVME_ASYNC_CCQ_SIZE) {
> +QueueSize = NVME_ASYNC_CCQ_SIZE;
> + } else {
> +QueueSize = Private->Cap.Mqes;
> + }
> +}
> +
> CrIoCq.Qid = Index;
> -CrIoCq.Qsize = (Index == 1) ? NVME_CCQ_SIZE : NVME_ASYNC_CCQ_SIZE;
> +CrIoCq.Qsize = QueueSize;
> CrIoCq.Pc= 1;
> CopyMem (&CommandPacket.NvmeCmd->Cdw10, &CrIoCq, sizeof
> (NVME_ADMIN_CRIOCQ));
> CommandPacket.NvmeCmd->Flags = CDW10_VALID | CDW11_VALID; @@ -
> 741,6 +752,7 @@ NvmeCreateIoSubmissionQueue (
>EFI_STATUS Status;
>NVME_ADMIN_CRIOSQCrIoSq;
>UINT32 Index;
> + UINT16 QueueSize;
>
>Status = EFI_SUCCESS;
>
> @@ -759,8 +771,18 @@ NvmeCreateIoSubmissionQueue (
> CommandPacket.CommandTimeout = NVME_GENERIC_TIMEOUT;
> CommandPacket.QueueType = NVME_ADMIN_QUEUE;
>
> +if (Index == 1) {
> + QueueSize = NVME_CSQ_SIZE;
> +} else {
> + if (Private->Cap.Mqes > NVME_ASYNC_CSQ_SIZE) {
> +QueueSize = NVME_ASYNC_CSQ_SIZE;
> + } else {
> +QueueSize = Private->Cap.Mqes;
> + }
> +}
> +
> CrIoSq.Qid = Index;
> -CrIoSq.Qsize = (Index == 1) ? NVME_CSQ_SIZE : NVME_ASYNC_CSQ_SIZE;
> +CrIoSq.Qsize = QueueSize;
> CrIoSq.Pc= 1;
> CrIoSq.Cqid = Index;
> CrIoSq.Qprio = 0;
> --
> 1.9.5.msysgit.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Add Memory Type selection support in Ramdisk HII
Hi Tapan, Two comments below. Best Regards Hao Wu > -Original Message- > From: Tapan Shah [mailto:tapands...@hpe.com] > Sent: Friday, June 03, 2016 2:34 AM > To: edk2-devel@lists.01.org > Cc: samer.el-haj-mahm...@hpe.com; Carsey, Jaben; Wu, Hao A; Tian, Feng; > Tapan Shah > Subject: [PATCH] MdeModulePkg/RamDiskDxe: Add Memory Type selection > support in Ramdisk HII > > Adding an option in HII menu so user can choose memory type to use when > creating a RAM Disk in system. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Tapan Shah > --- > .../Universal/Disk/RamDiskDxe/RamDiskHii.vfr | 12 > .../Disk/RamDiskDxe/RamDiskHiiStrings.uni | 7 - > .../Universal/Disk/RamDiskDxe/RamDiskImpl.c| 33 +-- > --- > .../Universal/Disk/RamDiskDxe/RamDiskNVData.h | 10 +++ > 4 files changed, 54 insertions(+), 8 deletions(-) > > diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > index 9c3e3e4..c8bb78b 100644 > --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > @@ -2,6 +2,7 @@ > // VFR file used by the RamDiskDxe driver. > // > // Copyright (c) 2016, Intel Corporation. All rights reserved. > +// (C) Copyright 2016 Hewlett Packard Enterprise Development LP > // 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 > @@ -31,6 +32,17 @@ formset >form formid = MAIN_FORM_ID, > title = STRING_TOKEN(STR_MAIN_FORM_TITLE); > > +oneof varid = RAM_DISK_CONFIGURATION.MemType, > + questionid = CREATE_RAW_MEMORY_TYPE_QUESTION_ID, > +prompt = STRING_TOKEN(STR_MEMORY_TYPE_PROMPT), > +help= STRING_TOKEN(STR_MEMORY_TYPE_HELP), > +flags = INTERACTIVE, > +option text = > STRING_TOKEN(STR_RAM_DISK_BOOT_SERVICE_DATA_MEMORY), value = > RAM_DISK_BOOT_SERVICE_DATA_MEMORY, flags = DEFAULT; > +option text = STRING_TOKEN(STR_RAM_DISK_RESERVED_MEMORY), > value = RAM_DISK_RESERVED_MEMORY, flags = 0; > +endoneof; > + > +subtitle text = STRING_TOKEN(STR_RAM_DISK_NULL_STRING); > + > goto CREATE_RAW_RAM_DISK_FORM_ID, >prompt = STRING_TOKEN(STR_GOTO_ADD_RAW_FORM), >help = STRING_TOKEN(STR_GOTO_ADD_RAW_FORM_HELP); > diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > index ee5f6e6..9cc0b08 100644 > --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > @@ -2,7 +2,7 @@ > // String definitions for RamDiskDxe driver form. > // > // Copyright (c) 2016, Intel Corporation. All rights reserved. > -// > +// (C) Copyright 2016 Hewlett Packard Enterprise Development LP > // 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 > @@ -36,6 +36,11 @@ > #string STR_SIZE_PROMPT#language en-US "Size (Hex):" > #string STR_SIZE_HELP #language en-US "The valid RAM disk > size > should be multiples of the RAM disk block size." > > +#string STR_MEMORY_TYPE_PROMPT#language en-US "Disk > Memory Type:" > +#string STR_MEMORY_TYPE_HELP #language en-US "Specifies type > of memory to use from available memory pool in system to create a disk." > +#string STR_RAM_DISK_BOOT_SERVICE_DATA_MEMORY #language en-US > "Boot Service Data" > +#string STR_RAM_DISK_RESERVED_MEMORY #language en-US > "Reserved" > + > #string STR_CREATE_AND_EXIT_HELP #language en-US "Create a new > RAM disk with the given starting and ending address." > #string STR_CREATE_AND_EXIT_PROMPT #language en-US "Create & Exit" > #string STR_DISCARD_AND_EXIT_HELP #language en-US "Discard and exit." > diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > index f402440..d8e081b 100644 > --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > @@ -2,6 +2,7 @@ >HII Config Access protocol implementation of RamDiskDxe driver. > >
Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Add RAW Ramdisk size change support in HII form
Hi Tapan, Similar to the comments on your previous patch, I think a previous call to the function HiiGetBrowserData() already updates the content in 'Configuration'. So I think the origin code is fine, what's your thought? Best Regards Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tapan Shah > Sent: Friday, June 03, 2016 2:35 AM > To: edk2-devel@lists.01.org > Cc: Carsey, Jaben; Wu, Hao A; Tian, Feng > Subject: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Add RAW Ramdisk size > change support in HII form > > Fix an issue where RAW disk size change was not stored back to the > variable store. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Tapan Shah > --- > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > index d8e081b..ad8af04 100644 > --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.c > @@ -756,6 +756,11 @@ RamDiskCallback ( >*ActionRequest = EFI_BROWSER_ACTION_REQUEST_FORM_APPLY; >break; > > +case CREATE_RAW_SIZE_QUESTION_ID: > + Configuration->Size = Value->u64; > + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_FORM_APPLY; > + break; > + > default: >break; > } > -- > 2.6.2.windows.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] MdeModulePkg/AtaBusDxe: Fix some ATA hard drives cannot be discovered
The patch is good to me. Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Cinnamon Shia > Sent: Monday, June 06, 2016 12:08 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; el...@hpe.com; Tian, Feng; Zeng, Star > Subject: [edk2] [PATCH] MdeModulePkg/AtaBusDxe: Fix some ATA hard drives > cannot be discovered > > If there is no multiplier, the DEV bit of the ATA device register would > always be set. It causes that some ATA hard drives don't response the > ATA identity command sent to them. > > Below is the description about DEV bit in ATA spec: > A device is selected when the DEV bit of the Device register is equal to > the device number assigned to the device by means of a Device 0/Device 1 > jumper or switch, or use of the CSEL signal. > > Below is the description about DEV bit in SATA spec: > When the DEV bit in the Device register is set to one, selecting the > non-existent Device 1, the host adapter shall respond to register reads > and writes as specified for a Device 0 with no Device 1 present, as > defined in the ATA/ATAPI-5 standard. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Cinnamon Shia > --- > MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > index a3008f9..a3739fc 100644 > --- a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > +++ b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > @@ -11,6 +11,7 @@ >Cylinder register. > >Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved. > + (C) Copyright 2016 Hewlett Packard Enterprise Development LP >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 > @@ -413,7 +414,7 @@ DiscoverAtaDevice ( >// >Acb = ZeroMem (&AtaDevice->Acb, sizeof (EFI_ATA_COMMAND_BLOCK)); >Acb->AtaCommand = ATA_CMD_IDENTIFY_DRIVE; > - Acb->AtaDeviceHead = (UINT8) (BIT7 | BIT6 | BIT5 | (AtaDevice- > >PortMultiplierPort << 4)); > + Acb->AtaDeviceHead = (UINT8) (BIT7 | BIT6 | BIT5 | (AtaDevice- > >PortMultiplierPort == 0x ? 0 : (AtaDevice->PortMultiplierPort << 4))); > >// >// Prepare for ATA pass through packet. > -- > 2.8.1.windows.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] MdeModulePkg/AtaBusDxe: Fix some ATA hard drives cannot be discovered
Pushed at 2d273c8db95430b680e542e38cf07b97f9b57d11. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Cinnamon Shia > Sent: Monday, June 06, 2016 12:08 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; el...@hpe.com; Tian, Feng; Zeng, Star > Subject: [edk2] [PATCH] MdeModulePkg/AtaBusDxe: Fix some ATA hard drives > cannot be discovered > > If there is no multiplier, the DEV bit of the ATA device register would > always be set. It causes that some ATA hard drives don't response the > ATA identity command sent to them. > > Below is the description about DEV bit in ATA spec: > A device is selected when the DEV bit of the Device register is equal to > the device number assigned to the device by means of a Device 0/Device 1 > jumper or switch, or use of the CSEL signal. > > Below is the description about DEV bit in SATA spec: > When the DEV bit in the Device register is set to one, selecting the > non-existent Device 1, the host adapter shall respond to register reads > and writes as specified for a Device 0 with no Device 1 present, as > defined in the ATA/ATAPI-5 standard. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Cinnamon Shia > --- > MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > index a3008f9..a3739fc 100644 > --- a/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > +++ b/MdeModulePkg/Bus/Ata/AtaBusDxe/AtaPassThruExecute.c > @@ -11,6 +11,7 @@ >Cylinder register. > >Copyright (c) 2009 - 2013, Intel Corporation. All rights reserved. > + (C) Copyright 2016 Hewlett Packard Enterprise Development LP >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 > @@ -413,7 +414,7 @@ DiscoverAtaDevice ( >// >Acb = ZeroMem (&AtaDevice->Acb, sizeof (EFI_ATA_COMMAND_BLOCK)); >Acb->AtaCommand = ATA_CMD_IDENTIFY_DRIVE; > - Acb->AtaDeviceHead = (UINT8) (BIT7 | BIT6 | BIT5 | (AtaDevice- > >PortMultiplierPort << 4)); > + Acb->AtaDeviceHead = (UINT8) (BIT7 | BIT6 | BIT5 | (AtaDevice- > >PortMultiplierPort == 0x ? 0 : (AtaDevice->PortMultiplierPort << 4))); > >// >// Prepare for ATA pass through packet. > -- > 2.8.1.windows.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] MdeModulePkg/RamDiskDxe: Add Memory Type selection support in Ramdisk HII
Hi Tapan, I think you are right that there will be issues for not saving the changed 'Size' numeric and 'MemoryType' oneof back to the varstore. My expecting behavior for these two HII elements during raw RAM disk creation is that after a user created (or canceled the creation) a RAM disk, their values will be back to their default value (i.e. 0x1000 for 'Size' and RAM_DISK_BOOT_SERVICE_DATA_MEMORY for 'MemoryType'). So I think using varstore to save the previous 'Size' and 'MemoryType' values is not necessary here. Eliminating the varstore will also remove the HiiGetBrowserData/HiiSetBrowserData calls to make the code less confusing. I will send out a new patch series based on your patch. The first patch of the series will remove the varstore used in the driver. The second patch will be your proposed patch (with some small modifications). Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wu, > Hao A > Sent: Friday, June 03, 2016 10:14 AM > To: Tapan Shah; edk2-devel@lists.01.org > Cc: Carsey, Jaben; Tian, Feng > Subject: Re: [edk2] [PATCH] MdeModulePkg/RamDiskDxe: Add Memory Type > selection support in Ramdisk HII > > Hi Tapan, > > Two comments below. > > Best Regards > Hao Wu > > > -Original Message- > > From: Tapan Shah [mailto:tapands...@hpe.com] > > Sent: Friday, June 03, 2016 2:34 AM > > To: edk2-devel@lists.01.org > > Cc: samer.el-haj-mahm...@hpe.com; Carsey, Jaben; Wu, Hao A; Tian, Feng; > > Tapan Shah > > Subject: [PATCH] MdeModulePkg/RamDiskDxe: Add Memory Type selection > > support in Ramdisk HII > > > > Adding an option in HII menu so user can choose memory type to use when > > creating a RAM Disk in system. > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Tapan Shah > > --- > > .../Universal/Disk/RamDiskDxe/RamDiskHii.vfr | 12 > > .../Disk/RamDiskDxe/RamDiskHiiStrings.uni | 7 - > > .../Universal/Disk/RamDiskDxe/RamDiskImpl.c| 33 > +-- > > --- > > .../Universal/Disk/RamDiskDxe/RamDiskNVData.h | 10 +++ > > 4 files changed, 54 insertions(+), 8 deletions(-) > > > > diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > > b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > > index 9c3e3e4..c8bb78b 100644 > > --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > > +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHii.vfr > > @@ -2,6 +2,7 @@ > > // VFR file used by the RamDiskDxe driver. > > // > > // Copyright (c) 2016, Intel Corporation. All rights reserved. > > +// (C) Copyright 2016 Hewlett Packard Enterprise Development LP > > // 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 > > @@ -31,6 +32,17 @@ formset > >form formid = MAIN_FORM_ID, > > title = STRING_TOKEN(STR_MAIN_FORM_TITLE); > > > > +oneof varid = RAM_DISK_CONFIGURATION.MemType, > > + questionid = CREATE_RAW_MEMORY_TYPE_QUESTION_ID, > > +prompt = STRING_TOKEN(STR_MEMORY_TYPE_PROMPT), > > +help= STRING_TOKEN(STR_MEMORY_TYPE_HELP), > > +flags = INTERACTIVE, > > +option text = > > STRING_TOKEN(STR_RAM_DISK_BOOT_SERVICE_DATA_MEMORY), value = > > RAM_DISK_BOOT_SERVICE_DATA_MEMORY, flags = DEFAULT; > > +option text = STRING_TOKEN(STR_RAM_DISK_RESERVED_MEMORY), > > value = RAM_DISK_RESERVED_MEMORY, flags = 0; > > +endoneof; > > + > > +subtitle text = STRING_TOKEN(STR_RAM_DISK_NULL_STRING); > > + > > goto CREATE_RAW_RAM_DISK_FORM_ID, > >prompt = STRING_TOKEN(STR_GOTO_ADD_RAW_FORM), > >help = STRING_TOKEN(STR_GOTO_ADD_RAW_FORM_HELP); > > diff --git > a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > > b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > > index ee5f6e6..9cc0b08 100644 > > --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > > +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskHiiStrings.uni > > @@ -2,7 +2,7 @@ > > // String definitions for RamDiskDxe driver form. > > // > > // Copyright (c) 2016, Intel Corporation. All rights reserved. > > -// > > +// (C) Copyright 2016 Hewlett Packard Enterprise Development LP > > // T
Re: [edk2] [patch] MdeModulePkg/SdMmc: update TPL to notify to fix UEFI SCT hang
Hi Feng,
I found that some "RemoveEntryList" calls that modifies SD/EMMC device's
queue are not guarded by raising the TPL.
I think most of them are related with EraseBlock feature functions in file
EmmcBlockIo.c & SdBlockIo.c.
Could you help to double confirm and add the missing guards?
Best Regards,
Hao Wu
> -Original Message-
> From: Tian, Feng
> Sent: Thursday, June 23, 2016 3:53 PM
> To: Wu, Hao A
> Cc: edk2-devel@lists.01.org
> Subject: [patch] MdeModulePkg/SdMmc: update TPL to notify to fix UEFI SCT
> hang
>
> We have to upgrade the TPL level used by SdMmc stack because the
> following flow:
>
> DiskIo2ReadWriteDisk() in logical partition -> PartitionReadBlocksEx()
> in logical partition at TPL callback level -> ProbeMediaStatusEx()
> with sync request -> DiskIo2ReadWriteDisk() in physical partition ->
> waiting for async task completion.
>
> if the low layer driver doesn't run at TPL_NOTIFY level, it will have
> no time to trigger async task and cause system hang.
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 8 ++--
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 2 +-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 48 +++-
> --
> MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 22 +-
> MdeModulePkg/Bus/Sd/SdDxe/SdDxe.c | 2 +-
> 5 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index ed6b557..8716fcd 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -665,7 +665,7 @@ SdMmcPciHcDriverBindingStart (
>//
>Status = gBS->CreateEvent (
>EVT_TIMER | EVT_NOTIFY_SIGNAL,
> - TPL_CALLBACK,
> + TPL_NOTIFY,
>ProcessAsyncTaskList,
>Private,
>&Private->TimerEvent
> @@ -684,7 +684,7 @@ SdMmcPciHcDriverBindingStart (
>//
>Status = gBS->CreateEvent (
>EVT_TIMER | EVT_NOTIFY_SIGNAL,
> - TPL_CALLBACK,
> + TPL_NOTIFY,
>SdMmcPciHcEnumerateDevice,
>Private,
>&Private->ConnectEvent
> @@ -961,7 +961,7 @@ SdMmcPassThruPassThru (
>// Wait async I/O list is empty before execute sync I/O operation.
>//
>while (TRUE) {
> -OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> +OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
> if (IsListEmpty (&Private->Queue)) {
>gBS->RestoreTPL (OldTpl);
>break;
> @@ -1273,7 +1273,7 @@ SdMmcPassThruResetDevice (
>//
>// Free all async I/O requests in the queue
>//
> - OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> + OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
>
>for (Link = GetFirstNode (&Private->Queue);
> !IsNull (&Private->Queue, Link);
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 8978182..b4ff2af 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1315,7 +1315,7 @@ SdMmcCreateTrb (
>}
>
>if (Event != NULL) {
> -OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> +OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
> InsertTailList (&Private->Queue, &Trb->TrbList);
> gBS->RestoreTPL (OldTpl);
>}
> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> index 5fe710d..a4c6053 100644
> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> @@ -339,7 +339,7 @@ EmmcSetExtCsd (
>}
>
>SetExtCsdReq->Signature = EMMC_REQUEST_SIGNATURE;
> - OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> + OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
>InsertTailList (&Partition->Queue, &SetExtCsdReq->Link);
>gBS->RestoreTPL (OldTpl);
>SetExtCsdReq->Packet.SdMmcCmdBlk= &SetExtCsdReq->SdMmcCmdBlk;
> @@ -361,7 +361,7 @@ EmmcSetExtCsd (
>if ((Token != NULL) && (Token->Event != NULL)) {
> Status = gBS->CreateEvent (
> EVT_NOTIFY_SIGNAL,
> -TPL_CALLBACK,
> +TPL_NOTIFY,
> AsyncIoCallback,
> SetExtCsd
Re: [edk2] [patch] MdeModulePkg/HiiDatabaseDxe: Add ASSERT before using the pointer 'String'
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Bi, Dandan
> Sent: Friday, June 24, 2016 1:43 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Wu, Hao A
> Subject: [patch] MdeModulePkg/HiiDatabaseDxe: Add ASSERT before using the
> pointer 'String'
>
> The 'Sting' is returned by the function GetUnicodeStringTextAndSize.
> If it is NULL, function GetUnicodeStringTextAndSize will return
> EFI_OUT_OF_RESOURCES, and error handling codes will cover it.
> So the pointer 'Sting' can not be NULL when using it.
> So we can add the ASSERT codes.
>
> Cc: Eric Dong
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi
> ---
> MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c | 8 -
> ---
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
> b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
> index 03f8141..6682319 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigKeywordHandler.c
> @@ -873,11 +873,11 @@ GetStringIdFromString (
>//
>Status = GetUnicodeStringTextAndSize (StringTextPtr, &StringSize,
> &String);
>if (EFI_ERROR (Status)) {
> goto Done;
>}
> -
> + ASSERT (String != NULL);
>if (StrCmp(KeywordValue, String) == 0) {
> *StringId = CurrentStringId;
> goto Done;
>}
>BlockSize += Offset + StringSize;
> @@ -893,11 +893,11 @@ GetStringIdFromString (
>//
>Status = GetUnicodeStringTextAndSize (StringTextPtr, &StringSize,
> &String);
>if (EFI_ERROR (Status)) {
> goto Done;
>}
> -
> + ASSERT (String != NULL);
>if (StrCmp(KeywordValue, String) == 0) {
> *StringId = CurrentStringId;
> goto Done;
>}
>BlockSize += Offset + StringSize;
> @@ -912,11 +912,11 @@ GetStringIdFromString (
>for (Index = 0; Index < StringCount; Index++) {
> Status = GetUnicodeStringTextAndSize (StringTextPtr, &StringSize,
> &String);
> if (EFI_ERROR (Status)) {
>goto Done;
> }
> -
> +ASSERT (String != NULL);
> BlockSize += StringSize;
> if (StrCmp(KeywordValue, String) == 0) {
>*StringId = CurrentStringId;
>goto Done;
> }
> @@ -937,11 +937,11 @@ GetStringIdFromString (
>for (Index = 0; Index < StringCount; Index++) {
> Status = GetUnicodeStringTextAndSize (StringTextPtr, &StringSize,
> &String);
> if (EFI_ERROR (Status)) {
>goto Done;
> }
> -
> +ASSERT (String != NULL);
> BlockSize += StringSize;
> if (StrCmp(KeywordValue, String) == 0) {
>*StringId = CurrentStringId;
>goto Done;
> }
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch v3] MdeModulePkg/SdMmc: update TPL to notify to fix UEFI SCT hang
The patch is good to me.
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Tian, Feng
> Sent: Friday, June 24, 2016 3:25 PM
> To: Wu, Hao A
> Cc: edk2-devel@lists.01.org
> Subject: [patch v3] MdeModulePkg/SdMmc: update TPL to notify to fix UEFI SCT
> hang
>
> Compared with v2, we add missing critical region protection to error handling
> path of SdRwSingleBlock & SdRwMultiBlocks functions.
>
> We also fix an issue found at v1 & v2, in which the enumeration timer should
> work at TPL_CALLBACK level as DiskIo is required to be <= TPL_CALLBACK.
>
> Compared with v1, we added critical region protection on queue access made
> in EraseBlock support.
>
> We have to upgrade the TPL level used by SdMmc stack because the
> following flow:
>
> DiskIo2ReadWriteDisk() in logical partition -> PartitionReadBlocksEx()
> in logical partition at TPL callback level -> ProbeMediaStatusEx()
> with sync request -> DiskIo2ReadWriteDisk() in physical partition ->
> waiting for async task completion.
>
> if the low layer driver doesn't run at TPL_NOTIFY level, it will have
> no time to trigger async task and cause system hang.
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 9 ++--
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 2 +-
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 60 +--
> ---
> MdeModulePkg/Bus/Sd/SdDxe/SdBlockIo.c | 42 +++
> MdeModulePkg/Bus/Sd/SdDxe/SdDxe.c | 2 +-
> 5 files changed, 75 insertions(+), 40 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index ed6b557..0be081d 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -238,6 +238,7 @@ SdMmcPciHcEnumerateDevice (
>LIST_ENTRY *Link;
>LIST_ENTRY *NextLink;
>SD_MMC_HC_TRB *Trb;
> + EFI_TPL OldTpl;
>
>Private = (SD_MMC_HC_PRIVATE_DATA*)Context;
>
> @@ -251,6 +252,7 @@ SdMmcPciHcEnumerateDevice (
> //
> // Signal all async task events at the slot with EFI_NO_MEDIA status.
> //
> +OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
> for (Link = GetFirstNode (&Private->Queue);
> !IsNull (&Private->Queue, Link);
> Link = NextLink) {
> @@ -263,6 +265,7 @@ SdMmcPciHcEnumerateDevice (
> SdMmcFreeTrb (Trb);
>}
> }
> +gBS->RestoreTPL (OldTpl);
> //
> // Notify the upper layer the connect state change through
> ReinstallProtocolInterface.
> //
> @@ -665,7 +668,7 @@ SdMmcPciHcDriverBindingStart (
>//
>Status = gBS->CreateEvent (
>EVT_TIMER | EVT_NOTIFY_SIGNAL,
> - TPL_CALLBACK,
> + TPL_NOTIFY,
>ProcessAsyncTaskList,
>Private,
>&Private->TimerEvent
> @@ -961,7 +964,7 @@ SdMmcPassThruPassThru (
>// Wait async I/O list is empty before execute sync I/O operation.
>//
>while (TRUE) {
> -OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> +OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
> if (IsListEmpty (&Private->Queue)) {
>gBS->RestoreTPL (OldTpl);
>break;
> @@ -1273,7 +1276,7 @@ SdMmcPassThruResetDevice (
>//
>// Free all async I/O requests in the queue
>//
> - OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> + OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
>
>for (Link = GetFirstNode (&Private->Queue);
> !IsNull (&Private->Queue, Link);
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 8978182..b4ff2af 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1315,7 +1315,7 @@ SdMmcCreateTrb (
>}
>
>if (Event != NULL) {
> -OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
> +OldTpl = gBS->RaiseTPL (TPL_NOTIFY);
> InsertTailList (&Private->Queue, &Trb->TrbList);
> gBS->RestoreTPL (OldTpl);
>}
> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
> index 5fe710d..fc705e1 100644
> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBloc
Re: [edk2] [patch] MdeModulePkg/EmmcDxe: Don't expose BlockIo interface for RPMB partition
The patch is good to me.
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng
> Tian
> Sent: Wednesday, June 29, 2016 11:18 AM
> To: Wu, Hao A
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] [patch] MdeModulePkg/EmmcDxe: Don't expose BlockIo
> interface for RPMB partition
>
> This change is to avoid UEFI SCT failure as UEFI SCT has no knowledge
> about how to accessing a EMMC RPMB partition.
>
> The user needs to access RPMB partition should get access through
> EFI_SD_MMC_PASS_THRU protocol with authentication key & mac.
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian
> ---
> MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c | 138 +++---
>
> 1 file changed, 45 insertions(+), 93 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> index d3602a5..5040882 100644
> --- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> +++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c
> @@ -443,77 +443,60 @@ InstallProtocolOnPartition (
> //
> // Install BlkIo/BlkIo2/Ssp for the specified partition
> //
> -Status = gBS->InstallMultipleProtocolInterfaces (
> -&Partition->Handle,
> -&gEfiDevicePathProtocolGuid,
> -Partition->DevicePath,
> -&gEfiBlockIoProtocolGuid,
> -&Partition->BlockIo,
> -&gEfiBlockIo2ProtocolGuid,
> -&Partition->BlockIo2,
> -NULL
> -);
> -if (EFI_ERROR (Status)) {
> - goto Error;
> -}
> -
> if (Partition->PartitionType != EmmcPartitionRPMB) {
> - Status = gBS->InstallProtocolInterface (
> + Status = gBS->InstallMultipleProtocolInterfaces (
>&Partition->Handle,
> + &gEfiDevicePathProtocolGuid,
> + Partition->DevicePath,
> + &gEfiBlockIoProtocolGuid,
> + &Partition->BlockIo,
> + &gEfiBlockIo2ProtocolGuid,
> + &Partition->BlockIo2,
>&gEfiEraseBlockProtocolGuid,
> - EFI_NATIVE_INTERFACE,
> - &Partition->EraseBlock
> + &Partition->EraseBlock,
> + NULL
>);
>if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces (
> - &Partition->Handle,
> - &gEfiDevicePathProtocolGuid,
> - Partition->DevicePath,
> - &gEfiBlockIoProtocolGuid,
> - &Partition->BlockIo,
> - &gEfiBlockIo2ProtocolGuid,
> - &Partition->BlockIo2,
> - NULL
> - );
> goto Error;
>}
> -}
>
> -if (((Partition->PartitionType == EmmcPartitionUserData) ||
> -(Partition->PartitionType == EmmcPartitionBoot1) ||
> -(Partition->PartitionType == EmmcPartitionBoot2)) &&
> -((Device->Csd.Ccc & BIT10) != 0)) {
> - Status = gBS->InstallProtocolInterface (
> - &Partition->Handle,
> - &gEfiStorageSecurityCommandProtocolGuid,
> - EFI_NATIVE_INTERFACE,
> - &Partition->StorageSecurity
> - );
> - if (EFI_ERROR (Status)) {
> -gBS->UninstallMultipleProtocolInterfaces (
> - &Partition->Handle,
> - &gEfiDevicePathProtocolGuid,
> - Partition->DevicePath,
> - &gEfiBlockIoProtocolGuid,
> - &Partition->BlockIo,
> - &gEfiBlockIo2ProtocolGuid,
> - &Partition->BlockIo2,
> - &gEfiEraseBlockProtocolGuid,
> - &Partition->EraseBlock,
> - NULL
> - );
> -goto Error;
> + if (((Partition->PartitionType == EmmcPartitionUserData) ||
> + (Partition->PartitionType == EmmcPartitionBoot1) ||
> + (Partition->PartitionType == EmmcPartitionBoot2)) &&
> + ((Device->Csd.Ccc & BIT10) != 0)) {
> +Status = gBS->InstallProtocolInterface (
> +&Partition->
Re: [edk2] [patch 1/2] MdeModulePkg/UefiHiiLib: Add error handling codes when AllocatePool fail
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, July 05, 2016 11:19 AM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Wu, Hao A
> Subject: [patch 1/2] MdeModulePkg/UefiHiiLib: Add error handling codes when
> AllocatePool fail
>
> Cc: Eric Dong
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi
> ---
> MdeModulePkg/Library/UefiHiiLib/HiiLib.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> index 74ccd02..afd9985 100644
> --- a/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> +++ b/MdeModulePkg/Library/UefiHiiLib/HiiLib.c
> @@ -1,9 +1,9 @@
> /** @file
>HII Library implementation that uses DXE protocols and services.
>
> - Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
>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
>
> @@ -463,14 +463,23 @@ HiiGetFormSetFromHiiHandle(
> continue;
>}
>
>if (FormSetBuffer != NULL){
> TempBuffer = AllocateCopyPool (TempSize + ((EFI_IFR_OP_HEADER *)
> OpCodeData)->Length, FormSetBuffer);
> -CopyMem (TempBuffer + TempSize, OpCodeData, ((EFI_IFR_OP_HEADER
> *) OpCodeData)->Length);
> FreePool(FormSetBuffer);
> +FormSetBuffer = NULL;
> +if (TempBuffer == NULL) {
> + Status = EFI_OUT_OF_RESOURCES;
> + goto Done;
> +}
> +CopyMem (TempBuffer + TempSize, OpCodeData,
> ((EFI_IFR_OP_HEADER *) OpCodeData)->Length);
>} else {
> TempBuffer = AllocateCopyPool (TempSize + ((EFI_IFR_OP_HEADER *)
> OpCodeData)->Length, OpCodeData);
> +if (TempBuffer == NULL) {
> + Status = EFI_OUT_OF_RESOURCES;
> + goto Done;
> +}
>}
>TempSize += ((EFI_IFR_OP_HEADER *) OpCodeData)->Length;
>FormSetBuffer = TempBuffer;
>
>Status = EFI_SUCCESS;
> @@ -478,10 +487,11 @@ HiiGetFormSetFromHiiHandle(
>//One form package has one formset, exit current form package to search
> other form package in the packagelist.
>//
>break;
> }
>}
> +Done:
>FreePool (HiiPackageList);
>
>*BufferSize = TempSize;
>*Buffer = (EFI_IFR_FORM_SET *)FormSetBuffer;
>
> --
> 1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch] MdeModulePkg/BootMaintUi: Add error handling codes when AllocatePool fail
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Bi, Dandan
> Sent: Tuesday, July 05, 2016 4:53 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric; Wu, Hao A
> Subject: [patch] MdeModulePkg/BootMaintUi: Add error handling codes when
> AllocatePool fail
>
> The AllocateCopyPool in function ExtractFileNameFromDevicePath
> may return NULL, so need to do error handling. This patch is to
> add error handling codes for function ExtractFileNameFromDevicePath
> and its caller functions.
>
> Cc: Eric Dong
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi
> Reviewed-by: Eric Dong
> ---
> .../BootMaintenanceManagerUiLib/BootMaintenance.c | 5 ++-
> .../BootMaintenanceManagerUiLib/BootOption.c | 42
> --
> .../BootMaintenanceManagerUiLib/UpdatePage.c | 14
> 3 files changed, 35 insertions(+), 26 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> index b35e938..393091f 100644
> ---
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> +++
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance.c
> @@ -377,19 +377,22 @@ ExtractFileNameFromDevicePath (
>ASSERT(DevicePath != NULL);
>
>String = UiDevicePathToStr(DevicePath);
>MatchString = String;
>LastMatch = String;
> + FileName= NULL;
>
>while(MatchString != NULL){
> LastMatch = MatchString + 1;
> MatchString = StrStr(LastMatch,L"\\");
>}
>
>Length = StrLen(LastMatch);
>FileName = AllocateCopyPool ((Length + 1) * sizeof(CHAR16), LastMatch);
> - *(FileName + Length) = 0;
> + if (FileName != NULL) {
> +*(FileName + Length) = 0;
> + }
>
>FreePool(String);
>
>return FileName;
> }
> diff --git
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> index c660c73..890728a 100644
> --- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> +++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOption.c
> @@ -863,33 +863,37 @@ BootFromFile (
>)
> {
>EFI_BOOT_MANAGER_LOAD_OPTION BootOption;
>CHAR16 *FileName;
>
> + FileName = NULL;
> +
>FileName = ExtractFileNameFromDevicePath(FilePath);
> - EfiBootManagerInitializeLoadOption (
> -&BootOption,
> -0,
> -LoadOptionTypeBoot,
> -LOAD_OPTION_ACTIVE,
> -FileName,
> -FilePath,
> -NULL,
> -0
> -);
> - //
> - // Since current no boot from removable media directly is allowed */
> - //
> - gST->ConOut->ClearScreen (gST->ConOut);
> + if (FileName != NULL) {
> +EfiBootManagerInitializeLoadOption (
> + &BootOption,
> + 0,
> + LoadOptionTypeBoot,
> + LOAD_OPTION_ACTIVE,
> + FileName,
> + FilePath,
> + NULL,
> + 0
> + );
> +//
> +// Since current no boot from removable media directly is allowed */
> +//
> +gST->ConOut->ClearScreen (gST->ConOut);
>
> - BmmSetConsoleMode (FALSE);
> - EfiBootManagerBoot (&BootOption);
> - BmmSetConsoleMode (TRUE);
> +BmmSetConsoleMode (FALSE);
> +EfiBootManagerBoot (&BootOption);
> +BmmSetConsoleMode (TRUE);
>
> - FreePool(FileName);
> +FreePool(FileName);
>
> - EfiBootManagerFreeLoadOption (&BootOption);
> +EfiBootManagerFreeLoadOption (&BootOption);
> + }
>
>return FALSE;
> }
>
> /**
> diff --git
> a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
> b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
> index 13a29db..9e79826 100644
> --- a/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
> +++ b/MdeModulePkg/Library/BootMaintenanceManagerUiLib/UpdatePage.c
> @@ -1,9 +1,9 @@
> /** @file
> Dynamically update the pages.
>
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
> 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
>
> @@ -1018,21 +1018,23 @@ UpdateOptionPage(
>)
> {
>CHAR16*String;
>EFI_STRING_ID StringTok
Re: [edk2] [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, February 12, 2019 3:56 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Wang, Jian J; Wu, Hao A; Zhang, Chao B; Gao, Liming
> Subject: [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.
>
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 83
> ---
> 1 file changed, 58 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index ba2583accb..732472bb9c 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, &Root);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>Status = Root->Open (Root, &DirHandle, EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>//
>// Get file count first
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, &FileInfo)
> - ; !EFI_ERROR(Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile)
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, &FileInfo);
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileCount++;
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile);
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>if (FileCount == 0) {
> Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
>
>FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
For me, AllocateZeroPool() should be used here.
Please refer to the reason below.
> + if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> + }
>NoFile = FALSE;
>
>//
>// Get all file info
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, &FileInfo)
> - ; !EFI_ERROR (Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile)
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, &FileInfo);
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> +}
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
If the memory allocation somehow fails during the 'do-while' loop, the
elements within array 'FileInfoBuffer' will not all have valid pointer
values.
So I believe, an 'AllocateZeroPool' should be used above.
With this addressed,
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> - }
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile);
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
>
>if (!DumpCapsuleInfo) {
> -ret
Re: [edk2] [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> -Original Message-
> From: Chen, Chen A
> Sent: Wednesday, February 13, 2019 8:53 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Wang, Jian J; Wu, Hao A; Zhang, Chao B; Gao, Liming
> Subject: [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.
>
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Zhang Chao B
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 87
> ---
> 1 file changed, 60 insertions(+), 27 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index ba2583accb..9fd4af4e55 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, &Root);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>Status = Root->Open (Root, &DirHandle, EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
> Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
>
>//
>// Get file count first
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, &FileInfo)
> - ; !EFI_ERROR(Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile)
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, &FileInfo);
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> }
> -FileCount++;
> - }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile);
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>if (FileCount == 0) {
> Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
>
> - FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
> + FileInfoBuffer = AllocateZeroPool (sizeof (FileInfo) * FileCount);
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> + if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> + }
>NoFile = FALSE;
>
>//
>// Get all file info
>//
> - for ( Status = FileHandleFindFirstFile (DirHandle, &FileInfo)
> - ; !EFI_ERROR (Status) && !NoFile
> - ; Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile)
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> - continue;
> + do {
> +Status = FileHandleFindFirstFile (DirHandle, &FileInfo);
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> + Print (L"Get File Info Fail. Status = %r\n", Status);
> + goto Done;
> +}
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> + FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> - }
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, &NoFile);
> +if (EFI_ERROR (Status)) {
> + Print (L"Get Next File Fail. Status = %r\n", Status);
> + goto Done;
> +}
> + } while (!NoFile);
>
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
>
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
>
>Print(L"The infomation of the capsules:\n");
> @@ -875,27 +897,28 @@ DumpCapsuleFromDisk (
> FileHandle = NULL;
> Status = DirHandle->Open
Re: [edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ray Ni > Sent: Tuesday, February 12, 2019 5:48 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 > BAR isn't restored sometimes > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505 > > v2: fixed all typos in PciBus driver. > changed RomSize to UINT32 and added type cast to PPB MEM32 BAR > Base/Length to avoid using RShiftU64(). For the series: Reviewed-by: Hao Wu Best Regards, Hao Wu > > > Ray Ni (3): > MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 type > MdeModulePkg/PciBus: Correct typos > MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored > sometimes > > MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h | 4 +- > MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c | 14 +-- > MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h | 16 +-- > .../Bus/Pci/PciBusDxe/PciDeviceSupport.c | 20 ++-- > .../Bus/Pci/PciBusDxe/PciDeviceSupport.h | 14 +-- > .../Bus/Pci/PciBusDxe/PciDriverOverride.c | 4 +- > .../Bus/Pci/PciBusDxe/PciDriverOverride.h | 4 +- > .../Bus/Pci/PciBusDxe/PciEnumerator.c | 8 +- > .../Bus/Pci/PciBusDxe/PciEnumerator.h | 8 +- > .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c | 42 +++ > .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h | 16 +-- > .../Bus/Pci/PciBusDxe/PciHotPlugSupport.c | 16 +-- > .../Bus/Pci/PciBusDxe/PciHotPlugSupport.h | 18 +-- > MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c| 16 +-- > MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h| 4 +- > MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 4 +- > .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c | 6 +- > .../Bus/Pci/PciBusDxe/PciOptionRomSupport.h | 4 +- > .../Bus/Pci/PciBusDxe/PciPowerManagement.c| 4 +- > .../Bus/Pci/PciBusDxe/PciPowerManagement.h| 4 +- > .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 113 +- > .../Bus/Pci/PciBusDxe/PciResourceSupport.h| 41 --- > MdeModulePkg/Bus/Pci/PciBusDxe/PciRomTable.h | 7 +- > 23 files changed, 190 insertions(+), 197 deletions(-) > > -- > 2.20.1.windows.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] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
Hello Jeff,
Sorry for the delayed response.
I have verified your patch with the board on my side and it is working
fine. And I saw around 3~4 milliseconds performance boost. So I think the
patch will bring performance benefit to the driver.
Some minor inline comments below:
From: Jeff Brasen [mailto:jbra...@nvidia.com]
Sent: Saturday, February 02, 2019 1:53 AM
To: Wu, Hao A; edk2-devel@lists.01.org
Cc: Edgar Handal
Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
From: Wu, Hao A
Sent: Friday, February 1, 2019 12:54 AM
To: Jeff Brasen; edk2-devel@lists.01.org
Cc: Edgar Handal
Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
> -Original Message-
> From: Jeff Brasen [mailto:jbra...@nvidia.com]
> Sent: Friday, February 01, 2019 3:12 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
>
>
> -----Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:56 PM
> To: Jeff Brasen ; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jeff Brasen
> > Sent: Thursday, January 31, 2019 7:59 AM
> > To: edk2-devel@lists.01.org
> > Cc: Edgar Handal; Jeff Brasen
> > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> > widths
> >
Could you help to file a Bugzilla tracker to state the purpose of this
patch and make a reference in the commit log message here? Thanks.
> > From: Edgar Handal
> >
> > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > accesses from being split up into 8-bit accesses.
> >
> > The SDHCI specification states that the registers shall be accessable
> > in byte, word, and double word accesses.
'accessable' -> 'accessible'.
Also, could you help to quote the detailed context from the SD HCI spec
for the above statement?
Lastly, could you help to add your performance evaluation data in the
commit log message as well?
With the above 3 minor comments handled:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>
> Hi,
>
> Thanks for the contribution. The change seems good to me.
>
> Just curious, if the accesses are always slit into byte(8-bit), is there any
> issue or
> performance impact is encountered during your usage?
>
> It will be helpful to get more information on the purpose of the patch.
> Thanks.
>
> Best Regards,
> Hao Wu
>
> [JMB] We were working with a simulation module that has some issues when
> accessing 16 or 32 bit registers by byte (This should be supported per the
> SDHCI
> specification.), and this patch resolves this while we work on getting the
> model
> fixed. This should also optimize performance as there will less read/write
> instructions (My guess is this is a marginal improvement as most of the SD
> access time would be DMA operations.)
Thanks Jeff,
Got it. May I know is it possible for you to collect some performance data
for the change?
[JMB] Sure, did a several boots on silicon platform and see an average boot
time improvement of 15ms. With a range of 10-20ms and never saw the performance
get worse.
Meanwhile, I will test this patch with the boards I own and try to collect
some data. Please grant me some time for this. Since the current
implementation does not violate the spec, let us evaluate whether better
performance will be brought.
Best Regards,
Hao Wu
>
> Thanks,
> Jeff
>
>
>
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jeff Brasen
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> >
> > 1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > index 5aec8c6..82f4493 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
> >)
> > {
> >EFI_STATUS Status;
> > + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> >
> >if ((PciIo == NULL) || (Data == NULL)) {
> > return EFI_INVALID_PARAMETER;
> >}
> >
> > - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> > -return EFI_INVALID_PARAMETER;
> > +
Re: [edk2] [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
Hi Mateusz,
I found that the patch proposed is actually handling one of the issues
reported in the below BZ tracker:
https://bugzilla.tianocore.org/show_bug.cgi?id=1140
According to the discussion within the tracker, there are 2 fixes needed
for the SdMmcPciHcDxe:
1. Move the clock supply before doing send status
2. More robust handle to the send status CRC error on the switch to HS200
I think the proposed patch is handling the 1st issue listed above.
So could you help to add the below line:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
at the beginning of your commit log message?
Also, please see the below inline comments below:
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Albecki, Mateusz
> Sent: Friday, February 15, 2019 10:45 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [edk2] [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC
> HS400 switch sequence
>
> In eMMC HS400 switch sequence flow eMMC driver attampted
'attampted' -> 'attempted'
> to execute SEND_STATUS just after switching bus timing to high
> speed and before downgrading clock frequency to 52MHz. Since link
> was at that time in incorrect state SEND_STATUS was failing which
> made driver think switch to HS400 failed.
> This change makes driver always change clock frequency after
> switching bus timing and before executing SEND_STATUS.
>
> Change-Id: Ib1f2c78a8693c2a4ef6e1f1b5da2f4133f6210d2
Please help to remove the above 'Change-Id' information.
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 37
> +
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> index 4ef849fd0962..22200f806f26 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> }
>
> /**
> - Switch the clock frequency to the specified value.
> + Switch the bus timing and clock frequency.
>
>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> Controller
>Simplified Spec 3.0 Figure 3-3 for details.
> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
>
> **/
> EFI_STATUS
> -EmmcSwitchClockFreq (
> +EmmcSwitchBusTiming (
Could you help to update the debug messages that include keyword
'EmmcSwitchClockFreq' to 'EmmcSwitchBusTiming' to align with the function
name change?
Best Regards,
Hao Wu
>IN EFI_PCI_IO_PROTOCOL*PciIo,
>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
>IN UINT8 Slot,
> @@ -693,18 +693,6 @@ EmmcSwitchClockFreq (
> return Status;
>}
>
> - Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> with %r\n", Status));
> -return Status;
> - }
> - //
> - // Check the switch operation is really successful or not.
> - //
> - if ((DevStatus & BIT7) != 0) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> -return EFI_DEVICE_ERROR;
> - }
>//
>// Convert the clock freq unit from MHz to KHz.
>//
> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
> return Status;
>}
>
> + Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> with %r\n", Status));
> +return Status;
> + }
> + //
> + // Check the switch operation is really successful or not.
> + //
> + if ((DevStatus & BIT7) != 0) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> +return EFI_DEVICE_ERROR;
> + }
> +
>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> Status = mOverride->NotifyPhase (
>Private->ControllerHandle,
> @@ -799,7 +800,7 @@ EmmcSwitchToHighSpeed (
>}
>
>HsTiming = 1;
> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, Timing,
> ClockFreq);
> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
> Timing, ClockFreq);
>
>return Status;
> }
> @@ -887,7 +888,7 @@ EmmcSwitchToHS200 (
>Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_CL
Re: [edk2] [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
> -Original Message- > From: Dong, Eric > Sent: Monday, February 18, 2019 10:59 AM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Wang, Jian J; Ni, Ray > Subject: RE: [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to > produce SSC PPI > > Hi Hao, > > > -----Original Message- > > From: Wu, Hao A > > Sent: Friday, February 15, 2019 2:24 PM > > To: edk2-devel@lists.01.org > > Cc: Wu, Hao A ; Wang, Jian J > ; > > Ni, Ray ; Dong, Eric > > Subject: [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to > > produce SSC PPI > > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 > > > > For the NvmExpressPei driver, this commit will add codes to produce the > > Storage Security Command PPI if the underlying NVM Express controller > > supports the Security Send and Security Receive commands. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Eric Dong > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf | 10 > +- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h| 58 > ++- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h | 20 > +- > > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h > > | 247 > > MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c | 231 > > +++ > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143 > > +-- > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c | 32 > +- > > > MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c > > | 423 > > 8 files changed, 1075 insertions(+), 89 deletions(-) > > > > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > index 9591572fec..0666e5892b 100644 > > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf > > @@ -2,7 +2,7 @@ > > # The NvmExpressPei driver is used to manage non-volatile memory > > subsystem > > # which follows NVM Express specification at PEI phase. > > # > > -# Copyright (c) 2018, Intel Corporation. All rights reserved. > > +# Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved. > > # > > # This program and the accompanying materials > > # are licensed and made available under the terms and conditions of the > > BSD License > > @@ -30,6 +30,7 @@ > > # > > > > [Sources] > > + DevicePath.c > >DmaMem.c > >NvmExpressPei.c > >NvmExpressPei.h > > @@ -39,6 +40,8 @@ > >NvmExpressPeiHci.h > >NvmExpressPeiPassThru.c > >NvmExpressPeiPassThru.h > > + NvmExpressPeiStorageSecurity.c > > + NvmExpressPeiStorageSecurity.h > > > > [Packages] > >MdePkg/MdePkg.dec > > @@ -54,11 +57,12 @@ > >PeimEntryPoint > > > > [Ppis] > > - gEfiPeiVirtualBlockIoPpiGuid ## PRODUCES > > - gEfiPeiVirtualBlockIo2PpiGuid ## PRODUCES > >gEdkiiPeiNvmExpressHostControllerPpiGuid ## CONSUMES > >gEdkiiIoMmuPpiGuid ## CONSUMES > >gEfiEndOfPeiSignalPpiGuid ## CONSUMES > > + gEfiPeiVirtualBlockIoPpiGuid ## SOMETIMES_PRODUCES > > + gEfiPeiVirtualBlockIo2PpiGuid ## SOMETIMES_PRODUCES > > + gEdkiiPeiStorageSecurityCommandPpiGuid ## > > SOMETIMES_PRODUCES > > > > [Depex] > >gEfiPeiMemoryDiscoveredPpiGuid AND > > diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > index 0135eca6f0..92c3854c6e 100644 > > --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h > > @@ -25,6 +25,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > > > @@ -44,6 +45,7 @@ typedef struct > > _PEI_NVME_CONTROLLER_PRIVATE_DATA > > PEI_NVME_CONTROLLER_PRIVATE_DA > > #include "NvmExpressPeiHci.h" > > #include "NvmExpressPeiPassThru.h" > > #include "NvmExpressPeiBlockIo.h" > > +#include "NvmExpressPeiStorageSecurity.h" > > > > // >
Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
Thanks Mateusz,
Reviewed-by: Hao Wu
And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.
Best Regards,
Hao Wu
> -Original Message-
> From: Albecki, Mateusz
> Sent: Monday, February 18, 2019 7:12 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400
> switch sequence
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
>
> In eMMC HS400 switch sequence flow eMMC driver attempted
> to execute SEND_STATUS just after switching bus timing to high
> speed and before downgrading clock frequency to 52MHz. Since link
> was at that time in incorrect state SEND_STATUS was failing which
> made driver think switch to HS400 failed.
> This change makes driver always change clock frequency after
> switching bus timing and before executing SEND_STATUS.
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
> +
> 1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> index 4ef849fd0962..15db8a87a5c4 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> }
>
> /**
> - Switch the clock frequency to the specified value.
> + Switch the bus timing and clock frequency.
>
>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> Controller
>Simplified Spec 3.0 Figure 3-3 for details.
> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
>
> **/
> EFI_STATUS
> -EmmcSwitchClockFreq (
> +EmmcSwitchBusTiming (
>IN EFI_PCI_IO_PROTOCOL*PciIo,
>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
>IN UINT8 Slot,
> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
>
>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
>if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to hstiming %d
> fails with %r\n", HsTiming, Status));
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to hstiming %d
> fails with %r\n", HsTiming, Status));
> return Status;
>}
>
> - Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> with %r\n", Status));
> -return Status;
> - }
> - //
> - // Check the switch operation is really successful or not.
> - //
> - if ((DevStatus & BIT7) != 0) {
> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> -return EFI_DEVICE_ERROR;
> - }
>//
>// Convert the clock freq unit from MHz to KHz.
>//
> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
> return Status;
>}
>
> + Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Send status fails
> with %r\n", Status));
> +return Status;
> + }
> + //
> + // Check the switch operation is really successful or not.
> + //
> + if ((DevStatus & BIT7) != 0) {
> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: The switch operation
> fails as DevStatus is 0x%08x\n", DevStatus));
> +return EFI_DEVICE_ERROR;
> + }
> +
>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
> Status = mOverride->NotifyPhase (
>Private->ControllerHandle,
> @@ -799,7 +800,7 @@ EmmcSwitchToHighSpeed (
>}
>
>HsTiming = 1;
> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, Timing,
> ClockFreq);
> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
> Timing, ClockFreq);
>
>return Status;
> }
> @@ -887,7 +888,7 @@ EmmcSwitchToHS200 (
>Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_CLOCK_CTRL, sizeof
> (ClockCtrl), &ClockCtrl);
>
>HsTiming = 2;
> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming, Timing,
> ClockFreq);
> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
> Timing, ClockFreq);
>if (EFI_ERROR (Status)) {
> return Status;
>}
> @@ -937,7 +938,7 @@ EmmcSwitchToHS400 (
>// Set to Hight Speed timing and set the clock frequency to a value less
> than
> 52MHz.
>//
>Hs
Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
Thanks Jeff.
Reviewed-by: Hao Wu
And pushed via commit f168816c49e388dcd097dd62d766d63f73aaabb3.
Best Regards,
Hao Wu
> -Original Message-
> From: Jeff Brasen [mailto:jbra...@nvidia.com]
> Sent: Wednesday, February 20, 2019 1:07 AM
> To: edk2-devel@lists.01.org
> Cc: Edgar Handal; Jeff Brasen; Wu, Hao A
> Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
>
> From: Edgar Handal
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1537
>
> Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> accesses from being split up into 8-bit accesses.
>
> The SDHCI specification states that the registers shall be accessible in
> byte, word, and double word accesses. (SD Host Controller Simplified
> Specification 4.20 Section 1.2)
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jeff Brasen
> Cc: Hao A Wu
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
>
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 4c64da3..d73fa10 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -154,19 +154,36 @@ SdMmcHcRwMmio (
>)
> {
>EFI_STATUS Status;
> + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
>
>if ((PciIo == NULL) || (Data == NULL)) {
> return EFI_INVALID_PARAMETER;
>}
>
> - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> -return EFI_INVALID_PARAMETER;
> + switch (Count) {
> +case 1:
> + Width = EfiPciIoWidthUint8;
> + break;
> +case 2:
> + Width = EfiPciIoWidthUint16;
> + Count = 1;
> + break;
> +case 4:
> + Width = EfiPciIoWidthUint32;
> + Count = 1;
> + break;
> +case 8:
> + Width = EfiPciIoWidthUint32;
> + Count = 2;
> + break;
> +default:
> + return EFI_INVALID_PARAMETER;
>}
>
>if (Read) {
> Status = PciIo->Mem.Read (
>PciIo,
> - EfiPciIoWidthUint8,
> + Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> @@ -175,7 +192,7 @@ SdMmcHcRwMmio (
>} else {
> Status = PciIo->Mem.Write (
>PciIo,
> - EfiPciIoWidthUint8,
> + Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> --
> 2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Sunday, February 03, 2019 8:39 PM
> To: Wu, Hao A
> Cc: Jeff Brasen; edk2-devel@lists.01.org; Edgar Handal; Marcin Wojtas
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> IO widths
>
> On Fri, 1 Feb 2019 at 06:55, Wu, Hao A wrote:
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jeff
> > > Brasen
> > > Sent: Thursday, January 31, 2019 7:59 AM
> > > To: edk2-devel@lists.01.org
> > > Cc: Edgar Handal; Jeff Brasen
> > > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit
> IO
> > > widths
> > >
> > > From: Edgar Handal
> > >
> > > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > > accesses from being split up into 8-bit accesses.
> > >
> > > The SDHCI specification states that the registers shall be accessable in
> > > byte, word, and double word accesses.
> >
>
> Acked-by: Ard Biesheuvel
Ard,
Really sorry for missing your 'Acked-by' tag.
It came to me after I pushed the commit.
Sorry again for this.
Best Regards,
Hao Wu
>
> I think we should always prefer accessing MMIO registers using their
> native size, unless there are pressing reasons not to.
>
>
> > Hi,
> >
> > Thanks for the contribution. The change seems good to me.
> >
> > Just curious, if the accesses are always slit into byte(8-bit), is there any
> > issue or performance impact is encountered during your usage?
> >
> > It will be helpful to get more information on the purpose of the patch.
> > Thanks.
> >
> > Best Regards,
> > Hao Wu
> >
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jeff Brasen
> > > ---
> > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> > >
> > > 1 file changed, 21 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > index 5aec8c6..82f4493 100644
> > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > > @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
> > >)
> > > {
> > >EFI_STATUS Status;
> > > + EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> > >
> > >if ((PciIo == NULL) || (Data == NULL)) {
> > > return EFI_INVALID_PARAMETER;
> > >}
> > >
> > > - if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> > > -return EFI_INVALID_PARAMETER;
> > > + switch (Count) {
> > > +case 1:
> > > + Width = EfiPciIoWidthUint8;
> > > + break;
> > > +case 2:
> > > + Width = EfiPciIoWidthUint16;
> > > + Count = 1;
> > > + break;
> > > +case 4:
> > > + Width = EfiPciIoWidthUint32;
> > > + Count = 1;
> > > + break;
> > > +case 8:
> > > + Width = EfiPciIoWidthUint32;
> > > + Count = 2;
> > > + break;
> > > +default:
> > > + return EFI_INVALID_PARAMETER;
> > >}
> > >
> > >if (Read) {
> > > Status = PciIo->Mem.Read (
> > >PciIo,
> > > - EfiPciIoWidthUint8,
> > > + Width,
> > >BarIndex,
> > >(UINT64) Offset,
> > >Count,
> > > @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
> > >} else {
> > > Status = PciIo->Mem.Write (
> > >PciIo,
> > > - EfiPciIoWidthUint8,
> > > + Width,
> > >BarIndex,
> > >(UINT64) Offset,
> > >Count,
> > > --
> > > 2.7.4
> > >
> > > ___
> > > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
> -Original Message-
> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> Sent: Friday, February 22, 2019 4:57 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Albecki, Mateusz
> Subject: Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix
> eMMC HS400 switch sequence
>
> Hi Hao A,
>
> On 2/20/19 2:11 AM, Wu, Hao A wrote:
> > Thanks Mateusz,
> >
> > Reviewed-by: Hao Wu
> > And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.
>
> I think you mean "pushed 'after' commit
> 68c67d3a2a33261e41ff0123129b4e9759617f71".
Yes, the commit should have been 195f673f6270aaf73dd34b75f1da26451b63c316.
It is my mistake.
>
> Commit 68c67d3a2a33261e41ff0123129b4e9759617f71 is:
> "BaseTools: Fixed a code bug for Pcd Array", while
> this patch is commited as 195f673f6270aaf73dd34b75f1da26451b63c316.
>
> Now about this commit 195f673f6270aaf, I think you have an issue with
> your configuration, as the patch author was remplaced from:
> Albecki, Mateusz
> to:
> Albecki, Mateusz (FYDIBOHF23SPDLT)/cn=Recipients/cn=Albecki, Mateusz3be>
You are right, there is something wrong with my local settings when
abstracting the patch. Thanks for pointing out.
Best Regards,
Hao Wu
>
> Regards,
>
> Phil.
>
> >
> > Best Regards,
> > Hao Wu
> >
> >
> >> -Original Message-
> >> From: Albecki, Mateusz
> >> Sent: Monday, February 18, 2019 7:12 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Albecki, Mateusz; Wu, Hao A
> >> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC
> HS400
> >> switch sequence
> >>
> >> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
> >>
> >> In eMMC HS400 switch sequence flow eMMC driver attempted
> >> to execute SEND_STATUS just after switching bus timing to high
> >> speed and before downgrading clock frequency to 52MHz. Since link
> >> was at that time in incorrect state SEND_STATUS was failing which
> >> made driver think switch to HS400 failed.
> >> This change makes driver always change clock frequency after
> >> switching bus timing and before executing SEND_STATUS.
> >>
> >> Cc: Hao Wu
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Albecki Mateusz
> >> ---
> >> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
> >> +
> >> 1 file changed, 20 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> index 4ef849fd0962..15db8a87a5c4 100644
> >> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> >> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
> >> }
> >>
> >> /**
> >> - Switch the clock frequency to the specified value.
> >> + Switch the bus timing and clock frequency.
> >>
> >>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> >> Controller
> >>Simplified Spec 3.0 Figure 3-3 for details.
> >> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
> >>
> >> **/
> >> EFI_STATUS
> >> -EmmcSwitchClockFreq (
> >> +EmmcSwitchBusTiming (
> >>IN EFI_PCI_IO_PROTOCOL*PciIo,
> >>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
> >>IN UINT8 Slot,
> >> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
> >>
> >>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
> >>if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to
> hstiming %d
> >> fails with %r\n", HsTiming, Status));
> >> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to
> hstiming %d
> >> fails with %r\n", HsTiming, Status));
> >> return Status;
> >>}
> >>
> >> - Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
> >> - if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
> >> with %r\n", Status));
> >> -return Status;
> >> - }
> >> - //
> >> - // Check the switch operation is really successful or not.
> >> - //
> >> - if ((DevStatus & BIT7) != 0) {
> >> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch
>
Re: [edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from Opal driver
Thanks all, Series pushed via commits: 94e0dd1afe53d23286968130d836ff0755c17c9b..a3efbc29c45183fe69bcb311c2d974ddc4e7c00a Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Hao Wu > Sent: Thursday, February 21, 2019 8:24 AM > To: edk2-devel@lists.01.org > Cc: Dong, Eric; Wu, Hao A; Yao, Jiewen; Zeng, Star; Laszlo Ersek; Zhang, Chao > B > Subject: [edk2] [PATCH v6 00/13] Split the S3 PEI phase HW init codes from > Opal driver > > The series is also available at: > https://github.com/hwu25/edk2/tree/opal_remodel_v6 > > V6 changes: > For patch 6, rename driver internal function NvmeCheckHcDevicePath() to > NvmeIsHcDevicePathValid(). > > For patch 7, add more comments for purpose of selective NVM Express > controller initialization during S3 resume. > > For patch 8: > * Rename driver internal function AhciCheckHcDevicePath() to > AhciIsHcDevicePathValid(); > * Add more comments for purpose of selective port enumeration/ > initialization on a ATA AHCI controller during S3 resume. > > For patch 6~8, since no functional impact, I still keep the 'Reviewed-by' > from Eric. > > For patch 13, as suggested by Ray, simplifies the logic within PPI > notification callback to directly use the PPI instance provided by the > input parameter of callback function. > > > V5 history: > For patch 11, as suggested by Star: > * Refine the UpdateLockBox() API description comment to be more precise; > * Ensure the parameter for macro 'EFI_SIZE_TO_PAGES' is of type 'UINTN'; > > Since the changes are minor, I still keep the origin 'Reviewed-by' from > Ray and the 'Acked-by' tag from Laszlo. > > For patch 12, sync the UpdateLockBox() API description comment with the > change made in patch 11. > > Since the changes are minor, I still keep the origin 'Reviewed-by' from > Laszlo an Ray. > > For patch 13, additional handling logic to prevent NULL pointer > de-reference, just as what has been done in commit > d72d8561fbe03a64e01c2ad57a93777de4b9ae2f. > > > V4 history: > > As suggested by Laszlo, add a new patch to sync the API description > comment for UpdateLockBox() in file > "OvmfPkg/Library/LockBoxLib/LockBoxLib.c" with its counterparts in > MdeModulePkg. > > For patch 13 (compared with patch 12 in V3), minor type refinement in > structure definition 'OPAL_DEVICE_LOCKBOX_DATA'. > > V3 history: > > For patch 2, reuse the definitions within AtaPassThru protocol header file > to reduce code duplication. > > For patch 4, add detailed comments to illustrate the content that will be > stored in the newly introduced LockBox. > > For patch 6, device path validity check refinement within function > NvmeCheckHcDevicePath(). > > For patch 7: > * Remove a redundant check within function NvmeS3SkipThisController(); > * Replace internal implementation of GetNextDevicePathInstance() with > GetDevicePathInstanceSize(), which avoids unnecessary memory allocation. > > For patch 8: > * Device path validity check refinement within function > AhciCheckHcDevicePath(); > * Remove a redundant check within function AhciS3GetEumeratePorts(); > * Replace internal implementation of GetNextDevicePathInstance() with > GetDevicePathInstanceSize(), which avoids unnecessary memory allocation. > > For patch 11: > * Remove the ASSERT() for memory allocation failure. Since error handling > codes already exist, no new code is added for this; > * Refine the codes to only allocate new SMM buffer when the required > LockBox size is greater than the size of origin pages allocated; > * Add additional parameter check for 'Offset' & 'Length' to prevent > potential numeric overflow. > > > V2 history: > > For patch 8, the new series removes the codes to produce the Block IO PPIs > from the AhciPei driver. > > The task to produce the Block IO services is out of the scope of BZ-1409 > (actually covered by BZ-1483). And we will later propose seperate patch(s) > to address this. > > V1 history: > > For the below 2 types of storage device: > > 1. NVM Express devices; > 2. ATA hard disk devices working under AHCI mode. > > the OpalPassword driver supports auto-unlocking those devices during S3 > resume. > > Current implementation of the OpalPassword driver is handling the device > initialization (using boot script to restore the host controller PCI > configuration space also counts) in the PEI phase during S3 resume by > itself. > > Meanwhile, the NvmExpressPei driver in MdeModulePkg also handles the >
Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross boundary access in Ramdisk
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Tuesday, February 26, 2019 7:45 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross > boundary access in Ramdisk > > On 02/26/19 08:45, Hao Wu wrote: > > V2 changes: > > > > Correct CC list information. > > > > > > V1 history: > > > > The series will resolve a buffer cross boundary access issue during the > > use of RAM disks. It is the mitigation for issue CVE-2018-12180. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Star Zeng > > > > Hao Wu (2): > > MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX) > > MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE > FIX) > > > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h | 6 +++--- > > MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 - > > MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 - > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 20 > ++-- > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c | 5 +++-- > > 5 files changed, 36 insertions(+), 13 deletions(-) > > > > Please put the exact CVE numbers in the subject lines. Thanks. V3 series proposed. Best Regards, Hao Wu > > Thanks > Laszlo > ___ > 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 v2 0/2] MdeModulePkg: Resolve buffer cross boundary access in Ramdisk
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Tuesday, February 26, 2019 7:45 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: Re: [edk2] [PATCH v2 0/2] MdeModulePkg: Resolve buffer cross > boundary access in Ramdisk > > On 02/26/19 08:45, Hao Wu wrote: > > V2 changes: > > > > Correct CC list information. > > > > > > V1 history: > > > > The series will resolve a buffer cross boundary access issue during the > > use of RAM disks. It is the mitigation for issue CVE-2018-12180. > > > > Cc: Jian J Wang > > Cc: Ray Ni > > Cc: Star Zeng > > > > Hao Wu (2): > > MdeModulePkg/PartitionDxe: Ensure blocksize can hold MBR (CVE FIX) > > MdeModulePkg/RamDiskDxe: Ramdisk size be multiple of BlkSize (CVE > FIX) > > > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h | 6 +++--- > > MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 - > > MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 - > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 20 > ++-- > > MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c | 5 +++-- > > 5 files changed, 36 insertions(+), 13 deletions(-) > > > > Please put the exact CVE numbers in the subject lines. Hello Laszlo and Liming, I totally agree the commit subject line should include the CVE number. But I have one feedback that, if the commit is for a CVE fix, is it possible to exempt the commit subject from 71 characters limit? I found it can be hard to summary the commit with the Package/Module plus the CVE number information. Best Regards, Hao Wu > > Thanks > Laszlo > ___ > 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] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Loop Ashish in.
Some comments below.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Wednesday, February 27, 2019 6:59 PM
> To: edk2-devel@lists.01.org; Wu, Hao A
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC
> v3 64-bit systems
>
> The SdMmcPciHcDriverBindingStart function was checking two
> different capability bits in determining whether 64-bit DMA
> modes were supported, one mode is defined in the SDHC version
> 3 specification (using 96-bit descriptors) and another is
> defined in the SDHC version 4 specification (using 128-bit
> descriptors). Since the currently implementation of 64-bit
> ADMA2 only supports the SDHC version 4 implementation it is
> incorrect to check the V3 64-bit capability bit since this
> will activate V4 ADMA2 on V3 controllers.
I remember the commit b5547b9ce97e80c3127682a2a5d4b9bd14af353e from Ashish
only handles the controllers with version greater or equal to 4.00.
And the ADMA2 (96-bit Descriptor) mode for V3 controllers is selected by
setting the 'DMA Select' filed in the Host Control 1 Register to 11b. But
the currently behavior of the driver is setting the field to 10b, which I
think will not switch to the ADMA2 (96-bit Descriptor) mode for V3.
Maybe there is something I miss here. Could you help to provide some more
detail on the issue you met? Thanks.
Best Regards,
Hao Wu
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eugene Cohen
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..5bc91c5 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -666,8 +666,7 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if (Private->Capability[Slot].SysBus64V4 == 0) {
>Support64BitDma = FALSE;
> }
>
> --
> 2.7.4
> ___
> 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] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
Hi Eugene, Ashish and Ard Sorry for the delayed response, I was out of office in the previous several days. According to the discussion, my understanding is that (quote the comments from Ard): > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute > 1. If the device does not support it; > 2. If the driver does not implement the 64-bit DMA mode that the device does >support. Thus, for the current implementation of the SdMmcPciHcDxe driver (including the V4 ADMA descriptor support from Ashish): * The driver should set the DUAL_ADDRESS_CYCLE attribute only when 'SysBus64V4' bit set, because of the statement 2 above. And for the previous implementation (before the change from Ashish): * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since the implementation was written to support only the 32b ADMA descriptor. If this is true, I am fine with your proposed fix. Eugene, Could you help to state the reason for the fix a bit more clear in the commit log? Also, I have filed a Bugzilla tracker for this one: https://bugzilla.tianocore.org/show_bug.cgi?id=1583 Could you help to add this information into the commit log as well? Thanks. Best Regards, Hao Wu > -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Friday, March 01, 2019 11:25 PM > To: Ard Biesheuvel; Cohen, Eugene > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Acked-by: Ashish Singhal > > -Original Message- > From: Ard Biesheuvel > Sent: Friday, March 1, 2019 4:39 AM > To: Cohen, Eugene > Cc: Ashish Singhal ; Wu, Hao A > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > SW1Lab.) > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > Ard, > > > > > So before these changes, we were in the exact same situation, but > > > since PC platforms never enable DMA above 4 GB in the first place, > > > nobody ever noticed until we started running this code on arm64 > > > platforms that have no 32-bit addressable DRAM to begin with. > > > > Interesting - I did not realize that there were designs that were crazy > enough to have no addressable DRAM below 4G. > > > > You must be new here :-) > > But seriously, it does make sense for an implementation to, say, put all > peripherals, PCIe resource windows etc in the bottom half and all DRAM in > the top half of a 40-bit address space, which is how the AMD Seattle SoC > ended with its system memory at address 0x80__. > Note that on this platform, we can still use 32-bit DMA if we want to with the > help of the SMMUs, but we haven't wired those up in UEFI (and the generic > host bridge driver did not have the IOMMU hooks at the > time) > > > > The obvious conclusion is that the driver should not set the > > > EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute if the device > does > > > not support it, or, which seems to be our case, if the driver does > > > not implement the 64-bit DMA mode that the driver does support. > > > However, since there are platforms for which bounce buffering is not > > > an option (since there is no 32-bit addressable memory to bounce > > > to), this is not just a performance optimization, and so it would be > > > useful to fix the code so it can drive all 64-bit DMA capable hardware. > > > > Okay, that's a great reason - let's get V3 64b ADMA2 in! > > > > Any objection to committing the original patch in the short term? > > > > not at all > > Acked-by: Ard Biesheuvel > > --- > This email message is for the sole use of the intended recipient(s) and may > contain > confidential information. Any unauthorized review, use, disclosure or > distribution > is prohibited. If you are not the intended recipient, please contact the > sender by > reply email and destroy all copies of the original message. > --- ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
> -Original Message- > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > Sent: Monday, March 04, 2019 12:00 PM > To: Wu, Hao A; Cohen, Eugene; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Hi Hao, > > I agree that there has been a bug all along which got exposed just now. We > should submit the patch as proposed by Eugene. Yes. I will co-work with Eugene to address this soon. > > Also, I have submitted the patch for enabling 64b DMA for V3. Please take > that into consideration once the freeze is over so that we can fix the issue > in > real sense. Sure. I will take a look at your proposed patch. Please grant me some time for the review and test. Best Regards, Hao Wu > > Eugene, > > Please let me know once you have tried my patch on your board. > > Thanks > Ashish > > -Original Message- > From: Wu, Hao A > Sent: Sunday, March 3, 2019 7:39 PM > To: Cohen, Eugene ; Ashish Singhal > ; Ard Biesheuvel > Cc: edk2-devel@lists.01.org; Kim, Sangwoo (??? SW1Lab.) > > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 > 64-bit systems > > Hi Eugene, Ashish and Ard > > Sorry for the delayed response, I was out of office in the previous several > days. > > According to the discussion, my understanding is that (quote the comments > from > Ard): > > > Driver should not set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE > > attribute 1. If the device does not support it; 2. If the driver does > > not implement the 64-bit DMA mode that the device does > >support. > > Thus, for the current implementation of the SdMmcPciHcDxe driver > (including the > V4 ADMA descriptor support from Ashish): > > * The driver should set the DUAL_ADDRESS_CYCLE attribute only when > 'SysBus64V4' > bit set, because of the statement 2 above. > > And for the previous implementation (before the change from Ashish): > > * The driver should not set the DUAL_ADDRESS_CYCLE attribute at all, since > the > implementation was written to support only the 32b ADMA descriptor. > > If this is true, I am fine with your proposed fix. > > > Eugene, > > Could you help to state the reason for the fix a bit more clear in the commit > log? > > Also, I have filed a Bugzilla tracker for this one: > https://bugzilla.tianocore.org/show_bug.cgi?id=1583 > > Could you help to add this information into the commit log as well? Thanks. > > Best Regards, > Hao Wu > > > -Original Message- > > From: Ashish Singhal [mailto:ashishsin...@nvidia.com] > > Sent: Friday, March 01, 2019 11:25 PM > > To: Ard Biesheuvel; Cohen, Eugene > > Cc: Wu, Hao A; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 SW1Lab.) > > Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 > > 64-bit systems > > > > Acked-by: Ashish Singhal > > > > -Original Message- > > From: Ard Biesheuvel > > Sent: Friday, March 1, 2019 4:39 AM > > To: Cohen, Eugene > > Cc: Ashish Singhal ; Wu, Hao A > > ; edk2-devel@lists.01.org; Kim, Sangwoo (김상우 > > SW1Lab.) > > Subject: Re: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 > > 64-bit systems > > > > On Fri, 1 Mar 2019 at 11:54, Cohen, Eugene wrote: > > > > > > Ard, > > > > > > > So before these changes, we were in the exact same situation, but > > > > since PC platforms never enable DMA above 4 GB in the first place, > > > > nobody ever noticed until we started running this code on arm64 > > > > platforms that have no 32-bit addressable DRAM to begin with. > > > > > > Interesting - I did not realize that there were designs that were > > > crazy > > enough to have no addressable DRAM below 4G. > > > > > > > You must be new here :-) > > > > But seriously, it does make sense for an implementation to, say, put > > all peripherals, PCIe resource windows etc in the bottom half and all > > DRAM in the top half of a 40-bit address space, which is how the AMD > > Seattle SoC ended with its system memory at address 0x80__. > > Note that on this platform, we can still use 32-bit DMA if we want to > > with the help of the SMMUs, but we haven't wired those up in UEFI (and > > the generic host bridge driver did not have the IOMMU hooks at the > > time) > > > > > > The obvious conclusion is that the driver should not set the > > > > EFI_PCI_IO_ATTRIB
Re: [edk2] [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems
> -Original Message- > From: Wu, Hao A > Sent: Tuesday, March 05, 2019 9:14 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; Eugene Cohen; Ard Biesheuvel; Ashish Singhal > Subject: [PATCH v2 0/1] MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC > v3 64-bit systems Since Ashish already posted a patch to add the 64-bit System Address support for V3 mode SDHC: https://www.mail-archive.com/edk2-devel@lists.01.org/msg52057.html I think this patch can be dropped. But since Ashish's patch above is considered as a new feature addition, it will be pushed (if passes the review process) after the 19`Q1 release tag. So Eugene, Ard and Ashish, do you have concern on this? Best Regards, Hao Wu > > V2 changes: > > On behalf of Eugene, V2 patch does not have functional changes compared > with V1, only the reference Bugzilla tracker link is added in the commit > log message. > > I added the previous 'Ack' tag from Ard and Ashish, I added my > 'Reviewed-by' as well. > > Cc: Eugene Cohen > Cc: Ard Biesheuvel > Cc: Ashish Singhal > > Cohen, Eugene (1): > MdeModulePkg/SdMmcPciHcDxe: Fix DMA on SDHC v3 64-bit systems > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > -- > 2.12.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Hi Ashish,
One thing to confirm, for the updated checks within
SdMmcPciHcDriverBindingStart():
> if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> Private->Capability[Slot].SysBus64V3 == 0) ||
> (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
When the SDHC with version greater than 4.10, the check is only performed
against the 'SysBus64V4' bit. My understanding of the purpose is that:
1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
that the possible support case is both or neither.
2. The spec states that SDHC with version greater than 4.10 divides the V3
mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
V3 mode support can be optional.
So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
when HC version >= 4.10. Is that right?
I verified the patch on SDHC version 3.00 with 64-bit System Address
Support. Hope more configurations are available for testing on Eugene's
side.
Besides, some minor comments below:
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Saturday, March 02, 2019 2:30 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
Please help to add the below Bugzilla tracker for reference:
https://bugzilla.tianocore.org/show_bug.cgi?id=1583
I have updated the above tracker to match the purpose of the proposed
patch.
>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 ++-
> 4 files changed, 170 insertions(+), 74 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..68d8a5c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms a
Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Ashish,
Thanks for the contribution.
Reviewed-by: Hao Wu
I will push this one after the release tag is created.
Best Regards,
Hao Wu
> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Wednesday, March 06, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Driver was supporting only 32b DMA support for V3 controllers. Add
> support for 64b DMA as well for completeness.
>
> For V4.0 64b support, driver was looking at incorrect capability
> register bit. Fix for that is present as well.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ashish Singhal
> ---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 189
> ++---
> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 +++-
> 4 files changed, 161 insertions(+), 73 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> index b474f8d..9b7b88c 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> // If any of the slots does not support 64b system bus
> // do not enable 64b DMA in the PCI layer.
> //
> -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> -Private->Capability[Slot].SysBus64V4 == 0) {
> +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> + Private->Capability[Slot].SysBus64V3 == 0) ||
> +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> + Private->Capability[Slot].SysBus64V4 == 0)) {
>Support64BitDma = FALSE;
> }
>
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> index 1bb701a..8846fde 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> @@ -2,7 +2,7 @@
>
>Provides some data structure definitions used by the SD/MMC host
> controller driver.
>
> -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2015, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -145,13 +145,15 @@ typedef struct {
>EFI_PHYSICAL_ADDRESSDataPhy;
>VOID*DataMap;
>SD_MMC_HC_TRANSFER_MODE Mode;
> + SD_MMC_HC_ADMA_LENGTH_MODE AdmaLengthMode;
>
>EFI_EVENT Event;
>BOOLEAN Started;
>UINT64 Timeout;
>
>SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
> - SD_MMC_HC_ADMA_64_DESC_LINE *Adma64Desc;
> + SD_MMC_HC_ADMA_64_V3_DESC_LINE *Adma64V3Desc;
> + SD_MMC_HC_ADMA_64_V4_DESC_LINE *Adma64V4Desc;
>EFI_PHYSICAL_ADDRESSAdmaDescPhy;
>VOID*AdmaMap;
>UINT32 AdmaPages;
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index d73fa10..6fefed1 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -6,7 +6,7 @@
>
>It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer use.
>
> - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
>Copyright (c) 2015 - 2019, Intel Corporation.
Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Thursday, March 07, 2019 8:54 AM
> To: Ashish Singhal; Wu, Hao A; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b
> DMA Support
>
> Tested-by: Eugene Cohen
Eugene,
Thanks for the testing. Really appreciate your help.
Best Regards,
Hao Wu
>
> Thanks again.
>
> From: Ashish Singhal
> Sent: Wednesday, March 6, 2019 4:07 PM
> To: Cohen, Eugene ; Wu, Hao A ;
> edk2-devel@lists.01.org
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Hi Eugene,
>
> Thanks for confirming. Can you please validate the v2 patch I sent as well for
> completeness?
>
> Thanks
> Ashish
>
> From: Cohen, Eugene mailto:eug...@hp.com>>
> Sent: Wednesday, March 6, 2019 4:05 PM
> To: Wu, Hao A mailto:hao.a...@intel.com>>; Ashish
> Singhal mailto:ashishsin...@nvidia.com>>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
>
> Ø I verified the patch on SDHC version 3.00 with 64-bit System Address
> Ø Support. Hope more configurations are available for testing on Eugene's
> Ø side.
>
> This patch works for us. Tested that the V3 64-bit DMA works and verified
> that addresses above 4GB DMA correctly.
>
> Thanks for putting this together.
>
> Feel free to add my Tested-By.
>
> Eugene
>
> From: Wu, Hao A mailto:hao.a...@intel.com>>
> Sent: Tuesday, March 5, 2019 8:01 PM
> To: Ashish Singhal
> mailto:ashishsin...@nvidia.com>>; edk2-
> de...@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Cohen, Eugene mailto:eug...@hp.com>>
> Subject: RE: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Hi Ashish,
>
> One thing to confirm, for the updated checks within
> SdMmcPciHcDriverBindingStart():
>
> > if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300 &&
> > Private->Capability[Slot].SysBus64V3 == 0) ||
> > (Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400 &&
> > Private->Capability[Slot].SysBus64V3 == 0) ||
> > (Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410 &&
> > Private->Capability[Slot].SysBus64V4 == 0)) {
> > Support64BitDma = FALSE;
> > }
>
> When the SDHC with version greater than 4.10, the check is only performed
> against the 'SysBus64V4' bit. My understanding of the purpose is that:
>
> 1. For SDHC with version 4.00, the support of V3 mode and V4 mode of
> 64-bit System Address are reflect by bit 'SysBus64V3'. Thus, I can infer
> that the possible support case is both or neither.
>
> 2. The spec states that SDHC with version greater than 4.10 divides the V3
> mode and V4 mode support into 2 bits (SysBus64V3, SysBus64V4) so that the
> V3 mode support can be optional.
>
> So based on 1 & 2, we do not even bother to check the 'SysBus64V3' bit
> when HC version >= 4.10. Is that right?
>
>
> I verified the patch on SDHC version 3.00 with 64-bit System Address
> Support. Hope more configurations are available for testing on Eugene's
> side.
>
>
> Besides, some minor comments below:
>
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Saturday, March 02, 2019 2:30 AM
> > To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Wu, Hao A; eug...@hp.com<mailto:eug...@hp.com>; Ashish Singhal
> > Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> > Support
>
> Please help to add the below Bugzilla tracker for reference:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1583<https://bugzilla.tianoc
> ore.org/show_bug.cgi?id=1583>
>
> I have updated the above tracker to match the purpose of the proposed
> patch.
>
>
> >
> > Driver was supporting only 32b DMA support for V3 controllers. Add
> > support for 64b DMA as well for completeness.
> >
> > For V4.0 64b support, driver was looking at incorrect capability
> > register bit. Fix for that is present as well.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> mailto:ashishsin...@nvidia.com>>
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 199
> > ++---
Re: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver
Quick comment, please add the CVE number in the patch subject. Liming has already documented the new rule for this kind of fix: https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ray Ni > Sent: Friday, March 08, 2019 10:21 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver > > Ray Ni (2): > MdeModulePkg/HiiDatabase: Fix potential integer overflow > MdeModulePkg/HiiImage: Fix stack overflow when corrupted BMP is > parsed > > MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 130 > ++ > 1 file changed, 105 insertions(+), 25 deletions(-) > > -- > 2.20.1.windows.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 v2 1/2] MdeModulePkg/HiiDatabase: Fix potential integer overflow (CVE-2018-12181)
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Ni, Ray
> Sent: Friday, March 08, 2019 10:35 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan; Wu, Hao A
> Subject: [PATCH v2 1/2] MdeModulePkg/HiiDatabase: Fix potential integer
> overflow (CVE-2018-12181)
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1135
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ray Ni
> Cc: Dandan Bi
> Cc: Hao A Wu
> ---
> MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 126
> ++
> 1 file changed, 103 insertions(+), 23 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> index 71ebc559c0..80a4ec1114 100644
> --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
> @@ -16,6 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "HiiDatabase.h"
>
> +#define MAX_UINT240xFF
>
> /**
>Get the imageid of last image block: EFI_HII_IIBT_END_BLOCK when input
> @@ -651,8 +652,16 @@ HiiNewImage (
>
>EfiAcquireLock (&mHiiDatabaseLock);
>
> - NewBlockSize = sizeof (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof
> (EFI_HII_RGB_PIXEL) +
> - BITMAP_LEN_24_BIT ((UINT32) Image->Width, Image->Height);
> + //
> + // Calcuate the size of new image.
> + // Make sure the size doesn't overflow UINT32.
> + // Note: 24Bit BMP occpuies 3 bytes per pixel.
> + //
> + NewBlockSize = (UINT32)Image->Width * Image->Height;
> + if (NewBlockSize > (MAX_UINT32 - (sizeof
> (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof (EFI_HII_RGB_PIXEL))) / 3) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> + NewBlockSize = NewBlockSize * 3 + (sizeof
> (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof (EFI_HII_RGB_PIXEL));
>
>//
>// Get the image package in the package list,
> @@ -671,6 +680,18 @@ HiiNewImage (
> //
> // Update the package's image block by appending the new block to the
> end.
> //
> +
> +//
> +// Make sure the final package length doesn't overflow.
> +// Length of the package header is represented using 24 bits. So MAX
> length is MAX_UINT24.
> +//
> +if (NewBlockSize > MAX_UINT24 - ImagePackage-
> >ImagePkgHdr.Header.Length) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +//
> +// Because ImagePackage->ImageBlockSize < ImagePackage-
> >ImagePkgHdr.Header.Length,
> +// So (ImagePackage->ImageBlockSize + NewBlockSize) <= MAX_UINT24
> +//
> ImageBlocks = AllocatePool (ImagePackage->ImageBlockSize +
> NewBlockSize);
> if (ImageBlocks == NULL) {
>EfiReleaseLock (&mHiiDatabaseLock);
> @@ -701,6 +722,13 @@ HiiNewImage (
> PackageListNode->PackageListHdr.PackageLength += NewBlockSize;
>
>} else {
> +//
> +// Make sure the final package length doesn't overflow.
> +// Length of the package header is represented using 24 bits. So MAX
> length is MAX_UINT24.
> +//
> +if (NewBlockSize > MAX_UINT24 - (sizeof
> (EFI_HII_IMAGE_PACKAGE_HDR) + sizeof (EFI_HII_IIBT_END_BLOCK))) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> //
> // The specified package list does not contain image package.
> // Create one to add this image block.
> @@ -902,8 +930,11 @@ IGetImage (
> // Use the common block code since the definition of these structures is
> the same.
> //
> CopyMem (&Iibt1bit, CurrentImageBlock, sizeof
> (EFI_HII_IIBT_IMAGE_1BIT_BLOCK));
> -ImageLength = sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL) *
> - ((UINT32) Iibt1bit.Bitmap.Width * Iibt1bit.Bitmap.Height);
> +ImageLength = (UINTN) Iibt1bit.Bitmap.Width * Iibt1bit.Bitmap.Height;
> +if (ImageLength > MAX_UINTN / sizeof
> (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)) {
> + return EFI_OUT_OF_RESOURCES;
> +}
> +ImageLength *= sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL);
> Image->Bitmap = AllocateZeroPool (ImageLength);
> if (Image->Bitmap == NULL) {
>return EFI_OUT_OF_RESOURCES;
> @@ -952,9 +983,13 @@ IGetImage (
> // fall through
> //
>case EFI_HII_IIBT_IMAGE_24BIT:
> -Width = ReadUnaligned16 ((VOID *)
> &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK *) CurrentImageBlock)-
> >Bitmap.Width);
> +Width = ReadUnaligned16 ((VOID *)
> &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK *) CurrentImageBlock)-
> >Bitmap.Width);
> Height = ReadUnaligned16 ((VOID *)
> &((EFI_HII_IIBT_IMAGE_
Re: [edk2] [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA Support
Ashish and Eugene,
The patch has been pushed as commit:
690d60c0ada5ff137c84982220b3fdd112697aa3
Thanks a lot for the contribution and testing effort.
Best Regards,
Hao Wu
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, March 07, 2019 9:33 AM
> To: Ashish Singhal; edk2-devel@lists.01.org
> Cc: eug...@hp.com
> Subject: RE: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> Support
>
> Ashish,
>
> Thanks for the contribution.
> Reviewed-by: Hao Wu
>
> I will push this one after the release tag is created.
>
> Best Regards,
> Hao Wu
>
>
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Wednesday, March 06, 2019 10:05 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wu, Hao A; eug...@hp.com; Ashish Singhal
> > Subject: [PATCH v2] MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA
> > Support
> >
> > Driver was supporting only 32b DMA support for V3 controllers. Add
> > support for 64b DMA as well for completeness.
> >
> > For V4.0 64b support, driver was looking at incorrect capability
> > register bit. Fix for that is present as well.
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ashish Singhal
> > ---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 10 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 6 +-
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 189
> > ++---
> > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 29 +++-
> > 4 files changed, 161 insertions(+), 73 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > index b474f8d..9b7b88c 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
> > @@ -6,7 +6,7 @@
> >
> >It would expose EFI_SD_MMC_PASS_THRU_PROTOCOL for upper layer
> use.
> >
> > - Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> > + Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> >Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of the
> BSD
> > License
> > @@ -666,8 +666,12 @@ SdMmcPciHcDriverBindingStart (
> > // If any of the slots does not support 64b system bus
> > // do not enable 64b DMA in the PCI layer.
> > //
> > -if (Private->Capability[Slot].SysBus64V3 == 0 &&
> > -Private->Capability[Slot].SysBus64V4 == 0) {
> > +if ((Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_300
> &&
> > + Private->Capability[Slot].SysBus64V3 == 0) ||
> > +(Private->ControllerVersion[Slot] == SD_MMC_HC_CTRL_VER_400
> &&
> > + Private->Capability[Slot].SysBus64V3 == 0) ||
> > +(Private->ControllerVersion[Slot] >= SD_MMC_HC_CTRL_VER_410
> &&
> > + Private->Capability[Slot].SysBus64V4 == 0)) {
> >Support64BitDma = FALSE;
> > }
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > index 1bb701a..8846fde 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
> > @@ -2,7 +2,7 @@
> >
> >Provides some data structure definitions used by the SD/MMC host
> > controller driver.
> >
> > -Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> > +Copyright (c) 2018-2019, NVIDIA CORPORATION. All rights reserved.
> > Copyright (c) 2015, Intel Corporation. All rights reserved.
> > This program and the accompanying materials
> > are licensed and made available under the terms and conditions of the BSD
> > License
> > @@ -145,13 +145,15 @@ typedef struct {
> >EFI_PHYSICAL_ADDRESSDataPhy;
> >VOID*DataMap;
> >SD_MMC_HC_TRANSFER_MODE Mode;
> > + SD_MMC_HC_ADMA_LENGTH_MODE AdmaLengthMode;
> >
> >EFI_EVENT Event;
> >BOOLEAN Started;
> >UINT64 Timeout;
> >
> >SD_MMC_HC_ADMA_32_DESC_LINE *Adma32Desc;
&
Re: [edk2] [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA vs PA ambiguity
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, March 11, 2019 11:36 PM > To: edk2-devel@lists.01.org > Cc: Ard Biesheuvel; Wang, Jian J; Wu, Hao A; Zeng, Star; Kinney, Michael D; > Gao, Liming; Achin Gupta; Yao, Jiewen; Supreeth Venkatesh; Jagadeesh Ujja > Subject: [PATCH 0/4] MdeModulePkg, StandaloneMmPkg: work around VA > vs PA ambiguity > > This series proposes one possible approach to work around the issue that the > traditional MM and standalone MM implement versions of the communicate > protocol > that are fundamentally incompatible from the point of view of the caller. > > In traditional MM, the MM communicate protocol takes a physical pointer for > the buffer, so that the SMM execution context can access the memory > directly > without having to translate it according to the translation regime of the > caller. > > In standalone MM, the buffer that is shared with the MM context is > preallocated, > and so it is up to the implementation of the MM communicate protocol to > copy the > data from the caller allocated buffer into the preallocated shared buffer. In > order to be able to do so, the DXE driver needs to copy the contents, and for > this it needs to know the virtual address not the physical address. > > So this means we have two incompatible versions of the same protocol, and > given > that we have even re-used the EFI_SMM_COMMUNICATE_PROTOCOL GUID > for the new > EFI_MM_COMMUNICATE_PROTOCOL, we cannot distinguish > programmatically between a > MM context that takes physical addresses vs one that takes virtual ones. > > Since this is known at build time, one way to deal with this is to have two > different implementations of a library that defines an abstract > MmCommunicate() > function, allowing the correct implementation to be selected at integration > time. Hello Ard, It seems to me that for platforms that include the VariableSmmRuntimeDxe driver, they need to add the 'MmCommunicateLib' dependency. Please grant us some time to evaluate this proposal and its impact. We will inform you as soon as there is a result. Thanks. Best Regards, Hao Wu > > Cc: Jian J Wang > Cc: Hao Wu > Cc: Star Zeng > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Achin Gupta > Cc: Jiewen Yao > Cc: Supreeth Venkatesh > Cc: Jagadeesh Ujja > > Ard Biesheuvel (4): > MdeModulePkg: introduce MmCommunicationLib library class > MdeModulePkg: add implementation of MmCommunicateLib > StandaloneMmPkg: add implementation of MmCommunicateLib > MdeModulePkg/VariableSmmRuntimeDxe: switch to MmCommunicateLib > library > > MdeModulePkg/MdeModulePkg.dec > | 4 + > MdeModulePkg/MdeModulePkg.dsc > | 2 + > > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.inf| 51 + > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.i > nf | 4 +- > > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.inf | 51 + > MdeModulePkg/Include/Library/MmCommunicateLib.h > | > 50 + > > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.c | 114 > > MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe. > c| 10 +- > > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.c | 113 +++ > > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.uni| 19 > > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.uni | 19 > 11 files changed, 428 insertions(+), 9 deletions(-) > create mode 100644 > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.inf > create mode 100644 > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.inf > create mode 100644 > MdeModulePkg/Include/Library/MmCommunicateLib.h > create mode 100644 > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.c > create mode 100644 > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.c > create mode 100644 > MdeModulePkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeMmC > ommunicateLib.uni > create mode 100644 > StandaloneMmPkg/Library/RuntimeDxeMmCommunicateLib/RuntimeDxeM > mCommunicateLib.uni > > -- > 2.20.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, March 15, 2019 7:10 PM > To: Wu, Hao A > Cc: edk2-devel@lists.01.org; Justen, Jordan L; Laszlo Ersek; Ni, Ray > Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On Fri, 15 Mar 2019 at 08:16, Hao Wu wrote: > > > > This series will update the OVMF to stop using the ISA drivers within > > IntelFrameworkModulePkg. > > > > As the replacement, a new OVMF Super I/O bus driver has been add which > > will install the Super I/O protocol for ISA serial and PS2 keyboard > > devices. By doing so, these devices can be managed by: > > > > MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf > > MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf > > > > respectively. > > > > Just a couple of notes from my side - I'm sure Laszlo will have a much > longer list :-) > > - Dropping the floppy driver is fine with me. > - What is OVMF specific about this driver? Is it only the hardcoded > list of COM1/COM2/PS2 keyboard? If so, should we split this into a > driver and a library class, where the driver lives in MdeModulePkg, > and the library is implemented in the context of OVMF? Hello Ard, I think the special thing for this one is that: For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I know, the SIO chip exists on other platforms. The driver proposed here simulates the behavior of an SIO chip. IMO, if we find more platforms that do not have a SIO chip, we can convert the driver into a general one. Also, for the implementation of the services in the Super I/O protocol, the proposed driver just does the minimal effort in order to support the serial/PS2 keyboard. > - Regardless of the previous, adding the new driver should be a patch > of its own. Agree. I will adopt the detailed approach suggested by Jordan for this one. Thanks for the feedback. > - I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2) Thanks for the catch. I will address this comment typo in the next version of the series. I will wait a little longer to see if Laszlo has additional comments/feedbacks on this. Best Regards, Hao Wu > > > > > > > Tests done: > > A. GCC5 & VS2015x86 tool chains build pass > > B. Launch QEMU (2.4.50, Windows) with command: > >> qemu-system-x86_64.exe -pflash \OVMF.fd -serial > file:1.txt -serial file:2.txt > > > >Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under > Shell > >using command 'devtree'; > > > >Both the serials and PS2 keyboard are working fine; > > > > Cc: Jordan Justen > > Cc: Laszlo Ersek > > Cc: Ard Biesheuvel > > Cc: Ray Ni > > > > Hao Wu (2): > > OvmfPkg: Drop the ISA Floppy device support > > OvmfPkg: Add an Super IO bus driver to replace the current ISA support > > > > OvmfPkg/OvmfPkgIa32.dsc | 10 +- > > OvmfPkg/OvmfPkgIa32X64.dsc| 10 +- > > OvmfPkg/OvmfPkgX64.dsc| 10 +- > > OvmfPkg/OvmfPkgIa32.fdf | 10 +- > > OvmfPkg/OvmfPkgIa32X64.fdf| 10 +- > > OvmfPkg/OvmfPkgX64.fdf| 10 +- > > OvmfPkg/SioBusDxe/SioBusDxe.inf | 54 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++ > > OvmfPkg/SioBusDxe/SioService.h| 221 +++ > > OvmfPkg/SioBusDxe/ComponentName.c | 167 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.c | 622 > > OvmfPkg/SioBusDxe/SioService.c| 405 + > > OvmfPkg/SioBusDxe/SioBusDxe.uni | 21 + > > 13 files changed, 1846 insertions(+), 36 deletions(-) > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.inf > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.h > > create mode 100644 OvmfPkg/SioBusDxe/SioService.h > > create mode 100644 OvmfPkg/SioBusDxe/ComponentName.c > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.c > > create mode 100644 OvmfPkg/SioBusDxe/SioService.c > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.uni > > > > -- > > 2.12.0.windows.1 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jordan Justen > Sent: Saturday, March 16, 2019 2:17 AM > To: Ard Biesheuvel; Wu, Hao A > Cc: edk2-devel@lists.01.org; Laszlo Ersek > Subject: Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 2019-03-15 04:09:56, Ard Biesheuvel wrote: > > On Fri, 15 Mar 2019 at 08:16, Hao Wu wrote: > > > > > > This series will update the OVMF to stop using the ISA drivers within > > > IntelFrameworkModulePkg. > > > > > > As the replacement, a new OVMF Super I/O bus driver has been add > which > > > will install the Super I/O protocol for ISA serial and PS2 keyboard > > > devices. By doing so, these devices can be managed by: > > > > > > MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf > > > MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf > > > > > > respectively. > > > > > > > Just a couple of notes from my side - I'm sure Laszlo will have a much > > longer list :-) > > > > - Dropping the floppy driver is fine with me. > > - What is OVMF specific about this driver? Is it only the hardcoded > > list of COM1/COM2/PS2 keyboard? If so, should we split this into a > > driver and a library class, where the driver lives in MdeModulePkg, > > and the library is implemented in the context of OVMF? > > - Regardless of the previous, adding the new driver should be a patch > > of its own. > > Yeah. I think the first patch should add the new driver, and update > the .dsc files to build the new driver. But, don't update the .fdf, so > there shouldn't be a functional change to the OVMF output after the > first patch. > > Then the second patch can modify the .dsc and .fdf files to swap out > the drivers. Hello Jordan, Agree. I will follow your suggestion in the next version of the patch. Thanks for the feedback. Best Regards, Hao Wu > > -Jordan > > > - I spotted an incorrect reference to PCI_IO_DEV in a comment (patch #2) > > > > > > > > > > > > Tests done: > > > A. GCC5 & VS2015x86 tool chains build pass > > > B. Launch QEMU (2.4.50, Windows) with command: > > >> qemu-system-x86_64.exe -pflash \OVMF.fd -serial > file:1.txt -serial file:2.txt > > > > > >Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under > Shell > > >using command 'devtree'; > > > > > >Both the serials and PS2 keyboard are working fine; > > > > > > Cc: Jordan Justen > > > Cc: Laszlo Ersek > > > Cc: Ard Biesheuvel > > > Cc: Ray Ni > > > > > > Hao Wu (2): > > > OvmfPkg: Drop the ISA Floppy device support > > > OvmfPkg: Add an Super IO bus driver to replace the current ISA support > > > > > > OvmfPkg/OvmfPkgIa32.dsc | 10 +- > > > OvmfPkg/OvmfPkgIa32X64.dsc| 10 +- > > > OvmfPkg/OvmfPkgX64.dsc| 10 +- > > > OvmfPkg/OvmfPkgIa32.fdf | 10 +- > > > OvmfPkg/OvmfPkgIa32X64.fdf| 10 +- > > > OvmfPkg/OvmfPkgX64.fdf| 10 +- > > > OvmfPkg/SioBusDxe/SioBusDxe.inf | 54 ++ > > > OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++ > > > OvmfPkg/SioBusDxe/SioService.h| 221 +++ > > > OvmfPkg/SioBusDxe/ComponentName.c | 167 ++ > > > OvmfPkg/SioBusDxe/SioBusDxe.c | 622 > > > OvmfPkg/SioBusDxe/SioService.c| 405 + > > > OvmfPkg/SioBusDxe/SioBusDxe.uni | 21 + > > > 13 files changed, 1846 insertions(+), 36 deletions(-) > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.inf > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.h > > > create mode 100644 OvmfPkg/SioBusDxe/SioService.h > > > create mode 100644 OvmfPkg/SioBusDxe/ComponentName.c > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.c > > > create mode 100644 OvmfPkg/SioBusDxe/SioService.c > > > create mode 100644 OvmfPkg/SioBusDxe/SioBusDxe.uni > > > > > > -- > > > 2.12.0.windows.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 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] MdeModulePkg/PiSmmCore: Control S3 related functionality with flag.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Eric Dong
> Sent: Tuesday, March 05, 2019 10:07 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch] MdeModulePkg/PiSmmCore: Control S3 related
> functionality with flag.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1590
>
> Use PcdAcpiS3Enable to control whether need to enable S3 related
> functionality
The above line does not pass the PatchCheck.py tool. Please help to
re-format it.
Also, please help to update the copyright year for the modified files.
With the above things handled,
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> in Pi SMM Core.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 70
> ++-
> MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
> 2 files changed, 51 insertions(+), 20 deletions(-)
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> index d0bc65b564..bd19803c37 100644
> --- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> +++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.c
> @@ -77,6 +77,12 @@ BOOLEAN mInLegacyBoot = FALSE;
> //
> BOOLEAN mDuringS3Resume = FALSE;
>
> +//
> +// Flag to determine if platform enabled S3.
> +// Get the value from PcdAcpiS3Enable.
> +//
> +BOOLEAN mAcpiS3Enable = FALSE;
> +
> //
> // Table of SMI Handlers that are registered by the SMM Core when it is
> initialized
> //
> @@ -87,6 +93,13 @@ SMM_CORE_SMI_HANDLERS
> mSmmCoreSmiHandlers[] = {
>{ SmmExitBootServicesHandler, &gEfiEventExitBootServicesGuid, NULL,
> FALSE },
>{ SmmReadyToBootHandler, &gEfiEventReadyToBootGuid, NULL,
> FALSE },
>{ SmmEndOfDxeHandler, &gEfiEndOfDxeEventGroupGuid, NULL,
> TRUE },
> + { NULL, NULL,NULL,
> FALSE }
> +};
> +
> +//
> +// Table of SMI Handlers that are registered by the SMM Core when it is
> initialized
> +//
> +SMM_CORE_SMI_HANDLERS mSmmCoreS3SmiHandlers[] = {
>{ SmmS3SmmInitDoneHandler,&gEdkiiS3SmmInitDoneGuid,NULL,
> FALSE },
>{ SmmEndOfS3ResumeHandler,&gEdkiiEndOfS3ResumeGuid,NULL,
> FALSE },
>{ NULL, NULL,NULL,
> FALSE }
> @@ -445,28 +458,30 @@ SmmEndOfDxeHandler (
> NULL
> );
>
> - //
> - // Locate SmmSxDispatch2 protocol.
> - //
> - Status = SmmLocateProtocol (
> - &gEfiSmmSxDispatch2ProtocolGuid,
> - NULL,
> - (VOID **)&SxDispatch
> - );
> - if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
> + if (mAcpiS3Enable) {
> //
> -// Register a S3 entry callback function to
> -// determine if it will be during S3 resume.
> +// Locate SmmSxDispatch2 protocol.
> //
> -EntryRegisterContext.Type = SxS3;
> -EntryRegisterContext.Phase = SxEntry;
> -Status = SxDispatch->Register (
> - SxDispatch,
> - SmmS3EntryCallBack,
> - &EntryRegisterContext,
> - &S3EntryHandle
> - );
> -ASSERT_EFI_ERROR (Status);
> +Status = SmmLocateProtocol (
> + &gEfiSmmSxDispatch2ProtocolGuid,
> + NULL,
> + (VOID **)&SxDispatch
> + );
> +if (!EFI_ERROR (Status) && (SxDispatch != NULL)) {
> + //
> + // Register a S3 entry callback function to
> + // determine if it will be during S3 resume.
> + //
> + EntryRegisterContext.Type = SxS3;
> + EntryRegisterContext.Phase = SxEntry;
> + Status = SxDispatch->Register (
> + SxDispatch,
> + SmmS3EntryCallBack,
> + &EntryRegisterContext,
> + &S3EntryHandle
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
>}
>
>return EFI_SUCCESS;
> @@ -883,6 +898,21 @@ SmmMain (
> ASSERT_EFI_ERROR (Status);
>}
>
> + mAcpiS3Enable = PcdGetBool (PcdAcpiS3Enable);
> + if (mAcpiS3Enable) {
> +//
> +// Register all S3 related SMI Handlers required by the SMM Core
> +//
> +for (Index = 0; mSmmCoreS3SmiHandlers[Index].HandlerType != NULL;
> Index++) {
> + Status = SmiHandlerRegister (
> + mSmmCoreS3SmiHandlers[Index].Handler,
> + mSmmCoreS3SmiHandlers[Index].HandlerType,
> + &mSmmCoreS3SmiHandlers[Index].DispatchHandle
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
> + }
> +
>RegisterSmramProfileHandler ();
>SmramProfileInstallProtocol ();
>
> diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> index f3ece22121..9a31cb79d6 100644
> --- a/MdeMo
Re: [edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, March 18, 2019 8:43 PM
> To: Ming Huang
> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng, Star; Dong,
> Eric; Ni, Ray; dann.fraz...@canonical.com; ard.biesheu...@linaro.org; Kinney,
> Michael D; Gao, Liming; wanghuiqi...@huawei.com;
> huangmin...@huawei.com; zhangjinso...@huawei.com;
> huangda...@hisilicon.com; wai...@126.com; Wang, Jian J; Wu, Hao A; Ni,
> Ray
> Subject: Re: [MdeModulePkg/Library v1 1/1]
> MdeModulePkg/UefiBootManangerLib: Fix exception issue
>
> +MdeModulePkg maintainers (you added MdePkg maintainers to cc)
>
> This looks like an improvement to me.
>
> Am I correct in guessing this behaviour refers to some specific corner
> case of a USB CDROM emulated from a BMC?
>
> On Mon, Feb 25, 2019 at 05:10:52PM +0800, Ming Huang wrote:
> > The system environment: virtual-CDROM(USB interface) via BMC, insert a
> > iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> > to first boot option.
> > With release version bios, disconnecting CDROM when boot to
> > "1 seconds left, Press Esc or F2 to enter Setup"
> > then system will get a exception.
> >
> > The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be
> uninstalled
> > in this situation after print some transfer error. The status will be
> > invalid parameter. This line will get a exception for BlockIo not point
Do you mean 'EFI_INVALID_PARAMETER' is returned from:
Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID **)
&BlockIo);
If so, my guess is that 'Handle' is NULL at this point. An improvement can
be adding a previous check for 'Status' after the ASSERT at:
Status = gBS->LocateDevicePath (&gEfiBlockIoProtocolGuid, &TempDevicePath,
&Handle);
ASSERT_EFI_ERROR (Status);
And leave:
Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID **)
&BlockIo);
ASSERT_EFI_ERROR (Status);
unchanged.
Best Regards,
Hao Wu
> > to right address:
> > AllocatePool (BlockIo->Media->BlockSize)
> > So, here need to judge the status not using ASSERT_EFI_ERROR.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ming Huang
> > ---
> > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index d5957db610d9..c2f1c651b02f 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1068,7 +1068,9 @@ BmExpandMediaDevicePath (
> >// Block IO read/write will success.
> >//
> >Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID
> **) &BlockIo);
> > - ASSERT_EFI_ERROR (Status);
> > + if (EFI_ERROR (Status)) {
>
> It would still be worth including an ASSERT here, to let DEBUG builds
> report on point of failure rather than several steps up the chain.
>
> /
> Leif
>
> > +return NULL;
> > + }
> >Buffer = AllocatePool (BlockIo->Media->BlockSize);
> >if (Buffer != NULL) {
> > BlockIo->ReadBlocks (
> > --
> > 2.9.5
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
> -Original Message- > From: Ming Huang [mailto:ming.hu...@linaro.org] > Sent: Tuesday, March 19, 2019 12:14 PM > To: Wu, Hao A; Leif Lindholm > Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng, Star; Dong, > Eric; Ni, Ray; dann.fraz...@canonical.com; ard.biesheu...@linaro.org; Kinney, > Michael D; Gao, Liming; wanghuiqi...@huawei.com; > huangmin...@huawei.com; zhangjinso...@huawei.com; > huangda...@hisilicon.com; wai...@126.com; Wang, Jian J > Subject: Re: [MdeModulePkg/Library v1 1/1] > MdeModulePkg/UefiBootManangerLib: Fix exception issue > > > > On 3/19/2019 10:25 AM, Wu, Hao A wrote: > >> -Original Message- > >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > >> Sent: Monday, March 18, 2019 8:43 PM > >> To: Ming Huang > >> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Zeng, Star; > >> Dong, > >> Eric; Ni, Ray; dann.fraz...@canonical.com; ard.biesheu...@linaro.org; > Kinney, > >> Michael D; Gao, Liming; wanghuiqi...@huawei.com; > >> huangmin...@huawei.com; zhangjinso...@huawei.com; > >> huangda...@hisilicon.com; wai...@126.com; Wang, Jian J; Wu, Hao A; > Ni, > >> Ray > >> Subject: Re: [MdeModulePkg/Library v1 1/1] > >> MdeModulePkg/UefiBootManangerLib: Fix exception issue > >> > >> +MdeModulePkg maintainers (you added MdePkg maintainers to cc) > >> > >> This looks like an improvement to me. > >> > >> Am I correct in guessing this behaviour refers to some specific corner > >> case of a USB CDROM emulated from a BMC? > >> > >> On Mon, Feb 25, 2019 at 05:10:52PM +0800, Ming Huang wrote: > >>> The system environment: virtual-CDROM(USB interface) via BMC, insert > a > >>> iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM > >>> to first boot option. > >>> With release version bios, disconnecting CDROM when boot to > >>> "1 seconds left, Press Esc or F2 to enter Setup" > >>> then system will get a exception. > >>> > >>> The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be > >> uninstalled > >>> in this situation after print some transfer error. The status will be > >>> invalid parameter. This line will get a exception for BlockIo not point > > > > Do you mean 'EFI_INVALID_PARAMETER' is returned from: > > Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID > **) &BlockIo); > > Yes. > > > > > If so, my guess is that 'Handle' is NULL at this point. An improvement can > > be adding a previous check for 'Status' after the ASSERT at: > > > > Status = gBS->LocateDevicePath (&gEfiBlockIoProtocolGuid, > &TempDevicePath, &Handle); > > ASSERT_EFI_ERROR (Status); > > As my debug output, this 'Status' is seccuss and Handle is not NULL, but > gBS->ConnectController return:Not Found > > Debug output: > [BmExpandMediaDevicePath]:[1056L] Handle=3E3F3D18 BlockIo=3B2757B6 > Media=AFAF6C617470AFAF Status=Success > EhcExecTransfer: transfer failed with 40 > EhcBulkTransfer: error - Device Error, transfer - 40 > . > [UsbOnHubInterrupt]:[632L] SignalEvent (HubIf->HubNotify) > UsbBotExecCommand: UsbBotSendCommand (Device Error) > UsbBootExecCmd: Device Error to Exec 0x0 Cmd (Result = 1) > EhcExecTransfer: transfer failed with 40 > ... > [USBMassDriverBindingStop]:[1010L] Uninstall USB block io, free: > 3E44F218(F0) > [BmExpandMediaDevicePath]:[1064L] Connect Not Found > [BmExpandMediaDevicePath]:[1076L] Handle=3E3F3D18 BlockIo=3B2757B6 > Media=AFAF6C617470AFAF Status=Invalid Parameter Thanks for the debug information, I got it now. The call to the gBS->ConnectController() leads to protocols being uninstalled from 'Handle' and removing 'Handle' from the database. Then within the call to gBS->HandleProtocol(), CoreValidateHandle() returns EFI_INVALID_PARAMETER since the handle cannot be found. I am good with this patch, please help to address Leif's previous comment to keep the ASSERT. Also, I have filed a Bugzilla tracker for this: https://bugzilla.tianocore.org/show_bug.cgi?id=1631 Could you help to add the reference to the above BZ in the commit log message? Thanks. Best Regards, Hao Wu > > Thanks > > > > > And leave: > > > > Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID > **) &BlockIo); > > ASSERT_EFI_ERROR (Status); > > > > unchanged. > > > > > > > Best Regard
Re: [edk2] [Patch MdeModulePkg/Library v1 1/1] MdeModulePkg/UefiBootManangerLib: Fix exception issue
Thanks Ming and Leif.
Reviewed-by: Hao Wu
Patch was committed at 6c27a4d337d0034cecf9f2c05d1f20c342d41e01.
Best Regards,
Hao Wu
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Tuesday, March 19, 2019 9:47 PM
> To: Ming Huang
> Cc: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Wu, Hao A; Kinney,
> Michael D; Gao, Liming; ard.biesheu...@linaro.org;
> wanghuiqi...@huawei.com; huangmin...@huawei.com;
> zhangjinso...@huawei.com; mengfanr...@huawei.com;
> huangda...@hisilicon.com
> Subject: Re: [Patch MdeModulePkg/Library v1 1/1]
> MdeModulePkg/UefiBootManangerLib: Fix exception issue
>
> Thanks, Ming.
>
> On Tue, Mar 19, 2019 at 08:59:13PM +0800, Ming Huang wrote:
> > The system environment: virtual-CDROM(USB interface) via BMC, insert a
> > iso file to CDROM, like ubuntu-18.04.1-server-arm64.iso, change CDROM
> > to first boot option.
> > With release version bios, disconnecting CDROM when boot to
> > "1 seconds left, Press Esc or F2 to enter Setup"
> > then system will get a exception.
> >
> > The root cause is the EFI_BLOCK_IO_PROTOCOL for UsbMass will be
> uninstalled
> > in this situation after print some transfer error. The status will be
> > invalid parameter. This line will get a exception for BlockIo not point
> > to right address:
> > AllocatePool (BlockIo->Media->BlockSize)
> > So, here need to judge the status after ASSERT_EFI_ERROR.
> >
> > The Bugzilla tracker for this:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1631
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ming Huang
>
> Reviewed-by: Leif Lindholm
>
> > ---
> > MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 4ce83ce22d61..0535cd7335b4 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1069,6 +1069,9 @@ BmExpandMediaDevicePath (
> >//
> >Status = gBS->HandleProtocol (Handle, &gEfiBlockIoProtocolGuid, (VOID
> **) &BlockIo);
> >ASSERT_EFI_ERROR (Status);
> > + if (EFI_ERROR (Status)) {
> > +return NULL;
> > + }
> >Buffer = AllocatePool (BlockIo->Media->BlockSize);
> >if (Buffer != NULL) {
> > BlockIo->ReadBlocks (
> > --
> > 2.9.5
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message-
> From: Zeng, Star
> Sent: Thursday, March 21, 2019 9:03 AM
> To: Leif Lindholm; Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J; Wu,
> Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> Another way to update the file is
>
> [LibraryClasses.EBC]
> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
>
> ->
>
> [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
> LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
Hello Leif,
The current proposed patch seems great to me.
Reviewed-by: Hao Wu
I am also fine with the above suggestion by Star. So if you prefer the
above approach, please feel free to propose another patch. Thanks in
advance.
Best Regards,
Hao Wu
>
>
> Thanks,
> Star
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, March 21, 2019 1:43 AM
> To: Laszlo Ersek
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
> ; Wu, Hao A ; Ni, Ray
> ; Zeng, Star ; Andrew Fish
> ; Kinney, Michael D
> Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> > Hi Leif,
> >
> > On 03/18/19 15:56, Leif Lindholm wrote:
> > > Commit 05fd2a926833
> > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > > LockBox") added a dependency on LockBoxLib to NvmExpressPei, causing
> > > builds using MdeModulePkg.dsc to fail on architectures other than
> > > IA32/X64 with missing reference to
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> > >
> > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Leif Lindholm
> > > ---
> > >
> > > Note: this patch hides the symptom, but this isn't really the fix I
> > > would like to see.
> > >
> > > The build error is caused by the chain of:
> > > 1) NvmExpressPei depending on LockBoxLib
> > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > > [LibraryClasses.common.PEIM]
> > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > > 4) PcdDxeIplSwitchToLongMode being declared in
> > >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> > >
> > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > > mapping into a [LibraryClasses.IA32.PEIM, LibraryClasses.X64.PEIM]
> > > section. But that would leave NvmExpressPei unbuildable on anything
> > > not IA32/X64.
> > >
> > > Another option would be to add default declaration (for all other
> > > architectures) of FALSE for PcdDxeIplSwitchToLongMode in
> > > MdeModulePkg.dec, but the current way this is expressed seems to
> > > treat this as an architecture-specific feature (which it is).
> > >
> > > What I believe would be the cleanest solution would be to abstract
> > > NvmExpressPei to the point where it can function without the LockBoxLib.
> > > But regardless, it does not look valid to me for something as
> > > architecture-specific as MdeModulePkg/Library/SmmLockBoxLib/ to live
> > > under .common sections in the .dsc. (And if this changes at some
> > > point, because we implement an ARM/AARCH64 equivalent based on
> > > StandaloneMmPkg, we will need a major refactoring of that library
> > > anyway.)
> > >
> > > /
> > > Leif
> > >
> > > MdeModulePkg/MdeModulePkg.dsc | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/MdeModulePkg/MdeModulePkg.dsc
> > > b/MdeModulePkg/MdeModulePkg.dsc index 6cd1727a0d..6e27e9cb68
> 100644
> > > --- a/MdeModulePkg/MdeModulePkg.dsc
> > > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > > @@ -178,6 +178,7 @@ [LibraryClasses.common.MM_STANDALONE]
> > > [LibraryClasses.ARM, LibraryClasses.AARCH64]
> > >ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > >ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > > + LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> > >
> > >#
> > ># It is not possible to prevent ARM compiler calls to generic intrinsic
> functions.
> > >
> >
> > I think this patch is exact
Re: [edk2] [PATCH V3 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
Sorry for the delayed response.
One minor comment below.
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 13/17]
> MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 144
> ++---
> 1 file changed, 128 insertions(+), 16 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> index 6f0f416273..f1d31cb619 100644
> --- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> +++
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> @@ -4,7 +4,7 @@
>Note that if the debug message length is larger than the maximum
> allowable
>record length, then the debug message will be ignored directly.
>
> - Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>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
> @@ -27,6 +27,12 @@
> #include
> #include
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
> /**
>Prints a debug message to the debug output device if the specified error
> level is enabled.
>
> @@ -52,12 +58,43 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>UINT64 Buffer[(EFI_STATUS_CODE_DATA_MAX_SIZE / sizeof (UINT64))
> + 1];
>EFI_DEBUG_INFO *DebugInfo;
>UINTN TotalSize;
> - VA_LIST VaListMarker;
> - BASE_LIST BaseListMarker;
> + BASE_LIST BaseListMarkerPointer;
Please help to update the comments in DebugPrintMarker() as well to
reflect the above name change of the variable.
Other than that, the patch is good to me:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
>CHAR8 *FormatString;
>BOOLEAN Long;
>
> @@ -96,7 +133,7 @@ DebugPrint (
>// If the TotalSize is larger than the maximum record size, then return
>//
>if (TotalSize > sizeof (Buffer)) {
> -TotalSize = sizeof (Buffer);
> +return;
>}
>
>//
> @@ -109,7 +146,7 @@ DebugPrint (
>//
>DebugInfo = (EFI_DEBUG_INFO *)(Buffer) + 1;
>DebugInfo->ErrorLevel = (UINT32)ErrorLevel;
> - BaseListMarker= (BASE_LIST)(DebugInfo + 1);
> + BaseListMarkerPointer = (BASE_LIST)(DebugInfo + 1);
>FormatString = (CHAR8 *)((UINT64 *)(DebugInfo + 1) + 12);
>
>//
> @@ -125,7 +162,6 @@ DebugPrint (
>// of format in DEBU
Re: [edk2] [PATCH V3 14/17] MdeModulePkg: Add definitions for EDKII DEBUG PPI
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 14/17] MdeModulePkg: Add definitions for EDKII DEBUG
> PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a debug PPI for PEI phase. This PPI will provide basic
> services of debug. PEI debug lib instance can use these
> services to implement debug function to reduce the PEIMs
> which consume the debug lib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> MdeModulePkg/Include/Ppi/Debug.h | 90
>
> MdeModulePkg/MdeModulePkg.dec| 3 ++
> 2 files changed, 93 insertions(+)
> create mode 100644 MdeModulePkg/Include/Ppi/Debug.h
>
> diff --git a/MdeModulePkg/Include/Ppi/Debug.h
> b/MdeModulePkg/Include/Ppi/Debug.h
> new file mode 100644
> index 00..40db304f3d
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/Debug.h
> @@ -0,0 +1,90 @@
> +/** @file
> + Define the EDKII_DEBUG_PPI that PEIMs can use to dump info to debug
> port.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + 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
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __EDKII_DEBUG_PPI_H__
> +#define __EDKII_DEBUG_PPI_H__
> +
> +#include
> +
> +//
> +// Global ID for the EDKII_DEBUG_PPI
> +//
> +#define EDKII_DEBUG_PPI_GUID \
> + { \
> +0x999e699c, 0xb013, 0x475e, {0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48,
> 0x75} \
> + }
> +
> +///
> +/// Forward declaration for the PEI_DEBUG_LIB_DEBUG_PPI
> EDKII_DEBUG_PPI
> +///
> +typedef struct _EDKII_DEBUG_PPI EDKII_DEBUG_PPI;
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_BPRINT)(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + );
Hello,
I checked the PEIM that implements this PPI (patch 15/17), and I did not
find the parameters 'PeiServices' & 'This' are being used there.
Thus, I suggest to remove those 2 parameters from the interfaces of
EFIAPI *EDKII_DEBUG_BPRINT
EFIAPI *EDKII_DEBUG_ASSERT
Best Regards,
Hao Wu
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_ASSERT)(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + );
> +
Re: [edk2] [PATCH V3 17/17] MdeModulePkg: Add PEIM and lib to dsc file
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Gao, Zhichao > Sent: Tuesday, March 19, 2019 11:26 PM > To: edk2-devel@lists.01.org > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan; > Michael Turner; Bret Barkelew > Subject: [PATCH V3 17/17] MdeModulePkg: Add PEIM and lib to dsc file > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 > > Add the new PEIM DebugServicePei and library instance > PeiDebugLibDebugPpi to dsc file to verify it can build > correctly. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Zhichao Gao > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ray Ni > Cc: Star Zeng > Cc: Liming Gao > Cc: Sean Brogan > Cc: Michael Turner > Cc: Bret Barkelew > --- > MdeModulePkg/MdeModulePkg.dsc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 6cd1727a0d..dec441e23e 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -297,6 +297,7 @@ > > MdeModulePkg/Library/PlatformHookLibSerialPortPpi/PlatformHookLibSeria > lPortPpi.inf > > MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompr > essLib.inf > > MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLib > ReportStatusCode.inf > + MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf >MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf > > MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManage > rLibNull.inf >MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf > @@ -423,6 +424,8 @@ >MdeModulePkg/Universal/SerialDxe/SerialDxe.inf >MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.inf > > + MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf > + >MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf > > MdeModulePkg/Library/FmpAuthenticationLibNull/FmpAuthenticationLibNu > ll.inf >MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf > -- > 2.16.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
Hello,
Besides the comments in patch 14/17 to remove the 'PeiServices' & 'This'
parameters from the PPI services, some minor comments below:
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEIM to install Debug PPI so that PEI debug library
> instance can locate gEdkiiDebugPpiGuid to implement the
> debug functions. Using this PPI can reduce the size of
> PEIMs which consume the debug library.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Universal/DebugServicePei/DebugService.c | 68
> ++
> .../Universal/DebugServicePei/DebugService.h | 64
>
> .../Universal/DebugServicePei/DebugServicePei.c| 54
> +
> .../Universal/DebugServicePei/DebugServicePei.inf | 51
>
> .../Universal/DebugServicePei/DebugServicePei.uni | 20 +++
> 5 files changed, 257 insertions(+)
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.h
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.uni
>
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> new file mode 100644
> index 00..54ae6974d1
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> @@ -0,0 +1,68 @@
> +/** @file
> + Debug services instances for PEI phase.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + 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
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugBPrint(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + )
> +{
> + DebugBPrint(ErrorLevel, Format, Marker);
> +}
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] PeiServices The pointer to the PEI Services Table.
> + @param[in] This The pointer to this instance of
> EDKII_DEBUG_PPI
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugAssert(
> + IN CONST EFI_PEI_SERVICES **PeiServices,
> + IN EDKII_DEBUG_PPI*This,
> + IN CONST CHAR8*FileName,
> + IN UINTN
Re: [edk2] [PATCH V3 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
Hello,
Besides the comments in patch 14/17 to remove the 'PeiServices' & 'This'
parameters from the PPI services, some minor comments below:
> -Original Message-
> From: Gao, Zhichao
> Sent: Tuesday, March 19, 2019 11:26 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V3 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI
> debug lib
>
> From: Liming Gao
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEI debug library instance PeiDebugLibDebugPpi base on
> DebugPpi. Using the combination of the DebugServicePei and
> this lib instance can reduce the image size of PEI drivers.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Library/PeiDebugLibDebugPpi/DebugLib.c | 469
> +
> .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++
> 2 files changed, 524 insertions(+)
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf
>
> diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> new file mode 100644
> index 00..839dff5268
> --- /dev/null
> +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> @@ -0,0 +1,469 @@
> +/** @file
> + PEI debug lib instance base on DebugPpi to save size
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + 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
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EDKII_DEBUG_PPI *mDebugPpi = NULL;
> +CONST EFI_PEI_SERVICES **mPeiServicesTablePointer = NULL;
If the EDKII_DEBUG_PPI interface changes, the above variable can be
removed.
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param VaListMarker VA_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + ...
> + )
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format
> and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugBPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN BASE_LIST BaseListMarker
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If Format is NULL, then ASSERT().
> + //
> + ASSERT (Format != NULL);
> +
> + //
> + // Check driver Debug Level value and global debug level
> + //
> + if ((ErrorLevel & GetDebugPrintErrorLevel ()) =
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> >> > >> Just a couple of notes from my side - I'm sure Laszlo will have a much > >> longer list :-) > >> > >> - Dropping the floppy driver is fine with me. > >> - What is OVMF specific about this driver? Is it only the hardcoded > >> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >> driver and a library class, where the driver lives in MdeModulePkg, > >> and the library is implemented in the context of OVMF? > > > > Hello Ard, > > > > I think the special thing for this one is that: > > For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > > know, the SIO chip exists on other platforms. The driver proposed here > > simulates the behavior of an SIO chip. IMO, if we find more platforms that > > do not have a SIO chip, we can convert the driver into a general one. > > > > Also, for the implementation of the services in the Super I/O protocol, > > the proposed driver just does the minimal effort in order to support the > > serial/PS2 keyboard. > > Here's why I'd like the majority of this driver to live under > MdeModulePkg (for example through a lib class separation like Ard suggests): > > Because then its maintenance would not be the responsibility of OvmfPkg > maintainers. > > Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > minimal effort in order to support the serial/PS2 keyboard". > > The risk of regressions is extreme (the PS/2 keyboard is the default > one, and if it breaks *subtly*, almost all users will be inconvenienced, > but not necessarily soon enough for us to get reports about it *early* > in the current development cycle). > > I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > upon nowadays, they may be ugly / platform specific / etc etc etc, but > they have also proved themselves to *work*, and (as far as I remember) > they have required practically zero fixes in order to function well on QEMU. > > It is very unwelcome by me to take on the maintenance burden for a > driver that is all of: > - not widely tested, > - replacing a proven set of drivers that is critical to users, > - large. > > I understand that Intel wants to stop maintaining > IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for me. > > Compare the case if we simply moved the > IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg: > - still large, > - but widely tested (with minimal churn in the past), > - and no risk of regressions. > > So in this form, I'm generally opposed to the switch. The two sets of > drivers need to coexist for a while, and we must expose the new drivers > to users while providing them with some sort of easy fallback. (I'd > prefer that fallback to be dynamically configurable, but, again, if your > keyboard breaks, how do you interact with e.g. the UEFI shell? So I > guess a static build flag would do as well.) I think the old drivers Hello Laszlo, I agree with your point. So your suggestion is to: 1. Duplicate the below drivers into OvmfPkg: PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf 2. Meanwhile, add the proposed SioBusDxe driver in the OvmfPkg as well 3. Add a static build flag within OvmfPkg to let users choose between: a) New OVMF SioBusDxe driver + ISA device drivers under MdeModulePkg/Bus/Isa; b) Legacy ISA stack copied from PcAtChipsetPkg & IntelFrameworkModulePkg Is my understanding correct? > should be removed only in the edk2 stable tag that comes *after* the > next one, once we've given the drivers enough time to "prove themselves". Do you mean we should keep the copy of the legacy ISA stack from PcAtChipsetPkg & IntelFrameworkModulePkg until the announcement of edk2-stable201905 tag? Best Regards, Hao Wu > > (We did something similar when we switched to the central PCI root > bridge driver in OVMF as well -- an OVMF lib instance for it was > implemented, so the maintenance burden wasn't fully under OvmfPkg to > begin with, plus we kept the old driver around with a build flag for a > while. IIRC.) > > Obviously I might feel safer if I could do a thorough review of the > driver, but I *absolutely* don't have time for it now. I'm sorry about that. > > Thanks, > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, March 21, 2019 2:58 PM
> To: Gao, Zhichao; edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan; Michael Turner;
> Bret Barkelew
> Subject: RE: [PATCH V3 13/17]
> MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
>
> Zhichao:
> Why do below change? Seemly, this change is not related to add new APIs. In
> fact, current log is added as the purpose by commit
> 137ed15511e2045a7333e33ae7f1e873ce1961dd.
I would suggest to add another separate commit to refine the below
comments to state the message truncating behavior here:
//
// If the TotalSize is larger than the maximum record size, then return
^^^
//
if (TotalSize > sizeof (Buffer)) {
TotalSize = sizeof (Buffer);
}
Best Regards,
Hao Wu
>
> if (TotalSize > sizeof (Buffer)) {
> TotalSize = sizeof (Buffer); ==> return;
> }
>
> Thanks
> Liming
> >-Original Message-
> >From: Gao, Zhichao
> >Sent: Tuesday, March 19, 2019 11:26 PM
> >To: edk2-devel@lists.01.org
> >Cc: Wang, Jian J ; Wu, Hao A ;
> >Ni, Ray ; Zeng, Star ; Gao, Liming
> >; Sean Brogan ;
> >Michael Turner ; Bret Barkelew
> >
> >Subject: [PATCH V3 13/17]
> >MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
> >
> >REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
> >
> >Add new APIs' implementation (DebugVPrint, DebugBPrint)
> >in the DebugLib instance. These APIs would expose print
> >routines with VaList parameter and BaseList parameter.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Zhichao Gao
> >Cc: Jian J Wang
> >Cc: Hao Wu
> >Cc: Ray Ni
> >Cc: Star Zeng
> >Cc: Liming Gao
> >Cc: Sean Brogan
> >Cc: Michael Turner
> >Cc: Bret Barkelew
> >---
> > .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 144
> >++---
> > 1 file changed, 128 insertions(+), 16 deletions(-)
> >
> >diff --git
> >a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >index 6f0f416273..f1d31cb619 100644
> >--- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >+++
> >b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> >@@ -4,7 +4,7 @@
> > Note that if the debug message length is larger than the maximum
> allowable
> > record length, then the debug message will be ignored directly.
> >
> >- Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> >+ Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> > 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
> >@@ -27,6 +27,12 @@
> > #include
> > #include
> >
> >+//
> >+// VA_LIST can not initialize to NULL for all compiler, so we use this to
> >+// indicate a null VA_LIST
> >+//
> >+VA_LIST mVaListNull;
> >+
> > /**
> > Prints a debug message to the debug output device if the specified error
> >level is enabled.
> >
> >@@ -52,12 +58,43 @@ DebugPrint (
> > IN CONST CHAR8 *Format,
> > ...
> > )
> >+{
> >+ VA_LIST Marker;
> >+
> >+ VA_START (Marker, Format);
> >+ DebugVPrint (ErrorLevel, Format, Marker);
> >+ VA_END (Marker);
> >+}
> >+
> >+/**
> >+ Prints a debug message to the debug output device if the specified
> >+ error level is enabled base on Null-terminated format string and a
> >+ VA_LIST argument list or a BASE_LIST argument list.
> >+
> >+ If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> >+ GetDebugPrintErrorLevel (), then print the message specified by Format
> >and
> >+ the associated variable argument list to the debug output device.
> >+
> >+ If Format is NULL, then ASSERT().
> >+
> >+ @param ErrorLevel The error level of the debug message.
> >+ @param Format Format string for the debug message to print.
> >+ @param VaListMarkerVA_LIST marker for the variable argument list.
> >+ @param BaseListMarker BASE_LIST marker for the variable argument list.
> >+
> >+**/
> >+VOID
> >+DebugPrintMarker (
> >+ IN UINTN Err
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 22, 2019 3:04 AM > To: Ard Biesheuvel; Wu, Hao A > Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray > Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/21/19 11:08, Ard Biesheuvel wrote: > > On Thu, 21 Mar 2019 at 07:44, Wu, Hao A wrote: > >> > >>>>> > >>>>> Just a couple of notes from my side - I'm sure Laszlo will have a much > >>>>> longer list :-) > >>>>> > >>>>> - Dropping the floppy driver is fine with me. > >>>>> - What is OVMF specific about this driver? Is it only the hardcoded > >>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >>>>> driver and a library class, where the driver lives in MdeModulePkg, > >>>>> and the library is implemented in the context of OVMF? > >>>> > >>>> Hello Ard, > >>>> > >>>> I think the special thing for this one is that: > >>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > >>>> know, the SIO chip exists on other platforms. The driver proposed here > >>>> simulates the behavior of an SIO chip. IMO, if we find more platforms > that > >>>> do not have a SIO chip, we can convert the driver into a general one. > >>>> > >>>> Also, for the implementation of the services in the Super I/O protocol, > >>>> the proposed driver just does the minimal effort in order to support the > >>>> serial/PS2 keyboard. > >>> > >>> Here's why I'd like the majority of this driver to live under > >>> MdeModulePkg (for example through a lib class separation like Ard > suggests): > >>> > >>> Because then its maintenance would not be the responsibility of OvmfPkg > >>> maintainers. > >>> > >>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > >>> minimal effort in order to support the serial/PS2 keyboard". > >>> > >>> The risk of regressions is extreme (the PS/2 keyboard is the default > >>> one, and if it breaks *subtly*, almost all users will be inconvenienced, > >>> but not necessarily soon enough for us to get reports about it *early* > >>> in the current development cycle). > >>> > >>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > >>> upon nowadays, they may be ugly / platform specific / etc etc etc, but > >>> they have also proved themselves to *work*, and (as far as I remember) > >>> they have required practically zero fixes in order to function well on > >>> QEMU. > >>> > >>> It is very unwelcome by me to take on the maintenance burden for a > >>> driver that is all of: > >>> - not widely tested, > >>> - replacing a proven set of drivers that is critical to users, > >>> - large. > >>> > >>> I understand that Intel wants to stop maintaining > >>> IntelFrameworkModulePkg/Bus/Isa/*, but the above price is too high for > me. > >>> > >>> Compare the case if we simply moved the > >>> IntelFrameworkModulePkg/Bus/Isa/* drivers under OvmfPkg: > >>> - still large, > >>> - but widely tested (with minimal churn in the past), > >>> - and no risk of regressions. > >>> > >>> So in this form, I'm generally opposed to the switch. The two sets of > >>> drivers need to coexist for a while, and we must expose the new drivers > >>> to users while providing them with some sort of easy fallback. (I'd > >>> prefer that fallback to be dynamically configurable, but, again, if your > >>> keyboard breaks, how do you interact with e.g. the UEFI shell? So I > >>> guess a static build flag would do as well.) I think the old drivers > >> > >> Hello Laszlo, > >> > >> I agree with your point. So your suggestion is to: > >> > >> 1. Duplicate the below drivers into OvmfPkg: > >> PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf > >> IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf > >> IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf > >> IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf > >> > >> 2. Meanwhile, add the pr
Re: [edk2] [PATCH V4 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode: Add new APIs
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 13/17] MdeModulePkg/PeiDxeDebugLibReportStatusCode:
> Add new APIs
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add new APIs' implementation (DebugVPrint, DebugBPrint)
> in the DebugLib instance. These APIs would expose print
> routines with VaList parameter and BaseList parameter.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../PeiDxeDebugLibReportStatusCode/DebugLib.c | 171
> +
> 1 file changed, 144 insertions(+), 27 deletions(-)
>
> diff --git
> a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> index 6f0f416273..d593752050 100644
> --- a/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> +++ b/MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/DebugLib.c
> @@ -4,7 +4,7 @@
>Note that if the debug message length is larger than the maximum allowable
>record length, then the debug message will be ignored directly.
>
> - Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>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
> @@ -27,6 +27,12 @@
> #include
> #include
>
> +//
> +// VA_LIST can not initialize to NULL for all compiler, so we use this to
> +// indicate a null VA_LIST
> +//
> +VA_LIST mVaListNull;
> +
> /**
>Prints a debug message to the debug output device if the specified error
> level
> is enabled.
>
> @@ -52,12 +58,48 @@ DebugPrint (
>IN CONST CHAR8 *Format,
>...
>)
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled base on Null-terminated format string and a
> + VA_LIST argument list or a BASE_LIST argument list.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + Only one list type is used.
> + If BaseListMarker == NULL, then use VaListMarker.
> + Otherwise use BaseListMarker and the VaListMarker should be initilized as
> + mVaListNull.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param VaListMarkerVA_LIST marker for the variable argument list.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +DebugPrintMarker (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN VA_LIST VaListMarker,
> + IN BASE_LIST BaseListMarker
> + )
> {
>UINT64 Buffer[(EFI_STATUS_CODE_DATA_MAX_SIZE / sizeof (UINT64))
> + 1];
>EFI_DEBUG_INFO *DebugInfo;
>UINTN TotalSize;
> - VA_LIST VaListMarker;
> - BASE_LIST BaseListMarker;
> + BASE_LIST BaseListMarkerPointer;
>CHAR8 *FormatString;
>BOOLEAN Long;
>
> @@ -78,22 +120,22 @@ DebugPrint (
>// Note that the passing-in format string and variable parameters will be
> constructed to
>// the following layout:
>//
> - // Buffer->||
> - // | Padding| 4 bytes
> - // DebugInfo->||
> - // | EFI_DEBUG_INFO| sizeof(EFI_DEBUG_INFO)
> - // BaseListMarker->||
> - // | ... |
> - // | variable arguments | 12 * sizeof (UINT64)
> - // | ... |
> - // ||
> - // |
Re: [edk2] [PATCH V4 14/17] MdeModulePkg: Add definitions for EDKII DEBUG PPI
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 14/17] MdeModulePkg: Add definitions for EDKII DEBUG
> PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a debug PPI for PEI phase. This PPI will provide basic
> services of debug. PEI debug lib instance can use these
> services to implement debug function to reduce the PEIMs
> which consume the debug lib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> MdeModulePkg/Include/Ppi/Debug.h | 82
>
> MdeModulePkg/MdeModulePkg.dec| 3 ++
> 2 files changed, 85 insertions(+)
> create mode 100644 MdeModulePkg/Include/Ppi/Debug.h
>
> diff --git a/MdeModulePkg/Include/Ppi/Debug.h
> b/MdeModulePkg/Include/Ppi/Debug.h
> new file mode 100644
> index 00..dc50ed1b46
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/Debug.h
> @@ -0,0 +1,82 @@
> +/** @file
> + Define the EDKII_DEBUG_PPI that PEIMs can use to dump info to debug port.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + 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
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __EDKII_DEBUG_PPI_H__
> +#define __EDKII_DEBUG_PPI_H__
> +
> +#include
> +
> +//
> +// Global ID for the EDKII_DEBUG_PPI
> +//
> +#define EDKII_DEBUG_PPI_GUID \
> + { \
> +0x999e699c, 0xb013, 0x475e, {0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c, 0x48,
> 0x75} \
> + }
> +
> +///
> +/// Forward declaration for the PEI_DEBUG_LIB_DEBUG_PPI
> EDKII_DEBUG_PPI
> +///
> +typedef struct _EDKII_DEBUG_PPI EDKII_DEBUG_PPI;
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] VaListMarker BASE_LIST marker for the variable
> argument list.
Minor comment:
Parameter name is not consistent between function description comment
'VaListMarker' and the service prototype 'Marker'.
With this handled:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_BPRINT)(
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + );
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_ASSERT)(
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + );
> +
> +///
> +/// This PPI contains a set of services to print message to debug output
> device
> +///
> +struct _EDKII_DEBUG_PPI {
> + EDKII_DEBUG_BPRINTDebugBPrint;
> + EDKII_DEBUG_ASSERTDebugAssert;
> +};
> +
> +extern EFI_GUID gEdkiiDebugPpiGuid;
> +
> +#endif
> +
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index a2130bc439..9bbd0572f5 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -492,6 +492,9 @@
>## Include/Ppi/AtaPassThru.h
>gEdkiiPeiAtaPassThruPpiGuid
Re: [edk2] [PATCH V4 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 15/17] MdeModulePkg: Add a PEIM to install Debug PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEIM to install Debug PPI so that PEI debug library
> instance can locate gEdkiiDebugPpiGuid to implement the
> debug functions. Using this PPI can reduce the size of
> PEIMs which consume the debug library.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Universal/DebugServicePei/DebugService.c | 60
> ++
> .../Universal/DebugServicePei/DebugService.h | 56
>
> .../Universal/DebugServicePei/DebugServicePei.c| 54
> +++
> .../Universal/DebugServicePei/DebugServicePei.inf | 52
> +++
> .../Universal/DebugServicePei/DebugServicePei.uni | 20
> 5 files changed, 242 insertions(+)
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugService.h
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.c
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf
> create mode 100644
> MdeModulePkg/Universal/DebugServicePei/DebugServicePei.uni
>
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> new file mode 100644
> index 00..a9ea14db81
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.c
> @@ -0,0 +1,60 @@
> +/** @file
> + Debug services instances for PEI phase.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + 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
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +
> +/**
> + Print a debug message to debug output device if the specified error level
> + is enabled.
> +
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugBPrint(
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + )
> +{
> + DebugBPrint(ErrorLevel, Format, Marker);
> +}
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +VOID
> +EFIAPI
> +PeiDebugAssert(
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + )
> +{
> + DebugAssert(FileName, LineNumber, Description);
> +}
> +
> diff --git a/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> b/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> new file mode 100644
> index 00..3e234f76b6
> --- /dev/null
> +++ b/MdeModulePkg/Universal/DebugServicePei/DebugService.h
> @@ -0,0 +1,56 @@
> +/** @file
> + Header file of Debug services instances.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials
> +
Re: [edk2] [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 21, 2019 10:05 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean Brogan;
> Michael Turner; Bret Barkelew
> Subject: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI
> debug lib
>
> From: Liming Gao
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395
>
> Add a PEI debug library instance PeiDebugLibDebugPpi base on
> DebugPpi. Using the combination of the DebugServicePei and
> this lib instance can reduce the image size of PEI drivers.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> ---
> .../Library/PeiDebugLibDebugPpi/DebugLib.c | 456
> +
> .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++
> 2 files changed, 511 insertions(+)
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf
>
> diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> new file mode 100644
> index 00..75859163ae
> --- /dev/null
> +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> @@ -0,0 +1,456 @@
> +/** @file
> + PEI debug lib instance base on DebugPpi to save size
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + 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
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EDKII_DEBUG_PPI *mDebugPpi = NULL;
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param ... Variable argument list whose contents are accessed
> +based on the format string specified by Format.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + ...
> + )
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib function
> + GetDebugPrintErrorLevel (), then print the message specified by Format and
> + the associated variable argument list to the debug output device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugBPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN BASE_LIST BaseListMarker
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If Format is NULL, then ASSERT().
> + //
> + ASSERT (Format != NULL);
> +
> + //
> + // Check driver Debug Level value and global debug level
> + //
> + if ((ErrorLevel & GetDebugPrintErrorLevel ()) == 0) {
> +return;
> + }
> +
> + if (mDebugPpi == NULL) {
> +Status = PeiServicesLocatePpi (
*
> +&gEdkiiDebugPpiGuid,
> +0,
> +NULL,
> +(VOID **)&mDebugP
Re: [edk2] [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
If it follows the EDK II C Coding Standards Specification, then ignore my relating comments then, Best Regards, Hao Wu > -Original Message- > From: Gao, Zhichao > Sent: Friday, March 22, 2019 10:19 AM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Gao, Liming; Wang, Jian J; Ni, Ray; Zeng, Star; Sean Brogan; Michael > Turner; > Bret Barkelew > Subject: RE: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI > debug lib > > For the sections you point. It seems good to watch the patch downloaded. > The indention is one or two space behind the function name depend on tab > expand(2 space). > Is it need to adjust them? > > Thanks, > Zhichao > > > -Original Message- > > From: Wu, Hao A > > Sent: Friday, March 22, 2019 10:09 AM > > To: Gao, Zhichao ; edk2-devel@lists.01.org > > Cc: Gao, Liming ; Wang, Jian J > > ; Ni, Ray ; Zeng, Star > > ; Sean Brogan ; > > Michael Turner ; Bret Barkelew > > > > Subject: RE: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add > > PEI debug lib > > > > > -Original Message- > > > From: Gao, Zhichao > > > Sent: Thursday, March 21, 2019 10:05 PM > > > To: edk2-devel@lists.01.org > > > Cc: Gao, Liming; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Sean > > > Brogan; Michael Turner; Bret Barkelew > > > Subject: [PATCH V4 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI > > > debug lib > > > > > > From: Liming Gao > > > > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 > > > > > > Add a PEI debug library instance PeiDebugLibDebugPpi base on DebugPpi. > > > Using the combination of the DebugServicePei and this lib instance can > > > reduce the image size of PEI drivers. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > > Signed-off-by: Zhichao Gao > > > Cc: Jian J Wang > > > Cc: Hao Wu > > > Cc: Ray Ni > > > Cc: Star Zeng > > > Cc: Liming Gao > > > Cc: Sean Brogan > > > Cc: Michael Turner > > > Cc: Bret Barkelew > > > --- > > > .../Library/PeiDebugLibDebugPpi/DebugLib.c | 456 > > > + > > > .../PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf| 55 +++ > > > 2 files changed, 511 insertions(+) > > > create mode 100644 > > > MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > create mode 100644 > > > MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf > > > > > > diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > new file mode 100644 > > > index 00..75859163ae > > > --- /dev/null > > > +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c > > > @@ -0,0 +1,456 @@ > > > +/** @file > > > + PEI debug lib instance base on DebugPpi to save size > > > + > > > + Copyright (c) 2019, Intel Corporation. All rights reserved. > > > + > > > + 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 > > > + > > > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > > > BASIS, > > > + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > > > EXPRESS OR IMPLIED. > > > + > > > +**/ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +EDKII_DEBUG_PPI *mDebugPpi = NULL; > > > + > > > +/** > > > + Prints a debug message to the debug output device if the specified > > > + error level is enabled. > > > + > > > + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib > > > + function GetDebugPrintErrorLevel (), then print the message > > > + specified by Format and the associated variable argument list to the > > debug output device. > > > + > > > + If Format is NULL, then ASSERT(). > > > + > > > + @param ErrorLevelThe error level of the debug message. > > > + @param FormatFormat string f
Re: [edk2] [PATCH 1/3] Nt32Pkg/Nt32Pkg.dsc: Remove EdkCompatibilityPkg information
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Shenglei Zhang > Sent: Friday, March 22, 2019 10:35 AM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A > Subject: [edk2] [PATCH 1/3] Nt32Pkg/Nt32Pkg.dsc: Remove > EdkCompatibilityPkg information > > EdkCompatibilityPkg will be removed from edk2/master. > The dependency about EdkCompatibilityPkg in Nt32Pkg.dsc should > also be removed. > > Cc: Ray Ni > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > Nt32Pkg/Nt32Pkg.dsc | 51 - > 1 file changed, 51 deletions(-) > > diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc > index 4dbde0cc45..d7b78007d2 100644 > --- a/Nt32Pkg/Nt32Pkg.dsc > +++ b/Nt32Pkg/Nt32Pkg.dsc > @@ -545,54 +545,3 @@ >NOOPT_*_*_DLINK_FLAGS = > /EXPORT:InitializeDriver=$(IMAGE_ENTRY_POINT) /BASE:0x1 /ALIGN:4096 > /FILEALIGN:4096 /SUBSYSTEM:CONSOLE >RELEASE_*_*_DLINK_FLAGS = /ALIGN:4096 /FILEALIGN:4096 > > - > > # > -# NOTE: > -# The following [Libraries] section is for building EDK module under the > EDKII > tool chain. > -# If you want build EDK module for Nt32 platform, please uncomment > [Libraries] section and > -# libraries used by that EDK module. > -# Currently, Nt32 platform do not has any EDK style module > -# > -# > -#[Libraries] > - # > - # Libraries common to PEI and DXE > - # > - # EdkCompatibilityPkg/Foundation/Efi/Guid/EfiGuidLib.inf > - # > EdkCompatibilityPkg/Foundation/Framework/Guid/EdkFrameworkGuidLib.inf > - # EdkCompatibilityPkg/Foundation/Guid/EdkGuidLib.inf > - # EdkCompatibilityPkg/Foundation/Library/EfiCommonLib/EfiCommonLib.inf > - # EdkCompatibilityPkg/Foundation/Cpu/Pentium/CpuIA32Lib/CpuIA32Lib.inf > - # EdkCompatibilityPkg/Foundation/Cpu/Itanium/CpuIa64Lib/CpuIA64Lib.inf > - # > EdkCompatibilityPkg/Foundation/Library/CustomizedDecompress/CustomizedD > ecompress.inf > - # > EdkCompatibilityPkg/Foundation/Library/CompilerStub/CompilerStubLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/Hob/HobLib.inf > - > - # > - # PEI libraries > - # > - # EdkCompatibilityPkg/Foundation/Framework/Ppi/EdkFrameworkPpiLib.inf > - # EdkCompatibilityPkg/Foundation/Ppi/EdkPpiLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Pei/PeiLib/PeiLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Pei/Hob/PeiHobLib.inf > - > - # > - # DXE libraries > - # > - # > EdkCompatibilityPkg/Foundation/Core/Dxe/ArchProtocol/ArchProtocolLib.inf > - # EdkCompatibilityPkg/Foundation/Efi/Protocol/EfiProtocolLib.inf > - # > EdkCompatibilityPkg/Foundation/Framework/Protocol/EdkFrameworkProtocolLi > b.inf > - # EdkCompatibilityPkg/Foundation/Protocol/EdkProtocolLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/EfiDriverLib/EfiDriverLib.inf > - # > EdkCompatibilityPkg/Foundation/Library/RuntimeDxe/EfiRuntimeLib/EfiRuntim > eLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/Graphics/Graphics.inf > - # > EdkCompatibilityPkg/Foundation/Library/Dxe/EfiIfrSupportLib/EfiIfrSupportLib.i > nf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/Print/PrintLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/EfiScriptLib/EfiScriptLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/EfiUiLib/EfiUiLib.inf > - > - # > - # Print/Graphics Library consume SetupBrowser Print Protocol > - # > - # EdkCompatibilityPkg/Foundation/Library/Dxe/PrintLite/PrintLib.inf > - # EdkCompatibilityPkg/Foundation/Library/Dxe/GraphicsLite/Graphics.inf > - > -- > 2.18.0.windows.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] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Saturday, March 23, 2019 2:13 AM
> To: Wu, Hao A
> Cc: Zeng, Star; Laszlo Ersek; edk2-devel@lists.01.org;
> ard.biesheu...@linaro.org; Wang, Jian J; Ni, Ray; Andrew Fish; Kinney, Michael
> D
> Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> in .dsc
>
> On Thu, Mar 21, 2019 at 03:27:45AM +, Wu, Hao A wrote:
> > > -Original Message-
> > > From: Zeng, Star
> > > Sent: Thursday, March 21, 2019 9:03 AM
> > > To: Leif Lindholm; Laszlo Ersek
> > > Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J; Wu,
> > > Hao A; Ni, Ray; Andrew Fish; Kinney, Michael D; Zeng, Star
> > > Subject: RE: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> > > in .dsc
> > >
> > > Another way to update the file is
> > >
> > > [LibraryClasses.EBC]
> > > LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> > >
> > > ->
> > >
> > > [LibraryClasses.EBC, LibraryClasses.ARM, LibraryClasses.AARCH64]
> > > LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> >
> > Hello Leif,
> >
> > The current proposed patch seems great to me.
> > Reviewed-by: Hao Wu
> >
> > I am also fine with the above suggestion by Star. So if you prefer the
> > above approach, please feel free to propose another patch. Thanks in
> > advance.
>
> Laszlo convinced me that this change makes sense. But the argument for
> that was that each architecture needs to decide itself how to
> implement LockBoxLib (or not).
>
> What does not make sense to me is that
> MdeModulePkg/Library/SmmLockBoxLib/ is used as a global default, and
> set as the resolution for LockBoxLib in common sections, when it is
> only valid for 2 of the 6 architectures supported by the UEFI
> specification.
Hello Leif,
I filed a BZ tracker according to your above concern:
https://bugzilla.tianocore.org/show_bug.cgi?id=1660
We will find an approach to address it.
>
> My original version is my preferred way of addressing the immediate
> problem though, mainly to keep the separate .EBC section.
Got it.
Do you want me to help to push the patch?
Best Regards,
Hao Wu
>
> Best Regards,
>
> Leif
>
> > Best Regards,
> > Hao Wu
> >
> > >
> > >
> > > Thanks,
> > > Star
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Thursday, March 21, 2019 1:43 AM
> > > To: Laszlo Ersek
> > > Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org; Wang, Jian J
> > > ; Wu, Hao A ; Ni, Ray
> > > ; Zeng, Star ; Andrew Fish
> > > ; Kinney, Michael D
> > > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64
> > > in .dsc
> > >
> > > On Wed, Mar 20, 2019 at 03:51:39PM +0100, Laszlo Ersek wrote:
> > > > Hi Leif,
> > > >
> > > > On 03/18/19 15:56, Leif Lindholm wrote:
> > > > > Commit 05fd2a926833
> > > > > ("MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList
> > > > > LockBox") added a dependency on LockBoxLib to NvmExpressPei,
> causing
> > > > > builds using MdeModulePkg.dsc to fail on architectures other than
> > > > > IA32/X64 with missing reference to
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdDxeIplSwitchToLongMode.
> > > > >
> > > > > Add a resolution for LockBoxNullLib for ARM/AARCH64 to restore builds.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Leif Lindholm
> > > > > ---
> > > > >
> > > > > Note: this patch hides the symptom, but this isn't really the fix I
> > > > > would like to see.
> > > > >
> > > > > The build error is caused by the chain of:
> > > > > 1) NvmExpressPei depending on LockBoxLib
> > > > > 2) LockBoxLib being mapped to SmmLockBoxPeiLib in
> > > > > [LibraryClasses.common.PEIM]
> > > > > 3) SmmLockBoxPeiLib depending on PcdDxeIplSwitchToLongMode
> > > > > 4) PcdDxeIplSwitchToLongMode being declared in
> > > > >[PcdsFeatureFlag.IA32, PcdsFeatureFlag.X64] in MdeModulePkg.dsc
> > > > >
> > > > > Now, an alternative quick-fix would be to move the PEIM LockBoxLib
> > > >
Re: [edk2] [PATCH v1 0/2] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, March 22, 2019 6:56 PM > To: Ard Biesheuvel > Cc: Wu, Hao A; edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray > Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/22/19 10:41, Ard Biesheuvel wrote: > > On Fri, 22 Mar 2019 at 10:25, Laszlo Ersek wrote: > >> > >> On 03/22/19 02:33, Wu, Hao A wrote: > >>>> -Original Message- > >>>> From: Laszlo Ersek [mailto:ler...@redhat.com] > >>>> Sent: Friday, March 22, 2019 3:04 AM > >>>> To: Ard Biesheuvel; Wu, Hao A > >>>> Cc: edk2-devel@lists.01.org; Justen, Jordan L; Ni, Ray > >>>> Subject: Re: [PATCH v1 0/2] Ovmf: Stop using ISA drivers within > >>>> IntelFrameworkModulePkg > >>>> > >>>> On 03/21/19 11:08, Ard Biesheuvel wrote: > >>>>> On Thu, 21 Mar 2019 at 07:44, Wu, Hao A wrote: > >>>>>> > >>>>>>>>> > >>>>>>>>> Just a couple of notes from my side - I'm sure Laszlo will have a > much > >>>>>>>>> longer list :-) > >>>>>>>>> > >>>>>>>>> - Dropping the floppy driver is fine with me. > >>>>>>>>> - What is OVMF specific about this driver? Is it only the hardcoded > >>>>>>>>> list of COM1/COM2/PS2 keyboard? If so, should we split this into a > >>>>>>>>> driver and a library class, where the driver lives in MdeModulePkg, > >>>>>>>>> and the library is implemented in the context of OVMF? > >>>>>>>> > >>>>>>>> Hello Ard, > >>>>>>>> > >>>>>>>> I think the special thing for this one is that: > >>>>>>>> For QEMU, it does not have a Super I/O (SIO) chip. While, as far as I > >>>>>>>> know, the SIO chip exists on other platforms. The driver proposed > here > >>>>>>>> simulates the behavior of an SIO chip. IMO, if we find more platforms > >>>> that > >>>>>>>> do not have a SIO chip, we can convert the driver into a general one. > >>>>>>>> > >>>>>>>> Also, for the implementation of the services in the Super I/O > >>>>>>>> protocol, > >>>>>>>> the proposed driver just does the minimal effort in order to support > the > >>>>>>>> serial/PS2 keyboard. > >>>>>>> > >>>>>>> Here's why I'd like the majority of this driver to live under > >>>>>>> MdeModulePkg (for example through a lib class separation like Ard > >>>> suggests): > >>>>>>> > >>>>>>> Because then its maintenance would not be the responsibility of > OvmfPkg > >>>>>>> maintainers. > >>>>>>> > >>>>>>> Consider, this driver is absolutely huge (1.5-2 kLOC), for doing "the > >>>>>>> minimal effort in order to support the serial/PS2 keyboard". > >>>>>>> > >>>>>>> The risk of regressions is extreme (the PS/2 keyboard is the default > >>>>>>> one, and if it breaks *subtly*, almost all users will be > >>>>>>> inconvenienced, > >>>>>>> but not necessarily soon enough for us to get reports about it *early* > >>>>>>> in the current development cycle). > >>>>>>> > >>>>>>> I realize that IntelFrameworkModulePkg/Bus/Isa/* drivers are frowned > >>>>>>> upon nowadays, they may be ugly / platform specific / etc etc etc, but > >>>>>>> they have also proved themselves to *work*, and (as far as I > remember) > >>>>>>> they have required practically zero fixes in order to function well on > QEMU. > >>>>>>> > >>>>>>> It is very unwelcome by me to take on the maintenance burden for a > >>>>>>> driver that is all of: > >>>>>>> - not widely tested, > >>>>>>> - replacing a proven set of drivers that is critical to users, > >>>>>>> - large. > >>>>>>> > >
Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, March 25, 2019 7:29 PM > To: Wu, Hao A; edk2-devel@lists.01.org; Julien Grall; Anthony Perard > Cc: Justen, Jordan L; Ard Biesheuvel; Ni, Ray > Subject: Re: [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/25/19 11:58, Laszlo Ersek wrote: > > On 03/25/19 06:28, Hao Wu wrote: > >> The series is also available at: > >> https://github.com/hwu25/edk2/tree/ovmf_siobus_v2 > >> > >> V2 changes: > >> * Introduce a static build flag 'USE_LEGACY_ISA_STACK' in OVMF DSC files > >> for users to select between the ISA driver stacks. > >> * V1 patch 2/2 is split into 2 patches in V2. The first one will add the > >> new OVMF SioBusDxe driver and list it in the DSC files. Then second one > >> will add the whole new ISA stack in DSC/FDF files. > >> > >> > >> V1 history: > >> > >> This series will update the OVMF to stop using the ISA drivers within > >> IntelFrameworkModulePkg. > >> > >> As the replacement, a new OVMF Super I/O bus driver has been add which > >> will install the Super I/O protocol for ISA serial and PS2 keyboard > >> devices. By doing so, these devices can be managed by: > >> > >> MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf > >> MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf > >> > >> respectively. > >> > >> > >> Tests done: > >> A. GCC5 & VS2015x86 tool chains build pass > >> B. Launch QEMU (2.4.50, Windows) with command: > >>> qemu-system-x86_64.exe -pflash \OVMF.fd -serial > file:1.txt -serial file:2.txt > >> > >>Able to see the ISA COM1/COM2 UART and PS2Keyboard devices under > Shell > >>using command 'devtree'; > >> > >>Both the serials and PS2 keyboard are working fine; > > > > Can you please confirm the following: > > > > (1) In the PrepareLpcBridgeDevicePath() function, in file > > "OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c", we add > > IsaKeyboard to ConIn, and IsaSerial to ConOut, ConIn, ErrOut. > > > > This function takes the "LPC Bridge device" handle from its caller, > > namely DetectAndPreparePlatformPciDevicePath(), and appends some > > constant device path nodes, from "BdsPlatform.h" / "PlatformData.c". > > > > Can you please confirm that the existing Platform BDS code described > > above is compatible with the new driver? > > > > In other words, do DetectAndPreparePlatformPciDevicePath() + > > PrepareLpcBridgeDevicePath() still add the proper device paths to > > ConIn/ConOut/ErrOut? > > > > (Note, they need not be identical to the previous device paths, but the > > *logic* must continue to work -- i.e. *some* device paths have to be > > added, and they should be correct.) Hello Laszlo, For (1), since I saw in function PrepareLpcBridgeDevicePath() there are already some codes to print out the device path for COM1/COM2. So I just add some logic to print the device path for the PS2 keyboard as well. I ran the qemu with command: qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log -global isa-debugcon.iobase=0x402 For the new and origin ISA stack, their logs both show: Found LPC Bridge device BdsPlatform.c+585: PS2 Keyboard DevPath: PciRoot(0x0)/Pci(0x1,0x0)/Acpi(PNP0303,0x0) BdsPlatform.c+615: COM1 DevPath: PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x0)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D) BdsPlatform.c+647: COM2 DevPath: PciRoot(0x0)/Pci(0x1,0x0)/Serial(0x1)/Uart(115200,8,N,1)/VenMsg(E0C14753-F9BE-11D2-9A0C-0090273FC14D) Thus, I think the Platform BDS code behavior remains the same. > > > > (2) Can you please confirm if the new build survives repeated > > > > reconnect -r > > > > commands in the UEFI shell? Both the ISA keyboard and the serial console > > should resume working after "reconnect -r". For (2), I also run the qemu with: qemu-system-x86_64.exe -pflash \OVMF.fd -debugcon file:boot.log -global isa-debugcon.iobase=0x402 After running 'reconnect -r' under Shell, the PS2 keyboard works fine. Then I switch the display from 'VGA' to 'serial0', and the serial works fine. (I just re-run the 'reconnect -r' under 'serial0', after the command finishes, the keyboard is responding and there is still output on 'serial0'.) > > (3) Hao, can you please verify the above steps on the "q35" machine type >
Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Monday, March 25, 2019 7:22 PM > To: Wu, Hao A; edk2-devel@lists.01.org > Cc: Justen, Jordan L > Subject: Re: [edk2] [PATCH v2 2/3] OvmfPkg: Add an Super IO bus driver > > On 03/25/19 06:28, Hao Wu wrote: > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495 > > > > There is a plan to remove the IntelFrameworkModulePkg: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1605 > > > > This patch will a new OVMF Super I/O bus driver which will create the > > below child devices: > > > > * COM 1 UART > > * COM 2 UART > > * PS/2 Keyboard > > > > and installs the Super I/O Protocol on them. > > > > Cc: Jordan Justen > > Cc: Laszlo Ersek > > Cc: Ard Biesheuvel > > Cc: Ray Ni > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Hao Wu > > --- > > OvmfPkg/OvmfPkgIa32.dsc | 1 + > > OvmfPkg/OvmfPkgIa32X64.dsc| 1 + > > OvmfPkg/OvmfPkgX64.dsc| 1 + > > OvmfPkg/SioBusDxe/SioBusDxe.inf | 54 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.h | 332 +++ > > OvmfPkg/SioBusDxe/SioService.h| 221 +++ > > OvmfPkg/SioBusDxe/ComponentName.c | 167 ++ > > OvmfPkg/SioBusDxe/SioBusDxe.c | 622 > > OvmfPkg/SioBusDxe/SioService.c| 405 + > > OvmfPkg/SioBusDxe/SioBusDxe.uni | 21 + > > 10 files changed, 1825 insertions(+) > > Acked-by: Laszlo Ersek > > but please don't push the series before answering my questions under 0/3. Thanks Laszlo, I have replied your comments under patch 0/3. I will wait for your approval, since I saw there is an open with regard to the file license header for the new files. Best Regards, Hao Wu > > Thanks! > Laszlo > ___ > 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 v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Tuesday, March 26, 2019 11:15 PM > To: Wu, Hao A > Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall > Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > Hi Hao, > > On 03/26/19 16:01, Laszlo Ersek wrote: > > On 03/26/19 14:03, Anthony PERARD wrote: > >> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote: > >>> (4) Julien, Anthony: can you please fetch this series (github URL at the > >>> top) and see if the PS/2 keyboard, and the serial port, still work on > >>> Xen, to interact e.g. with the UEFI shell? > >> > >> Yes, I can still interact with the UEFI shell with this series applied, > >> both via the console and via VNC (which uses respectively the serial > >> port and PS/2 I think). > > > > Thank you -- can you please follow up with a Tested-by, or do you prefer > > if I push the set without it? > > ... actually, I just realize that you can push this series just fine, > after Anthony's answer -- so please excuse my confusing comment; I'll of > course let you push the series. Hello Laszlo, Sure, I will push the series. But one thing to confirm, for patch 2/3, it only got a couple of 'Ack' tags and a 'Tested-by' tag. I am not sure if this meets the criteria for pushing. Best Regards, Hao Wu > > Thanks > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 in .dsc
> -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Wednesday, March 27, 2019 3:43 AM > To: Wu, Hao A > Cc: Zeng, Star; Laszlo Ersek; edk2-devel@lists.01.org; > ard.biesheu...@linaro.org; Wang, Jian J; Ni, Ray; Andrew Fish; Kinney, Michael > D > Subject: Re: [RFC PATCH] MdeModulePkg: add LockBoxNullLib for !IA32/X64 > in .dsc > > On Mon, Mar 25, 2019 at 02:17:05AM +, Wu, Hao A wrote: > > > My original version is my preferred way of addressing the immediate > > > problem though, mainly to keep the separate .EBC section. > > > > Got it. > > Do you want me to help to push the patch? > > If you could, that would be appreciated. Hello Leif, Pushed at commit: 4a1f6b85c184eecab22df88312a207f5e0ea4264 Thanks for the patch. Best Regards, Hao Wu > > Best Regards, > > Leif ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within IntelFrameworkModulePkg
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, March 27, 2019 11:37 AM > To: Wu, Hao A > Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall > Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > IntelFrameworkModulePkg > > On 03/27/19 01:20, Wu, Hao A wrote: > >> -Original Message- > >> From: Laszlo Ersek [mailto:ler...@redhat.com] > >> Sent: Tuesday, March 26, 2019 11:15 PM > >> To: Wu, Hao A > >> Cc: Anthony PERARD; Justen, Jordan L; edk2-devel@lists.01.org; Julien Grall > >> Subject: Re: [edk2] [PATCH v2 0/3] Ovmf: Stop using ISA drivers within > >> IntelFrameworkModulePkg > >> > >> Hi Hao, > >> > >> On 03/26/19 16:01, Laszlo Ersek wrote: > >>> On 03/26/19 14:03, Anthony PERARD wrote: > >>>> On Mon, Mar 25, 2019 at 12:29:25PM +0100, Laszlo Ersek wrote: > >>>>> (4) Julien, Anthony: can you please fetch this series (github URL at the > >>>>> top) and see if the PS/2 keyboard, and the serial port, still work on > >>>>> Xen, to interact e.g. with the UEFI shell? > >>>> > >>>> Yes, I can still interact with the UEFI shell with this series applied, > >>>> both via the console and via VNC (which uses respectively the serial > >>>> port and PS/2 I think). > >>> > >>> Thank you -- can you please follow up with a Tested-by, or do you prefer > >>> if I push the set without it? > >> > >> ... actually, I just realize that you can push this series just fine, > >> after Anthony's answer -- so please excuse my confusing comment; I'll of > >> course let you push the series. > > > > Hello Laszlo, > > > > Sure, I will push the series. > > > > But one thing to confirm, for patch 2/3, it only got a couple of 'Ack' > > tags and a 'Tested-by' tag. I am not sure if this meets the criteria for > > pushing. > > Yes, if you get an Acked-by from at least one "M" person for the package > (and no open questions remain), that's sufficient. For edk2, my > interpretation of "Acked-by" is: "although I haven't reviewed in detail, > I agree/approve". Got it. Thanks all for the feedbacks and review/test effort. Series has been pushed via commits: c455bc8c8d..a068102296 Best Regards, Hao Wu > > Thanks, > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/12] SourceLevelDebugPkg/DebugAgentCommon: Remove .S files
Hello Shenglei,
There are still two .S files under SourceLevelDebugPkg:
edk2\SourceLevelDebugPkg\Library\PeCoffExtraActionLibDebug\Ia32\IntHandler.S
edk2\SourceLevelDebugPkg\Library\PeCoffExtraActionLibDebug\X64\IntHandler.S
Is there any special reason to left them in the repo?
Best Regards,
Hao Wu
> -Original Message-
> From: Zhang, Shenglei
> Sent: Friday, March 29, 2019 3:28 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH v3 12/12] SourceLevelDebugPkg/DebugAgentCommon:
> Remove .S files
>
> .nasm file has been added for X86 arch. .S assembly code
> is not required any more.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1594
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> .../DebugAgentCommon/Ia32/AsmFuncs.S | 415 -
> .../DebugAgentCommon/X64/AsmFuncs.S | 431 --
> .../Library/DebugAgent/DxeDebugAgentLib.inf | 2 -
> 3 files changed, 848 deletions(-)
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmFun
> cs.S
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/X64/AsmFun
> cs.S
>
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> deleted file mode 100644
> index 30d279e80d..00
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> +++ /dev/null
> @@ -1,415 +0,0 @@
> -#--
> -#
> -# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> -# 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.
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -#
> -# Module Name:
> -#
> -# AsmFuncs.S
> -#
> -# Abstract:
> -#
> -# Debug interrupt handle functions.
> -#
> -#--
> -
> -#include "DebugException.h"
> -
> -ASM_GLOBAL ASM_PFX(InterruptProcess)
> -ASM_GLOBAL ASM_PFX(Exception0Handle)
> -ASM_GLOBAL ASM_PFX(ExceptionStubHeaderSize)
> -ASM_GLOBAL ASM_PFX(TimerInterruptHandle)
> -ASM_GLOBAL ASM_PFX(CommonEntry)
> -
> -.macro AGENT_HANDLER_SIGNATURE
> - .byte 0x41, 0x47, 0x54, 0x48 # AGENT_HANDLER_SIGNATURE
> SIGNATURE_32('A','G','T','H')
> -.endm
> -
> -.data
> -
> -ASM_PFX(ExceptionStubHeaderSize): .long ASM_PFX(Exception1Handle) -
> ASM_PFX(Exception0Handle)
> -
> -.text
> -
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception0Handle):
> - cli
> - pushl %eax
> - mov $0, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception1Handle):
> - cli
> - pushl %eax
> - mov $1, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception2Handle):
> - cli
> - pushl %eax
> - mov $2, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception3Handle):
> - cli
> - pushl %eax
> - mov $3, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception4Handle):
> - cli
> - pushl %eax
> - mov $4, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception5Handle):
> - cli
> - pushl %eax
> - mov $5, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception6Handle):
> - cli
> - pushl %eax
> - mov $6, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception7Handle):
> - cli
> - pushl %eax
> - mov $7, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception8Handle):
> - cli
> - pushl %eax
> - mov $8, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception9Handle):
> - cli
> - pushl %eax
> - mov $9, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception10Handle):
> - cli
> - pushl %eax
> - mov $10, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exce
Re: [edk2] [PATCH 1/3] MdeModulePkg/UfsPassThruDxe: Fix unaligned data transfer handling
Hello Mateusz,
There has been a Bugzilla tracker for the issue you addressed in this
patch:
https://bugzilla.tianocore.org/show_bug.cgi?id=1341
Could you help to add this information in the commit log message? Thanks.
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, March 28, 2019 9:56 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH 1/3] MdeModulePkg/UfsPassThruDxe: Fix unaligned data
> transfer handling
>
> Since UFS spcification requiers the data buffer specified
specification -> specification
requiers -> requires
> in PRDT to be DWORD aligned in size we had a code in
> UfsInitUtpPrdt that aligned the data buffer by rounding down
> the buffer size to DWORD boundary. This meant that for SCSI
> commands that wanted to perform unaligned data transfer(such as
> SENSE command) we specified to small buffer for the data to fit
> and transfer was aborted. This change introduces code that allocates
> auxilary DWORD aligned data buffer for unaligned transfer. Device
auxilary -> auxiliary
There are some 'auxilary' typos within the update in file UfsPassThruHci.c
as well, please help to update them.
> transfers data to aligned buffer and when data transfer is over driver copies
The above line seems too long. Please help to refine it under 76 chars.
> data from aligned buffer to data buffer passed by user.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Hao Wu
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 1 +
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 190 +++-
> -
> 2 files changed, 135 insertions(+), 56 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> index b8937842b8..e591e78661 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h
> @@ -98,6 +98,7 @@ typedef struct {
>UINT32CmdDescSize;
>VOID *CmdDescHost;
>VOID *CmdDescMapping;
> + VOID *AlignedDataBuf;
>VOID *DataBufMapping;
>
>EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET*Packet;
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> index 0238264878..9d0793c6be 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> @@ -400,17 +400,13 @@ UfsInitUtpPrdt (
>UINT8 *Remaining;
>UINTN PrdtNumber;
>
> - if ((BufferSize & (BIT0 | BIT1)) != 0) {
> -BufferSize &= ~(BIT0 | BIT1);
> -DEBUG ((DEBUG_WARN, "UfsInitUtpPrdt: The BufferSize [%d] is not dword-
> aligned!\n", BufferSize));
> - }
> + ASSERT (((UINTN)Buffer & (BIT0 | BIT1)) == 0);
> + ASSERT ((BufferSize & (BIT1 | BIT0)) == 0);
>
>if (BufferSize == 0) {
> return EFI_SUCCESS;
>}
>
> - ASSERT (((UINTN)Buffer & (BIT0 | BIT1)) == 0);
> -
>RemainingLen = BufferSize;
>Remaining= Buffer;
>PrdtNumber = (UINTN)DivU64x32 ((UINT64)BufferSize +
> UFS_MAX_DATA_LEN_PER_PRD - 1, UFS_MAX_DATA_LEN_PER_PRD);
> @@ -1212,8 +1208,6 @@ UfsSetFlag (
>return Status;
> }
>
> -
> -
> /**
>Read specified flag from a UFS device.
>
> @@ -1323,6 +1317,129 @@ Exit:
>return Status;
> }
>
> +/**
> + Cleanup data buffers after data transfer. This function
> + also takes care to copy all data to user memory pool for
> + unaligned data transfers.
> +
> + @param[in] Private Pointer to the UFS_PASS_THRU_PRIVATE_DATA
> + @param[in] TransReq Pointer to the transfer request
> +**/
> +VOID
> +UfsReconcileDataTransferBuffer (
> + IN UFS_PASS_THRU_PRIVATE_DATA *Private,
> + IN UFS_PASS_THRU_TRANS_REQ *TransReq
> + )
> +{
> + if (TransReq->DataBufMapping != NULL) {
> +Private->UfsHostController->Unmap (
> + Private->UfsHostController,
> + TransReq->DataBufMapping
> + );
> + }
> +
> + //
> + // Check if unaligned transfer was performed. If it was and we read
> + // data from device copy memory to user data buffers before cleanup.
> + // The assumption is if auxilary aligned data buffer is not NULL then
> + // unaligned transfer has been performed.
> + //
> + i
Re: [edk2] [PATCH 2/3] MdeModulePkg/UfsPassThruDxe: Refactor UFS device presence detection
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, March 28, 2019 9:56 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH 2/3] MdeModulePkg/UfsPassThruDxe: Refactor UFS device
> presence detection
>
> In current implementation we are checking for device presence every
> time we execute UIC command. To make UfsExecUicCommands more generic
> checking device presence has been moved to UfsDeviceDetection.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Hao Wu
> Signed-off-by: Albecki Mateusz
> ---
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 49
> --
> 1 file changed, 18 insertions(+), 31 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> index 9d0793c6be..c37161c4ae 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c
> @@ -1621,7 +1621,7 @@ Exit1:
> }
>
> /**
> - Sent UIC DME_LINKSTARTUP command to start the link startup procedure.
> + Send UIC command.
>
>@param[in] Private The pointer to the UFS_PASS_THRU_PRIVATE_DATA
> data structure.
>@param[in] UicOpcodeThe opcode of the UIC command.
Please help to update remove the line:
@return EFI_NOT_FOUNDThe presence of the UFS device isn't detected.
from the description of functions UfsExecUicCommands().
Other than this, the patch is good to me:
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> @@ -1716,24 +1716,6 @@ UfsExecUicCommands (
> }
>}
>
> - //
> - // Check value of HCS.DP and make sure that there is a device attached to
> the Link.
> - //
> - Status = UfsMmioRead32 (Private, UFS_HC_STATUS_OFFSET, &Data);
> - if (EFI_ERROR (Status)) {
> -return Status;
> - }
> -
> - if ((Data & UFS_HC_HCS_DP) == 0) {
> -Status = UfsWaitMemSet (Private, UFS_HC_IS_OFFSET, UFS_HC_IS_ULSS,
> UFS_HC_IS_ULSS, UFS_TIMEOUT);
> -if (EFI_ERROR (Status)) {
> - return EFI_DEVICE_ERROR;
> -}
> -return EFI_NOT_FOUND;
> - }
> -
> - DEBUG ((DEBUG_INFO, "UfsPassThruDxe: found a attached UFS device\n"));
> -
>return EFI_SUCCESS;
> }
>
> @@ -1907,8 +1889,9 @@ UfsDeviceDetection (
>IN UFS_PASS_THRU_PRIVATE_DATA *Private
>)
> {
> - UINTN Retry;
> - EFI_STATUS Status;
> + UINTN Retry;
> + EFI_STATUS Status;
> + UINT32 Data;
>
>//
>// Start UFS device detection.
> @@ -1916,22 +1899,26 @@ UfsDeviceDetection (
>//
>for (Retry = 0; Retry < 3; Retry++) {
> Status = UfsExecUicCommands (Private, UfsUicDmeLinkStartup, 0, 0, 0);
> -if (!EFI_ERROR (Status)) {
> - break;
> +if (EFI_ERROR (Status)) {
> + return EFI_DEVICE_ERROR;
> }
>
> -if (Status == EFI_NOT_FOUND) {
> - continue;
> +Status = UfsMmioRead32 (Private, UFS_HC_STATUS_OFFSET, &Data);
> +if (EFI_ERROR (Status)) {
> + return EFI_DEVICE_ERROR;
> }
>
> -return EFI_DEVICE_ERROR;
> - }
> -
> - if (Retry == 3) {
> -return EFI_NOT_FOUND;
> +if ((Data & UFS_HC_HCS_DP) == 0) {
> + Status = UfsWaitMemSet (Private, UFS_HC_IS_OFFSET, UFS_HC_IS_ULSS,
> UFS_HC_IS_ULSS, UFS_TIMEOUT);
> + if (EFI_ERROR (Status)) {
> +return EFI_DEVICE_ERROR;
> + }
> +} else {
> + return EFI_SUCCESS;
> +}
>}
>
> - return EFI_SUCCESS;
> + return EFI_NOT_FOUND;
> }
>
> /**
> --
> 2.14.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] MdeModulePkg/UfsPassThruDxe: Add UFS info protocol
Hello Mateusz,
A couple of general comments:
A. I suggest to break this commit into 2 patches:
The first one will just introduce the new protocol.
The second one will update the UfsPassThruDxe driver to consume this new
protocol.
B. There has been a Bugzilla tracker for the feature you add in this
patch:
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Could you help to add this information in the commit log message? Thanks.
C. I prefer the new protocol to have platform level singleton instance:
I do not see much value for a platform to produce multiple instances of
this protocol, I think the additional UIC commands needed during the UFS
HC initialization for a specific platform is deterministic.
Also, the selection of protocol instance implemented in function
GetUfsHcInfoProtocol() is by:
1) LocateHandleBuffer() to get all protocol instances;
2) Choose the 1st instance if the 'Supported' service returns without
error.
I think this will bring some kind of confusion to the protocol producers,
since they do not know which one will be selected when there are multiple
instances of the protocol.
> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, March 28, 2019 9:56 PM
> To: edk2-devel@lists.01.org
> Cc: Albecki, Mateusz; Wu, Hao A
> Subject: [PATCH 3/3] MdeModulePkg/UfsPassThruDxe: Add UFS info protocol
>
> UFS host controller specification allows for implementation specific
> UIC programming to take place just after host controller enable and before
> device detection. Since there is no way for generic driver to anticipate
> implementation specific programming we add a UFS info protocol
> which allows the implementation specific code to pass this information
> to generic driver. UFS info protocol is located by the driver at the
> BindingStart call and the supported instance is retained throught entire
throught -> through
> driver lifetime. Presence of the protocol is optional.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Cc: Hao Wu
> Signed-off-by: Albecki Mateusz
> ---
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 62
> ++
> MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 2 +
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruDxe.inf | 1 +
> .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 60 +
> .../Include/Protocol/UfsHostControllerInfo.h | 75
> ++
> MdeModulePkg/MdeModulePkg.dec | 3 +
> 6 files changed, 203 insertions(+)
> create mode 100644 MdeModulePkg/Include/Protocol/UfsHostControllerInfo.h
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> index ea329618dc..a41079e311 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c
> @@ -40,6 +40,7 @@ UFS_PASS_THRU_PRIVATE_DATA gUfsPassThruTemplate
> = {
> UfsRwUfsAttribute
>},
>0, // UfsHostController
> + NULL, // UfsInfo
>0, // UfsHcBase
>0, // Capabilities
>0, // TaskTag
> @@ -776,6 +777,66 @@ UfsFinishDeviceInitialization (
>return EFI_SUCCESS;
> }
>
> +/**
> + Locates UFS HC infor protocol suitable for this controller.
infor -> info
> +
> + @param[in] DriverBinding Pointer to driver binding protocol
> + @param[in] Private Pointer to host controller private data
> + @param[in] ControllerHandle Controller to which driver is bound
> +**/
> +VOID
> +GetUfsHcInfoProtocol (
> + IN EFI_DRIVER_BINDING_PROTOCOL *DriverBinding,
> + IN UFS_PASS_THRU_PRIVATE_DATA *Private,
> + IN EFI_HANDLE ControllerHandle
> + )
> +{
> + EFI_STATUSStatus;
> + EFI_HANDLE*ProtocolHandleArray;
> + UINTN NoHandles;
> + UINTN HandleIndex;
> + UFS_HC_INFO_PROTOCOL *UfsHcInfo;
> +
> + Status = gBS->LocateHandleBuffer (
> + ByProtocol,
> + &gUfsHcInfoProtocolGuid,
> + NULL,
> + &NoHandles,
> + &ProtocolHandleArray
> + );
> + if (EFI_ERROR (Status)) {
> +return;
> + }
> +
> + for (HandleIndex = 0; HandleIndex < NoHandles; HandleIndex++) {
> +Status = gBS->OpenProtocol (
> +ProtocolHandleArray[HandleIndex],
> +&gUfsHcInfoProtocolGuid,
> +&UfsHcInfo,
> +DriverBinding->DriverBindingHandle,
> +
Re: [edk2] [PATCH 0/3] Implement UFS info protocol to pass additional UIC programming data from platform/silicon specific driver
> -Original Message- > From: Albecki, Mateusz > Sent: Thursday, March 28, 2019 9:49 PM > To: edk2-devel@lists.01.org > Cc: Albecki, Mateusz; Wu; Wu, Hao A > Subject: [PATCH 0/3] Implement UFS info protocol to pass additional UIC > programming data from platform/silicon specific driver > > UFS specification allows for additional, implementation specific, programming > to be done during host controller initialization. Since some hosts > might require it to allow for device detection we add a way for > platform/silicon > specific code to pass required attributes and their values to > generic UFS driver. Please see UFS 2.0 specification for details of the host > controller initialization sequence(JESD223B section 7.1.1 step 4). > Patchset consists of 3 patches to achieve this. The first one is a bugfix for > data > transfers that are not aligned to DWORD boundary such as SCSI SENSE > command. The second one is code refactoring for device presence detection > that cleans up the function that sends UIC commands. Final patch defines > UFS info protocol and implements driver logic for servicing it. > > Tests performed: > -Test UFS LU enumeration with UFS 2.0 card with 3 enabled LUs > -Test that no unaligned data transfers are performed during enumeration > -Test that UIC is programmed according to platform table Hello Mateusz, For the additional UIC during HC initialization change, could you help to verify a 'reconnect -r' under Shell to see whether the UFS devices work fine in such case? Thanks. Best Regards, Hao Wu > -Test that driver operation is not impacted when no UFS info protocol is > installed > > CC: Wu, Hao A > > Albecki, Mateusz (3): > MdeModulePkg/UfsPassThruDxe: Fix unaligned data transfer handling > MdeModulePkg/UfsPassThruDxe: Refactor UFS device presence detection > MdeModulePkg/UfsPassThruDxe: Add UFS info protocol > > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c | 62 + > MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.h | 3 + > .../Bus/Ufs/UfsPassThruDxe/UfsPassThruDxe.inf | 1 + > .../Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c| 299 +++- > - > .../Include/Protocol/UfsHostControllerInfo.h | 75 ++ > MdeModulePkg/MdeModulePkg.dec | 3 + > 6 files changed, 356 insertions(+), 87 deletions(-) > create mode 100644 MdeModulePkg/Include/Protocol/UfsHostControllerInfo.h > > -- > 2.14.1.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/14] SourceLevelDebugPkg/DebugAgentCommon: Remove .S files
> -Original Message-
> From: Zhang, Shenglei
> Sent: Monday, April 01, 2019 4:30 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [PATCH v3 12/14] SourceLevelDebugPkg/DebugAgentCommon:
> Remove .S files
>
> .nasm file has been added for X86 arch. .S assembly code
> is not required any more.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1594
>
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> Reviewed-by: Liming Gao
> ---
> .../DebugAgentCommon/Ia32/AsmFuncs.S | 415 -
> .../DebugAgentCommon/X64/AsmFuncs.S | 431 --
> .../Library/DebugAgent/DxeDebugAgentLib.inf | 2 -
Please help to remove the .s file include in:
SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf
SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf
With the above changes:
Reviewed-by: Hao Wu
Sorry for missing this in the v2 patch.
Best Regards,
Hao Wu
> 3 files changed, 848 deletions(-)
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmFun
> cs.S
> delete mode 100644
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/X64/AsmFun
> cs.S
>
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> b/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> deleted file mode 100644
> index 30d279e80d..00
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/Ia32/AsmF
> uncs.S
> +++ /dev/null
> @@ -1,415 +0,0 @@
> -#--
> -#
> -# Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> -# 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.
> -#
> -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -#
> -# Module Name:
> -#
> -# AsmFuncs.S
> -#
> -# Abstract:
> -#
> -# Debug interrupt handle functions.
> -#
> -#--
> -
> -#include "DebugException.h"
> -
> -ASM_GLOBAL ASM_PFX(InterruptProcess)
> -ASM_GLOBAL ASM_PFX(Exception0Handle)
> -ASM_GLOBAL ASM_PFX(ExceptionStubHeaderSize)
> -ASM_GLOBAL ASM_PFX(TimerInterruptHandle)
> -ASM_GLOBAL ASM_PFX(CommonEntry)
> -
> -.macro AGENT_HANDLER_SIGNATURE
> - .byte 0x41, 0x47, 0x54, 0x48 # AGENT_HANDLER_SIGNATURE
> SIGNATURE_32('A','G','T','H')
> -.endm
> -
> -.data
> -
> -ASM_PFX(ExceptionStubHeaderSize): .long ASM_PFX(Exception1Handle) -
> ASM_PFX(Exception0Handle)
> -
> -.text
> -
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception0Handle):
> - cli
> - pushl %eax
> - mov $0, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception1Handle):
> - cli
> - pushl %eax
> - mov $1, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception2Handle):
> - cli
> - pushl %eax
> - mov $2, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception3Handle):
> - cli
> - pushl %eax
> - mov $3, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception4Handle):
> - cli
> - pushl %eax
> - mov $4, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception5Handle):
> - cli
> - pushl %eax
> - mov $5, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception6Handle):
> - cli
> - pushl %eax
> - mov $6, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception7Handle):
> - cli
> - pushl %eax
> - mov $7, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception8Handle):
> - cli
> - pushl %eax
> - mov $8, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception9Handle):
> - cli
> - pushl %eax
> - mov $9, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(Exception10Handle):
> - cli
> - pushl %eax
> - mov $10, %eax
> - jmp ASM_PFX(CommonEntry)
> -AGENT_HANDLER_SIGNATURE
> -ASM_PFX(E
Re: [edk2] [PATCH v4 13/14] SourceLevelDebugPkg/PeCoffExtraActionLibDebug: Remove .S files
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zhang, Shenglei > Sent: Monday, April 01, 2019 4:30 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A > Subject: [PATCH v4 13/14] SourceLevelDebugPkg/PeCoffExtraActionLibDebug: > Remove .S files > > .nasm file has been added for X86 arch. .S assembly code > is not required any more. > https://bugzilla.tianocore.org/show_bug.cgi?id=1594 > > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > .../Ia32/IntHandler.S | 28 --- > .../PeCoffExtraActionLibDebug.inf | 2 -- > .../X64/IntHandler.S | 28 --- > 3 files changed, 58 deletions(-) > delete mode 100644 > SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > delete mode 100644 > SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > > diff --git > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > deleted file mode 100644 > index 69c903788c..00 > --- > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/Ia32/IntHandler.S > +++ /dev/null > @@ -1,28 +0,0 @@ > -#-- > -# > -# Copyright (c) 2013, Intel Corporation. All rights reserved. > -# 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. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# IntHandler.S > -# > -# Abstract: > -# > -# Assembly interrupt handler function. > -# > -#-- > - > -ASM_GLOBAL ASM_PFX(AsmInterruptHandle) > - > -.text > -ASM_PFX(AsmInterruptHandle): > - cli > - movb $1, %al > - iretl > diff --git > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > index 1c52a000b0..fd56b8c94a 100644 > --- > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > +++ > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraAction > LibDebug.inf > @@ -35,12 +35,10 @@ > [Sources.IA32] >Ia32/IntHandlerFuncs.c >Ia32/IntHandler.nasm > - Ia32/IntHandler.S > > [Sources.X64] >X64/IntHandlerFuncs.c >X64/IntHandler.nasm > - X64/IntHandler.S > > [Packages] >MdePkg/MdePkg.dec > diff --git > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > b/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > deleted file mode 100644 > index 108b40cf6d..00 > --- > a/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/X64/IntHandler.S > +++ /dev/null > @@ -1,28 +0,0 @@ > -#-- > -# > -# Copyright (c) 2013, Intel Corporation. All rights reserved. > -# 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. > -# > -# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > -# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > -# > -# Module Name: > -# > -# IntHandler.S > -# > -# Abstract: > -# > -# Assembly interrupt handler function. > -# > -#-- > - > -ASM_GLOBAL ASM_PFX(AsmInterruptHandle) > - > -.text > -ASM_PFX(AsmInterruptHandle): > - cli > - movb $1, %al > - iretq > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for coreboot and Slim Bootloader
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Monday, April 01, 2019 10:05 PM > To: Ni, Ray; Dong, Guo; edk2-devel@lists.01.org > Cc: Wu, Hao A; Kinney, Michael D; Ma, Maurice; David Woodhouse > Subject: Re: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for > coreboot and Slim Bootloader > > (+David) > > On 03/29/19 06:15, Ni, Ray wrote: > > > > Guo, > > Just to double confirm: UefiPayloadPkg will not require Legacy8254 timer > support. > > The old packages Coreboot*Pkgs will be removed. > > Which means now only QEMU/OVMF needs the Legacy8254 support. > > > > Laszlo, > > Now since QEMU/OVMF is the only consumer of the Legacy8254 driver, do > you > > agree that the Legacy8254 is moved to OvmfPkg? > > Note: We agreed that Legacy8259 will be moved to OvmfPkg/Csm directory > and > > that decision is not going to be changed by this new situation. > > The last status (up to & including comment 12) in > <https://bugzilla.tianocore.org/show_bug.cgi?id=1496> was that: > > (1) 8254TimerDxe would remain a generic driver, with the minimal > interrupt controller programming that it needs flattened into it (no > dependency on gEfiLegacy8259ProtocolGuid) > > (2) the 8259InterruptControllerDxe driver (producing > gEfiLegacy8259ProtocolGuid) would move under OvmfPkg/Csm. > > Now, if 8254TimerDxe becomes specific to OvmfPkg, then I think it's not > necessary to modify it -- it can continue depending on > gEfiLegacy8259ProtocolGuid. Simply move both drivers from PcAtChipsetPkg > to OvmfPkg. (Note: *not* to OvmfPkg/Csm). > > Hao: can you please update > <https://bugzilla.tianocore.org/show_bug.cgi?id=1496> accordingly? (If > you agree, that is.) Sure. I will double confirm the latest direction and update the above BZ. Best Regards, Hao Wu > > Thanks > Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF
Reviewed-by: Hao Wu I will push this patch shortly to address the build failure for SourceLevelDebugPkg. Best Regards, Hao Wu > -Original Message- > From: Zhang, Shenglei > Sent: Wednesday, April 03, 2019 2:32 PM > To: edk2-devel@lists.01.org > Cc: Wu, Hao A; Zhang, Shenglei > Subject: [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S > in INF > > AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680. > And also it should be removed in SecPeiDebugAgentLib.inf and > SmmDebugAgentLib.inf. > > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 -- > SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 -- > 2 files changed, 4 deletions(-) > > diff --git > a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > index 03ebbb6e74..8b81795d96 100644 > --- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > @@ -39,14 +39,12 @@ >DebugAgentCommon/DebugMp.h > > [Sources.Ia32] > - DebugAgentCommon/Ia32/AsmFuncs.S >DebugAgentCommon/Ia32/AsmFuncs.nasm >DebugAgentCommon/Ia32/ArchDebugSupport.h >DebugAgentCommon/Ia32/ArchDebugSupport.c >DebugAgentCommon/Ia32/DebugException.h > > [Sources.X64] > - DebugAgentCommon/X64/AsmFuncs.S >DebugAgentCommon/X64/AsmFuncs.nasm >DebugAgentCommon/X64/ArchDebugSupport.h >DebugAgentCommon/X64/ArchDebugSupport.c > diff --git > a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > index 08ed1777be..f1b32daab3 100644 > --- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > @@ -39,14 +39,12 @@ >DebugAgentCommon/DebugMp.h > > [Sources.Ia32] > - DebugAgentCommon/Ia32/AsmFuncs.S >DebugAgentCommon/Ia32/AsmFuncs.nasm >DebugAgentCommon/Ia32/ArchDebugSupport.h >DebugAgentCommon/Ia32/ArchDebugSupport.c >DebugAgentCommon/Ia32/DebugException.h > > [Sources.X64] > - DebugAgentCommon/X64/AsmFuncs.S >DebugAgentCommon/X64/AsmFuncs.nasm >DebugAgentCommon/X64/ArchDebugSupport.h >DebugAgentCommon/X64/ArchDebugSupport.c > -- > 2.18.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove AsmFuncs.S in INF
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Hao A > Sent: Wednesday, April 03, 2019 3:27 PM > To: Zhang, Shenglei; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] SourceLevelDebugPkg/DebugAgent: Remove > AsmFuncs.S in INF > > Reviewed-by: Hao Wu > > I will push this patch shortly to address the build failure for > SourceLevelDebugPkg. Pushed via commit 7ed72121b753a7493a8c5bf3711b5efbc5e80491. > > Best Regards, > Hao Wu > > > > -Original Message- > > From: Zhang, Shenglei > > Sent: Wednesday, April 03, 2019 2:32 PM > > To: edk2-devel@lists.01.org > > Cc: Wu, Hao A; Zhang, Shenglei > > Subject: [PATCH] SourceLevelDebugPkg/DebugAgent: Remove > AsmFuncs.S > > in INF > > > > AsmFuncs.S is removed at c7d22535f7dc90b8fef70153ef98549228569680. > > And also it should be removed in SecPeiDebugAgentLib.inf and > > SmmDebugAgentLib.inf. > > > > Cc: Hao Wu > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Shenglei Zhang > > --- > > SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf | 2 - > - > > SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf| 2 - > - > > 2 files changed, 4 deletions(-) > > > > diff --git > > a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > index 03ebbb6e74..8b81795d96 100644 > > --- a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > +++ > b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > > @@ -39,14 +39,12 @@ > >DebugAgentCommon/DebugMp.h > > > > [Sources.Ia32] > > - DebugAgentCommon/Ia32/AsmFuncs.S > >DebugAgentCommon/Ia32/AsmFuncs.nasm > >DebugAgentCommon/Ia32/ArchDebugSupport.h > >DebugAgentCommon/Ia32/ArchDebugSupport.c > >DebugAgentCommon/Ia32/DebugException.h > > > > [Sources.X64] > > - DebugAgentCommon/X64/AsmFuncs.S > >DebugAgentCommon/X64/AsmFuncs.nasm > >DebugAgentCommon/X64/ArchDebugSupport.h > >DebugAgentCommon/X64/ArchDebugSupport.c > > diff --git > > a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > index 08ed1777be..f1b32daab3 100644 > > --- a/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > +++ b/SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf > > @@ -39,14 +39,12 @@ > >DebugAgentCommon/DebugMp.h > > > > [Sources.Ia32] > > - DebugAgentCommon/Ia32/AsmFuncs.S > >DebugAgentCommon/Ia32/AsmFuncs.nasm > >DebugAgentCommon/Ia32/ArchDebugSupport.h > >DebugAgentCommon/Ia32/ArchDebugSupport.c > >DebugAgentCommon/Ia32/DebugException.h > > > > [Sources.X64] > > - DebugAgentCommon/X64/AsmFuncs.S > >DebugAgentCommon/X64/AsmFuncs.nasm > >DebugAgentCommon/X64/ArchDebugSupport.h > >DebugAgentCommon/X64/ArchDebugSupport.c > > -- > > 2.18.0.windows.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] More info on revision2 and revision3 of EFI_BLOCK_IO_PROTOCOL
Hi Jabir,
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jabir
> Sent: Friday, January 11, 2019 4:17 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] More info on revision2 and revision3 of
> EFI_BLOCK_IO_PROTOCOL
>
> Hi All,
>
> EFI_BLOCK_IO_MEDIA has two new fields, LowestAlignedLba and
> LogicalBlocksPerPhysicalBlock, added in the revision2 and a field
> OptimalTransferLengthGranularity added in revision3 of
> EFI_BLOCK_IO_PROTOCOL.
> Couldn’t find more info from https://github.com/tianocore/edk2.
>
> Please help to understand how these fields are consumed by the system
> firmware?
Maybe you can check the latest UEFI Specification Version 2.7 (Errata A):
http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf
Section 5.3.1, to see if you can get the information.
Best Regards,
Hao Wu
>
> typedef struct {
> UINT32 MediaId;
> BOOLEAN RemovableMedia;
> BOOLEAN MediaPresent;
> BOOLEAN LogicalPartition;
> BOOLEAN ReadOnly;
> BOOLEAN WriteCaching;
> UINT32 BlockSize;
> UINT32 IoAlign;
> EFI_LBA LastBlock;
> EFI_LBA LowestAlignedLba; //added in Revision 2
> UINT32 LogicalBlocksPerPhysicalBlock; //added in Revision 2
> UINT32 OptimalTransferLengthGranularity; // added in Revision 3
> } EFI_BLOCK_IO_MEDIA;
>
> Thanks,
> Jabir
> ___
> 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 V2 03/15] MdeModulePkg Variable: Not get NV PCD in VariableWriteServiceInitialize
Hi Star,
One minor comment below.
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V2 03/15] MdeModulePkg Variable: Not get NV PCD in
> VariableWriteServiceInitialize
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add macro NV_STORAGE_VARIABLE_BASE.
> Not get NV PCD in VariableWriteServiceInitialize, but in
> FtwNotificationEvent/SmmFtwNotificationEvent, then
> VariableWriteServiceInitialize could be not aware the NV
> storage is real or emulated.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 20
> ++--
> .../Universal/Variable/RuntimeDxe/Variable.h | 9 +++--
> .../Universal/Variable/RuntimeDxe/VariableDxe.c | 12
> .../Universal/Variable/RuntimeDxe/VariableSmm.c | 16 +++
> -
> 4 files changed, 28 insertions(+), 29 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 0b675c8f36df..424f92a53757 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3770,10 +3770,7 @@ InitRealNonVolatileVariableStore (
> return EFI_OUT_OF_RESOURCES;
>}
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> + NvStorageBase = NV_STORAGE_VARIABLE_BASE;
>ASSERT (NvStorageBase != 0);
>
>//
> @@ -4027,7 +4024,7 @@ FlushHobVariableToFlash (
> }
>
> /**
> - Initializes variable write service after FTW was ready.
> + Initializes variable write service.
>
>@retval EFI_SUCCESS Function successfully executed.
>@retval Others Fail to initialize the variable service.
> @@ -4041,23 +4038,10 @@ VariableWriteServiceInitialize (
>EFI_STATUS Status;
>UINTN Index;
>UINT8 Data;
> - EFI_PHYSICAL_ADDRESSVariableStoreBase;
> - EFI_PHYSICAL_ADDRESSNvStorageBase;
>VARIABLE_ENTRY_PROPERTY *VariableEntry;
>
>AcquireLockOnlyAtBootTime(&mVariableModuleGlobal-
> >VariableGlobal.VariableServicesLock);
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> - VariableStoreBase = NvStorageBase + (mNvFvHeaderCache-
> >HeaderLength);
> -
> - //
> - // Let NonVolatileVariableBase point to flash variable store base directly
> after FTW ready.
> - //
> - mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase =
> VariableStoreBase;
> -
>//
>// Check if the free area is really free.
>//
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> index 938eb5de61fa..566e7268d187 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> @@ -2,7 +2,7 @@
>The internal header file includes the common header files, defines
>internal structure and functions used by Variable modules.
>
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> 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
> @@ -46,6 +46,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "PrivilegePolymorphic.h"
>
> +#define NV_STORAGE_VARIABLE_BASE (EFI_PHYSICAL_ADDRESS) \
> + (PcdGet64
> (PcdFlashNvStorageVariableBase64) != 0 ? \
> +PcdGet64
> (PcdFlashNvStorageVariableBase64) : \
> +PcdGet32 (PcdFlashNvStorageVariableBase))
> +
> #define EFI_VARIABLE_ATTRIB
Re: [edk2] [PATCH V2 01/15] MdeModulePkg Variable: Add some missing changes for 9b18845
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Star Zeng
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A; Zeng, Star
> Subject: [edk2] [PATCH V2 01/15] MdeModulePkg Variable: Add some
> missing changes for 9b18845
>
> To improve performance 9b18845a4b4cd1d2cf004cbc1cadf8a93ccb37ea
> changed the code which read from physical MMIO address to read
> from memory cache, but it missed some places that could be updated
> at the same away for performance optimization.
>
> The patch updates these places as supplementary.
>
> I found them when updating code for
> https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c| 12 +
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 6 +++---
> 2 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 443cf07144a1..99d487adac9e 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -16,7 +16,7 @@
>VariableServiceSetVariable() should also check authenticate data to avoid
> buffer overflow,
>integer overflow. It should also check attribute to avoid authentication
> bypass.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> (C) Copyright 2015-2018 Hewlett Packard Enterprise Development LP
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -262,13 +262,12 @@ UpdateVariableStore (
>UINT8 *CurrBuffer;
>EFI_LBA LbaNumber;
>UINTN Size;
> - EFI_FIRMWARE_VOLUME_HEADER *FwVolHeader;
>VARIABLE_STORE_HEADER *VolatileBase;
>EFI_PHYSICAL_ADDRESSFvVolHdr;
>EFI_PHYSICAL_ADDRESSDataPtr;
>EFI_STATUS Status;
>
> - FwVolHeader = NULL;
> + FvVolHdr= 0;
>DataPtr = DataPtrIndex;
>
>//
> @@ -281,7 +280,6 @@ UpdateVariableStore (
> Status = Fvb->GetPhysicalAddress(Fvb, &FvVolHdr);
> ASSERT_EFI_ERROR (Status);
>
> -FwVolHeader = (EFI_FIRMWARE_VOLUME_HEADER *) ((UINTN)
> FvVolHdr);
> //
> // Data Pointer should point to the actual Address where data is to be
> // written.
> @@ -290,7 +288,7 @@ UpdateVariableStore (
>DataPtr += mVariableModuleGlobal-
> >VariableGlobal.NonVolatileVariableBase;
> }
>
> -if ((DataPtr + DataSize) > ((EFI_PHYSICAL_ADDRESS) (UINTN) ((UINT8 *)
> FwVolHeader + FwVolHeader->FvLength))) {
> +if ((DataPtr + DataSize) > (FvVolHdr + mNvFvHeaderCache->FvLength)) {
>return EFI_OUT_OF_RESOURCES;
> }
>} else {
> @@ -317,7 +315,7 @@ UpdateVariableStore (
>//
>// If we are here we are dealing with Non-Volatile Variables.
>//
> - LinearOffset = (UINTN) FwVolHeader;
> + LinearOffset = (UINTN) FvVolHdr;
>CurrWritePtr = (UINTN) DataPtr;
>CurrWriteSize = DataSize;
>CurrBuffer= Buffer;
> @@ -2739,7 +2737,7 @@ UpdateVariable (
>}
> }
>
> -State = Variable->CurrPtr->State;
> +State = CacheVariable->CurrPtr->State;
> State &= VAR_DELETED;
>
> Status = UpdateVariableStore (
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index 23186176be75..f7185df3a7eb 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -3,7 +3,7 @@
>and volatile storage space and install variable architecture protocol.
>
> Copyright (C) 2013, Red Hat, Inc.
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> (C) Copyright 2015 Hewlett Packard Enterprise Development LP
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> @@ -402,8 +402,8 @@ FtwNotificationEvent (
>//
>// Mark the variable storage region
Re: [edk2] [PATCH V2 02/15] MdeModulePkg Variable: Abstract InitRealNonVolatileVariableStore
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V2 02/15] MdeModulePkg Variable: Abstract
> InitRealNonVolatileVariableStore
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Abstract InitRealNonVolatileVariableStore from
> InitNonVolatileVariableStore.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 86 +++
> ---
> 1 file changed, 58 insertions(+), 28 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 99d487adac9e..0b675c8f36df 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3728,9 +3728,9 @@ GetMaxVariableSize (
> }
>
> /**
> - Init non-volatile variable store.
> + Init real non-volatile variable store.
>
> - @param[out] NvFvHeaderOutput pointer to non-volatile FV header
> address.
> + @param[out] VariableStoreBase Output pointer to real non-volatile
> variable store base.
>
>@retval EFI_SUCCESS Function successfully executed.
>@retval EFI_OUT_OF_RESOURCES Fail to allocate enough memory
> resource.
> @@ -3738,16 +3738,13 @@ GetMaxVariableSize (
>
> **/
> EFI_STATUS
> -InitNonVolatileVariableStore (
> - OUT EFI_FIRMWARE_VOLUME_HEADER**NvFvHeader
> +InitRealNonVolatileVariableStore (
> + OUT EFI_PHYSICAL_ADDRESS *VariableStoreBase
>)
> {
>EFI_FIRMWARE_VOLUME_HEADER*FvHeader;
> - VARIABLE_HEADER *Variable;
> - VARIABLE_HEADER *NextVariable;
> - EFI_PHYSICAL_ADDRESS VariableStoreBase;
> - UINT64VariableStoreLength;
> - UINTN VariableSize;
> + VARIABLE_STORE_HEADER *VariableStore;
> + UINT32VariableStoreLength;
>EFI_HOB_GUID_TYPE *GuidHob;
>EFI_PHYSICAL_ADDRESS NvStorageBase;
>UINT8 *NvStorageData;
> @@ -3777,6 +3774,8 @@ InitNonVolatileVariableStore (
>if (NvStorageBase == 0) {
> NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
>}
> + ASSERT (NvStorageBase != 0);
> +
>//
>// Copy NV storage data to the memory buffer.
>//
> @@ -3826,24 +3825,23 @@ InitNonVolatileVariableStore (
> return EFI_VOLUME_CORRUPTED;
>}
>
> - VariableStoreBase = (UINTN) FvHeader + FvHeader->HeaderLength;
> + VariableStore = (VARIABLE_STORE_HEADER *) ((UINTN) FvHeader +
> FvHeader->HeaderLength);
>VariableStoreLength = NvStorageSize - FvHeader->HeaderLength;
> + ASSERT (sizeof (VARIABLE_STORE_HEADER) <= VariableStoreLength);
> + ASSERT (VariableStore->Size == VariableStoreLength);
>
> - mNvFvHeaderCache = FvHeader;
> - mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase =
> VariableStoreBase;
> - mNvVariableCache = (VARIABLE_STORE_HEADER *) (UINTN)
> VariableStoreBase;
> - if (GetVariableStoreStatus (mNvVariableCache) != EfiValid) {
> + //
> + // Check if the Variable Store header is not corrupted
> + //
> + if (GetVariableStoreStatus (VariableStore) != EfiValid) {
> FreePool (NvStorageData);
> -mNvFvHeaderCache = NULL;
> -mNvVariableCache = NULL;
> DEBUG((EFI_D_ERROR, "Variable Store header is corrupted\n"));
> return EFI_VOLUME_CORRUPTED;
>}
> - ASSERT(mNvVariableCache->Size == VariableStoreLength);
>
> - ASSERT (sizeof (VARIABLE_STORE_HEADER) <= VariableStoreLength);
> + mNvFvHeaderCache = FvHeader;
>
> - mVariableModuleGlobal->VariableGlobal.AuthFormat =
> (BOOLEAN)(CompareGuid (&mNvVariableCache->Signature,
> &gEfiAuthenticatedVariableGuid));
> + *VariableStoreBase = (EFI_PHYSICAL_ADDRESS) (UINTN) VariableStore;
>
>HwErrStorageSize = PcdGet32 (PcdHwErrStorageSize);
>MaxUserNvVariableSpaceSize = PcdGet32
> (PcdMaxUserNvVariableSpaceSize);
> @@ -3878,14 +3876,45 @@ InitNonVolatileVariableStore (
>//
>ASSERT (GetNonVolatileMaxVariableSize () < (VariableStoreLength - sizeof
> (VARI
Re: [edk2] [PATCH V2 04/15] MdeModulePkg Variable: Abstract VariableWriteServiceInitializeDxe/Smm
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V2 04/15] MdeModulePkg Variable: Abstract
> VariableWriteServiceInitializeDxe/Smm
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Abstract VariableWriteServiceInitializeDxe/Smm from
> FtwNotificationEvent/SmmFtwNotificationEvent, then
> VariableWriteServiceInitializeDxe/Smm could be not aware
> the NV storage is real or emulated.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/VariableDxe.c| 55 ++--
> --
> .../Universal/Variable/RuntimeDxe/VariableSmm.c| 43
> -
> 2 files changed, 66 insertions(+), 32 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index baba6729c1c2..5131e6f351e4 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -346,6 +346,40 @@ OnEndOfDxe (
> }
>
> /**
> + Initializes variable write service for DXE.
> +
> +**/
> +VOID
> +VariableWriteServiceInitializeDxe (
> + VOID
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = VariableWriteServiceInitialize ();
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Variable write service initialization failed.
> Status = %r\n", Status));
> + }
> +
> + //
> + // Some Secure Boot Policy Var (SecureBoot, etc) updates following other
> + // Secure Boot Policy Variable change. Record their initial value.
> + //
> + RecordSecureBootPolicyVarData();
> +
> + //
> + // Install the Variable Write Architectural protocol.
> + //
> + Status = gBS->InstallProtocolInterface (
> + &mHandle,
> + &gEfiVariableWriteArchProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + ASSERT_EFI_ERROR (Status);
> +}
> +
> +/**
>Fault Tolerant Write protocol notification event handler.
>
>Non-Volatile variable write may needs FTW protocol to reclaim when
> @@ -428,27 +462,10 @@ FtwNotificationEvent (
> }
>}
>
> - Status = VariableWriteServiceInitialize ();
> - if (EFI_ERROR (Status)) {
> -DEBUG ((DEBUG_ERROR, "Variable write service initialization failed.
> Status
> = %r\n", Status));
> - }
> -
>//
> - // Some Secure Boot Policy Var (SecureBoot, etc) updates following other
> - // Secure Boot Policy Variable change. Record their initial value.
> + // Initializes variable write service after FTW was ready.
>//
> - RecordSecureBootPolicyVarData();
> -
> - //
> - // Install the Variable Write Architectural protocol.
> - //
> - Status = gBS->InstallProtocolInterface (
> - &mHandle,
> - &gEfiVariableWriteArchProtocolGuid,
> - EFI_NATIVE_INTERFACE,
> - NULL
> - );
> - ASSERT_EFI_ERROR (Status);
> + VariableWriteServiceInitializeDxe ();
>
>//
>// Close the notify event to avoid install
> gEfiVariableWriteArchProtocolGuid
> again.
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> index 018587ed7373..e63af812534e 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> @@ -846,6 +846,34 @@ SmmEndOfDxeCallback (
> }
>
> /**
> + Initializes variable write service for SMM.
> +
> +**/
> +VOID
> +VariableWriteServiceInitializeSmm (
> + VOID
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = VariableWriteServiceInitialize ();
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Variable write service initialization failed.
> Status = %r\n", Status));
> + }
> +
> + //
> + // Notify the variable wrapper driver the variable write service is ready
> + //
> + Status = gBS->InstallProtocolInterface (
> + &mSmmVariableHandle,
> + &gSmmVariableWriteGuid,
> + EFI_NATIVE_INTERFACE,
> +
Re: [edk2] [PATCH V2 05/15] MdeModulePkg: Add PcdEmuVariableNvModeEnable in dec
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zeng, Star > Sent: Monday, January 14, 2019 11:20 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star; Wang, Jian J; Wu, Hao A > Subject: [PATCH V2 05/15] MdeModulePkg: Add > PcdEmuVariableNvModeEnable in dec > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > Add PcdEmuVariableNvModeEnable (support both static and > dynamic) to indicate if Variable driver will enable > emulated variable NV mode. > > This patch prepares for adding emulated variable NV mode > support in VariableRuntimeDxe. > > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > Reviewed-by: Laszlo Ersek > --- > MdeModulePkg/MdeModulePkg.dec | 10 -- > MdeModulePkg/MdeModulePkg.uni | 10 -- > 2 files changed, 16 insertions(+), 4 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > index 217ede1f7163..8fbc0af61365 100644 > --- a/MdeModulePkg/MdeModulePkg.dec > +++ b/MdeModulePkg/MdeModulePkg.dec > @@ -3,7 +3,7 @@ > # It also provides the definitions(including PPIs/PROTOCOLs/GUIDs and > library classes) > # and libraries instances, which are used for those modules. > # > -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. > # Copyright (c) 2016, Linaro Ltd. All rights reserved. > # (C) Copyright 2016 Hewlett Packard Enterprise Development LP > # Copyright (c) 2017, AMD Incorporated. All rights reserved. > @@ -1586,7 +1586,13 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic, PcdsDynamicEx] ># @Prompt 64-bit Base address of flash FTW working block range. > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64 > |0x0|UINT64|0x8010 > > - ## This PCD defines a reserved memory range for the EMU Variable > driver's NV Variable Store. > + ## Indicates if Variable driver will enable emulated variable NV > mode. > + # TRUE - An EMU variable NV storage will be allocated or reserved for NV > variables. > + # FALSE - No EMU variable NV storage will be allocated or reserved for > NV variables. > + # @Prompt EMU variable NV mode enable. > + > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE > |BOOLEAN|0x0111 > + > + ## This PCD defines a reserved memory range for EMU variable NV storage. ># The range is valid if non-zero. The memory range size must be > PcdVariableStoreSize. ># @Prompt Reserved memory range for EMU variable NV storage. > > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0|U > INT64|0x4008 > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni > index 35af744d89be..9c413a98f65d 100644 > --- a/MdeModulePkg/MdeModulePkg.uni > +++ b/MdeModulePkg/MdeModulePkg.uni > @@ -4,7 +4,7 @@ > // It also provides the definitions(including PPIs/PROTOCOLs/GUIDs and > library classes) > // and libraries instances, which are used for those modules. > // > -// Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +// Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. > // > // This program and the accompanying materials are licensed and made > available under > // the terms and conditions of the BSD License that accompanies this > distribution. > @@ -389,9 +389,15 @@ > > #string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdFlashNvStorageFtwWorkingBa > se64_HELP #language en-US "64-bit Base address of the FTW working block > range in flash device. If PcdFlashNvStorageFtwWorkingSize is larger than > one block size, this value should be block size aligned." > > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvModeEnable_ > PROMPT #language en-US "EMU variable NV mode enable" > + > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvModeEnable_ > HELP #language en-US "Indicates if Variable driver will enable emulated > variable NV mode." > + > "TRUE - An EMU variable NV > storage will be allocated or reserved for NV variables." > + > "FALSE - No EMU variable NV > storage will be allocated or reserved for NV variables." > + > #string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _PROMPT #language en-US "Reserved memory range for EMU variable NV > stora
Re: [edk2] [PATCH V2 07/15] MdeModulePkg Variable: type case VolatileBase to UINTN directly
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A; Laszlo Ersek
> Subject: [PATCH V2 07/15] MdeModulePkg Variable: type case VolatileBase
> to UINTN directly
>
> Simplify
> ((UINTN) ((UINT8 *) VolatileBase + VolatileBase->Size))
> to
> ((UINTN) VolatileBase + VolatileBase->Size)
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 4d524db30fec..4c8e1d8cf4f1 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -301,7 +301,7 @@ UpdateVariableStore (
>DataPtr += mVariableModuleGlobal-
> >VariableGlobal.VolatileVariableBase;
> }
>
> -if ((DataPtr + DataSize) > ((UINTN) ((UINT8 *) VolatileBase +
> VolatileBase-
> >Size))) {
> +if ((DataPtr + DataSize) > ((UINTN) VolatileBase + VolatileBase->Size)) {
>return EFI_OUT_OF_RESOURCES;
> }
>
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2 06/15] MdeModulePkg Variable: Remove CacheOffset in UpdateVariable()
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Monday, January 14, 2019 11:20 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A; Laszlo Ersek
> Subject: [PATCH V2 06/15] MdeModulePkg Variable: Remove CacheOffset in
> UpdateVariable()
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> CacheOffset could be removed in UpdateVariable() after
> //
> // update the memory copy of Flash region.
> //
> CopyMem (
> (UINT8 *)mNvVariableCache + CacheOffset,
> (UINT8 *)NextVariable, VarSize
>);
>
> is moved to be before mVariableModuleGlobal-
> >NonVolatileLastVariableOffset
> value is updated, like right before
>
> mVariableModuleGlobal->NonVolatileLastVariableOffset +=
> HEADER_ALIGN (VarSize);
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 424f92a53757..4d524db30fec 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -2139,7 +2139,6 @@ UpdateVariable (
>VARIABLE_POINTER_TRACK *Variable;
>VARIABLE_POINTER_TRACK NvVariable;
>VARIABLE_STORE_HEADER *VariableStoreHeader;
> - UINTN CacheOffset;
>UINT8 *BufferForMerge;
>UINTN MergedBufSize;
>BOOLEAN DataReady;
> @@ -2577,7 +2576,6 @@ UpdateVariable (
> //
> // Step 1:
> //
> -CacheOffset = mVariableModuleGlobal->NonVolatileLastVariableOffset;
> Status = UpdateVariableStore (
> &mVariableModuleGlobal->VariableGlobal,
> FALSE,
> @@ -2643,6 +2641,11 @@ UpdateVariable (
>goto Done;
> }
>
> +//
> +// update the memory copy of Flash region.
> +//
> +CopyMem ((UINT8 *)mNvVariableCache + mVariableModuleGlobal-
> >NonVolatileLastVariableOffset, (UINT8 *)NextVariable, VarSize);
> +
> mVariableModuleGlobal->NonVolatileLastVariableOffset +=
> HEADER_ALIGN (VarSize);
>
> if ((Attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) != 0) {
> @@ -2653,10 +2656,6 @@ UpdateVariable (
> mVariableModuleGlobal->CommonUserVariableTotalSize +=
> HEADER_ALIGN (VarSize);
>}
> }
> -//
> -// update the memory copy of Flash region.
> -//
> -CopyMem ((UINT8 *)mNvVariableCache + CacheOffset, (UINT8
> *)NextVariable, VarSize);
>} else {
> //
> // Create a volatile variable.
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 03/17] MdeModulePkg Variable: Move "extern XXX" to Variable.h
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V3 03/17] MdeModulePkg Variable: Move "extern XXX" to
> Variable.h
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Move "extern XXX" to Variable.h from VariableDxe.c/VariableSmm.c.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h| 11
> ---
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 4
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c | 3 ---
> 3 files changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> index 938eb5de61fa..90507a8e64f6 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> @@ -792,9 +792,14 @@ InitializeVariableQuota (
>VOID
>);
>
> -extern VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
> -
> -extern AUTH_VAR_LIB_CONTEXT_OUT mAuthContextOut;
> +extern VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
> +extern EFI_FIRMWARE_VOLUME_HEADER *mNvFvHeaderCache;
> +extern VARIABLE_STORE_HEADER*mNvVariableCache;
> +extern VARIABLE_INFO_ENTRY *gVariableInfo;
> +extern BOOLEAN mEndOfDxe;
> +extern VAR_CHECK_REQUEST_SOURCE mRequestSource;
> +
> +extern AUTH_VAR_LIB_CONTEXT_OUT mAuthContextOut;
>
> /**
>Finds variable in storage blocks of volatile and non-volatile storage
> areas.
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> index f7185df3a7eb..f1304c9dbccc 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> @@ -17,13 +17,9 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "Variable.h"
>
> -extern VARIABLE_STORE_HEADER*mNvVariableCache;
> -extern EFI_FIRMWARE_VOLUME_HEADER *mNvFvHeaderCache;
> -extern VARIABLE_INFO_ENTRY *gVariableInfo;
> EFI_HANDLE mHandle= NULL;
> EFI_EVENT mVirtualAddressChangeEvent = NULL;
> EFI_EVENT mFtwRegistration = NULL;
> -extern BOOLEAN mEndOfDxe;
> VOID***mVarCheckAddressPointer = NULL;
> UINTN mVarCheckAddressPointerCount = 0;
> EDKII_VARIABLE_LOCK_PROTOCOLmVariableLock =
> { VariableLockRequestToLock };
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> index 8c53f84ff6e8..623badb0c755 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.c
> @@ -37,14 +37,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
> #include
> #include "Variable.h"
>
> -extern VARIABLE_INFO_ENTRY *gVariableInfo;
> EFI_HANDLE mSmmVariableHandle
> = NULL;
> EFI_HANDLE mVariableHandle
> = NULL;
> BOOLEAN mAtRuntime
> = FALSE;
> UINT8*mVariableBufferPayload
> = NULL;
> UINTN
> mVariableBufferPayloadSize;
> -extern BOOLEAN mEndOfDxe;
> -extern VAR_CHECK_REQUEST_SOURCE mRequestSource;
>
> /**
>SecureBoot Hook for SetVariable.
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 11/17] MdeModulePkg VariablePei: Don't check BOOT_IN_RECOVERY_MODE
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:30 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V3 11/17] MdeModulePkg VariablePei: Don't check
> BOOT_IN_RECOVERY_MODE
>
> Don't check BOOT_IN_RECOVERY_MODE, but check
> PcdEmuVariableNvModeEnable
> which platform can configure flexibly.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> MdeModulePkg/Universal/Variable/Pei/Variable.c | 8 +---
> MdeModulePkg/Universal/Variable/Pei/VariablePei.inf | 3 ++-
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/Pei/Variable.c
> b/MdeModulePkg/Universal/Variable/Pei/Variable.c
> index 77b3eaeb210d..148c1cfefd90 100644
> --- a/MdeModulePkg/Universal/Variable/Pei/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/Pei/Variable.c
> @@ -2,7 +2,7 @@
>Implement ReadOnly Variable Services required by PEIM and install
>PEI ReadOnly Varaiable2 PPI. These services operates the non volatile
> storage space.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> 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
> @@ -584,9 +584,9 @@ GetVariableStore (
>break;
>
> case VariableStoreTypeNv:
> - if (GetBootModeHob () != BOOT_IN_RECOVERY_MODE) {
> + if (!PcdGetBool (PcdEmuVariableNvModeEnable)) {
> //
> -// The content of NV storage for variable is not reliable in recovery
> boot mode.
> +// Emulated non-volatile variable mode is not enabled.
> //
>
> NvStorageSize = PcdGet32 (PcdFlashNvStorageVariableSize);
> @@ -594,6 +594,8 @@ GetVariableStore (
> PcdGet64
> (PcdFlashNvStorageVariableBase64) :
> PcdGet32
> (PcdFlashNvStorageVariableBase)
> );
> +ASSERT (NvStorageBase != 0);
> +
> //
> // First let FvHeader point to NV storage base.
> //
> diff --git a/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> b/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> index 565efdc02116..3161617a56c2 100644
> --- a/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> +++ b/MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
> @@ -3,7 +3,7 @@
> #
> # This module implements ReadOnly Variable Services required by PEIM
> and installs PEI ReadOnly Varaiable2 PPI.
> #
> -# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> # 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
> @@ -68,6 +68,7 @@ [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase ##
> SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
> ## CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize ##
> CONSUMES
> + gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
> ## SOMETIMES_CONSUMES
>
> [Depex]
>gEdkiiFaultTolerantWriteGuid
> --
> 2.7.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 09/17] MdeModulePkg: Refine description a little for PcdEmuVariableNvStoreReserved
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zeng, Star > Sent: Tuesday, January 15, 2019 6:30 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star; Wang, Jian J; Wu, Hao A > Subject: [PATCH V3 09/17] MdeModulePkg: Refine description a little for > PcdEmuVariableNvStoreReserved > > This patch is not related directly to > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > PcdEmuVariableNvStoreReserved actually defines the base address of > reserved memory range. > > This patch refines description a little for PcdEmuVariableNvStoreReserved. > > Suggested-by: Jian J Wang > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdeModulePkg/MdeModulePkg.dec | 6 +++--- > MdeModulePkg/MdeModulePkg.uni | 4 ++-- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/MdeModulePkg/MdeModulePkg.dec > b/MdeModulePkg/MdeModulePkg.dec > index 2be77022c948..e5c32d15edcd 100644 > --- a/MdeModulePkg/MdeModulePkg.dec > +++ b/MdeModulePkg/MdeModulePkg.dec > @@ -1594,9 +1594,9 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic, PcdsDynamicEx] ># @Prompt EMU variable NV mode enable. > > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE > |BOOLEAN|0x0111 > > - ## This PCD defines a reserved memory range for EMU variable NV storage. > - # The range is valid if non-zero. The memory range size must be > PcdVariableStoreSize. > - # @Prompt Reserved memory range for EMU variable NV storage. > + ## This PCD defines the base address of reserved memory range for EMU > variable NV storage. > + # A non-ZERO value indicates a valid range reserved with size given by > PcdVariableStoreSize. > + # @Prompt Base of reserved memory range for EMU variable NV storage. > > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0|UI > NT64|0x4008 > >## This PCD defines the times to print hello world string. > diff --git a/MdeModulePkg/MdeModulePkg.uni > b/MdeModulePkg/MdeModulePkg.uni > index 2f437d78eba2..787fdf2282c3 100644 > --- a/MdeModulePkg/MdeModulePkg.uni > +++ b/MdeModulePkg/MdeModulePkg.uni > @@ -397,9 +397,9 @@ > > "TRUE - An EMU variable NV > storage will be allocated or reserved for NV variables." > > "FALSE - No EMU variable NV > storage will be allocated or reserved for NV variables." > > -#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _PROMPT #language en-US "Reserved memory range for EMU variable NV > storage" > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _PROMPT #language en-US "Base of reserved memory range for EMU > variable NV storage" > > -#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _HELP #language en-US "This PCD defines a reserved memory range for > EMU variable NV storage. The range is valid if non-zero. The memory range > size must be PcdVariableStoreSize." > +#string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdEmuVariableNvStoreReserved > _HELP #language en-US "This PCD defines the base address of reserved > memory range for EMU variable NV storage. A non-ZERO value indicates a > valid range reserved with size given by PcdVariableStoreSize." > > #string > STR_gEfiMdeModulePkgTokenSpaceGuid_PcdHelloWorldPrintTimes_PROM > PT #language en-US "HelloWorld print times" > > -- > 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V3 04/17] MdeModulePkg Variable: Not get NV PCD in VariableWriteServiceInitialize
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:29 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A
> Subject: [PATCH V3 04/17] MdeModulePkg Variable: Not get NV PCD in
> VariableWriteServiceInitialize
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add macro NV_STORAGE_VARIABLE_BASE.
> Not get NV PCD in VariableWriteServiceInitialize, but in
> FtwNotificationEvent/SmmFtwNotificationEvent, then
> VariableWriteServiceInitialize could be not aware the NV
> storage is real or emulated.
>
> This patch prepares for adding emulated variable NV mode
> support in VariableRuntimeDxe.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 20
> ++--
> .../Universal/Variable/RuntimeDxe/Variable.h | 9 +++--
> .../Universal/Variable/RuntimeDxe/VariableDxe.c | 13 -
> .../Universal/Variable/RuntimeDxe/VariableSmm.c | 15 ++-
> 4 files changed, 27 insertions(+), 30 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index 0b675c8f36df..424f92a53757 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -3770,10 +3770,7 @@ InitRealNonVolatileVariableStore (
> return EFI_OUT_OF_RESOURCES;
>}
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> + NvStorageBase = NV_STORAGE_VARIABLE_BASE;
>ASSERT (NvStorageBase != 0);
>
>//
> @@ -4027,7 +4024,7 @@ FlushHobVariableToFlash (
> }
>
> /**
> - Initializes variable write service after FTW was ready.
> + Initializes variable write service.
>
>@retval EFI_SUCCESS Function successfully executed.
>@retval Others Fail to initialize the variable service.
> @@ -4041,23 +4038,10 @@ VariableWriteServiceInitialize (
>EFI_STATUS Status;
>UINTN Index;
>UINT8 Data;
> - EFI_PHYSICAL_ADDRESSVariableStoreBase;
> - EFI_PHYSICAL_ADDRESSNvStorageBase;
>VARIABLE_ENTRY_PROPERTY *VariableEntry;
>
>AcquireLockOnlyAtBootTime(&mVariableModuleGlobal-
> >VariableGlobal.VariableServicesLock);
>
> - NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet64
> (PcdFlashNvStorageVariableBase64);
> - if (NvStorageBase == 0) {
> -NvStorageBase = (EFI_PHYSICAL_ADDRESS) PcdGet32
> (PcdFlashNvStorageVariableBase);
> - }
> - VariableStoreBase = NvStorageBase + (mNvFvHeaderCache-
> >HeaderLength);
> -
> - //
> - // Let NonVolatileVariableBase point to flash variable store base directly
> after FTW ready.
> - //
> - mVariableModuleGlobal->VariableGlobal.NonVolatileVariableBase =
> VariableStoreBase;
> -
>//
>// Check if the free area is really free.
>//
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> index 90507a8e64f6..d128d1a9c680 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.h
> @@ -2,7 +2,7 @@
>The internal header file includes the common header files, defines
>internal structure and functions used by Variable modules.
>
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> 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
> @@ -46,6 +46,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> #include "PrivilegePolymorphic.h"
>
> +#define NV_STORAGE_VARIABLE_BASE (EFI_PHYSICAL_ADDRESS) \
> + (PcdGet64
> (PcdFlashNvStorageVariableBase64) != 0 ? \
> +PcdGet64
> (PcdFlashNvStorageVariableBase64) : \
> +PcdGet32 (PcdFlashNvStorageVariableBase))
> +
> #define EFI_VARIABLE_ATTRIBUTE
Re: [edk2] [PATCH V3 10/17] MdeModulePkg Variable: Add emulated variable NV mode support
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 15, 2019 6:30 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wang, Jian J; Wu, Hao A; Kinney, Michael D; Gao, Liming; Ni,
> Ray; Laszlo Ersek; Ard Biesheuvel
> Subject: [PATCH V3 10/17] MdeModulePkg Variable: Add emulated variable
> NV mode support
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
> Merge EmuVariable and Real variable driver.
>
> Add emulated variable NV mode support in real variable driver.
> Platform can configure PcdEmuVariableNvModeEnable statically
> (build time) or dynamically (boot time) to support emulated
> variable NV mode.
>
> If PcdEmuVariableNvModeEnable is configured to dynamic, its
> value should be set before Variable driver starts to work,
> otherwise default value will take effect.
>
> Then EmuVariableRuntimeDxe could be removed, the removal of
> EmuVariableRuntimeDxe will be done after platforms are migrated
> to use the merged variable driver.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> Acked-by: Laszlo Ersek
> ---
> .../Universal/Variable/RuntimeDxe/Variable.c | 318 +++
> --
> .../Universal/Variable/RuntimeDxe/Variable.h | 1 +
> .../Universal/Variable/RuntimeDxe/VariableDxe.c| 27 +-
> .../Variable/RuntimeDxe/VariableRuntimeDxe.inf | 4 +-
> .../Universal/Variable/RuntimeDxe/VariableSmm.c| 29 +-
> .../Universal/Variable/RuntimeDxe/VariableSmm.inf | 4 +-
> 6 files changed, 271 insertions(+), 112 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> index d3df21819abe..e8e19508cd9a 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> @@ -34,6 +34,7 @@ VARIABLE_MODULE_GLOBAL *mVariableModuleGlobal;
>
> ///
> /// Define a memory cache that improves the search performance for a
> variable.
> +/// For EmuNvMode == TRUE, it will be equal to NonVolatileVariableBase.
> ///
> VARIABLE_STORE_HEADER *mNvVariableCache = NULL;
>
> @@ -273,7 +274,7 @@ UpdateVariableStore (
>//
>// Check if the Data is Volatile.
>//
> - if (!Volatile) {
> + if (!Volatile && !mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> if (Fvb == NULL) {
>return EFI_UNSUPPORTED;
> }
> @@ -296,17 +297,30 @@ UpdateVariableStore (
> // Data Pointer should point to the actual Address where data is to be
> // written.
> //
> -VolatileBase = (VARIABLE_STORE_HEADER *) ((UINTN)
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
> -if (SetByIndex) {
> - DataPtr += mVariableModuleGlobal-
> >VariableGlobal.VolatileVariableBase;
> -}
> +if (Volatile) {
> + VolatileBase = (VARIABLE_STORE_HEADER *) ((UINTN)
> mVariableModuleGlobal->VariableGlobal.VolatileVariableBase);
> + if (SetByIndex) {
> +DataPtr += mVariableModuleGlobal-
> >VariableGlobal.VolatileVariableBase;
> + }
>
> -if ((DataPtr + DataSize) > ((UINTN) VolatileBase + VolatileBase->Size)) {
> - return EFI_OUT_OF_RESOURCES;
> + if ((DataPtr + DataSize) > ((UINTN) VolatileBase +
> VolatileBase->Size)) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> +} else {
> + //
> + // Emulated non-volatile variable mode.
> + //
> + if (SetByIndex) {
> +DataPtr += (UINTN) mNvVariableCache;
> + }
> +
> + if ((DataPtr + DataSize) > ((UINTN) mNvVariableCache +
> mNvVariableCache->Size)) {
> +return EFI_OUT_OF_RESOURCES;
> + }
> }
>
> //
> -// If Volatile Variable just do a simple mem copy.
> +// If Volatile/Emulated Non-volatile Variable just do a simple mem copy.
> //
> CopyMem ((UINT8 *)(UINTN)DataPtr, Buffer, DataSize);
> return EFI_SUCCESS;
> @@ -987,7 +1001,7 @@ Reclaim (
>CommonUserVariableTotalSize = 0;
>HwErrVariableTotalSize = 0;
>
> - if (IsVolatile) {
> + if (IsVolatile || mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> //
> // Start Pointers for the variable.
> //
> @@ -1155,13 +1169,21 @@ Reclaim (
> CurrPtr += NewVariableSize;
>}
>
> - if (IsVolatile) {
> + if (IsVolatile || mVariableModuleGlobal->VariableGlobal.EmuNvMode) {
> //
>
Re: [edk2] [PATCH V3 17/17] MdeModulePkg: Remove EmuVariableRuntimeDxe
Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Zeng, Star > Sent: Tuesday, January 15, 2019 6:30 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star; Wang, Jian J; Wu, Hao A > Subject: [PATCH V3 17/17] MdeModulePkg: Remove > EmuVariableRuntimeDxe > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > Merge EmuVariable and Real variable driver. > > The real variable driver has been updated to support emulated > variable NV mode. > This patch removes EmuVariableRuntimeDxe after platforms are > migrated to use the merged variable driver. > > Cc: Jian J Wang > Cc: Hao Wu > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdeModulePkg/MdeModulePkg.dsc |5 +- > .../Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 1820 > > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.inf| 88 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.uni| 22 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxeExtra.uni | 19 - > .../Variable/EmuRuntimeDxe/InitVariable.c | 259 --- > .../Universal/Variable/EmuRuntimeDxe/Variable.h| 277 --- > 7 files changed, 1 insertion(+), 2489 deletions(-) > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > Dxe.inf > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > Dxe.uni > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > DxeExtra.uni > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/InitVariable.c > delete mode 100644 > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/Variable.h > > diff --git a/MdeModulePkg/MdeModulePkg.dsc > b/MdeModulePkg/MdeModulePkg.dsc > index 5d042be3a862..3186f35a1a48 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -2,7 +2,7 @@ > # EFI/PI Reference Module Package for All Architectures > # > # (C) Copyright 2014 Hewlett-Packard Development Company, L.P. > -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved. > +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved. > # > #This program and the accompanying materials > #are licensed and made available under the terms and conditions of the > BSD License > @@ -433,9 +433,6 @@ [Components.IA32, Components.X64, > Components.ARM, Components.AARCH64] > > NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32G > uidedSectionExtractLib.inf >} > > -[Components.IA32, Components.X64, Components.Ebc] > - > MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime > Dxe.inf > - > [Components.IA32, Components.X64] > > MdeModulePkg/Application/SmiHandlerProfileInfo/SmiHandlerProfileInfo. > inf >MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf > diff --git > a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > b/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > deleted file mode 100644 > index 1bcf931b96a6.. > --- a/MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariable.c > +++ /dev/null > @@ -1,1820 +0,0 @@ > -/** @file > - > - Emulation Variable services operate on the runtime volatile memory. > - The nonvolatile variable space doesn't exist. > - > -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved. > -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 > - > -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > - > -**/ > - > -#include "Variable.h" > - > -/// > -/// Don't use module globals after the SetVirtualAddress map is signaled > -/// > -ESAL_VARIABLE_GLOBAL *mVariableModuleGlobal; > - > -VARIABLE_INFO_ENTRY *gVariableInfo = NULL; > - > -/// > -/// The size of a 3 character ISO639 language code. > -/// > -#define ISO_639_2_ENTRY_SIZE3 > - > -/** > - Update the variable region with Variable information. These are the same > - arguments as the EFI Variable services. > - > - @param[in] VariableName Name of variable > - > - @param[in] VendorGuid Guid of variable > - > - @param[in] Data Variable data > - > - @param[in] DataSize Size
Re: [edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable driver
Star, The KW scan for the patch series is good. Best Regards, Hao Wu > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Star Zeng > Sent: Tuesday, January 15, 2019 6:29 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: [edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable > driver > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323 > > Purpose: > 1. Add emulated variable NV mode support in >MdeModulePkg\Universal\Variable\RuntimeDxe. >Platform can configure PCD statically (build time) or >dynamically (boot time) to support emulated variable NV mode. > 2. Remove MdeModulePkg\Universal\Variable\EmuRuntimeDxe whose >most codes are duplicated. > > > V3: > Addressed all the great feedbacks from Jian, Hao, Laszlo and Leif, thanks. > Pick up RB and AB tags. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode_V3 > > Patches 1~9: Preparation > Patch 3 and 9 are new added based on feedbacks. > Patch 10~11: Real work > Patch 12~17: Migration for platforms and cleanup > > > V2: Addressed all the feedbacks from Laszlo, thanks. > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode_V2 > > Patches 1~7: Preparation > Patch 6 and 7 are new separated. > Patch 8~9: Real work > Patch 10~15: Migration for platforms and cleanup > Patch 11 is new added to let ArmVirtXen be aligned with ArmVirtQemuXXX. > > > V1: > > Repo: g...@github.com:lzeng14/edk2.git > Branch: MergedVariableDriver_EmuNvMode > > Patches 1~5: Preparation > Patch 6~7: Real work > Patch 8~12: Migration for platforms and cleanup > > Test done: > Build code with VS2012, VS2015 and GCC49. > Regression: Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to UEFI > SHELL. > Boot some internal platform to UEFI SHELL and Windows. > Functionality: Boot Nt32, Ovmf (including 32, 3264 and 64 with no SMM) to > UEFI SHELL >with PcdEmuVariableNvModeEnable == TRUE. > > More test will be welcome and appreciated. :) > > Patches to update edk2-platforms Repo will be sent out separately. > > Star Zeng (17): > MdeModulePkg Variable: Add some missing changes for 9b18845 > MdeModulePkg Variable: Abstract InitRealNonVolatileVariableStore > MdeModulePkg Variable: Move "extern XXX" to Variable.h > MdeModulePkg Variable: Not get NV PCD in > VariableWriteServiceInitialize > MdeModulePkg Variable: Abstract VariableWriteServiceInitializeDxe/Smm > MdeModulePkg Variable: Remove CacheOffset in UpdateVariable() > MdeModulePkg Variable: type case VolatileBase to UINTN directly > MdeModulePkg: Add PcdEmuVariableNvModeEnable in dec > MdeModulePkg: Refine description a little for > PcdEmuVariableNvStoreReserved > MdeModulePkg Variable: Add emulated variable NV mode support > MdeModulePkg VariablePei: Don't check BOOT_IN_RECOVERY_MODE > ArmVirtXen: Use merged variable driver for emulated NV mode > ArmVirtXen: Link VarCheckUefiLib NULL class library instance > BeagleBoardPkg: Use merged variable driver for emulated NV mode > QuarkMin: Use merged variable driver for emulated NV mode > CorebootPayloadPkg: Use merged variable driver for emulated NV mode > MdeModulePkg: Remove EmuVariableRuntimeDxe > > ArmVirtPkg/ArmVirtXen.dsc | 12 +- > ArmVirtPkg/ArmVirtXen.fdf |4 +- > BeagleBoardPkg/BeagleBoardPkg.dsc | 14 +- > BeagleBoardPkg/BeagleBoardPkg.fdf |4 +- > CorebootPayloadPkg/CorebootPayloadPkg.fdf |4 +- > CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc | 11 +- > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 11 +- > MdeModulePkg/MdeModulePkg.dec | 16 +- > MdeModulePkg/MdeModulePkg.dsc |5 +- > MdeModulePkg/MdeModulePkg.uni | 14 +- > .../Universal/Variable/EmuRuntimeDxe/EmuVariable.c | 1820 -- > -- > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.inf| 88 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxe.uni| 22 - > .../EmuRuntimeDxe/EmuVariableRuntimeDxeExtra.uni | 19 - > .../Variable/EmuRuntimeDxe/InitVariable.c | 259 --- > .../Universal/Variable/EmuRuntimeDxe/Variable.h| 277 --- > MdeModulePkg/Universal/Variable/Pei/Variable.c |8 +- > .../Universal/Variable/Pei/VariablePei.inf |3 +- > .../Universal/Variable/RuntimeDxe/Variable.c | 431 +++-- > .../Universal/Variable/RuntimeDxe/Variable.h | 19 +- > .../Universal/Variable/RuntimeDxe/VariableDxe.c| 103 +- > .../Variable/RuntimeDxe/VariableRuntimeDxe.inf |4 +- > .../Universal/Variable/RuntimeDxe/VariableSmm.c| 90 +- > .../Universal/Variable/RuntimeDxe/VariableSmm.inf |4 +- > QuarkPlatformPkg/QuarkMin.dsc |8 +- > QuarkPlatformPkg/QuarkMin.fdf |
[edk2] Recall: [PATCH V3 00/17] Merge EmuVariable and Real variable driver
Wu, Hao A would like to recall the message, "[edk2] [PATCH V3 00/17] Merge EmuVariable and Real variable driver". ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Recall: [PATCH V3 00/17] Merge EmuVariable and Real variable driver
Wrong operation made. Please ignore the message. Sorry for the noise. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Wu, Hao A > Sent: Wednesday, January 16, 2019 3:42 PM > To: Zeng, Star; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: [edk2] Recall: [PATCH V3 00/17] Merge EmuVariable and Real > variable driver > > Wu, Hao A would like to recall the message, "[edk2] [PATCH V3 00/17] Merge > EmuVariable and Real variable driver". > ___ > 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 v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Hi Jiaxin,
A comment that is not related with the content of the patch itself:
Please help to send the full patch series when a new version is needed.
Best Regards,
Hao Wu
> -Original Message-
> From: Wu, Jiaxin
> Sent: Friday, January 18, 2019 1:16 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting; Fu, Siyuan; Wu, Hao A; Gao, Liming; Wu, Jiaxin
> Subject: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary
> NULL pointer check.
>
> v2: The DHCP Instance might be destroyed in PxeDhcpDone. So,
> we need safe-delete.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469
>
> Since the value of Instance is retrieved from the list Entry,
> it can't be the NULL pointer, so just remove the unnecessary
> check.
>
> Cc: Ye Ting
> Cc: Fu Siyuan
> Cc: Wu Hao A
> Cc: Gao Liming
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wu Jiaxin
> ---
> MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> index 98a22a77b4..780f8b4224 100644
> --- a/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> +++ b/MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c
> @@ -1,9 +1,9 @@
> /** @file
>EFI DHCP protocol implementation.
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> 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
>
> @@ -1646,16 +1646,13 @@ ON_EXIT:
>//
>// Iterate through all the DhcpSb Children.
>//
>NET_LIST_FOR_EACH_SAFE (Entry, Next, &DhcpSb->Children) {
> Instance = NET_LIST_USER_STRUCT (Entry, DHCP_PROTOCOL, Link);
> -
> -if ((Instance != NULL) && (Instance->Token != NULL)) {
> - Instance->Timeout--;
> - if (Instance->Timeout == 0) {
> -PxeDhcpDone (Instance);
> - }
> +Instance->Timeout--;
> +if (Instance->Timeout == 0) {
> + PxeDhcpDone (Instance);
> }
>}
>
>return ;
>
> --
> 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
