Dell Customer Communication
________________________________________ Wei Liu BIOS Development DELL Enterprise Server Group 512-725-2873(o) -----Original Message----- From: edk2-devel [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, September 24, 2015 4:11 PM To: [email protected] Subject: edk2-devel Digest, Vol 3, Issue 142 Send edk2-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.01.org/mailman/listinfo/edk2-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of edk2-devel digest..." Today's Topics: 1. Re: ShellPkg: ShellPkg DSC update (Laszlo Ersek) 2. Re: ShellPkg: ShellPkg DSC update (Carsey, Jaben) 3. PCI code is finding only Bus 0. I need Bus 1 (Shubha Ramani) 4. Re: PCI code is finding only Bus 0. I need Bus 1 (Laszlo Ersek) 5. Re: [PATCH 1/2] ArmVirtPkg: VirtFdtDxe: detect fw-cfg DMA interface from the DTB (Ard Biesheuvel) 6. Re: [PATCH 2/2] ArmVirtPkg: QemuFwCfgLib: read bytes from fw-cfg with DMA when available (Ard Biesheuvel) ---------------------------------------------------------------------- Message: 1 Date: Thu, 24 Sep 2015 22:33:08 +0200 From: Laszlo Ersek To: "Carsey, Jaben" Cc: "[email protected]" Subject: Re: [edk2] ShellPkg: ShellPkg DSC update Message-ID: Content-Type: text/plain; charset=windows-1252 On 09/24/15 22:21, Laszlo Ersek wrote: > On 09/24/15 22:07, Laszlo Ersek wrote: >> On 09/24/15 22:03, Laszlo Ersek wrote: >>> On 09/24/15 21:56, Carsey, Jaben wrote: >>>> Shumin, >>>> >>>> Can you review this? >>>> >>>> The update makes all the libs built when the package is built. >>>> (prevent future issue like where TFPT lib wouldn't build) >>> >>> I'm just about to send patches that will build TFTP into OVMF's and >>> ArmVirt*'s shell, so we too will catch such errors quickly. >>> >>> I am also reposting your patch "ShellPkg: Update tftp to build with >>> current tip" (in gitified form), because it needs a small fix for >>> building with gcc. >> >> Sigh. I can see the patch has been already committed. Okay, I'll >> include a patch that fixes it up then. > > Please do not commit patches to SVN with *significant changes* > relative to the last reviewed version. I compared the patch that is > now committed to SVN against your original posting (the one that Qiu > Shumin reviewed on the list), and there's a long list of differences: > > - IP4_CONFIG2_INTERFACE_INFO_NAME_LENGTH got prefixed with EFI_ > - HP's copyright was removed > - documentation of functions was updated > - various variables and fields were changed from UINTN to UINT64. And this change actually breaks the Ia32 build, because it divides a UINT64 quantity with the "/" division operator. I'll send a patch for that too. Laszlo > - long lines were rewrapped > > These changes may all be justified, but they would have certainly > warranted a v2 post, and a new review. > > I understand this is tedious to do without git; hopefully once git is > universally used, noone will be tempted to cut corners like the above. > > Thanks > Laszlo > >> Thanks >> Laszlo >> >>> >>>> ShellPkg: ShellPkg DSC update >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Jaben Carsey >>> >>> Please consider moving to git; the list server is stripping away all >>> your attachments. >>> >>> Thanks >>> Laszlo >>> >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> [email protected] >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>> >>> >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.01.org/mailman/listinfo/edk2-devel >> > ------------------------------ Message: 2 Date: Thu, 24 Sep 2015 20:42:23 +0000 From: "Carsey, Jaben" To: Laszlo Ersek Cc: "Carsey, Jaben" , "[email protected]" Subject: Re: [edk2] ShellPkg: ShellPkg DSC update Message-ID: Content-Type: text/plain; charset="us-ascii" That was an error on my part. I plan to revert the change and then apply the correct one. > -----Original Message----- > From: Laszlo Ersek [mailto:[email protected]] > Sent: Thursday, September 24, 2015 1:21 PM > To: Carsey, Jaben > Cc: [email protected] > Subject: Re: [edk2] ShellPkg: ShellPkg DSC update > Importance: High > > On 09/24/15 22:07, Laszlo Ersek wrote: > > On 09/24/15 22:03, Laszlo Ersek wrote: > >> On 09/24/15 21:56, Carsey, Jaben wrote: > >>> Shumin, > >>> > >>> Can you review this? > >>> > >>> The update makes all the libs built when the package is built. > >>> (prevent > future issue like where TFPT lib wouldn't build) > >> > >> I'm just about to send patches that will build TFTP into OVMF's and > >> ArmVirt*'s shell, so we too will catch such errors quickly. > >> > >> I am also reposting your patch "ShellPkg: Update tftp to build with > >> current tip" (in gitified form), because it needs a small fix for > >> building with gcc. > > > > Sigh. I can see the patch has been already committed. Okay, I'll > > include a patch that fixes it up then. > > Please do not commit patches to SVN with *significant changes* > relative to the last reviewed version. I compared the patch that is > now committed to SVN against your original posting (the one that Qiu > Shumin reviewed on the list), and there's a long list of differences: > > - IP4_CONFIG2_INTERFACE_INFO_NAME_LENGTH got prefixed with EFI_ > - HP's copyright was removed > - documentation of functions was updated > - various variables and fields were changed from UINTN to UINT64. > - long lines were rewrapped > > These changes may all be justified, but they would have certainly > warranted a v2 post, and a new review. > > I understand this is tedious to do without git; hopefully once git is > universally used, noone will be tempted to cut corners like the above. > > Thanks > Laszlo > > > Thanks > > Laszlo > > > >> > >>> ShellPkg: ShellPkg DSC update > >>> > >>> Contributed-under: TianoCore Contribution Agreement 1.0 > >>> Signed-off-by: Jaben Carsey > >> > >> Please consider moving to git; the list server is stripping away > >> all your attachments. > >> > >> Thanks > >> Laszlo > >> > >>> _______________________________________________ > >>> edk2-devel mailing list > >>> [email protected] > >>> https://lists.01.org/mailman/listinfo/edk2-devel > >>> > >> > >> _______________________________________________ > >> edk2-devel mailing list > >> [email protected] > >> https://lists.01.org/mailman/listinfo/edk2-devel > >> > > > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > > ------------------------------ Message: 3 Date: Thu, 24 Sep 2015 20:52:09 +0000 (UTC) From: Shubha Ramani To: "[email protected]" Subject: [edk2] PCI code is finding only Bus 0. I need Bus 1 Message-ID: Content-Type: text/plain; charset=UTF-8 Please see the code below which follows 1 b) in Lazlo's detailed email suggestion of a few days ago.?The code is not seeing Bus 1. It's only seeing Bus 0.Does this have something to ?do with passing?gEfiPciIoProtocolGuid into LocateHandleBuffer ?I noticed that there is also?gEfiLegacyBiosGuid and?gEfiSimpleTextInProtocolGuid(in perusing "LegacyPci.c"). The PCI device in question is a proprietary Intel chip. I checked with the design team and these registersare definitely visible to UEFI drivers. So I'm wondering why the code is not seeing Bus 1. Any suggestions ? EFI_PCI_IO_PROTOCOL *PciIo; EFI_STATUS ?Status = EFI_SUCCESS; UINTN ? HandleCount;? ? EFI_HANDLE *HandleBuffer; UINTN Index, Segment, Bus, Device, Function; UINT64 ?Value; ? Status = gBS->LocateHandleBuffer (? ? ? ? ? ? ? ? ? ByProtocol,? ? ? ? ? ? ? ? ? &gEfiPciIoProtocolGuid,? ? ? ? ? ? ? ? ? NULL,? ? ? ? ? ? ? ? ? &HandleCount,? ? ? ? ? ? ? ? ? &HandleBuffer? ? ? ? ? ? ? ? ? ); ? if (EFI_ERROR (Status)) {? Print(L"ERROR Status after gBS->LocateHandleBuffer: %r\n", Status);?? ? return PTU_FAILURE;? }??? for (Index = 0; Index < HandleCount; Index++) {? ? ? ? Status = gBS->HandleProtocol (? ? ? ? ? ? ? ? ? ? HandleBuffer[Index],? ? ? ? ? ? ? ? ? ? &gEfiPciIoProtocolGuid,? ? ? ? ? ? ? ? ? ? (VOID **) &PciIo? ? ? ? ? ? ? ? ? ? ); if (EFI_ERROR (Status)) { ? ? ? ? ? continue; } ? ? ? Status = PciIo->GetLocation(PciIo, &Segment, &Bus, &Device, &Function); Print(L"Index = %d, Segment = %d, Bus = %d, Device = %d, Function ?%d, Status = %r\n", Index, Segment, Bus, Device, Function, Status); if (Status == EFI_SUCCESS) ?{ ? ? ? ? ? ? if ((Bus == 1) && (Device == 29) && (Function == 0)) ? ? ? ? ? ?{ ? ? ? ? ? ? Print(L"Congrats BFD Found !\n");? ? ? ? ? ? ? ? ?for (OffsetIdx = 0; OffsetIdx < 8; OffsetIdx++) ? ? ? ? ? ? ? ?{? ? ? ? ? ? ? ? ? ? ?Status = PciIo->Pci.Read(? ? ? ? ? ? ? ? ? ? ? PciIo,? ? ? ? ? ? ? ? ? ? ? EfiPciIoWidthUint64,? ? ? ? ? ? ? ? ? ? ? Slice0DramRuleOffset[OffsetIdx],? ? ? ? ? ? ? ? ? ? ? 1,? ? ? ? ? ? ? ? ? ? ? &Value? ? ? ? ? ? ? ? ? ? ? ); ? ? ? ? ? ? ? ? ? ? ?if (Status == EFI_SUCCESS) ?{ ? ? ? ? ? ? ? ? ? ? ? ? Print(L"PciIo->Pci.Read SUCCESS for Offset: 0X%x Value: 0X%x\n", ?Slice0DramRuleOffset[OffsetIdx], Value); ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? }//for OffsetIdx ? ? ? ? ?}//if BFD matches ? }//if EFI_SUCCESS? ?}//for HandleCount Shubha D. [email protected] [email protected] ------------------------------ Message: 4 Date: Thu, 24 Sep 2015 23:07:29 +0200 From: Laszlo Ersek To: Shubha Ramani , "[email protected]" Subject: Re: [edk2] PCI code is finding only Bus 0. I need Bus 1 Message-ID: Content-Type: text/plain; charset=utf-8 On 09/24/15 22:52, Shubha Ramani wrote: > > Please see the code below which follows 1 b) in Lazlo's detailed email > suggestion of a few days ago. The code is not seeing Bus 1. > It's only seeing Bus 0.Does this have something to do with passing > gEfiPciIoProtocolGuid into LocateHandleBuffer ?I noticed that there is > also gEfiLegacyBiosGuid and gEfiSimpleTextInProtocolGuid(in perusing > "LegacyPci.c"). The PCI device in question is a proprietary Intel > chip. I checked with the design team and these registersare definitely > visible to UEFI drivers. So I'm wondering why the code is not seeing > Bus 1. Any suggestions ? Can you see the relevant device (BFD) in the debug output of the PCI Bus driver? PciBus: Discovered PCI @ [..|..|..] Laszlo ------------------------------ Message: 5 Date: Thu, 24 Sep 2015 14:08:18 -0700 From: Ard Biesheuvel To: Laszlo Ersek Cc: edk2-devel-01 Subject: Re: [edk2] [PATCH 1/2] ArmVirtPkg: VirtFdtDxe: detect fw-cfg DMA interface from the DTB Message-ID: Content-Type: text/plain; charset=UTF-8 On 24 September 2015 at 04:26, Laszlo Ersek wrote: > A DMA-like transfer interface has recently been implemented in QEMU > for fw-cfg. For ARM and AARCH64 virtual machines, the binding > prescribes a new 8-byte wide register at offset 0x10 in the register > block. Make VirtFdtDxe expose this register if it is present. > > Please see "docs/specs/fw_cfg.txt" in the QEMU tree for more information. > > Cc: Ard Biesheuvel > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel > --- > ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf | 1 + > ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c | 15 +++++++++++++++ > ArmVirtPkg/ArmVirtPkg.dec | 1 + > ArmVirtPkg/ArmVirtQemu.dsc | 1 + > ArmVirtPkg/ArmVirtXen.dsc | 1 + > 5 files changed, 19 insertions(+) > > diff --git a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > index 657b4e8..ee2503a 100644 > --- a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > +++ b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf > @@ -53,6 +53,7 @@ [Pcd] > gArmVirtTokenSpaceGuid.PcdArmPsciMethod > gArmVirtTokenSpaceGuid.PcdFwCfgSelectorAddress > gArmVirtTokenSpaceGuid.PcdFwCfgDataAddress > + gArmVirtTokenSpaceGuid.PcdFwCfgDmaAddress > gArmVirtTokenSpaceGuid.PcdArmGicRevision > gArmTokenSpaceGuid.PcdGicDistributorBase > gArmTokenSpaceGuid.PcdGicRedistributorsBase > diff --git a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > index 73db630..74f80d1 100644 > --- a/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > +++ b/ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.c > @@ -302,6 +302,8 @@ InitializeVirtFdtDxe ( > UINT64 FwCfgSelectorSize; > UINT64 FwCfgDataAddress; > UINT64 FwCfgDataSize; > + UINT64 FwCfgDmaAddress; > + UINT64 FwCfgDmaSize; > > Hob = GetFirstGuidHob(&gFdtHobGuid); > if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) > { @@ -382,6 +384,19 @@ InitializeVirtFdtDxe ( > > DEBUG ((EFI_D_INFO, "Found FwCfg @ 0x%Lx/0x%Lx\n", FwCfgSelectorAddress, > FwCfgDataAddress)); > + > + if (fdt64_to_cpu (((UINT64 *)RegProp)[1]) >= 0x18) { > + FwCfgDmaAddress = FwCfgDataAddress + 0x10; > + FwCfgDmaSize = 0x08; > + > + // > + // See explanation above. > + // > + ASSERT (FwCfgDmaAddress <= MAX_UINTN - FwCfgDmaSize + 1); > + > + PcdSet64 (PcdFwCfgDmaAddress, FwCfgDmaAddress); > + DEBUG ((EFI_D_INFO, "Found FwCfg DMA @ 0x%Lx\n", FwCfgDmaAddress)); > + } > break; > > case PropertyTypeVirtio: > diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec > index d987035..89e8448 100644 > --- a/ArmVirtPkg/ArmVirtPkg.dec > +++ b/ArmVirtPkg/ArmVirtPkg.dec > @@ -67,6 +67,7 @@ [PcdsDynamic, PcdsFixedAtBuild] > > gArmVirtTokenSpaceGuid.PcdFwCfgSelectorAddress|0x0|UINT64|0x00000004 > gArmVirtTokenSpaceGuid.PcdFwCfgDataAddress|0x0|UINT64|0x00000005 > + gArmVirtTokenSpaceGuid.PcdFwCfgDmaAddress|0x0|UINT64|0x00000009 > > # > # Supported GIC revision (2, 3, ...) diff --git > a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index > f1af968..9e40f39 100644 > --- a/ArmVirtPkg/ArmVirtQemu.dsc > +++ b/ArmVirtPkg/ArmVirtQemu.dsc > @@ -199,6 +199,7 @@ [PcdsDynamicDefault.common] > > gArmVirtTokenSpaceGuid.PcdFwCfgSelectorAddress|0x0 > gArmVirtTokenSpaceGuid.PcdFwCfgDataAddress|0x0 > + gArmVirtTokenSpaceGuid.PcdFwCfgDmaAddress|0x0 > > # > # Set video resolution for boot options and for text setup. > diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc > index 5c19afc..ac37cd2 100644 > --- a/ArmVirtPkg/ArmVirtXen.dsc > +++ b/ArmVirtPkg/ArmVirtXen.dsc > @@ -144,6 +144,7 @@ [PcdsDynamicDefault.common] > > gArmVirtTokenSpaceGuid.PcdFwCfgSelectorAddress|0x0 > gArmVirtTokenSpaceGuid.PcdFwCfgDataAddress|0x0 > + gArmVirtTokenSpaceGuid.PcdFwCfgDmaAddress|0x0 > > gArmVirtTokenSpaceGuid.PcdArmPsciMethod|0 > > -- > 1.8.3.1 > > ------------------------------ Message: 6 Date: Thu, 24 Sep 2015 14:10:39 -0700 From: Ard Biesheuvel To: Laszlo Ersek Cc: edk2-devel-01 Subject: Re: [edk2] [PATCH 2/2] ArmVirtPkg: QemuFwCfgLib: read bytes from fw-cfg with DMA when available Message-ID: Content-Type: text/plain; charset=UTF-8 On 24 September 2015 at 04:26, Laszlo Ersek wrote: > The protocol is documented in "docs/specs/fw_cfg.txt" in the QEMU tree. > > Cc: Ard Biesheuvel > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Laszlo Ersek Nice feature! Reviewed-by: Ard Biesheuvel > --- > ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf | 2 + > ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c | 126 ++++++++++++++++++-- > 2 files changed, 121 insertions(+), 7 deletions(-) > > diff --git a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf > b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf > index 42f21f2..298aa6e 100644 > --- a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf > +++ b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf > @@ -44,9 +44,11 @@ [Packages] > [LibraryClasses] > BaseLib > BaseMemoryLib > + DebugLib > IoLib > PcdLib > > [Pcd] > gArmVirtTokenSpaceGuid.PcdFwCfgSelectorAddress > gArmVirtTokenSpaceGuid.PcdFwCfgDataAddress > + gArmVirtTokenSpaceGuid.PcdFwCfgDmaAddress > diff --git a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c > b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c > index c62eee3..303dc52 100644 > --- a/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c > +++ b/ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c > @@ -16,12 +16,58 @@ > > #include > #include > +#include > #include > #include > #include > > STATIC UINTN mFwCfgSelectorAddress; > STATIC UINTN mFwCfgDataAddress; > +STATIC UINTN mFwCfgDmaAddress; > + > +/** > + Reads firmware configuration bytes into a buffer > + > + @param[in] Size Size in bytes to read > + @param[in] Buffer Buffer to store data into (OPTIONAL if Size is > + 0) > + > +**/ > +typedef > +VOID (EFIAPI READ_BYTES_FUNCTION) ( > + IN UINTN Size, > + IN VOID *Buffer OPTIONAL > + ); > + > +// > +// Forward declaration of the two implementations we have. > +// > +STATIC READ_BYTES_FUNCTION MmioReadBytes; STATIC READ_BYTES_FUNCTION > +DmaReadBytes; > + > +// > +// This points to the one we detect at runtime. > +// > +STATIC READ_BYTES_FUNCTION *InternalQemuFwCfgReadBytes = > +MmioReadBytes; > + > +// > +// Communication structure for DmaReadBytes(). All fields are encoded > +in big // endian. > +// > +#pragma pack (1) > +typedef struct { > + UINT32 Control; > + UINT32 Length; > + UINT64 Address; > +} FW_CFG_DMA_ACCESS; > +#pragma pack () > + > +// > +// Macros for the FW_CFG_DMA_ACCESS.Control bitmap (in native encoding). > +// > +#define FW_CFG_DMA_CTL_ERROR BIT0 > +#define FW_CFG_DMA_CTL_READ BIT1 > +#define FW_CFG_DMA_CTL_SKIP BIT2 > +#define FW_CFG_DMA_CTL_SELECT BIT3 > > > /** > @@ -77,7 +123,22 @@ QemuFwCfgInitialize ( > > QemuFwCfgSelectItem (QemuFwCfgItemSignature); > Signature = QemuFwCfgRead32 (); > - if (Signature != SIGNATURE_32 ('Q', 'E', 'M', 'U')) { > + if (Signature == SIGNATURE_32 ('Q', 'E', 'M', 'U')) { > + // > + // For DMA support, we require the DTB to advertise the register, and the > + // feature bitmap (which we read without DMA) to confirm the feature. > + // > + if (PcdGet64 (PcdFwCfgDmaAddress) != 0) { > + UINT32 Features; > + > + QemuFwCfgSelectItem (QemuFwCfgItemInterfaceVersion); > + Features = QemuFwCfgRead32 (); > + if ((Features & BIT1) != 0) { > + mFwCfgDmaAddress = PcdGet64 (PcdFwCfgDmaAddress); > + InternalQemuFwCfgReadBytes = DmaReadBytes; > + } > + } > + } else { > mFwCfgSelectorAddress = 0; > mFwCfgDataAddress = 0; > } > @@ -108,16 +169,12 @@ QemuFwCfgSelectItem ( > > > /** > - Reads firmware configuration bytes into a buffer > - > - @param[in] Size Size in bytes to read > - @param[in] Buffer Buffer to store data into (OPTIONAL if Size is > 0) > - > + Slow READ_BYTES_FUNCTION. > **/ > STATIC > VOID > EFIAPI > -InternalQemuFwCfgReadBytes ( > +MmioReadBytes ( > IN UINTN Size, > IN VOID *Buffer OPTIONAL > ) > @@ -163,6 +220,61 @@ InternalQemuFwCfgReadBytes ( > > > /** > + Fast READ_BYTES_FUNCTION. > +**/ > +STATIC > +VOID > +EFIAPI > +DmaReadBytes ( > + IN UINTN Size, > + IN VOID *Buffer OPTIONAL > + ) > +{ > + volatile FW_CFG_DMA_ACCESS Access; > + UINT32 Status; > + > + if (Size == 0) { > + return; > + } > + > + ASSERT (Size <= MAX_UINT32); > + > + Access.Control = SwapBytes32 (FW_CFG_DMA_CTL_READ); Access.Length > + = SwapBytes32 ((UINT32)Size); Access.Address = SwapBytes64 > + ((UINT64)(UINTN)Buffer); > + > + // > + // We shouldn't start the transfer before setting up Access. > + // > + MemoryFence (); > + > + // > + // This will fire off the transfer. > + // > +#ifdef MDE_CPU_AARCH64 > + MmioWrite64 (mFwCfgDmaAddress, SwapBytes64 ((UINT64)&Access)); > +#else > + MmioWrite32 ((UINT32)(mFwCfgDmaAddress + 4), SwapBytes32 > +((UINT32)&Access)); #endif > + > + // > + // We shouldn't look at Access.Control before starting the transfer. > + // > + MemoryFence (); > + > + do { > + Status = SwapBytes32 (Access.Control); > + ASSERT ((Status & FW_CFG_DMA_CTL_ERROR) == 0); } while (Status > + != 0); > + > + // > + // The caller will want to access the transferred data. > + // > + MemoryFence (); > +} > + > + > +/** > Reads firmware configuration bytes into a buffer > > If called multiple times, then the data read will continue at the > offset of > -- > 1.8.3.1 > ------------------------------ Subject: Digest Footer _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel ------------------------------ End of edk2-devel Digest, Vol 3, Issue 142 ****************************************** _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
