Re: [edk2] [PATCH v3 1/4] MdePkg/UefiSpec.h: Add definition to support Capsule-on-Disk feature

[Ni, Ray]

Where does the macro name come from?
If it's not defined in Spec, how about to rename it to 
"EFI_CAPSULE_FILE_DIRECTORY"?


> -Original Message-
> From: edk2-devel  On Behalf Of Chen A Chen
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Zhang, Chao B
> ; Gao, Liming 
> Subject: [edk2] [PATCH v3 1/4] MdePkg/UefiSpec.h: Add definition to support
> Capsule-on-Disk feature
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
> 
> UEFI Spec define this definition to support Capsule-on-Disk.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhang Chao B 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen 
> ---
>  MdePkg/Include/Uefi/UefiSpec.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h b/MdePkg/Include/Uefi/UefiSpec.h
> index 75af99de50..9d3d7a9a63 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -2201,6 +2201,11 @@ typedef struct {
>#error Unknown Processor Type
>  #endif
> 
> +//
> +// The directory within the active EFI System Partition defined for
> +delivery of capsule to firmware //
> +#define EFI_CAPSULE_FROM_FILE_DIRL"\\EFI\\UpdateCapsule\\"
> +
>  #include 
>  #include 
>  #include 
> --
> 2.16.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 2/5] ArmPkg/ArmMmuLib AARCH64: get rid of needless TLB invalidation

[Ard Biesheuvel]

On Mon, 28 Jan 2019 at 19:01, Leif Lindholm  wrote:
>
> On Mon, Jan 28, 2019 at 01:29:54PM +0100, Ard Biesheuvel wrote:
> > > > > > > > @@ -296,7 +297,8 @@ GetBlockEntryListFromAddress (
> > > > > > > >
> > > > > > > >  // Fill the BlockEntry with the new TranslationTable
> > > > > > > >  ReplaceLiveEntry (BlockEntry,
> > > > > > > > -  ((UINTN)TranslationTable & 
> > > > > > > > TT_ADDRESS_MASK_DESCRIPTION_TABLE) | TableAttributes | 
> > > > > > > > TT_TYPE_TABLE_ENTRY);
> > > > > > > > +  (UINTN)TranslationTable | TableAttributes | 
> > > > > > > > TT_TYPE_TABLE_ENTRY,
> > > > > > > > +  RegionStart);
> > > > > > >
> > > > > >
> > > > > > /me pages in the data ...
> > > > > >
> > > > > > > OK, this whole patch took a few times around the loop before I 
> > > > > > > think I
> > > > > > > caught on what was happening.
> > > > > > >
> > > > > > > I think I'm down to the only things confusing me being:
> > > > > > > - The name "Address" to refer to something that is always the 
> > > > > > > start
> > > > > > >   address of a 4KB-aligned translation region.
> > > > > > >   Is this because the function will be usable in other contexts in
> > > > > > >   later patches?
> > > > > >
> > > > > > I could change it to VirtualAddress if you prefer.
> > > > > > It is only passed
> > > > > > for TLB maintenance which is only needed at page granularity, and 
> > > > > > the
> > > > > > low bits are shifted out anyway.
> > > > >
> > > > > Yeah, exactly. It would just be nice if the name reflected that. Not
> > > > > sure VirtualAddress does. VirtualBase? PageBase?
> > > > >
> > > >
> > > > Well, the argument passed in is called RegionStart, so let's just
> > > > stick with that.
> > >
> > > Sure. With that:
> > > Reviewed-by: Leif Lindholm 
> > >
> >
> > Thanks
> >
> > GIven the discussion in the other thread regarding shareability
> > upgrades of barriers and TLB maintenance instructions when running
> > under virt, mind if I fold in the hunk below? (and add a mention to
> > the commit log)
> >
> > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > @@ -35,7 +35,7 @@
> >// flush translations for the target address from the TLBs
> >lsr   x2, x2, #12
> >tlbi  vae\el, x2
> > -  dsb   sy
> > +  dsb   nsh
>
> So, this one, definitely. MMU is off, shareability is a shady concept
> at best, so it's arguably a fix.
>
> >// re-enable the MMU
> >msr   sctlr_el\el, x8
> > @@ -58,7 +58,7 @@ ASM_FUNC(ArmReplaceLiveTranslationEntry)
> >// clean and invalidate first so that we don't clobber
> >// adjacent entries that are dirty in the caches
> >dccivac, x0
> > -  dsb   ish
> > +  dsb   nsh
>
> This one I guess is safe because we know we're never going to get
> pre-empted or migrated (because interrupts are disabled and we don't
> do that sort of thing)?
>

Well, we can only get pre-empted under virt, in which case HCR_EL2.BSU
will be set so that barriers are upgraded to inner-shareable. In bare
metal cases, we only care about the local CPU since there are no other
masters (nor DMA capable devices) that care about this cache
maintenance having completed since the page tables are used by the CPU
only.

> If that's the rationale:
> Reviewed-by: Leif Lindholm 
>

Thanks

Pushed as f34b38fae614..d5788777bcc7
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if relocation info is invalid.

[Laszlo Ersek]

On 01/29/19 00:40, Hsueh, Hong-chihX wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Monday, January 28, 2019 2:17 PM
>> To: Hsueh, Hong-chihX ; edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; Gao, Liming
>> ; Bi, Dandan 
>> Subject: Re: [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if
>> relocation info is invalid.
>>
>> On 01/28/19 19:40, Neo Hsueh wrote:
>>> Skip runtime relocation for PE images that provide invalid relocation
>>> infomation
>>> (ex: RelocDir->Size = 0) to fix a hang observed while booting Windows.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>>
>>> Signed-off-by: Neo Hsueh 
>>> Cc: Michael D Kinney 
>>> Cc: Liming Gao 
>>> Cc: Dandan Bi 
>>> Cc: Laszlo Ersek 
>>> ---
>>>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>>> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>>> index 1bd079ad6a..f01c691dea 100644
>>> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>>> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>>> @@ -1746,6 +1746,12 @@ PeCoffLoaderRelocateImageForRuntime (
>>> 
>>>  RelocDir->VirtualAddress +
>> RelocDir->Size - 1,
>>> 
>>>  0
>>>
>>> );
>>> +if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd <
>> RelocBase) {
>>> +  //
>>> +  // relocation block is not valid, just return
>>> +  //
>>> +  return;
>>> +}
>>>} else {
>>>  //
>>>  // Cannot find relocations, cannot continue to relocate the image, 
>>> ASSERT
>> for this invalid image.
>>>
>>
>> Thank you for the update.
>>
>> ... Originally I meant to respond with an Acked-by (purely from a formal 
>> point-
>> of-view); however I figured the patch wasn't large and I could check it for a
>> Reviewed-by as well.
>>
>> I'm noticing the comparison (RelocBaseEnd < RelocBase) is supposed to catch
>> invalid relocation info. These variables are pointers, declared as
>> follows:
>>
>>   EFI_IMAGE_BASE_RELOCATION *RelocBase;
>>   EFI_IMAGE_BASE_RELOCATION *RelocBaseEnd;
>>
>> According to the C standard, the relational operators can only be applied to 
>> a
>> pair of pointers if each of those points into the same array, or one past 
>> the last
>> element. In this case, given that you intend to catch invalid relocation 
>> info,
>> that's exactly *not* the case. In other words, in the only case when the
>> relational operator would evaluate to true, it would also invoke undefined
>> behavior. Furthermore, the byte distance between the pointed-to-objects might
>> not even be a whole multiple of sizeof (EFI_IMAGE_BASE_RELOCATION).
>>
>> Normally I would suggest changing the return type of
>> PeCoffLoaderImageAddress() to UINTN -- that would be fitting because the
>> internal computation is already performed in UINTN, and only cast to
>> (CHAR8 *) as last step. This way we could move the cast to the callers, and
>> perform the sanity checks before the conversion to (VOID*) (or to other 
>> pointer
>> types).
>>
>> I do see the function is called from many places, so this change might be too
>> costly. Can we at least write in this patch,
>>
>>   if (RelocBase == NULL ||
>>   RelocBaseEnd == NULL ||
>>   (UINTN)RelocBaseEnd < (UINTN)RelocBase ||
>>   (((UINTN)RelocBaseEnd - (UINTN)RelocBase) %
>>sizeof (EFI_IMAGE_BASE_RELOCATION) != 0)) {
>> return;
>>   }
>>
>> ?
>>
>> Perhaps we should even extract this logic to a helper function, because I see
>> another spot with the same condition. That's in PeCoffLoaderRelocateImage(),
>> from the top of commit a8d8d430510d ("Support load 64 bit image from 32 bit
>> core. Add more enhancement to check invalid PE format.", 2014-03-25).
>>
>> I'm sorry that I didn't manage to make these suggestions under the v1 
>> posting.
>>
>> Thanks,
>> Laszlo
> 
> Hi Laszlo,
> Thank you. I agree the pointer comparison is not optimal especially in this 
> case.
> However I didn't add multiple of size (EFI_IMAGE_BASE_RELOCATION) check 
> because from the commit eb76b762, we actually check the address range between 
> Base to RelocDir->Size - 1.

Thank you for pointing that out.

I think that patch is not correct. We have:

  EFI_IMAGE_BASE_RELOCATION *RelocBase;
  EFI_IMAGE_BASE_RELOCATION *RelocBaseEnd;

and

RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(ImageContext, RelocDir->VirtualAddress, TeStrippedOffset);
RelocBaseEnd = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(ImageContext,

RelocDir->VirtualAddress + RelocDir->Size - 1,

TeStrippedOffset

Re: [edk2] Network Stack Budgeting

[Tomas Pilar (tpilar)]

On 29/01/2019 03:20, Fu, Siyuan wrote:
> Hi, Tomas
>
>> -Original Message-
>> From: Tomas Pilar (tpilar) [mailto:tpi...@solarflare.com]
>> Sent: Monday, January 28, 2019 7:24 PM
>> To: Fu, Siyuan ; Wu, Jiaxin ; 
>> Laszlo
>> Ersek ; edk2-devel@lists.01.org
>> Cc: Ye, Ting 
>> Subject: Re: [edk2] Network Stack Budgeting
>>
>> Hi Siyuan,
>>
>> I had to do some tweaks due to the fact that people in the wild want to PXE
>> boot whole WDS installations which are upwards of 300MB.
>>
>> I have an internal set of queues where the NIC receives into. Snp.Receive()
>> will get a packet from this store. I had to implement a separate queue for
>> unicast/multicast/broadcast traffic so that I could reprioritise and deliver
>> unicast traffic while under ARP spam. I tied internal poll to receive and
>> transmit, so Snp.Receive() will poll the NIC and then dequeue a packet while
>> Snp.Transmit() will transmit the packet and then poll the NIC to get a
>> completion. I also implemented a busy poll for 100us or until the next packet
>> comes in when the NIC is polled.
> I see some problems here. Both Snp.Receive() and Snp.Transmit() should be 
> non-blocking
> interface in current design and UEFI spec, but it's not true in your driver.
> For Receive(), it could poll the NIC only once and return either a received 
> packet
> or an error, it should not do any blocking poll to wait for a packet.
On some platforms (tftp clients), if the Snp.Receive() returns EFI_NOT_READY 
they do not poll the NIC until the next MnpSystemPoll(). Hence the delay before 
returning EFI_NOT_READY in case the packet is still incoming.
> For Transmit(), it just need to put the packet into the TX queue and return 
> directly,
> without checking if the TX is completed. 
> Instead of that, Snp.GetStatus() should be
> used to check if the packet has really been sent out.
I've seen quite a few platforms where GetStatus was only called by the 
MnpSystemPoll() and the application would not call it. This means our hardware 
rings are stuffed with completions and we stop being able to transmit. Yes, you 
could say that we should solve the application, but unfortunately I can't do 
that.
>
> May I know how did you control the 100us timeout of the busy poll (by which 
> API?),
> and what's the TPL of this busy poll?
>
Create a timeout timer with value of 1000. Then busy poll in a loop until 
packet is received or a timer is triggered.
This runs at TPL_CALLBACK while the EfxPoll function itself runs at TPL_NOTIFY.

-- 
  /* Set the poll moderation timeout to 100us */
  gBS->SetTimer(NetDev->PollModeratorTimer, TimerRelative, 1000);

  while (!InterruptStatus) {
    EfxPoll(NULL, NetDev->Efx);
    InterruptStatus = EfxStatus(NetDev->Efx);

    if (gBS->CheckEvent(NetDev->PollModeratorTimer))
  return InterruptStatus;
  }

  return InterruptStatus;
--

>> Otherwise I have seen a pathological case where the TFTP client would pull 
>> one
>> packet per second but the TFTP_RETRANSMIT interval on the server was also one
>> second and everything was awful.
> Why TFTP client just pull one packet per second? I think it’s not correct and 
> it
> could use the poll() function to accelerate the receive. Why you trying to 
> solve a
> TFTP layer problem in SNP layer? It breaks the design principle of network 
> layer model.
Yes, I appreciate the principle. However, in practice we don't get to sell 
adapters that do not PXE boot and it's pointless to argue with customers that 
they have a rubbish TFTP client implementation. So we put in workarounds into 
the driver.
>> In theory the busy poll moderator might cause an issue in a pathological 
>> case,
>> if it stalls the machine for 100us for each packet - with 100 packets per
>> second this would eat only 10ms.
> Not only 10ms, it's at least 10ms, and in theory. If you have multiple NICs 
> in the
> system, this time will double. If someone tries to poll the NIC, the time 
> will increase
> significantly. It also depends on who you measure the 100us timeout, I did 
> see some
> platform which has a minimum timer interval limitation, that you thought you 
> are using
> a 100us timeout but it’s actually 1ms or even 10ms.
>
> So my suggestion is do NOT add any busy wait in SNP layer API, keep it as 
> unblocking,
> and the try to solve the application layer problem in application layer.
I'll try dropping the busy poll and see whether that helps.

Cheers,
Tom
>
> Best Regards,
> Siyuan
>
>> Cheers,
>> Tom
>>
>> On 27/01/2019 14:28, Fu, Siyuan wrote:
>>> Hi, Tom
>>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Tomas
 Pilar (tpilar)
 Sent: Friday, January 25, 2019 8:09 PM
 To: Wu, Jiaxin ; Laszlo Ersek ;
>> edk2-
 de...@lists.01.org
 Cc: Ye, Ting 
 Subject: Re: [edk2] Network Stack Budgeting

 Yeah, that makes sense I suppose. The end result is however that the
>> network
 device is 'opened' as soon as ConnectControl

Re: [edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if relocation info is invalid.

[Laszlo Ersek]

On 01/29/19 00:22, Neo Hsueh wrote:
> Skip runtime relocation for PE images that provide invalid relocation 
> infomation
> (ex: RelocDir->Size = 0) to fix a hang observed while booting Windows.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Signed-off-by: Neo Hsueh 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> Cc: Laszlo Ersek 
> ---
>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c 
> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> index 1bd079ad6a..6d6c37bd61 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> @@ -1002,7 +1002,7 @@ PeCoffLoaderRelocateImage (
>  
> RelocDir->VirtualAddress + RelocDir->Size - 1,
>  
> TeStrippedOffset
>  
> );
> -if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd < 
> RelocBase) {
> +if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd < 
> (UINTN) RelocBase) {
>ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
>return RETURN_LOAD_ERROR;
>  }
> @@ -1022,7 +1022,7 @@ PeCoffLoaderRelocateImage (
>  // Run the relocation information and apply the fixups
>  //
>  FixupData = ImageContext->FixupData;
> -while (RelocBase < RelocBaseEnd) {
> +while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
>  
>Reloc = (UINT16 *) ((CHAR8 *) RelocBase + sizeof 
> (EFI_IMAGE_BASE_RELOCATION));
>//
> @@ -1051,7 +1051,7 @@ PeCoffLoaderRelocateImage (
>//
>// Run this relocation record
>//
> -  while (Reloc < RelocEnd) {
> +  while ((UINTN) Reloc < (UINTN) RelocEnd) {
>  Fixup = PeCoffLoaderImageAddress (ImageContext, 
> RelocBase->VirtualAddress + (*Reloc & 0xFFF), TeStrippedOffset);
>  if (Fixup == NULL) {
>ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
> @@ -1746,6 +1746,12 @@ PeCoffLoaderRelocateImageForRuntime (
>  
> RelocDir->VirtualAddress + RelocDir->Size - 1,
>  0
>  
> );
> +if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd < 
> (UINTN) RelocBase) {
> +  //
> +  // relocation block is not valid, just return
> +  //
> +  return;
> +}
>} else {
>  //
>  // Cannot find relocations, cannot continue to relocate the image, 
> ASSERT for this invalid image.
> @@ -1769,7 +1775,7 @@ PeCoffLoaderRelocateImageForRuntime (
>  //
>  FixupData = RelocationData;
>  RelocBaseOrig = RelocBase;
> -while (RelocBase < RelocBaseEnd) {
> +while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
>//
>// Add check for RelocBase->SizeOfBlock field.
>//
> @@ -1794,7 +1800,7 @@ PeCoffLoaderRelocateImageForRuntime (
>//
>// Run this relocation record
>//
> -  while (Reloc < RelocEnd) {
> +  while ((UINTN) Reloc < (UINTN) RelocEnd) {
>  
>  Fixup = PeCoffLoaderImageAddress (&ImageContext, 
> RelocBase->VirtualAddress + (*Reloc & 0xFFF), 0);
>  if (Fixup == NULL) {
> 

I think this patch is good enough, but it seems to miss the size==0
check that Dandan asked for.

Thanks,
laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if relocation info is invalid.

[Laszlo Ersek]

On 01/29/19 06:13, Bi, Dandan wrote:
> Hi Neo,
> 
> Thank you very much for the patch.
> 
> Some minor comments
> 1) Besides the skip check in this patch, could you help to add additional  
> check for RelocDir->Size before calling PeCoffLoaderImageAddress to calculate 
> the RelocBase and RelocBaseEnd?
> Since when RelocDir->Size==0, we can just return, don't need to do the 
> calculation.

I agree, checking Size against 0 before calling
PeCoffLoaderImageAddress() is best; we do the same in
PeCoffLoaderRelocateImage():

  if ((RelocDir != NULL) && (RelocDir->Size > 0)) {

Thanks,
Laszlo

> 
> 2) Please use the PatchCheck.py in edk2\BaseTools\Scripts to check the patch 
> format before committing  the patch.
> Can refer following link for more info:
> https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format
> 
> 
> Thanks,
> Dandan
> 
>> -Original Message-
>> From: Hsueh, Hong-chihX
>> Sent: Tuesday, January 29, 2019 2:41 AM
>> To: edk2-devel@lists.01.org
>> Cc: Kinney, Michael D ; Gao, Liming
>> ; Bi, Dandan ; Laszlo Ersek
>> 
>> Subject: [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if
>> relocation info is invalid.
>>
>> Skip runtime relocation for PE images that provide invalid relocation
>> infomation
>> (ex: RelocDir->Size = 0) to fix a hang observed while booting Windows.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>>
>> Signed-off-by: Neo Hsueh 
>> Cc: Michael D Kinney 
>> Cc: Liming Gao 
>> Cc: Dandan Bi 
>> Cc: Laszlo Ersek 
>> ---
>>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>> index 1bd079ad6a..f01c691dea 100644
>> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
>> @@ -1746,6 +1746,12 @@ PeCoffLoaderRelocateImageForRuntime (
>>  
>> RelocDir->VirtualAddress + RelocDir-
>>> Size - 1,
>>  >> 0
>>  
>> );
>> +if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd <
>> RelocBase) {
>> +  //
>> +  // relocation block is not valid, just return
>> +  //
>> +  return;
>> +}
>>} else {
>>  //
>>  // Cannot find relocations, cannot continue to relocate the image, 
>> ASSERT
>> for this invalid image.
>> --
>> 2.16.2.windows.1
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to split Pkgs

[Laszlo Ersek]

Hi Ray,

On 01/29/19 06:59, Ni, Ray wrote:
> Hello,
> I'd like to propose to split today's BIG packages in following ways:
> 
> ==Overview =
> 
> 1. Separate Industry standard definitions from UEFI and PI interfaces.
> 2. Separate UEFI and PI interfaces from implementations.
> a. Separate UEFI and PI interfaces to different packages
> b. Separate PI PEI, DXE and MM phase interfaces to different packages
> 3. Separate different features into feature packages.
> Feature interface may be in the feature package to provide minimal
> common interface packages.
> 
> The POC code is in https://github.com/jyao1/edk2/tree/ReOrg.
> It basically split the EDKII common code to three directories:
> Core/, Device/, and Feature/.
> The code is in very early POC phase and only code in Core/ directory
> can pass the build.
> I would like to gather feedbacks through this RFC to see whether
> this splitting direction makes sense.
> Is there any other better ways of splitting?
> Or perhaps do not split in such a small granularity?
> Or perhaps Mike's work to move lib-c content to edk2-libc repo,
> to move real platform code to edk2-platform repo is enough for
> now?
> 
> ==More explanations =
> 
> There are 9 packages inside Core/ directory:
> 1. BasePkg
> Contains industry standard definitions (exclude UEFI and PI) and base
> libraries that non-UEFI and non-PI development can depend on.
> UEFI or PI development can also depend on this package.
> 2. UefiPkg
> Contains UEFI interfaces and libraries that UEFI driver-model driver
> development can depend on.
> 3. PiPeiPkg
> Contains PI interfaces and libraries for PEI phase that PEI module
> development can depend on.
> 4. PiDxePkg
> Contains PI interfaces and libraries for DXE phase that DXE module
> development can depend on.
> 5. PiMmPkg
> Contains PI interfaces and libraries for MM phase that MM/SMM
> module development can depend on.
> 6. MdeModulePkg (TianoPkg? Name is still TBD)
> Contains Tiano implementation specific interfaces and libraries.
> Developing modules for pure UEFI or PI should not depend on this package.
> 7. PeiFoundationPkg
> Contains the PEI foundation modules (PeiCore and DxeIpl) and supported
> libraries.
> 8. DxeFoundationPkg
> Contains the DXE foundation modules (DxeCore and RuntimeDxe) and
> supported libraries.
> 9. SmmFoundationPkg
> Contains the SMM foundation modules (SmmCore, SmmIpl and
> SmmCommunicationBuffer) and supported libraries.
> 
> These packages are positioned in different layers. The package in higher
> layer depends on all packages that are in lower layers.
> Layer 0: BasePkg.
> Layer 1: UefiPkg.
> Layer 2: PiPeiPkg 
> Layer 3: PiDxePkg
> Layer 4: PiMmPkg
> Layer 5: MdeModulePkg (TianoPkg?)
> 
> All other modules are put to small packages under Device/ or Feature/.
> 
> == Benefit of this proposal =
> 
> This helps to reduce the size of each package, especially the very BIG
> MdeModulePkg which contains almost all edk2 modules (except
> CPU, network, etc). So platform can use git sparse checkout feature
> to only clone the needed code still in package granularity.
> This also helps to separate the code maintenance to more expert
> developers. MdeModulePkg is just too huge to be maintained by 2 or 3
> developers.

from a first / quick skim, it sounds OK to me; however, I'd like to
explicitly defer on this to the other stewards & stakeholders. I
remember that Leif had ideas about reorganizing the tree.

(Also, I vaguely feel that the movement/renaming of some macros /
definitions that Andrew and Mike have been discussing in thread

  [edk2] History question about Base.h and its alternate parallel name
 space Should we change it?

might overlap with this reorg.)

Regarding the benefits, I agree that we need clearer / finer grained
assignments between modules / packages and maintainers. I'm unsure if
that really requires reorganizing the tree (we could just reorganize
Maintainers.txt instead -- add some pathname patterns), but I agree that
reorganizing the tree is one method that could work.

Regarding sparse git checkout -- I'm probably missing details of this
git feature itself (regardless of subject project), but I'm generally
indifferent / unexcited about this. On my disk, a clean QEMU tree is
twice as large as edk2, and a clean Linux tree is more than thrice as
large. Also, it's been years since I decided it was impossible for me to
work without a good SSD (i.e. that traditional spindle disks would be
way too slow.) So, if the reorg helps some developers with handling the
tree locally, I don't mind, but personally I don't consider the reorg a
benefit for that.

Again, I'd like to leave the specifics to Leif, Mike, and others. I hope
that's acceptable.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 00/22] DynamicTablesPkg: Introduce Dynamic Tables Framework

[Alexei Fedorov]

I'm OK with these v2 patch series.

Reviewed-by: Alexei Fedorov 

Regards.
Alexei.


From: Sami Mujawar 
Sent: 24 January 2019 15:44
To: edk2-devel@lists.01.org
Cc: Alexei Fedorov; leif.lindh...@linaro.org; Matteo Carlini; Stephanie 
Hughes-Fitt; nd
Subject: [PATCH v2 00/22] DynamicTablesPkg: Introduce Dynamic Tables Framework

Dynamic Tables Framework aims to reduce the amount of effort
required for porting firmware to new platforms by simplifying
the generation of firmware tables based on hardware description
provided by a platform specific component.

The Dynamic Tables Framework core queries the platform specific
component to retrieve the required hardware information for
generating standardised firmware tables at run-time.

This patch series introduce the Dynamic Tables Framework.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar 

The changes can be seen at:
https://github.com/samimujawar/edk2/tree/365_dynamic_tables_framework_v2

This v2 patch series incorporates:
  * provision for extending the framework to support newer
versions of specifications.
  * minor code improvements.

The corresponding edk2-platform changes can be seen at:
https://github.com/samimujawar/edk2-platforms/tree/365_dynamic_tables_framework_v3

Sami Mujawar (22):
  DynamicTablesPkg: Dynamic Tables Framework
  DynamicTablesPkg: Table Generator definition
  DynamicTablesPkg: Acpi Table Generator
  DynamicTablesPkg: SMBIOS Table Generator
  DynamicTablesPkg: DT Table Generator
  DynamicTablesPkg: Standard NameSpace Objects
  DynamicTablesPkg: Arm NameSpace Objects
  DynamicTablesPkg: Configuration Manager Objects
  DynamicTablesPkg: Configuration Manager Protocol
  DynamicTablesPkg: Configuration Manager Helper
  DynamicTablesPkg: Table Helper Library
  DynamicTablesPkg: Dynamic Table Factory Protocol
  DynamicTablesPkg: Dynamic Table Factory Dxe
  DynamicTablesPkg: Dynamic Table Manager Dxe
  DynamicTablesPkg: Arm Raw/DSDT/SSDT Generator
  DynamicTablesPkg: Arm ACPI FADT Generator
  DynamicTablesPkg: Arm ACPI MADT Generator
  DynamicTablesPkg: Arm ACPI GTDT Generator
  DynamicTablesPkg: Arm SPCR Table Generator
  DynamicTablesPkg: Arm DBG2 Table Generator
  DynamicTablesPkg: Arm PCI MCFG Table Generator
  DynamicTablesPkg: Arm IORT Table Generator

 
DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/AcpiTableFactory/AcpiTableFactory.c
 |  226 +++
 
DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DeviceTreeTableFactory/DeviceTreeTableFactory.c
 |  225 +++
 DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactory.h  
 |  125 ++
 DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.c   
 |   90 +
 DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf 
 |   60 +
 
DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/SmbiosTableFactory/SmbiosTableFactory.c
 |  226 +++
 DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.c   
 |  735 +++
 DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf 
 |   50 +
 DynamicTablesPkg/DynamicTables.dsc.inc 
 |   44 +
 DynamicTablesPkg/DynamicTables.fdf.inc 
 |   24 +
 DynamicTablesPkg/DynamicTablesPkg.dec  
 |   43 +
 DynamicTablesPkg/Include/AcpiTableGenerator.h  
 |  360 
 DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
 |  591 ++
 DynamicTablesPkg/Include/ConfigurationManagerHelper.h  
 |  132 ++
 DynamicTablesPkg/Include/ConfigurationManagerObject.h  
 |  182 ++
 DynamicTablesPkg/Include/DeviceTreeTableGenerator.h
 |  182 ++
 DynamicTablesPkg/Include/Library/TableHelperLib.h  
 |   68 +
 DynamicTablesPkg/Include/Protocol/ConfigurationManagerProtocol.h   
 |  128 ++
 DynamicTablesPkg/Include/Protocol/DynamicTableFactoryProtocol.h
 |  269 +++
 DynamicTablesPkg/Include/SmbiosTableGenerator.h
 |  240 +++
 DynamicTablesPkg/Include/StandardNameSpaceObjects.h
 |  119 ++
 DynamicTablesPkg/Include/TableGenerator.h  
 |  252 +++
 DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf
 |   48 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c   
 |  463 +
 DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/AcpiFa

Re: [edk2] [RFC] Proposal to split Pkgs

[Leif Lindholm]

Hi Laszlo,

Managed to spot this before I sent my own reply :)

On Tue, Jan 29, 2019 at 12:11:51PM +0100, Laszlo Ersek wrote:
> Hi Ray,
> 
> On 01/29/19 06:59, Ni, Ray wrote:
> > Hello,
> > I'd like to propose to split today's BIG packages in following ways:
> > 
> > ==Overview =
> > 
> > 1. Separate Industry standard definitions from UEFI and PI interfaces.
> > 2. Separate UEFI and PI interfaces from implementations.
> > a. Separate UEFI and PI interfaces to different packages
> > b. Separate PI PEI, DXE and MM phase interfaces to different packages
> > 3. Separate different features into feature packages.
> > Feature interface may be in the feature package to provide minimal
> > common interface packages.
> > 
> > The POC code is in https://github.com/jyao1/edk2/tree/ReOrg.
> > It basically split the EDKII common code to three directories:
> > Core/, Device/, and Feature/.
> > The code is in very early POC phase and only code in Core/ directory
> > can pass the build.
> > I would like to gather feedbacks through this RFC to see whether
> > this splitting direction makes sense.
> > Is there any other better ways of splitting?
> > Or perhaps do not split in such a small granularity?
> > Or perhaps Mike's work to move lib-c content to edk2-libc repo,
> > to move real platform code to edk2-platform repo is enough for
> > now?
> > 
> > ==More explanations =
> > 
> > There are 9 packages inside Core/ directory:
> > 1. BasePkg
> > Contains industry standard definitions (exclude UEFI and PI) and base
> > libraries that non-UEFI and non-PI development can depend on.
> > UEFI or PI development can also depend on this package.
> > 2. UefiPkg
> > Contains UEFI interfaces and libraries that UEFI driver-model driver
> > development can depend on.
> > 3. PiPeiPkg
> > Contains PI interfaces and libraries for PEI phase that PEI module
> > development can depend on.
> > 4. PiDxePkg
> > Contains PI interfaces and libraries for DXE phase that DXE module
> > development can depend on.
> > 5. PiMmPkg
> > Contains PI interfaces and libraries for MM phase that MM/SMM
> > module development can depend on.
> > 6. MdeModulePkg (TianoPkg? Name is still TBD)
> > Contains Tiano implementation specific interfaces and libraries.
> > Developing modules for pure UEFI or PI should not depend on this package.
> > 7. PeiFoundationPkg
> > Contains the PEI foundation modules (PeiCore and DxeIpl) and supported
> > libraries.
> > 8. DxeFoundationPkg
> > Contains the DXE foundation modules (DxeCore and RuntimeDxe) and
> > supported libraries.
> > 9. SmmFoundationPkg
> > Contains the SMM foundation modules (SmmCore, SmmIpl and
> > SmmCommunicationBuffer) and supported libraries.
> > 
> > These packages are positioned in different layers. The package in higher
> > layer depends on all packages that are in lower layers.
> > Layer 0: BasePkg.
> > Layer 1: UefiPkg.
> > Layer 2: PiPeiPkg 
> > Layer 3: PiDxePkg
> > Layer 4: PiMmPkg
> > Layer 5: MdeModulePkg (TianoPkg?)
> > 
> > All other modules are put to small packages under Device/ or Feature/.
> > 
> > == Benefit of this proposal =
> > 
> > This helps to reduce the size of each package, especially the very BIG
> > MdeModulePkg which contains almost all edk2 modules (except
> > CPU, network, etc). So platform can use git sparse checkout feature
> > to only clone the needed code still in package granularity.
> > This also helps to separate the code maintenance to more expert
> > developers. MdeModulePkg is just too huge to be maintained by 2 or 3
> > developers.
> 
> from a first / quick skim, it sounds OK to me; however, I'd like to
> explicitly defer on this to the other stewards & stakeholders. I
> remember that Leif had ideas about reorganizing the tree.

Heh. Mainly that it needs reorganising :)
Although I may have brought up Mike's long-term plans to reorganise on
several occasions.

> (Also, I vaguely feel that the movement/renaming of some macros /
> definitions that Andrew and Mike have been discussing in thread
> 
>   [edk2] History question about Base.h and its alternate parallel name
>  space Should we change it?

Oh, I've been lax at following the list since I came back off
holiday. This looks like a good thread to get stuck into.

> might overlap with this reorg.)
> 
> Regarding the benefits, I agree that we need clearer / finer grained
> assignments between modules / packages and maintainers. I'm unsure if
> that really requires reorganizing the tree (we could just reorganize
> Maintainers.txt instead -- add some pathname patterns), but I agree that
> reorganizing the tree is one method that could work.

I would like both.
This split won't resolve the issue of defining separate maintainers
for */ARM* and */AARCH64* (and RISCV, ...).

But a proper tree rework would help newcomers. Figuring out what goes
where is non-trivial effort, and the archaic names don't help with

Re: [edk2] [PATCH v3 edk2-platforms 03/23] Platform/Raspberry/Pi3: Add ACPI tables

[Ard Biesheuvel]

On Tue, 29 Jan 2019 at 13:54, Pete Batard  wrote:
>
> Hi Ard, thanks for the reviews,
>
> On 2019.01.28 13:24, Ard Biesheuvel wrote:
> > A couple of general remarks on these tables.
> >
> > - AFAICT (but is is difficult to tell from the binary dumps), these
> > are based on ACPI 5.0, which predates the introduction of ARM support
> > into the spec. That essentially makes them Windows-only, and not spec
> > based, which is unfortunate. However, since this SoC does not have an
> > interrupt controller permitted by ACPI, that actually does not matter
> > a lot in practice.
>
> Publicly, these tables are only meant to boot Windows and we got them
> from Microsoft. So they are not exactly meant to be ACPI compliant (for
> instance, AFAIK, there's no definition of ACPI that includes the RPI
> interrupt controller).
>
> As such, we really don't want to touch these because we have run into
> nightmarish situation where Windows wouldn't boot at all after we tried
> to alter them.
>
> In other words, if we are to try to change much in here, we will
> probably need to have Microsoft's involvement...
>
> > - _CID fields should be properly formatted ACPI or PNP handles, you
> > can't put arbitrary strings in there (like BCMAUXSPI or VC4)
>
> The Microsoft Windows drivers expect those exact IDs, so that's not
> something we can alter either. Once again, these ACPI tables were not
> designed to be ACPI compliant, and making them so that late in the game
> is going to break a lot of things downstream, so we don't believe that
> we can do that at this stage.
>

No, I kind of figured that. It is just very unfortunate that we have
two completely separate descriptions for Windows vs Linux, so that is
why I brought it up.

>
> I will apply your other request for ACPI (drop the "-mcmodel=tiny"
> workaround in [BuildOptions]), as well as the changes you requested for
> 1/2/19 and, if you are okay with having our hands tied with regards to
> ACPI compliance, submit a v4 later on today.
>

Sure, although I was expecting Leif to chime in as well. Leif?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 edk2-platforms 03/23] Platform/Raspberry/Pi3: Add ACPI tables

[Pete Batard]

Hi Ard, thanks for the reviews,

On 2019.01.28 13:24, Ard Biesheuvel wrote:

A couple of general remarks on these tables.

- AFAICT (but is is difficult to tell from the binary dumps), these
are based on ACPI 5.0, which predates the introduction of ARM support
into the spec. That essentially makes them Windows-only, and not spec
based, which is unfortunate. However, since this SoC does not have an
interrupt controller permitted by ACPI, that actually does not matter
a lot in practice.


Publicly, these tables are only meant to boot Windows and we got them 
from Microsoft. So they are not exactly meant to be ACPI compliant (for 
instance, AFAIK, there's no definition of ACPI that includes the RPI 
interrupt controller).


As such, we really don't want to touch these because we have run into 
nightmarish situation where Windows wouldn't boot at all after we tried 
to alter them.


In other words, if we are to try to change much in here, we will 
probably need to have Microsoft's involvement...



- _CID fields should be properly formatted ACPI or PNP handles, you
can't put arbitrary strings in there (like BCMAUXSPI or VC4)


The Microsoft Windows drivers expect those exact IDs, so that's not 
something we can alter either. Once again, these ACPI tables were not 
designed to be ACPI compliant, and making them so that late in the game 
is going to break a lot of things downstream, so we don't believe that 
we can do that at this stage.



I will apply your other request for ACPI (drop the "-mcmodel=tiny" 
workaround in [BuildOptions]), as well as the changes you requested for 
1/2/19 and, if you are okay with having our hands tied with regards to 
ACPI compliance, submit a v4 later on today.


Regards,

/Pete
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Network Stack Budgeting

[Fu, Siyuan]

Hi, Tomas

> -Original Message-
> From: Tomas Pilar (tpilar) [mailto:tpi...@solarflare.com]
> Sent: Tuesday, January 29, 2019 6:54 PM
> To: Fu, Siyuan ; Wu, Jiaxin ; Laszlo
> Ersek ; edk2-devel@lists.01.org
> Cc: Ye, Ting 
> Subject: Re: [edk2] Network Stack Budgeting
> 
> 
> 
> On 29/01/2019 03:20, Fu, Siyuan wrote:
> > Hi, Tomas
> >
> >> -Original Message-
> >> From: Tomas Pilar (tpilar) [mailto:tpi...@solarflare.com]
> >> Sent: Monday, January 28, 2019 7:24 PM
> >> To: Fu, Siyuan ; Wu, Jiaxin ;
> Laszlo
> >> Ersek ; edk2-devel@lists.01.org
> >> Cc: Ye, Ting 
> >> Subject: Re: [edk2] Network Stack Budgeting
> >>
> >> Hi Siyuan,
> >>
> >> I had to do some tweaks due to the fact that people in the wild want to PXE
> >> boot whole WDS installations which are upwards of 300MB.
> >>
> >> I have an internal set of queues where the NIC receives into. Snp.Receive()
> >> will get a packet from this store. I had to implement a separate queue for
> >> unicast/multicast/broadcast traffic so that I could reprioritise and
> deliver
> >> unicast traffic while under ARP spam. I tied internal poll to receive and
> >> transmit, so Snp.Receive() will poll the NIC and then dequeue a packet
> while
> >> Snp.Transmit() will transmit the packet and then poll the NIC to get a
> >> completion. I also implemented a busy poll for 100us or until the next
> packet
> >> comes in when the NIC is polled.
> > I see some problems here. Both Snp.Receive() and Snp.Transmit() should be
> non-blocking
> > interface in current design and UEFI spec, but it's not true in your driver.
> > For Receive(), it could poll the NIC only once and return either a received
> packet
> > or an error, it should not do any blocking poll to wait for a packet.
> On some platforms (tftp clients), if the Snp.Receive() returns EFI_NOT_READY
> they do not poll the NIC until the next MnpSystemPoll(). Hence the delay
> before returning EFI_NOT_READY in case the packet is still incoming.

OK, that's really not good practice.

> > For Transmit(), it just need to put the packet into the TX queue and return
> directly,
> > without checking if the TX is completed.
> > Instead of that, Snp.GetStatus() should be
> > used to check if the packet has really been sent out.
> I've seen quite a few platforms where GetStatus was only called by the
> MnpSystemPoll() and the application would not call it. This means our hardware
> rings are stuffed with completions and we stop being able to transmit. Yes,
> you could say that we should solve the application, but unfortunately I can't
> do that.

The application doesn't need to call Snp.GetStatus() to recycle the TX buffer, 
the
Mnp.Transmit() will do this automatically when it found the SNP's TX buffer is 
full.
See MnpSyncSendPacket() and MnpRecycleTxBuf(). 

> >
> > May I know how did you control the 100us timeout of the busy poll (by which
> API?),
> > and what's the TPL of this busy poll?
> >
> Create a timeout timer with value of 1000. Then busy poll in a loop until
> packet is received or a timer is triggered.
> This runs at TPL_CALLBACK while the EfxPoll function itself runs at 
> TPL_NOTIFY.
> 
> --
>   /* Set the poll moderation timeout to 100us */
>   gBS->SetTimer(NetDev->PollModeratorTimer, TimerRelative, 1000);
> 
>   while (!InterruptStatus) {
>     EfxPoll(NULL, NetDev->Efx);
>     InterruptStatus = EfxStatus(NetDev->Efx);
> 
>     if (gBS->CheckEvent(NetDev->PollModeratorTimer))
>   return InterruptStatus;
>   }
> 
>   return InterruptStatus;
> --

This is exactly the case what I worried about. Some platform has a minimum timer
interval (like 1ms or 10ms), so if you set a timer interval shorter than that,
it will actually be signaled after the minimum value. Please check if your
platform could support a such a short timeout (100us).

> 
> >> Otherwise I have seen a pathological case where the TFTP client would pull
> one
> >> packet per second but the TFTP_RETRANSMIT interval on the server was also
> one
> >> second and everything was awful.
> > Why TFTP client just pull one packet per second? I think it’s not correct
> and it
> > could use the poll() function to accelerate the receive. Why you trying to
> solve a
> > TFTP layer problem in SNP layer? It breaks the design principle of network
> layer model.
> Yes, I appreciate the principle. However, in practice we don't get to sell
> adapters that do not PXE boot and it's pointless to argue with customers that
> they have a rubbish TFTP client implementation. So we put in workarounds into
> the driver.

OK I understand your situation now. Technically it will be better to fix the
problem in TFTP client, so I still suggest you to confirm this with your 
customer
or the TFTP application owner. This workaround in your SNP driver will put you
in the risk that a normal application which follow UEFI spec may not work 
correctly
with you, so I think you should only consider this method if you can confirm
the TFTP client is the only application layer clien

Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

[Laszlo Ersek]

Hi Bob,

On 01/29/19 03:05, Feng, Bob C wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=55
>
> V2:
> The python files under CParser4 folder of ECC/Eot tool
> are generated by antlr4 and forpython3 usage.
> They have python3 specific syntax, for example
> the data type declaration for the arguments of a function. That
> is not compitable with python2. this patch is to remove these syntax.
>
> The version2 patch set is commit to https://github.com/BobCF/edk2.git
> branch py3basetools_v2

(reusing the "test plan" from my email at
http://mid.mail-archive.com/cab4fed6-4c5d-94a9-b29f-da41ad7f320e@redhat.com>:)

I ran the following tests, at commit 6edb6bd9f182 ("BaseTools: Eot tool
Python3 adaption", 2019-01-29). Each test was performed in a clean tree
(after running "git clean -ffdx") and clean environment (I re-sourced
"edksetup.sh" for each test in separation). In addition, the base tools
were rebuilt (again from a clean tree) for each test, with the following
command [1]:

  nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)

(a) On my RHEL7.5 Workstation laptop, I have both the system-level
python packages installed (python-2.7.5-69.el7_5.x86_64), and the extra
python-3.4 stuff from EPEL-7 (python34-3.4.9-1.el7.x86_64).

(a1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build
utility picked

  PYTHON_COMMAND   = /usr/bin/python3.4

and I successfully built OvmfPkg for IA32, IA32X64, and X64; also
ArmVirtQemu for AARCH64. The built firmware images passed a smoke test
too.

(a2) I removed all the python34 packages (and the dependent packages)
from my laptop. Didn't set either of PYTHON3_ENABLE and PYTHON_COMMAND.
(This is the configuration what a "normal" RHEL7 environment would
provide.) The "build" utility didn't print any PYTHON_COMMAND setting,
but the same fw platform builds as in (a1) completed fine. The smoke
tests passed again as well.

(b) RHEL-8 virtual machine, with "/usr/bin/python3.6" from
python36-3.6.6-18.el8.x86_64, and "/usr/libexec/platform-python" from
platform-python-3.6.8-1.el8.x86_64.

(b1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build
utility picked

  PYTHON_COMMAND   = /usr/bin/python3.6

and I successfully built OvmfPkg for IA32, IA32X64, and X64. (I don't
have a cross-compiler installed in this environment yet, nor a RHEL8
aarch64 KVM guest, so I couldn't test ArmVirtQemu for now).

(b2) I set PYTHON_COMMAND to "/usr/libexec/platform-python". Didn't set
PYTHON3_ENABLE. The same builds as in (b1) succeeded.


For the series:

Tested-by: Laszlo Ersek 

Given that the testing is quite time consuming, I suggest that we push
v2 (assuming reviewers don't find critical issues), and address small
issues incrementally.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Add support for PPTT

[Krzysztof Koch]

Hi Zhichao,

Thank you for spotting that. I agree, the cache attribute check can be applied 
to all architectures.
I will submit a patch fixing that in the next few days.

Kind regards,
Krzysztof Koch

-Original Message-
From: Gao, Zhichao 
Sent: Sunday, January 27, 2019 14:33
To: Krzysztof Koch ; edk2-devel@lists.01.org
Cc: Gao, Liming 
Subject: RE: [edk2] [PATCH v1 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Add 
support for PPTT

The function ValidateCacheAttributes(..) is based on APCI spec.
It may not need the conditional pre-compiling for ARM CPU.

Thanks,
GaoZhichao

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Krzysztof Koch
> Sent: Wednesday, January 23, 2019 6:58 PM
> To: edk2-devel@lists.01.org
> Cc: n...@arm.com
> Subject: [edk2] [PATCH v1 1/1] ShellPkg/UefiShellAcpiViewCommandLib:
> Add support for PPTT
>
> Added the acpiview parser for the PPTT table.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Krzysztof Koch 
> ---
>
> The changes can be seen at:
> https://github.com/KrzysztofKoch1/edk2/tree/woa_390_pptt_acpiview_v1
>
> Notes:
> v1:
> - added a parser for PPTT in acpiview   [Krzysztof]
>
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> |  23 +-
>  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c   
> |
> 362 
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib
> .c   |   4 +-
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib
> .inf |   3 +-
>
> ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib
> .uni |   3 +-
>  5 files changed, 391 insertions(+), 4 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> index
> ecf7dae9038a4ebcb3e3764964f0c16ca3ef51f6..a42450c1431be343870dabb4e0
> 3f64ed1cf78afc 100644
> --- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
> @@ -1,7 +1,7 @@
>  /** @file
>Header file for ACPI parser
>
> -  Copyright (c) 2016 - 2018, ARM Limited. All rights reserved.
> +  Copyright (c) 2016 - 2019, ARM Limited. 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 @@ -655,6 +655,27 @@ ParseAcpiMcfg (
>IN UINT8   AcpiTableRevision
>);
>
> +/**
> +  This function parses the ACPI PPTT table.
> +  When trace is enabled this function parses the PPTT table and
> +  traces the ACPI table fields.
> +
> +  This function also performs validation of the ACPI table fields.
> +
> +  @param [in] Trace  If TRUE, trace the ACPI fields.
> +  @param [in] PtrPointer to the start of the buffer.
> +  @param [in] AcpiTableLengthLength of the ACPI table.
> +  @param [in] AcpiTableRevision  Revision of the ACPI table.
> +**/
> +VOID
> +EFIAPI
> +ParseAcpiPptt (
> +  IN BOOLEAN Trace,
> +  IN UINT8*  Ptr,
> +  IN UINT32  AcpiTableLength,
> +  IN UINT8   AcpiTableRevision
> +  );
> +
>  /**
>This function parses the ACPI RSDP table.
>
> diff --git
> a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser
> .c
> b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser
> .c
> new file mode 100644
> index
> ..d97ddf8e925d30917f888bf33
> e2c1346cd330663
> --- /dev/null
> +++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttPa
> +++ rs
> +++ er.c
> @@ -0,0 +1,362 @@
> +/** @file
> +  PPTT table parser
> +
> +  Copyright (c) 2019, ARM Limited. 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.
> +
> +  @par Reference(s):
> +- ACPI 6.2 Specification - Errata A, September 2017 **/
> +
> +#include 
> +#include 
> +#include "AcpiParser.h"
> +
> +// Local variables
> +STATIC CONST UINT8*  ProcessorTopologyStructureType; STATIC CONST
> +UINT8*  ProcessorTopologyStructureLength; STATIC CONST UINT32*
> +NumberOfPrivateResources; STATIC ACPI_DESCRIPTION_HEADER_INFO
> +AcpiHdrInfo;
> +
> +/**
> +  An ACPI_PARSER array describing the ACPI PPTT Table.
> +**/
> +STATIC CONST ACPI_PARSER PpttParser[] = {
> +  PARSE_ACPI_HEADER (&AcpiHdrInfo)
> +};
> +
> +/**
> +  This function validates the Cache Type Structure (Type 1) Line size field.
> +
> +  @pa

Re: [edk2] Network Stack Budgeting

[Tomas Pilar (tpilar)]

Hi Siyuan,

Thanks for the insights, hopefully removing the moderator will fix my current 
issue and I'll have a look at how to do the recycling better.

Cheers,
Tom

On 29/01/2019 13:06, Fu, Siyuan wrote:
> Hi, Tomas
>
>> -Original Message-
>> From: Tomas Pilar (tpilar) [mailto:tpi...@solarflare.com]
>> Sent: Tuesday, January 29, 2019 6:54 PM
>> To: Fu, Siyuan ; Wu, Jiaxin ; 
>> Laszlo
>> Ersek ; edk2-devel@lists.01.org
>> Cc: Ye, Ting 
>> Subject: Re: [edk2] Network Stack Budgeting
>>
>>
>>
>> On 29/01/2019 03:20, Fu, Siyuan wrote:
>>> Hi, Tomas
>>>
 -Original Message-
 From: Tomas Pilar (tpilar) [mailto:tpi...@solarflare.com]
 Sent: Monday, January 28, 2019 7:24 PM
 To: Fu, Siyuan ; Wu, Jiaxin ;
>> Laszlo
 Ersek ; edk2-devel@lists.01.org
 Cc: Ye, Ting 
 Subject: Re: [edk2] Network Stack Budgeting

 Hi Siyuan,

 I had to do some tweaks due to the fact that people in the wild want to PXE
 boot whole WDS installations which are upwards of 300MB.

 I have an internal set of queues where the NIC receives into. Snp.Receive()
 will get a packet from this store. I had to implement a separate queue for
 unicast/multicast/broadcast traffic so that I could reprioritise and
>> deliver
 unicast traffic while under ARP spam. I tied internal poll to receive and
 transmit, so Snp.Receive() will poll the NIC and then dequeue a packet
>> while
 Snp.Transmit() will transmit the packet and then poll the NIC to get a
 completion. I also implemented a busy poll for 100us or until the next
>> packet
 comes in when the NIC is polled.
>>> I see some problems here. Both Snp.Receive() and Snp.Transmit() should be
>> non-blocking
>>> interface in current design and UEFI spec, but it's not true in your driver.
>>> For Receive(), it could poll the NIC only once and return either a received
>> packet
>>> or an error, it should not do any blocking poll to wait for a packet.
>> On some platforms (tftp clients), if the Snp.Receive() returns EFI_NOT_READY
>> they do not poll the NIC until the next MnpSystemPoll(). Hence the delay
>> before returning EFI_NOT_READY in case the packet is still incoming.
> OK, that's really not good practice.
>
>>> For Transmit(), it just need to put the packet into the TX queue and return
>> directly,
>>> without checking if the TX is completed.
>>> Instead of that, Snp.GetStatus() should be
>>> used to check if the packet has really been sent out.
>> I've seen quite a few platforms where GetStatus was only called by the
>> MnpSystemPoll() and the application would not call it. This means our 
>> hardware
>> rings are stuffed with completions and we stop being able to transmit. Yes,
>> you could say that we should solve the application, but unfortunately I can't
>> do that.
> The application doesn't need to call Snp.GetStatus() to recycle the TX 
> buffer, the
> Mnp.Transmit() will do this automatically when it found the SNP's TX buffer 
> is full.
> See MnpSyncSendPacket() and MnpRecycleTxBuf(). 
>
>>> May I know how did you control the 100us timeout of the busy poll (by which
>> API?),
>>> and what's the TPL of this busy poll?
>>>
>> Create a timeout timer with value of 1000. Then busy poll in a loop until
>> packet is received or a timer is triggered.
>> This runs at TPL_CALLBACK while the EfxPoll function itself runs at 
>> TPL_NOTIFY.
>>
>> --
>>   /* Set the poll moderation timeout to 100us */
>>   gBS->SetTimer(NetDev->PollModeratorTimer, TimerRelative, 1000);
>>
>>   while (!InterruptStatus) {
>>     EfxPoll(NULL, NetDev->Efx);
>>     InterruptStatus = EfxStatus(NetDev->Efx);
>>
>>     if (gBS->CheckEvent(NetDev->PollModeratorTimer))
>>   return InterruptStatus;
>>   }
>>
>>   return InterruptStatus;
>> --
> This is exactly the case what I worried about. Some platform has a minimum 
> timer
> interval (like 1ms or 10ms), so if you set a timer interval shorter than that,
> it will actually be signaled after the minimum value. Please check if your
> platform could support a such a short timeout (100us).
>
 Otherwise I have seen a pathological case where the TFTP client would pull
>> one
 packet per second but the TFTP_RETRANSMIT interval on the server was also
>> one
 second and everything was awful.
>>> Why TFTP client just pull one packet per second? I think it’s not correct
>> and it
>>> could use the poll() function to accelerate the receive. Why you trying to
>> solve a
>>> TFTP layer problem in SNP layer? It breaks the design principle of network
>> layer model.
>> Yes, I appreciate the principle. However, in practice we don't get to sell
>> adapters that do not PXE boot and it's pointless to argue with customers that
>> they have a rubbish TFTP client implementation. So we put in workarounds into
>> the driver.
> OK I understand your situation now. Technically it will be better to fix the
> problem in TFTP client, so I still suggest you to confirm this with your 
> customer
> or t

Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

[Ryszard Knop]

Hi Ard,

I've finally got some time to review and merge all of this. A bit
problematic thing is that we internally have a separate tree that we
need to merge those commits into, then generate the open source tree
and related commits from that. This will result in somewhat broken
history, so sorry about that in advance - we're still figuring out the
proper way to handle multiple source trees on our end without messing
it up. I'll push these changes to edk2-staging once we've got it all
ready.

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI
> branch
> at github.com/tianocore so it can be built with GCC on Linux for ARM
> and AARCH64 (as well as X64)
> 
> Ard Biesheuvel (19):
>   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
> architectures
>   IntelUndiPkg: remove EOF markers
>   IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in
> filenames
>   IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path
> separators
>   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type
> definition
>   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for pointers
>   IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build
> options
>   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
>   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
>   IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
>   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting
>   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct
> pointer
> type
>   IntelUndiPkg/GigUndiDxe: don't take address of cast expression
>   IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros
> for
> GCC
>   IntelUndiPkg/GigUndiDxe: remove forward declaration of non-existent
> function
>   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
>   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file
>   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
>   IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables
> 
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
>  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++---
>  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++---
>  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++---
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39 +--
> 
>  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++---
>  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++---
>  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
>  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
>  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
>  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37 -
> -
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10 -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.c  |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.h  |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 18 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.c   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.h   |  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.c|  1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.h

Re: [edk2] [RFC] Proposal to split Pkgs

[Ni, Ray]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
> Ersek
> Sent: Tuesday, January 29, 2019 7:12 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Cc: Zimmer, Vincent ; Wolman, Ayellet
> ; Cetola, Stephano ;
> Kinney, Michael D 
> Subject: Re: [edk2] [RFC] Proposal to split Pkgs
> 
> Hi Ray,
> 
> On 01/29/19 06:59, Ni, Ray wrote:
> > Hello,
> > I'd like to propose to split today's BIG packages in following ways:
> >
> > ==Overview =
> >
> > 1. Separate Industry standard definitions from UEFI and PI interfaces.
> > 2. Separate UEFI and PI interfaces from implementations.
> > a. Separate UEFI and PI interfaces to different packages
> > b. Separate PI PEI, DXE and MM phase interfaces to different
> > packages 3. Separate different features into feature packages.
> > Feature interface may be in the feature package to provide minimal
> > common interface packages.
> >
> > The POC code is in https://github.com/jyao1/edk2/tree/ReOrg.
> > It basically split the EDKII common code to three directories:
> > Core/, Device/, and Feature/.
> > The code is in very early POC phase and only code in Core/ directory
> > can pass the build.
> > I would like to gather feedbacks through this RFC to see whether this
> > splitting direction makes sense.
> > Is there any other better ways of splitting?
> > Or perhaps do not split in such a small granularity?
> > Or perhaps Mike's work to move lib-c content to edk2-libc repo, to
> > move real platform code to edk2-platform repo is enough for now?
> >
> > ==More explanations =
> >
> > There are 9 packages inside Core/ directory:
> > 1. BasePkg
> > Contains industry standard definitions (exclude UEFI and PI) and base
> > libraries that non-UEFI and non-PI development can depend on.
> > UEFI or PI development can also depend on this package.
> > 2. UefiPkg
> > Contains UEFI interfaces and libraries that UEFI driver-model driver
> > development can depend on.
> > 3. PiPeiPkg
> > Contains PI interfaces and libraries for PEI phase that PEI module
> > development can depend on.
> > 4. PiDxePkg
> > Contains PI interfaces and libraries for DXE phase that DXE module
> > development can depend on.
> > 5. PiMmPkg
> > Contains PI interfaces and libraries for MM phase that MM/SMM module
> > development can depend on.
> > 6. MdeModulePkg (TianoPkg? Name is still TBD) Contains Tiano
> > implementation specific interfaces and libraries.
> > Developing modules for pure UEFI or PI should not depend on this package.
> > 7. PeiFoundationPkg
> > Contains the PEI foundation modules (PeiCore and DxeIpl) and supported
> > libraries.
> > 8. DxeFoundationPkg
> > Contains the DXE foundation modules (DxeCore and RuntimeDxe) and
> > supported libraries.
> > 9. SmmFoundationPkg
> > Contains the SMM foundation modules (SmmCore, SmmIpl and
> > SmmCommunicationBuffer) and supported libraries.
> >
> > These packages are positioned in different layers. The package in
> > higher layer depends on all packages that are in lower layers.
> > Layer 0: BasePkg.
> > Layer 1: UefiPkg.
> > Layer 2: PiPeiPkg
> > Layer 3: PiDxePkg
> > Layer 4: PiMmPkg
> > Layer 5: MdeModulePkg (TianoPkg?)
> >
> > All other modules are put to small packages under Device/ or Feature/.
> >
> > == Benefit of this proposal =
> >
> > This helps to reduce the size of each package, especially the very BIG
> > MdeModulePkg which contains almost all edk2 modules (except CPU,
> > network, etc). So platform can use git sparse checkout feature to only
> > clone the needed code still in package granularity.
> > This also helps to separate the code maintenance to more expert
> > developers. MdeModulePkg is just too huge to be maintained by 2 or 3
> > developers.
> 
> from a first / quick skim, it sounds OK to me; however, I'd like to 
> explicitly defer
> on this to the other stewards & stakeholders. I remember that Leif had ideas
> about reorganizing the tree.

That's great to have feedbacks in the early phase.

> 
> (Also, I vaguely feel that the movement/renaming of some macros / definitions
> that Andrew and Mike have been discussing in thread
> 
>   [edk2] History question about Base.h and its alternate parallel name
>  space Should we change it?
> 
> might overlap with this reorg.)
> 
> Regarding the benefits, I agree that we need clearer / finer grained 
> assignments
> between modules / packages and maintainers. I'm unsure if that really requires
> reorganizing the tree (we could just reorganize Maintainers.txt instead -- add
> some pathname patterns), but I agree that reorganizing the tree is one method
> that could work.
I agree adding more information in Maintainers.txt works as well.
Thanks for providing the "pathname pattern" idea.
I may do that in parallel to find more maintainers for MdeModulePkg.
Do you agree to have more than 2 maintainers for MdeModulePkg?

> 
> Regard

Re: [edk2] [PATCH] ArmPkg: update InvalidateInstructionCacheRange to flush only to PoU

[Laszlo Ersek]

On 01/29/19 12:19, xinliang wrote:
> 
> 
> On 2019/1/29 14:47, Tan Xiaojun wrote:
>> +cc Xinliang
>>
>> Sorry, I didn't react to what you discussed at the beginning, because
>> this
>> problem is mainly handled by Xinliang.
>>
>> The host we used for testing is Huawei D06 (AArch64), and its CPU chip is
>> 1620 (self-developed chip that follows the arm v8.2 specification).
>> Its vmid
>> is 16 bit.
>>
>> Thanks.
>> Xiaojun.
>>
>> On 2019/1/28 21:46, Mark Rutland wrote:
>>> On Mon, Jan 28, 2019 at 09:09:26PM +0800, Tan Xiaojun wrote:
 On 2019/1/28 19:54, Laszlo Ersek wrote:
> On 01/28/19 11:46, Mark Rutland wrote:
>> On Wed, Jan 23, 2019 at 10:54:56AM +0100, Laszlo Ersek wrote:
>>> And even on the original (unspecified) hardware, the same binary
>>> works
>>> frequently. My understanding is that there are five VMs executing
>>> reboot
>>> loops in parallel, on the same host, and 4 out of 5 may hit the
>>> issue in
>>> a reasonable time period (300 reboots or so).
>> Interesting.
>>
>> Do you happen to know how many VMID bits the host has? If it has
>> an 8-bit VMID,
>> this could be indicative of some problem upon overflow.
> I'll let Tan Xiaojun (CC'd) answer this questions.
>
>> Can you point us at the host kernel?
> In the report, Tan Xiaojun wrote "4.18.0-48.el8.aarch64"; I guess that
> information is mostly useless in an upstream discussion.
> Unfortunately,
> I couldn't reproduce the symptom at all (I know nothing about the
> hardware in question), so I can't myself retest with an upstream host
> kernel.
 I don't understand, what do you want me to do? What is the specific
 problem?
>>> Could you let us know which CPU/system you've seen this issue with?
>>>
>>> ... and what the value of ID_AA64MMFR1_EL1.VMIDBits is?
> 
> Hi, our hardware is D06 board which compatible with armv8.1. So it
> should be 16-bit VMID.
> 
> BTW, we now only reproduce this issue on guest without shim, such as
> suse SLE15-SP1 guest which is easy to reproduce. This founding not sure
> could help for this issue.

Unfortunately, it doesn't help without access to the host -- I used the
exact same guest installer ISO from the original report, and failed to
reproduce the symptom.

... Since we've been discussing this for a while in public too, can
someone from Huawei please authorize Red Hat to open up
 to the public? If
you agree, please comment so on the BZ itself.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to split Pkgs

[Laszlo Ersek]

On 01/29/19 14:13, Ni, Ray wrote:
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
>> Ersek
>> Sent: Tuesday, January 29, 2019 7:12 PM
>> To: Ni, Ray ; edk2-devel@lists.01.org
>> Cc: Zimmer, Vincent ; Wolman, Ayellet
>> ; Cetola, Stephano ;
>> Kinney, Michael D 
>> Subject: Re: [edk2] [RFC] Proposal to split Pkgs

>> Regarding the benefits, I agree that we need clearer / finer grained 
>> assignments
>> between modules / packages and maintainers. I'm unsure if that really 
>> requires
>> reorganizing the tree (we could just reorganize Maintainers.txt instead -- 
>> add
>> some pathname patterns), but I agree that reorganizing the tree is one method
>> that could work.

> I agree adding more information in Maintainers.txt works as well.
> Thanks for providing the "pathname pattern" idea.
> I may do that in parallel to find more maintainers for MdeModulePkg.
> Do you agree to have more than 2 maintainers for MdeModulePkg?

I certainly do; I think we should assign maintainers under MdeModulePkg
on a module (library instance, driver) basis.

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Network Stack Budgeting

[Laszlo Ersek]

On 01/29/19 11:54, Tomas Pilar (tpilar) wrote:
>> Why TFTP client just pull one packet per second? I think it’s not
>> correct and it could use the poll() function to accelerate the
>> receive. Why you trying to solve a TFTP layer problem in SNP layer?
>> It breaks the design principle of network layer model.

> Yes, I appreciate the principle. However, in practice we don't get to
> sell adapters that do not PXE boot and it's pointless to argue with
> customers that they have a rubbish TFTP client implementation. So we
> put in workarounds into the driver.

Actually, I think this is the core principle behind the UEFI forum, and
the UEFI spec. You shouldn't have to implement bug compat hacks. The era
when an add-on card would work on some platform's BIOS but not on
another's should be left behind. You have a spec to point at, and the
platform in question was likely certified against that spec in some form
(possibly self-certified).

Sp I think it would be reasonable to contact the platform vendor, and to
direct your own customers to that ticket too. If you have a
representative on the USWG, it might make sense to raise the issue there
as well, especially if the issue is wide-spread and affects multiple
platform vendors. The UEFI spec targets practical, common use cases, and
this looks like one.

(When a RH customer or partner reports e.g. a RHEL kernel issue to us,
and we determine it is a problem in the firmware, we absolutely talk to
the platform vendor, and sometimes to standards bodies too. We also
advise customers on the applications that they run on RHEL, if they ask
and/or care to listen. Plus, some high-profile applications and RHEL are
explicitly certified against each other.)

... I don't mean to intrude of course; I'm sorry if I came through like
that.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 04/12] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the GUID definitions for LockBox which is used to
save a list of storage devices that need to get initialized during the S3
resume.

The content of the LockBox will be a DevicePath structure that contains
zero or more DevicePath instances. Each instance denotes a storage device
that needs to get initialized during the S3 resume.

The producers of the content of this LockBox will be drivers like
OpalPassword DXE driver. This kind of drivers requires some specific
storage devices to be initialized during the PEI phase of in S3 resume.
(For the OpalPasword case, it requires the managing devices to be
automatically unlocked during the S3 resume).

The attribute of the LockBox should be set to
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY.

The consumers of the content of this LockBox will be PEI storage device
controller/bus drivers (e.g. NvmExpressPei) during S3 resume. This kind of
drivers can use the DevicePath instances stored in the LockBox to get a
list of devices that need to get initialized. In such way, an on-demand
(partial) device enumeration/initialization can be performed to benefit
the S3 resume performance.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dec   |  3 ++
 MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h | 36 
 2 files changed, 39 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 7f646d7702..a2130bc439 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -422,6 +422,9 @@
   ## Include/Guid/S3SmmInitDone.h
   gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71, 0x84, 
0x50, 0x25, 0x79, 0x2e, 0xf6 } }
 
+  ## Include/Guid/S3StorageDeviceInitList.h
+  gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 
0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
diff --git a/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h 
b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
new file mode 100644
index 00..cfbd2a78e7
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
@@ -0,0 +1,36 @@
+/** @file
+  Define the LockBox GUID for list of storage devices need to be initialized in
+  S3.
+
+  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 __S3_STORAGE_DEVICE_INIT_LIST_H__
+#define __S3_STORAGE_DEVICE_INIT_LIST_H__
+
+#define S3_STORAGE_DEVICE_INIT_LIST \
+  { \
+0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 0x9e, 0xef, 0xb6, 0x17, 0xc8, 
0xef } \
+  }
+
+//
+// The LockBox will store a DevicePath structure that contains zero or more
+// DevicePath instances. Each instance denotes a storage device that needs to
+// get initialized during the S3 resume.
+//
+// The attribute of the LockBox should be set to
+// 'LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY'.
+//
+extern EFI_GUID  gS3StorageDeviceInitListGuid;
+
+#endif  // __S3_STORAGE_DEVICE_INIT_LIST_H__
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 02/12] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the definitions for EDKII PEI ATA PassThru PPI. This
PPI will provide services that allow ATA commands to be sent to ATA
devices attached to an ATA controller in the PEI phase.

More specifically, the PPI will provide services to:

* Send ATA commands to an ATA device (by service 'PassThru');
* Get the list of the attached ATA device on a controller (by services
  'GetNextPort' and 'GetNextDevice');
* Get the identification information (DevicePath) of the underlying ATA
  host controller (by service 'GetDevicePath').

Cc: Jian J Wang 
Cc: Ruiyu Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dec  |   3 +
 MdeModulePkg/Include/Ppi/AtaPassThru.h | 359 
 2 files changed, 362 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4411185073..8efb19e626 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -483,6 +483,9 @@
   ## Include/Ppi/AtaAhciController.h
   gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
 
+  ## Include/Ppi/AtaPassThru.h
+  gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
diff --git a/MdeModulePkg/Include/Ppi/AtaPassThru.h 
b/MdeModulePkg/Include/Ppi/AtaPassThru.h
new file mode 100644
index 00..9281f0b833
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/AtaPassThru.h
@@ -0,0 +1,359 @@
+/** @file
+
+  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_ATA_PASS_THRU_PPI_H_
+#define _EDKII_ATA_PASS_THRU_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_PEI_ATA_PASS_THRU_PPI.
+///
+#define EDKII_PEI_ATA_PASS_THRU_PPI_GUID \
+  { \
+0xa16473fd, 0xd474, 0x4c89, { 0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 
0x9 } \
+  }
+
+//
+// Forward declaration for the EDKII_PEI_ATA_PASS_THRU_PPI.
+//
+typedef struct _EDKII_PEI_ATA_PASS_THRU_PPI  EDKII_PEI_ATA_PASS_THRU_PPI;
+
+//
+// Revision The revision to which the ATA Pass Thru PPI interface adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_PEI_ATA_PASS_THRU_PPI_REVISION 0x0001
+
+typedef struct {
+  UINT32Attributes;
+  UINT32IoAlign;
+} EDKII_PEI_ATA_PASS_THRU_MODE;
+
+///
+/// If this bit is set, then the EDKII_PEI_ATA_PASS_THRU_PPI interface is for
+/// physical devices on the ATA controller.
+///
+#define EDKII_PEI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL  0x0001
+///
+/// If this bit is set, then the EDKII_PEI_ATA_PASS_THRU_PPI interface is for
+/// logical devices on the ATA controller.
+///
+#define EDKII_PEI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL   0x0002
+
+typedef struct {
+  UINT8Reserved1[2];
+  UINT8AtaStatus;
+  UINT8AtaError;
+  UINT8AtaSectorNumber;
+  UINT8AtaCylinderLow;
+  UINT8AtaCylinderHigh;
+  UINT8AtaDeviceHead;
+  UINT8AtaSectorNumberExp;
+  UINT8AtaCylinderLowExp;
+  UINT8AtaCylinderHighExp;
+  UINT8Reserved2;
+  UINT8AtaSectorCount;
+  UINT8AtaSectorCountExp;
+  UINT8Reserved3[6];
+} EDKII_PEI_ATA_STATUS_BLOCK;
+
+typedef struct {
+  UINT8Reserved1[2];
+  UINT8AtaCommand;
+  UINT8AtaFeatures;
+  UINT8AtaSectorNumber;
+  UINT8AtaCylinderLow;
+  UINT8AtaCylinderHigh;
+  UINT8AtaDeviceHead;
+  UINT8AtaSectorNumberExp;
+  UINT8AtaCylinderLowExp;
+  UINT8AtaCylinderHighExp;
+  UINT8AtaFeaturesExp;
+  UINT8AtaSectorCount;
+  UINT8AtaSectorCountExp;
+  UINT8Reserved2[6];
+} EDKII_PEI_ATA_COMMAND_BLOCK;
+
+typedef UINT8 EDKII_PEI_ATA_PASS_THRU_CMD_PROTOCOL;
+
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_ATA_HARDWARE_RESET  0x00
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_ATA_SOFTWARE_RESET  0x01
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_ATA_NON_DATA0x02
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_PIO_DATA_IN 0x04
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_PIO_DATA_OUT0x05
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_DMA 0x06
+#define EDKII_PEI_ATA_PASS_THRU_PROTOCOL_DMA_QUEUED  0x07
+#define EDKII_PEI_AT

[edk2] [PATCH v1 00/12] Split the S3 PEI phase HW init codes from Opal driver

[Hao Wu]

The series is also available at:
https://github.com/hwu25/edk2/tree/opal_remodel


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 NVME
device initialization during the PEI phase in order to produce the Block
IO PPI.

Moreover, there is a Bugzilla request (BZ-1483) for adding the Block IO
PPI support for ATA device as well. So there is likely to be an PEI driver
for ATA device that will handle the ATA device initialization.

In order to remove code duplication, the series will split the S3 phase
device initialization related codes out from the OpalPassword driver. And
let the existing NvmExpressPei driver and the new AhciPei driver to handle
the task.

After this remodel, NvmExpressPei and AhciPei drivers will produce a PPI
called Storage Security Command PPI. And the OpalPassword driver will
consume this PPI to perform the device auto-unlock in S3 resume.


Patch   1~4: Add the definitions of PPIs and GUIDs;
Patch 5: Refinement for the NvmExpressPei driver;
Patch   6~7: Update the NvmExpressPei driver to produce the PPI needed by
 OpalPassword;
Patch 8: Add the Ahci mode ATA device support in the PEI phase, it
 will produce the PPI needed by OpalPassword;
Patch  9~10: Refinements for the SmmLockBoxLib;
Patch11: Support LockBox enlarge for LockBoxLib API UpdateLockBox();
Patch12: Remove the hardware initialization codes from the
 OpalPassword driver. And consume the SSC PPI to unlock device
 in S3 resume.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Cc: Star Zeng 
Cc: Chao Zhang 
Cc: Jiewen Yao 

Hao Wu (12):
  MdeModulePkg: Add definitions for ATA AHCI host controller PPI
  MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI
  MdeModulePkg: Add definitions for Storage Security Command PPI
  MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3
  MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable
  MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
  MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox
  MdeModulePkg/AhciPei: Add AHCI mode ATA device support in PEI
  MdeModulePkg/SmmLockBoxLib: Use 'DEBUG_' prefix instead of 'EFI_D_'
  MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()
  MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()
  SecurityPkg/OpalPassword: Remove HW init codes and consume SSC PPI

 MdeModulePkg/MdeModulePkg.dec |   12 +
 MdeModulePkg/MdeModulePkg.dsc |1 +
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf  |   78 +
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf  |   18 +-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf |6 +-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.inf |   12 +-
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h|  741 
+++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.h |  264 +++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiPassThru.h|  184 ++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiStorageSecurity.h |  247 +++
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h|  109 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h |   20 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h |  247 +++
 MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h   |   36 +
 MdeModulePkg/Include/Library/LockBoxLib.h |7 +-
 MdeModulePkg/Include/Ppi/AtaAhciController.h  |   89 +
 MdeModulePkg/Include/Ppi/AtaPassThru.h|  359 
 MdeModulePkg/Include/Ppi/StorageSecurityCommand.h |  283 +++
 SecurityPkg/Tcg/Opal/OpalPassword/OpalAhciMode.h  |  412 
 SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.h|4 +-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeMode.h  |  327 ---
 SecurityPkg/Tcg/Opal/OpalPassword/OpalNvmeReg.h   |  815 

 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordCommon.h|   45 +-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.h   |  106 +-
 MdeModulePkg/Bus/Ata/AhciPei/AhciMode.c   | 2134 

 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.c|  337 
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiBlockIo.c |  533 +
 MdeModulePkg/Bus/Ata/AhciPei/

[edk2] [PATCH v1 01/12] MdeModulePkg: Add definitions for ATA AHCI host controller PPI

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the definitions for ATA AHCI host controller PPI. The
purpose of the PPI in to provide:

* MMIO base address
* Controller identification information (DevicePath)

for ATA host controllers working under AHCI mode.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dec|  3 +
 MdeModulePkg/Include/Ppi/AtaAhciController.h | 89 
 2 files changed, 92 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index e5c32d15ed..4411185073 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -480,6 +480,9 @@
   ## Include/Ppi/NvmExpressHostController.h
   gEdkiiPeiNvmExpressHostControllerPpiGuid  = { 0xcae3aa63, 0x676f, 0x4da3, { 
0xbd, 0x50, 0x6c, 0xc5, 0xed, 0xde, 0x9a, 0xad } }
 
+  ## Include/Ppi/AtaAhciController.h
+  gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
diff --git a/MdeModulePkg/Include/Ppi/AtaAhciController.h 
b/MdeModulePkg/Include/Ppi/AtaAhciController.h
new file mode 100644
index 00..2bdd53ff36
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/AtaAhciController.h
@@ -0,0 +1,89 @@
+/** @file
+
+  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_ATA_AHCI_HOST_CONTROLLER_PPI_H_
+#define _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
+///
+#define EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_GUID \
+  { \
+0x61dd33ea, 0x421f, 0x4cc0, { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 
0x61 } \
+  }
+
+//
+// Forward declaration for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
+//
+typedef struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI  
EDKII_ATA_AHCI_HOST_CONTROLLER_PPI;
+
+/**
+  Get the MMIO base address of ATA AHCI host controller.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  ControllerId The ID of the ATA AHCI host controller.
+  @param[out] MmioBar  The MMIO base address of the controller.
+
+  @retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+  @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not 
found.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ATA_AHCI_HC_GET_MMIO_BAR) (
+  IN  EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
+  IN  UINT8 ControllerId,
+  OUT UINTN *MmioBar
+  );
+
+/**
+  Get the device path of ATA AHCI host controller.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  ControllerId The ID of the ATA AHCI host controller.
+  @param[out] DevicePathLength The length of the device path in bytes 
specified
+   by DevicePath.
+  @param[out] DevicePath   The device path of ATA AHCI host controller.
+   This field re-uses EFI Device Path Protocol 
as
+   defined by Section 10.2 EFI Device Path 
Protocol
+   of UEFI 2.7 Specification.
+
+  @retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+  @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not 
found.
+  @retval EFI_OUT_OF_RESOURCES The operation fails due to lack of 
resources.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ATA_AHCI_HC_GET_DEVICE_PATH) (
+  IN  EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
+  IN  UINT8 ControllerId,
+  OUT UINTN *DevicePathLength,
+  OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath
+  );
+
+//
+// This PPI contains a set of services to interact with the ATA AHCI host 
controller.
+//
+struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI {
+  EDKII_ATA_AHCI_HC_GET_MMIO_BAR   GetAhciHcMmioBar;
+  EDKII_ATA_AHCI_HC_GET_DEVICE_PATHGetAhciHcDevicePath;
+};
+
+extern EFI_GUID gEdkiiPeiAtaAhciHostControllerPpiGuid;
+
+#endif
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.

[edk2] [PATCH v1 05/12] MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable

[Hao Wu]

This commit is out of the scope for BZ-1409. The commit will remove the
call of RegisterForShadow() at the entry point of the driver. By doing so,
the driver is now possible to be executed without being re-loaded into
permanent memory.

Thus, this commit will update the NvmExpressPei driver to avoid updating
the content of a global variable.

Cc: Jian J Wang 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h |  12 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c| 153 +++-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c |  11 +-
 3 files changed, 92 insertions(+), 84 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 0bd62c2459..0135eca6f0 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -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
@@ -147,13 +147,9 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, EndOfPeiNotifyList, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
 
 
-/**
-  Initialize IOMMU.
-**/
-VOID
-IoMmuInit (
-  VOID
-  );
+//
+// Internal functions
+//
 
 /**
   Allocates pages that are suitable for an OperationBusMasterCommonBuffer or
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
index 51b48d38dd..cb629c16b0 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
@@ -1,7 +1,7 @@
 /** @file
   The DMA memory help function.
 
-  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
@@ -16,7 +16,33 @@
 
 #include "NvmExpressPei.h"
 
-EDKII_IOMMU_PPI  *mIoMmu;
+/**
+  Get IOMMU PPI.
+
+  @return Pointer to IOMMU PPI.
+
+**/
+EDKII_IOMMU_PPI *
+GetIoMmu (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu  = NULL;
+  Status = PeiServicesLocatePpi (
+ &gEdkiiIoMmuPpiGuid,
+ 0,
+ NULL,
+ (VOID **) &IoMmu
+ );
+  if (!EFI_ERROR (Status) && (IoMmu != NULL)) {
+return IoMmu;
+  }
+
+  return NULL;
+}
 
 /**
   Provides the controller-specific addresses required to access system memory 
from a
@@ -46,18 +72,21 @@ IoMmuMap (
   OUT VOID  **Mapping
   )
 {
-  EFI_STATUS  Status;
-  UINT64  Attribute;
-
-  if (mIoMmu != NULL) {
-Status = mIoMmu->Map (
-   mIoMmu,
-   Operation,
-   HostAddress,
-   NumberOfBytes,
-   DeviceAddress,
-   Mapping
-   );
+  EFI_STATUS Status;
+  UINT64 Attribute;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu = GetIoMmu ();
+
+  if (IoMmu != NULL) {
+Status = IoMmu->Map (
+ IoMmu,
+ Operation,
+ HostAddress,
+ NumberOfBytes,
+ DeviceAddress,
+ Mapping
+ );
 if (EFI_ERROR (Status)) {
   return EFI_OUT_OF_RESOURCES;
 }
@@ -78,11 +107,11 @@ IoMmuMap (
   ASSERT(FALSE);
   return EFI_INVALID_PARAMETER;
 }
-Status = mIoMmu->SetAttribute (
-   mIoMmu,
-   *Mapping,
-   Attribute
-   );
+Status = IoMmu->SetAttribute (
+  IoMmu,
+  *Mapping,
+  Attribute
+  );
 if (EFI_ERROR (Status)) {
   return Status;
 }
@@ -108,11 +137,14 @@ IoMmuUnmap (
   IN VOID  *Mapping
   )
 {
-  EFI_STATUS  Status;
+  EFI_STATUS Status;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu = GetIoMmu ();
 
-  if (mIoMmu != NULL) {
-Status = mIoMmu->SetAttribute (mIoMmu, Mapping, 0);
-Status = mIoMmu->Unmap (mIoMmu, Mapping);
+  if (IoMmu != NULL) {
+Status = IoMmu->SetAttribute (IoMmu, Mapping, 0);
+Status = IoMmu->Unmap (IoMmu, Mapping);
   } else {
 Status = EFI_SUCCESS;
   }
@@ -148,39 +180,42 @@ IoMmuAllocateBuffer (
   EFI_STATUSStatus;
   UINTN NumberOfBytes;
   EFI_PHYSICAL_ADDRESS  HostPhyAddress;
+  EDKII_IOMMU_PPI   *IoMmu;
 
   *HostAddress = NULL;
   *DeviceAddress = 0

[edk2] [PATCH v1 06/12] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI

[Hao Wu]

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|  81 +++-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h |  20 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h | 247 

 MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c   | 317 
+++
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143 +--
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c |  32 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c | 423 

 8 files changed, 1184 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..7047c4f3ff 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"
 
 //
 // NVME PEI driver implementation related definitions
@@ -90,10 +92,15 @@ struct _PEI_NVME_NAMESPACE_INFO {
 struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   UINT32Signature;
   UINTN MmioBase;
+  UINTN DevicePathLength;
+  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
+
   EFI_PEI_RECOVERY_BLOCK_IO_PPI BlkIoPpi;
   EFI_PEI_RECOVERY_BLOCK_IO2_PPIBlkIo2Ppi;
+  EDKII_PEI_STORAGE_SECURITY_CMD_PPIStorageSecurityPpi;
   EFI_PEI_PPI_DESCRIPTORBlkIoPpiList;
   EFI_PEI_PPI_DESCRIPTORBlkIo2PpiList;
+  EFI_PEI_PPI_DESCRIPTORStorageSecurityPpiList;
   EFI_PEI_NOTIFY_DESCRIPTOR EndOfPeiNotifyList;
 
   //
@@ -139,11 +146,13 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   PEI_NVME_NAMESPACE_INFO   *NamespaceInfo;
 };
 
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO(a) \
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO(a)   \
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, BlkIoPpi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2(a)\
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2(a)  \
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, BlkIo2Ppi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_NOTIFY(a)\
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_STROAGE_SECURITY(a)\
+  CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, StorageSecurityPpi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNA

[edk2] [PATCH v1 03/12] MdeModulePkg: Add definitions for Storage Security Command PPI

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the definitions for Storage Security Command (SSC)
PPI. This PPI will be be used to abstract mass storage devices to allow
code running in the PEI phase to send security protocol commands to mass
storage devices without specific knowledge of the type of device or
controller that manages the device.

More specifically, the PPI will provide services to:

* Get the number of mass storage devices managed by a instance of the SSC
  PPI (by service 'GetNumberofDevices');
* Get the identification information (DevicePath) of a managing mass
  storage devices (by service 'GetDevicePath');
* Send security protocol commands to mass storage devices (by services
  'ReceiveData' and 'SendData').

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dec |   3 +
 MdeModulePkg/Include/Ppi/StorageSecurityCommand.h | 283 
 2 files changed, 286 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 8efb19e626..7f646d7702 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -483,6 +483,9 @@
   ## Include/Ppi/AtaAhciController.h
   gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
 
+  ## Include/Ppi/StorageSecurityCommand.h
+  gEdkiiPeiStorageSecurityCommandPpiGuid= { 0x35de0b4e, 0x30fb, 0x46c3, { 
0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 0x56 } }
+
   ## Include/Ppi/AtaPassThru.h
   gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
 
diff --git a/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h 
b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
new file mode 100644
index 00..cc1688dabb
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
@@ -0,0 +1,283 @@
+/** @file
+
+  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_STORAGE_SECURITY_COMMAND_PPI_H_
+#define _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
+///
+#define EDKII_PEI_STORAGE_SECURITY_CMD_PPI_GUID \
+  { \
+0x35de0b4e, 0x30fb, 0x46c3, { 0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 
0x56 } \
+  }
+
+//
+// Forward declaration for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
+//
+typedef struct _EDKII_PEI_STORAGE_SECURITY_CMD_PPI  
EDKII_PEI_STORAGE_SECURITY_CMD_PPI;
+
+//
+// Revision The revision to which the Storage Security Command interface 
adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_STORAGE_SECURITY_PPI_REVISION  0x0001
+
+
+/**
+  Gets the count of storage security devices that one specific driver detects.
+
+  @param[in]  This   The PPI instance pointer.
+  @param[out] NumberofDevicesThe number of storage security devices 
discovered.
+
+  @retval EFI_SUCCESS  The operation performed successfully.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_PEI_STORAGE_SECURITY_GET_NUMBER_DEVICES) (
+  IN  EDKII_PEI_STORAGE_SECURITY_CMD_PPI*This,
+  OUT UINTN *NumberofDevices
+  );
+
+/**
+  Gets the device path of a specific storage security device.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  DeviceIndex  Specifies the storage security device to 
which
+   the function wants to talk. Because the 
driver
+   that implements Storage Security Command 
PPIs
+   will manage multiple storage devices, the 
PPIs
+   that want to talk to a single device must 
specify
+   the device index that was assigned during 
the
+   enumeration process. This index is a number 
from
+   one to NumberofDevices.
+  @param[out] DevicePathLength The length of the device path in bytes 
specified
+   by DevicePath.
+  @param[out] DevicePath   The device path of storage security device.
+   This field re-uses EFI De

[edk2] [PATCH v1 10/12] MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()

[Hao Wu]

This commit is out of the scope for BZ-1409. It is a refinement for the
PEI library instance within SmmLockBoxLib.

For the below ASSERT statement within function RestoreLockBox():
  Status = SmmCommunicationPpi->Communicate (
  SmmCommunicationPpi,
  &CommBuffer[0],
  &CommSize
  );
  if (Status == EFI_NOT_STARTED) {
//
// Pei SMM communication not ready yet, so we access SMRAM directly
//
DEBUG ((DEBUG_INFO, "SmmLockBoxPeiLib Communicate - (%r)\n", Status));
Status = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
LockBoxParameterRestore->Header.ReturnStatus = (UINT64)Status;
if (Length != NULL) {
  LockBoxParameterRestore->Length = (UINT64)*Length;
}
  }
  ASSERT_EFI_ERROR (Status);

It is possible for previous codes to return an error status that is
possible for happen. One example is that, when the 'if' statement
'if (Status == EFI_NOT_STARTED) {' is entered, function
InternalRestoreLockBoxFromSmram() is possible to return 'BUFFER_TOO_SMALL'
if the caller of RestoreLockBox() provides a buffer that is too small to
hold the content of LockBox.

Thus, this commit will remove the ASSERT here.

Please note that the current implementation of RestoreLockBox() is
handling the above-mentioned error case properly, so no additional error
handling codes are needed here.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
index 9f73480070..9d7b4c3706 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
@@ -623,7 +623,7 @@ RestoreLockBox (
   LockBoxParameterRestore->Length = (UINT64)*Length;
 }
   }
-  ASSERT_EFI_ERROR (Status);
+  //ASSERT_EFI_ERROR (Status);
 
   if (Length != NULL) {
 *Length = (UINTN)LockBoxParameterRestore->Length;
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v1 09/12] MdeModulePkg/SmmLockBoxLib: Use 'DEBUG_' prefix instead of 'EFI_D_'

[Hao Wu]

This commit is out of the scope for BZ-1409. It is a coding style
refinement for the SmmLockBoxLib.

More specifically, the commit will remove all the debug message display
level macros starting with 'EFI_D_' and replace them with macros starting
with 'DEBUG_'.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c | 22 +++---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 26 +++
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 78 ++--
 3 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
index ac8bcd2ff7..0428decbac 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -153,7 +153,7 @@ SaveLockBox (
   UINT8   *CommBuffer;
   UINTN   CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SaveLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SaveLockBox - Enter\n"));
 
   //
   // Basic check
@@ -199,7 +199,7 @@ SaveLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterSave->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SaveLockBox - Exit (%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SaveLockBox - Exit (%r)\n", Status));
 
   //
   // Done
@@ -235,7 +235,7 @@ SetLockBoxAttributes (
   UINT8 *CommBuffer;
   UINTN CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Enter\n"));
 
   //
   // Basic check
@@ -281,7 +281,7 @@ SetLockBoxAttributes (
 
   Status = (EFI_STATUS)LockBoxParameterSetAttributes->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Exit (%r)\n", 
Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Exit (%r)\n", 
Status));
 
   //
   // Done
@@ -322,7 +322,7 @@ UpdateLockBox (
   UINT8 *CommBuffer;
   UINTN CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib UpdateLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib UpdateLockBox - Enter\n"));
 
   //
   // Basic check
@@ -369,7 +369,7 @@ UpdateLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterUpdate->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib UpdateLockBox - Exit (%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib UpdateLockBox - Exit (%r)\n", Status));
 
   //
   // Done
@@ -411,7 +411,7 @@ RestoreLockBox (
   UINT8  *CommBuffer;
   UINTN  CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreLockBox - Enter\n"));
 
   //
   // Basic check
@@ -467,7 +467,7 @@ RestoreLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterRestore->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreLockBox - Exit (%r)\n", 
Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreLockBox - Exit (%r)\n", 
Status));
 
   //
   // Done
@@ -496,7 +496,7 @@ RestoreAllLockBoxInPlace (
   UINT8   *CommBuffer;
   UINTN   CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Enter\n"));
 
   SmmCommunication = LockBoxGetSmmCommProtocol ();
   if (SmmCommunication == NULL) {
@@ -532,7 +532,7 @@ RestoreAllLockBoxInPlace (
 
   Status = (EFI_STATUS)LockBoxParameterRestoreAllInPlace->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Exit 
(%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Exit 
(%r)\n", Status));
 
   //
   // Done
diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
index 8a168663c4..9f73480070 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -542,7 +542,7 @@ RestoreLockBox (
   // } EFI_SMM_

[edk2] [PATCH v1 11/12] MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the support to enlarge a LockBox when using the
LockBoxLib API UpdateLockBox().

Please note that the new support will ONLY work for LockBox with attribute
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY set.

The functional uni-test for the commit is available at:
https://github.com/hwu25/edk2/tree/lockbox_unitest

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Include/Library/LockBoxLib.h |  7 ++-
 MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c  |  7 ++-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c |  5 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c |  5 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 57 ++--
 5 files changed, 72 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Include/Library/LockBoxLib.h 
b/MdeModulePkg/Include/Library/LockBoxLib.h
index 5921731419..addce3bd4a 100644
--- a/MdeModulePkg/Include/Library/LockBoxLib.h
+++ b/MdeModulePkg/Include/Library/LockBoxLib.h
@@ -2,7 +2,7 @@
   This library is only intended to be used by DXE modules that need save
   confidential information to LockBox and get it by PEI modules in S3 phase.
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -85,7 +85,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+no enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by 
implementaion.
diff --git a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c 
b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
index c40dfea398..0adda1e2a9 100644
--- a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
+++ b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -76,7 +76,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+no enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by 
implementaion.
diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
index 0428decbac..5ee563b71f 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
@@ -300,7 +300,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with at

[edk2] [PATCH v1 07/12] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox

[Hao Wu]

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

For the NvmExpressPei driver, this commit will update the driver to
consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to
perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.

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 |   8 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h   |  16 +++
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c   |  20 
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c | 106 
 4 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
index 0666e5892b..22b703e971 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
@@ -40,6 +40,7 @@
   NvmExpressPeiHci.h
   NvmExpressPeiPassThru.c
   NvmExpressPeiPassThru.h
+  NvmExpressPeiS3.c
   NvmExpressPeiStorageSecurity.c
   NvmExpressPeiStorageSecurity.h
 
@@ -54,6 +55,7 @@
   BaseMemoryLib
   IoLib
   TimerLib
+  LockBoxLib
   PeimEntryPoint
 
 [Ppis]
@@ -64,9 +66,13 @@
   gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
   gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
 
+[Guids]
+  gS3StorageDeviceInitListGuid   ## SOMETIMES_CONSUMES ## 
UNDEFINED
+
 [Depex]
   gEfiPeiMemoryDiscoveredPpiGuid AND
-  gEdkiiPeiNvmExpressHostControllerPpiGuid
+  gEdkiiPeiNvmExpressHostControllerPpiGuid AND
+  gEfiPeiMasterBootModePpiGuid
 
 [UserExtensions.TianoCore."ExtraFiles"]
   NvmExpressPeiExtra.uni
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 7047c4f3ff..6f01413e6d 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -332,4 +332,20 @@ NvmeBuildDevicePath (
   OUT EFI_DEVICE_PATH_PROTOCOL**DevicePath
   );
 
+/**
+  Determine if a specific NVM Express controller can be skipped for S3 phase.
+
+  @param[in]  HcDevicePath  Device path of the controller.
+  @param[in]  HcDevicePathLengthLength of the device path specified by
+HcDevicePath.
+
+  @retvalThe number of ports that need to be enumerated.
+
+**/
+BOOLEAN
+NvmeS3SkipThisController (
+  IN  EFI_DEVICE_PATH_PROTOCOL*HcDevicePath,
+  IN  UINTN   HcDevicePathLength
+  );
+
 #endif
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
index 96622e6fd5..43b2dfc3e7 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
@@ -213,6 +213,7 @@ NvmExpressPeimEntry (
   )
 {
   EFI_STATUS   Status;
+  EFI_BOOT_MODEBootMode;
   EDKII_NVM_EXPRESS_HOST_CONTROLLER_PPI*NvmeHcPpi;
   UINT8Controller;
   UINTNMmioBase;
@@ -224,6 +225,15 @@ NvmExpressPeimEntry (
   DEBUG ((DEBUG_INFO, "%a: Enters.\n", __FUNCTION__));
 
   //
+  // Get the current boot mode.
+  //
+  Status = PeiServicesGetBootMode (&BootMode);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Fail to get the current boot mode.\n", 
__FUNCTION__));
+return Status;
+  }
+
+  //
   // Locate the NVME host controller PPI
   //
   Status = PeiServicesLocatePpi (
@@ -279,6 +289,16 @@ NvmExpressPeimEntry (
   continue;
 }
 
+if ((BootMode == BOOT_ON_S3_RESUME) &&
+(NvmeS3SkipThisController (DevicePath, DevicePathLength))) {
+  DEBUG ((
+DEBUG_ERROR, "%a: Controller %d is skipped during S3.\n",
+__FUNCTION__, Controller
+));
+  Controller++;
+  continue;
+}
+
 //
 // Memory allocation for controller private data
 //
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c
new file mode 100644
index 00..afcf5f6c0a
--- /dev/null
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c
@@ -0,0 +1,106 @@
+/** @file
+  The NvmExpressPei driver is used to manage non-volatile memory subsystem
+  which follows NVM Express specification at 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 WARRANTIE

Re: [edk2] Network Stack Budgeting

[Tomas Pilar (tpilar)]

On 29/01/2019 13:42, Laszlo Ersek wrote:
> On 01/29/19 11:54, Tomas Pilar (tpilar) wrote:
>>> Why TFTP client just pull one packet per second? I think it’s not
>>> correct and it could use the poll() function to accelerate the
>>> receive. Why you trying to solve a TFTP layer problem in SNP layer?
>>> It breaks the design principle of network layer model.
>> Yes, I appreciate the principle. However, in practice we don't get to
>> sell adapters that do not PXE boot and it's pointless to argue with
>> customers that they have a rubbish TFTP client implementation. So we
>> put in workarounds into the driver.
> Actually, I think this is the core principle behind the UEFI forum, and
> the UEFI spec. You shouldn't have to implement bug compat hacks. The era
> when an add-on card would work on some platform's BIOS but not on
> another's should be left behind. You have a spec to point at, and the
> platform in question was likely certified against that spec in some form
> (possibly self-certified).
>
> Sp I think it would be reasonable to contact the platform vendor, and to
> direct your own customers to that ticket too. If you have a
> representative on the USWG, it might make sense to raise the issue there
> as well, especially if the issue is wide-spread and affects multiple
> platform vendors. The UEFI spec targets practical, common use cases, and
> this looks like one.
>
> (When a RH customer or partner reports e.g. a RHEL kernel issue to us,
> and we determine it is a problem in the firmware, we absolutely talk to
> the platform vendor, and sometimes to standards bodies too. We also
> advise customers on the applications that they run on RHEL, if they ask
> and/or care to listen. Plus, some high-profile applications and RHEL are
> explicitly certified against each other.)
>
> ... I don't mean to intrude of course; I'm sorry if I came through like
> that.
Thanks, this is some good food for thought. I certainly appreciate the progress 
we've made since the old EFI days.

Tom

>
> Thanks
> Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-staging 01/19] IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported architectures

[Ryszard Knop]

One thing of note here: We're primarily using MSVC for IA32/X64 builds,
and that's the only thing we "officially" support. I'll try to build
and test GCC binaries once in a while as well, but things might break
once now and then. Our team also doesn't have any ARM hardware to test
this on, so I'd appreciate any reports if it breaks :)

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/IntelOpenSourceUndiPkg.dsc | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> index 21b1fb27984e..ca440bde2cb4 100644
> --- a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> +++ b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> @@ -29,7 +29,7 @@
>PLATFORM_VERSION   = 0.1
>DSC_SPECIFICATION  = 0x00010005
>OUTPUT_DIRECTORY   = Build/IntelUndiPkg
> -  SUPPORTED_ARCHITECTURES= IA32|IPF|X64
> +  SUPPORTED_ARCHITECTURES= IA32|IPF|X64|ARM|AARCH64
>BUILD_TARGETS  = DEBUG|RELEASE|DEV
>SKUID_IDENTIFIER   = DEFAULT
>  
> @@ -62,6 +62,17 @@
>SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynch
> ronizationLib.inf
>DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib
> /BaseDebugPrintErrorLevelLib.inf
>  
> +[LibraryClasses.ARM, LibraryClasses.AARCH64]
> +  #
> +  # It is not possible to prevent the ARM compiler from inserting
> calls to
> +  # intrinsic functions. This library provides the instrinsic
> functions such
> +  # a compiler may generate calls to.
> +  #
> +  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.in
> f
> +
> +  # Add support for GCC stack protector
> +  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> +
>  
> 
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this
> Platform

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-staging 00/19] IntelUndiPkg/GigUndiDxe: build fixes for AARCH64/ARM/GCC

[Ryszard Knop]

+Team

On Tue, 2019-01-29 at 14:13 +0100, Ryszard Knop wrote:
> Hi Ard,
> 
> I've finally got some time to review and merge all of this. A bit
> problematic thing is that we internally have a separate tree that we
> need to merge those commits into, then generate the open source tree
> and related commits from that. This will result in somewhat broken
> history, so sorry about that in advance - we're still figuring out
> the
> proper way to handle multiple source trees on our end without messing
> it up. I'll push these changes to edk2-staging once we've got it all
> ready.
> 
> On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> > This series fixes the GigUndiDxe in the edk2-staging/Intel_UNDI
> > branch
> > at github.com/tianocore so it can be built with GCC on Linux for
> > ARM
> > and AARCH64 (as well as X64)
> > 
> > Ard Biesheuvel (19):
> >   IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported
> > architectures
> >   IntelUndiPkg: remove EOF markers
> >   IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in
> > filenames
> >   IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path
> > separators
> >   IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type
> > definition
> >   IntelUndiPkg/GigUndiDxe: use intermediate UINTN casts for
> > pointers
> >   IntelUndiPkg/GigUndiDxe: create GCC alternatives for MSFT build
> > options
> >   IntelUndiPkg/GigUndiDxe: add missing VOID** cast
> >   IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
> >   IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
> >   IntelUndiPkg/GigUndiDxe: fix incorrect use of CPP token pasting
> >   IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct
> > pointer
> > type
> >   IntelUndiPkg/GigUndiDxe: don't take address of cast expression
> >   IntelUndiPkg/GigUndiDxe: redefine UNREFERENCED_nPARAMETER macros
> > for
> > GCC
> >   IntelUndiPkg/GigUndiDxe: remove forward declaration of non-
> > existent
> > function
> >   IntelUndiPkg/GigUndiDxe: fix incorrect indentation
> >   IntelUndiPkg/GigUndiDxe: move MSFT warning overrides to INF file
> >   IntelUndiPkg/GigUndiDxe: add missing EFIAPI modifiers
> >   IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables
> > 
> >  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  |  6 ++-
> >  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/Brand.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/ComponentName.c   |  5 ++-
> >  IntelUndiPkg/GigUndiDxe/ComponentName.h   |  2 +-
> >  IntelUndiPkg/GigUndiDxe/Decode.c  |  5 +--
> >  IntelUndiPkg/GigUndiDxe/Decode.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   |  9 ++---
> >  IntelUndiPkg/GigUndiDxe/Dma.c | 11 +++---
> >  IntelUndiPkg/GigUndiDxe/Dma.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c |  6 ++-
> >  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 12 +++---
> >  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   |  1 -
> >  IntelUndiPkg/GigUndiDxe/DriverHealth.c|  5 ++-
> >  IntelUndiPkg/GigUndiDxe/EepromConfig.c|  1 -
> >  IntelUndiPkg/GigUndiDxe/EepromConfig.h|  3 +-
> >  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 39 +--
> > 
> >  IntelUndiPkg/GigUndiDxe/Hii.c | 11 +++---
> >  IntelUndiPkg/GigUndiDxe/Hii.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  |  3 --
> >  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/Init.c| 11 +++---
> >  IntelUndiPkg/GigUndiDxe/Init.h|  1 -
> >  IntelUndiPkg/GigUndiDxe/Inventory.vfr |  1 -
> >  IntelUndiPkg/GigUndiDxe/NVDataStruc.h |  7 ++--
> >  IntelUndiPkg/GigUndiDxe/StartStop.c   |  5 ++-
> >  IntelUndiPkg/GigUndiDxe/StartStop.h   |  7 ++--
> >  IntelUndiPkg/GigUndiDxe/Version.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c}  | 37 ---
> > --
> > -
> >  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h}  |  5 +--
> >  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_82571.c |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_82571.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_82575.c |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_82575.h |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_api.c   |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_api.h   |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 10 -
> >  IntelUndiPkg/GigUndiDxe/e1000_hw.h|  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_i210.c  |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_i210.h  |  1 -
> >  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 18 ---

Re: [edk2] [PATCH edk2-platforms 19/27] Silicon/NXP: Add i.MX6 ACPI tables

[Ard Biesheuvel]

On Tue, 8 Jan 2019 at 22:43, Chris Co  wrote:
>
> Hi Ard,
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Monday, December 17, 2018 3:14 AM
> > To: Chris Co 
> > Cc: edk2-devel@lists.01.org; Leif Lindholm ; 
> > Michael
> > D Kinney 
> > Subject: Re: [PATCH edk2-platforms 19/27] Silicon/NXP: Add i.MX6 ACPI tables
> >
> > On Fri, 21 Sep 2018 at 10:26, Chris Co 
> > wrote:
> > >
> > > +// PL310 L2 Cache Controller Resource Group
> > > +#define CSRT_PL310_MINIMUM_VERSION   1
> > > +#define CSRT_PL310_VERSION_2 2
> > > +#define CSRT_PL310_RAW_PROTOCOL  0
> > > +#define CSRT_PL310_SMC_PROTOCOL  1
> > > +
> > > +// We use PSCI_CPU_ON to turn on the L2 cache, with special value
> > > +// 0x0010 for the Core ID. PSCI sees this core ID and knows
> > > +// this is an L2 cache operation, then looks at R2 for the
> > > +// operation to perform.
> > > +#define PSCI_FID_CPU_ON0x8403
> > > +#define L2CACHE_SMC_R1 0x0010
> > > +#define L2CACHE_OP_ENABLE  1
> > > +#define L2CACHE_OP_DISABLE 2
> > > +#define L2CACHE_OP_ENABLE_WRITEBACK3
> > > +#define L2CACHE_OP_DISABLE_WRITEBACK   4
> > > +#define L2CACHE_OP_ENABLE_WFLZ 5
> > > +
> >
> > Who defined this protocol? Where is the opposite side implemented?
> >
> > Overloading architected PSCI calls to manage platform specific pieces
> > is really a no-go.
> >
>
> Since my initial patch set submission, we have updated this code to use the 
> standardized protocol instead of overloading PSCI_CPU_ON. It will be in the 
> V2 patch set.
>
> // PL310 L2 Cache Controller Resource Group
> #define CSRT_PL310_MINIMUM_VERSION   1
> #define CSRT_PL310_VERSION_2 2
> #define CSRT_PL310_RAW_PROTOCOL  0
> #define CSRT_PL310_SMC_PROTOCOL  1
>
> #define SMC_CALL_VAL(owner, funcid) \
> (0x8000 | (((owner) & 0x3F) << 24) | ((funcid) & 0x))
>
> #define SMC_OWNER_SIP   2
> #define IMX_SMC_PL310_ENABLESMC_CALL_VAL(SMC_OWNER_SIP, 1)
> #define IMX_SMC_PL310_DISABLE   SMC_CALL_VAL(SMC_OWNER_SIP, 2)
> #define IMX_SMC_PL310_ENABLE_WRITEBACK  SMC_CALL_VAL(SMC_OWNER_SIP, 3)
> #define IMX_SMC_PL310_DISABLE_WRITEBACK SMC_CALL_VAL(SMC_OWNER_SIP, 4)
> #define IMX_SMC_PL310_ENABLE_WFLZ   SMC_CALL_VAL(SMC_OWNER_SIP, 5)
>

Excellent!

> > > +// Debug Port 2 table
> > > +EFI_ACPI_5_0_DEBUG_PORT_2_TABLE Dbg2 = {
> >
> > STATIC
> >
> > > +  {
> > > +// Header
> > > +{
> > > +  EFI_ACPI_5_0_DEBUG_PORT_2_TABLE_SIGNATURE, // Signature
> > "DBG2"
> > > +  sizeof (EFI_ACPI_5_0_DEBUG_PORT_2_TABLE),  // Length
> > > +  EFI_ACPI_DEBUG_PORT_2_TABLE_REVISION,  // Revision
> > > +  EFI_ACPI_5_0_UNDEFINED,// Checksum - 
> > > updated at
> > runtime
> > > +  EFI_ACPI_OEM_ID,   // OEM ID[6]
> > > +  EFI_ACPI_OEM_TABLE_ID, // OEM Table ID
> > > +  EFI_ACPI_OEM_REVISION, // OEM Revision
> > > +  EFI_ACPI_CREATOR_ID,   // Creator ID
> > > +  EFI_ACPI_CREATOR_REVISION  // Creator Revision
> > > +},
> > > +sizeof (EFI_ACPI_5_0_DEBUG_PORT_2_TABLE_HEADER), //
> > OffsetDbgDeviceinfo
> > > +1,   // 
> > > NumberDbgDeviceInfo
> > > +  },
> > > +  {
> > > +// Uart
> > > +{
> > > +  // DeviceInfo
> > > +  EFI_ACPI_RESERVED_BYTE, // Revision
> > > +  sizeof (DEBUG_DEVICE_INFO_UART),// Length
> > > +  1,  // 
> > > NumberofGenericAddressRegisters
> > > +  UART_NAME_SPACE_STRING_LENGTH,  //
> > NameSpaceStringLength
> > > +  OFFSET_OF (DEBUG_DEVICE_INFO_UART, NameSpaceString),//
> > NameSpaceStringOffset
> > > +  0,  // 
> > > OemDataLength
> > > +  EFI_ACPI_RESERVED_WORD, // 
> > > OemDataOffset
> > > +  DBG2_TYPE_SERIAL,   // PortType
> > > +  DBG_PORT_SUBTYPE_IMX6,  // 
> > > PortSubtype 000Ch
> >
> > Is this subtype defined in a published version of the SPCR/DBG2 specs?
> >
>
> Just checked and the IMX6 subtype is not present in the latest DBG2 spec. 
> I'll work on getting it added. Does the subtype need to be in the published 
> DBG2 spec before the patch can be accepted upstream?
>

Preferably, yes.

> Note: The definition is present in our WDK headers but I'm guessing that is 
> not sufficient...
>
> //
> // ACPI debug device port types.  The bottom 15 bits of these values should
> // match the BCDE_DEBUGGER_TYPE values that are defined in the header
> // minkernel\published\base\bcdtypes.w
> //
>
> #define DEBUG_

Re: [edk2] [PATCH edk2-staging 02/19] IntelUndiPkg: remove EOF markers

[Ryszard Knop]

This seems to be an issue within our open source tree generation script
which appends some nasty unexpected characters... MSVC didn't ever
complain about these. Fixed this, next commits should be clean.

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Remove the Ctrl-Z markers at the end of each file: these break the
> GCC build on Linux.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/Brand.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/ComponentName.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/Decode.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/Decode.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/Dma.c | 1 -
>  IntelUndiPkg/GigUndiDxe/Dma.h | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.h | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c| 1 -
>  IntelUndiPkg/GigUndiDxe/E1000.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/E1000.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/E1000_osdep.c | 1 -
>  IntelUndiPkg/GigUndiDxe/E1000_osdep.h | 1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.c| 1 -
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h| 1 -
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 1 -
>  IntelUndiPkg/GigUndiDxe/Hii.c | 1 -
>  IntelUndiPkg/GigUndiDxe/Hii.h | 1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/HiiInternalLib.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/Init.c| 1 -
>  IntelUndiPkg/GigUndiDxe/Init.h| 1 -
>  IntelUndiPkg/GigUndiDxe/Inventory.vfr | 1 -
>  IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 1 -
>  IntelUndiPkg/GigUndiDxe/StartStop.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/StartStop.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/Version.h | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.c | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82571.h | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.c | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_82575.h | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_api.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_defines.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_hw.h| 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_i210.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_mac.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.c| 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_manage.h| 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_nvm.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_nvm.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_phy.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_phy.h   | 1 -
>  IntelUndiPkg/GigUndiDxe/e1000_regs.h  | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wol.c | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wol.h | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wol_1G.c  | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolfamily.c   | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolimpl.c | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolimpl.h | 1 -
>  IntelUndiPkg/GigUndiDxe/wol/wolinfo.c | 1 -
>  IntelUndiPkg/I40eUndiDxe/AdapterInformation.c | 1 -
>  IntelUndiPkg/I40eUndiDxe/AdapterInformation.h | 1 -
>  IntelUndiPkg/I40eUndiDxe/Brand.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/ComponentName.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/ComponentName.h  | 1 -
>  IntelUndiPkg/I40eUndiDxe/Decode.c | 1 -
>  IntelUndiPkg/I40eUndiDxe/Decode.h | 1 -
>  IntelUndiPkg/I40eUndiDxe/DeviceSupport.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/DeviceSupport.h  | 1 -
>  IntelUndiPkg/I40eUndiDxe/Dma.c| 1 -
>  IntelUndiPkg/I40eUndiDxe/Dma.h| 1 -
>  IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.c  | 1 -
>  IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.h  | 1 -
>  IntelUndiPkg/I40eUndiDxe/DriverHealth.c   | 1 -
>  IntelUndiPkg/I40eUndiDxe/DriverHealthCommon.h | 1 -
>  IntelUndiPkg/I40eUndiDxe/EepromConfig.c   | 1 -
>  IntelUndiPkg/I40eUndiDxe/EepromConfig.h   | 1 -
>  IntelUndiPkg/I40eUndiDxe/Hii.c| 1 -
>  Intel

Re: [edk2] [PATCH v3 3/4] MdeModulePkg/CapsuleApp: Add functions to support Capsule-on-Disk

[Wang, Jian J]

Reviewed-by: Jian J Wang 


> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
> 
> Subject: [PATCH v3 3/4] MdeModulePkg/CapsuleApp: Add functions to support
> Capsule-on-Disk
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
> 
> This file provide some basic function to support Capsule-on-Disk.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Zhang Chao B 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen 
> ---
>  .../Application/CapsuleApp/CapsuleOnDisk.c | 806
> +
>  1 file changed, 806 insertions(+)
>  create mode 100644 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> 
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> new file mode 100644
> index 00..16ce9519b2
> --- /dev/null
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -0,0 +1,806 @@
> +/** @file
> +  Process Capsule On Disk.
> +
> +  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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_GUID mCapsuleOnDiskBootOptionGuid = { 0x4CC29BB7, 0x2413, 0x40A2,
> { 0xB0, 0x6D, 0x25, 0x3E, 0x37, 0x10, 0xF5, 0x32 } };
> +
> +/**
> +  Get shell protocol.
> +
> +  @return Pointer to shell protocol.
> +
> +**/
> +EFI_SHELL_PROTOCOL *
> +GetShellProtocol (
> +  VOID
> +  );
> +
> +/**
> +  Get file name from file path.
> +
> +  @param  FilePathFile path.
> +
> +  @return Pointer to file name.
> +
> +**/
> +CHAR16 *
> +GetFileNameFromPath (
> +  CHAR16*FilePath
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_SHELL_PROTOCOL*ShellProtocol;
> +  SHELL_FILE_HANDLE Handle;
> +  EFI_FILE_INFO *FileInfo;
> +
> +  ShellProtocol = GetShellProtocol ();
> +  if (ShellProtocol == NULL) {
> +return NULL;
> +  }
> +
> +  //
> +  // Open file by FileName.
> +  //
> +  Status = ShellProtocol->OpenFileByName (
> +FilePath,
> +&Handle,
> +EFI_FILE_MODE_READ
> +);
> +  if (EFI_ERROR (Status)) {
> +return NULL;
> +  }
> +
> +  //
> +  // Get file name from EFI_FILE_INFO.
> +  //
> +  FileInfo = ShellProtocol->GetFileInfo (Handle);
> +  ShellProtocol->CloseFile (Handle);
> +  if (FileInfo == NULL) {
> +return NULL;
> +  }
> +
> +  return FileInfo->FileName;
> +}
> +
> +/**
> +  Check if the device path is EFI system Partition.
> +
> +  @param  DevicePathThe ESP device path.
> +
> +  @retval TRUEDevicePath is a device path for ESP.
> +  @retval FALSE   DevicePath is not a device path for ESP.
> +
> +**/
> +BOOLEAN
> +IsEfiSysPartitionDevicePath (
> +  EFI_DEVICE_PATH_PROTOCOL   *DevicePath
> +  )
> +{
> +  EFI_STATUS Status;
> +  EFI_DEVICE_PATH_PROTOCOL   *TempDevicePath;
> +  HARDDRIVE_DEVICE_PATH  *Hd;
> +  EFI_HANDLE Handle;
> +
> +  //
> +  // Check if the device path contains GPT node
> +  //
> +  TempDevicePath = DevicePath;
> +
> +  while (!IsDevicePathEnd (TempDevicePath)) {
> +if ((DevicePathType (TempDevicePath) == MEDIA_DEVICE_PATH) &&
> +  (DevicePathSubType (TempDevicePath) == MEDIA_HARDDRIVE_DP)) {
> +  Hd = (HARDDRIVE_DEVICE_PATH *)TempDevicePath;
> +  if (Hd->MBRType == MBR_TYPE_EFI_PARTITION_TABLE_HEADER) {
> +break;
> +  }
> +}
> +TempDevicePath = NextDevicePathNode (TempDevicePath);
> +  }
> +
> +  if (!IsDevicePathEnd (TempDevicePath)) {
> +//
> +// Search for EFI system partition protocol on full device path in Boot 
> Option
> +//
> +Status = gBS->LocateDevicePath (&gEfiPartTypeSystemPartGuid,
> &DevicePath, &Handle);
> +return EFI_ERROR (Status) ? FALSE : TRUE;
> +  } else {
> +return FALSE;
> +  }
> +}
> +
> +/**
> +  Dump all EFI System Partition.
> +
> +**/
> +VOID
> +DumpAllEfiSysPartition (
> +  VOID
> +  )
> +{
> +  EFI_HANDLE *SimpleFileSystemHandles;
> +  UINTN  NumberSimpleFileSystemHandles;
> +  UINTN  Index;
> +  EFI_DEVICE_PATH_PROTOCOL   *DevicePath;
> +  UINTN  

Re: [edk2] [PATCH v3 2/4] MdeModulePkg/CapsuleApp: Add a function used to get next DevicePath

[Wang, Jian J]

Reviewed-by: Jian J Wang 


> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
> 
> Subject: [PATCH v3 2/4] MdeModulePkg/CapsuleApp: Add a function used to get
> next DevicePath
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
> 
> Add a new function to support Capsule-on-Disk feature.
> This function is used to get next full DevicePath from a load option.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Zhang Chao B 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen 
> ---
>  MdeModulePkg/Include/Library/UefiBootManagerLib.h | 21
> +++-
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c  | 24
> ++-
>  2 files changed, 43 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> index bfc0cb86f8..64347ff160 100644
> --- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> +++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -1,7 +1,7 @@
>  /** @file
>Provide Boot Manager related library APIs.
> 
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-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
> @@ -445,6 +445,25 @@ EfiBootManagerGetBootManagerMenu (
>EFI_BOOT_MANAGER_LOAD_OPTION *BootOption
>);
> 
> +/**
> +  Get the next possible full path pointing to the load option.
> +  The routine doesn't guarantee the returned full path points to an existing
> +  file, and it also doesn't guarantee the existing file is a valid load 
> option.
> +  BmGetNextLoadOptionBuffer() guarantees.
> +
> +  @param FilePath  The device path pointing to a load option.
> +   It could be a short-form device path.
> +  @param FullPath  The full path returned by the routine in last call.
> +   Set to NULL in first call.
> +
> +  @return The next possible full path pointing to the load option.
> +  Caller is responsible to free the memory.
> +**/
> +EFI_DEVICE_PATH_PROTOCOL *
> +EfiBootManagerGetNextFullDevicePath (
> +  IN  EFI_DEVICE_PATH_PROTOCOL  *FilePath,
> +  IN  EFI_DEVICE_PATH_PROTOCOL  *FullPath
> +  );
> 
>  /**
>Get the load option by its device path.
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 6a23477eb8..684d7b8b1b 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1,7 +1,7 @@
>  /** @file
>Library functions which relates with booting.
> 
> -Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  (C) Copyright 2015-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
> @@ -2461,3 +2461,25 @@ EfiBootManagerGetBootManagerMenu (
>}
>  }
> 
> +/**
> +  Get the next possible full path pointing to the load option.
> +  The routine doesn't guarantee the returned full path points to an existing
> +  file, and it also doesn't guarantee the existing file is a valid load 
> option.
> +  BmGetNextLoadOptionBuffer() guarantees.
> +
> +  @param FilePath  The device path pointing to a load option.
> +   It could be a short-form device path.
> +  @param FullPath  The full path returned by the routine in last call.
> +   Set to NULL in first call.
> +
> +  @return The next possible full path pointing to the load option.
> +  Caller is responsible to free the memory.
> +**/
> +EFI_DEVICE_PATH_PROTOCOL *
> +EfiBootManagerGetNextFullDevicePath (
> +  IN  EFI_DEVICE_PATH_PROTOCOL  *FilePath,
> +  IN  EFI_DEVICE_PATH_PROTOCOL  *FullPath
> +  )
> +{
> +  return BmGetNextLoadOptionDevicePath(FilePath, FullPath);
> +}
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Proposal to split Pkgs

[Leif Lindholm]

Hi Ray,

First of all, thank you for restarting this discussion, and putting
the effort in for a POC.

On Tue, Jan 29, 2019 at 05:59:35AM +, Ni, Ray wrote:
> Hello,
> I'd like to propose to split today's BIG packages in following ways:
> 
> ==Overview =
> 
> 1. Separate Industry standard definitions from UEFI and PI interfaces.
> 2. Separate UEFI and PI interfaces from implementations.
> a. Separate UEFI and PI interfaces to different packages
> b. Separate PI PEI, DXE and MM phase interfaces to different packages
> 3. Separate different features into feature packages.
> Feature interface may be in the feature package to provide minimal
> common interface packages.
> 
> The POC code is in https://github.com/jyao1/edk2/tree/ReOrg.
> It basically split the EDKII common code to three directories:
> Core/, Device/, and Feature/.

I'm not sure I like the 'Device' name, but that's not that important
at this stage - I like that this is split up the way it is.

I also think a lot of things currently under Feture/misc could be
broken out into additional subdirectories under Feature/.

> The code is in very early POC phase and only code in Core/ directory
> can pass the build.
> I would like to gather feedbacks through this RFC to see whether
> this splitting direction makes sense.
> Is there any other better ways of splitting?
> Or perhaps do not split in such a small granularity?

I think this would be my only negative(ish) feedback on the POC.

While it has the benefit of modules requiring to specify more
precisely which functionality they are pulling in...
...it means that they now need to list *everything*.

And with the mechanism by which I have seen Intel engineers make use
of PACKAGES_PATH in the past*, we end up with a bazillion packages
that need to be added individually to this variable for each build.

* (arguably how it was designed to be used - just not how I am
  interested in using it)

It also means that we need *tons* of dummy .dsc files in order to run
through simple build tests.

My preference would be to push the packages back up to the top-level.
The split still makes sense, and allocating maintainers to sub-parts
can happen without a full-out redesign of the Maintainers.txt format.
(Which I will try to resurrect with a proposal over the next few weeks
anyway.)

> Or perhaps Mike's work to move lib-c content to edk2-libc repo,
> to move real platform code to edk2-platform repo is enough for
> now?

I think we need this further restructuring, and renaming. Not just for
splitting up maintainership duties (which as I mentioned in email to
Laszlo, we will still need to do with this change). But to make the
codebase more approachable.

> ==More explanations =
> 
> There are 9 packages inside Core/ directory:
> 1. BasePkg
> Contains industry standard definitions (exclude UEFI and PI) and base
> libraries that non-UEFI and non-PI development can depend on.
> UEFI or PI development can also depend on this package.
> 2. UefiPkg
> Contains UEFI interfaces and libraries that UEFI driver-model driver
> development can depend on.
> 3. PiPeiPkg
> Contains PI interfaces and libraries for PEI phase that PEI module
> development can depend on.
> 4. PiDxePkg
> Contains PI interfaces and libraries for DXE phase that DXE module
> development can depend on.

Really happy with the above split.

> 5. PiMmPkg
> Contains PI interfaces and libraries for MM phase that MM/SMM
> module development can depend on.

How would/should this work relative to StandaloneMmPkg?

> 6. MdeModulePkg (TianoPkg? Name is still TBD)

Yes, this needs to be renamed. I don't object to the Tiano naming.

> Contains Tiano implementation specific interfaces and libraries.
> Developing modules for pure UEFI or PI should not depend on this package.
> 7. PeiFoundationPkg
> Contains the PEI foundation modules (PeiCore and DxeIpl) and supported
> libraries.
> 8. DxeFoundationPkg
> Contains the DXE foundation modules (DxeCore and RuntimeDxe) and
> supported libraries.
> 9. SmmFoundationPkg
> Contains the SMM foundation modules (SmmCore, SmmIpl and
> SmmCommunicationBuffer) and supported libraries.

So as a feedback on the whole, this would somewhat help with
addressing the confusion caused by PI defining interfaces named EFI_*
(which we really ought to address on the spec level at some point).

> These packages are positioned in different layers. The package in higher
> layer depends on all packages that are in lower layers.
> Layer 0: BasePkg.
> Layer 1: UefiPkg.

This looks a bit weird though - surely PI components should not have
dependencies on UEFI components? I presume this is what Laszlo
referred to with regards to Base.h and the thread from earlier this
month.

> Layer 2: PiPeiPkg 
> Layer 3: PiDxePkg
> Layer 4: PiMmPkg
> Layer 5: MdeModulePkg (TianoPkg?)
> 
> All other modules are put to small packages under Device/ or Feature/.
> 
> == Benefit of 

Re: [edk2] [PATCH edk2-staging 01/19] IntelOpenSourceUndiPkg.dsc: add AARCH64 and ARM to supported architectures

[Ard Biesheuvel]

On Tue, 29 Jan 2019 at 14:54, Ryszard Knop  wrote:
>
> One thing of note here: We're primarily using MSVC for IA32/X64 builds,
> and that's the only thing we "officially" support. I'll try to build
> and test GCC binaries once in a while as well, but things might break
> once now and then. Our team also doesn't have any ARM hardware to test
> this on, so I'd appreciate any reports if it breaks :)
>
> Reviewed-by: Ryszard Knop 
>

Thanks!

Let me know once these changes have hit the upstream. I'll add GCC
builds for IA32, X64, ARM and AARCH64 to our CI setup.

> On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  IntelUndiPkg/IntelOpenSourceUndiPkg.dsc | 13 -
> >  1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> > b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> > index 21b1fb27984e..ca440bde2cb4 100644
> > --- a/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> > +++ b/IntelUndiPkg/IntelOpenSourceUndiPkg.dsc
> > @@ -29,7 +29,7 @@
> >PLATFORM_VERSION   = 0.1
> >DSC_SPECIFICATION  = 0x00010005
> >OUTPUT_DIRECTORY   = Build/IntelUndiPkg
> > -  SUPPORTED_ARCHITECTURES= IA32|IPF|X64
> > +  SUPPORTED_ARCHITECTURES= IA32|IPF|X64|ARM|AARCH64
> >BUILD_TARGETS  = DEBUG|RELEASE|DEV
> >SKUID_IDENTIFIER   = DEFAULT
> >
> > @@ -62,6 +62,17 @@
> >SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynch
> > ronizationLib.inf
> >DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib
> > /BaseDebugPrintErrorLevelLib.inf
> >
> > +[LibraryClasses.ARM, LibraryClasses.AARCH64]
> > +  #
> > +  # It is not possible to prevent the ARM compiler from inserting
> > calls to
> > +  # intrinsic functions. This library provides the instrinsic
> > functions such
> > +  # a compiler may generate calls to.
> > +  #
> > +  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.in
> > f
> > +
> > +  # Add support for GCC stack protector
> > +  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> > +
> >  
> > 
> >  #
> >  # Pcd Section - list of all EDK II PCD Entries defined by this
> > Platform
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 4/4] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to support Capsule-on-Disk

[Wang, Jian J]

Reviewed-by: Jian J Wang 


> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Wang, Jian J
> ; Wu, Hao A ; Zhang, Chao B
> 
> Subject: [PATCH v3 4/4] MdeModulePkg/CapsuleApp: Enhance CapsuleApp to
> support Capsule-on-Disk
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
> 
> CapsuleApp is used for trigger capsule update.
> Add -OD option in CapsuleApp to support doing capsule update via storage.
> Add -F and -L options to support dumping information feature.
> Finish unit test for -F and -L options.
> Already verify this feature on Denlow platform, success to update capsule
> via hard disk with -OD option.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Zhang Chao B 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen 
> ---
>  MdeModulePkg/Application/CapsuleApp/CapsuleApp.c   | 155 +-
>  MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf |   8 +
>  MdeModulePkg/Application/CapsuleApp/CapsuleDump.c  | 538
> -
>  3 files changed, 684 insertions(+), 17 deletions(-)
> 
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> index 4d907242f3..258e6995bc 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
> @@ -1,7 +1,7 @@
>  /** @file
>A shell application that triggers capsule update process.
> 
> -  Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 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
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -105,6 +106,44 @@ DumpEsrtData (
>VOID
>);
> 
> +/**
> +  Dump Provisioned Capsule.
> +
> +  @param[in]  DumpCapsuleInfo  The flag to indicate whether to dump the
> capsule inforomation.
> +**/
> +VOID
> +DumpProvisionedCapsule (
> +  IN BOOLEAN  DumpCapsuleInfo
> +  );
> +
> +/**
> +  Dump all EFI System Partition.
> +**/
> +VOID
> +DumpAllEfiSysPartition (
> +  VOID
> +  );
> +
> +/**
> +  Process Capsule On Disk.
> +
> +  @param[in]  CapsuleBufferAn array of pointer to capsule images
> +  @param[in]  FileSize An array of UINTN to capsule images size
> +  @param[in]  OrgFileName  An array of orginal capsule images name
> +  @param[in]  NewFileName  An array of new capsule images name
> +  @param[in]  CapsuleNum   The count of capsule images
> +
> +  @retval EFI_SUCCESS   Capsule on disk success.
> +**/
> +EFI_STATUS
> +ProcessCapsuleOnDisk (
> +  IN VOID  **CapsuleBuffer,
> +  IN UINTN *CapsuleBufferSize,
> +  IN CHAR16**FilePath,
> +  IN CHAR16*Map,
> +  IN UINTN CapsuleNum
> +  );
> +
>  /**
>Read a file.
> 
> @@ -799,19 +838,22 @@ PrintUsage (
>)
>  {
>Print(L"CapsuleApp:  usage\n");
> -  Print(L"  CapsuleApp  [-NR]\n");
> +  Print(L"  CapsuleApp  [-NR] [-OD [FSx]]\n");
>Print(L"  CapsuleApp -S\n");
>Print(L"  CapsuleApp -C\n");
>Print(L"  CapsuleApp -P\n");
>Print(L"  CapsuleApp -E\n");
> +  Print(L"  CapsuleApp -L\n");
> +  Print(L"  CapsuleApp -L INFO\n");
> +  Print(L"  CapsuleApp -F\n");
>Print(L"  CapsuleApp -G  -O \n");
>Print(L"  CapsuleApp -N  -O \n");
>Print(L"  CapsuleApp -D \n");
>Print(L"  CapsuleApp -P GET   -O \n");
>Print(L"Parameter:\n");
> -  Print(L"  -NR: No reset will be triggered for the capsule with\n");
> -  Print(L"   CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without\n");
> -  Print(L"   CAPSULE_FLAGS_INITIATE_RESET.\n");
> +  Print(L"  -NR: No reset will be triggered for the capsule\n");
> +  Print(L"   with CAPSULE_FLAGS_PERSIST_ACROSS_RESET and without
> CAPSULE_FLAGS_INITIATE_RESET.\n");
> +  Print(L"  -OD: Delivery of Capsules via file on Mass Storage device.");
>Print(L"  -S:  Dump capsule report variable (EFI_CAPSULE_REPORT_GUID),\n");
>Print(L"   which is defined in UEFI specification.\n");
>Print(L"  -C:  Clear capsule report variable 
> (EFI_CAPSULE_REPORT_GUID),\n");
> @@ -820,6 +862,8 @@ PrintUsage (
>Print(L"   ImageTypeId and Index (decimal format) to a file if 
> 'GET'\n");
>Print(L"   option is used.\n");
>Print(L"  -E:  Dump UEFI ESRT table info.\n");
> +  Print(L"  -L:  Dump provisioned capsule image information.\n");
> +  Print(L"  -F:  Dump all EFI System Partition.\n");
>Print(L"  -G:  Convert a BMP file to be an UX capsule,\n");
>Print(L"   according to Windows Firmware Update document\n");
>Print(L"  -N:  Append a

Re: [edk2] [PATCH edk2-staging 03/19] IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in filenames

[Ryszard Knop]

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Rename E1000.[ch] and E1000_osdep.[ch] to all lowercase, and replace
> all #include references with lowercase ones as well.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/AdapterInformation.c | 2 +-
>  IntelUndiPkg/GigUndiDxe/ComponentName.c  | 2 +-
>  IntelUndiPkg/GigUndiDxe/Decode.c | 2 +-
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h  | 2 +-
>  IntelUndiPkg/GigUndiDxe/Dma.c| 2 +-
>  IntelUndiPkg/GigUndiDxe/DriverConfiguration.c| 2 +-
>  IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c  | 2 +-
>  IntelUndiPkg/GigUndiDxe/DriverHealth.c   | 2 +-
>  IntelUndiPkg/GigUndiDxe/EepromConfig.h   | 2 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf   | 8 ---
> -
>  IntelUndiPkg/GigUndiDxe/Init.c   | 2 +-
>  IntelUndiPkg/GigUndiDxe/StartStop.c  | 2 +-
>  IntelUndiPkg/GigUndiDxe/StartStop.h  | 2 +-
>  IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c} | 2 +-
>  IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h} | 0
>  IntelUndiPkg/GigUndiDxe/{E1000_osdep.c => e1000_osdep.c} | 2 +-
>  IntelUndiPkg/GigUndiDxe/{E1000_osdep.h => e1000_osdep.h} | 0
>  IntelUndiPkg/GigUndiDxe/wol/wolimpl.h| 2 +-
>  18 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> index b0320b11839b..8918c538e447 100644
> --- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> +++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
> @@ -28,7 +28,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
> ***/
>  #include "Uefi.h"
>  
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  
>  #include "AdapterInformation.h"
> diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> index 1473bfbed0af..70baf00f4a5d 100644
> --- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
> +++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
> @@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE
>  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  #include "ComponentName.h"
>  #include "DeviceSupport.h"
> diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c
> b/IntelUndiPkg/GigUndiDxe/Decode.c
> index 88e8be315bd1..14060db0d050 100644
> --- a/IntelUndiPkg/GigUndiDxe/Decode.c
> +++ b/IntelUndiPkg/GigUndiDxe/Decode.c
> @@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE
>  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
> -#include "E1000.h"
> +#include "e1000.h"
>  #include 
>  
>  /** This routine determines the operational state of the UNDI.  It
> updates the state flags in the
> diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> index f309044d9b9d..e156b587f6a7 100644
> --- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> +++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> @@ -29,7 +29,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  #ifndef DEVICE_SUPPORT_H_
>  #define DEVICE_SUPPORT_H_
>  
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  typedef struct BRAND_STRUCT_S BRAND_STRUCT;
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/Dma.c
> b/IntelUndiPkg/GigUndiDxe/Dma.c
> index 76a3fcf69601..bf94c1e2fd54 100644
> --- a/IntelUndiPkg/GigUndiDxe/Dma.c
> +++ b/IntelUndiPkg/GigUndiDxe/Dma.c
> @@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
>  
> -#include "E1000.h"
> +#include "e1000.h"
>  
>  #include "Dma.h"
>  
> diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> index 118c1b2b9b04..20d40ab672ef 100644
> --- a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> +++ b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
> @@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
> IN ANY WAY OUT OF THE USE
>  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
> -#include "E1000.h"
> +#include "e1000.h"
>  #include "DriverConfiguration.h"
>
>  /* Protocol structure tentative definition */  
> diff --git a/IntelUndiPkg/GigUndiDxe/Drive

Re: [edk2] [PATCH edk2-staging 04/19] IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path separators

[Ryszard Knop]

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Replace backslashes in paths with forward slashes to be compatible
> with
> non-Windows OSes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/Decode.c   |  2 +-
>  IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 14 +++---
>  IntelUndiPkg/GigUndiDxe/e1000_osdep.h  |  4 ++--
>  3 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c
> b/IntelUndiPkg/GigUndiDxe/Decode.c
> index 14060db0d050..9f8a5a8c1c81 100644
> --- a/IntelUndiPkg/GigUndiDxe/Decode.c
> +++ b/IntelUndiPkg/GigUndiDxe/Decode.c
> @@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  
> ***/
>  #include "e1000.h"
> -#include 
> +#include 
>  
>  /** This routine determines the operational state of the UNDI.  It
> updates the state flags in the
> Command Descriptor Block based on information derived from the
> GigAdapter instance data.
> diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> index 0e4462733df6..6c195872c00f 100644
> --- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> +++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf
> @@ -115,13 +115,13 @@ AdapterInformation.c
>  AdapterInformation.h
>  Version.h
>  
> -wol\wol.h
> -wol\wol.c
> -wol\wolimpl.h
> -wol\wolimpl.c
> -wol\wolfamily.c
> -wol\wolinfo.c
> -wol\wol_1G.c
> +wol/wol.h
> +wol/wol.c
> +wol/wolimpl.h
> +wol/wolimpl.c
> +wol/wolfamily.c
> +wol/wolinfo.c
> +wol/wol_1G.c
>  
>  [sources.X64]
>
> diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> index 01c0843a2c9a..4408b409a445 100644
> --- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> +++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h
> @@ -31,8 +31,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
>  
>  #pragma warning(disable : 4244)
>  #pragma warning(disable : 4206)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-staging 05/19] IntelUndiPkg/GigUndiDxe: move BRAND_STRUCT declaration after type definition

[Ryszard Knop]

Hmm, BRAND_STRUCT_S could be simplified into a single struct def -
works on both MSVC and GCC.

Reviewed-by: Ryszard Knop 

On Tue, 2018-11-06 at 18:58 +0100, ard.biesheuvela wrote:
> Move the extern declaration of mBrandingTable[] after the definition
> of
> the type. This solves a build issue with GCC.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  IntelUndiPkg/GigUndiDxe/DeviceSupport.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> index e156b587f6a7..e2b730131f8e 100644
> --- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> +++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
> @@ -33,9 +33,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY OF SUCH DAMAGE.
>  
>  typedef struct BRAND_STRUCT_S BRAND_STRUCT;
>  
> -extern BRAND_STRUCT mBrandingTable[];
> -extern UINTNmBrandingTableSize;
> -
>  /* Defines */
>  #define INVALID_VENDOR_ID 0x
>  #define INVALID_SUBVENDOR_ID  0x
> @@ -53,6 +50,9 @@ struct BRAND_STRUCT_S {
>CHAR16 *BrandString;
>  };
>  
> +extern BRAND_STRUCT mBrandingTable[];
> +extern UINTNmBrandingTableSize;
> +
>  /* Function declarations */
>  
>  /** Returns pointer to current device's branding string (looks for
> best match)

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 edk2-platforms 00/23] Platform/Raspberry: Add Raspberry Pi 3 support

[Pete Batard]

Changes applied to v4:

* Silicon/Broadcom/Include has been moved to Silicon/Broadcom/Bcm283x/Include.
  The [Packages] and [Includes] directives were also updated accordingly.
* Move the GpioLib function declarations into their own separate header.
* Add NOOPT to BUILD_TARGETS.
* Remove the no longer needed '-mcmodel=small' workaround from AcpiTables.

Changes not applied to v4:

* Ensure that all the ACPI tables _CID names, and the rest of the tables, are
  ACPI specs compliant, since we are constrained with regards to their usage
  for Microsoft Windows.


Preamble:

Because of its price point, ease of use and availability, the Raspberry Pi is
undeniably one of the most successful ARM platform in existence today. Its
widespread adoption therefore makes it a perfect fit as an EDK2 platform.

However, up until now, the Raspberry Pi hasn't been supported as a bona fide
platform in our repository. This series of patches remedies that by introducing
the Raspberry Pi 3 Model B and Model B+ as a viable EDK2 platform.

Notes regarding non-OSI content:

* Even though the ARM Trusted Firmware binary blobs are subject to a
  BSD-3-Clause licence, which may be compatible with the EDK2 one, we chose
  to follow the lead of other platforms that provide ATF binaries in non OSI.
  Ultimately, once there is a new dot release of ATF, we plan to remove these
  binaries and point to a dot release build configuartion.
* The Device Tree binaries (and source descriptors) are subject to a GPLv2
  license, as per the ones published by the Raspberry Pi Foundation.
* The Logo source code is under an EDK2 license, but the logo itself, which
  we obtained authorisation to use from the Raspberry Pi Foundation itself
  after detailing our planned usage, is subject to the trademark licensing
  terms put forward by the Foundation.

Additional Notes:

* Detailed instructions on how to build and test the platform firmware are
  included in the Readme.md found at the root of the platform.
* As detailed in the Readme, the resulting platform firmware has been
  successfully used to install and run Linux OSes, such as Ubuntu 18.10, as
  well as Windows 10 1809 (*full* UI version, not IoT).

Regards,

/Pete

Pete Batard (23):
  Silicon/Broadcom/Bcm282x: Add interrupt driver
  Silicon/Broadcom/Bcm283x: Add GpioLib
  Platform/Raspberry/Pi3: Add ACPI tables
  Platform/Raspberry/Pi3: Add reset and memory init libraries
  Platform/Raspberry/Pi3: Add platform library
  Platform/Raspberry/Pi3: Add RTC library
  Platform/Raspberry/Pi3: Add firmware driver
  Platform/Raspberry/Pi3: Add platform config driver
  Platform/Raspberry/Pi3: Add SMBIOS driver
  Platform/Raspberry/Pi3: Add display driver
  Platform/Raspberry/Pi3: Add console driver
  Platform/Raspberry/Pi3: Add NV storage driver
  Platform/Raspberry/Pi3: Add Device Tree driver
  Platform/Raspberry/Pi3: Add base MMC driver
  Platform/Raspberry/Pi3: Add Arasan MMC driver
  Platform/Raspberry/Pi3: Platform/Raspberry/Pi3: Add SD Host driver
  Platform/Raspberry/Pi3: Add platform boot manager and helper libraries
  Platform/Raspberry/Pi3: Add USB host driver
  Platform/Raspberry/Pi3: Add platform
  Platform/Raspberry/Pi3: Add platform readme
  Platform/Raspberry/Pi3 *NON-OSI*: Add ATF binaries
  Platform/Raspberry/Pi3 *NON-OSI*: Add Device Tree binaries
  Platform/Raspberry/Pi3 *NON-OSI*: Add logo driver

 .../Raspberry/Pi3/AcpiTables/AcpiTables.h |   82 +
 .../Raspberry/Pi3/AcpiTables/AcpiTables.inf   |   46 +
 Platform/Raspberry/Pi3/AcpiTables/Csrt.aslc   |  332 +++
 Platform/Raspberry/Pi3/AcpiTables/Dbg2.aslc   |   34 +
 Platform/Raspberry/Pi3/AcpiTables/Dsdt.asl|  511 +
 Platform/Raspberry/Pi3/AcpiTables/Fadt.aslc   |   52 +
 Platform/Raspberry/Pi3/AcpiTables/Gtdt.aslc   |   33 +
 Platform/Raspberry/Pi3/AcpiTables/Madt.aslc   |   62 +
 Platform/Raspberry/Pi3/AcpiTables/Pep.asl |   95 +
 Platform/Raspberry/Pi3/AcpiTables/Pep.c   |   84 +
 Platform/Raspberry/Pi3/AcpiTables/Pep.h   |  126 ++
 Platform/Raspberry/Pi3/AcpiTables/Rhpx.asl|  201 ++
 Platform/Raspberry/Pi3/AcpiTables/Sdhc.asl|  105 +
 Platform/Raspberry/Pi3/AcpiTables/Spcr.asl|   53 +
 Platform/Raspberry/Pi3/AcpiTables/Uart.asl|  158 ++
 Platform/Raspberry/Pi3/DeviceTree/License.txt |  340 +++
 .../Pi3/DeviceTree/bcm2710-rpi-3-b-plus.dtb   |  Bin 0 -> 25617 bytes
 .../Pi3/DeviceTree/bcm2710-rpi-3-b-plus.dts   | 1263 
 .../Pi3/DeviceTree/bcm2710-rpi-3-b.dtb|  Bin 0 -> 25354 bytes
 .../Pi3/DeviceTree/bcm2710-rpi-3-b.dts| 1259 +++
 .../ArasanMmcHostDxe/ArasanMmcHostDxe.c   |  723 +++
 .../ArasanMmcHostDxe/ArasanMmcHostDxe.h   |   50 +
 .../ArasanMmcHostDxe/ArasanMmcHostDxe.inf |   52 +
 .../Pi3/Drivers/ConfigDxe/ConfigDxe.c |  351 
 .../Pi3/Drivers/ConfigDxe/ConfigDxe.inf   |   78 +
 .../Drivers/ConfigDxe/ConfigDxeFormSetGuid.h  |   23 +
 .../Pi3/Drivers/ConfigDxe/ConfigDxeHii.uni|  100 +
 .../Pi3/Drivers/ConfigDxe/ConfigDxeHii.v

[edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 

Reviewed-by: Ard Biesheuvel 
---
 Silicon/Broadcom/Bcm283x/Bcm283x.dec   |  23 ++
 Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c   | 367 

 Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf |  48 +++
 Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h|  72 
 4 files changed, 510 insertions(+)

diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec 
b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
new file mode 100644
index ..d193da4c0e1e
--- /dev/null
+++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
@@ -0,0 +1,23 @@
+## @file
+#
+#  Copyright (c) 2019, Pete Batard 
+#
+#  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.
+#
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = Bcm283xPkg
+  PACKAGE_GUID   = 900C0F44-1152-4FF9-B9C5-933E2918C831
+  PACKAGE_VERSION= 1.0
+
+[Includes]
+  Include
diff --git a/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c 
b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
new file mode 100644
index ..9058aa94ffb9
--- /dev/null
+++ b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
@@ -0,0 +1,367 @@
+/** @file
+ *
+ *  Copyright (c) 2016, Linaro, Ltd. 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 
+#include 
+
+//
+// This currently only implements support for the architected timer interrupts
+// on the per-CPU interrupt controllers.
+//
+#define NUM_IRQS(4)
+
+#ifdef MDE_CPU_AARCH64
+#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_AARCH64_IRQ
+#else
+#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_ARM_IRQ
+#endif
+
+STATIC CONST
+EFI_PHYSICAL_ADDRESS RegBase = FixedPcdGet32 (PcdInterruptBaseAddress);
+
+//
+// Notifications
+//
+STATIC EFI_EVENTmExitBootServicesEvent;
+STATIC HARDWARE_INTERRUPT_HANDLER   mRegisteredInterruptHandlers[NUM_IRQS];
+
+/**
+  Shutdown our hardware
+
+  DXE Core will disable interrupts and turn off the timer and disable 
interrupts
+  after all the event handlers have run.
+
+  @param[in]  Event   The Event that is being processed
+  @param[in]  Context Event Context
+**/
+STATIC
+VOID
+EFIAPI
+ExitBootServicesEvent (
+  IN EFI_EVENT  Event,
+  IN VOID   *Context
+  )
+{
+  // Disable all interrupts
+  MmioWrite32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 0);
+}
+
+/**
+  Enable interrupt source Source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+
+  @retval EFI_SUCCESS   Source interrupt enabled.
+  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+EnableInterruptSource (
+  IN EFI_HARDWARE_INTERRUPT_PROTOCOL*This,
+  IN HARDWARE_INTERRUPT_SOURCE  Source
+  )
+{
+  if (Source >= NUM_IRQS) {
+ASSERT (FALSE);
+return EFI_UNSUPPORTED;
+  }
+
+  MmioOr32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 1 << Source);
+
+  return EFI_SUCCESS;
+}
+
+
+/**
+  Disable interrupt source Source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+
+  @retval EFI_SUCCESS   Source interrupt disabled.
+  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+DisableInterruptSource (
+  IN EFI_HARDWARE_INTERRUPT_PROTOCOL*This,
+  IN HARDWARE_INTERRUPT_SOURCE  Source
+  )
+{
+  if (Source >= NUM_IRQS) {
+ASSERT (FALSE);
+return EFI_UNSUPPORTED;
+  }
+
+  MmioAnd32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, ~(1 << Source));
+
+  return EFI_SUCCESS;
+}
+
+/**
+  Register Handler for the specified interrupt source.
+
+  @param This Instance pointer for this protocol
+  @param Source   Hardware source of the interrupt
+  @param Handler  Callback for interrupt. NULL to unregister
+
+  @retval EFI_SUCCESS Source was updated to support Handler.
+  @retval EFI_DEVICE_ERROR  Hardware could not be programmed

[edk2] [PATCH v4 edk2-platforms 02/23] Silicon/Broadcom/Bcm283x: Add GpioLib

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h | 49 
+++
 Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h  | 33 
 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c  | 89 

 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.inf| 39 +
 4 files changed, 210 insertions(+)

diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
new file mode 100644
index ..5fc43ddaa27b
--- /dev/null
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Gpio.h
@@ -0,0 +1,49 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) Microsoft 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 __BCM2836_GPIO_H__
+#define __BCM2836_GPIO_H__
+
+#define GPIO_BASE_ADDRESS  (BCM2836_SOC_REGISTERS + 0x0020)
+
+#define GPIO_GPFSEL0   (GPIO_BASE_ADDRESS + 0x00)
+#define GPIO_GPFSEL1   (GPIO_BASE_ADDRESS + 0x04)
+#define GPIO_GPFSEL2   (GPIO_BASE_ADDRESS + 0x08)
+#define GPIO_GPFSEL3   (GPIO_BASE_ADDRESS + 0x0C)
+#define GPIO_GPFSEL4   (GPIO_BASE_ADDRESS + 0x10)
+#define GPIO_GPFSEL5   (GPIO_BASE_ADDRESS + 0x14)
+
+#define GPIO_GPCLR0(GPIO_BASE_ADDRESS + 0x28)
+#define GPIO_GPCLR1(GPIO_BASE_ADDRESS + 0x2C)
+
+#define GPIO_GPSET0(GPIO_BASE_ADDRESS + 0x1C)
+#define GPIO_GPSET1(GPIO_BASE_ADDRESS + 0x20)
+
+#define GPIO_FSEL_INPUT0x0
+#define GPIO_FSEL_OUTPUT   0x1
+#define GPIO_FSEL_ALT0 0x4
+#define GPIO_FSEL_ALT1 0x5
+#define GPIO_FSEL_ALT2 0x6
+#define GPIO_FSEL_ALT3 0x7
+#define GPIO_FSEL_ALT4 0x3
+#define GPIO_FSEL_ALT5 0x2
+
+#define GPIO_FSEL_PINS_PER_REGISTER 10
+#define GPIO_FSEL_BITS_PER_PIN  3
+#define GPIO_FSEL_MASK  ((1 << GPIO_FSEL_BITS_PER_PIN) - 1)
+
+#define GPIO_PINS  54
+
+#endif /* __BCM2836_GPIO_H__ */
diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
new file mode 100644
index ..c3e1fc21bf8d
--- /dev/null
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -0,0 +1,33 @@
+/** @file
+ *
+ *  GPIO manipulation.
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *
+ *  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 __GPIO_LIB__
+#define __GPIO_LIB__
+
+#include 
+
+VOID
+GpioPinFuncSet (
+  IN  UINTN Pin,
+  IN  UINTN Function
+  );
+
+UINTN
+GpioPinFuncGet (
+  IN  UINTN Pin
+  );
+
+#endif /* __GPIO_LIB__ */
diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
new file mode 100644
index ..8cf560e4fcc5
--- /dev/null
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -0,0 +1,89 @@
+/** @file
+ *
+ *  GPIO manipulation.
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *
+ *  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 
+
+STATIC
+VOID
+GpioFSELModify (
+  IN  UINTN RegIndex,
+  IN  UINT32 ModifyMask,
+  IN  UINT32 FunctionMask
+  )
+{
+  UINT32 Val;
+  EFI_PHYSICAL_ADDRESS Reg;
+
+  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+
+  ASSERT (Reg <= GPIO_GPFSEL5);
+  ASSERT ((~ModifyMask & FunctionMask) == 0);
+
+  Val = MmioRead32 (Reg);
+  Val &= ~ModifyMask;
+  Val |= FunctionMask;
+  MmioWrite32 (Reg, Val);
+}
+
+VOID
+GpioPinFuncSet (
+  IN  UINTN Pin,
+  IN  UINTN Function
+  )
+{
+  UINTN RegIndex;
+  UINTN SelIndex;
+  UINT32 ModifyMask;
+  UINT32 FunctionMask;
+
+  ASSERT (Pin < GPIO_PINS);
+  ASSERT (Function 

[edk2] [PATCH v4 edk2-platforms 04/23] Platform/Raspberry/Pi3: Add reset and memory init libraries

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.c   | 162 

 Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.inf |  51 
++
 Platform/Raspberry/Pi3/Library/ResetLib/ResetLib.c   | 104 
+
 Platform/Raspberry/Pi3/Library/ResetLib/ResetLib.inf |  46 
++
 4 files changed, 363 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.c 
b/Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
new file mode 100644
index ..903364e08b15
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
@@ -0,0 +1,162 @@
+/** @file
+ *
+ *  Copyright (c) 2017-2018, Andrey Warkentin 
+ *  Copyright (c) 2011-2015, ARM Limited. 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 
+
+extern UINT64 mSystemMemoryEnd;
+
+VOID
+BuildMemoryTypeInformationHob (
+  VOID
+  );
+
+STATIC
+VOID
+InitMmu (
+  IN ARM_MEMORY_REGION_DESCRIPTOR  *MemoryTable
+  )
+{
+  RETURN_STATUS Status;
+
+  //Note: Because we called PeiServicesInstallPeiMemory() before to call 
InitMmu() the MMU Page Table
+  //  resides in DRAM (even at the top of DRAM as it is the first 
permanent memory allocation)
+  Status = ArmConfigureMmu (MemoryTable, NULL, NULL);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "Error: Failed to enable MMU\n"));
+  }
+}
+
+STATIC
+VOID
+AddRuntimeServicesRegion (
+  IN ARM_MEMORY_REGION_DESCRIPTOR *Desc
+)
+{
+  BuildResourceDescriptorHob (
+EFI_RESOURCE_SYSTEM_MEMORY,
+EFI_RESOURCE_ATTRIBUTE_PRESENT |
+EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_TESTED,
+Desc->PhysicalBase,
+Desc->Length
+  );
+
+  BuildMemoryAllocationHob (
+Desc->PhysicalBase,
+Desc->Length,
+EfiRuntimeServicesData
+  );
+}
+
+STATIC
+VOID
+AddReservedMemoryRegion (
+  IN ARM_MEMORY_REGION_DESCRIPTOR *Desc
+  )
+{
+  BuildResourceDescriptorHob (
+EFI_RESOURCE_SYSTEM_MEMORY,
+EFI_RESOURCE_ATTRIBUTE_PRESENT |
+EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_TESTED,
+Desc->PhysicalBase,
+Desc->Length
+  );
+
+  BuildMemoryAllocationHob (
+Desc->PhysicalBase,
+Desc->Length,
+EfiReservedMemoryType
+  );
+}
+
+/*++
+
+Routine Description:
+
+
+
+Arguments:
+
+  FileHandle  - Handle of the file being invoked.
+  PeiServices - Describes the list of possible PEI Services.
+
+Returns:
+
+  Status -  EFI_SUCCESS if the boot mode could be set
+
+--*/
+EFI_STATUS
+EFIAPI
+MemoryPeim (
+  IN EFI_PHYSICAL_ADDRESS  UefiMemoryBase,
+  IN UINT64UefiMemorySize
+  )
+{
+  ARM_MEMORY_REGION_DESCRIPTOR *MemoryTable;
+
+  // Get Virtual Memory Map from the Platform Library
+  ArmPlatformGetVirtualMemoryMap (&MemoryTable);
+
+  // Ensure PcdSystemMemorySize has been set
+  ASSERT (PcdGet64 (PcdSystemMemorySize) != 0);
+
+  // FD without variable store
+  AddReservedMemoryRegion (&MemoryTable[0]);
+
+  // Variable store.
+  AddRuntimeServicesRegion (&MemoryTable[1]);
+
+  // Trusted Firmware region
+  AddReservedMemoryRegion (&MemoryTable[2]);
+
+  // Usable memory.
+  BuildResourceDescriptorHob (
+EFI_RESOURCE_SYSTEM_MEMORY,
+EFI_RESOURCE_ATTRIBUTE_PRESENT |
+EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
+EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
+EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
+EFI_RESOURCE_ATTRIBUTE_TESTED,
+MemoryTable[3].PhysicalBase,
+MemoryTable[3].Length
+  );
+
+  AddReservedMemoryRegion (&MemoryTable[4]);
+
+  // Build Memory Allocation Hob
+  InitMmu (MemoryTable);
+
+  if (FeaturePcdGet (PcdPrePiProduceMemoryTypeInformationHob)) {
+// Optional feature that helps prevent EFI memory map fragmentation.
+BuildMemoryTypeInformationHob ();
+  }
+
+  return EFI_SUCCESS;
+}
diff --git 
a/Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.inf 
b/Platform/Raspberry/Pi3/Library/MemoryInitPeiLib/MemoryInitPeiLib.inf
new file mode 100644
index ..8e44f2e39408
--- /

[edk2] [PATCH v4 edk2-platforms 03/23] Platform/Raspberry/Pi3: Add ACPI tables

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/AcpiTables/AcpiTables.h   |  82 
 Platform/Raspberry/Pi3/AcpiTables/AcpiTables.inf |  46 ++
 Platform/Raspberry/Pi3/AcpiTables/Csrt.aslc  | 332 +
 Platform/Raspberry/Pi3/AcpiTables/Dbg2.aslc  |  34 ++
 Platform/Raspberry/Pi3/AcpiTables/Dsdt.asl   | 511 
 Platform/Raspberry/Pi3/AcpiTables/Fadt.aslc  |  52 ++
 Platform/Raspberry/Pi3/AcpiTables/Gtdt.aslc  |  33 ++
 Platform/Raspberry/Pi3/AcpiTables/Madt.aslc  |  62 +++
 Platform/Raspberry/Pi3/AcpiTables/Pep.asl|  95 
 Platform/Raspberry/Pi3/AcpiTables/Pep.c  |  84 
 Platform/Raspberry/Pi3/AcpiTables/Pep.h  | 126 +
 Platform/Raspberry/Pi3/AcpiTables/Rhpx.asl   | 201 
 Platform/Raspberry/Pi3/AcpiTables/Sdhc.asl   | 105 
 Platform/Raspberry/Pi3/AcpiTables/Spcr.asl   |  53 ++
 Platform/Raspberry/Pi3/AcpiTables/Uart.asl   | 158 ++
 15 files changed, 1974 insertions(+)

diff --git a/Platform/Raspberry/Pi3/AcpiTables/AcpiTables.h 
b/Platform/Raspberry/Pi3/AcpiTables/AcpiTables.h
new file mode 100644
index ..be28b6decefd
--- /dev/null
+++ b/Platform/Raspberry/Pi3/AcpiTables/AcpiTables.h
@@ -0,0 +1,82 @@
+/** @file
+ *
+ *  RPi3 defines for constructing ACPI tables
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) Microsoft 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 __ACPITABLES_H__
+#define __ACPITABLES_H__
+
+#include 
+
+#define EFI_ACPI_OEM_ID   {'M','C','R','S','F','T'} // 
OEMID 6 bytes long
+#define EFI_ACPI_OEM_TABLE_ID SIGNATURE_64 
('R','P','I','3','E','D','K','2') // OEM table id 8 bytes long
+#define EFI_ACPI_OEM_REVISION 0x02000820
+#define EFI_ACPI_CREATOR_ID   SIGNATURE_32 ('R','P','I','3')
+#define EFI_ACPI_CREATOR_REVISION 0x0097
+
+#define EFI_ACPI_VENDOR_IDSIGNATURE_32 ('M','S','F','T')
+#define EFI_ACPI_CSRT_REVISION0x0005
+#define EFI_ACPI_CSRT_DEVICE_ID_DMA   0x0009 // Fixed id
+#define EFI_ACPI_CSRT_RESOURCE_ID_IN_DMA_GRP  0x0 // Count up from 0
+
+#define RPI3_DMA_CHANNEL_COUNT10 // All 10 DMA channels are 
listed, including the reserved ones
+#define RPI3_DMA_USED_CHANNEL_COUNT   5  // Use 5 DMA channels
+
+#define EFI_ACPI_5_0_CSRT_REVISION0x
+
+typedef enum
+{
+  EFI_ACPI_CSRT_RESOURCE_TYPE_RESERVED,   // 0
+  EFI_ACPI_CSRT_RESOURCE_TYPE_INTERRUPT,  // 1
+  EFI_ACPI_CSRT_RESOURCE_TYPE_TIMER,  // 2
+  EFI_ACPI_CSRT_RESOURCE_TYPE_DMA,// 3
+  EFI_ACPI_CSRT_RESOURCE_TYPE_CACHE,  // 4
+}
+CSRT_RESOURCE_TYPE;
+
+typedef enum
+{
+  EFI_ACPI_CSRT_RESOURCE_SUBTYPE_DMA_CHANNEL, // 0
+  EFI_ACPI_CSRT_RESOURCE_SUBTYPE_DMA_CONTROLLER   // 1
+}
+CSRT_DMA_SUBTYPE;
+
+//
+// CSRT Resource Group header 24 bytes long
+//
+typedef struct
+{
+  UINT32 Length;  // Length
+  UINT32 VendorID;// 4 bytes
+  UINT32 SubVendorId; // 4 bytes
+  UINT16 DeviceId;// 2 bytes
+  UINT16 SubdeviceId; // 2 bytes
+  UINT16 Revision;// 2 bytes
+  UINT16 Reserved;// 2 bytes
+  UINT32 SharedInfoLength;// 4 bytes
+} EFI_ACPI_5_0_CSRT_RESOURCE_GROUP_HEADER;
+
+//
+// CSRT Resource Descriptor 12 bytes total
+//
+typedef struct
+{
+  UINT32 Length;  // 4 bytes
+  UINT16 ResourceType;// 2 bytes
+  UINT16 ResourceSubType; // 2 bytes
+  UINT32 UID; // 4 bytes
+} EFI_ACPI_5_0_CSRT_RESOURCE_DESCRIPTOR_HEADER;
+
+#endif // __ACPITABLES_H__
diff --git a/Platform/Raspberry/Pi3/AcpiTables/AcpiTables.inf 
b/Platform/Raspberry/Pi3/AcpiTables/AcpiTables.inf
new file mode 100644
index ..62de9c072052
--- /dev/null
+++ b/Platform/Raspberry/Pi3/AcpiTables/AcpiTables.inf
@@ -0,0 +1,46 @@
+#/** @file
+#
+#  ACPI table data and ASL sources required to boot the platform.
+#
+#  Copyright (c) 2017, Andrey Warkentin 
+#  Copyright (c) Microsoft Corporation. All rights reserved.
+#
+#  This program and 

[edk2] [PATCH v4 edk2-platforms 05/23] Platform/Raspberry/Pi3: Add platform library

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Include/IndustryStandard/RpiMbox.h  | 108 
+
 Platform/Raspberry/Pi3/Library/PlatformLib/AArch64/RaspberryPiHelper.S | 107 
+
 Platform/Raspberry/Pi3/Library/PlatformLib/PlatformLib.inf |  65 

 Platform/Raspberry/Pi3/Library/PlatformLib/RaspberryPi.c   |  99 

 Platform/Raspberry/Pi3/Library/PlatformLib/RaspberryPiMem.c| 160 

 5 files changed, 539 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Include/IndustryStandard/RpiMbox.h 
b/Platform/Raspberry/Pi3/Include/IndustryStandard/RpiMbox.h
new file mode 100644
index ..8547ad05ba61
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Include/IndustryStandard/RpiMbox.h
@@ -0,0 +1,108 @@
+/** @file
+ *
+ * Copyright (c) 2019, Pete Batard 
+ * Copyright (c) 2016, Linaro Limited. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * Redistributions of source code must retain the above copyright notice, this
+ * list of conditions and the following disclaimer.
+ *
+ * Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * Neither the name of ARM nor the names of its contributors may be used
+ * to endorse or promote products derived from this software without specific
+ * prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ **/
+
+#ifndef __RASPBERRY_PI_MAILBOX_H__
+#define __RASPBERRY_PI_MAILBOX_H__
+
+/* Mailbox channels */
+#define RPI_MBOX_PM_CHANNEL   0
+#define RPI_MBOX_FB_CHANNEL   1
+#define RPI_MBOX_VUART_CHANNEL2
+#define RPI_MBOX_VCHIQ_CHANNEL3
+#define RPI_MBOX_LED_CHANNEL  4
+#define RPI_MBOX_BUTTON_CHANNEL   5
+#define RPI_MBOX_TOUCHSCREEN_CHANNEL  6
+/* Request from ARM for response by VideoCore */
+#define RPI_MBOX_VC_CHANNEL   8
+/* Request from VideoCore for response by ARM */
+#define RPI_MBOX_ARM_CHANNEL  9
+
+#define RPI_MBOX_RESP_SUCCESS 0x8000
+#define RPI_MBOX_RESP_FAILURE 0x8001
+
+#define RPI_MBOX_VALUE_SIZE_RESPONSE_MASK BIT31
+
+#define RPI_MBOX_GET_REVISION 0x0001
+#define RPI_MBOX_GET_BOARD_MODEL  0x00010001
+#define RPI_MBOX_GET_BOARD_REVISION   0x00010002
+#define RPI_MBOX_GET_MAC_ADDRESS  0x00010003
+#define RPI_MBOX_GET_BOARD_SERIAL 0x00010004
+#define RPI_MBOX_GET_ARM_MEMSIZE  0x00010005
+
+#define RPI_MBOX_SET_POWER_STATE  0x00028001
+
+#define RPI_MBOX_POWER_STATE_SDHCI0x
+#define RPI_MBOX_POWER_STATE_UART00x0001
+#define RPI_MBOX_POWER_STATE_UART10x0002
+#define RPI_MBOX_POWER_STATE_USB_HCD  0x0003
+#define RPI_MBOX_POWER_STATE_I2C0 0x0004
+#define RPI_MBOX_POWER_STATE_I2C1 0x0005
+#define RPI_MBOX_POWER_STATE_I2C2 0x0006
+#define RPI_MBOX_POWER_STATE_SPI  0x0007
+#define RPI_MBOX_POWER_STATE_CCP2TX   0x0008
+
+#define RPI_MBOX_GET_CLOCK_RATE   0x00030002
+#define RPI_MBOX_GET_MAX_CLOCK_RATE   0x00030004
+#define RPI_MBOX_GET_MIN_CLOCK_RATE   0x00030007
+
+#define RPI_MBOX_SET_CLOCK_RATE   0x00038002
+#def

[edk2] [PATCH v4 edk2-platforms 06/23] Platform/Raspberry/Pi3: Add RTC library

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 
Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
   | 221 
 
Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
 |  43 
 2 files changed, 264 insertions(+)

diff --git 
a/Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
 
b/Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
new file mode 100644
index ..dea621ff03ef
--- /dev/null
+++ 
b/Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
@@ -0,0 +1,221 @@
+/** @file
+ *
+ *  Implement dummy EFI RealTimeClock runtime services.
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) Microsoft 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 
+#include 
+
+/**
+   Returns the current time and date information, and the time-keeping 
capabilities
+   of the virtual RTC.
+
+   For simplicity, this LibGetTime does not report Years/Months, instead it 
will only report current
+   Day, Hours, Minutes and Seconds starting from the begining of CPU up-time. 
Otherwise, a more
+   complex logic will be required to account for leap years and days/month 
differences.
+
+   @param  Time  A pointer to storage to receive a snapshot of 
the current time.
+   @param  Capabilities  An optional pointer to a buffer to receive 
the real time clock
+   device's capabilities.
+
+   @retval EFI_SUCCESS   The operation completed successfully.
+   @retval EFI_INVALID_PARAMETER Time is NULL.
+   @retval EFI_DEVICE_ERROR  The time could not be retrieved due to 
hardware error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibGetTime (
+  OUT EFI_TIME   *Time,
+  OUT EFI_TIME_CAPABILITIES  *Capabilities
+  )
+{
+  UINTN DataSize;
+  UINT64 Counter;
+  EFI_STATUS Status;
+  UINTN ElapsedSeconds;
+  UINT32 Remainder;
+  UINT32 Freq = ArmGenericTimerGetTimerFreq ();
+
+  if (Time == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  //
+  // Depend on ARM generic timer to report date/time relative to the
+  // start of CPU timer counting where date and time will always
+  // be relative to the date/time 1/1/1900 00H:00M:00S
+  //
+
+  ASSERT (Freq != 0);
+  if (Freq == 0) {
+return EFI_DEVICE_ERROR;
+  }
+
+  if (Capabilities) {
+Capabilities->Accuracy = 0;
+Capabilities->Resolution = Freq;
+Capabilities->SetsToZero = FALSE;
+  }
+
+  DataSize = sizeof (UINTN);
+  ElapsedSeconds = 0;
+  Status = EfiGetVariable (L"RtcEpochSeconds",
+ &gEfiCallerIdGuid,
+ NULL,
+ &DataSize,
+ &ElapsedSeconds);
+  if (EFI_ERROR (Status)) {
+ElapsedSeconds = PcdGet64 (PcdBootEpochSeconds);
+  }
+  Counter = GetPerformanceCounter ();
+  ElapsedSeconds += DivU64x32Remainder (Counter, Freq, &Remainder);
+  EpochToEfiTime (ElapsedSeconds, Time);
+
+  //
+  // Frequency < 0x1, so Remainder < 0x1, then (Remainder * 
1,000,000,000)
+  // will not overflow 64-bit.
+  //
+  Time->Nanosecond = DivU64x32 (MultU64x64 ((UINT64)Remainder, 10U), 
Freq);
+
+  return EFI_SUCCESS;
+}
+
+
+/**
+   Sets the current local time and date information.
+
+   @param  Time  A pointer to the current time.
+
+   @retval EFI_SUCCESS   The operation completed successfully.
+   @retval EFI_INVALID_PARAMETER A time field is out of range.
+   @retval EFI_DEVICE_ERROR  The time could not be set due due to hardware 
error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibSetTime (
+  IN EFI_TIME  *Time
+  )
+{
+  UINTN Epoch;
+
+  if (!IsTimeValid (Time)) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  Epoch = EfiTimeToEpoch (Time);
+  return EfiSetVariable (L"RtcEpochSeconds", &gEfiCallerIdGuid,
+   EFI_VARIABLE_BOOTSERVICE_ACCESS |
+   EFI_VARIABLE_RUNTIME_ACCESS |
+   EFI_VARIABLE_NON_VOLATILE,
+   sizeof (Epoch),
+   &Epoch);
+}
+
+
+/**
+   Returns the current wakeup alarm clock setting.
+
+   @param  Enabled   Indicates if the alarm is currently enabled 
or disabled.
+   @param  Pending   Indicates if the alarm signal is pending and 
requires acknowledgement.
+   @param  Time  The current alarm setting.
+
+   @retval EFI_SUCCESS   The alarm settings were returned.
+   @retval EFI_INVALID_PARAMETER Any parameter is NULL.

[edk2] [PATCH v4 edk2-platforms 07/23] Platform/Raspberry/Pi3: Add firmware driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 

Reviewed-by: Ard Biesheuvel 
---
 Platform/Raspberry/Pi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 1084 

 Platform/Raspberry/Pi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.inf |   50 +
 Platform/Raspberry/Pi3/Include/Protocol/RpiFirmware.h|  131 +++
 3 files changed, 1265 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/Raspberry/Pi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
new file mode 100644
index ..d330e45fdc4c
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -0,0 +1,1084 @@
+/** @file
+ *
+ *  Copyright (c) 2017-2018, Andrei Warkentin 
+ *  Copyright (c) 2016, Linaro, Ltd. 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 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+//
+// The number of statically allocated buffer pages
+//
+#define NUM_PAGES   1
+
+//
+// The number of iterations to perform when waiting for the mailbox
+// status to change
+//
+#define MAX_TRIES   0x10
+
+STATIC VOID  *mDmaBuffer;
+STATIC VOID  *mDmaBufferMapping;
+STATIC UINTN mDmaBufferBusAddress;
+
+STATIC SPIN_LOCK mMailboxLock;
+
+STATIC
+BOOLEAN
+DrainMailbox (
+  VOID
+  )
+{
+  INTNTries;
+  UINT32  Val;
+
+  //
+  // Get rid of stale response data in the mailbox
+  //
+  Tries = 0;
+  do {
+Val = MmioRead32 (BCM2836_MBOX_BASE_ADDRESS + BCM2836_MBOX_STATUS_OFFSET);
+if (Val & (1U << BCM2836_MBOX_STATUS_EMPTY)) {
+  return TRUE;
+}
+ArmDataSynchronizationBarrier ();
+MmioRead32 (BCM2836_MBOX_BASE_ADDRESS + BCM2836_MBOX_READ_OFFSET);
+  } while (++Tries < MAX_TRIES);
+
+  return FALSE;
+}
+
+STATIC
+BOOLEAN
+MailboxWaitForStatusCleared (
+  IN  UINTN   StatusMask
+  )
+{
+  INTNTries;
+  UINT32  Val;
+
+  //
+  // Get rid of stale response data in the mailbox
+  //
+  Tries = 0;
+  do {
+Val = MmioRead32 (BCM2836_MBOX_BASE_ADDRESS + BCM2836_MBOX_STATUS_OFFSET);
+if ((Val & StatusMask) == 0) {
+  return TRUE;
+}
+ArmDataSynchronizationBarrier ();
+  } while (++Tries < MAX_TRIES);
+
+  return FALSE;
+}
+
+STATIC
+EFI_STATUS
+MailboxTransaction (
+  INUINTN   Length,
+  INUINTN   Channel,
+  OUT   UINT32  *Result
+  )
+{
+  if (Channel >= BCM2836_MBOX_NUM_CHANNELS) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  //
+  // Get rid of stale response data in the mailbox
+  //
+  if (!DrainMailbox ()) {
+DEBUG ((DEBUG_ERROR, "%a: timeout waiting for mailbox to drain\n",
+  __FUNCTION__));
+return EFI_TIMEOUT;
+  }
+
+  //
+  // Wait for the 'output register full' bit to become clear
+  //
+  if (!MailboxWaitForStatusCleared (1U << BCM2836_MBOX_STATUS_FULL)) {
+DEBUG ((DEBUG_ERROR, "%a: timeout waiting for outbox to become empty\n",
+  __FUNCTION__));
+return EFI_TIMEOUT;
+  }
+
+  ArmDataSynchronizationBarrier ();
+
+  //
+  // Start the mailbox transaction
+  //
+  MmioWrite32 (BCM2836_MBOX_BASE_ADDRESS + BCM2836_MBOX_WRITE_OFFSET,
+(UINT32)((UINTN)mDmaBufferBusAddress | Channel));
+
+  ArmDataSynchronizationBarrier ();
+
+  //
+  // Wait for the 'input register empty' bit to clear
+  //
+  if (!MailboxWaitForStatusCleared (1U << BCM2836_MBOX_STATUS_EMPTY)) {
+DEBUG ((DEBUG_ERROR, "%a: timeout waiting for inbox to become full\n",
+  __FUNCTION__));
+return EFI_TIMEOUT;
+  }
+
+  //
+  // Read back the result
+  //
+  ArmDataSynchronizationBarrier ();
+  *Result = MmioRead32 (BCM2836_MBOX_BASE_ADDRESS + BCM2836_MBOX_READ_OFFSET);
+  ArmDataSynchronizationBarrier ();
+
+  return EFI_SUCCESS;
+}
+
+#pragma pack(1)
+typedef struct {
+  UINT32BufferSize;
+  UINT32Response;
+} RPI_FW_BUFFER_HEAD;
+
+typedef struct {
+  UINT32TagId;
+  UINT32TagSize;
+  UINT32TagValueSize;
+} RPI_FW_TAG_HEAD;
+
+typedef struct {
+  UINT32DeviceId;
+  UINT32PowerState;
+} RPI_FW_POWER_STATE_TAG;
+
+typedef struct {
+  RPI_FW_BUFFER_HEADBufferHead;
+  RPI_FW_TAG_HEAD   TagHead;
+  RPI_FW_POWER_STATE_TAGTagBody;
+  UINT32EndTag;
+} RPI_FW_SET_POWER_STATE_CMD;
+#pragma pack()
+
+STATIC
+EFI_STATUS
+EFIAPI
+RpiFirmwareSetPowerState (
+  IN  UINT32DeviceId,
+  IN  BOOLEAN   PowerState,
+  IN  BOOLEAN   Wait
+  )
+{
+  RPI_FW_SET_POWER_STATE_CMD  *Cmd;
+  EFI_STATUS  Status;
+  UINT32  Res

[edk2] [PATCH v4 edk2-platforms 08/23] Platform/Raspberry/Pi3: Add platform config driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxe.c| 351 

 Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxe.inf  |  78 +
 Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxeFormSetGuid.h |  23 ++
 Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxeHii.uni   | 100 ++
 Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxeHii.vfr   | 306 
+
 5 files changed, 858 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxe.c
new file mode 100644
index ..b78d7deae402
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/ConfigDxe/ConfigDxe.c
@@ -0,0 +1,351 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *
+ *  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 
+#include 
+#include 
+#include "ConfigDxeFormSetGuid.h"
+
+extern UINT8 ConfigDxeHiiBin[];
+extern UINT8 ConfigDxeStrings[];
+
+STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
+
+typedef struct {
+  VENDOR_DEVICE_PATH VendorDevicePath;
+  EFI_DEVICE_PATH_PROTOCOL End;
+} HII_VENDOR_DEVICE_PATH;
+
+STATIC HII_VENDOR_DEVICE_PATH mVendorDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8)(sizeof (VENDOR_DEVICE_PATH)),
+(UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+CONFIGDXE_FORM_SET_GUID
+  },
+  {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{
+  (UINT8)(END_DEVICE_PATH_LENGTH),
+  (UINT8)((END_DEVICE_PATH_LENGTH) >> 8)
+}
+  }
+};
+
+
+STATIC EFI_STATUS
+InstallHiiPages (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EFI_HII_HANDLE HiiHandle;
+  EFI_HANDLE DriverHandle;
+
+  DriverHandle = NULL;
+  Status = gBS->InstallMultipleProtocolInterfaces (&DriverHandle,
+  &gEfiDevicePathProtocolGuid,
+  &mVendorDevicePath,
+  NULL);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  HiiHandle = HiiAddPackages (&gConfigDxeFormSetGuid,
+DriverHandle,
+ConfigDxeStrings,
+ConfigDxeHiiBin,
+NULL);
+
+  if (HiiHandle == NULL) {
+gBS->UninstallMultipleProtocolInterfaces (DriverHandle,
+   &gEfiDevicePathProtocolGuid,
+   &mVendorDevicePath,
+   NULL);
+return EFI_OUT_OF_RESOURCES;
+  }
+  return EFI_SUCCESS;
+}
+
+
+STATIC EFI_STATUS
+SetupVariables (
+  VOID
+  )
+{
+  UINTN Size;
+  UINT32 Var32;
+  EFI_STATUS Status;
+
+  /*
+   * Create the vars with default value.
+   * If we don't, forms won't be able to update.
+   */
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"CpuClock",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdCpuClock, PcdGet32 (PcdCpuClock));
+  }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"SdIsArasan",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdSdIsArasan, PcdGet32 (PcdSdIsArasan));
+  }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"MmcDisableMulti",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdMmcDisableMulti, PcdGet32 (PcdMmcDisableMulti));
+  }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"MmcForce1Bit",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdMmcForce1Bit, PcdGet32 (PcdMmcForce1Bit));
+  }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"MmcForceDefaultSpeed",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdMmcForceDefaultSpeed, PcdGet32 (PcdMmcForceDefaultSpeed));
+  }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"MmcSdDefaultSpeedMHz",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdMmcSdDefaultSpeedMHz, PcdGet32 (PcdMmcSdDefaultSpeedMHz));
+  }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"MmcSdHighSpeedMHz",
+  &gConfigDxeFormSetGuid,
+  NULL, &Size, &Var32);
+  if (EFI_ERROR (Status)) {
+PcdSet32 (PcdMm

[edk2] [PATCH v4 edk2-platforms 09/23] Platform/Raspberry/Pi3: Add SMBIOS driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c   | 903 

 Platform/Raspberry/Pi3/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf |  56 ++
 2 files changed, 959 insertions(+)

diff --git 
a/Platform/Raspberry/Pi3/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/Raspberry/Pi3/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
new file mode 100644
index ..7707763e4332
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -0,0 +1,903 @@
+/** @file
+ *
+ *  Static SMBIOS Table for ARM platform
+ *  Derived from EmulatorPkg package
+ *
+ *  Note SMBIOS 2.7.1 Required structures:
+ *  BIOS Information (Type 0)
+ *  System Information (Type 1)
+ *  Board Information (Type 2)
+ *  System Enclosure (Type 3)
+ *  Processor Information (Type 4) - CPU Driver
+ *  Cache Information (Type 7) - For cache that is external to processor
+ *  System Slots (Type 9) - If system has slots
+ *  Physical Memory Array (Type 16)
+ *  Memory Device (Type 17) - For each socketed system-memory Device
+ *  Memory Array Mapped Address (Type 19) - One per contiguous block per 
Physical Memroy Array
+ *  System Boot Information (Type 32)
+ *
+ *  Copyright (c) 2017-2018, Andrey Warkentin 
+ *  Copyright (c) 2013, Linaro.org
+ *  Copyright (c) 2012, Apple Inc. All rights reserved.
+ *  Copyright (c) Microsoft 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
+
+/***
+SMBIOS data definition  TYPE0  BIOS Information
+/
+SMBIOS_TABLE_TYPE0 mBIOSInfoType0 = {
+  { EFI_SMBIOS_TYPE_BIOS_INFORMATION, sizeof (SMBIOS_TABLE_TYPE0), 0 },
+  1,// Vendor String
+  2,// BiosVersion String
+  0x0,  // BiosSegment
+  3,// BiosReleaseDate String
+  0x1F, // BiosSize
+  { // BiosCharacteristics
+0,//  Reserved  :2;  ///< Bits 0-1.
+0,//  Unknown   :1;
+0,//  BiosCharacteristicsNotSupported   :1;
+0,//  IsaIsSupported:1;
+0,//  McaIsSupported:1;
+0,//  EisaIsSupported   :1;
+0,//  PciIsSupported:1;
+0,//  PcmciaIsSupported :1;
+0,//  PlugAndPlayIsSupported:1;
+0,//  ApmIsSupported:1;
+0,//  BiosIsUpgradable  :1;
+0,//  BiosShadowingAllowed  :1;
+0,//  VlVesaIsSupported :1;
+0,//  EscdSupportIsAvailable:1;
+0,//  BootFromCdIsSupported :1;
+1,//  SelectableBootIsSupported :1;
+0,//  RomBiosIsSocketed :1;
+0,//  BootFromPcmciaIsSupported :1;
+0,//  EDDSpecificationIsSupported   :1;
+0,//  JapaneseNecFloppyIsSupported  :1;
+0,//  JapaneseToshibaFloppyIsSupported  :1;
+0,//  Floppy525_360IsSupported  :1;
+0,//  Floppy525_12IsSupported   :1;
+0,//  Floppy35_720IsSupported   :1;
+0,//  Floppy35_288IsSupported   :1;
+0,//  PrintScreenIsSupported:1;
+0,//  Keyboard8042IsSupported   :1;
+0,//  SerialIsSupported :1;
+0,//  PrinterIsSupported:1;
+0,//  CgaMonoIsSupported:1;
+0,//  NecPc98   :1;
+0 //  ReservedForVendor :32; ///< Bits 32-63. Bits 
32-47 reserved for BIOS vendor
+///< and bits 48-63 reserved for System Vendor.
+  },
+  {   // BIOSCharacteristicsExtensionBytes[]
+0x01, //  AcpiIsSupported   :1;
+  //  UsbLegacyIsSupported  :1;
+  //  AgpIsSupported:1;
+  //  I2OBootIsSupported:1;
+  //  Ls120BootIsSupported  :1;
+  //  AtapiZipDriveBootIsSupported  :1;
+  //  Boot1394IsSupported 

[edk2] [PATCH v4 edk2-platforms 10/23] Platform/Raspberry/Pi3: Add display driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/DisplayDxe/ComponentName.c | 222 +++
 Platform/Raspberry/Pi3/Drivers/DisplayDxe/DisplayDxe.c| 606 

 Platform/Raspberry/Pi3/Drivers/DisplayDxe/DisplayDxe.h|  42 ++
 Platform/Raspberry/Pi3/Drivers/DisplayDxe/DisplayDxe.inf  |  71 +++
 Platform/Raspberry/Pi3/Drivers/DisplayDxe/Screenshot.c| 375 
 5 files changed, 1316 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/DisplayDxe/ComponentName.c 
b/Platform/Raspberry/Pi3/Drivers/DisplayDxe/ComponentName.c
new file mode 100644
index ..9a84aea511f4
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/DisplayDxe/ComponentName.c
@@ -0,0 +1,222 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  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
+ *
+ *  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 "DisplayDxe.h"
+
+STATIC
+EFI_STATUS
+EFIAPI
+ComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  );
+
+STATIC
+EFI_STATUS
+EFIAPI
+ComponentNameGetControllerName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL *This,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  EFI_HANDLE  ChildHandle,
+  IN  CHAR8   *Language,
+  OUT CHAR16  **ControllerName
+  );
+
+//
+// EFI Component Name Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL gComponentName = {
+  ComponentNameGetDriverName,
+  ComponentNameGetControllerName,
+  "eng"
+};
+
+//
+// EFI Component Name 2 Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL gComponentName2 = {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)ComponentNameGetDriverName,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)ComponentNameGetControllerName,
+  "en"
+};
+
+
+STATIC EFI_UNICODE_STRING_TABLE mDriverName[] = {
+  {
+"eng;en",
+(CHAR16*)L"Raspberry Pi Display Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+STATIC EFI_UNICODE_STRING_TABLE mDeviceName[] = {
+  {
+"eng;en",
+(CHAR16*)L"Raspberry Pi Framebuffer"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This[in]  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+  @param  Language[in]  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+  @param  DriverName[out]   A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support
+the language specified by Language.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+ComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  )
+{
+  return LookupUnicodeString2 (
+   

[edk2] [PATCH v4 edk2-platforms 11/23] Platform/Raspberry/Pi3: Add console driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/ComponentName.c 
|  183 ++
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/GraphicsConsole.c   
| 1837 
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/GraphicsConsole.h   
|  591 +++
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.inf  
|   75 +
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.uni  
|   18 +
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxeExtra.uni 
|   18 +
 Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/NewFont.c   
|  287 +++
 Platform/Raspberry/Pi3/Include/Protocol/ExtendedTextOut.h 
|   36 +
 8 files changed, 3045 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/ComponentName.c 
b/Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/ComponentName.c
new file mode 100644
index ..3ae639ad3d97
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/GraphicsConsoleDxe/ComponentName.c
@@ -0,0 +1,183 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  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
+ *
+ *  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 "GraphicsConsole.h"
+
+//
+// EFI Component Name Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  
gGraphicsConsoleComponentName = {
+  GraphicsConsoleComponentNameGetDriverName,
+  GraphicsConsoleComponentNameGetControllerName,
+  "eng"
+};
+
+//
+// EFI Component Name 2 Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL 
gGraphicsConsoleComponentName2 = {
+  
(EFI_COMPONENT_NAME2_GET_DRIVER_NAME)GraphicsConsoleComponentNameGetDriverName,
+  
(EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)GraphicsConsoleComponentNameGetControllerName,
+  "en"
+};
+
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE 
mGraphicsConsoleDriverNameTable[] = {
+  {
+"eng;en",
+(CHAR16*)L"Graphics Console Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This[in]  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+  @param  Language[in]  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+  @param  DriverName[out]   A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support
+the language specified by Language.
+
+**/
+EFI_STATUS
+EFIAPI
+GraphicsConsoleComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  )
+{
+  return LookupUnicodeString2 (
+   Language,
+   This->SupportedLanguages,
+   mGraphicsConsoleDriverNameTable,
+   DriverName,
+   (BO

[edk2] [PATCH v4 edk2-platforms 12/23] Platform/Raspberry/Pi3: Add NV storage driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/FileIo.c   | 196 

 Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/FvbInfo.c  | 115 
+++
 Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/VarBlockService.c  | 971 

 Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/VarBlockService.h  | 217 
+
 Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c   | 331 
+++
 Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf |  93 
++
 6 files changed, 1923 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/FileIo.c 
b/Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/FileIo.c
new file mode 100644
index ..0e8cd516f65e
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/VarBlockServiceDxe/FileIo.c
@@ -0,0 +1,196 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) 2007-2009, 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 "VarBlockService.h"
+
+
+EFI_STATUS
+FileWrite (
+  IN EFI_FILE_PROTOCOL *File,
+  IN UINTN Offset,
+  IN UINTN Buffer,
+  IN UINTN Size
+  )
+{
+  EFI_STATUS Status;
+
+  Status = File->SetPosition (File, Offset);
+  ASSERT_EFI_ERROR (Status);
+  if (!EFI_ERROR (Status)) {
+Status = File->Write (File, &Size, (VOID*)Buffer);
+ASSERT_EFI_ERROR (Status);
+  }
+  return Status;
+}
+
+
+VOID
+FileClose (
+  IN  EFI_FILE_PROTOCOL *File
+  )
+{
+  File->Flush (File);
+  File->Close (File);
+}
+
+
+EFI_STATUS
+FileOpen (
+  IN  EFI_DEVICE_PATH_PROTOCOL *Device,
+  IN  CHAR16 *MappedFile,
+  OUT EFI_FILE_PROTOCOL **File,
+  IN  UINT64 OpenMode
+  )
+{
+  EFI_HANDLEHandle;
+  EFI_FILE_HANDLE   Root;
+  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL   *Volume;
+  EFI_STATUSStatus;
+
+  *File = NULL;
+
+  Status = gBS->LocateDevicePath (
+  &gEfiSimpleFileSystemProtocolGuid,
+  &Device,
+  &Handle
+);
+
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  Status = gBS->HandleProtocol (
+  Handle,
+  &gEfiSimpleFileSystemProtocolGuid,
+  (VOID**)&Volume
+);
+  ASSERT_EFI_ERROR (Status);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  //
+  // Open the root directory of the volume
+  //
+  Root = NULL;
+  Status = Volume->OpenVolume (
+ Volume,
+ &Root
+   );
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (Root != NULL);
+
+  //
+  // Open file
+  //
+  Status = Root->Open (
+   Root,
+   File,
+   MappedFile,
+   OpenMode,
+   0
+ );
+  if (EFI_ERROR (Status)) {
+*File = NULL;
+  }
+
+  //
+  // Close the Root directory
+  //
+  Root->Close (Root);
+  return Status;
+}
+
+
+EFI_STATUS
+CheckStore (
+  IN  EFI_HANDLE SimpleFileSystemHandle,
+  OUT EFI_DEVICE_PATH_PROTOCOL **Device
+  )
+{
+  EFI_STATUS Status;
+  EFI_BLOCK_IO_PROTOCOL *BlkIo;
+  EFI_FILE_PROTOCOL *File;
+
+  *Device = NULL;
+  Status = gBS->HandleProtocol (
+  SimpleFileSystemHandle,
+  &gEfiBlockIoProtocolGuid,
+  (VOID*)&BlkIo
+);
+
+  if (EFI_ERROR (Status)) {
+goto ErrHandle;
+  }
+  if (!BlkIo->Media->MediaPresent) {
+DEBUG ((DEBUG_ERROR, "FwhMappedFile: Media not present!\n"));
+Status = EFI_NO_MEDIA;
+goto ErrHandle;
+  }
+  if (BlkIo->Media->ReadOnly) {
+DEBUG ((DEBUG_ERROR, "FwhMappedFile: Media is read-only!\n"));
+Status = EFI_ACCESS_DENIED;
+goto ErrHandle;
+  }
+
+  Status = FileOpen (DevicePathFromHandle (SimpleFileSystemHandle),
+ mFvInstance->MappedFile, &File,
+ EFI_FILE_MODE_READ);
+  if (EFI_ERROR (Status)) {
+goto ErrHandle;
+  }
+
+  /* We found it! Maybe do more checks...? */
+
+  FileClose (File);
+  *Device = DuplicateDevicePath (DevicePathFromHandle 
(SimpleFileSystemHandle));
+
+  ASSERT (*Device != NULL);
+
+ErrHandle:
+  return Status;
+}
+
+
+EFI_STATUS
+CheckStoreExists (
+  IN  EFI_DEVICE_PATH_PROTOCOL *Device
+  )
+{
+  EFI_HANDLE Handle;
+  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL *Volume;
+  EFI_STATUS Status;
+
+  Status = gBS->LocateDevicePath (
+  &gEfiSimpleFileSystemProtocolGuid,
+  &Device,
+  &Handle
+ 

[edk2] [PATCH v4 edk2-platforms 13/23] Platform/Raspberry/Pi3: Add Device Tree driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/FdtDxe/FdtDxe.c   | 364 
 Platform/Raspberry/Pi3/Drivers/FdtDxe/FdtDxe.inf |  53 +++
 2 files changed, 417 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/FdtDxe/FdtDxe.c 
b/Platform/Raspberry/Pi3/Drivers/FdtDxe/FdtDxe.c
new file mode 100644
index ..eb5698cb505b
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/FdtDxe/FdtDxe.c
@@ -0,0 +1,364 @@
+/** @file
+ *
+ *  Copyright (c) 2017, Andrey Warkentin 
+ *  Copyright (c) 2016, Linaro, Ltd. 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 
+
+#include 
+
+STATIC VOID *mFdtImage;
+
+STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL   *mFwProtocol;
+
+STATIC
+VOID
+UpdateMacAddress (
+  VOID
+  )
+{
+  INTN  Node;
+  INTN  Retval;
+  EFI_STATUSStatus;
+  UINT8 MacAddress[6];
+
+  //
+  // Locate the node that the 'ethernet' alias refers to
+  //
+  Node = fdt_path_offset (mFdtImage, "ethernet");
+  if (Node < 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to locate 'ethernet' alias\n", 
__FUNCTION__));
+return;
+  }
+
+  //
+  // Get the MAC address from the firmware
+  //
+  Status = mFwProtocol->GetMacAddress (MacAddress);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: failed to retrieve MAC address\n", 
__FUNCTION__));
+return;
+  }
+
+  Retval = fdt_setprop (mFdtImage, Node, "mac-address", MacAddress,
+sizeof MacAddress);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to create 'mac-address' property (%d)\n",
+  __FUNCTION__, Retval));
+return;
+  }
+
+  DEBUG ((DEBUG_INFO, "%a: setting MAC address to 
%02x:%02x:%02x:%02x:%02x:%02x\n",
+__FUNCTION__, MacAddress[0], MacAddress[1], MacAddress[2], MacAddress[3],
+MacAddress[4], MacAddress[5]));
+}
+
+STATIC
+VOID
+CleanMemoryNodes (
+  VOID
+  )
+{
+  INTN Node;
+  INT32 Retval;
+
+  Node = fdt_path_offset (mFdtImage, "/memory");
+  if (Node < 0) {
+return;
+  }
+
+  /*
+   * Remove bogus memory nodes which can make the booted
+   * OS go crazy and ignore the UEFI map.
+   */
+  DEBUG ((DEBUG_INFO, "Removing bogus /memory\n"));
+  Retval = fdt_del_node (mFdtImage, Node);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "Failed to remove /memory\n"));
+  }
+}
+
+STATIC
+VOID
+SanitizePSCI (
+  VOID
+  )
+{
+  INTN Node;
+  INTN Root;
+  INT32 Retval;
+
+  Root = fdt_path_offset (mFdtImage, "/");
+  ASSERT (Root >= 0);
+  if (Root < 0) {
+return;
+  }
+
+  Node = fdt_path_offset (mFdtImage, "/psci");
+  if (Node < 0) {
+Node = fdt_add_subnode (mFdtImage, Root, "psci");
+  }
+
+  ASSERT (Node >= 0);
+  if (Node < 0) {
+DEBUG ((DEBUG_ERROR, "Couldn't find/create /psci\n"));
+return;
+  }
+
+  Retval = fdt_setprop_string (mFdtImage, Node, "compatible", "arm,psci-1.0");
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "Couldn't set /psci compatible property\n"));
+return;
+  }
+
+  Retval = fdt_setprop_string (mFdtImage, Node, "method", "smc");
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "Couldn't set /psci method property\n"));
+return;
+  }
+
+  Root = fdt_path_offset (mFdtImage, "/cpus");
+  if (Root < 0) {
+DEBUG ((DEBUG_ERROR, "No CPUs to update with PSCI enable-method?\n"));
+return;
+  }
+
+  Node = fdt_first_subnode (mFdtImage, Root);
+  while (Node >= 0) {
+if (fdt_setprop_string (mFdtImage, Node, "enable-method", "psci") != 0) {
+  DEBUG ((DEBUG_ERROR, "Failed to update enable-method for a CPU\n"));
+  return;
+}
+
+fdt_delprop (mFdtImage, Node, "cpu-release-addr");
+Node = fdt_next_subnode (mFdtImage, Node);
+  }
+}
+
+STATIC
+VOID
+CleanSimpleFramebuffer (
+  VOID
+  )
+{
+  INTN Node;
+  INT32 Retval;
+
+  /*
+   * Should look for nodes by kind and remove aliases
+   * by matching against device.
+   */
+  Node = fdt_path_offset (mFdtImage, "display0");
+  if (Node < 0) {
+return;
+  }
+
+  /*
+   * Remove bogus GPU-injected simple-framebuffer, which
+   * doesn't reflect the framebuffer built by UEFI.
+   */
+  DEBUG ((DEBUG_INFO, "Removing bogus display0\n"));
+  Retval = fdt_del_node (mFdtImage, Node);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "Failed to remove display0\n"));
+return;
+  }
+
+  Node = fdt_path_offset (mFdtImage, "/aliases");
+  if (Node < 0) {
+DEBUG ((DEBUG_ERROR, "Couldn't find /aliases to remove display0\n"));
+return;
+  }
+
+  Retval 

[edk2] [PATCH v4 edk2-platforms 14/23] Platform/Raspberry/Pi3: Add base MMC driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/MmcDxe/ComponentName.c | 163 
 Platform/Raspberry/Pi3/Drivers/MmcDxe/Diagnostics.c   | 263 ++
 Platform/Raspberry/Pi3/Drivers/MmcDxe/Mmc.c   | 460 +
 Platform/Raspberry/Pi3/Drivers/MmcDxe/Mmc.h   | 533 +++
 Platform/Raspberry/Pi3/Drivers/MmcDxe/MmcBlockIo.c| 469 ++
 Platform/Raspberry/Pi3/Drivers/MmcDxe/MmcDebug.c  | 170 
 Platform/Raspberry/Pi3/Drivers/MmcDxe/MmcDxe.inf  |  58 ++
 Platform/Raspberry/Pi3/Drivers/MmcDxe/MmcIdentification.c | 980 

 Platform/Raspberry/Pi3/Include/Protocol/RpiMmcHost.h  | 206 
 9 files changed, 3302 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/MmcDxe/ComponentName.c 
b/Platform/Raspberry/Pi3/Drivers/MmcDxe/ComponentName.c
new file mode 100644
index ..034da778cae2
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/MmcDxe/ComponentName.c
@@ -0,0 +1,163 @@
+/** @file
+ *
+ *  Component Name Protocol implementation for the MMC DXE driver
+ *
+ *  Copyright (c) 2011, ARM Limited. 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 "Mmc.h"
+
+//
+// EFI Component Name Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL  gMmcComponentName = 
{
+  MmcGetDriverName,
+  MmcGetControllerName,
+  "eng"
+};
+
+//
+// EFI Component Name 2 Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL gMmcComponentName2 
= {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)MmcGetDriverName,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)MmcGetControllerName,
+  "en"
+};
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_UNICODE_STRING_TABLE
+mMmcDriverNameTable[] = {
+  {"eng;en", L"MMC/SD Card Interface Driver"},
+  {NULL,  NULL}
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+  @param  Language  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+  @param  DriverNameA pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support
+the language specified by Language.
+
+**/
+EFI_STATUS
+EFIAPI
+MmcGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  )
+{
+  return LookupUnicodeString2 (
+   Language,
+   This->SupportedLanguages,
+   mMmcDriverNameTable,
+   DriverName,
+   (BOOLEAN)(This == &gMmcComponentName)
+ );
+}
+
+/**
+  Retrieves a Unicode string that is the user readable name of the controller
+  that is being managed by a driver.
+
+  This function retrieves the user readable name of the controller specified by
+  ControllerHandle and ChildHandle in the form of a Unicode string.

[edk2] [PATCH v4 edk2-platforms 15/23] Platform/Raspberry/Pi3: Add Arasan MMC driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c   | 723 

 Platform/Raspberry/Pi3/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.h   |  50 ++
 Platform/Raspberry/Pi3/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.inf |  52 ++
 Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Sdio.h  | 199 
++
 4 files changed, 1024 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c 
b/Platform/Raspberry/Pi3/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
new file mode 100644
index ..828b40f82a5f
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c
@@ -0,0 +1,723 @@
+/** @file
+ *
+ *  Copyright (c) 2017, Andrei Warkentin 
+ *  Copyright (c) Microsoft 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 "ArasanMmcHostDxe.h"
+
+#define DEBUG_MMCHOST_SD DEBUG_VERBOSE
+
+BOOLEAN PreviousIsCardPresent = FALSE;
+UINT32 LastExecutedCommand = (UINT32) -1;
+
+STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
+
+/**
+   These SD commands are optional, according to the SD Spec
+**/
+BOOLEAN
+IgnoreCommand (
+  UINT32 Command
+  )
+{
+  switch (Command) {
+  case MMC_CMD20:
+return TRUE;
+  default:
+return FALSE;
+  }
+}
+
+/**
+   Translates a generic SD command into the format used by the Arasan SD Host 
Controller
+**/
+UINT32
+TranslateCommand (
+  UINT32 Command,
+  UINT32 Argument
+  )
+{
+  UINT32 Translation = 0x;
+
+  if (LastExecutedCommand == CMD55) {
+switch (Command) {
+case MMC_CMD6:
+  Translation = ACMD6;
+  DEBUG ((DEBUG_MMCHOST_SD, "ACMD6\n"));
+  break;
+case MMC_ACMD22:
+  Translation = ACMD22;
+  DEBUG ((DEBUG_MMCHOST_SD, "ACMD22\n"));
+  break;
+case MMC_ACMD41:
+  Translation = ACMD41;
+  DEBUG ((DEBUG_MMCHOST_SD, "ACMD41\n"));
+  break;
+case MMC_ACMD51:
+  Translation = ACMD51;
+  DEBUG ((DEBUG_MMCHOST_SD, "ACMD51\n"));
+  break;
+default:
+  DEBUG ((DEBUG_ERROR, "ArasanMMCHost: TranslateCommand(): Unrecognized 
App command: %d\n", Command));
+}
+  } else {
+switch (Command) {
+case MMC_CMD0:
+  Translation = CMD0;
+  break;
+case MMC_CMD1:
+  Translation = CMD1;
+  break;
+case MMC_CMD2:
+  Translation = CMD2;
+  break;
+case MMC_CMD3:
+  Translation = CMD3;
+  break;
+case MMC_CMD5:
+  Translation = CMD5;
+  break;
+case MMC_CMD6:
+  Translation = CMD6;
+  break;
+case MMC_CMD7:
+  Translation = CMD7;
+  break;
+case MMC_CMD8: {
+  if (Argument == CMD8_SD_ARG) {
+Translation = CMD8_SD;
+DEBUG ((DEBUG_MMCHOST_SD, "Sending SD CMD8 variant\n"));
+  } else {
+ASSERT (Argument == CMD8_MMC_ARG);
+Translation = CMD8_MMC;
+DEBUG ((DEBUG_MMCHOST_SD, "Sending MMC CMD8 variant\n"));
+  }
+  break;
+}
+case MMC_CMD9:
+  Translation = CMD9;
+  break;
+case MMC_CMD11:
+  Translation = CMD11;
+  break;
+case MMC_CMD12:
+  Translation = CMD12;
+  break;
+case MMC_CMD13:
+  Translation = CMD13;
+  break;
+case MMC_CMD16:
+  Translation = CMD16;
+  break;
+case MMC_CMD17:
+  Translation = CMD17;
+  break;
+case MMC_CMD18:
+  Translation = CMD18;
+  break;
+case MMC_CMD23:
+  Translation = CMD23;
+  break;
+case MMC_CMD24:
+  Translation = CMD24;
+  break;
+case MMC_CMD25:
+  Translation = CMD25;
+  break;
+case MMC_CMD55:
+  Translation = CMD55;
+  break;
+default:
+  DEBUG ((DEBUG_ERROR, "ArasanMMCHost: TranslateCommand(): Unrecognized 
Command: %d\n", Command));
+}
+  }
+
+  return Translation;
+}
+
+/**
+   Repeatedly polls a register until its value becomes correct, or until 
MAX_RETRY_COUNT polls is reached
+**/
+EFI_STATUS
+PollRegisterWithMask (
+  IN UINTN Register,
+  IN UINTN Mask,
+  IN UINTN ExpectedValue
+  )
+{
+  UINTN RetryCount = 0;
+
+  while (RetryCount < MAX_RETRY_COUNT) {
+if ((MmioRead32 (Register) & Mask) != ExpectedValue) {
+  RetryCount++;
+  gBS->Stall (STALL_AFTER_RETRY_US);
+} else {
+  break;
+}
+  }
+
+  if (RetryCount == MAX_RETRY_COUNT) {
+return EFI_TIMEOUT;
+  }
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+SoftReset (
+  IN UINT32 Mask
+  )
+{
+  MmioOr32 (MMCHS_SYSCTL, Mask);
+  if (PollRegisterWithMask (MMCHS_SYSCT

[edk2] [PATCH v4 edk2-platforms 16/23] Platform/Raspberry/Pi3: Platform/Raspberry/Pi3: Add SD Host driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/SdHostDxe/SdHostDxe.c  | 787 

 Platform/Raspberry/Pi3/Drivers/SdHostDxe/SdHostDxe.inf|  55 ++
 Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836SdHost.h |  92 +++
 3 files changed, 934 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/SdHostDxe/SdHostDxe.c 
b/Platform/Raspberry/Pi3/Drivers/SdHostDxe/SdHostDxe.c
new file mode 100644
index ..3bf789f96b27
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/SdHostDxe/SdHostDxe.c
@@ -0,0 +1,787 @@
+/** @file
+ *
+ *  Copyright (c) 2017, Andrei Warkentin 
+ *  Copyright (c) Microsoft 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 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define SDHOST_BLOCK_BYTE_LENGTH512
+
+// Driver Timing Parameters
+#define CMD_STALL_AFTER_POLL_US 1
+#define CMD_MIN_POLL_TOTAL_TIME_US  10 // 100ms
+#define CMD_MAX_POLL_COUNT  (CMD_MIN_POLL_TOTAL_TIME_US / 
CMD_STALL_AFTER_POLL_US)
+#define CMD_MAX_RETRY_COUNT 3
+#define CMD_STALL_AFTER_RETRY_US20 // 20us
+#define FIFO_MAX_POLL_COUNT 100
+#define STALL_TO_STABILIZE_US   1 // 10ms
+
+#define IDENT_MODE_SD_CLOCK_FREQ_HZ 40 // 400KHz
+
+// Macros adopted from MmcDxe internal header
+#define SDHOST_R0_READY_FOR_DATABIT8
+#define SDHOST_R0_CURRENTSTATE(Response)((Response >> 9) & 0xF)
+
+#define DEBUG_MMCHOST_SD   DEBUG_VERBOSE
+#define DEBUG_MMCHOST_SD_INFO  DEBUG_INFO
+#define DEBUG_MMCHOST_SD_ERROR DEBUG_ERROR
+
+STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL   *mFwProtocol;
+
+// Per Physical Layer Simplified Specs
+#ifndef NDEBUG
+STATIC CONST CHAR8* mStrSdState[] = { "idle", "ready", "ident", "stby",
+  "tran", "data", "rcv", "prg", "dis",
+  "ina" };
+STATIC CONST CHAR8 *mFsmState[] = { "identmode", "datamode", "readdata",
+"writedata", "readwait", "readcrc",
+"writecrc", "writewait1", "powerdown",
+"powerup", "writestart1", "writestart2",
+"genpulses", "writewait2", "?",
+"startpowdown" };
+#endif /* NDEBUG */
+STATIC UINT32 mLastGoodCmd = MMC_GET_INDX (MMC_CMD0);
+
+STATIC inline BOOLEAN
+IsAppCmd (
+  VOID
+  )
+{
+  return mLastGoodCmd == MMC_CMD55;
+}
+
+STATIC BOOLEAN
+IsBusyCmd (
+  IN  UINT32 MmcCmd
+  )
+{
+  if (IsAppCmd ()) {
+return FALSE;
+  }
+
+  return MmcCmd == MMC_CMD7 || MmcCmd == MMC_CMD12;
+}
+
+STATIC BOOLEAN
+IsWriteCmd (
+  IN  UINT32 MmcCmd
+  )
+{
+  if (IsAppCmd ()) {
+return FALSE;
+  }
+
+  return MmcCmd == MMC_CMD24 || MmcCmd == MMC_CMD25;
+}
+
+STATIC BOOLEAN
+IsReadCmd (
+  IN  UINT32 MmcCmd,
+  IN  UINT32 Argument
+  )
+{
+  if (MmcCmd == MMC_CMD8 && !IsAppCmd ()) {
+if (Argument == CMD8_MMC_ARG) {
+  DEBUG ((DEBUG_MMCHOST_SD, "Sending MMC CMD8 variant\n"));
+  return TRUE;
+} else {
+  ASSERT (Argument == CMD8_SD_ARG);
+  DEBUG ((DEBUG_MMCHOST_SD, "Sending SD CMD8 variant\n"));
+  return FALSE;
+}
+  }
+
+  return
+(MmcCmd == MMC_CMD6 && !IsAppCmd ()) ||
+(MmcCmd == MMC_CMD17 && !IsAppCmd ()) ||
+(MmcCmd == MMC_CMD18 && !IsAppCmd ()) ||
+(MmcCmd == MMC_CMD13 && IsAppCmd ()) ||
+(MmcCmd == MMC_ACMD22 && IsAppCmd ()) ||
+(MmcCmd == MMC_ACMD51 && IsAppCmd ());
+}
+
+STATIC VOID
+SdHostDumpRegisters (
+  VOID
+  )
+{
+  DEBUG ((DEBUG_MMCHOST_SD, "SdHost: Registers Dump:\n"));
+  DEBUG ((DEBUG_MMCHOST_SD, "  CMD:  0x%8.8X\n", MmioRead32 (SDHOST_CMD)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  ARG:  0x%8.8X\n", MmioRead32 (SDHOST_ARG)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  TOUT: 0x%8.8X\n", MmioRead32 (SDHOST_TOUT)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  CDIV: 0x%8.8X\n", MmioRead32 (SDHOST_CDIV)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  RSP0: 0x%8.8X\n", MmioRead32 (SDHOST_RSP0)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  RSP1: 0x%8.8X\n", MmioRead32 (SDHOST_RSP1)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  RSP2: 0x%8.8X\n", MmioRead32 (SDHOST_RSP2)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  RSP3: 0x%8.8X\n", MmioRead32 (SDHOST_RSP3)));
+  DEBUG ((DEBUG_MMCHOST_SD, "  H

[edk2] [PATCH v4 edk2-platforms 17/23] Platform/Raspberry/Pi3: Add platform boot manager and helper libraries

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Library/PlatformBootManagerLib/PlatformBm.c 
  | 793 
 Platform/Raspberry/Pi3/Library/PlatformBootManagerLib/PlatformBm.h 
  |  60 ++
 
Platform/Raspberry/Pi3/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
 |  90 +++
 Platform/Raspberry/Pi3/Library/PlatformUiAppLib/PlatformUiAppLib.c 
  | 120 +++
 Platform/Raspberry/Pi3/Library/PlatformUiAppLib/PlatformUiAppLib.inf   
  |  34 +
 5 files changed, 1097 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Library/PlatformBootManagerLib/PlatformBm.c 
b/Platform/Raspberry/Pi3/Library/PlatformBootManagerLib/PlatformBm.c
new file mode 100644
index ..9bbe0db64950
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Library/PlatformBootManagerLib/PlatformBm.c
@@ -0,0 +1,793 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Pete Batard 
+ *  Copyright (c) 2017-2018, Andrei Warkentin 
+ *  Copyright (c) 2016, Linaro Ltd. All rights reserved.
+ *  Copyright (c) 2015-2016, Red Hat, Inc.
+ *  Copyright (c) 2014, ARM Ltd. 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
+ *
+ *  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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "PlatformBm.h"
+
+#define BOOT_PROMPT L"ESC (setup), F1 (shell), ENTER (boot)"
+
+#define DP_NODE_LEN(Type) { (UINT8)sizeof (Type), (UINT8)(sizeof (Type) >> 8) }
+
+#pragma pack (1)
+typedef struct {
+  VENDOR_DEVICE_PATH SerialDxe;
+  UART_DEVICE_PATH   Uart;
+  VENDOR_DEFINED_DEVICE_PATH TermType;
+  EFI_DEVICE_PATH_PROTOCOL   End;
+} PLATFORM_SERIAL_CONSOLE;
+#pragma pack ()
+
+typedef struct {
+  VENDOR_DEVICE_PATH Custom;
+  USB_DEVICE_PATHHub;
+  USB_DEVICE_PATHDev;
+  EFI_DEVICE_PATH_PROTOCOL   EndDevicePath;
+} PLATFORM_USB_DEV;
+
+typedef struct {
+  VENDOR_DEVICE_PATH Custom;
+  EFI_DEVICE_PATH_PROTOCOL   EndDevicePath;
+} PLATFORM_SD_DEV;
+
+#define ARASAN_MMC_DXE_FILE_GUID  \
+  { 0x100c2cfa, 0xb586, 0x4198, { 0x9b, 0x4c, 0x16, 0x83, 0xd1, 0x95, 0xb1, 
0xda } }
+
+#define SDHOST_MMC_DXE_FILE_GUID  \
+  { 0x58abd787, 0xf64d, 0x4ca2, { 0xa0, 0x34, 0xb9, 0xac, 0x2d, 0x5a, 0xd0, 
0xcf } }
+
+#define SERIAL_DXE_FILE_GUID  \
+  { 0xD3987D4B, 0x971A, 0x435F, { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 
0x41 } }
+
+STATIC PLATFORM_SD_DEV mArasan = {
+  //
+  // VENDOR_DEVICE_PATH ArasanMMCHostDxe
+  //
+  {
+{ HARDWARE_DEVICE_PATH, HW_VENDOR_DP, DP_NODE_LEN (VENDOR_DEVICE_PATH) },
+ARASAN_MMC_DXE_FILE_GUID
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+STATIC PLATFORM_SD_DEV mSDHost = {
+  //
+  // VENDOR_DEVICE_PATH SdHostDxe
+  //
+  {
+{ HARDWARE_DEVICE_PATH, HW_VENDOR_DP, DP_NODE_LEN (VENDOR_DEVICE_PATH) },
+SDHOST_MMC_DXE_FILE_GUID
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+STATIC PLATFORM_SERIAL_CONSOLE mSerialConsole = {
+  //
+  // VENDOR_DEVICE_PATH SerialDxe
+  //
+  {
+{ HARDWARE_DEVICE_PATH, HW_VENDOR_DP, DP_NODE_LEN (VENDOR_DEVICE_PATH) },
+SERIAL_DXE_FILE_GUID
+  },
+
+  //
+  // UART_DEVICE_PATH Uart
+  //
+  {
+{ MESSAGING_DEVICE_PATH, MSG_UART_DP, DP_NODE_LEN (UART_DEVICE_PATH) },
+0,  // Reserved
+FixedPcdGet64 (PcdUartDefaultBaudRate), // BaudRate
+FixedPcdGet8 (PcdUartDefaultDataBits),  // DataBits
+FixedPcdGet8 (PcdUartDefaultParity),// Parity
+FixedPcdGet8 (PcdUartDefaultStopBits)   // StopBits
+  },
+
+  //
+  // VENDOR_DEFINED_DEVICE_PATH TermType
+  //
+  {
+{
+  MESSAGING_DEVICE_PATH, MSG_VENDOR_DP,
+  DP_NODE_LEN (VENDOR_DEFINED_DEVICE_PATH)
+}
+//
+// Guid to be filled in dynamically
+//
+  },
+
+  //
+  // EFI_DEVICE_PATH_PROTOCOL End
+  //
+  {
+END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
+DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
+  }
+};
+
+
+#pragma pack (1)
+typedef struct {
+  USB_CLASS_DEVICE_PATHKeyboard;
+  EFI_DEVICE_PATH_PROTOCOL End;
+} PLATFORM_USB_KEYBOARD;
+#pragma pack ()
+
+STATIC PLATFORM_USB_KEYBOARD mUsbKeyboard = {
+  //
+  // USB_CLASS_DEVICE_PATH Keyboard
+  //
+  

[edk2] [PATCH v4 edk2-platforms 18/23] Platform/Raspberry/Pi3: Add USB host driver

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/ComponentName.c  |  226 +++
 Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/DriverBinding.c  |  275 
 Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.c   | 1637 

 Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.h   |  165 ++
 Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.inf |   53 +
 Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/DwcHw.h  |  791 ++
 Platform/Raspberry/Pi3/Include/Protocol/DwUsb.h  |   53 +
 7 files changed, 3200 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/ComponentName.c 
b/Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/ComponentName.c
new file mode 100644
index ..0f4db4e21204
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Drivers/DwUsbHostDxe/ComponentName.c
@@ -0,0 +1,226 @@
+/** @file
+ *
+ *  Copyright (c) 2018, Andrey Warkentin 
+ *
+ *
+ *  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 "DwUsbHostDxe.h"
+
+STATIC
+EFI_STATUS
+EFIAPI
+ComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+  OUT CHAR16   **DriverName
+  );
+
+STATIC
+EFI_STATUS
+EFIAPI
+ComponentNameGetControllerName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL *This,
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  EFI_HANDLE  ChildHandle,
+  IN  CHAR8   *Language,
+  OUT CHAR16  **ControllerName
+  );
+
+//
+// EFI Component Name Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME_PROTOCOL gComponentName = {
+  ComponentNameGetDriverName,
+  ComponentNameGetControllerName,
+  "eng"
+};
+
+//
+// EFI Component Name 2 Protocol
+//
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_COMPONENT_NAME2_PROTOCOL gComponentName2 = {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME)ComponentNameGetDriverName,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME)ComponentNameGetControllerName,
+  "en"
+};
+
+
+STATIC EFI_UNICODE_STRING_TABLE mDriverName[] = {
+  {
+"eng;en",
+(CHAR16*)L"Raspberry Pi USB Host Driver"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+STATIC EFI_UNICODE_STRING_TABLE mDeviceName[] = {
+  {
+"eng;en",
+(CHAR16*)L"Raspberry Pi USB Host"
+  },
+  {
+NULL,
+NULL
+  }
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This[in]  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+  @param  Language[in]  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+  @param  DriverName[out]   A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support
+the language specified by Language.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+ComponentNameGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL  *This,
+  IN  CHAR8*Language,
+

[edk2] [PATCH v4 edk2-platforms 19/23] Platform/Raspberry/Pi3: Add platform

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/RPi3.dec |  59 ++
 Platform/Raspberry/Pi3/RPi3.dsc | 637 
 Platform/Raspberry/Pi3/RPi3.fdf | 449 ++
 3 files changed, 1145 insertions(+)

diff --git a/Platform/Raspberry/Pi3/RPi3.dec b/Platform/Raspberry/Pi3/RPi3.dec
new file mode 100644
index ..a4c12e332676
--- /dev/null
+++ b/Platform/Raspberry/Pi3/RPi3.dec
@@ -0,0 +1,59 @@
+## @file
+#
+#  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
+#  Copyright (c) 2017-2018, Andrei Warkentin 
+#
+#  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.
+#
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 0x0001001A
+  PACKAGE_NAME   = RPi3Pkg
+  PACKAGE_GUID   = DFA0CA8B-F3AC-4607-96AC-46FA04B84DCC
+  PACKAGE_VERSION= 1.0
+
+[Includes]
+  Include
+
+[Protocols]
+  gRaspberryPiFirmwareProtocolGuid = { 0x0ACA9535, 0x7AD0, 0x4286, { 0xB0, 
0x2E, 0x87, 0xFA, 0x7E, 0x2A, 0x57, 0x11 } }
+  gRaspberryPiConfigAppliedProtocolGuid = { 0x0ACA, 0x7AD0, 0x4286, { 
0xB0, 0x2E, 0x87, 0xFA, 0x7E, 0x2A, 0x57, 0x11 } }
+  gRaspberryPiMmcHostProtocolGuid = { 0x3e591c00, 0x9e4a, 0x11df, {0x92, 0x44, 
0x00, 0x02, 0xA5, 0xF5, 0xF5, 0x1B } }
+  gExtendedTextOutputProtocolGuid = { 0x387477ff, 0xffc7, 0xffd2, {0x8e, 0x39, 
0x0, 0xff, 0xc9, 0x69, 0x72, 0x3b } }
+
+[Guids]
+  gRaspberryPiTokenSpaceGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 0x63, 
0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}
+  gRaspberryPiFdtFileGuid = {0xDF5DA223, 0x1D27, 0x47C3, { 0x8D, 0x1B, 0x9A, 
0x41, 0xB5, 0x5A, 0x18, 0xBC}}
+  gRaspberryPiEventResetGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 0x63, 
0xB4, 0xB4, 0xE4, 0xD4, 0xB4}}
+  gConfigDxeFormSetGuid = {0xCD7CC258, 0x31DB, 0x22E6, {0x9F, 0x22, 0x63, 
0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}
+
+[PcdsFixedAtBuild.common]
+  gRaspberryPiTokenSpaceGuid.PcdFdtBaseAddress|0x1|UINT32|0x0001
+  gRaspberryPiTokenSpaceGuid.PcdFirmwareBlockSize|0x0|UINT32|0x0002
+  gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogBase|0x0|UINT32|0x0003
+  gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogSize|0x0|UINT32|0x0004
+  gRaspberryPiTokenSpaceGuid.PcdNvStorageVariableBase|0x0|UINT32|0x0005
+  gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwSpareBase|0x0|UINT32|0x0006
+  gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwWorkingBase|0x0|UINT32|0x0007
+  gRaspberryPiTokenSpaceGuid.PcdBootEpochSeconds|0x0|UINT64|0x0008
+
+[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
+  gRaspberryPiTokenSpaceGuid.PcdCpuClock|0|UINT32|0x000d
+  gRaspberryPiTokenSpaceGuid.PcdSdIsArasan|0|UINT32|0x000e
+  gRaspberryPiTokenSpaceGuid.PcdMmcForce1Bit|0|UINT32|0x000f
+  gRaspberryPiTokenSpaceGuid.PcdMmcForceDefaultSpeed|0|UINT32|0x0010
+  gRaspberryPiTokenSpaceGuid.PcdMmcSdDefaultSpeedMHz|0|UINT32|0x0011
+  gRaspberryPiTokenSpaceGuid.PcdMmcSdHighSpeedMHz|0|UINT32|0x0012
+  gRaspberryPiTokenSpaceGuid.PcdMmcDisableMulti|0|UINT32|0x0013
+  gRaspberryPiTokenSpaceGuid.PcdDebugEnableJTAG|0|UINT32|0x0014
+  gRaspberryPiTokenSpaceGuid.PcdDebugShowUEFIExit|0|UINT32|0x0015
+  gRaspberryPiTokenSpaceGuid.PcdDisplayEnableVModes|0|UINT32|0x0017
+  gRaspberryPiTokenSpaceGuid.PcdDisplayEnableSShot|0|UINT32|0x0018
diff --git a/Platform/Raspberry/Pi3/RPi3.dsc b/Platform/Raspberry/Pi3/RPi3.dsc
new file mode 100644
index ..4d43363e433d
--- /dev/null
+++ b/Platform/Raspberry/Pi3/RPi3.dsc
@@ -0,0 +1,637 @@
+# @file
+#
+#  Copyright (c) 2011-2015, ARM Limited. All rights reserved.
+#  Copyright (c) 2014, Linaro Limited. All rights reserved.
+#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2017 - 2018, Andrei Warkentin 
+#
+#  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.
+#
+##
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = RPi3
+  PLATFORM_GUID  = 5d30c4fc-93cf-40c9-8486-3badc0410816
+  PLA

[edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/Readme.md | 259 
 Readme.md|   3 +
 2 files changed, 262 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Readme.md b/Platform/Raspberry/Pi3/Readme.md
new file mode 100644
index ..7fb59ccdc321
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Readme.md
@@ -0,0 +1,259 @@
+Raspberry Pi 3 EDK2 Platform Support
+
+
+# Summary
+
+This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi 3/3B+ 
platforms,
+based on [Ard Bisheuvel's 
64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/)
+and [Microsoft's 
32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg)
+implementations, as maintained by [Andrei 
Warkentin](https://github.com/andreiw/RaspberryPiPkg).
+
+This is meant as a generally useful 64-bit ATF + UEFI implementation for the 
Raspberry
+Pi 3/3B+ which should be good enough for most kind of UEFI development, as 
well as for
+running consummer Operating Systems in such as Linux or Windows.
+
+Raspberry Pi is a trademark of the [Raspberry Pi 
Foundation](http://www.raspberrypi.org).
+
+# Status
+
+This firmware, that has been validated to compile against the current
+[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
+should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as 
Windows 10 ARM64
+(full GUI version).
+
+It also provides support for ATF ([Arm Trusted 
Platform](https://github.com/ARM-software/arm-trusted-firmware)).
+
+HDMI and the mini-UART serial port can be used for output devices, with 
mirrored output.
+USB keyboards and the mini-UART serial port can be used as input.
+
+The boot order is currently hardcoded, first to the USB ports and then to the 
uSD card.
+If there no bootable media media is found, the UEFI Shell is launched.
+Esc enters platform setup. F1 boots the UEFI Shell.
+
+# Building
+
+(These instructions were validated against the latest edk2 / edk2-platforms /
+edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system).
+
+You may need to install the relevant compilation tools. Especially you should 
have the
+ACPI Source Language (ASL) compiler, `nasm` as well as a native compiler 
installed.
+On a Debian system, you can get these prerequisites installed with:
+```
+sudo apt-get install build-essential acpica-tools nasm uuid-dev
+```
+
+**IMPORTANT:** We recommend the use of the Linaro GCC for compilation instead 
of
+your system's native ARM64 GCC cross compiler.
+
+You can then build the firmware as follows:
+
+* Standalone instructions
+
+```
+mkdir ~/workspace
+cd ~/workspace
+git clone https://github.com/tianocore/edk2.git
+# The following is only needed once, after you cloned edk2
+make -C edk2/BaseTools
+git clone https://github.com/tianocore/edk2-platforms.git
+git clone https://github.com/tianocore/edk2-non-osi.git
+wget 
https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02/aarch64-linux-gnu/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz
+tar -xJvf gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu.tar.xz
+# If you have multiple AARCH64 toolchains, make sure the above one comes first 
in your path
+export PATH=$PWD/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin:$PATH
+export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
+export WORKSPACE=$PWD
+export 
PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
+. edk2/edksetup.sh
+build -a AARCH64 -t GCC5 -p edk2-platforms/Platform/Raspberry/Pi3/RPi3.dsc 
-DBUILD_EPOCH=`date +%s` -b RELEASE
+```
+
+# Booting the firmware
+
+1. Format a uSD card as FAT32
+2. Copy the generated `RPI_EFI.fd` firmware onto the partition
+3. Download and copy the following files from 
https://github.com/raspberrypi/firmware/tree/master/boot
+  - `bootcode.bin`
+  - `fixup.dat`
+  - `start.elf`
+4. Create a `config.txt` with the following content:
+  ```
+  arm_control=0x200
+  enable_uart=1
+  armstub=RPI_EFI.fd
+  disable_commandline_tags=1
+  ```
+5. Insert the uSD card and power up the Pi.
+
+Note that if you have a model 3+ or a model 3 where you enabled USB boot 
through OTP
+(see 
[here](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md))
+you may also be able to boot from a FAT32 USB driver rather than uSD.
+
+# Notes
+
+## ARM Trusted Firmware (ATF)
+
+The ATF binaries being used were compiled from the ATF mainline.
+
+For more details on the ATF compilation, see the [README](./Binary/README.md) 
in the `Binary/` directory.
+
+## Custom Device Tree
+
+The default Device Tree included in the firmware is the one for a Raspberry Pi 
3 Model B (not B+).
+If you want to use a different Device Tree, to boot a Pi 3 Model B+ for 
instance (for which a
+DTB is also provided under `DeviceTree/`), you should copy the relevant `.dtb` 
into the root of
+the SD or USB, and then

[edk2] [PATCH v4 edk2-platforms 21/23] Platform/Raspberry/Pi3 *NON-OSI*: Add ATF binaries

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/TrustedFirmware/License.txt |  26 
 Platform/Raspberry/Pi3/TrustedFirmware/README.md   |  42 
 Platform/Raspberry/Pi3/TrustedFirmware/bl1.bin | Bin 0 -> 18801 bytes
 Platform/Raspberry/Pi3/TrustedFirmware/fip.bin | Bin 0 -> 41714 bytes
 4 files changed, 68 insertions(+)

diff --git a/Platform/Raspberry/Pi3/TrustedFirmware/License.txt 
b/Platform/Raspberry/Pi3/TrustedFirmware/License.txt
new file mode 100644
index ..b98dc643227e
--- /dev/null
+++ b/Platform/Raspberry/Pi3/TrustedFirmware/License.txt
@@ -0,0 +1,26 @@
+Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without 
modification,
+are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice, 
this
+  list of conditions and the following disclaimer in the documentation and/or
+  other materials provided with the distribution.
+
+* Neither the name of ARM nor the names of its contributors may be used to
+  endorse or promote products derived from this software without specific prior
+  written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 
FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/Platform/Raspberry/Pi3/TrustedFirmware/README.md 
b/Platform/Raspberry/Pi3/TrustedFirmware/README.md
new file mode 100644
index ..862933f6f2ba
--- /dev/null
+++ b/Platform/Raspberry/Pi3/TrustedFirmware/README.md
@@ -0,0 +1,42 @@
+ARM Trusted Firmware for Raspberry Pi 3
+===
+
+The `bl1` and `fip` ATF binaries, found in this directory, were built from
+the [latest ATF](https://github.com/ARM-software/arm-trusted-firmware)
+(commit c3859557) using Linaro's GCC 5.5 compiler with:
+
+```
+export 
CROSS_COMPILE=/usr/src/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
+make PLAT=rpi3 PRELOADED_BL33_BASE=0x3 RPI3_PRELOADED_DTB_BASE=0x1 
SUPPORT_VFP=1 RPI3_USE_UEFI_MAP=1 fip all
+```
+
+This results in the following memory mapping:
+
+```
+0x +-+
+   |   ROM   | BL1
+0x0001 +-+
+   |   DTB   | (Loaded by the VideoCore)
+0x0002 +-+
+   |   FIP   |
+0x0003 +-+
+   | |
+   |  UEFI PAYLOAD   |
+   | |
+0x0020 +-+
+   |   Secure SRAM   | BL2, BL31
+0x0030 +-+
+   |   Secure DRAM   | BL32 (Secure payload)
+0x0040 +-+
+   | |
+   | |
+   | Non-secure DRAM | BL33
+   | |
+   | |
+0x0100 +-+
+   | |
+   |   ...   |
+   | |
+0x3F00 +-+
+   |   I/O   |
+```
diff --git a/Platform/Raspberry/Pi3/TrustedFirmware/bl1.bin 
b/Platform/Raspberry/Pi3/TrustedFirmware/bl1.bin
new file mode 100644
index 
..e25138828d0a4ddb24772abb1a60eefc334666b5
GIT binary patch
literal 18801
zcmeHud2|%#mG7;pmedFVtpy|tJ-S*z4DF582<)+{TLO%YF^IMyw%@2*ivhC;Enpe2
zRTADp&Ya2NoOkF$@l}1x-M+hhw@Q@U820D96C>N0$f-gpvNVO-6r%k^_LFjhV53f>
zzYYB^p(#wZhayBm(40?m)v%ZRF-jkU{?@RJdpUDVq_0@Qvl>>=KM8BSMAN6D9c2X^
zv}!gTC9-IZXdThl_aE5oz6A)Ol0}J=O^M4yanPmrUEBE6z%_}qi$f`XQKFzu
zlVZ_?G$rnX41{DgYzORyWMj?6p-TMP#*g+gylWdj3`8X%sIOlv1lmB)R$NV@Mf2q+
zY4d>}JWrcSYDNxGR%4SA-?^DI?>kETG0>;<^-cF@D)C*r!0X4PiJ}^Q9sQugsR%T^
zW2zF8L8m(ZKusahN`})&mx1t%~~5>0PQR^krEJ6wr3iAo6aZSmWc_!Ag6
z`56X&xUWmf4DJH$r=?NBrxUaj_-e#D|7a!d7m4LPR23=2^S_NbBGxi5Ce4?hcK6f$
z3TXVu>I#)XZeBsnU^%~vzTYcJS`*qLzY-q@C2Lj%?d)EP7gLhfKy+cZh2moYa~$X{
zx3%XUwhAHXdf#-#Z|vK6?76XLKQ{Io`^9@z>$YethdSW8QZ5C&;8{(g13fpB7t2Z#
zv}wTee+aU&&~*P;CC>ZC@)`!-q9RS70s5}E1#N

[edk2] [PATCH v4 edk2-platforms 22/23] Platform/Raspberry/Pi3 *NON-OSI*: Add Device Tree binaries

[Pete Batard]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
 Platform/Raspberry/Pi3/DeviceTree/License.txt  |  340 ++
 Platform/Raspberry/Pi3/DeviceTree/bcm2710-rpi-3-b-plus.dtb |  Bin 0 -> 25617 
bytes
 Platform/Raspberry/Pi3/DeviceTree/bcm2710-rpi-3-b-plus.dts | 1263 

 Platform/Raspberry/Pi3/DeviceTree/bcm2710-rpi-3-b.dtb  |  Bin 0 -> 25354 
bytes
 Platform/Raspberry/Pi3/DeviceTree/bcm2710-rpi-3-b.dts  | 1259 
+++
 5 files changed, 2862 insertions(+)

diff --git a/Platform/Raspberry/Pi3/DeviceTree/License.txt 
b/Platform/Raspberry/Pi3/DeviceTree/License.txt
new file mode 100644
index ..1603937dad82
--- /dev/null
+++ b/Platform/Raspberry/Pi3/DeviceTree/License.txt
@@ -0,0 +1,340 @@
+GNU GENERAL PUBLIC LICENSE
+   Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+   51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you rece

Re: [edk2] [PATCH v4 edk2-platforms 00/23] Platform/Raspberry: Add Raspberry Pi 3 support

[Ard Biesheuvel]

Hi Pete,

On Tue, 29 Jan 2019 at 17:27, Pete Batard  wrote:
>
> Changes applied to v4:
>
> * Silicon/Broadcom/Include has been moved to Silicon/Broadcom/Bcm283x/Include.
>   The [Packages] and [Includes] directives were also updated accordingly.
> * Move the GpioLib function declarations into their own separate header.
> * Add NOOPT to BUILD_TARGETS.
> * Remove the no longer needed '-mcmodel=small' workaround from AcpiTables.
>
> Changes not applied to v4:
>
> * Ensure that all the ACPI tables _CID names, and the rest of the tables, are
>   ACPI specs compliant, since we are constrained with regards to their usage
>   for Microsoft Windows.
>

I managed to build and run a RELEASE image, and I must say, I'm
impressed. It works really well, and looks really slick too. Thanks a
lot for taking the time to upstream this, it makes the RPI3 a lot more
usable for people that want to run a generic distro.

So

Tested-by: Ard Biesheuvel 

I'll give others some time to respond before proceeding.

>
> Preamble:
>
> Because of its price point, ease of use and availability, the Raspberry Pi is
> undeniably one of the most successful ARM platform in existence today. Its
> widespread adoption therefore makes it a perfect fit as an EDK2 platform.
>
> However, up until now, the Raspberry Pi hasn't been supported as a bona fide
> platform in our repository. This series of patches remedies that by 
> introducing
> the Raspberry Pi 3 Model B and Model B+ as a viable EDK2 platform.
>
> Notes regarding non-OSI content:
>
> * Even though the ARM Trusted Firmware binary blobs are subject to a
>   BSD-3-Clause licence, which may be compatible with the EDK2 one, we chose
>   to follow the lead of other platforms that provide ATF binaries in non OSI.
>   Ultimately, once there is a new dot release of ATF, we plan to remove these
>   binaries and point to a dot release build configuartion.
> * The Device Tree binaries (and source descriptors) are subject to a GPLv2
>   license, as per the ones published by the Raspberry Pi Foundation.
> * The Logo source code is under an EDK2 license, but the logo itself, which
>   we obtained authorisation to use from the Raspberry Pi Foundation itself
>   after detailing our planned usage, is subject to the trademark licensing
>   terms put forward by the Foundation.
>
> Additional Notes:
>
> * Detailed instructions on how to build and test the platform firmware are
>   included in the Readme.md found at the root of the platform.
> * As detailed in the Readme, the resulting platform firmware has been
>   successfully used to install and run Linux OSes, such as Ubuntu 18.10, as
>   well as Windows 10 1809 (*full* UI version, not IoT).
>
> Regards,
>
> /Pete
>
> Pete Batard (23):
>   Silicon/Broadcom/Bcm282x: Add interrupt driver
>   Silicon/Broadcom/Bcm283x: Add GpioLib
>   Platform/Raspberry/Pi3: Add ACPI tables
>   Platform/Raspberry/Pi3: Add reset and memory init libraries
>   Platform/Raspberry/Pi3: Add platform library
>   Platform/Raspberry/Pi3: Add RTC library
>   Platform/Raspberry/Pi3: Add firmware driver
>   Platform/Raspberry/Pi3: Add platform config driver
>   Platform/Raspberry/Pi3: Add SMBIOS driver
>   Platform/Raspberry/Pi3: Add display driver
>   Platform/Raspberry/Pi3: Add console driver
>   Platform/Raspberry/Pi3: Add NV storage driver
>   Platform/Raspberry/Pi3: Add Device Tree driver
>   Platform/Raspberry/Pi3: Add base MMC driver
>   Platform/Raspberry/Pi3: Add Arasan MMC driver
>   Platform/Raspberry/Pi3: Platform/Raspberry/Pi3: Add SD Host driver
>   Platform/Raspberry/Pi3: Add platform boot manager and helper libraries
>   Platform/Raspberry/Pi3: Add USB host driver
>   Platform/Raspberry/Pi3: Add platform
>   Platform/Raspberry/Pi3: Add platform readme
>   Platform/Raspberry/Pi3 *NON-OSI*: Add ATF binaries
>   Platform/Raspberry/Pi3 *NON-OSI*: Add Device Tree binaries
>   Platform/Raspberry/Pi3 *NON-OSI*: Add logo driver
>
>  .../Raspberry/Pi3/AcpiTables/AcpiTables.h |   82 +
>  .../Raspberry/Pi3/AcpiTables/AcpiTables.inf   |   46 +
>  Platform/Raspberry/Pi3/AcpiTables/Csrt.aslc   |  332 +++
>  Platform/Raspberry/Pi3/AcpiTables/Dbg2.aslc   |   34 +
>  Platform/Raspberry/Pi3/AcpiTables/Dsdt.asl|  511 +
>  Platform/Raspberry/Pi3/AcpiTables/Fadt.aslc   |   52 +
>  Platform/Raspberry/Pi3/AcpiTables/Gtdt.aslc   |   33 +
>  Platform/Raspberry/Pi3/AcpiTables/Madt.aslc   |   62 +
>  Platform/Raspberry/Pi3/AcpiTables/Pep.asl |   95 +
>  Platform/Raspberry/Pi3/AcpiTables/Pep.c   |   84 +
>  Platform/Raspberry/Pi3/AcpiTables/Pep.h   |  126 ++
>  Platform/Raspberry/Pi3/AcpiTables/Rhpx.asl|  201 ++
>  Platform/Raspberry/Pi3/AcpiTables/Sdhc.asl|  105 +
>  Platform/Raspberry/Pi3/AcpiTables/Spcr.asl|   53 +
>  Platform/Raspberry/Pi3/AcpiTables/Uart.asl|  158 ++
>  Platform/Raspberry/Pi3/DeviceTree/License.txt |  340 +++
>  .../Pi3/DeviceTree/bcm2710-rpi-3-b-plus.dtb   |  Bin 0 -> 25617 bytes
>  .../Pi3/DeviceTree/bcm2710-rpi-3-b-plus.dts   | 1263 

[edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if reloc info is invalid

[Neo Hsueh]

Skip runtime relocation for PE images that provide invalid relocation
infomation (ex: RelocDir->Size = 0) to fix a hang observed while booting
Windows.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Neo Hsueh 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Laszlo Ersek 
---
 MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c 
b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
index 1bd079ad6a..3a46e626e4 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
@@ -1002,7 +1002,7 @@ PeCoffLoaderRelocateImage (
 
RelocDir->VirtualAddress + RelocDir->Size - 1,
 
TeStrippedOffset
 );
-if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd < RelocBase) 
{
+if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd < 
(UINTN) RelocBase) {
   ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
   return RETURN_LOAD_ERROR;
 }
@@ -1022,7 +1022,7 @@ PeCoffLoaderRelocateImage (
 // Run the relocation information and apply the fixups
 //
 FixupData = ImageContext->FixupData;
-while (RelocBase < RelocBaseEnd) {
+while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
 
   Reloc = (UINT16 *) ((CHAR8 *) RelocBase + sizeof 
(EFI_IMAGE_BASE_RELOCATION));
   //
@@ -1051,7 +1051,7 @@ PeCoffLoaderRelocateImage (
   //
   // Run this relocation record
   //
-  while (Reloc < RelocEnd) {
+  while ((UINTN) Reloc < (UINTN) RelocEnd) {
 Fixup = PeCoffLoaderImageAddress (ImageContext, 
RelocBase->VirtualAddress + (*Reloc & 0xFFF), TeStrippedOffset);
 if (Fixup == NULL) {
   ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
@@ -1741,11 +1741,19 @@ PeCoffLoaderRelocateImageForRuntime (
   //
   if (NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC) {
 RelocDir  = DataDirectory + EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC;
-RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext, RelocDir->VirtualAddress, 0);
-RelocBaseEnd  = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext,
-
RelocDir->VirtualAddress + RelocDir->Size - 1,
-0
-);
+if ((RelocDir != NULL) && (RelocDir->Size > 0)) {
+  RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext, RelocDir->VirtualAddress, 0);
+  RelocBaseEnd  = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext,
+  
RelocDir->VirtualAddress + RelocDir->Size - 1,
+  0
+  
);
+}
+if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd < 
(UINTN) RelocBase) {
+  //
+  // relocation block is not valid, just return
+  //
+  return;
+}
   } else {
 //
 // Cannot find relocations, cannot continue to relocate the image, ASSERT 
for this invalid image.
@@ -1769,7 +1777,7 @@ PeCoffLoaderRelocateImageForRuntime (
 //
 FixupData = RelocationData;
 RelocBaseOrig = RelocBase;
-while (RelocBase < RelocBaseEnd) {
+while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
   //
   // Add check for RelocBase->SizeOfBlock field.
   //
@@ -1794,7 +1802,7 @@ PeCoffLoaderRelocateImageForRuntime (
   //
   // Run this relocation record
   //
-  while (Reloc < RelocEnd) {
+  while ((UINTN) Reloc < (UINTN) RelocEnd) {
 
 Fixup = PeCoffLoaderImageAddress (&ImageContext, 
RelocBase->VirtualAddress + (*Reloc & 0xFFF), 0);
 if (Fixup == NULL) {
-- 
2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Fmp Payload Header Usage

[Ashish Singhal]

Hello Michael/Liming,

I am trying to use FmpDevicePkg for FMP based capsule update and am failing in 
FmpPayloadHeaderLib while verifying FMP payload header. I am building capsule 
and payload using FDF file itself and not calling Capsule tools explicitly from 
basetools. Is there a special build flag I need to provide to add FMP payload 
header to my payload?

Thanks
Ashish

---
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 v4 edk2-platforms 00/23] Platform/Raspberry: Add Raspberry Pi 3 support

[Pete Batard]

On 2019.01.29 17:40, Ard Biesheuvel wrote:

I managed to build and run a RELEASE image, and I must say, I'm
impressed. It works really well, and looks really slick too. Thanks a
lot for taking the time to upstream this, it makes the RPI3 a lot more
usable for people that want to run a generic distro.


I'm very happy to hear that.

Indeed, our hope is that, once the firmware gets "officialized" into 
edk2-platforms, mainline Linux distros will switch to using its 
facilities and make the whole Linux boot process a friendlier/more 
familiar experience for Pi3 users.


Of course, you have to thank Andrei Warkentin for this nice outcome, 
since he put a lot of effort into it, as well as all the people who 
contributed to the firmware (including Linaro & Microsoft).



Tested-by: Ard Biesheuvel 


Many thanks for this.

/Pete
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Fmp Payload Header Usage

[Kinney, Michael D]

Hi Ashish,

You do need to use the standalone tool called GenerateCapsule to convert
a payload to a UEFI Capsule.

Here is an example:

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/Feature/Capsule/GenerateCapsule/GenCapsuleMinnowMax.bat

You can customize this script for your platform.  This script is for
dev/debug purposes only for use on a local dev system.  It supports
different keys and tools to generate a UEFI Capsule.  You can simplify
it for a specific tool/key option.

You can integrate this into the standard build process by adding a
script to the DSC file as a post build step.

https://github.com/tianocore/edk2/blob/master/Vlv2TbltDevicePkg/PlatformCapsule.dsc

  POSTBUILD = 
Vlv2TbltDevicePkg/Feature/Capsule/GenerateCapsule/GenCapsuleAll.bat

This specific platform has some extra steps that need to be 
performed after the normal build of the FW image before the capsule
is generated, so a 2nd DSC/FDF file is used.  If you do not have 
any extra steps, then you can add the POSTBUILD statement to the
[Defines] section of your platform DSC file.

Best regards,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Ashish Singhal
> Sent: Tuesday, January 29, 2019 1:09 PM
> To: Gao, Liming ; Kinney, Michael
> D 
> Cc: edk2-devel@lists.01.org
> Subject: [edk2] Fmp Payload Header Usage
> 
> Hello Michael/Liming,
> 
> I am trying to use FmpDevicePkg for FMP based capsule
> update and am failing in FmpPayloadHeaderLib while
> verifying FMP payload header. I am building capsule and
> payload using FDF file itself and not calling Capsule
> tools explicitly from basetools. Is there a special
> build flag I need to provide to add FMP payload header
> to my payload?
> 
> Thanks
> Ashish
> 
> 
> ---
> 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Peripheral FW capsule delivery?

[Brad Bozarth]

Hi!

I am implementing firmware for a touchpad that will be going into a laptop,
connected via i2c. We would like to take advantage of the UEFI firmware
capsule delivery method for firmware updates if possible. I am struggling
to find out how to do this. In particular, I'd like to know whether there
is a "standard" delivery mechanism we can take advantage of and communicate
with from the firmware side over i2c, or if we need to write UEFI driver
code of some sort to pass the update down. We'd love to leverage a standard
pipe that dumps an update over i2c if possible and implement what we need
to on the firmware side. We are supplying our touchpad to the laptop OEM
and they are distant and have their own software teams, so if we need to
write UEFI code, it complicates matters!

This is the page that I'd love to read, if it were filled out :)
https://github.com/mdkinney/edk2/wiki/Capsule-Based-Device-Firmware-Update

Thank you!
Brad
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] CryptoPkg/BaseCryptLib: split CryptPkcs7Verify.c on behalf of runtime

[Ye, Ting]

Looks good to me.

Reviewed-by: Ye Ting  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Monday, January 28, 2019 4:38 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Long, Qin 
Subject: [edk2] [PATCH] CryptoPkg/BaseCryptLib: split CryptPkcs7Verify.c on 
behalf of runtime

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1493

Pkcs7GetAttachedContent() implementation in current CryptPkcs7Verify.c is 
actually shared by RuntimeCryptLib.inf, SmmCryptLib.inf and BaseCryptLib.inf, 
which are not correct since there's no use scenario for runtime and 
AllocatePool() used in this method can only be called in boot time.

This patch fix this issue by splitting file CryptPkcs7Verify.c into 3 parts.

  CryptPkcs7VerifyCommon.c  (shared among Base, SMM, Runtime)
  CryptPkcs7VerifyBase.c(shared between Base, SMM)
  CryptPkcs7VerifyRuntime.c (for Runtime only)

CryptPkcs7VerifyBase.c will have original implementation of
Pkcs7GetAttachedContent() as CryptPkcs7Verify.c. CryptPkcs7VerifyRuntime.c 
provide a NULL version of Pkcs7GetAttachedContent().

No functionality and interface change is involved in this patch.

Cc: Ting Ye 
Cc: Qin Long 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 .../Library/BaseCryptLib/BaseCryptLib.inf |   5 +-
 .../Library/BaseCryptLib/InternalCryptLib.h   |  32 +
 .../Library/BaseCryptLib/PeiCryptLib.inf  |   3 +-
 .../BaseCryptLib/Pk/CryptPkcs7VerifyBase.c| 131 ++
 ...Pkcs7Verify.c => CryptPkcs7VerifyCommon.c} | 112 +--  
.../BaseCryptLib/Pk/CryptPkcs7VerifyRuntime.c |  45 ++
 .../Library/BaseCryptLib/RuntimeCryptLib.inf  |   6 +-
 .../Library/BaseCryptLib/SmmCryptLib.inf  |   5 +-
 8 files changed, 220 insertions(+), 119 deletions(-)  create mode 100644 
CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyBase.c
 rename CryptoPkg/Library/BaseCryptLib/Pk/{CryptPkcs7Verify.c => 
CryptPkcs7VerifyCommon.c} (85%)  create mode 100644 
CryptoPkg/Library/BaseCryptLib/Pk/CryptPkcs7VerifyRuntime.c

diff --git a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf 
b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
index f29445ce34..c5558eedb7 100644
--- a/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
+++ b/CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -6,7 +6,7 @@
 #  This external input must be validated carefully to avoid security issues 
such as  #  buffer overflow or integer overflow.
 #
-#  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2009 - 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 @@ 
-49,7 +49,8 @@
   Pk/CryptRsaExt.c
   Pk/CryptPkcs5Pbkdf2.c
   Pk/CryptPkcs7Sign.c
-  Pk/CryptPkcs7Verify.c
+  Pk/CryptPkcs7VerifyCommon.c
+  Pk/CryptPkcs7VerifyBase.c
   Pk/CryptDh.c
   Pk/CryptX509.c
   Pk/CryptAuthenticode.c
diff --git a/CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h 
b/CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h
index 8cccf72567..026793f664 100644
--- a/CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h
+++ b/CryptoPkg/Library/BaseCryptLib/InternalCryptLib.h
@@ -33,4 +33,36 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define OBJ_length(o) ((o)->length)
 #endif
 
+/**
+  Check input P7Data is a wrapped ContentInfo structure or not. If not 
+construct
+  a new structure to wrap P7Data.
+
+  Caution: This function may receive untrusted input.
+  UEFI Authenticated Variable is external input, so this function will 
+ do basic  check for PKCS#7 data structure.
+
+  @param[in]  P7Data   Pointer to the PKCS#7 message to verify.
+  @param[in]  P7Length Length of the PKCS#7 message in bytes.
+  @param[out] WrapFlag If TRUE P7Data is a ContentInfo structure, otherwise
+   return FALSE.
+  @param[out] WrapData If return status of this function is TRUE:
+   1) when WrapFlag is TRUE, pointer to P7Data.
+   2) when WrapFlag is FALSE, pointer to a new 
ContentInfo
+   structure. It's caller's responsibility to free this
+   buffer.
+  @param[out] WrapDataSize Length of ContentInfo structure in bytes.
+
+  @retval TRUE The operation is finished successfully.
+  @retval FALSEThe operation is failed due to lack of resources.
+
+**/
+BOOLEAN
+WrapPkcs7Data (
+  IN  CONST UINT8  *P7Data,
+  IN  UINTNP7Length,
+  OUT BOOLEAN  *WrapFlag,
+  OUT UINT8**WrapData,
+  OUT UINTN*WrapDataSize
+  );
+
 #endif
diff --git a/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf 
b/CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf
index e7b4b2f618..386810e442 100644
--- a/Cryp

Re: [edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if relocation info is invalid.

[Hsueh, Hong-chihX]

Hi Laszlo & Dandan,
Here is the updated patch for your review. Thank you!
https://lists.01.org/pipermail/edk2-devel/2019-January/035954.html

Regards,
Neo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, January 29, 2019 2:57 AM
> To: Hsueh, Hong-chihX ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> ; Bi, Dandan 
> Subject: Re: [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if
> relocation info is invalid.
> 
> On 01/29/19 00:22, Neo Hsueh wrote:
> > Skip runtime relocation for PE images that provide invalid relocation
> > infomation
> > (ex: RelocDir->Size = 0) to fix a hang observed while booting Windows.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> >
> > Signed-off-by: Neo Hsueh 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Dandan Bi 
> > Cc: Laszlo Ersek 
> > ---
> >  MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 16 +++-
> >  1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> > b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> > index 1bd079ad6a..6d6c37bd61 100644
> > --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> > +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> > @@ -1002,7 +1002,7 @@ PeCoffLoaderRelocateImage (
> > 
> >  RelocDir->VirtualAddress +
> RelocDir->Size - 1,
> > 
> >  TeStrippedOffset
> > 
> >  );
> > -if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd <
> RelocBase) {
> > +if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN)
> > + RelocBaseEnd < (UINTN) RelocBase) {
> >ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
> >return RETURN_LOAD_ERROR;
> >  }
> > @@ -1022,7 +1022,7 @@ PeCoffLoaderRelocateImage (
> >  // Run the relocation information and apply the fixups
> >  //
> >  FixupData = ImageContext->FixupData;
> > -while (RelocBase < RelocBaseEnd) {
> > +while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
> >
> >Reloc = (UINT16 *) ((CHAR8 *) RelocBase + sizeof
> (EFI_IMAGE_BASE_RELOCATION));
> >//
> > @@ -1051,7 +1051,7 @@ PeCoffLoaderRelocateImage (
> >//
> >// Run this relocation record
> >//
> > -  while (Reloc < RelocEnd) {
> > +  while ((UINTN) Reloc < (UINTN) RelocEnd) {
> >  Fixup = PeCoffLoaderImageAddress (ImageContext, RelocBase-
> >VirtualAddress + (*Reloc & 0xFFF), TeStrippedOffset);
> >  if (Fixup == NULL) {
> >ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
> > @@ -1746,6 +1746,12 @@ PeCoffLoaderRelocateImageForRuntime (
> > 
> >  RelocDir->VirtualAddress +
> RelocDir->Size - 1,
> > 
> >  0
> >
> > );
> > +if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd
> < (UINTN) RelocBase) {
> > +  //
> > +  // relocation block is not valid, just return
> > +  //
> > +  return;
> > +}
> >} else {
> >  //
> >  // Cannot find relocations, cannot continue to relocate the image, 
> > ASSERT
> for this invalid image.
> > @@ -1769,7 +1775,7 @@ PeCoffLoaderRelocateImageForRuntime (
> >  //
> >  FixupData = RelocationData;
> >  RelocBaseOrig = RelocBase;
> > -while (RelocBase < RelocBaseEnd) {
> > +while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
> >//
> >// Add check for RelocBase->SizeOfBlock field.
> >//
> > @@ -1794,7 +1800,7 @@ PeCoffLoaderRelocateImageForRuntime (
> >//
> >// Run this relocation record
> >//
> > -  while (Reloc < RelocEnd) {
> > +  while ((UINTN) Reloc < (UINTN) RelocEnd) {
> >
> >  Fixup = PeCoffLoaderImageAddress (&ImageContext, RelocBase-
> >VirtualAddress + (*Reloc & 0xFFF), 0);
> >  if (Fixup == NULL) {
> >
> 
> I think this patch is good enough, but it seems to miss the size==0 check that
> Dandan asked for.
> 
> Thanks,
> laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if reloc info is invalid

[Neo Hsueh]

Skip runtime relocation for PE images that provide invalid relocation
infomation (ex: RelocDir->Size = 0) to fix a hang observed while booting
Windows.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Neo Hsueh 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Laszlo Ersek 
---
 MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c 
b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
index 1bd079ad6a..e2c62e1932 100644
--- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
+++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
@@ -1002,7 +1002,7 @@ PeCoffLoaderRelocateImage (
 
RelocDir->VirtualAddress + RelocDir->Size - 1,
 
TeStrippedOffset
 );
-if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd < RelocBase) 
{
+if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd < 
(UINTN) RelocBase) {
   ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
   return RETURN_LOAD_ERROR;
 }
@@ -1022,7 +1022,7 @@ PeCoffLoaderRelocateImage (
 // Run the relocation information and apply the fixups
 //
 FixupData = ImageContext->FixupData;
-while (RelocBase < RelocBaseEnd) {
+while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
 
   Reloc = (UINT16 *) ((CHAR8 *) RelocBase + sizeof 
(EFI_IMAGE_BASE_RELOCATION));
   //
@@ -1051,7 +1051,7 @@ PeCoffLoaderRelocateImage (
   //
   // Run this relocation record
   //
-  while (Reloc < RelocEnd) {
+  while ((UINTN) Reloc < (UINTN) RelocEnd) {
 Fixup = PeCoffLoaderImageAddress (ImageContext, 
RelocBase->VirtualAddress + (*Reloc & 0xFFF), TeStrippedOffset);
 if (Fixup == NULL) {
   ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
@@ -1739,13 +1739,23 @@ PeCoffLoaderRelocateImageForRuntime (
   // is present in the image. You have to check the NumberOfRvaAndSizes in
   // the optional header to verify a desired directory entry is there.
   //
+  RelocBase = NULL;
+  RelocBaseEnd = NULL;
   if (NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC) {
 RelocDir  = DataDirectory + EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC;
-RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext, RelocDir->VirtualAddress, 0);
-RelocBaseEnd  = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext,
-
RelocDir->VirtualAddress + RelocDir->Size - 1,
-0
-);
+if ((RelocDir != NULL) && (RelocDir->Size > 0)) {
+  RelocBase = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext, RelocDir->VirtualAddress, 0);
+  RelocBaseEnd  = (EFI_IMAGE_BASE_RELOCATION *) PeCoffLoaderImageAddress 
(&ImageContext,
+  
RelocDir->VirtualAddress + RelocDir->Size - 1,
+  0
+  
);
+}
+if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd < 
(UINTN) RelocBase) {
+  //
+  // relocation block is not valid, just return
+  //
+  return;
+}
   } else {
 //
 // Cannot find relocations, cannot continue to relocate the image, ASSERT 
for this invalid image.
@@ -1769,7 +1779,7 @@ PeCoffLoaderRelocateImageForRuntime (
 //
 FixupData = RelocationData;
 RelocBaseOrig = RelocBase;
-while (RelocBase < RelocBaseEnd) {
+while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
   //
   // Add check for RelocBase->SizeOfBlock field.
   //
@@ -1794,7 +1804,7 @@ PeCoffLoaderRelocateImageForRuntime (
   //
   // Run this relocation record
   //
-  while (Reloc < RelocEnd) {
+  while ((UINTN) Reloc < (UINTN) RelocEnd) {
 
 Fixup = PeCoffLoaderImageAddress (&ImageContext, 
RelocBase->VirtualAddress + (*Reloc & 0xFFF), 0);
 if (Fixup == NULL) {
-- 
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 v2 00/33] BaseTools python3 migration patch set

[Gao, Liming]

Laszlo:
 I agree your proposal. Push this patch set first if no other comments, then 
continue to do minor bug fix. 
 
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
> Ersek
> Sent: Tuesday, January 29, 2019 9:07 PM
> To: Feng, Bob C 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set
> 
> Hi Bob,
> 
> On 01/29/19 03:05, Feng, Bob C wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=55
> >
> > V2:
> > The python files under CParser4 folder of ECC/Eot tool
> > are generated by antlr4 and forpython3 usage.
> > They have python3 specific syntax, for example
> > the data type declaration for the arguments of a function. That
> > is not compitable with python2. this patch is to remove these syntax.
> >
> > The version2 patch set is commit to https://github.com/BobCF/edk2.git
> > branch py3basetools_v2
> 
> (reusing the "test plan" from my email at
> http://mid.mail-archive.com/cab4fed6-4c5d-94a9-b29f-da41ad7f320e@redhat.com>:)
> 
> I ran the following tests, at commit 6edb6bd9f182 ("BaseTools: Eot tool
> Python3 adaption", 2019-01-29). Each test was performed in a clean tree
> (after running "git clean -ffdx") and clean environment (I re-sourced
> "edksetup.sh" for each test in separation). In addition, the base tools
> were rebuilt (again from a clean tree) for each test, with the following
> command [1]:
> 
>   nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)
> 
> (a) On my RHEL7.5 Workstation laptop, I have both the system-level
> python packages installed (python-2.7.5-69.el7_5.x86_64), and the extra
> python-3.4 stuff from EPEL-7 (python34-3.4.9-1.el7.x86_64).
> 
> (a1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build
> utility picked
> 
>   PYTHON_COMMAND   = /usr/bin/python3.4
> 
> and I successfully built OvmfPkg for IA32, IA32X64, and X64; also
> ArmVirtQemu for AARCH64. The built firmware images passed a smoke test
> too.
> 
> (a2) I removed all the python34 packages (and the dependent packages)
> from my laptop. Didn't set either of PYTHON3_ENABLE and PYTHON_COMMAND.
> (This is the configuration what a "normal" RHEL7 environment would
> provide.) The "build" utility didn't print any PYTHON_COMMAND setting,
> but the same fw platform builds as in (a1) completed fine. The smoke
> tests passed again as well.
> 
> (b) RHEL-8 virtual machine, with "/usr/bin/python3.6" from
> python36-3.6.6-18.el8.x86_64, and "/usr/libexec/platform-python" from
> platform-python-3.6.8-1.el8.x86_64.
> 
> (b1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build
> utility picked
> 
>   PYTHON_COMMAND   = /usr/bin/python3.6
> 
> and I successfully built OvmfPkg for IA32, IA32X64, and X64. (I don't
> have a cross-compiler installed in this environment yet, nor a RHEL8
> aarch64 KVM guest, so I couldn't test ArmVirtQemu for now).
> 
> (b2) I set PYTHON_COMMAND to "/usr/libexec/platform-python". Didn't set
> PYTHON3_ENABLE. The same builds as in (b1) succeeded.
> 
> 
> For the series:
> 
> Tested-by: Laszlo Ersek 
> 
> Given that the testing is quite time consuming, I suggest that we push
> v2 (assuming reviewers don't find critical issues), and address small
> issues incrementally.
> 
> 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 00/33] BaseTools python3 migration patch set

[Feng, Bob C]

Hi Laszlo,

Thank you very much for the testing.

Thanks!
Bob

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, January 29, 2019 9:07 PM
To: Feng, Bob C 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

Hi Bob,

On 01/29/19 03:05, Feng, Bob C wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=55
>
> V2:
> The python files under CParser4 folder of ECC/Eot tool are generated 
> by antlr4 and forpython3 usage.
> They have python3 specific syntax, for example the data type 
> declaration for the arguments of a function. That is not compitable 
> with python2. this patch is to remove these syntax.
>
> The version2 patch set is commit to https://github.com/BobCF/edk2.git 
> branch py3basetools_v2

(reusing the "test plan" from my email at
http://mid.mail-archive.com/cab4fed6-4c5d-94a9-b29f-da41ad7f320e@redhat.com>:)

I ran the following tests, at commit 6edb6bd9f182 ("BaseTools: Eot tool
Python3 adaption", 2019-01-29). Each test was performed in a clean tree (after 
running "git clean -ffdx") and clean environment (I re-sourced "edksetup.sh" 
for each test in separation). In addition, the base tools were rebuilt (again 
from a clean tree) for each test, with the following command [1]:

  nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)

(a) On my RHEL7.5 Workstation laptop, I have both the system-level python 
packages installed (python-2.7.5-69.el7_5.x86_64), and the extra
python-3.4 stuff from EPEL-7 (python34-3.4.9-1.el7.x86_64).

(a1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build utility 
picked

  PYTHON_COMMAND   = /usr/bin/python3.4

and I successfully built OvmfPkg for IA32, IA32X64, and X64; also ArmVirtQemu 
for AARCH64. The built firmware images passed a smoke test too.

(a2) I removed all the python34 packages (and the dependent packages) from my 
laptop. Didn't set either of PYTHON3_ENABLE and PYTHON_COMMAND.
(This is the configuration what a "normal" RHEL7 environment would
provide.) The "build" utility didn't print any PYTHON_COMMAND setting, but the 
same fw platform builds as in (a1) completed fine. The smoke tests passed again 
as well.

(b) RHEL-8 virtual machine, with "/usr/bin/python3.6" from 
python36-3.6.6-18.el8.x86_64, and "/usr/libexec/platform-python" from 
platform-python-3.6.8-1.el8.x86_64.

(b1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build utility 
picked

  PYTHON_COMMAND   = /usr/bin/python3.6

and I successfully built OvmfPkg for IA32, IA32X64, and X64. (I don't have a 
cross-compiler installed in this environment yet, nor a RHEL8
aarch64 KVM guest, so I couldn't test ArmVirtQemu for now).

(b2) I set PYTHON_COMMAND to "/usr/libexec/platform-python". Didn't set 
PYTHON3_ENABLE. The same builds as in (b1) succeeded.


For the series:

Tested-by: Laszlo Ersek 

Given that the testing is quite time consuming, I suggest that we push
v2 (assuming reviewers don't find critical issues), and address small issues 
incrementally.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] BaseTools: Enable compiler cache support in edk2 build

[Steven Shi]

https://bugzilla.tianocore.org/show_bug.cgi?id=1499
Compiler cache can greatly improve the build performance and
guarantee the build result safe. In our testing, the compiler
cache can improve the overall clean build time usually by 30+%
in linux and 10+% in windows. The compiler cache are very fit
to improve the Continuous Integration (CI) build performance.

For linux compiler cache (ccache) enabling, there is no need
to update edk2 code.
Below link has the ccache enabling referencd steps:
https://github.com/shijunjing/edk2/wiki/
Edk2-compiler-cache-enabling-steps-on-Linux

For windows compiler cache (clcache) enabling, we need update
the .PDB debugging file producing option from /Zi to /Z7,
which is to let the C object file contain its full symbolic
debugging information rather than produces a separated PDB file
for all obj files per folder. "PDB files are generated by a different
process (mspdbsrv). They arrive or are updated on disk after
cl completes a compilation or linking operation. One huge problem
with caching them is that the pdb files are input files as well as
outputs. mspdbsrv updates the file with new debug information if
the file exists beforehand. If there are several compilations going
on at once targetting the same pdb then the order the pdb gets
updated is unpredictable. All this makes caching very hard."
The /Zi issue more detail disccusion can be found:
https://github.com/frerich/clcache/issues/30
Please be aware that this change has no any impact to edk2 module
level PDB file generation, and we still can get the PDB debug file
for a .efi module. The /Z7 only impact intermediate obj files level
PDB file, which is current one PDB file (vc140.pdb) per obj folder.

Below link has the clcache enabling referencd steps:
https://github.com/shijunjing/edk2/wiki/
Edk2-compiler-cache-enabling-steps-on-Windows

Have tested below tools which consume the .PDB file:
*Edk2 source code debugger
*Various hardware and software debuggers
*Uefi code coverage tools

Only update and test below most commonly used four msvc toolchains:
VS2012x86 VS2013x86 VS2015x86 VS2017

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Steven Shi 
Cc: Liming Gao 
---
 BaseTools/Conf/tools_def.template | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2bd0982872..7d04b3efd2 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2589,9 +2589,9 @@ NOOPT_VS2012xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 *_VS2012x86_IA32_ASM_PATH = DEF(VS2012x86_BIN)\ml.exe
 
   *_VS2012x86_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
+  DEBUG_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7
 RELEASE_VS2012x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2012x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
+NOOPT_VS2012x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Z7 /Od
 
   DEBUG_VS2012x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2012x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -2621,9 +2621,9 @@ NOOPT_VS2012x86_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2012x86_X64_DLINK_PATH= DEF(VS2012x86_BINX64)\link.exe
 *_VS2012x86_X64_ASLDLINK_PATH = DEF(VS2012x86_BINX64)\link.exe
 
-  DEBUG_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm
+  DEBUG_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7
 RELEASE_VS2012x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF
-NOOPT_VS2012x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
+NOOPT_VS2012x86_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Z7 /Od
 
   DEBUG_VS2012x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2012x86_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -3055,9 +3055,9 @@ NOOPT_VS2013xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 *_VS2013x86_IA32_ASM_PATH = DEF(VS2013x86_BIN)\ml.exe
 
   *_VS2013x86_IA32_MAKE_FLAGS  = /nologo
-  DEBUG_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Gw
+  DEBUG_VS2013x86_IA32_

Re: [edk2] [PATCH v2] SD/eMMC : Fix Command Argument for SD/eMMC R/W operation.

[Meenakshi Aggarwal]

Any comments?

> -Original Message-
> From: Meenakshi Aggarwal
> Sent: Tuesday, January 29, 2019 10:13 AM
> To: Meenakshi Aggarwal ;
> ard.biesheu...@linaro.org; leif.lindh...@linaro.org; edk2-devel@lists.01.org;
> jun@linaro.org; haojian.zhu...@linaro.org
> Subject: RE: [PATCH v2] SD/eMMC : Fix Command Argument for SD/eMMC R/W
> operation.
> 
> Hi,
> 
> Please share review comments.
> 
> Thanks,
> Meenakshi
> 
> > -Original Message-
> > From: Meenakshi Aggarwal 
> > Sent: Thursday, January 24, 2019 7:35 PM
> > To: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; edk2-
> > de...@lists.01.org; jun@linaro.org; haojian.zhu...@linaro.org
> > Cc: Meenakshi Aggarwal 
> > Subject: [PATCH v2] SD/eMMC : Fix Command Argument for SD/eMMC R/W
> > operation.
> >
> > Issue : SD read failure for high capacity cards e.g. 64 GB i Reason :
> > Command argument value exceeds 32 bit for block number 0x3787FFF and
> > cant be fit into
> > 32 bit wide SD host controller register.
> >
> > Fix :
> > AccessMode bits [29:30] of OCR is a valid definition to calculate data
> > address for eMMC cards.
> >
> > For SD cards, data address is calculated on the basis of card capacity
> > status bit[30] of OCR.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  EmbeddedPkg/Universal/MmcDxe/Mmc.h|  2 ++
> >  EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c | 21 
> -
> >  2 files changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> > b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> > index a77ba41..62de2c8 100644
> > --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> > +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.h
> > @@ -70,6 +70,8 @@
> >  #define SD_HIGH_SPEED   5000
> >  #define SWITCH_CMD_SUCCESS_MASK 0x0f00
> >
> > +#define SD_CARD_CAPACITY0x0002
> > +
> >  #define BUSWIDTH_4  4
> >
> >  typedef enum {
> > diff --git a/EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c
> > b/EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c
> > index a2b9232..1dea7d3 100644
> > --- a/EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c
> > +++ b/EmbeddedPkg/Universal/MmcDxe/MmcBlockIo.c
> > @@ -148,12 +148,23 @@ MmcTransferBlock (
> >MmcHostInstance = MMC_HOST_INSTANCE_FROM_BLOCK_IO_THIS (This);
> >MmcHost = MmcHostInstance->MmcHost;
> >
> > -  //Set command argument based on the card access mode (Byte mode or
> > Block
> > mode)
> > -  if ((MmcHostInstance->CardInfo.OCRData.AccessMode &
> > MMC_OCR_ACCESS_MASK) ==
> > -  MMC_OCR_ACCESS_SECTOR) {
> > -CmdArg = Lba;
> > +  if (MmcHostInstance->CardInfo.CardType != EMMC_CARD) {
> > +//Set command argument based on the card capacity
> > +//if 0 : SDSC card
> > +//if 1 : SDXC/SDHC
> > +if (MmcHostInstance->CardInfo.OCRData.AccessMode &
> > SD_CARD_CAPACITY) {
> > +  CmdArg = Lba;
> > +} else {
> > +  CmdArg = Lba * This->Media->BlockSize;
> > +}
> >} else {
> > -CmdArg = Lba * This->Media->BlockSize;
> > +//Set command argument based on the card access mode (Byte mode
> > + or
> > Block mode)
> > +if ((MmcHostInstance->CardInfo.OCRData.AccessMode &
> > MMC_OCR_ACCESS_MASK) ==
> > +MMC_OCR_ACCESS_SECTOR) {
> > +  CmdArg = Lba;
> > +} else {
> > +  CmdArg = Lba * This->Media->BlockSize;
> > +}
> >}
> >
> >Status = MmcHost->SendCommand (MmcHost, Cmd, CmdArg);
> > --
> > 1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

[Feng, Bob C]

I agree this proposal. 
I plan to push python3 patch set to edk2 master in this Friday morning, Feb.1 
PRC time if there is no more comments or no critical issues found.

Thanks,
Bob

-Original Message-
From: Gao, Liming 
Sent: Wednesday, January 30, 2019 9:53 AM
To: Laszlo Ersek ; Feng, Bob C 
Cc: edk2-devel@lists.01.org
Subject: RE: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

Laszlo:
 I agree your proposal. Push this patch set first if no other comments, then 
continue to do minor bug fix. 
 
Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Laszlo Ersek
> Sent: Tuesday, January 29, 2019 9:07 PM
> To: Feng, Bob C 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch 
> set
> 
> Hi Bob,
> 
> On 01/29/19 03:05, Feng, Bob C wrote:
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=55
> >
> > V2:
> > The python files under CParser4 folder of ECC/Eot tool are generated 
> > by antlr4 and forpython3 usage.
> > They have python3 specific syntax, for example the data type 
> > declaration for the arguments of a function. That is not compitable 
> > with python2. this patch is to remove these syntax.
> >
> > The version2 patch set is commit to 
> > https://github.com/BobCF/edk2.git branch py3basetools_v2
> 
> (reusing the "test plan" from my email at
>  at.com>:)
> 
> I ran the following tests, at commit 6edb6bd9f182 ("BaseTools: Eot 
> tool
> Python3 adaption", 2019-01-29). Each test was performed in a clean 
> tree (after running "git clean -ffdx") and clean environment (I 
> re-sourced "edksetup.sh" for each test in separation). In addition, 
> the base tools were rebuilt (again from a clean tree) for each test, 
> with the following command [1]:
> 
>   nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)
> 
> (a) On my RHEL7.5 Workstation laptop, I have both the system-level 
> python packages installed (python-2.7.5-69.el7_5.x86_64), and the 
> extra
> python-3.4 stuff from EPEL-7 (python34-3.4.9-1.el7.x86_64).
> 
> (a1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build 
> utility picked
> 
>   PYTHON_COMMAND   = /usr/bin/python3.4
> 
> and I successfully built OvmfPkg for IA32, IA32X64, and X64; also 
> ArmVirtQemu for AARCH64. The built firmware images passed a smoke test 
> too.
> 
> (a2) I removed all the python34 packages (and the dependent packages) 
> from my laptop. Didn't set either of PYTHON3_ENABLE and PYTHON_COMMAND.
> (This is the configuration what a "normal" RHEL7 environment would
> provide.) The "build" utility didn't print any PYTHON_COMMAND setting, 
> but the same fw platform builds as in (a1) completed fine. The smoke 
> tests passed again as well.
> 
> (b) RHEL-8 virtual machine, with "/usr/bin/python3.6" from 
> python36-3.6.6-18.el8.x86_64, and "/usr/libexec/platform-python" from 
> platform-python-3.6.8-1.el8.x86_64.
> 
> (b1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build 
> utility picked
> 
>   PYTHON_COMMAND   = /usr/bin/python3.6
> 
> and I successfully built OvmfPkg for IA32, IA32X64, and X64. (I don't 
> have a cross-compiler installed in this environment yet, nor a RHEL8
> aarch64 KVM guest, so I couldn't test ArmVirtQemu for now).
> 
> (b2) I set PYTHON_COMMAND to "/usr/libexec/platform-python". Didn't 
> set PYTHON3_ENABLE. The same builds as in (b1) succeeded.
> 
> 
> For the series:
> 
> Tested-by: Laszlo Ersek 
> 
> Given that the testing is quite time consuming, I suggest that we push
> v2 (assuming reviewers don't find critical issues), and address small 
> issues incrementally.
> 
> 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

[edk2] [PATCH v4] MdePkg/BaseLib: Add Base64Encode() and Base64Decode()

[Shenglei Zhang]

From: Mike Turner 

Introduce public functions Base64Encode and Base64Decode.
https://bugzilla.tianocore.org/show_bug.cgi?id=1370

v2:1.Remove some white space.
   2.Add unit test with test vectors in RFC 4648.
 https://github.com/shenglei10/edk2/tree/encode_test
 https://github.com/shenglei10/edk2/tree/decode_test

v3:1.Align white space.
   2.Update comments of Base64Encode and Base64Decode.
   3.Change the use of macro RETURN_DEVICE_ERROR to
 RETURN_INVALID_PARAMETER in string.c.

v4:Change parameters' names.

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 MdePkg/Include/Library/BaseLib.h |  56 +
 MdePkg/Library/BaseLib/String.c  | 344 +++
 2 files changed, 400 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 1eb842384e..03173def58 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -2720,6 +2720,62 @@ AsciiStrnToUnicodeStrS (
   OUT UINTN *DestinationLength
   );
 
+/**
+  Convert binary data to a Base64 encoded ascii string based on RFC4648.
+
+  Produce a Null-terminated Ascii string in the output buffer specified by 
Destination and DestinationSize.
+  The Ascii string is produced by converting the data string specified by 
Source and SourceLength.
+
+  @param Source   Input UINT8 data
+  @param SourceLength Number of UINT8 bytes of data
+  @param Destination  Pointer to output string buffer
+  @param DestinationSize  Size of ascii buffer. Set to 0 to get the size 
needed.
+  Caller is responsible for passing in buffer of 
DestinationSize
+
+  @retval RETURN_SUCCESS When ascii buffer is filled in.
+  @retval RETURN_INVALID_PARAMETER   If Source is NULL or DestinationSize is 
NULL.
+  @retval RETURN_INVALID_PARAMETER   If SourceLength or DestinationSize is 
bigger than (MAX_ADDRESS - (UINTN)Destination).
+  @retval RETURN_BUFFER_TOO_SMALLIf SourceLength is 0 and DestinationSize 
is <1.
+  @retval RETURN_BUFFER_TOO_SMALLIf Destination is NULL or DestinationSize 
is smaller than required buffersize.
+
+**/
+RETURN_STATUS
+EFIAPI
+Base64Encode (
+  IN  CONST UINT8  *Source,
+  INUINTN   SourceLength,
+  OUT   CHAR8  *Destination  OPTIONAL,
+  IN OUTUINTN  *DestinationSize
+  );
+
+/**
+  Convert Base64 ascii string to binary data based on RFC4648.
+
+  Produce Null-terminated binary data in the output buffer specified by 
Destination and DestinationSize.
+  The binary data is produced by converting the Base64 ascii string specified 
by Source and SourceLength.
+
+  @param Source  Input ASCII characters
+  @param SourceLengthNumber of ASCII characters
+  @param Destination Pointer to output buffer
+  @param DestinationSize Caller is responsible for passing in buffer of at 
least DestinationSize.
+ Set 0 to get the size needed. Set to bytes stored on 
return.
+
+  @retval RETURN_SUCCESS When binary buffer is filled in.
+  @retval RETURN_INVALID_PARAMETER   If Source is NULL or DestinationSize is 
NULL.
+  @retval RETURN_INVALID_PARAMETER   If SourceLength or DestinationSize is 
bigger than (MAX_ADDRESS -(UINTN)Destination ).
+  @retval RETURN_INVALID_PARAMETER   If there is any invalid character in 
input stream.
+  @retval RETURN_BUFFER_TOO_SMALLIf buffer length is smaller than required 
buffer size.
+
+ **/
+RETURN_STATUS
+EFIAPI
+Base64Decode (
+  IN  CONST CHAR8  *Source,
+  INUINTN   SourceLength,
+  OUT   UINT8  *Destination  OPTIONAL,
+  IN OUTUINTN  *DestinationSize
+  );
+
 /**
   Converts an 8-bit value to an 8-bit BCD value.
 
diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
index e6df12797d..e4aa5a57e4 100644
--- a/MdePkg/Library/BaseLib/String.c
+++ b/MdePkg/Library/BaseLib/String.c
@@ -1763,6 +1763,350 @@ AsciiStrToUnicodeStr (
 
 #endif
 
+//
+// The basis for Base64 encoding is RFC 4686 
https://tools.ietf.org/html/rfc4648
+//
+// RFC 4686 has a number of MAY and SHOULD cases.  This implementation chooses
+// the more restrictive versions for security concerns (see RFC 4686 section 
3.3).
+//
+// A invalid character, if encountered during the decode operation, causes the 
data
+// to be rejected. In addition, the '=' padding character is only allowed at 
the end
+// of the Base64 encoded string.
+//
+#define BAD_V  99
+
+STATIC CHAR8 Encoding_table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
+"abcdefghijklmnopqrstuvwxyz"
+"0123456789+/";
+
+STATIC UINT8 Decoding_table[] = {
+  //
+  // Valid characters 
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
+  // Also, set '=' as a zero for decoding
+  // 0  ,1,   2,   3,4,   5,   
 6,   7,   8,  

[edk2] [PATCH v5 2/7] MdePkg/BaseLib: Introduce CharToUpper and AsciiCharToUpper publicly

[Shenglei Zhang]

From: Mike Turner 

Introduce two public functions CharToUpper and AsciiCharToUpper.
They have the same functions as InternalCharToUpper and
InternalBaseLibAsciiToUpper.Considering the internal functions will
be removed,so directly I change their function names to the public ones'.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 MdePkg/Include/Library/BaseLib.h| 40 +
 MdePkg/Library/BaseLib/SafeString.c |  8 +++---
 MdePkg/Library/BaseLib/String.c | 16 ++--
 3 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 1eb842384e..10e01f07ea 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -2720,6 +2720,46 @@ AsciiStrnToUnicodeStrS (
   OUT UINTN *DestinationLength
   );
 
+/**
+  Convert a Unicode character to upper case only if
+  it maps to a valid small-case ASCII character.
+
+  This internal function only deal with Unicode character
+  which maps to a valid small-case ASCII character, i.e.
+  L'a' to L'z'. For other Unicode character, the input character
+  is returned directly.
+
+  @param  Char  The character to convert.
+
+  @retval LowerCharacter   If the Char is with range L'a' to L'z'.
+  @retval UnchangedOtherwise.
+
+**/
+CHAR16
+EFIAPI
+CharToUpper (
+  IN  CHAR16Char
+  );
+
+/**
+  Converts a lowercase Ascii character to upper one.
+
+  If Chr is lowercase Ascii character, then converts it to upper one.
+
+  If Value >= 0xA0, then ASSERT().
+  If (Value & 0x0F) >= 0x0A, then ASSERT().
+
+  @param  Chr   one Ascii character
+
+  @return The uppercase value of Ascii character
+
+**/
+CHAR8
+EFIAPI
+AsciiCharToUpper (
+  IN  CHAR8 Chr
+  );
+
 /**
   Converts an 8-bit value to an 8-bit BCD value.
 
diff --git a/MdePkg/Library/BaseLib/SafeString.c 
b/MdePkg/Library/BaseLib/SafeString.c
index 417497cbc9..a6d271c9f2 100644
--- a/MdePkg/Library/BaseLib/SafeString.c
+++ b/MdePkg/Library/BaseLib/SafeString.c
@@ -905,7 +905,7 @@ StrHexToUintnS (
 String++;
   }
 
-  if (InternalCharToUpper (*String) == L'X') {
+  if (CharToUpper (*String) == L'X') {
 if (*(String - 1) != L'0') {
   *Data = 0;
   return RETURN_SUCCESS;
@@ -1036,7 +1036,7 @@ StrHexToUint64S (
 String++;
   }
 
-  if (InternalCharToUpper (*String) == L'X') {
+  if (CharToUpper (*String) == L'X') {
 if (*(String - 1) != L'0') {
   *Data = 0;
   return RETURN_SUCCESS;
@@ -2459,7 +2459,7 @@ AsciiStrHexToUintnS (
 String++;
   }
 
-  if (InternalBaseLibAsciiToUpper (*String) == 'X') {
+  if (AsciiCharToUpper (*String) == 'X') {
 if (*(String - 1) != '0') {
   *Data = 0;
   return RETURN_SUCCESS;
@@ -2586,7 +2586,7 @@ AsciiStrHexToUint64S (
 String++;
   }
 
-  if (InternalBaseLibAsciiToUpper (*String) == 'X') {
+  if (AsciiCharToUpper (*String) == 'X') {
 if (*(String - 1) != '0') {
   *Data = 0;
   return RETURN_SUCCESS;
diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
index e6df12797d..689c4f79fe 100644
--- a/MdePkg/Library/BaseLib/String.c
+++ b/MdePkg/Library/BaseLib/String.c
@@ -552,7 +552,7 @@ InternalIsDecimalDigitCharacter (
 **/
 CHAR16
 EFIAPI
-InternalCharToUpper (
+CharToUpper (
   IN  CHAR16Char
   )
 {
@@ -586,7 +586,7 @@ InternalHexCharToUintn (
 return Char - L'0';
   }
 
-  return (10 + InternalCharToUpper (Char) - L'A');
+  return (10 + CharToUpper (Char) - L'A');
 }
 
 /**
@@ -1181,7 +1181,7 @@ AsciiStrCmp (
 **/
 CHAR8
 EFIAPI
-InternalBaseLibAsciiToUpper (
+AsciiCharToUpper (
   IN  CHAR8 Chr
   )
 {
@@ -1211,7 +1211,7 @@ InternalAsciiHexCharToUintn (
 return Char - '0';
   }
 
-  return (10 + InternalBaseLibAsciiToUpper (Char) - 'A');
+  return (10 + AsciiCharToUpper (Char) - 'A');
 }
 
 
@@ -1260,13 +1260,13 @@ AsciiStriCmp (
   ASSERT (AsciiStrSize (FirstString));
   ASSERT (AsciiStrSize (SecondString));
 
-  UpperFirstString  = InternalBaseLibAsciiToUpper (*FirstString);
-  UpperSecondString = InternalBaseLibAsciiToUpper (*SecondString);
+  UpperFirstString  = AsciiCharToUpper (*FirstString);
+  UpperSecondString = AsciiCharToUpper (*SecondString);
   while ((*FirstString != '\0') && (*SecondString != '\0') && 
(UpperFirstString == UpperSecondString)) {
 FirstString++;
 SecondString++;
-UpperFirstString  = InternalBaseLibAsciiToUpper (*FirstString);
-UpperSecondString = InternalBaseLibAsciiToUpper (*SecondString);
+UpperFirstString  = AsciiCharToUpper (*FirstString);
+UpperSecondString = AsciiCharToUpper (*SecondString);
   }
 
   return UpperFirstString - UpperSecondString;
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-deve

[edk2] [PATCH v5 0/7] Introduce two public functions and remove internal ones

[Shenglei Zhang]

Introduce public functions CharToUpper and AsciiCharToUpper.
Remove internal functions InternalCharToUpper and InternalBaseLibAsciiToUpper.

v2: Update the title and commit message of 1/3.

v3: 1.Add a patch to remove AsciiToUpper in EdbSupportString.c.
2.Revert the changes in Basetools.

v4: 1.Add1/7: Change function names in EdbSupportString.c.
2.Update the title of 4/7.
3.Add 5/7: Use BaseLib api AsciiToUpper in DxeHttpLib.c.
4.Add 6/7: Use BaseLib api CharToUpper in ShellManParser.c.
5.Add 7/7: Use BaseLib api CharToUpper in UefiShellLib.c.

v5: Change AsciiToUpper to AsciiCharToUpper in 2/7,4/7 and 5/7.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Star Zeng 
Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Shenglei Zhang (7):
  MdeModulePkg/EbcDebugger: Change function names
  MdePkg/BaseLib: Introduce CharToUpper and AsciiCharToUpper publicly
  MdePkg/BaseLib: Remove definitions of two functions
  MdeModulePkg/EbcDebugger: Use AsciiCharToUpper and CharToUpper
  MdeModulePkg/DxeHttpLib: Use BaseLib api AsciiCharToUpper
  ShellPkg/Shell: Use BaseLib api CharToUpper
  ShellPkg/UefiShellLib: Use BaseLib api CharToUpper

 MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c  | 23 +-
 .../EbcDxe/EbcDebugger/EdbSupportString.c | 39 ++---
 MdePkg/Include/Library/BaseLib.h  | 40 ++
 MdePkg/Library/BaseLib/BaseLibInternals.h | 42 ---
 MdePkg/Library/BaseLib/SafeString.c   |  8 ++--
 MdePkg/Library/BaseLib/String.c   | 16 +++
 ShellPkg/Application/Shell/ShellManParser.c   | 23 +-
 ShellPkg/Library/UefiShellLib/UefiShellLib.c  | 31 +-
 8 files changed, 60 insertions(+), 162 deletions(-)

-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v5 4/7] MdeModulePkg/EbcDebugger: Use AsciiCharToUpper and CharToUpper

[Shenglei Zhang]

InternalUnicodeToUpper and InternalAsciiToUpper are internal functions,
so they are substituted by public functions AsciiCharToUpper and CharToUpper.
And their implements are removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../EbcDxe/EbcDebugger/EdbSupportString.c | 39 ++-
 1 file changed, 4 insertions(+), 35 deletions(-)

diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
index 02e1876ffa..d34acf892b 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
@@ -307,37 +307,6 @@ AsciiAtoi (
   return RetVal;
 }
 
-/**
-
-  Convert the character to upper case.
-
-  @param  Chrthe character to be converted.
-
-**/
-STATIC
-CHAR16
-InternalUnicodeToUpper (
-  IN  CHAR16Chr
-  )
-{
-  return (Chr >= L'a' && Chr <= L'z') ? Chr - (L'a' - L'A') : Chr;
-}
-
-/**
-
-  Convert the character to upper case.
-
-  @param  Chrthe character to be converted.
-
-**/
-STATIC
-CHAR8
-InternalAsciiToUpper (
-  IN  CHAR8 Chr
-  )
-{
-  return (Chr >= 'a' && Chr <= 'z') ? Chr - ('a' - 'A') : Chr;
-}
 
 /**
   Compare the Unicode and Ascii string pointed by String to the string pointed 
by String2.
@@ -390,12 +359,12 @@ StriCmp (
   )
 {
   while ((*String != L'\0') &&
- (InternalUnicodeToUpper (*String) == InternalUnicodeToUpper 
(*String2))) {
+ (CharToUpper (*String) == CharToUpper (*String2))) {
 String++;
 String2++;
   }
 
-  return InternalUnicodeToUpper (*String) - InternalUnicodeToUpper (*String2);
+  return CharToUpper (*String) - CharToUpper (*String2);
 }
 
 /**
@@ -418,12 +387,12 @@ StriCmpUnicodeAndAscii (
   )
 {
   while ((*String != L'\0') &&
- (InternalUnicodeToUpper (*String) == (CHAR16)InternalAsciiToUpper 
(*String2))) {
+ (CharToUpper (*String) == (CHAR16)AsciiCharToUpper (*String2))) {
 String++;
 String2++;
   }
 
-  return InternalUnicodeToUpper (*String) - (CHAR16)InternalAsciiToUpper 
(*String2);
+  return CharToUpper (*String) - (CHAR16)AsciiCharToUpper (*String2);
 }
 
 /**
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v5 1/7] MdeModulePkg/EbcDebugger: Change function names

[Shenglei Zhang]

Change UnicodeToUpper to InternalUnicodeToUpper.
Change AsciiToUpper to InternalAsciiToUpper.
These changes are committed for bisectability, or build failure will
occur when 2/7 is applied. Because the introduced function names in
2/7 are the same as ones in EdbSupporting.c.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Hao Wu 
Reviewed-by: Liming Gao 
---
 .../Universal/EbcDxe/EbcDebugger/EdbSupportString.c  | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c 
b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
index 78a0559079..02e1876ffa 100644
--- a/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
+++ b/MdeModulePkg/Universal/EbcDxe/EbcDebugger/EdbSupportString.c
@@ -316,7 +316,7 @@ AsciiAtoi (
 **/
 STATIC
 CHAR16
-UnicodeToUpper (
+InternalUnicodeToUpper (
   IN  CHAR16Chr
   )
 {
@@ -332,7 +332,7 @@ UnicodeToUpper (
 **/
 STATIC
 CHAR8
-AsciiToUpper (
+InternalAsciiToUpper (
   IN  CHAR8 Chr
   )
 {
@@ -390,12 +390,12 @@ StriCmp (
   )
 {
   while ((*String != L'\0') &&
- (UnicodeToUpper (*String) == UnicodeToUpper (*String2))) {
+ (InternalUnicodeToUpper (*String) == InternalUnicodeToUpper 
(*String2))) {
 String++;
 String2++;
   }
 
-  return UnicodeToUpper (*String) - UnicodeToUpper (*String2);
+  return InternalUnicodeToUpper (*String) - InternalUnicodeToUpper (*String2);
 }
 
 /**
@@ -418,12 +418,12 @@ StriCmpUnicodeAndAscii (
   )
 {
   while ((*String != L'\0') &&
- (UnicodeToUpper (*String) == (CHAR16)AsciiToUpper (*String2))) {
+ (InternalUnicodeToUpper (*String) == (CHAR16)InternalAsciiToUpper 
(*String2))) {
 String++;
 String2++;
   }
 
-  return UnicodeToUpper (*String) - (CHAR16)AsciiToUpper (*String2);
+  return InternalUnicodeToUpper (*String) - (CHAR16)InternalAsciiToUpper 
(*String2);
 }
 
 /**
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v5 3/7] MdePkg/BaseLib: Remove definitions of two functions

[Shenglei Zhang]

InternalCharToUpper and InternalBaseLibAsciiToUpper are internal functions
and now we will introduce public functions that have the same effects.
So I remove their definitions in BaseLibInternals.h.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Liming Gao 
---
 MdePkg/Library/BaseLib/BaseLibInternals.h | 42 ---
 1 file changed, 42 deletions(-)

diff --git a/MdePkg/Library/BaseLib/BaseLibInternals.h 
b/MdePkg/Library/BaseLib/BaseLibInternals.h
index 8855231c1a..9db925b157 100644
--- a/MdePkg/Library/BaseLib/BaseLibInternals.h
+++ b/MdePkg/Library/BaseLib/BaseLibInternals.h
@@ -469,28 +469,6 @@ InternalIsDecimalDigitCharacter (
   );
 
 
-/**
-  Convert a Unicode character to upper case only if
-  it maps to a valid small-case ASCII character.
-
-  This internal function only deal with Unicode character
-  which maps to a valid small-case ASCII character, i.e.
-  L'a' to L'z'. For other Unicode character, the input character
-  is returned directly.
-
-  @param  Char  The character to convert.
-
-  @retval LowerCharacter   If the Char is with range L'a' to L'z'.
-  @retval UnchangedOtherwise.
-
-**/
-CHAR16
-EFIAPI
-InternalCharToUpper (
-  IN  CHAR16Char
-  );
-
-
 /**
   Convert a Unicode character to numerical value.
 
@@ -552,26 +530,6 @@ InternalAsciiIsDecimalDigitCharacter (
   );
 
 
-/**
-  Converts a lowercase Ascii character to upper one.
-
-  If Chr is lowercase Ascii character, then converts it to upper one.
-
-  If Value >= 0xA0, then ASSERT().
-  If (Value & 0x0F) >= 0x0A, then ASSERT().
-
-  @param  Chr   one Ascii character
-
-  @return The uppercase value of Ascii character
-
-**/
-CHAR8
-EFIAPI
-InternalBaseLibAsciiToUpper (
-  IN  CHAR8 Chr
-  );
-
-
 /**
   Check if a ASCII character is a hexadecimal character.
 
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v5 6/7] ShellPkg/Shell: Use BaseLib api CharToUpper

[Shenglei Zhang]

Substitute InternalShellCharToUpper with a public function
CharToUpper which has the same function.
Remove the implement of InternalShellCharToUpper.

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Jaben Carsey 
Reviewed-by: Liming Gao 
---
 ShellPkg/Application/Shell/ShellManParser.c | 23 +
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/ShellPkg/Application/Shell/ShellManParser.c 
b/ShellPkg/Application/Shell/ShellManParser.c
index b180c6c8f7..2c044dbe4a 100644
--- a/ShellPkg/Application/Shell/ShellManParser.c
+++ b/ShellPkg/Application/Shell/ShellManParser.c
@@ -46,27 +46,6 @@ SHELL_MAN_HII_VENDOR_DEVICE_PATH  mShellManHiiDevicePath = {
   }
 };
 
-
-/**
-  Convert a Unicode character to upper case only if
-  it maps to a valid small-case ASCII character.
-
-  This internal function only deal with Unicode character
-  which maps to a valid small-case ASCII character, i.e.
-  L'a' to L'z'. For other Unicode character, the input character
-  is returned directly.
-
-  @param  Char  The character to convert.
-
-  @retval LowerCharacter   If the Char is with range L'a' to L'z'.
-  @retval UnchangedOtherwise.
-
-**/
-CHAR16
-InternalShellCharToUpper (
-  IN CHAR16  Char
-  );
-
 /**
   Verifies that the filename has .EFI on the end.
 
@@ -416,7 +395,7 @@ IsTitleHeader(
   ReturnFound = TRUE;  // This is the desired command's title header 
line.
   State = (BriefDesc == NULL) ? Final : GetBriefDescription;
 }
-else if (InternalShellCharToUpper (*Line) != InternalShellCharToUpper 
(*(Command + CommandIndex++))) {
+else if (CharToUpper (*Line) != CharToUpper (*(Command + 
CommandIndex++))) {
   State = Final;
 }
 Line++;
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v5 7/7] ShellPkg/UefiShellLib: Use BaseLib api CharToUpper

[Shenglei Zhang]

Substitute InternalShellCharToUpper with CharToUpper which is a public
function with the same effect.
Remove the implement of InternalShellCharToUpper.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369

Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Jaben Carsey 
Reviewed-by: Liming Gao 
---
 ShellPkg/Library/UefiShellLib/UefiShellLib.c | 31 ++--
 1 file changed, 2 insertions(+), 29 deletions(-)

diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c 
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index b17266d623..aff933dcdf 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -3740,33 +3740,6 @@ ShellFileExists(
   return (EFI_SUCCESS);
 }
 
-/**
-  Convert a Unicode character to upper case only if
-  it maps to a valid small-case ASCII character.
-
-  This internal function only deal with Unicode character
-  which maps to a valid small-case ASCII character, i.e.
-  L'a' to L'z'. For other Unicode character, the input character
-  is returned directly.
-
-  @param  Char  The character to convert.
-
-  @retval LowerCharacter   If the Char is with range L'a' to L'z'.
-  @retval UnchangedOtherwise.
-
-**/
-CHAR16
-InternalShellCharToUpper (
-  IN  CHAR16Char
-  )
-{
-  if (Char >= L'a' && Char <= L'z') {
-return (CHAR16) (Char - (L'a' - L'A'));
-  }
-
-  return Char;
-}
-
 /**
   Convert a Unicode character to numerical value.
 
@@ -3789,7 +3762,7 @@ InternalShellHexCharToUintn (
 return Char - L'0';
   }
 
-  return (10 + InternalShellCharToUpper (Char) - L'A');
+  return (10 + CharToUpper (Char) - L'A');
 }
 
 /**
@@ -3849,7 +3822,7 @@ InternalShellStrHexToUint64 (
 String++;
   }
 
-  if (InternalShellCharToUpper (*String) == L'X') {
+  if (CharToUpper (*String) == L'X') {
 if (*(String - 1) != L'0') {
   return 0;
 }
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v5 5/7] MdeModulePkg/DxeHttpLib: Use BaseLib api AsciiCharToUpper

[Shenglei Zhang]

Substitute HttpIoCharToUpper with AsciiCharToUpper which is a public function
with the same effect. And remove the implement of HttpIoCharToUpper.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c | 23 +---
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c 
b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
index 2fc3da8a2d..3884bc8361 100644
--- a/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
+++ b/MdeModulePkg/Library/DxeHttpLib/DxeHttpLib.c
@@ -898,27 +898,6 @@ typedef struct {
   UINTN CurrentChunkParsedSize;
 } HTTP_BODY_PARSER;
 
-/**
-
-  Convert an Ascii char to its uppercase.
-
-  @param[in]   Char   Ascii character.
-
-  @return  Uppercase value of the input Char.
-
-**/
-CHAR8
-HttpIoCharToUpper (
-  IN  CHAR8Char
-  )
-{
-  if (Char >= 'a' && Char <= 'z') {
-return  Char - ('a' - 'A');
-  }
-
-  return Char;
-}
-
 /**
   Convert an hexadecimal char to a value of type UINTN.
 
@@ -936,7 +915,7 @@ HttpIoHexCharToUintn (
 return Char - '0';
   }
 
-  return (10 + HttpIoCharToUpper (Char) - 'A');
+  return (10 + AsciiCharToUpper (Char) - 'A');
 }
 
 /**
-- 
2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] SecurityPkg: Add a PCD to skip Opal password prompt

[Maggie Chu]

https://bugzilla.tianocore.org/show_bug.cgi?id=1484
Add a PCD for skipping password prompt and device unlock flow
so that other pre-OS applications are able to take over Opal devices unlock 
flow.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Maggie Chu 
Cc: Chao Zhang 
Cc: Jiewen Yao 
Cc: Eric Dong 
---
 SecurityPkg/SecurityPkg.dec   | 6 ++
 SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c| 4 
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
index 2708e7953c..70c9ff28a8 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -428,6 +428,12 @@
   # @Prompt Possible TPM2 Interrupt Number buffer
   gEfiSecurityPkgTokenSpaceGuid.PcdTpm2PossibleIrqNumBuf|{0x00, 0x00, 0x00, 
0x00}|VOID*|0x0001001D
 
+  ## Indicates if Opal DXE driver skip unlock device flow.
+  #   TRUE  - Skip unlock device flow.
+  #   FALSE - Does not skip unlock device flow.
+  # @Prompt Skip Opal DXE driver unlock device flow.
+  gEfiSecurityPkgTokenSpaceGuid.PcdSkipOpalDxeUnlock|FALSE|BOOLEAN|0x00010020
+
 [PcdsDynamic, PcdsDynamicEx]
 
   ## This PCD indicates Hash mask for TPM 2.0. Bit definition strictly follows 
TCG Algorithm Registry.
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
index 38268539fb..734c5f06ff 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
@@ -988,6 +988,10 @@ OpalDriverRequestPassword (
 
 IsLocked = OpalDeviceLocked (&Dev->OpalDisk.SupportedAttributes, 
&Dev->OpalDisk.LockingFeature);
 
+if (IsLocked && PcdGetBool (PcdSkipOpalDxeUnlock)) {
+  return;
+}
+
 while (Count < MAX_PASSWORD_TRY_COUNT) {
   Password = OpalDriverPopUpPasswordInput (Dev, PopUpString, NULL, 
&PressEsc);
   if (PressEsc) {
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf
index cfa55dded7..11e58b95cd 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf
@@ -75,5 +75,8 @@
 [Guids]
   gEfiEndOfDxeEventGroupGuid## CONSUMES ## 
Event
 
+[Pcd]
+  gEfiSecurityPkgTokenSpaceGuid.PcdSkipOpalDxeUnlock  ## CONSUMES
+
 [Depex]
   gEfiHiiStringProtocolGuid AND gEfiHiiDatabaseProtocolGuid
-- 
2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel