[edk2-devel] [patch] MdeModulePkg/HiiDB: Minimize memory allocation times after ReadyToBoot

[Dandan Bi]

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

Currently RTData are allocated at/after ReadyToBoot to store the
contents in HiiDatabase and the HII configurations for OS runtime
utilization.
Some platforms may meet S4 resume issue since the allocation after
ReadyToBoot cause memory map change.
Now this patch to do some overallocation to minimize the number
of memory allocations after ReadyToBoot and also add warning
message when do allocation after ReadyToBoot.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Eric Dong 
Signed-off-by: Dandan Bi 
---
 .../Universal/HiiDatabaseDxe/Database.c   | 24 +--
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
index 6da0e30c98..d3791ca68b 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
@@ -1,9 +1,9 @@
 /** @file
 Implementation for EFI_HII_DATABASE_PROTOCOL.
 
-Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 
@@ -3361,18 +3361,23 @@ HiiGetConfigRespInfo(
   Status = 
HiiConfigRoutingExportConfig(>ConfigRouting,);
 
   if (!EFI_ERROR (Status)){
 ConfigSize = StrSize(ConfigAltResp);
 if (ConfigSize > gConfigRespSize){
-  gConfigRespSize = ConfigSize;
+  //
+  // Do 25% overallocation to minimize the number of memory allocations 
after ReadyToBoot.
+  // Since lots of allocation after ReadyToBoot may change memory map and 
cause S4 resume issue.
+  //
+  gConfigRespSize = ConfigSize + (ConfigSize >> 2);
   if (gRTConfigRespBuffer != NULL){
 FreePool(gRTConfigRespBuffer);
+DEBUG ((DEBUG_WARN, "[HiiDatabase]: Memory allocation is required 
after ReadyToBoot, which may change memory map and cause S4 resume issue.\n"));
   }
-  gRTConfigRespBuffer = (EFI_STRING)AllocateRuntimeZeroPool(ConfigSize);
+  gRTConfigRespBuffer = (EFI_STRING) AllocateRuntimeZeroPool 
(gConfigRespSize);
   if (gRTConfigRespBuffer == NULL){
 FreePool(ConfigAltResp);
-DEBUG ((DEBUG_ERROR, "Not enough memory resource to get the ConfigResp 
string.\n"));
+DEBUG ((DEBUG_ERROR, "[HiiDatabase]: No enough memory resource to 
store the ConfigResp string.\n"));
 return EFI_OUT_OF_RESOURCES;
   }
 } else {
   ZeroMem(gRTConfigRespBuffer,gConfigRespSize);
 }
@@ -3412,17 +3417,22 @@ HiiGetDatabaseInfo(
   Status = HiiExportPackageLists(This, NULL, , DatabaseInfo);
 
   ASSERT(Status == EFI_BUFFER_TOO_SMALL);
 
   if(DatabaseInfoSize > gDatabaseInfoSize ) {
-gDatabaseInfoSize = DatabaseInfoSize;
+//
+// Do 25% overallocation to minimize the number of memory allocations 
after ReadyToBoot.
+// Since lots of allocation after ReadyToBoot may change memory map and 
cause S4 resume issue.
+//
+gDatabaseInfoSize = DatabaseInfoSize + (DatabaseInfoSize >> 2);
 if (gRTDatabaseInfoBuffer != NULL){
   FreePool(gRTDatabaseInfoBuffer);
+  DEBUG ((DEBUG_WARN, "[HiiDatabase]: Memory allocation is required after 
ReadyToBoot, which may change memory map and cause S4 resume issue.\n"));
 }
-gRTDatabaseInfoBuffer = AllocateRuntimeZeroPool(DatabaseInfoSize);
+gRTDatabaseInfoBuffer = AllocateRuntimeZeroPool (gDatabaseInfoSize);
 if (gRTDatabaseInfoBuffer == NULL){
-  DEBUG ((DEBUG_ERROR, "Not enough memory resource to get the HiiDatabase 
info.\n"));
+  DEBUG ((DEBUG_ERROR, "[HiiDatabase]: No enough memory resource to store 
the HiiDatabase info.\n"));
   return EFI_OUT_OF_RESOURCES;
 }
   } else {
 ZeroMem(gRTDatabaseInfoBuffer,gDatabaseInfoSize);
   }
-- 
2.18.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39535): https://edk2.groups.io/g/devel/message/39535
Mute This Topic: https://groups.io/mt/31338933/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Andrew Fish via Groups.Io]

> On Apr 24, 2019, at 6:40 PM, Zhang, Chao B  wrote:
> 
> Hi Andrew:
>Tks for your explanation. The middle octet of StartingCHS (0x000200) is 
> for Sector. Based on CHS to LBA conversion rule. It should be 0x02.   I think 
> it is an spec compliance issue.
> Partition Dxe driver doesn’t apply such check so there is no problem.  
> Partition Pei is in BIOS TCB, we applied stronger check and exposed this 
> issue.
> We need carefully document such limitation somewhere.
>BTW the whole GPT support in PEI is new in Q1 stable tag,
>

My bigger point is what PartitionDxe driver does is likely the defacto standard 
in terms of what has been tested. Thus using the same test as the PartitionDxe 
driver will give you maximum compatibility. 

Given this is the recovery path for your ROM I think you would want it to be as 
reliable as possible. I would posit the protective MBR being corrupted has no 
impact on being able to mount the GPT partitions on the disk as thus does not 
have a lot of value in the PEI path. If the GPT is valid you should mount it. 
Don't get me wrong I'm all for spec conformance and I wrote that part of the 
spec, but as a customer I'd much rather that the Firmware update actually 
complete if at all possible. 

Thanks,

Andrew Fish

>   <>
>  <>From: devel@edk2.groups.io  
> [mailto:devel@edk2.groups.io ] On Behalf Of 
> Andrew Fish via Groups.Io
> Sent: Thursday, April 25, 2019 12:07 AM
> To: devel@edk2.groups.io ; Xu, Wei6 
> mailto:wei6...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>; Kinney, 
> Michael D mailto:michael.d.kin...@intel.com>>
> Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu
>
> The intent of the protective MBR was to prevent tools that did not understand 
> GPT to not think a GPT disk was blank. 20 years ago that made a lot of sense, 
> today it is kind of an obsolete concept.
>
> The protective MBR was never intended to identify the disk as GPT, but it 
> seems it got used as a short cut to not have to read a variable number of 
> blocks from the disk to validate the GPT header. 
>
> From a practical sense the DXE Partition driver uses this algorithm to 
> validate the Protective MBR. It would be a good idea for the PEI code to do 
> the same thing. 
>
> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
>  
> 
>  //
>  // Verify that the Protective MBR is valid
>  //
>  for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
> if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
> ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
> UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
> ) {
>   break;
> }
>   }
>  if (Index == MAX_MBR_PARTITIONS) {
> goto Done;
>   }
>
> I'd also point out that that ATA-6 specification obsoleted CHS addressing in 
> 2002 and I think the 0x200 has to do with the sector size of 512 bytes, which 
> is also kind of an obsolete concept. So I'm not sure what the 0x100 is about 
> in your example?
>
> Thanks,
>
> Andrew Fish
> 
> 
> On Apr 24, 2019, at 4:36 AM, Xu, Wei6  > wrote:
>
> Hi,
>
> I have a question about protective MBR. Thanks a lot for your time.
> Why is the StartingCHS of protective MBR partition record set to 0x000100 in 
> RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
>
> Problem Statement:
> I met a problem when trying to use FatPei to fetch a file on the GPT 
> partition of RedHat/Ubuntu in TCB.
> FatPei has a check about Partition Record of protective MBR: StartingCHS 
> should to 0x000200.
> But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that the 
> check fails.
>
> According to UEFI spec, StartingCHS should be 0x000200.
>
> 
>
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39534): https://edk2.groups.io/g/devel/message/39534
Mute This Topic: https://groups.io/mt/31320822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Zhang, Chao B]

Hi Andrew:
   Tks for your explanation. The middle octet of StartingCHS (0x000200) is for 
Sector. Based on CHS to LBA conversion rule. It should be 0x02.   I think it is 
an spec compliance issue.
Partition Dxe driver doesn't apply such check so there is no problem.  
Partition Pei is in BIOS TCB, we applied stronger check and exposed this issue.
We need carefully document such limitation somewhere.
   BTW the whole GPT support in PEI is new in Q1 stable tag,


From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew 
Fish via Groups.Io
Sent: Thursday, April 25, 2019 12:07 AM
To: devel@edk2.groups.io; Xu, Wei6 
Cc: Laszlo Ersek ; Kinney, Michael D 

Subject: Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

The intent of the protective MBR was to prevent tools that did not understand 
GPT to not think a GPT disk was blank. 20 years ago that made a lot of sense, 
today it is kind of an obsolete concept.

The protective MBR was never intended to identify the disk as GPT, but it seems 
it got used as a short cut to not have to read a variable number of blocks from 
the disk to validate the GPT header.

>From a practical sense the DXE Partition driver uses this algorithm to 
>validate the Protective MBR. It would be a good idea for the PEI code to do 
>the same thing.

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c

 //


 // Verify that the Protective MBR is valid


 //


 for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {


if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&


ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&


UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1


) {


  break;


}


  }


 if (Index == MAX_MBR_PARTITIONS) {


goto Done;


  }



I'd also point out that that ATA-6 specification obsoleted CHS addressing in 
2002 and I think the 0x200 has to do with the sector size of 512 bytes, which 
is also kind of an obsolete concept. So I'm not sure what the 0x100 is about in 
your example?

Thanks,

Andrew Fish


On Apr 24, 2019, at 4:36 AM, Xu, Wei6 
mailto:wei6...@intel.com>> wrote:

Hi,

I have a question about protective MBR. Thanks a lot for your time.
Why is the StartingCHS of protective MBR partition record set to 0x000100 in 
RedHat / Ubuntu? While UEFI spec defines it as 0x000200.

Problem Statement:
I met a problem when trying to use FatPei to fetch a file on the GPT partition 
of RedHat/Ubuntu in TCB.
FatPei has a check about Partition Record of protective MBR: StartingCHS should 
to 0x000200.
But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that the 
check fails.

According to UEFI spec, StartingCHS should be 0x000200.





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39531): https://edk2.groups.io/g/devel/message/39531
Mute This Topic: https://groups.io/mt/31320822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] CryptoPkg: add issetugid declaration to fix openssl build on FreeBSD

[rebecca via Groups.Io]

On 2019-04-24 13:17, Laszlo Ersek wrote:
>
> So I don't think there's anything to fix for package maintainers here.
> It seems that groups.io rewrites the sender address for Rebecca. I don't
> know why groups.io performs this rewrite, and why only for Rebecca.
>
> Stephano -- can you please ask groups.io why it keeps changing the From
> header on messages sent by "Rebecca Cran "?



Trying again, now that I've disabled DKIM.


-- 
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39524): https://edk2.groups.io/g/devel/message/39524
Mute This Topic: https://groups.io/mt/31250604/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] CryptoPkg: add issetugid declaration to fix openssl build on FreeBSD

[rebecca via Groups.Io]

On 2019-04-24 13:17, Laszlo Ersek wrote:
>
> Again, in email that I get directly from Rebecca, the From field looks
> just fine.
>
> So I don't think there's anything to fix for package maintainers here.
> It seems that groups.io rewrites the sender address for Rebecca. I don't
> know why groups.io performs this rewrite, and why only for Rebecca.
>
> Stephano -- can you please ask groups.io why it keeps changing the From
> header on messages sent by "Rebecca Cran "?



I think it'll be because I'm still sending email with DKIM signatures: I
thought I'd disabled it for edk2.groups.io but I'll go investigate why
it's still being added.


-- 
Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39523): https://edk2.groups.io/g/devel/message/39523
Mute This Topic: https://groups.io/mt/31250604/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] CryptoPkg: add issetugid declaration to fix openssl build on FreeBSD

[Laszlo Ersek]

+Stephano

On 04/24/19 11:25, Philippe Mathieu-Daudé wrote:
> On 4/22/19 3:46 PM, Wang, Jian J wrote:
>> crypto/uid.c is needed by VS201x toolchain on Windows. Let's still keep it 
>> in inf.
>> That means we need this patch for build on FreeBSD.
>>
>> Reviewed-by: Jian J Wang 
> 
> Commit 1a734ed85fda71630c795832e6d24ea560caf739 has weird authorship
> again: rebecca via Groups.Io 

And, again, that's exactly how the sender is displayed to me by
Thunderbird, in my list folder only:

  From: Rebecca via Groups.Io 

Again, in email that I get directly from Rebecca, the From field looks
just fine.

So I don't think there's anything to fix for package maintainers here.
It seems that groups.io rewrites the sender address for Rebecca. I don't
know why groups.io performs this rewrite, and why only for Rebecca.

Stephano -- can you please ask groups.io why it keeps changing the From
header on messages sent by "Rebecca Cran "?

Thanks
Laszlo

> 
>> Jian
>>
>>> -Original Message-
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>> rebecca via Groups.Io
>>> Sent: Sunday, April 21, 2019 1:18 AM
>>> To: devel@edk2.groups.io; ard.biesheu...@linaro.org
>>> Cc: Ye, Ting ; Gang Wei ; Wang, Jian
>>> J 
>>> Subject: Re: [edk2-devel] [PATCH] CryptoPkg: add issetugid declaration to 
>>> fix
>>> openssl build on FreeBSD
>>>
>>> On 2019-04-20 05:28, Ard Biesheuvel wrote:

 This is slightly odd. The host architecture shouldn't really matter,
 and so if we end up calling different code in UEFI when built on *BSD,
 there is differently something wrong. Or am I missing something?
>>>
>>>
>>> No, that's a good point. I guess it's something we don't ever call.
>>>
>>> In fact, OVMF continues to build after removing crypto/uid.c (which
>>> contains the OPENSSL_issetugid definition) from
>>> CryptoPkg/Library/OpensslLib/OpensslLib.inf and
>>> CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf .
>>>
>>>
>>> --
>>>
>>> Rebecca Cran
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39522): https://edk2.groups.io/g/devel/message/39522
Mute This Topic: https://groups.io/mt/31250604/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] Request to add new edk2-libc repository

[Laszlo Ersek]

On 04/24/19 11:50, Laszlo Ersek wrote:

> That's great, but there are two more sections in edk2-libc's
> Maintainers.txt that are not replated to edk2-libc's packages:

sorry, s/replated/related/

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39521): https://edk2.groups.io/g/devel/message/39521
Mute This Topic: https://groups.io/mt/31251207/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-test]Regarding using any shell command in SCT

[Supreeth Venkatesh]

Changing subject line to include [edk2-test].
+ Eric

Prakriti,
With the disclaimer that UEFI SCT is intended for testing against UEFI 
specification, I will try to answer your question in the way I interpreted it.

I am not sure whether you are asking how to test EFI_SHELL_PROTOCOL or is it 
related to a non uefi standard device interface you want to test?
Assuming it as the latter and with the limited information you mentioned about 
your requirement, I am assuming you will have a non-standard Protocol/Driver 
for your device and want to test those APIs.
With the above assumption, you can follow any of the standard test cases as 
reference for implementing your own test. Example below:
https://github.com/tianocore/edk2-test/tree/master/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/DeviceIo/BlackBoxTest

Eric can provide more information based on detailed explanation of your 
requirements.

Thanks,
Supreeth

From: Prakriti Chauhan 
Sent: Wednesday, April 24, 2019 4:28 AM
To: Supreeth Venkatesh ; devel@edk2.groups.io
Subject: Regarding using any shell command in SCT

Hi,



I want to test if my interface is working or not using SCT framework, like give 
IP address to interface and then run ping command.

Any pointers how can I achieve same?



Thanks,
Prakriti
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39520): https://edk2.groups.io/g/devel/message/39520
Mute This Topic: https://groups.io/mt/31331918/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Laszlo Ersek]

On 04/24/19 13:36, Xu, Wei6 wrote:
> Hi,
> 
> I have a question about protective MBR. Thanks a lot for your time.
> Why is the StartingCHS of protective MBR partition record set to 0x000100 in 
> RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
> 
> Problem Statement:
> I met a problem when trying to use FatPei to fetch a file on the GPT 
> partition of RedHat/Ubuntu in TCB.
> FatPei has a check about Partition Record of protective MBR: StartingCHS 
> should to 0x000200.
> But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that the 
> check fails.
> 
> According to UEFI spec, StartingCHS should be 0x000200.
> 
> [cid:image001.png@01D4FACC.71570DF0]
> 

Anaconda (the RHEL & Fedora installer) uses GNU Parted for creating GPT
partitions. This utility creates the protective MBR as well.

GNU Parted used to have a bug in setting the sector in "StartingCHS" --
in C/H/S, sectors are 1-based, not 0-based.

The problem was fixed in upstream parted commit df6770d213b6
("libparted: Fix starting CHS in protective MBR", 2016-12-22):

  http://git.savannah.gnu.org/cgit/parted.git/commit/?id=df6770d213b6

As far as I can determine, this fix has been included in Fedora 27 and
later. (The oldest supported Fedora release at this point is Fedora 28,
so I think we can consider "Fedora" fixed.) The fix is also included in
RHEL-8.0.

RHEL-7.7 however lacks the fix (as of build "parted-3.1-31.el7"). I've
now filed a Red Hat Bugzilla for you:

  https://bugzilla.redhat.com/show_bug.cgi?id=1702778

Please register in the Red Hat Bugzilla instance, subscribe to the bug,
and assist with testing the fix, if the BZ assignee requests that.

Thank you for reporting this issue,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39519): https://edk2.groups.io/g/devel/message/39519
Mute This Topic: https://groups.io/mt/31320822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 3/8] MdePkg/UefiDebugLibStdErr: Decrease the name collisions

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 19:31, Kinney, Michael D
 wrote:
>
> Hi Ard,
>
> I see no issues with using 'static' on more symbols.
>
> I am not sure how to enforce it, so it would be a good
> recommendation for code style and a good recommendation
> for a code reviews.
>

In Linux, it is one of the things enforced by the sparse tool: if no
declaration exists anywhere in a .h file, it warns about it, since it
means only the defining translation unit can refer to it.

> Can you provide an example where code generation is
> improved when 'static' is used.  That would be good to
> include with the recommendations and would help encourage
> developers to follow the recommendation.
>

Something like

STATIC UINT32 mVar = FixedPcdGet32 (FooCount);

VOID Func (VOID)
{
  UINT32 Index;

   for (Index = 0; Index < mVar; Index++) {
 ...
   }
}

If the compiler notices that there are no other assignments of mVar
(or can prove they are unreachable), it simply treats mVar as an
immediate constant, and removes the whole loop if mVar == 0. This is
only possible when using STATIC (or when using LTO, and so the lack of
STATIC may be one of the reasons LTO is so effective on our codebase)

The compiler will even track value ranges, i.e., if the only other
reachable assignment sets mVar to 1, it can take that into account in
the code generation as well.

As soon as the mVar symbol gets exported, the compiler must assume
that it can hold any value representable by the type, which defeats
many of these optimizations.


>
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> > On Behalf Of Ard Biesheuvel
> > Sent: Wednesday, April 24, 2019 10:10 AM
> > To: Kinney, Michael D 
> > Cc: devel@edk2.groups.io; Gao, Zhichao
> > ; Laszlo Ersek
> > ; Gao, Liming ;
> > Bi, Dandan 
> > Subject: Re: [edk2-devel] [PATCH V2 3/8]
> > MdePkg/UefiDebugLibStdErr: Decrease the name collisions
> >
> > On Wed, 24 Apr 2019 at 18:59, Kinney, Michael D
> >  wrote:
> > >
> > > Hi Ard,
> > >
> > > I see a mix of use of 'static' and 'STATIC' in the
> > sources.
> > >
> > > The reason to use STATIC is if it needs to be replaced
> > with
> > > something other than 'static' for a specific compiler
> > or
> > > debug scenario.
> > >
> > > Long ago, there were some source level debug issue with
> > > 'static' symbols, so using the macro STATIC was
> > preferred
> > > so it could be mapped to nothing for a debug scenario.
> > That
> > > issue no long exists.
> > >
> > > Do you know of a reason today to map 'STATIC' to
> > anything
> > > Other than 'static'?
> > >
> > > I also looked at the EDK II C Coding Standard.  It is
> > also
> > > inconsistent and had references to both 'static' and
> > 'STATIC'.
> > > We should enter a few BZs to update that doc once we
> > have
> > > clear guidance from this discussion.
> > >
> >
> > I wasn't aware that lower case static is also in use, so
> > I was simply
> > extrapolating from personal experience.
> >
> > i think there should be no reason to use the preprocessor
> > to change
> > 'static' into something else, and so I'm happy to settle
> > on lowercase
> > static, as long as we are consistent. But more
> > importantly, now that
> > this has come up, what I would like to do is make
> > 'static' mandatory
> > unless the code requires otherwise: this results in much
> > better code
> > generation (given that the compiler can infer constness
> > for non-const
> > static variables but not for ones with external linkage)
> > and generally
> > improves programmer hygiene when it comes to linking to
> > arbitrary
> > symbols that are really internal to a library.
> >
> >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io
> > [mailto:devel@edk2.groups.io]
> > > > On Behalf Of Ard Biesheuvel
> > > > Sent: Wednesday, April 24, 2019 1:07 AM
> > > > To: edk2-devel-groups-io ; Gao,
> > > > Zhichao 
> > > > Cc: Laszlo Ersek ; Kinney, Michael
> > D
> > > > ; Gao, Liming
> > > > ; Bi, Dandan
> > 
> > > > Subject: Re: [edk2-devel] [PATCH V2 3/8]
> > > > MdePkg/UefiDebugLibStdErr: Decrease the name
> > collisions
> > > >
> > > > On Wed, 24 Apr 2019 at 06:59, Gao, Zhichao
> > > >  wrote:
> > > > >
> > > > > REF:
> > > > https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> > > > >
> > > > > Add a 'static' descriptor to the global variables
> > that
> > > > only
> > > > > used in a single file to minimize the name
> > collisions.
> > > > > This is only for the varable named
> > > > 'mExitBootServicesEvent'.
> > > > >
> > > > > Cc: Laszlo Ersek 
> > > > > Cc: Michael D Kinney 
> > > > > Cc: Liming Gao 
> > > > > Cc: Dandan Bi 
> > > > > Signed-off-by: Zhichao Gao 
> > > > > ---
> > > > >
> > > >
> > MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c |
> > > > 4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git
> > > >
> > a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > >
> > 

Re: [edk2-devel] [PATCH V2 3/8] MdePkg/UefiDebugLibStdErr: Decrease the name collisions

[Michael D Kinney]

Hi Ard,

I see no issues with using 'static' on more symbols.

I am not sure how to enforce it, so it would be a good
recommendation for code style and a good recommendation
for a code reviews.

Can you provide an example where code generation is 
improved when 'static' is used.  That would be good to
include with the recommendations and would help encourage
developers to follow the recommendation.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Ard Biesheuvel
> Sent: Wednesday, April 24, 2019 10:10 AM
> To: Kinney, Michael D 
> Cc: devel@edk2.groups.io; Gao, Zhichao
> ; Laszlo Ersek
> ; Gao, Liming ;
> Bi, Dandan 
> Subject: Re: [edk2-devel] [PATCH V2 3/8]
> MdePkg/UefiDebugLibStdErr: Decrease the name collisions
> 
> On Wed, 24 Apr 2019 at 18:59, Kinney, Michael D
>  wrote:
> >
> > Hi Ard,
> >
> > I see a mix of use of 'static' and 'STATIC' in the
> sources.
> >
> > The reason to use STATIC is if it needs to be replaced
> with
> > something other than 'static' for a specific compiler
> or
> > debug scenario.
> >
> > Long ago, there were some source level debug issue with
> > 'static' symbols, so using the macro STATIC was
> preferred
> > so it could be mapped to nothing for a debug scenario.
> That
> > issue no long exists.
> >
> > Do you know of a reason today to map 'STATIC' to
> anything
> > Other than 'static'?
> >
> > I also looked at the EDK II C Coding Standard.  It is
> also
> > inconsistent and had references to both 'static' and
> 'STATIC'.
> > We should enter a few BZs to update that doc once we
> have
> > clear guidance from this discussion.
> >
> 
> I wasn't aware that lower case static is also in use, so
> I was simply
> extrapolating from personal experience.
> 
> i think there should be no reason to use the preprocessor
> to change
> 'static' into something else, and so I'm happy to settle
> on lowercase
> static, as long as we are consistent. But more
> importantly, now that
> this has come up, what I would like to do is make
> 'static' mandatory
> unless the code requires otherwise: this results in much
> better code
> generation (given that the compiler can infer constness
> for non-const
> static variables but not for ones with external linkage)
> and generally
> improves programmer hygiene when it comes to linking to
> arbitrary
> symbols that are really internal to a library.
> 
> 
> > > -Original Message-
> > > From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io]
> > > On Behalf Of Ard Biesheuvel
> > > Sent: Wednesday, April 24, 2019 1:07 AM
> > > To: edk2-devel-groups-io ; Gao,
> > > Zhichao 
> > > Cc: Laszlo Ersek ; Kinney, Michael
> D
> > > ; Gao, Liming
> > > ; Bi, Dandan
> 
> > > Subject: Re: [edk2-devel] [PATCH V2 3/8]
> > > MdePkg/UefiDebugLibStdErr: Decrease the name
> collisions
> > >
> > > On Wed, 24 Apr 2019 at 06:59, Gao, Zhichao
> > >  wrote:
> > > >
> > > > REF:
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> > > >
> > > > Add a 'static' descriptor to the global variables
> that
> > > only
> > > > used in a single file to minimize the name
> collisions.
> > > > This is only for the varable named
> > > 'mExitBootServicesEvent'.
> > > >
> > > > Cc: Laszlo Ersek 
> > > > Cc: Michael D Kinney 
> > > > Cc: Liming Gao 
> > > > Cc: Dandan Bi 
> > > > Signed-off-by: Zhichao Gao 
> > > > ---
> > > >
> > >
> MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c |
> > > 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git
> > >
> a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > >
> b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > > index d4fdfbab55..bb7b144569 100644
> > > > ---
> > >
> a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > > +++
> > >
> b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > > @@ -15,9 +15,9 @@
> > > >  //
> > > >  // BOOLEAN value to indicate if it is at the post
> > > ExitBootServices pahse
> > > >  //
> > > > -BOOLEAN mPostEBS = FALSE;
> > > > +BOOLEAN   mPostEBS = FALSE;
> > > >
> > > > -EFI_EVENT   mExitBootServicesEvent;
> > > > +static EFI_EVENT  mExitBootServicesEvent;
> > > >
> > >
> > > Please use STATIC not static.
> > >
> > >
> > > >  //
> > > >  // Pointer to SystemTable
> > > > --
> > > > 2.21.0.windows.1
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39517): https://edk2.groups.io/g/devel/message/39517
Mute This Topic: https://groups.io/mt/3131/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms] [RFC] Migrate devel-MinPlatform branch to master branch

[Kubacki, Michael A]

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1748 

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, April 24, 2019 12:22 AM
> To: devel@edk2.groups.io; Kubacki, Michael A
> 
> Subject: RE: [edk2-platforms] [RFC] Migrate devel-MinPlatform branch to
> master branch
> 
> Michael:
>   I think this change is good. Could you submit one BZ for it?
> 
> Thanks
> Liming
> >-Original Message-
> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> >Kubacki, Michael A
> >Sent: Friday, April 19, 2019 5:12 AM
> >To: 'devel@edk2.groups.io' 
> >Subject: [edk2-devel] [edk2-platforms] [RFC] Migrate devel-MinPlatform
> >branch to master branch
> >
> >Hello,
> >
> >This RFC proposes moving the content on the devel-MinPlatform branch in
> >the edk2-platforms repository to the master branch in the
> >edk2-platforms repository.
> >
> >The devel-MinPlatform branch has been used for the initial development
> >of an EDK II based platform design referred to as "Minimum Platform".
> >This design is intended to provide a structured approach to introducing
> >Intel platform code into open source in a consistent manner.
> >
> >For more information about the EDK II Minimum Platform, please refer to
> >the Readme.md in devel-MinPlatform.
> >https://github.com/tianocore/edk2-platforms/blob/devel-
> >MinPlatform/ReadMe.md
> >
> >The following packages would be added in Platform/Intel:
> >  * Generic packages:
> > * AdvancedFeaturePkg
> > * MinPlatformPkg
> >  * Board-specific packages:
> > * ClevoOpenBoardPkg
> > * KabylakeOpenBoardPkg
> > * PurleyOpenBoardPkg
> >
> >The following packages would be added in Silicon/Intel:
> > * KabylakeSiliconPkg
> > * LewisburgPkg
> > * PurleyRcPkg
> > * PurleySktPkg
> >
> >The following growth is expected over time:
> > * Platform/Intel - Additional board packages for Intel reference boards
> >including support for some pre-existing product releases
> > * AdvancedFeaturePkg - Additional modular features capable of being used
> >in board packages
> > * Silicon/Intel - Additional silicon packages roughly keeping 1:1 parity
> >with board packages
> >
> >We hope the content will enable others to add new board packages and
> >advanced features over time.
> >
> >The result of the change is available here for reference:
> >https://github.com/lgao4/edk2-platforms
> >
> >Regards,
> >Michael
> >
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39516): https://edk2.groups.io/g/devel/message/39516
Mute This Topic: https://groups.io/mt/31236064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch 0/7] Move BaseUefiTianoCustomDecompressLib from IntelFrameworkModulePkg to MdeModulePkg

[Michael D Kinney]

Ard,

Using edk2 and edk2-non-osi as submodules in the edk2-platforms 
repo does have some advantages.  Each branch in edk2-platforms
can decide which release/tag/sha is required from dependent repos.

This provides a platform focused view of the EDK II project.

If using a release/tag/sha for the dependent repos, the content
is effectively being used as read-only content like we do for
the OpenSSL submodule.

When using the combination of edk2-platforms/master, edk2/master,
and edk2-non-osi/master, if changes are made in submodules, then
there are some additional complexities that the developer needs
to be aware.  But this is a workflow that is required to make
sure a change in edk2/master does not break any platforms in
edk2-platforms/master.  I think easily discovering a build break
is higher priority.

Thanks,

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, April 24, 2019 6:04 AM
> To: Gao, Liming 
> Cc: Laszlo Ersek ; Bi, Dandan
> ; edk2-devel-groups-io
> ; Julien Grall
> ; Leif Lindholm
> ; Justen, Jordan L
> ; Andrew Fish
> ; Ni, Ray ; Wang, Jian
> J ; Wu, Hao A
> ; Kinney, Michael D
> ; Steele, Kelly
> ; Sun, Zailiang
> ; Qian, Yi 
> Subject: Re: [patch 0/7] Move
> BaseUefiTianoCustomDecompressLib from
> IntelFrameworkModulePkg to MdeModulePkg
> 
> On Wed, 24 Apr 2019 at 15:02, Gao, Liming
>  wrote:
> >
> > Ard:
> >   I prefer to keep them as the separate repo. One dummy
> Git repo can be introduced to submodule edk2, edk2-
> platform, edk2-non-osi, and others. User can use this git
> repo to get everything.
> >
> 
> That is not really my point.
> 
> A git submodule allows you to store *in* the dependent
> repository
> which exact commit in the core repository you depend on.
> A dummy git
> repo does not work the same way.
> 
> > > -Original Message-
> > > From: Ard Biesheuvel
> [mailto:ard.biesheu...@linaro.org]
> > > Sent: Wednesday, April 24, 2019 8:48 PM
> > > To: Gao, Liming 
> > > Cc: Laszlo Ersek ; Bi, Dandan
> ; edk2-devel-groups-io
> ; Julien Grall
> > > ; Leif Lindholm
> ; Justen, Jordan L
> ; Andrew Fish
> > > ; Ni, Ray ; Wang,
> Jian J ; Wu, Hao A
> ; Kinney,
> > > Michael D ; Steele, Kelly
> ; Sun, Zailiang
> ; Qian, Yi
> > > 
> > > Subject: Re: [patch 0/7] Move
> BaseUefiTianoCustomDecompressLib from
> IntelFrameworkModulePkg to MdeModulePkg
> > >
> > > On Wed, 24 Apr 2019 at 14:46, Gao, Liming
>  wrote:
> > > >
> > > >
> > > > So, we need to consider the combination of edk2
> master + edk2-platform master. When do the incompatible
> change in edk2 master, we
> > > need to update edk2-platform master together.
> > > >
> > >
> > > Yes, it is either that, or we separate them properly,
> by pulling core
> > > EDK2 into edk2-platforms as a git submodule. That
> way, we can update
> > > the upstream commit depended upon instead of assuming
> that we are
> > > always updated in lockstep.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39515): https://edk2.groups.io/g/devel/message/39515
Mute This Topic: https://groups.io/mt/30896388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 3/8] MdePkg/UefiDebugLibStdErr: Decrease the name collisions

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 18:59, Kinney, Michael D
 wrote:
>
> Hi Ard,
>
> I see a mix of use of 'static' and 'STATIC' in the sources.
>
> The reason to use STATIC is if it needs to be replaced with
> something other than 'static' for a specific compiler or
> debug scenario.
>
> Long ago, there were some source level debug issue with
> 'static' symbols, so using the macro STATIC was preferred
> so it could be mapped to nothing for a debug scenario. That
> issue no long exists.
>
> Do you know of a reason today to map 'STATIC' to anything
> Other than 'static'?
>
> I also looked at the EDK II C Coding Standard.  It is also
> inconsistent and had references to both 'static' and 'STATIC'.
> We should enter a few BZs to update that doc once we have
> clear guidance from this discussion.
>

I wasn't aware that lower case static is also in use, so I was simply
extrapolating from personal experience.

i think there should be no reason to use the preprocessor to change
'static' into something else, and so I'm happy to settle on lowercase
static, as long as we are consistent. But more importantly, now that
this has come up, what I would like to do is make 'static' mandatory
unless the code requires otherwise: this results in much better code
generation (given that the compiler can infer constness for non-const
static variables but not for ones with external linkage) and generally
improves programmer hygiene when it comes to linking to arbitrary
symbols that are really internal to a library.


> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> > On Behalf Of Ard Biesheuvel
> > Sent: Wednesday, April 24, 2019 1:07 AM
> > To: edk2-devel-groups-io ; Gao,
> > Zhichao 
> > Cc: Laszlo Ersek ; Kinney, Michael D
> > ; Gao, Liming
> > ; Bi, Dandan 
> > Subject: Re: [edk2-devel] [PATCH V2 3/8]
> > MdePkg/UefiDebugLibStdErr: Decrease the name collisions
> >
> > On Wed, 24 Apr 2019 at 06:59, Gao, Zhichao
> >  wrote:
> > >
> > > REF:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> > >
> > > Add a 'static' descriptor to the global variables that
> > only
> > > used in a single file to minimize the name collisions.
> > > This is only for the varable named
> > 'mExitBootServicesEvent'.
> > >
> > > Cc: Laszlo Ersek 
> > > Cc: Michael D Kinney 
> > > Cc: Liming Gao 
> > > Cc: Dandan Bi 
> > > Signed-off-by: Zhichao Gao 
> > > ---
> > >
> > MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c |
> > 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git
> > a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > index d4fdfbab55..bb7b144569 100644
> > > ---
> > a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > +++
> > b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > > @@ -15,9 +15,9 @@
> > >  //
> > >  // BOOLEAN value to indicate if it is at the post
> > ExitBootServices pahse
> > >  //
> > > -BOOLEAN mPostEBS = FALSE;
> > > +BOOLEAN   mPostEBS = FALSE;
> > >
> > > -EFI_EVENT   mExitBootServicesEvent;
> > > +static EFI_EVENT  mExitBootServicesEvent;
> > >
> >
> > Please use STATIC not static.
> >
> >
> > >  //
> > >  // Pointer to SystemTable
> > > --
> > > 2.21.0.windows.1
> > >
> > >
> > >
> > >
> >
> > 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39514): https://edk2.groups.io/g/devel/message/39514
Mute This Topic: https://groups.io/mt/3131/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 3/8] MdePkg/UefiDebugLibStdErr: Decrease the name collisions

[Michael D Kinney]

Hi Ard,

I see a mix of use of 'static' and 'STATIC' in the sources.

The reason to use STATIC is if it needs to be replaced with
something other than 'static' for a specific compiler or
debug scenario.

Long ago, there were some source level debug issue with
'static' symbols, so using the macro STATIC was preferred
so it could be mapped to nothing for a debug scenario. That
issue no long exists.

Do you know of a reason today to map 'STATIC' to anything
Other than 'static'?

I also looked at the EDK II C Coding Standard.  It is also
inconsistent and had references to both 'static' and 'STATIC'.
We should enter a few BZs to update that doc once we have 
clear guidance from this discussion.

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Ard Biesheuvel
> Sent: Wednesday, April 24, 2019 1:07 AM
> To: edk2-devel-groups-io ; Gao,
> Zhichao 
> Cc: Laszlo Ersek ; Kinney, Michael D
> ; Gao, Liming
> ; Bi, Dandan 
> Subject: Re: [edk2-devel] [PATCH V2 3/8]
> MdePkg/UefiDebugLibStdErr: Decrease the name collisions
> 
> On Wed, 24 Apr 2019 at 06:59, Gao, Zhichao
>  wrote:
> >
> > REF:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> >
> > Add a 'static' descriptor to the global variables that
> only
> > used in a single file to minimize the name collisions.
> > This is only for the varable named
> 'mExitBootServicesEvent'.
> >
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Dandan Bi 
> > Signed-off-by: Zhichao Gao 
> > ---
> >
> MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c |
> 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > index d4fdfbab55..bb7b144569 100644
> > ---
> a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > +++
> b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> > @@ -15,9 +15,9 @@
> >  //
> >  // BOOLEAN value to indicate if it is at the post
> ExitBootServices pahse
> >  //
> > -BOOLEAN mPostEBS = FALSE;
> > +BOOLEAN   mPostEBS = FALSE;
> >
> > -EFI_EVENT   mExitBootServicesEvent;
> > +static EFI_EVENT  mExitBootServicesEvent;
> >
> 
> Please use STATIC not static.
> 
> 
> >  //
> >  // Pointer to SystemTable
> > --
> > 2.21.0.windows.1
> >
> >
> >
> >
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39513): https://edk2.groups.io/g/devel/message/39513
Mute This Topic: https://groups.io/mt/3131/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: BaseSerialPortLib16550: Add Mmio32 support

[Michael D Kinney]

Hi,

Can we change the name of the access size PCD so it
does not use Mmio in the name?

I am ok with not implementing support for different
access widths for I/O, but it would be good if the PCD
name and description is for the access width so it 
could potentially be used for I/O in the future if 
there is a need.  The default access width can be 8-bits
so it is a compatible change.

How about the following name and description in the DEC file?

  ## Indicates the access width for 16550 serial port registers.
  # Default is 8-bit access mode.
  #   8  - 16550 serial port registers are accessed in 8-bit width.
  #   32 - 16550 serial port registers are accessed in 32-bit width.
  # @Prompt Serial port register access width.
  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterAccessWidth|8|UINT8|0x00020007

Thanks,

Mike

> -Original Message-
> From: Loh, Tien Hock
> Sent: Tuesday, April 23, 2019 11:58 PM
> To: Kinney, Michael D ; Wu,
> Hao A ; devel@edk2.groups.io;
> thlo...@gmail.com
> Cc: Wang, Jian J 
> Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg:
> BaseSerialPortLib16550: Add Mmio32 support
> 
> Hi Mike, Hao,
> 
> Replies inlined.
> 
> On Wed, 2019-04-24 at 03:45 +, Michael D Kinney
> wrote:
> > One issue I see is using a FeatureFlag PCD.
> > These PCDs can only be TRUE or FALSE, so they can not
> be
> > extended later.  A FixedAtBuild PCD of type BOOL has
> the
> > same issue.
> >
> > It would be better to use a UINTx FixedAtBuild PCD, and
> > define a bit or a value for 32-bit access.  That way,
> if
> > there is a device that requires 16-bit access, it can
> be
> > added in the same PCD.
> >
> OK noted. I'll update with UINT8, and set 0x0 to default
> 8bits and 0x1
> to 32 bits access
> 
> > Also, should the new PCD be limited to MMIO?  It could
> be
> > an access width PCD that could be applied to I/O or
> MMIO
> > Access.
> >
> I'm not sure if this should affect the I/O. I would
> separate the I/O
> access with MMIO access with different PCD, I'll skip
> this for now as I
> don't have platform that uses I/O space, thus I'm unable
> to test the
> changes.
> 
> > Mike
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io]
> > > On Behalf Of Wu, Hao A
> > > Sent: Tuesday, April 23, 2019 8:20 PM
> > > To: Loh, Tien Hock ;
> > > devel@edk2.groups.io; thlo...@gmail.com
> > > Cc: Wang, Jian J 
> > > Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg:
> > > BaseSerialPortLib16550: Add Mmio32 support
> > >
> > > > -Original Message-
> > > > From: Loh, Tien Hock
> > > > Sent: Wednesday, April 24, 2019 11:05 AM
> > > > To: devel@edk2.groups.io; thlo...@gmail.com
> > > > Cc: Loh, Tien Hock; Wang, Jian J; Wu, Hao A
> > > > Subject: [PATCH 1/1] MdeModulePkg:
> > >
> > > BaseSerialPortLib16550: Add Mmio32
> > > > support
> > > >
> > > > From: "Tien Hock, Loh" 
> > > >
> > > > Some busses doesn't allow 8 bit MMIO read/write,
> this
> > >
> > > adds support for
> > > > 32 bits read/write
> > >
> > > Hello Tien Hock,
> > >
> > > Your V2 patch seems to be based on your V1 patch.
> > >
> > > Could you help to update the V2 patch to base on the
> tip
> > > of the edk2
> > > master branch? Thanks.
> > >
> > > One easy way to do this is to squash the 2 commits
> into
> > > one.
> > >
> Yes sorry I wasn't aware I'm making patch on top of a
> patch.
> > >
> > > Some minor comments:
> > > A. Please help to update the copyright year for the
> > > files:
> > >BaseSerialPortLib16550.c
> > >BaseSerialPortLib16550.inf
> > >
> OK noted. I'll update the copyright year.
> 
> > > B. For BaseSerialPortLib16550.inf, maybe:
> > >
> > >
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess
> > > ## SOMETIMES_CONSUMES
> > >
> OK noted.
> 
> > > is more appropriate here.
> > >
> > > Best Regards,
> > > Hao Wu
> > >
> > > >
> > > > Signed-off-by: "Tien Hock, Loh"
> > >
> > > 
> > > > Cc: Jian J Wang 
> > > > Cc: Hao Wu 
> > > >
> > > > --
> > > > v2:
> > > > - Updates the Pcd name to PcdSerialMmio32BitAccess
> and
> > >
> > > access 32 bits
> > > > register if PcdSerialUseMmio and
> > >
> > > PcdSerialMmio32BitAccess is set
> > > > ---
> > > >
> .../BaseSerialPortLib16550/BaseSerialPortLib16550.c
> > > > 16 
> > > >
> .../BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> > > >  2 +-
> > > >  MdeModulePkg/MdeModulePkg.dec
> > > > 12 +++-
> > > >  3 files changed, 16 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git
> > > >
> > >
> > >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > > ortLib16550.c
> > > >
> > >
> > >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > > ortLib16550.c
> > > > index b242b23..f90fb55 100644
> > > > ---
> > >
> > >
> a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > > ortLib16550.c
> > > > +++
> > > >
> > >
> > >
> b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > > ortLib16550.c
> > > > @@ -76,10 +76,10 @@ SerialPortReadRegister (
> > > >

Re: [edk2-devel] [RFC] Remove PI spec TemporaryRamSupport PPI from PEI Core

[Laszlo Ersek]

On 04/24/19 09:51, Jordan Justen wrote:
> Short summary: Despite being part of the Platorm Initialization
> Specificication, this proposal would remove support for the
> TemporaryRamSupport PPI from PEI Core. Arguably, this would mean the
> PEI Core does not support the PI spec, but we do not currently know if
> any platforms require this PPI.
> 
> Main question: Does anyone know of a platform that requires this PPI,

You mention edk2 sample platforms below. I presume you include OVMF
among those. To me, OVMF is not a sample (or validation) platform, but
the upstream project for a *product*.

That said, I don't think OVMF "requires" this PPI. IOW, this part of
OVMF's SEC indeed qualifies as (functional) "sample code". I think
Replacement#1 applies (stop producing the PPI and let the PEI Core
fallback do the work).

I'd expect a patch series that removes the PPI definition (and its
consumption by the PEI Core) to update OVMF as well (and all the other
platforms in edk2 that currently produce the PPI).

> or does anyone have major concerns with removing it before the PI
> specification can be updated to remove the PPI?

I do, purely from a process / specs perspective.

It's one thing to design & implement an edk2 extension (one that doesn't
break compatibility with any of the relevant specs), amass evidence that
the implementation works and is robust, then standardize the extension
in PI / UEFI, and then complete the feature in edk2 by code movement /
renaming to standard locations / names. In that scenario, it's safe for
the code to advance first, and the spec(s) second, and I think I've
always encouraged (and requested) this.

With feature removal, I'm afraid we should work in the reverse order.
Minimally, I think you should please post this RFC to the PIWG list, and
file a Mantis ticket for the PI spec. Then we should start working on
the feature removal once there is "buy in" from the PIWG. IMO, we
shouldn't tag a handful of edk2-stableMM releases with the feature
removed, but the Mantis ticket *stuck* (let alone non-existent).

I'm not suggesting to gate the code removal on a PI spec release, but I
think it's reasonable to require a *clear commitment* from the PIWG, to
the PPI removal, by the time we first tag an edk2-stableMM release
that no longer handles the PPI. In the release notes for that
edk2-stableMM release, we should be able to reference a TianoCore BZ
that gives the rationale, and in turn references an in-progress
(committed-to) Mantis ticket.

... My experience with the specs suggests that they move very slowly, so
even the above "clear commitment" approach (= *non-stuck* Mantis ticket)
would likely result in multiple edk2-stableMM releases that don't
conform to the latest available PI spec. While I don't consider that a
"deal breaker" (as long as the Mantis ticket is moving, see above), it's
also not optimal. Applying your v2 series now, then shepherding the
Mantis ticket to completion / spec release, *then* removing the PPI from
edk2 altogether (including your v2 series) looks safest & cleanest, for
edk2-stableMM releases.

Summary of my opinion:

- PIWG buy-in must exist and be documented on a Mantis ticket (and on a
  TianoCore bugzilla) before we tag an edk2-stableMM release with
  the PPI removed from edk2,

- the series that removes the PPI should update all platforms in edk2
  and preferably edk2-platforms too that currently produce the PPI,

- merging the v2 series first (with clearly marked ownership /
  maintenance) would be nice (but not a hard req), in order to keep
  compat with PI until PI is actually updated.

My two cents...

Thanks,
Laszlo

> Alternatives: Continue to support the PPI, but we would need to merge
> a bug-fix patchset which adds some assembly code into the PEI Core.
> 
> More details:
> 
> I discussed this topic with the Tianocore Stewards, Vincent and Ray.
> Although the path forward was not unanimous, it appears that the
> majority thought we should propose to remove support for the
> TemporaryRamSupport PPI from the PEI Core.
> 
> This PPI is defined in MdePkg/Include/Ppi/TemporaryRamSupport.h. I
> believe it has been present in all versions of the Platorm
> Initialization Specificication, including the latest, version 1.7.
> (https://uefi.org/specsandtesttools)
> 
> The TemporaryRamSupport PPI is defined as "optional" in the PI spec,
> but I believe this only applied to producers of the PPI (PI
> platforms). The PEI Core (which is the consumer of this PPI) should
> arguably support the PPI in order to fully support PI spec based
> platforms.
> 
> But, there are some subtle issues with the PPI that make it difficult
> to implement for both the consumer (PEI Core) and the producer (the
> platform). In fact, there is a bug currently with the PEI Core's
> implementation, which I sent a patch series to address on April 10th,
> with the subject of "[PATCH v2 0/6] Fix PEI Core issue during
> TemporaryRamMigration".
> 
> Unfortunately the 

Re: [edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Andrew Fish via Groups.Io]

The intent of the protective MBR was to prevent tools that did not understand 
GPT to not think a GPT disk was blank. 20 years ago that made a lot of sense, 
today it is kind of an obsolete concept.

The protective MBR was never intended to identify the disk as GPT, but it seems 
it got used as a short cut to not have to read a variable number of blocks from 
the disk to validate the GPT header. 

>From a practical sense the DXE Partition driver uses this algorithm to 
>validate the Protective MBR. It would be a good idea for the PEI code to do 
>the same thing. 

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c

  //
  // Verify that the Protective MBR is valid
  //
  for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
) {
  break;
}
  }
  if (Index == MAX_MBR_PARTITIONS) {
goto Done;
  }

I'd also point out that that ATA-6 specification obsoleted CHS addressing in 
2002 and I think the 0x200 has to do with the sector size of 512 bytes, which 
is also kind of an obsolete concept. So I'm not sure what the 0x100 is about in 
your example?

Thanks,

Andrew Fish

> On Apr 24, 2019, at 4:36 AM, Xu, Wei6  wrote:
> 
> Hi,
>  
> I have a question about protective MBR. Thanks a lot for your time.
> Why is the StartingCHS of protective MBR partition record set to 0x000100 in 
> RedHat / Ubuntu? While UEFI spec defines it as 0x000200.
>  
> Problem Statement:
> I met a problem when trying to use FatPei to fetch a file on the GPT 
> partition of RedHat/Ubuntu in TCB.
> FatPei has a check about Partition Record of protective MBR: StartingCHS 
> should to 0x000200.
> But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that the 
> check fails.
>  
> According to UEFI spec, StartingCHS should be 0x000200.  
>  
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39510): https://edk2.groups.io/g/devel/message/39510
Mute This Topic: https://groups.io/mt/31320822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/5] patches for some warnings raised by "RH covscan"

[Laszlo Ersek]

On 04/18/19 19:47, Laszlo Ersek wrote:
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
> Repo: https://github.com/lersek/edk2.git
> Branch:   covscan_bz_1710_v2
> 
> Patch-level updates relative to v1 have been noted on the patches
> themselves. And earlier I described the changes to the series's
> structure at .
> 
> Cc: Ard Biesheuvel 
> Cc: Bob Feng 
> Cc: Jordan Justen 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Yonghong Zhu 
> 
> Thanks
> Laszlo
> 
> Laszlo Ersek (5):
>   MdePkg/PiFirmwareFile: express IS_SECTION2 in terms of SECTION_SIZE
>   MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE
>   BaseTools/PiFirmwareFile: fix undefined behavior in SECTION_SIZE
>   MdePkg/PiFirmwareFile: fix undefined behavior in FFS_FILE_SIZE
>   OvmfPkg/Sec: fix out-of-bounds reads
> 
>  BaseTools/Source/C/Include/Common/PiFirmwareFile.h | 11 +++--
>  MdePkg/Include/Pi/PiFirmwareFile.h | 26 +++-
>  OvmfPkg/Sec/SecMain.c  |  6 ++---
>  3 files changed, 32 insertions(+), 11 deletions(-)
> 

Series pushed as commit range 1a734ed85fda..b9d4847ec258.

Thank you all,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39509): https://edk2.groups.io/g/devel/message/39509
Mute This Topic: https://groups.io/mt/31233845/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Emulator: update binary AARCH64 build of X64 PE/COFF emulator

[Laszlo Ersek]

Hi Ard,

On 04/23/19 22:21, Ard Biesheuvel wrote:
> Update the binary RELEASE build targeting AARCH64 systems, created
> with Ubuntu's gcc 7.3.0 using the GCC5 profile. This fixes an issue
> in the previous build which was built against the wrong version of
> CacheMaintenanceLib.
> 
> Repo:   http://github.com/ardbiesheuvel/X86EmulatorPkg.git
> Commit: 4b3f43430729d2d9569b13743e3e7133ea502d91
> 
>   4b3f43430729 Use the correct version of CacheMaintenanceLib
>   67d5dd9ff915 Update README to reflect upstream status
> 
> Repo:   http://github.com/tiancore/edk2.git
> Commit: 2c0d39ac4704b76b7efb67b0aee23c2e78045cbc
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> Full patch can be found at
> https://git.linaro.org/leg/noupstream/edk2-non-osi.git/log/?h=upstream

Does this mean that the patch is for the edk2-non-osi repo? ... That
seems to be the case:

https://github.com/tianocore/edk2-non-osi

Please put [edk2-non-osi PATCH] in the subject prefix next time :)

Thanks
Laszlo

> 
>  Emulator/X86EmulatorDxe/X86EmulatorDxe.depex | Bin 54 -> 36 bytes
>  Emulator/X86EmulatorDxe/X86EmulatorDxe.efi   | Bin 913408 -> 913408 bytes
>  2 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex
> index ffce8c06d8a5..addc7467048e 100644
> Binary files a/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex and 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.depex differ
> diff --git a/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi
> index 316ef245f834..6e71de70ba76 100644
> Binary files a/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi and 
> b/Emulator/X86EmulatorDxe/X86EmulatorDxe.efi differ
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39508): https://edk2.groups.io/g/devel/message/39508
Mute This Topic: https://groups.io/mt/31315294/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms/devel-MinPlatform][PATCH 3/5] LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem

[Kwolek, Adam]

Hi,
For me it looks good also,
I do not see any change that will not allow to call WS ME on reset (as we 
currently have for Workstation).

BR
Adam


> -Original Message-
> From: Piwko, Maciej
> Sent: Wednesday, April 24, 2019 3:45 PM
> To: Gao, Zhichao ; Bu, Daocheng
> ; devel@edk2.groups.io; Kwolek, Adam
> 
> Cc: Oram, Isaac W ; Gao, Liming
> 
> Subject: RE: [edk2-platforms/devel-MinPlatform][PATCH 3/5]
> LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem
> 
> Hi,
> 
> For me the change seems fine.
> The only concern that I have may be related to the fact, the resetting the
> system we may also want to inform the ME engine about that fact and choose
> proper reset type.
> I'm adding Adam, who can comment on the reset functionality from ME
> UEFIFW perspective.
> 
> Adam, could you also look at this change?
> 
> Thanks,
> Maciej
> 
> 
> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, April 22, 2019 4:50 AM
> To: Bu, Daocheng ; devel@edk2.groups.io
> Cc: Piwko, Maciej ; Oram, Isaac W
> ; Gao, Liming 
> Subject: RE: [edk2-platforms/devel-MinPlatform][PATCH 3/5]
> LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem
> 
> Hi,
> 
> I didn't receive any comments with this patch yet. Maybe you missed this
> email.
> The new added function is only a few part of the ResetSystemRuntimeDxe to
> provide the reset function.
> As I know, platforms always have their own ResetSystemLib instance and do
> not use the instance in MdeModulePkg.
> While the platform contains a driver base on the new interface(the driver may
> be in the edk2 repo), the driver would not find the interface's implement and
> cause a link error.
> I suggest all platform code should update it to avoid the link error if the
> platform is working with the edk2 master repo.
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: Bu, Daocheng
> > Sent: Monday, April 15, 2019 3:56 PM
> > To: Gao, Zhichao ; devel@edk2.groups.io
> > Cc: Piwko, Maciej ; Oram, Isaac W
> > ; Gao, Liming 
> > Subject: RE: [edk2-platforms/devel-MinPlatform][PATCH 3/5]
> > LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem
> >
> >
> > Hi Maciej,
> >
> >  Please help review this code from PCH perspective.
> >  If you approve this change , please also help cherry pick this change
> > to ServerSiliconPkg\Pch\SouthClusterLbg pkg @10nm trunk.
> >
> > Thanks,
> >   Amos
> >
> > UEFI FW, IAFW or System Firmware is more generic & accurate it's not
> > BIOS anymore!
> >
> > -Original Message-
> > From: Gao, Zhichao
> > Sent: Monday, April 15, 2019 11:08 AM
> > To: devel@edk2.groups.io
> > Cc: Piwko, Maciej ; Bu, Daocheng
> > ; Oram, Isaac W ; Gao,
> > Liming 
> > Subject: [edk2-platforms/devel-MinPlatform][PATCH 3/5]
> > LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> >
> > Add a new API ResetSystem to this ResetSystemLib instance.
> > It only adds the basic functions from ResetSystemRuntimeDxe.
> > Lacking of this interface may cause link error, if some drivers use
> > this new API and link to this library instance.
> > Make the ResetPlatformSpecific's parameters same with the interface in
> > Edk2 repo.
> > Notes:
> > This library API only provide a basic function of reset. If the
> > consumers want full functions, they should use the instance in the
> > MdeModulePkg and make sure the depex driver is dispatched.
> >
> > Cc: "Piwko, Maciej" 
> > Cc: "Bu, Daocheng" 
> > Cc: "Oram, Isaac W" 
> > Cc: Liming Gao 
> > Signed-off-by: Zhichao Gao 
> > ---
> >  .../DxeRuntimeResetSystemLib/PchReset.c   | 47 +--
> >  1 file changed, 44 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchReset.
> > c
> > b/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchReset.
> > c
> > index cdc0f19c17..673f42e72c 100644
> > ---
> > a/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchReset.
> > c
> > +++
> > b/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchRes
> > +++ et.c
> > @@ -1,6 +1,6 @@
> >  /** @file
> >
> > -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 that
> > accompanies this distribution.
> >  The full text of the license may be found at @@ -255,7 +255,6 @@
> > ResetShutdown (
> >  /**
> >Calling this function causes the system to enter a power state for
> > platform specific.
> >
> > -  @param[in] ResetStatus  The status code for the reset.
> >@param[in] DataSize The size of ResetData in bytes.
> >@param[in] ResetDataOptional element used to introduce a
> platform
> > specific reset.
> >The exact type of 

Re: [edk2-devel] [edk2-platforms: PATCH v2 3/3] Marvell/Drivers: Add non-mmio mode to MvFvbDxe

[Marcin Wojtas]

śr., 24 kwi 2019 o 15:51 Ard Biesheuvel  napisał(a):
>
> On Wed, 24 Apr 2019 at 15:48, Marcin Wojtas  wrote:
> >
> > Hi Ard,
> >
> > śr., 24 kwi 2019 o 15:02 Ard Biesheuvel  
> > napisał(a):
> > >
> > > On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel  
> > > wrote:
> > > >
> > > > On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas  wrote:
> > > > >
> > > > > From: Kornel Duleba 
> > > > >
> > > > > This path enables support for reading variables directly from flash 
> > > > > without
> > > > > relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
> > > > > allows to switch between the modes. When in non-memory-mapped mode the
> > > > > driver will copy the variables from flash to previously allocated 
> > > > > buffer
> > > > > and set PcdFlashNvStorageVariableBase64, 
> > > > > PcdFlashNvStorageFtwWorkingBase64
> > > > > and PcdFlashNvStorageFtwSpareBase64 accordingly.
> > > > >
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Marcin Wojtas 
> > > > > ---
> > > > >  Silicon/Marvell/Marvell.dec   |   8 ++
> > > > >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  10 +-
> > > > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
> > > > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
> > > > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 135 
> > > > > +++-
> > > > >  5 files changed, 135 insertions(+), 36 deletions(-)
> > > > >
> > > > > diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> > > > > index 7210ba2..a23c329 100644
> > > > > --- a/Silicon/Marvell/Marvell.dec
> > > > > +++ b/Silicon/Marvell/Marvell.dec
> > > > > @@ -58,6 +58,12 @@
> > > > >
> > > > >gMarvellFvbDxeGuid = { 0x42903750, 0x7e61, 0x4aaf, { 0x83, 0x29, 
> > > > > 0xbf, 0x42, 0x36, 0x4e, 0x24, 0x85 } }
> > > > >gMarvellSpiFlashDxeGuid = { 0x49d7fb74, 0x306d, 0x42bd, { 0x94, 
> > > > > 0xc8, 0xc0, 0xc5, 0x4b, 0x18, 0x1d, 0xd7 } }
> > > > > +  #
> > > > > +  # Generic FaultTolerantWriteDxe driver use variables,
> > > > > +  # whose setting is done in MvFvbDxe driver in case
> > > > > +  # the SPI contents are not mapped in memory.
> > > > > +  #
> > > > > +  gFaultTolerantWriteDxeFileGuid = { 0xfe5cea76, 0x4f72, 0x49e8, { 
> > > > > 0x98, 0x6f, 0x2c, 0xd8, 0x99, 0xdf, 0xfe, 0x5d} }
> > > > >
> > > > >  [LibraryClasses]
> > > > >ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
> > > > > @@ -140,6 +146,8 @@
> > > > >  #SPI
> > > > >gMarvellTokenSpaceGuid.PcdSpiRegBase|0|UINT32|0x351
> > > > >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0|UINT64|0x359
> > > > > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE|BOOLEAN|0x360
> > > > > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0|UINT32|0x361
> > > > >gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|0|UINT32|0x3052
> > > > >gMarvellTokenSpaceGuid.PcdSpiClockFrequency|0|UINT32|0x3053
> > > > >
> > > > > diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> > > > > b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > > > index ca3de2e..d53d128 100644
> > > > > --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > > > +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > > > @@ -256,6 +256,11 @@
> > > > ># USB support
> > > > >gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
> > > > >
> > > > > +[PcdsDynamicDefault.common]
> > > > > +  
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > > > > +  
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > > > > +  
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > > > > +
> > > > >  [PcdsFixedAtBuild.common]
> > > > >
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"MARVELL_EFI"
> > > > >gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> > > > > @@ -396,11 +401,10 @@
> > > > ># Variable store - default values
> > > > >#
> > > > >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
> > > > > -  
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > > > > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE
> > > > > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0x3C
> > > > >
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> > > > > -  
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > > > >
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> > > > > -  
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > > > >
> > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
> > > > >
> > > > >  !if $(CAPSULE_ENABLE)
> > > > > diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf 
> > > > > b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > > > index 

[edk2-devel] reg: reg : HTTP Download Performance

[Sivaraman Nainar]

Hello All:

Would like to clarify few information on the timings on the HTTP Boot / 
Download performed through  Windows / Linux and UEFI HTTP Boot.

There was a HTTP server running in California and when an 450 MB ISO tried to 
downloaded from that below are the time took to download. The data retroeived 
with the same Platform and same controller.

UEFI HTTP:
1529 seconds
310128 Bytes/seconds

Windows wget:
255 seconds
1859551 Bytes/seconds

The performance is still high (over 100MB/s) if the server is in LAN.

When we tried to change MNP_SYS_POLL_INTERVAL from (10 * TICKS_PER_MS) to (5 * 
TICKS_PER_MS) it does not give big change in download time.

Is there any other way to increase the speed or its limitation due to the 
single threaded execution.

-Siva


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39505): https://edk2.groups.io/g/devel/message/39505
Mute This Topic: https://groups.io/mt/31322238/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms/devel-MinPlatform][PATCH 3/5] LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem

[Piwko, Maciej]

Hi,

For me the change seems fine.
The only concern that I have may be related to the fact, the resetting the 
system we may also want to inform the ME engine about that fact and choose 
proper reset type.
I'm adding Adam, who can comment on the reset functionality from ME UEFIFW 
perspective.

Adam, could you also look at this change?

Thanks,
Maciej


-Original Message-
From: Gao, Zhichao 
Sent: Monday, April 22, 2019 4:50 AM
To: Bu, Daocheng ; devel@edk2.groups.io
Cc: Piwko, Maciej ; Oram, Isaac W 
; Gao, Liming 
Subject: RE: [edk2-platforms/devel-MinPlatform][PATCH 3/5] 
LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem

Hi,

I didn't receive any comments with this patch yet. Maybe you missed this email.
The new added function is only a few part of the ResetSystemRuntimeDxe to 
provide the reset function.
As I know, platforms always have their own ResetSystemLib instance and do not 
use the instance in MdeModulePkg.
While the platform contains a driver base on the new interface(the driver may 
be in the edk2 repo), the driver would not find the interface's implement and 
cause a link error.
I suggest all platform code should update it to avoid the link error if the 
platform is working with the edk2 master repo.

Thanks,
Zhichao

> -Original Message-
> From: Bu, Daocheng
> Sent: Monday, April 15, 2019 3:56 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Piwko, Maciej ; Oram, Isaac W 
> ; Gao, Liming 
> Subject: RE: [edk2-platforms/devel-MinPlatform][PATCH 3/5]
> LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem
> 
> 
> Hi Maciej,
> 
>  Please help review this code from PCH perspective.
>  If you approve this change , please also help cherry pick this change 
> to ServerSiliconPkg\Pch\SouthClusterLbg pkg @10nm trunk.
> 
> Thanks,
>   Amos
> 
> UEFI FW, IAFW or System Firmware is more generic & accurate it's not 
> BIOS anymore!
> 
> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, April 15, 2019 11:08 AM
> To: devel@edk2.groups.io
> Cc: Piwko, Maciej ; Bu, Daocheng 
> ; Oram, Isaac W ; Gao, 
> Liming 
> Subject: [edk2-platforms/devel-MinPlatform][PATCH 3/5]
> LewisburgPkg/DxeRuntimeResetSystemLib: Add a new API ResetSystem
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
> 
> Add a new API ResetSystem to this ResetSystemLib instance.
> It only adds the basic functions from ResetSystemRuntimeDxe.
> Lacking of this interface may cause link error, if some drivers use 
> this new API and link to this library instance.
> Make the ResetPlatformSpecific's parameters same with the interface in
> Edk2 repo.
> Notes:
> This library API only provide a basic function of reset. If the 
> consumers want full functions, they should use the instance in the 
> MdeModulePkg and make sure the depex driver is dispatched.
> 
> Cc: "Piwko, Maciej" 
> Cc: "Bu, Daocheng" 
> Cc: "Oram, Isaac W" 
> Cc: Liming Gao 
> Signed-off-by: Zhichao Gao 
> ---
>  .../DxeRuntimeResetSystemLib/PchReset.c   | 47 +--
>  1 file changed, 44 insertions(+), 3 deletions(-)
> 
> diff --git
> a/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchReset.
> c
> b/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchReset.
> c
> index cdc0f19c17..673f42e72c 100644
> ---
> a/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchReset.
> c
> +++
> b/Silicon/Intel/LewisburgPkg/Library/DxeRuntimeResetSystemLib/PchRes
> +++ et.c
> @@ -1,6 +1,6 @@
>  /** @file
> 
> -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 that 
> accompanies this distribution.
>  The full text of the license may be found at @@ -255,7 +255,6 @@ 
> ResetShutdown (
>  /**
>Calling this function causes the system to enter a power state for 
> platform specific.
> 
> -  @param[in] ResetStatus  The status code for the reset.
>@param[in] DataSize The size of ResetData in bytes.
>@param[in] ResetDataOptional element used to introduce a 
> platform
> specific reset.
>The exact type of the reset is 
> defined by the EFI_GUID that follows @@ -265,7 +264,6 @@ ResetShutdown 
> (  VOID  EFIAPI ResetPlatformSpecific (
> -  IN EFI_STATUS   ResetStatus,
>IN UINTNDataSize,
>IN VOID *ResetData OPTIONAL
>)
> @@ -306,6 +304,49 @@ EnterS3WithImmediateWake (
>PchReset (mPchResetInstance, (PCH_RESET_TYPE) EfiResetWarm);  }
> 
> +/**
> +  The ResetSystem function resets the entire platform.
> +
> +  @param[in] ResetType  The type of reset to perform.
> +  @param[in] ResetStatusThe status code for the reset.
> +  @param[in] DataSize   The size, in bytes, of ResetData.
> +  @param[in] ResetData  For a ResetType of EfiResetCold, 

Re: [edk2-devel] [edk2-platforms: PATCH v2 3/3] Marvell/Drivers: Add non-mmio mode to MvFvbDxe

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 15:48, Marcin Wojtas  wrote:
>
> Hi Ard,
>
> śr., 24 kwi 2019 o 15:02 Ard Biesheuvel  
> napisał(a):
> >
> > On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel  
> > wrote:
> > >
> > > On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas  wrote:
> > > >
> > > > From: Kornel Duleba 
> > > >
> > > > This path enables support for reading variables directly from flash 
> > > > without
> > > > relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
> > > > allows to switch between the modes. When in non-memory-mapped mode the
> > > > driver will copy the variables from flash to previously allocated buffer
> > > > and set PcdFlashNvStorageVariableBase64, 
> > > > PcdFlashNvStorageFtwWorkingBase64
> > > > and PcdFlashNvStorageFtwSpareBase64 accordingly.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Marcin Wojtas 
> > > > ---
> > > >  Silicon/Marvell/Marvell.dec   |   8 ++
> > > >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  10 +-
> > > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
> > > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
> > > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 135 
> > > > +++-
> > > >  5 files changed, 135 insertions(+), 36 deletions(-)
> > > >
> > > > diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> > > > index 7210ba2..a23c329 100644
> > > > --- a/Silicon/Marvell/Marvell.dec
> > > > +++ b/Silicon/Marvell/Marvell.dec
> > > > @@ -58,6 +58,12 @@
> > > >
> > > >gMarvellFvbDxeGuid = { 0x42903750, 0x7e61, 0x4aaf, { 0x83, 0x29, 
> > > > 0xbf, 0x42, 0x36, 0x4e, 0x24, 0x85 } }
> > > >gMarvellSpiFlashDxeGuid = { 0x49d7fb74, 0x306d, 0x42bd, { 0x94, 
> > > > 0xc8, 0xc0, 0xc5, 0x4b, 0x18, 0x1d, 0xd7 } }
> > > > +  #
> > > > +  # Generic FaultTolerantWriteDxe driver use variables,
> > > > +  # whose setting is done in MvFvbDxe driver in case
> > > > +  # the SPI contents are not mapped in memory.
> > > > +  #
> > > > +  gFaultTolerantWriteDxeFileGuid = { 0xfe5cea76, 0x4f72, 0x49e8, { 
> > > > 0x98, 0x6f, 0x2c, 0xd8, 0x99, 0xdf, 0xfe, 0x5d} }
> > > >
> > > >  [LibraryClasses]
> > > >ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
> > > > @@ -140,6 +146,8 @@
> > > >  #SPI
> > > >gMarvellTokenSpaceGuid.PcdSpiRegBase|0|UINT32|0x351
> > > >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0|UINT64|0x359
> > > > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE|BOOLEAN|0x360
> > > > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0|UINT32|0x361
> > > >gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|0|UINT32|0x3052
> > > >gMarvellTokenSpaceGuid.PcdSpiClockFrequency|0|UINT32|0x3053
> > > >
> > > > diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> > > > b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > > index ca3de2e..d53d128 100644
> > > > --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > > +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > > @@ -256,6 +256,11 @@
> > > ># USB support
> > > >gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
> > > >
> > > > +[PcdsDynamicDefault.common]
> > > > +  
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > > > +  
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > > > +  
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > > > +
> > > >  [PcdsFixedAtBuild.common]
> > > >
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"MARVELL_EFI"
> > > >gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> > > > @@ -396,11 +401,10 @@
> > > ># Variable store - default values
> > > >#
> > > >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
> > > > -  
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > > > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE
> > > > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0x3C
> > > >
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> > > > -  
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > > >
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> > > > -  
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > > >
> > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
> > > >
> > > >  !if $(CAPSULE_ENABLE)
> > > > diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf 
> > > > b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > > index ef10bfd..c85e8a6 100644
> > > > --- a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > > +++ b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > > @@ -76,13 +76,22 @@
> > > >gMarvellSpiMasterProtocolGuid
> > > >
> > > >  [FixedPcd]
> > > > -  

Re: [edk2-devel] [edk2-platforms: PATCH v2 3/3] Marvell/Drivers: Add non-mmio mode to MvFvbDxe

[Marcin Wojtas]

Hi Ard,

śr., 24 kwi 2019 o 15:02 Ard Biesheuvel  napisał(a):
>
> On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel  
> wrote:
> >
> > On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas  wrote:
> > >
> > > From: Kornel Duleba 
> > >
> > > This path enables support for reading variables directly from flash 
> > > without
> > > relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
> > > allows to switch between the modes. When in non-memory-mapped mode the
> > > driver will copy the variables from flash to previously allocated buffer
> > > and set PcdFlashNvStorageVariableBase64, PcdFlashNvStorageFtwWorkingBase64
> > > and PcdFlashNvStorageFtwSpareBase64 accordingly.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Marcin Wojtas 
> > > ---
> > >  Silicon/Marvell/Marvell.dec   |   8 ++
> > >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  10 +-
> > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
> > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
> > >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 135 
> > > +++-
> > >  5 files changed, 135 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> > > index 7210ba2..a23c329 100644
> > > --- a/Silicon/Marvell/Marvell.dec
> > > +++ b/Silicon/Marvell/Marvell.dec
> > > @@ -58,6 +58,12 @@
> > >
> > >gMarvellFvbDxeGuid = { 0x42903750, 0x7e61, 0x4aaf, { 0x83, 0x29, 0xbf, 
> > > 0x42, 0x36, 0x4e, 0x24, 0x85 } }
> > >gMarvellSpiFlashDxeGuid = { 0x49d7fb74, 0x306d, 0x42bd, { 0x94, 0xc8, 
> > > 0xc0, 0xc5, 0x4b, 0x18, 0x1d, 0xd7 } }
> > > +  #
> > > +  # Generic FaultTolerantWriteDxe driver use variables,
> > > +  # whose setting is done in MvFvbDxe driver in case
> > > +  # the SPI contents are not mapped in memory.
> > > +  #
> > > +  gFaultTolerantWriteDxeFileGuid = { 0xfe5cea76, 0x4f72, 0x49e8, { 0x98, 
> > > 0x6f, 0x2c, 0xd8, 0x99, 0xdf, 0xfe, 0x5d} }
> > >
> > >  [LibraryClasses]
> > >ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
> > > @@ -140,6 +146,8 @@
> > >  #SPI
> > >gMarvellTokenSpaceGuid.PcdSpiRegBase|0|UINT32|0x351
> > >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0|UINT64|0x359
> > > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE|BOOLEAN|0x360
> > > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0|UINT32|0x361
> > >gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|0|UINT32|0x3052
> > >gMarvellTokenSpaceGuid.PcdSpiClockFrequency|0|UINT32|0x3053
> > >
> > > diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> > > b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > index ca3de2e..d53d128 100644
> > > --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > @@ -256,6 +256,11 @@
> > ># USB support
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
> > >
> > > +[PcdsDynamicDefault.common]
> > > +  
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > > +  
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > > +  
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > > +
> > >  [PcdsFixedAtBuild.common]
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"MARVELL_EFI"
> > >gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> > > @@ -396,11 +401,10 @@
> > ># Variable store - default values
> > >#
> > >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
> > > -  
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE
> > > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0x3C
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> > > -  
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > >
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> > > -  
> > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
> > >
> > >  !if $(CAPSULE_ENABLE)
> > > diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf 
> > > b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > index ef10bfd..c85e8a6 100644
> > > --- a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > +++ b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > > @@ -76,13 +76,22 @@
> > >gMarvellSpiMasterProtocolGuid
> > >
> > >  [FixedPcd]
> > > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
> > > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
> > > -  

Re: [edk2-devel] [PATCH edk2-platforms v2 0/3] add X64 PE/COFF emulator to PCI systems

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 15:33, Leif Lindholm  wrote:
>
> On Wed, Apr 24, 2019 at 03:23:54PM +0200, Ard Biesheuvel wrote:
> > Add a conditional build time include of the prebuild X64 PE/COFF emulator
> > binary to some platforms that will be able to make use of it (i.e., have
> > usable PCI slots)
> >
> > Changes since v1:
> > - add Armada entry to the shared .fdf, and drop the default FALSE value (at
> >   the request of Marcin)
>
> For the series:
> Reviewed-by: Leif Lindholm 
>

Thanks

Pushed as 3826301c6426..bcdcb65cc077

> > Ard Biesheuvel (3):
> >   Platform/DeveloperBox: conditionally include the X64 PE/COFF emulator
> >   Platform/Overdrive: conditionally include the X64 PE/COFF emulator
> >   Platform/MacchiatoBin: conditionally include the X64 PE/COFF emulator
> >
> >  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 5 +++--
> >  Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
> >  Platform/AMD/OverdriveBoard/OverdriveBoard.fdf   | 3 +++
> >  Platform/Socionext/DeveloperBox/DeveloperBox.fdf | 3 +++
> >  Silicon/Marvell/Armada7k8k/Armada7k8k.fdf| 4 
> >  5 files changed, 14 insertions(+), 2 deletions(-)
> >
> > --
> > 2.20.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39501): https://edk2.groups.io/g/devel/message/39501
Mute This Topic: https://groups.io/mt/31321811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms] Silicon/AMD/Styx: remove the non-capsule based flasher tool

[Leif Lindholm]

On Wed, Apr 24, 2019 at 03:29:52PM +0200, Ard Biesheuvel wrote:
> We have had capsule support enabled on this platform for a while now, so
> let's drop the hacked up flasher tool that we no longer have a need for.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  |  8 --
>  Platform/LeMaker/CelloBoard/CelloBoard.dsc  |  8 --
>  Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc |  8 --
>  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf   | 53 
> ---
>  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.c | 96 
> 
>  Silicon/AMD/Styx/Applications/StyxFlashUefi/Scripts/GccBase.lds | 86 
> --
>  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashImage.S| 25 -
>  7 files changed, 284 deletions(-)
> 
> diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
> b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
> index 0e1db0745d89..616553172bf0 100644
> --- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
> +++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
> @@ -18,7 +18,6 @@
>  [Defines]
>  
>  DEFINE NUM_CORES  = 8
> -DEFINE DO_FLASHER = FALSE
>  DEFINE X64EMU_ENABLE  = FALSE
>  
>PLATFORM_NAME  = Overdrive
> @@ -747,13 +746,6 @@ DEFINE X64EMU_ENABLE  = FALSE
>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
>}
>  
> -!if $(DO_FLASHER) == TRUE
> -  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf {
> -
> -  
> ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
> -  }
> -!endif
> -
>#
># Firmware update
>#
> diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
> b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
> index 56a31a97a4ec..c26d38226cd2 100644
> --- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
> +++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
> @@ -18,7 +18,6 @@
>  [Defines]
>  
>  DEFINE NUM_CORES= 4
> -DEFINE DO_FLASHER   = FALSE
>  
>PLATFORM_NAME  = Cello
>PLATFORM_GUID  = 77861b3e-74b0-4ff3-8d18-c5ba5803e1bf
> @@ -676,10 +675,3 @@ DEFINE DO_FLASHER   = FALSE
>  !ifdef $(RENESAS_XHCI_FW_DIR)
>
> OpenPlatformPkg/Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.inf
>  !endif
> -
> -!if $(DO_FLASHER) == TRUE
> -  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf {
> -
> -  
> ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
> -  }
> -!endif
> diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
> b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
> index 6ae0f2620c38..4fbc4201cf6b 100644
> --- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
> +++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
> @@ -18,7 +18,6 @@
>  [Defines]
>  
>  DEFINE NUM_CORES= 4
> -DEFINE DO_FLASHER   = FALSE
>  
>PLATFORM_NAME  = Overdrive1000
>PLATFORM_GUID  = 36774DD7-20DE-4C5B-8722-f8861DFF1F16
> @@ -668,10 +667,3 @@ DEFINE DO_FLASHER   = FALSE
>gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
>}
> -
> -!if $(DO_FLASHER) == TRUE
> -  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf {
> -
> -  
> ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
> -  }
> -!endif
> diff --git a/Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf 
> b/Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf
> deleted file mode 100644
> index 0c289dcf95f4..
> --- a/Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf
> +++ /dev/null
> @@ -1,53 +0,0 @@
> -#/** @file
> -#
> -#  Copyright (c) 2017, 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.
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 0x00010019
> -  BASE_NAME  = StyxFlashUefi
> -  FILE_GUID  = 07b65d9d-b1a2-416e-bd04-0b61b775f924
> -  MODULE_TYPE= UEFI_APPLICATION
> -  VERSION_STRING = 0.1
> -  ENTRY_POINT= ShellCEntryLib
> -
> -#
> -#  VALID_ARCHITECTURES   = AARCH64
> -#
> -
> -[Sources]
> -  StyxFlashImage.S
> -  StyxFlashUefi.c
> -
> -[Packages]
> -  ArmPkg/ArmPkg.dec
> -  MdePkg/MdePkg.dec

Re: [edk2-devel] [PATCH edk2-platforms v2 0/3] add X64 PE/COFF emulator to PCI systems

[Leif Lindholm]

On Wed, Apr 24, 2019 at 03:23:54PM +0200, Ard Biesheuvel wrote:
> Add a conditional build time include of the prebuild X64 PE/COFF emulator
> binary to some platforms that will be able to make use of it (i.e., have
> usable PCI slots)
> 
> Changes since v1:
> - add Armada entry to the shared .fdf, and drop the default FALSE value (at
>   the request of Marcin)

For the series:
Reviewed-by: Leif Lindholm 

> Ard Biesheuvel (3):
>   Platform/DeveloperBox: conditionally include the X64 PE/COFF emulator
>   Platform/Overdrive: conditionally include the X64 PE/COFF emulator
>   Platform/MacchiatoBin: conditionally include the X64 PE/COFF emulator
> 
>  Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 5 +++--
>  Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
>  Platform/AMD/OverdriveBoard/OverdriveBoard.fdf   | 3 +++
>  Platform/Socionext/DeveloperBox/DeveloperBox.fdf | 3 +++
>  Silicon/Marvell/Armada7k8k/Armada7k8k.fdf| 4 
>  5 files changed, 14 insertions(+), 2 deletions(-)
> 
> -- 
> 2.20.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39499): https://edk2.groups.io/g/devel/message/39499
Mute This Topic: https://groups.io/mt/31321811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms] Silicon/AMD/Styx: remove the non-capsule based flasher tool

[Ard Biesheuvel]

We have had capsule support enabled on this platform for a while now, so
let's drop the hacked up flasher tool that we no longer have a need for.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc  |  8 --
 Platform/LeMaker/CelloBoard/CelloBoard.dsc  |  8 --
 Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc |  8 --
 Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf   | 53 
---
 Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.c | 96 

 Silicon/AMD/Styx/Applications/StyxFlashUefi/Scripts/GccBase.lds | 86 
--
 Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashImage.S| 25 -
 7 files changed, 284 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index 0e1db0745d89..616553172bf0 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -18,7 +18,6 @@
 [Defines]
 
 DEFINE NUM_CORES  = 8
-DEFINE DO_FLASHER = FALSE
 DEFINE X64EMU_ENABLE  = FALSE
 
   PLATFORM_NAME  = Overdrive
@@ -747,13 +746,6 @@ DEFINE X64EMU_ENABLE  = FALSE
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
   }
 
-!if $(DO_FLASHER) == TRUE
-  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf {
-
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-  }
-!endif
-
   #
   # Firmware update
   #
diff --git a/Platform/LeMaker/CelloBoard/CelloBoard.dsc 
b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
index 56a31a97a4ec..c26d38226cd2 100644
--- a/Platform/LeMaker/CelloBoard/CelloBoard.dsc
+++ b/Platform/LeMaker/CelloBoard/CelloBoard.dsc
@@ -18,7 +18,6 @@
 [Defines]
 
 DEFINE NUM_CORES= 4
-DEFINE DO_FLASHER   = FALSE
 
   PLATFORM_NAME  = Cello
   PLATFORM_GUID  = 77861b3e-74b0-4ff3-8d18-c5ba5803e1bf
@@ -676,10 +675,3 @@ DEFINE DO_FLASHER   = FALSE
 !ifdef $(RENESAS_XHCI_FW_DIR)
   
OpenPlatformPkg/Drivers/Xhci/RenesasFirmwarePD720202/RenesasFirmwarePD720202.inf
 !endif
-
-!if $(DO_FLASHER) == TRUE
-  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf {
-
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-  }
-!endif
diff --git a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc 
b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
index 6ae0f2620c38..4fbc4201cf6b 100644
--- a/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
+++ b/Platform/SoftIron/Overdrive1000Board/Overdrive1000Board.dsc
@@ -18,7 +18,6 @@
 [Defines]
 
 DEFINE NUM_CORES= 4
-DEFINE DO_FLASHER   = FALSE
 
   PLATFORM_NAME  = Overdrive1000
   PLATFORM_GUID  = 36774DD7-20DE-4C5B-8722-f8861DFF1F16
@@ -668,10 +667,3 @@ DEFINE DO_FLASHER   = FALSE
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
   }
-
-!if $(DO_FLASHER) == TRUE
-  Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf {
-
-  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
-  }
-!endif
diff --git a/Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf 
b/Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf
deleted file mode 100644
index 0c289dcf95f4..
--- a/Silicon/AMD/Styx/Applications/StyxFlashUefi/StyxFlashUefi.inf
+++ /dev/null
@@ -1,53 +0,0 @@
-#/** @file
-#
-#  Copyright (c) 2017, 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.
-#
-#**/
-
-[Defines]
-  INF_VERSION= 0x00010019
-  BASE_NAME  = StyxFlashUefi
-  FILE_GUID  = 07b65d9d-b1a2-416e-bd04-0b61b775f924
-  MODULE_TYPE= UEFI_APPLICATION
-  VERSION_STRING = 0.1
-  ENTRY_POINT= ShellCEntryLib
-
-#
-#  VALID_ARCHITECTURES   = AARCH64
-#
-
-[Sources]
-  StyxFlashImage.S
-  StyxFlashUefi.c
-
-[Packages]
-  ArmPkg/ArmPkg.dec
-  MdePkg/MdePkg.dec
-  ShellPkg/ShellPkg.dec
-  Silicon/AMD/Styx/AmdModulePkg/AmdModulePkg.dec
-
-[LibraryClasses]
-  BaseMemoryLib
-  ShellCEntryLib
-  UefiBootServicesTableLib
-  UefiLib
-
-[Protocols]
-  gAmdIscpDxeProtocolGuid
-
-[FixedPcd]
-  gArmTokenSpaceGuid.PcdFdBaseAddress
-  gArmTokenSpaceGuid.PcdFvBaseAddress
-
-[BuildOptions]
-  *_*_*_CC_FLAGS = -mcmodel=small
-  *_*_*_DLINK_FLAGS 

[edk2-devel] [PATCH edk2-platforms v2 2/3] Platform/Overdrive: conditionally include the X64 PE/COFF emulator

[Ard Biesheuvel]

Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc | 5 +++--
 Platform/AMD/OverdriveBoard/OverdriveBoard.fdf | 3 +++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
index b6a1507b4ae3..0e1db0745d89 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.dsc
@@ -17,8 +17,9 @@
 

 [Defines]
 
-DEFINE NUM_CORES= 8
-DEFINE DO_FLASHER   = FALSE
+DEFINE NUM_CORES  = 8
+DEFINE DO_FLASHER = FALSE
+DEFINE X64EMU_ENABLE  = FALSE
 
   PLATFORM_NAME  = Overdrive
   PLATFORM_GUID  = B2296C02-9DA1-4CD1-BD48-4D4F0F1276EB
diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf 
b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
index 4b6b808c1454..a058665bccdd 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
@@ -159,6 +159,9 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
   INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
   INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
+!if $(X64EMU_ENABLE) == TRUE
+  INF Emulator/X86EmulatorDxe/X86EmulatorDxe.inf
+!endif
 
   #
   # AHCI Support
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39495): https://edk2.groups.io/g/devel/message/39495
Mute This Topic: https://groups.io/mt/31321813/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 0/3] add X64 PE/COFF emulator to PCI systems

[Ard Biesheuvel]

Add a conditional build time include of the prebuild X64 PE/COFF emulator
binary to some platforms that will be able to make use of it (i.e., have
usable PCI slots)

Changes since v1:
- add Armada entry to the shared .fdf, and drop the default FALSE value (at
  the request of Marcin)

Ard Biesheuvel (3):
  Platform/DeveloperBox: conditionally include the X64 PE/COFF emulator
  Platform/Overdrive: conditionally include the X64 PE/COFF emulator
  Platform/MacchiatoBin: conditionally include the X64 PE/COFF emulator

 Platform/AMD/OverdriveBoard/OverdriveBoard.dsc   | 5 +++--
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
 Platform/AMD/OverdriveBoard/OverdriveBoard.fdf   | 3 +++
 Platform/Socionext/DeveloperBox/DeveloperBox.fdf | 3 +++
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf| 4 
 5 files changed, 14 insertions(+), 2 deletions(-)

-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39493): https://edk2.groups.io/g/devel/message/39493
Mute This Topic: https://groups.io/mt/31321811/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 3/3] Platform/MacchiatoBin: conditionally include the X64 PE/COFF emulator

[Ard Biesheuvel]

Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line. Note that this only works on AARCH64 builds.
Also note that the edk2-non-osi repository needs to be listed in the
PACKAGES_PATH environment variable.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf | 4 
 1 file changed, 4 insertions(+)

diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
index e90e10e69623..ccfeb90102a2 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
@@ -220,6 +220,10 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   # ACPI support
   INF MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
   INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+!if $(X64EMU_ENABLE) == TRUE
+  # PE/COFF emulator for X64 option ROMs taken from edk2-non-osi
+  INF Emulator/X86EmulatorDxe/X86EmulatorDxe.inf
+!endif
 !endif
 
 !include $(BOARD_DXE_FV_COMPONENTS)
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39496): https://edk2.groups.io/g/devel/message/39496
Mute This Topic: https://groups.io/mt/31321814/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 1/3] Platform/DeveloperBox: conditionally include the X64 PE/COFF emulator

[Ard Biesheuvel]

Add the X64 emulator to the build if '-D X64EMU_ENABLE=TRUE' is passed
on the build command line. Note that this only works on AARCH64 builds.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 1 +
 Platform/Socionext/DeveloperBox/DeveloperBox.fdf | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc 
b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 4ddb0d427f13..909cfb550757 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -30,6 +30,7 @@
 
   DEFINE DEBUG_ON_UART1  = FALSE
   DEFINE SECURE_BOOT_ENABLE  = FALSE
+  DEFINE X64EMU_ENABLE   = FALSE
 
 !include Platform/Socionext/DeveloperBox/DeveloperBox.dsc.inc
 
diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf 
b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
index 72997e143de5..e6b42fc2028c 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.fdf
@@ -159,6 +159,9 @@ READ_LOCK_STATUS   = TRUE
   INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
 !if $(ARCH) == AARCH64
   INF MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
+!if $(X64EMU_ENABLE) == TRUE
+  INF Emulator/X86EmulatorDxe/X86EmulatorDxe.inf
+!endif
 !endif
   INF 
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   INF MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39494): https://edk2.groups.io/g/devel/message/39494
Mute This Topic: https://groups.io/mt/31321812/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] [PATCH v2 edk2-platforms] Platform/ARM/Drivers: Add Nor Flash Driver

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 11:05, Jagadeesh Ujja  wrote:
>
> Fwd to new EDKII development mailing list.
>
> hi Ard,
>
> Sorry about missing your previous comment and adding here.
>
>  "Hello Jagadeesh,
>
>  Why are you moving this driver into edk2-platforms? I'd prefer to have
>
> it alongside the non-MM version instead.
>
> That would allow us to share a lot more code between the two versions."
> -
>
> my Point of view:
>
> In ArmPlatformPkg/Drivers/NorFlashDxe driver supports block I/O and
> disk  I/O protocols.
> In case of StandaloneMM norflash driver the block I/O and disk I/O
> protocols are not required
>
> We don’t want to remove support of block I/O and disk I/O protocols in
> “ArmPlatformPkg/Drivers/NorFlashDxe”
> In this case “NOR_FLASH_INSTANCE” is different in both
> drivers(DXE/STANDALONEMM). So we end up with  having 2 different
> drivers.
>
> Even if we want to share common code then we end up with multiple
> files as  “NOR_FLASH_INSTANCE” is used in almost all files
> Ex: “NorFlash.c”  “NorFlash.h” NorFlashFvb.c
> In this case “NorFlash.c”  will have 2 copies one used by DXE and
> other by STANDALONE_MM driver
>
> So instead of having 2 different drivers in one place
> “ArmPlatformPkg/Drivers/NorFlashDxe”
> added a new refactored nor flash driver in "Platform/ARM/Drivers"
>
> I am not sure if any other platform is using
> “ArmPlatformPkg/Drivers/NorFlashDxe” and may require block I/O and
> disk  I/O protocols
> if we remove “support of block I/O and disk  I/O protocols” then we
> can share the common code easily.
>

I see your point.

The only reason you need block i/o and disk i/o is to use ordinary
partition and filesystem drivers. I guess Juno uses this for its magic
filesystem? If not, I'd be glad to get rid of it.


>
> On Mon, Apr 8, 2019 at 7:16 PM Jagadeesh Ujja  wrote:
> >
> > hi Ard/Leif
> >
> > Please let me know if you have any comments on this patch set
> > thanks
> > Jagadeesh
> >
> > On Tue, Apr 2, 2019 at 6:48 PM Jagadeesh Ujja  
> > wrote:
> > >
> > > Refactor the existing ArmPlatformPkg NOR flash driver to be usable
> > > as a StandaloneMM library. Some of the functionality not required
> > > in StandaloneMM, such as the block layer, is removed. This allows
> > > storing of EFI variables on NOR flash which is accessible only via
> > > the MM STANDALONE mode software
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jagadeesh Ujja 
> > > ---
> > > Changes since v1:
> > > - This is a next version of patch
> > >   “[edk2] [PATCH 0/2] Allow use of ArmPlatformPkg NOR flash driver in 
> > > StandaloneMM”
> > >https://lists.01.org/pipermail/edk2-devel/2019-February/036882.html
> > >https://lists.01.org/pipermail/edk2-devel/2019-February/036884.html
> > >https://lists.01.org/pipermail/edk2-devel/2019-February/036883.html
> > > - ArmPlatformPkg/Drivers/NorFlashDxe driver supports block I/O and disk
> > >   I/O protocols. This driver is required in StandaloneMM but the block I/O
> > >   and disk I/O protocols are not required in StandaloneMM.
> > > - Instead of removing support for block I/O and disk I/O protocols,
> > >   add a new refactored nor flash driver in "Platform/ARM/Drivers"
> > > - Addressed all the comments from Ard Biesheuvel.
> > >
> > >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c   | 982 
> > > 
> > >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.h   | 326 
> > > +++
> > >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlashFvb.c| 740 
> > > +++
> > >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlashStandaloneMm.c   | 250 
> > > +
> > >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlashStandaloneMm.inf |  68 
> > > ++
> > >  5 files changed, 2366 insertions(+)
> > >
> > > diff --git a/Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c 
> > > b/Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c
> > > new file mode 100644
> > > index 000..4ba4fb5
> > > --- /dev/null
> > > +++ b/Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c
> > > @@ -0,0 +1,982 @@
> > > +/** @file  NorFlash.c
> > > +
> > > +  Copyright (c) 2019, ARM 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 "NorFlash.h"
> > > +
> > > +STATIC
> > > +UINT32
> > > +NorFlashReadStatusRegister (
> > > +  IN NOR_FLASH_INSTANCE *Instance,
> > > +  IN UINTN  

Re: [edk2-devel] [patch 0/7] Move BaseUefiTianoCustomDecompressLib from IntelFrameworkModulePkg to MdeModulePkg

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 15:02, Gao, Liming  wrote:
>
> Ard:
>   I prefer to keep them as the separate repo. One dummy Git repo can be 
> introduced to submodule edk2, edk2-platform, edk2-non-osi, and others. User 
> can use this git repo to get everything.
>

That is not really my point.

A git submodule allows you to store *in* the dependent repository
which exact commit in the core repository you depend on. A dummy git
repo does not work the same way.

> > -Original Message-
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: Wednesday, April 24, 2019 8:48 PM
> > To: Gao, Liming 
> > Cc: Laszlo Ersek ; Bi, Dandan ; 
> > edk2-devel-groups-io ; Julien Grall
> > ; Leif Lindholm ; Justen, 
> > Jordan L ; Andrew Fish
> > ; Ni, Ray ; Wang, Jian J 
> > ; Wu, Hao A ; Kinney,
> > Michael D ; Steele, Kelly 
> > ; Sun, Zailiang ; Qian, Yi
> > 
> > Subject: Re: [patch 0/7] Move BaseUefiTianoCustomDecompressLib from 
> > IntelFrameworkModulePkg to MdeModulePkg
> >
> > On Wed, 24 Apr 2019 at 14:46, Gao, Liming  wrote:
> > >
> > >
> > > So, we need to consider the combination of edk2 master + edk2-platform 
> > > master. When do the incompatible change in edk2 master, we
> > need to update edk2-platform master together.
> > >
> >
> > Yes, it is either that, or we separate them properly, by pulling core
> > EDK2 into edk2-platforms as a git submodule. That way, we can update
> > the upstream commit depended upon instead of assuming that we are
> > always updated in lockstep.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39491): https://edk2.groups.io/g/devel/message/39491
Mute This Topic: https://groups.io/mt/30896388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch 0/7] Move BaseUefiTianoCustomDecompressLib from IntelFrameworkModulePkg to MdeModulePkg

[Liming Gao]

Ard:
  I prefer to keep them as the separate repo. One dummy Git repo can be 
introduced to submodule edk2, edk2-platform, edk2-non-osi, and others. User can 
use this git repo to get everything. 

Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, April 24, 2019 8:48 PM
> To: Gao, Liming 
> Cc: Laszlo Ersek ; Bi, Dandan ; 
> edk2-devel-groups-io ; Julien Grall
> ; Leif Lindholm ; Justen, 
> Jordan L ; Andrew Fish
> ; Ni, Ray ; Wang, Jian J 
> ; Wu, Hao A ; Kinney,
> Michael D ; Steele, Kelly 
> ; Sun, Zailiang ; Qian, Yi
> 
> Subject: Re: [patch 0/7] Move BaseUefiTianoCustomDecompressLib from 
> IntelFrameworkModulePkg to MdeModulePkg
> 
> On Wed, 24 Apr 2019 at 14:46, Gao, Liming  wrote:
> >
> >
> > So, we need to consider the combination of edk2 master + edk2-platform 
> > master. When do the incompatible change in edk2 master, we
> need to update edk2-platform master together.
> >
> 
> Yes, it is either that, or we separate them properly, by pulling core
> EDK2 into edk2-platforms as a git submodule. That way, we can update
> the upstream commit depended upon instead of assuming that we are
> always updated in lockstep.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39490): https://edk2.groups.io/g/devel/message/39490
Mute This Topic: https://groups.io/mt/30896388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 3/3] Marvell/Drivers: Add non-mmio mode to MvFvbDxe

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 09:11, Ard Biesheuvel  wrote:
>
> On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas  wrote:
> >
> > From: Kornel Duleba 
> >
> > This path enables support for reading variables directly from flash without
> > relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
> > allows to switch between the modes. When in non-memory-mapped mode the
> > driver will copy the variables from flash to previously allocated buffer
> > and set PcdFlashNvStorageVariableBase64, PcdFlashNvStorageFtwWorkingBase64
> > and PcdFlashNvStorageFtwSpareBase64 accordingly.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  Silicon/Marvell/Marvell.dec   |   8 ++
> >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  10 +-
> >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
> >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
> >  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 135 
> > +++-
> >  5 files changed, 135 insertions(+), 36 deletions(-)
> >
> > diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> > index 7210ba2..a23c329 100644
> > --- a/Silicon/Marvell/Marvell.dec
> > +++ b/Silicon/Marvell/Marvell.dec
> > @@ -58,6 +58,12 @@
> >
> >gMarvellFvbDxeGuid = { 0x42903750, 0x7e61, 0x4aaf, { 0x83, 0x29, 0xbf, 
> > 0x42, 0x36, 0x4e, 0x24, 0x85 } }
> >gMarvellSpiFlashDxeGuid = { 0x49d7fb74, 0x306d, 0x42bd, { 0x94, 0xc8, 
> > 0xc0, 0xc5, 0x4b, 0x18, 0x1d, 0xd7 } }
> > +  #
> > +  # Generic FaultTolerantWriteDxe driver use variables,
> > +  # whose setting is done in MvFvbDxe driver in case
> > +  # the SPI contents are not mapped in memory.
> > +  #
> > +  gFaultTolerantWriteDxeFileGuid = { 0xfe5cea76, 0x4f72, 0x49e8, { 0x98, 
> > 0x6f, 0x2c, 0xd8, 0x99, 0xdf, 0xfe, 0x5d} }
> >
> >  [LibraryClasses]
> >ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
> > @@ -140,6 +146,8 @@
> >  #SPI
> >gMarvellTokenSpaceGuid.PcdSpiRegBase|0|UINT32|0x351
> >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0|UINT64|0x359
> > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE|BOOLEAN|0x360
> > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0|UINT32|0x361
> >gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|0|UINT32|0x3052
> >gMarvellTokenSpaceGuid.PcdSpiClockFrequency|0|UINT32|0x3053
> >
> > diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> > b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > index ca3de2e..d53d128 100644
> > --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > @@ -256,6 +256,11 @@
> ># USB support
> >gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
> >
> > +[PcdsDynamicDefault.common]
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> > +  
> > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> > +
> >  [PcdsFixedAtBuild.common]
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"MARVELL_EFI"
> >gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> > @@ -396,11 +401,10 @@
> ># Variable store - default values
> >#
> >gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE
> > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0x3C
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> > -  
> > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
> >
> >  !if $(CAPSULE_ENABLE)
> > diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf 
> > b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > index ef10bfd..c85e8a6 100644
> > --- a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > +++ b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> > @@ -76,13 +76,22 @@
> >gMarvellSpiMasterProtocolGuid
> >
> >  [FixedPcd]
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
> > -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64
> >gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
> >gMarvellTokenSpaceGuid.PcdSpiMemoryBase
> > +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped
> > +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset
> > +
> > +[Pcd]
> > +  

Re: [edk2-devel] [patch 0/7] Move BaseUefiTianoCustomDecompressLib from IntelFrameworkModulePkg to MdeModulePkg

[Liming Gao]

So, we need to consider the combination of edk2 master + edk2-platform master. 
When do the incompatible change in edk2 master, we need to update edk2-platform 
master together. 

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, April 24, 2019 5:53 PM
> To: Ard Biesheuvel ; Bi, Dandan 
> 
> Cc: edk2-devel-groups-io ; Julien Grall 
> ; Leif Lindholm ; Justen,
> Jordan L ; Andrew Fish ; Gao, 
> Liming ; Ni, Ray ;
> Wang, Jian J ; Wu, Hao A ; Kinney, 
> Michael D ; Steele, Kelly
> ; Sun, Zailiang ; Qian, Yi 
> 
> Subject: Re: [patch 0/7] Move BaseUefiTianoCustomDecompressLib from 
> IntelFrameworkModulePkg to MdeModulePkg
> 
> On 04/23/19 18:26, Ard Biesheuvel wrote:
> > On Thu, 4 Apr 2019 at 15:52, Dandan Bi  wrote:
> >>
> >> We will remove IntelFrameworkModulePkg,but 
> >> BaseUefiTianoCustomDecompressLib in it
> >> may still need to be used. So move BaseUefiTianoCustomDecompressLib from
> >> IntelFrameworkModulePkg to MdeModulePkg firstly.
> >>
> >
> > The following platforms are now broken in edk2-platforms/master since
> > they still refer to BaseUefiTianoCustomDecompressLib in the old
> > location:
> >
> > AMD Overdrive
> > Lemaker Cello
> > Raspberry Pi3
> > SoftIron 1000
> > D03/D05/D06
> > Hikey/Hikey960
> >
> > Could we please try not to leave edk2-platforms behind when making
> > changes to the core repository? Thanks.
> >
> 
> (this is why edk2-platforms should live inside edk2...)

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39487): https://edk2.groups.io/g/devel/message/39487
Mute This Topic: https://groups.io/mt/30896388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Question about the Protective MBR in RedHat/Ubuntu

[Xu, Wei6]

Hi,

I have a question about protective MBR. Thanks a lot for your time.
Why is the StartingCHS of protective MBR partition record set to 0x000100 in 
RedHat / Ubuntu? While UEFI spec defines it as 0x000200.

Problem Statement:
I met a problem when trying to use FatPei to fetch a file on the GPT partition 
of RedHat/Ubuntu in TCB.
FatPei has a check about Partition Record of protective MBR: StartingCHS should 
to 0x000200.
But I find the StartingCHS in both RedHat and Ubuntu is 0x000100, so that the 
check fails.

According to UEFI spec, StartingCHS should be 0x000200.

[cid:image001.png@01D4FACC.71570DF0]

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39486): https://edk2.groups.io/g/devel/message/39486
Mute This Topic: https://groups.io/mt/31320822/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 0/8] Decrease the name collisions

[Laszlo Ersek]

Hi Zhichao,

On 04/24/19 06:58, Zhichao Gao wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
> 
> V1:
> The DebugLib instances of DebugPortProtocol, ConOut and StdErr
> use a global variable "mExitBootServicesEvent" which is in
> conflict with the same variable in StatusCodeHandlerRuntimeDxe.inf.
> That would cause a build error through GCC5. So change the
> name to the "mDebugLibExitBootServicesEvent".
> 
> V2:
> Abandon v1.
> Add a 'static' descriptor to the global variables that only
> used in a single file to minimize the name collisions.
> This is only for the varable named 'mExitBootServicesEvent'.

I recommend a number of easy changes:

(1) in all of the subject lines, please replace

  Decrease the name collisions

with

  make mExitBootServicesEvent STATIC

(The longest resultant subject line,
"MdeModulePkg/StatusCodeHandlerRuntimeDxe: make mExitBootServicesEvent
STATIC", will be 76 chars wide, but I think it's acceptable in this case
-- there's simply no way to express what we do in fewer characters. I
have thought of "hide mExitBootServicesEvent" too, but "hide" is ambiguous.)

(2) In the commit messages, I suggest replacing "descriptor" with
"storage-class specifier". (That's the term ISO C uses.)

(3) Please spell it as "STATIC" in source code, not "static". For
whatever reason, the edk2 coding style requires STATIC. (See
"MdePkg/Include/Base.h".)

(4) In the first three patches (the DebugLib instances), there is a
blank line between "mPostEBS" and "mExitBootServicesEvent". For that
reason, I think it's unnecessary to change the indentation of
"mPostEBS", when you add STATIC to "mExitBootServicesEvent".


Having stated those, I totally defer to the respective package owners on
this series, as I don't co-maintain any of the affected packages. If
they disagree with the above, I'm OK too.

Thanks
Laszlo


> 
> Cc: Laszlo Ersek 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> 
> 
> Zhichao Gao (8):
>   MdePkg/UefiDebugLibConOut: Decrease the name collisions
>   MdePkg/UefiDebugLibDebugPortProtocol: Decrease the name collisions
>   MdePkg/UefiDebugLibStdErr: Decrease the name collisions
>   IntelFrameworkModulePkg: Decrease the name collisions
>   MdeModulePkg/FirmwarePerformanceDxe: Decrease the name collisions
>   IntelFsp2WrapperPkg/FspWrapperNotifyDxe: Decrease the name collisions
>   IntelFrameworkModulePkg: Decrease the name collisions
>   MdeModulePkg/StatusCodeHandlerRuntimeDxe: Decrease the name collisions
> 
>  .../SmmRuntimeDxeSupport.c| 2 +-
>  .../DatahubStatusCodeHandlerDxe/DatahubStatusCodeHandlerDxe.c | 2 +-
>  IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.c | 2 +-
>  .../FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.c  | 2 +-
>  .../RuntimeDxe/StatusCodeHandlerRuntimeDxe.c  | 2 +-
>  MdePkg/Library/UefiDebugLibConOut/DebugLibConstructor.c   | 4 ++--
>  .../UefiDebugLibDebugPortProtocol/DebugLibConstructor.c   | 4 ++--
>  MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c   | 4 ++--
>  8 files changed, 11 insertions(+), 11 deletions(-)
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39485): https://edk2.groups.io/g/devel/message/39485
Mute This Topic: https://groups.io/mt/31318885/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 2/2] MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen

[Laszlo Ersek]

On 04/24/19 12:24, Laszlo Ersek wrote:

> ... Actually, you mention "the phase immediately after the
> PlatformBootManagerAfterConsole() is the best choice". So how about the
> following approach:
> 
> (1) Introduce a new protocol (an edk2 extension). The UEFI protocol
> database is supposed to contain *at most* one instance of this protocol,
> at any time.
> 
> (2) The protocol should consist of a BOOLEAN field only. (You can add a
> "revision" field at the beginning too, if you like.)
> 
> (3) In GraphicsConsoleDxe, which is a UEFI driver, you try to locate the
> protocol at the right spot -- when SetMode is about to clear the screen.
> If the protocol instance is missing, there is no change in behavior (the
> screen is cleared). If the protocol instance is available, but the
> BOOLEAN field is , there is no change in behavior (the screen
> is cleared). If the protocol instance is available, and the BOOLEAN
> field is , then the screen is *not* cleared.
> 
> (4) Platforms that need the anti-flicker tweak are expected to do the
> following two steps:
> 
> (4a) add a platform DXE driver (or modify one) to install the protocol,
> with the BOOLEAN field set to .
> 
> (4b) append new logic to PlatformBootManagerAfterConsole(), for locating
> the protocol, and setting the BOOLEAN field in it to .

Two more thoughts:

* regarding (4a), it's not necessary to modify (or introduce) a platform
DXE driver for installing the protocol, with . I think it can
be done in PlatformBootManagerBeforeConsole() as well.


* the new protocol could be replced with a new event group:

- GraphicsConsoleDxe would get a new global variable (a BOOLEAN), with
the default value meaning "clear screen on SetMode".

- GraphicsConsoleDxe would also install an event group notification
function, for *inverting* the boolean variable (and doing nothing else).

- In the affected platforms, BeforeConsole would signal the new event
group once (to disable screen clearing temporarily). Then AfterConsole
would signal the new event group once more, to restore the default
(standards conformant) behavior.

- Unaffected platforms would never signal the new event group; they'd
ignore it.

Personally, I like the protocol approach a lot more, because at any
point, you can query the state of the "system" (= the protocol DB) with
external utilities. The new event group allows for much less
introspection, not to mention that the meaning of signaling the event
group depends on the current state. (That could be avoided by
introducing two event groups, one for setting the variable and another
for clearing it, but that's getting baroque in my opinion.)

I'd go with the new protocol -- you don't need GraphicsConsoleDxe to
react to PlatformBootManagerLib with a callback.

Thanks
Laszlo

> 
> 
> A variant could be to introduce a tri-state DynamicEx PCD -- ,
> the DEC default, means no change in behavior (= the platform doesn't
> need the anti-flicker tweak); while  and  work like
> above. The question is whether we are OK adding an EFI_PCD_PROTOCOL
> dependency to GraphicsConsoleDxe, which is a UEFI driver
> (EFI_PCD_PROTOCOL comes from the PI spec, not from the UEFI spec).
> Inventing a new edk2 extension protocol (with a fresh protocol GUID)
> would avoid that problem -- it could be implemented purely in terms of
> the UEFI spec.
> 
> Thanks
> Laszlo
> 
>>> I guess you have already investigated adding a boolean field to
>>> GRAPHICS_CONSOLE_DEV, and found it unsuitable for those platforms that
>>> need this anti-flicker tweak. So I'm not going to suggest such a boolean 
>>> field
>>> now.
>>>
>>> Instead, I propose a PCD (feature PCD or dynamic boolean PCD). If you add a
>>> PCD, I won't care about the particulars of this patch, as long as platforms
>>> continue observing the std conformant behavior, under the default value of
>>> the PCD (i.e., from "MdeModulePkg.dec").
>>>
>>> Thanks,
>>> Laszlo
>>>
 Cc: Jian J Wang 
 Cc: Hao Wu 
 Cc: Ray Ni 
 Cc: Star Zeng 
 Cc: Liming Gao 
 Cc: Sean Brogan 
 Cc: Michael Turner 
 Cc: Bret Barkelew 
 Cc: Laszlo Ersek 
 Signed-off-by: Zhichao Gao 
 ---
  .../GraphicsConsoleDxe/GraphicsConsole.c  | 82 +--
  .../GraphicsConsoleDxe/GraphicsConsoleDxe.inf |  3 +
  2 files changed, 62 insertions(+), 23 deletions(-)

 diff --git

>>> a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole
>>> .c

>>> b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsol
>>> e.c
 index 26ea19f300..39a999838c 100644
 ---

>>> a/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsole
>>> .c
 +++
>>> b/MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsol
 +++ e.c
 @@ -1,7 +1,7 @@
  /** @file
This is the main routine for initializing the Graphics Console support
>>> routines.

 -Copyright (c) 2006 - 2018, Intel Corporation. All rights
 reserved.
 +Copyright (c) 2006 - 

Re: [edk2-devel] [PATCH V2 2/2] MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen

[Laszlo Ersek]

On 04/24/19 04:37, Gao, Zhichao wrote:
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, April 23, 2019 9:51 PM
>> To: Gao, Zhichao ; devel@edk2.groups.io
>> Cc: Aaron Antone ; Wang, Jian J
>> ; Wu, Hao A ; Ni, Ray
>> ; Zeng, Star ; Gao, Liming
>> ; Sean Brogan ;
>> Michael Turner ; Bret Barkelew
>> 
>> Subject: Re: [edk2-devel] [PATCH V2 2/2]
>> MdeModulePkg/GraphicsConsoleDxe: Do not clean the screen
>>
>> On 04/23/19 09:04, Zhichao Gao wrote:
>>> From: Aaron Antone 
>>>
>>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1412
>>>
>>> For now, most platform support to display during PEIM. It means the
>>> logo can show at PEI phase. But the screen would be cleared at BDS
>>> connect console phase. That may make the screen flush and turn into black
>> screen.
>>> So do not clear the screen while set the text mode for graphics
>>> console device for the first time boot.
>>> As the shell reconnect command would make the same reslut with the
>>> first boot, use the gEfiEventReadyToBootGuid to distinguish them.
>>>
>>> Also replace the debug code in GraphicsConsoleControllerDriverStart.
>>> The origin one would set a basic mode and then print the text info to
>>> graphic console device. Then the conspliter would set a best mode for
>>> graphics console device. If the best mode is different with the basic
>>> one, the screen would be cleared. So use the debug output instead.
>>>
>>> This patch only affect the behavior of SetMode at the first boot
>>> during the graphics console devices first connect operations. That
>>> means at DXE phase before ReadyToBoot, the Graphics Simple Text Out
>>> SetMode would not clear the screen during the first connecttion of the
>> graphics devices.
>>
>> The UEFI spec requirement doesn't apply after ReadyToBoot only. What
>> about SysPrep applications, for example:
>>
>> """
>> When launched, the platform is required to provide the application loaded by
>> SysPrep, with the same services such as console and network as are
>> normally provided at launch to applications referenced by a Boot
>> variable. [...] After all SysPrep variables have been launched and 
>> exited,
>> the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group
>> and begin to evaluate Boot variables [...] """
>>
>> Thus a SysPrep application is permitted to expect, and to use, the console,
>> but it is launched before ReadyToBoot; and so this patch could break the
>> console's std conformance for SysPrep apps.
> 
> Thanks for your reminder. The 'SysPrep' and 'PlatformRecovery' are 
> both optional for the consumers. The condition of 'SysPrep' is like what 
> you mentioned above. For 'PlatformRecovery', if the platform set the 
> 'OsIndications' EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY bit, then the 
> system would directly try to execute the 'PlatformRecovery'. And the 
> PlatformRecovery application would have the same issue with SysPrep 
> application.
> To cover all the conditions we discussed, the phase immediately after the 
> PlatformBootManagerAfterConsole() is the best choice. I also thought of the 
> EndOfDxe event. But it is controlled by the PlatformBdsLib and the usual 
> signal function is at the end of PlatformBootManagerBeforeConsole(). That 
> would miss the PCI graphics devices connected in the after console.
> For now seems there is no suitable event to distinguish the behaviors in 
> different phases. Adding an event in the Bds is also unsuitable.

I think we should find a general way to add edk2 extensions (status
codes and events) to BdsDxe / UefiBootManagerLib, without having to go
through standardization every time.

Can we introduce a new PlatformBootManagerLib hook for the present use
case? See for example

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

which was fixed in commit range

  cef7ecf6cdb4..1010873becc5

... Actually, you mention "the phase immediately after the
PlatformBootManagerAfterConsole() is the best choice". So how about the
following approach:

(1) Introduce a new protocol (an edk2 extension). The UEFI protocol
database is supposed to contain *at most* one instance of this protocol,
at any time.

(2) The protocol should consist of a BOOLEAN field only. (You can add a
"revision" field at the beginning too, if you like.)

(3) In GraphicsConsoleDxe, which is a UEFI driver, you try to locate the
protocol at the right spot -- when SetMode is about to clear the screen.
If the protocol instance is missing, there is no change in behavior (the
screen is cleared). If the protocol instance is available, but the
BOOLEAN field is , there is no change in behavior (the screen
is cleared). If the protocol instance is available, and the BOOLEAN
field is , then the screen is *not* cleared.

(4) Platforms that need the anti-flicker tweak are expected to do the
following two steps:

(4a) add a platform DXE driver (or modify one) to 

Re: [edk2-devel] Requestion for LTS version on EDK2

[Laszlo Ersek]

On 04/23/19 19:52, Rebecca Cran wrote:
> On 2019-04-18 17:26, Laszlo Ersek wrote:
>>
>> (1) Introduce stable *branches* to the development model. Those would be
>> forked off at the stable tags (well, at some of them).
> 
> 
> Would this be _re_ introducing stable branches?

Yes.

> As explained in
> https://github.com/tianocore/tianocore.github.io/wiki/UDK it seems the
> project only recently moved from UDK stable branches (at least, I
> took them to be stable branches) to periodically tagging master with a
> stable tag.

UDK is conceptually identical to stable branches. The difference is that
all the resources that Intel used to sink into UDK, for evaluation,
backporting, testing, validation, etc, would now have to be offered by
the TianoCore community. (This would also allow for widening the scope,
of course, such as architecture support.)

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39482): https://edk2.groups.io/g/devel/message/39482
Mute This Topic: https://groups.io/mt/31222094/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [patch 0/7] Move BaseUefiTianoCustomDecompressLib from IntelFrameworkModulePkg to MdeModulePkg

[Laszlo Ersek]

On 04/23/19 18:26, Ard Biesheuvel wrote:
> On Thu, 4 Apr 2019 at 15:52, Dandan Bi  wrote:
>>
>> We will remove IntelFrameworkModulePkg,but BaseUefiTianoCustomDecompressLib 
>> in it
>> may still need to be used. So move BaseUefiTianoCustomDecompressLib from
>> IntelFrameworkModulePkg to MdeModulePkg firstly.
>>
> 
> The following platforms are now broken in edk2-platforms/master since
> they still refer to BaseUefiTianoCustomDecompressLib in the old
> location:
> 
> AMD Overdrive
> Lemaker Cello
> Raspberry Pi3
> SoftIron 1000
> D03/D05/D06
> Hikey/Hikey960
> 
> Could we please try not to leave edk2-platforms behind when making
> changes to the core repository? Thanks.
> 

(this is why edk2-platforms should live inside edk2...)

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39480): https://edk2.groups.io/g/devel/message/39480
Mute This Topic: https://groups.io/mt/30896388/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] Request to add new edk2-libc repository

[Laszlo Ersek]

On 04/23/19 23:43, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> Many topics in here.  Please let me know if I missed anything.
> 
> 1) I did use git filter-branch to extract the history of these
>packages.  The script I ran is shown below.  It results in 
>a local repo in the directory edk2-filter that contains
>the 3 packages with complete history and the Maintainers,
>License, and Readme files.  The step remaining is to add a 
>remote to the new edk2-libc repo and push the master branch
>in edk2-filter to edk2-libc.  I will add these details to
>the commit message.
> 
> export PATHS_TO_KEEP="./AppPkg ./ StdLib ./StdLibPrivateInternalFiles 
> ./Maintainers.txt ./License* ./Read*"

(probably typo in "./[space]StdLib")

> git clone https://github.com/tianocore/edk2.git edk2-filter
> cd edk2-filter
> git checkout master
> git remote rm origin
> git filter-branch -f --index-filter "git rm --ignore-unmatch --cached -qr -- 
> . && git reset -q \$GIT_COMMIT -- $PATHS_TO_KEEP" --prune-empty -- "master"

This is awesome! :) Please do include this description in a commit
message (on a genuine, new commit) or in a text file (possibly part of
Readme.md). Thanks!

> 2) There are 2 reviews.  
> 
> 2a)One to add new edk2-libc repo and populate with complete
>history and update the Maintainers.txt and Readme.md file.  
> 
>https://github.com/mdkinney/edk2-libc
> 
>https://github.com/mdkinney/edk2-libc/commits/master
> 
>I think it makes sense to have a pointer to the edk2 repo
>from the edk2-libc repo in the Readme.md.  I am ok with
>removing the stewards from the edk2-libc Maintainers.txt
>and pointing to Maintainers.txt in edk2 repo.

OK.

>However, I
>would prefer the list of packages in Maintainers.txt be
>limited to the packages in that repo.

Yes, that's fine.

>So the Readme.md
>in edk2-libc would point to Maintainers.txt in the edk2-libc
>repo for the packages in edk2-libc

That's OK.

>and provide a link to 
>Maintainers.txt in edk2 repo for the stewards.

That's great, but there are two more sections in edk2-libc's
Maintainers.txt that are not replated to edk2-libc's packages:

- reporting security issues
- releases

Both of those sections inherit the edk2 traits, and IMO that's not correct:

- In the TianoCore Bugzilla instance, the security process has
disclaimed coverage for any and all issues found in libc (classifying
them all as "normal bugs").

- Plus, the edk2 release process is not going to cover edk2-libc at all,
at least until we invent new rules for edk2-libc.

For now, I think it would be OK if we just stated "TBD" or "work in
progress" under both of these sections.

> 
> 2b)Another review to remove the packages from the edk2 repo
>and remove those packages from Maintainers.txt
>and Readme.md.  I did edit the commit to edk2 repo to make
>it smaller.  I have a V2 that does the remove in the first
>patch, and updates Maintainers.txt and Readme.md in a second
>patch.

Thanks. I guess my main point there was that even on the (now-)first
patch, the diffstat should be included (the long list of files being
removed). The contents of the files can be snipped.

$ git ls-files AppPkg/ StdLib/ StdLibPrivateInternalFiles/ | wc
   36473647  209360

Fewer than 4000 lines, and ~200KB in size. Even if it ends up doubled in
the diffstat, that's not a huge email, and it helps with the review,
IMO. (People can skim the list of files easily and catch something
they'd like to keep.)

> 3) I understand your point about splitting actively maintained
>content into multiple repos and being able to use the 
>history effectively to find the cause of a regression.
>The current plans for moving content are limited to the 
>retiring packages that are no longer needed,

OK -- I've been collaborating on that (contributing to reviews and BZ
discussions).

>adding the edk2-libc repo

OK.

>and moving content from the edk2 repo to the
>edk2-platforms repo.  We already have a number of platforms
>being maintained in edk2-platforms, so we will not be making
>it any worse by this move.

OK. As long as we're not making it any worse. I'll have to watch this
space closely. I do understand that everything we preserve in edk2 will
need active maintainership.

>There are no plans to move the
>EmulatorPkg or the OvmfPkg out of the edk2 repo.

Thanks -- and please include ArmVirtPkg in the above list too.

> 
> 4) I agree that the unit test for OrderedCollectionLib should
>be in the package that defines that library class.  The
>SafeIntLib unit tests you point to is a better style.

I don't understand your second sentence here. Can you please elaborate
on "better style"?

>I do not think unit tests should have a dependency on libc.
>I recommend we port the OrderedCollectionLib to not depend
>on libc

I think this could make unit test development in general more expensive

Re: [edk2-devel] [PATCH] CryptoPkg: add issetugid declaration to fix openssl build on FreeBSD

[Philippe Mathieu-Daudé]

On 4/22/19 3:46 PM, Wang, Jian J wrote:
> crypto/uid.c is needed by VS201x toolchain on Windows. Let's still keep it in 
> inf.
> That means we need this patch for build on FreeBSD.
> 
> Reviewed-by: Jian J Wang 

Commit 1a734ed85fda71630c795832e6d24ea560caf739 has weird authorship
again: rebecca via Groups.Io 

> Jian
> 
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> rebecca via Groups.Io
>> Sent: Sunday, April 21, 2019 1:18 AM
>> To: devel@edk2.groups.io; ard.biesheu...@linaro.org
>> Cc: Ye, Ting ; Gang Wei ; Wang, Jian
>> J 
>> Subject: Re: [edk2-devel] [PATCH] CryptoPkg: add issetugid declaration to fix
>> openssl build on FreeBSD
>>
>> On 2019-04-20 05:28, Ard Biesheuvel wrote:
>>>
>>> This is slightly odd. The host architecture shouldn't really matter,
>>> and so if we end up calling different code in UEFI when built on *BSD,
>>> there is differently something wrong. Or am I missing something?
>>
>>
>> No, that's a good point. I guess it's something we don't ever call.
>>
>> In fact, OVMF continues to build after removing crypto/uid.c (which
>> contains the OPENSSL_issetugid definition) from
>> CryptoPkg/Library/OpensslLib/OpensslLib.inf and
>> CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf .
>>
>>
>> --
>>
>> Rebecca Cran

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39477): https://edk2.groups.io/g/devel/message/39477
Mute This Topic: https://groups.io/mt/31250604/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2] [PATCH v2 edk2-platforms] Platform/ARM/Drivers: Add Nor Flash Driver

[Jagadeesh Ujja]

Fwd to new EDKII development mailing list.

hi Ard,

Sorry about missing your previous comment and adding here.

 "Hello Jagadeesh,

 Why are you moving this driver into edk2-platforms? I'd prefer to have

it alongside the non-MM version instead.

That would allow us to share a lot more code between the two versions."
-

my Point of view:

In ArmPlatformPkg/Drivers/NorFlashDxe driver supports block I/O and
disk  I/O protocols.
In case of StandaloneMM norflash driver the block I/O and disk I/O
protocols are not required

We don’t want to remove support of block I/O and disk I/O protocols in
“ArmPlatformPkg/Drivers/NorFlashDxe”
In this case “NOR_FLASH_INSTANCE” is different in both
drivers(DXE/STANDALONEMM). So we end up with  having 2 different
drivers.

Even if we want to share common code then we end up with multiple
files as  “NOR_FLASH_INSTANCE” is used in almost all files
Ex: “NorFlash.c”  “NorFlash.h” NorFlashFvb.c
In this case “NorFlash.c”  will have 2 copies one used by DXE and
other by STANDALONE_MM driver

So instead of having 2 different drivers in one place
“ArmPlatformPkg/Drivers/NorFlashDxe”
added a new refactored nor flash driver in "Platform/ARM/Drivers"

I am not sure if any other platform is using
“ArmPlatformPkg/Drivers/NorFlashDxe” and may require block I/O and
disk  I/O protocols
if we remove “support of block I/O and disk  I/O protocols” then we
can share the common code easily.

thanks
Jagadeesh

On Mon, Apr 8, 2019 at 7:16 PM Jagadeesh Ujja  wrote:
>
> hi Ard/Leif
>
> Please let me know if you have any comments on this patch set
> thanks
> Jagadeesh
>
> On Tue, Apr 2, 2019 at 6:48 PM Jagadeesh Ujja  wrote:
> >
> > Refactor the existing ArmPlatformPkg NOR flash driver to be usable
> > as a StandaloneMM library. Some of the functionality not required
> > in StandaloneMM, such as the block layer, is removed. This allows
> > storing of EFI variables on NOR flash which is accessible only via
> > the MM STANDALONE mode software
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jagadeesh Ujja 
> > ---
> > Changes since v1:
> > - This is a next version of patch
> >   “[edk2] [PATCH 0/2] Allow use of ArmPlatformPkg NOR flash driver in 
> > StandaloneMM”
> >https://lists.01.org/pipermail/edk2-devel/2019-February/036882.html
> >https://lists.01.org/pipermail/edk2-devel/2019-February/036884.html
> >https://lists.01.org/pipermail/edk2-devel/2019-February/036883.html
> > - ArmPlatformPkg/Drivers/NorFlashDxe driver supports block I/O and disk
> >   I/O protocols. This driver is required in StandaloneMM but the block I/O
> >   and disk I/O protocols are not required in StandaloneMM.
> > - Instead of removing support for block I/O and disk I/O protocols,
> >   add a new refactored nor flash driver in "Platform/ARM/Drivers"
> > - Addressed all the comments from Ard Biesheuvel.
> >
> >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c   | 982 
> > 
> >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.h   | 326 
> > +++
> >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlashFvb.c| 740 
> > +++
> >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlashStandaloneMm.c   | 250 
> > +
> >  Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlashStandaloneMm.inf |  68 ++
> >  5 files changed, 2366 insertions(+)
> >
> > diff --git a/Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c 
> > b/Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c
> > new file mode 100644
> > index 000..4ba4fb5
> > --- /dev/null
> > +++ b/Platform/ARM/Drivers/StandaloneMmNorFlash/NorFlash.c
> > @@ -0,0 +1,982 @@
> > +/** @file  NorFlash.c
> > +
> > +  Copyright (c) 2019, ARM 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 "NorFlash.h"
> > +
> > +STATIC
> > +UINT32
> > +NorFlashReadStatusRegister (
> > +  IN NOR_FLASH_INSTANCE *Instance,
> > +  IN UINTN  SR_Address
> > +  )
> > +{
> > +  // Prepare to read the status register
> > +  SEND_NOR_COMMAND (Instance->DeviceBaseAddress, 0, 
> > P30_CMD_READ_STATUS_REGISTER);
> > +  return MmioRead32 (Instance->DeviceBaseAddress);
> > +}
> > +
> > +STATIC
> > +BOOLEAN
> > +NorFlashBlockIsLocked (
> > +  IN NOR_FLASH_INSTANCE *Instance,
> > +  IN UINTN  BlockAddress
> > +  )
> > +{
> > +  UINT32LockStatus;
> > +
> > +  // Send command for reading device id
> > +  

Re: [edk2-devel] [PATCH V2 3/8] MdePkg/UefiDebugLibStdErr: Decrease the name collisions

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 06:59, Gao, Zhichao  wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1740
>
> Add a 'static' descriptor to the global variables that only
> used in a single file to minimize the name collisions.
> This is only for the varable named 'mExitBootServicesEvent'.
>
> Cc: Laszlo Ersek 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> Signed-off-by: Zhichao Gao 
> ---
>  MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c 
> b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> index d4fdfbab55..bb7b144569 100644
> --- a/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> +++ b/MdePkg/Library/UefiDebugLibStdErr/DebugLibConstructor.c
> @@ -15,9 +15,9 @@
>  //
>  // BOOLEAN value to indicate if it is at the post ExitBootServices pahse
>  //
> -BOOLEAN mPostEBS = FALSE;
> +BOOLEAN   mPostEBS = FALSE;
>
> -EFI_EVENT   mExitBootServicesEvent;
> +static EFI_EVENT  mExitBootServicesEvent;
>

Please use STATIC not static.


>  //
>  // Pointer to SystemTable
> --
> 2.21.0.windows.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39473): https://edk2.groups.io/g/devel/message/39473
Mute This Topic: https://groups.io/mt/3131/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC] Remove PI spec TemporaryRamSupport PPI from PEI Core

[Jordan Justen]

Short summary: Despite being part of the Platorm Initialization
Specificication, this proposal would remove support for the
TemporaryRamSupport PPI from PEI Core. Arguably, this would mean the
PEI Core does not support the PI spec, but we do not currently know if
any platforms require this PPI.

Main question: Does anyone know of a platform that requires this PPI,
or does anyone have major concerns with removing it before the PI
specification can be updated to remove the PPI?

Alternatives: Continue to support the PPI, but we would need to merge
a bug-fix patchset which adds some assembly code into the PEI Core.

More details:

I discussed this topic with the Tianocore Stewards, Vincent and Ray.
Although the path forward was not unanimous, it appears that the
majority thought we should propose to remove support for the
TemporaryRamSupport PPI from the PEI Core.

This PPI is defined in MdePkg/Include/Ppi/TemporaryRamSupport.h. I
believe it has been present in all versions of the Platorm
Initialization Specificication, including the latest, version 1.7.
(https://uefi.org/specsandtesttools)

The TemporaryRamSupport PPI is defined as "optional" in the PI spec,
but I believe this only applied to producers of the PPI (PI
platforms). The PEI Core (which is the consumer of this PPI) should
arguably support the PPI in order to fully support PI spec based
platforms.

But, there are some subtle issues with the PPI that make it difficult
to implement for both the consumer (PEI Core) and the producer (the
platform). In fact, there is a bug currently with the PEI Core's
implementation, which I sent a patch series to address on April 10th,
with the subject of "[PATCH v2 0/6] Fix PEI Core issue during
TemporaryRamMigration".

Unfortunately the fix is not very simple, and requires adding assembly
code to the PEI Core module. Based on this, we discussed if the
TemporaryRamSupport PPI is no longer required by current PI platforms,
despite being present in the PI spec. The only known example of it
being required was a platform based on the IPF architecture, which is
no longer supported by EDK II.

Several EDK II sample platforms produce this PPI in EDK II, but only
as sample code. Clearly the removal would have to take this into
account.

There are two replacements for the TemporaryRamSupport PPI, but they
do not cover all types of potential hardware. If a platform cannot
access main memory at the same time as the Temporary RAM, then it
would not be supported by the alternatives. Nevertheless, the two
replacements are:

1. Stop producing the PPI, and the PEI Core will automatically copy
   the required memory from Temporary RAM to the main memory. This
   will work for platforms that do not require special code to shut
   down Temporary RAM.

2. Produce the MdePkg/Include/Ppi/TemporaryRamDone.h PPI. This will
   cause the PEI Core to notify the platform after it has copied
   memory, and the platform can take special actions to disable
   Temporary RAM mode if required.

Since both of these options will cause the PEI Core to do a memory
copy from Temporary RAM to the main memory, there might be platforms
that they cannot work with as described above.

Thanks for your time,

-Jordan

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39471): https://edk2.groups.io/g/devel/message/39471
Mute This Topic: https://groups.io/mt/31319621/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms] [RFC] Migrate devel-MinPlatform branch to master branch

[Liming Gao]

Michael:
  I think this change is good. Could you submit one BZ for it?

Thanks
Liming
>-Original Message-
>From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>Kubacki, Michael A
>Sent: Friday, April 19, 2019 5:12 AM
>To: 'devel@edk2.groups.io' 
>Subject: [edk2-devel] [edk2-platforms] [RFC] Migrate devel-MinPlatform
>branch to master branch
>
>Hello,
>
>This RFC proposes moving the content on the devel-MinPlatform branch
>in the edk2-platforms repository to the master branch in the
>edk2-platforms repository.
>
>The devel-MinPlatform branch has been used for the initial development
>of an EDK II based platform design referred to as "Minimum Platform".
>This design is intended to provide a structured approach to introducing
>Intel platform code into open source in a consistent manner.
>
>For more information about the EDK II Minimum Platform, please refer to
>the Readme.md in devel-MinPlatform.
>https://github.com/tianocore/edk2-platforms/blob/devel-
>MinPlatform/ReadMe.md
>
>The following packages would be added in Platform/Intel:
>  * Generic packages:
> * AdvancedFeaturePkg
> * MinPlatformPkg
>  * Board-specific packages:
> * ClevoOpenBoardPkg
> * KabylakeOpenBoardPkg
> * PurleyOpenBoardPkg
>
>The following packages would be added in Silicon/Intel:
> * KabylakeSiliconPkg
> * LewisburgPkg
> * PurleyRcPkg
> * PurleySktPkg
>
>The following growth is expected over time:
> * Platform/Intel - Additional board packages for Intel reference boards
>including support for some pre-existing product releases
> * AdvancedFeaturePkg - Additional modular features capable of being used
>in board packages
> * Silicon/Intel - Additional silicon packages roughly keeping 1:1 parity
>with board packages
>
>We hope the content will enable others to add new board packages and
>advanced
>features over time.
>
>The result of the change is available here for reference:
>https://github.com/lgao4/edk2-platforms
>
>Regards,
>Michael
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39470): https://edk2.groups.io/g/devel/message/39470
Mute This Topic: https://groups.io/mt/31236064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms: PATCH v2 3/3] Marvell/Drivers: Add non-mmio mode to MvFvbDxe

[Ard Biesheuvel]

On Wed, 24 Apr 2019 at 08:52, Marcin Wojtas  wrote:
>
> From: Kornel Duleba 
>
> This path enables support for reading variables directly from flash without
> relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
> allows to switch between the modes. When in non-memory-mapped mode the
> driver will copy the variables from flash to previously allocated buffer
> and set PcdFlashNvStorageVariableBase64, PcdFlashNvStorageFtwWorkingBase64
> and PcdFlashNvStorageFtwSpareBase64 accordingly.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Marvell.dec   |   8 ++
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  10 +-
>  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
>  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
>  Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 135 +++-
>  5 files changed, 135 insertions(+), 36 deletions(-)
>
> diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> index 7210ba2..a23c329 100644
> --- a/Silicon/Marvell/Marvell.dec
> +++ b/Silicon/Marvell/Marvell.dec
> @@ -58,6 +58,12 @@
>
>gMarvellFvbDxeGuid = { 0x42903750, 0x7e61, 0x4aaf, { 0x83, 0x29, 0xbf, 
> 0x42, 0x36, 0x4e, 0x24, 0x85 } }
>gMarvellSpiFlashDxeGuid = { 0x49d7fb74, 0x306d, 0x42bd, { 0x94, 0xc8, 
> 0xc0, 0xc5, 0x4b, 0x18, 0x1d, 0xd7 } }
> +  #
> +  # Generic FaultTolerantWriteDxe driver use variables,
> +  # whose setting is done in MvFvbDxe driver in case
> +  # the SPI contents are not mapped in memory.
> +  #
> +  gFaultTolerantWriteDxeFileGuid = { 0xfe5cea76, 0x4f72, 0x49e8, { 0x98, 
> 0x6f, 0x2c, 0xd8, 0x99, 0xdf, 0xfe, 0x5d} }
>
>  [LibraryClasses]
>ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
> @@ -140,6 +146,8 @@
>  #SPI
>gMarvellTokenSpaceGuid.PcdSpiRegBase|0|UINT32|0x351
>gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0|UINT64|0x359
> +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE|BOOLEAN|0x360
> +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0|UINT32|0x361
>gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|0|UINT32|0x3052
>gMarvellTokenSpaceGuid.PcdSpiClockFrequency|0|UINT32|0x3053
>
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index ca3de2e..d53d128 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -256,6 +256,11 @@
># USB support
>gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
>
> +[PcdsDynamicDefault.common]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
> +
>  [PcdsFixedAtBuild.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"MARVELL_EFI"
>gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> @@ -396,11 +401,10 @@
># Variable store - default values
>#
>gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
> +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE
> +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0x3C
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
>
>  !if $(CAPSULE_ENABLE)
> diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf 
> b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> index ef10bfd..c85e8a6 100644
> --- a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> +++ b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
> @@ -76,13 +76,22 @@
>gMarvellSpiMasterProtocolGuid
>
>  [FixedPcd]
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64
>gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
>gMarvellTokenSpaceGuid.PcdSpiMemoryBase
> +  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped
> +  gMarvellTokenSpaceGuid.PcdSpiVariableOffset
> +
> +[Pcd]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64
>
>  [Depex]
> -  gEfiCpuArchProtocolGuid
> +  #
> +  # Generic FaultTolerantWriteDxe driver use variables,
> +  # whose setting is 

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: BaseSerialPortLib16550: Add Mmio32 support

[Loh, Tien Hock]

Hi Mike, Hao,

Replies inlined.

On Wed, 2019-04-24 at 03:45 +, Michael D Kinney wrote:
> One issue I see is using a FeatureFlag PCD.
> These PCDs can only be TRUE or FALSE, so they can not be
> extended later.  A FixedAtBuild PCD of type BOOL has the 
> same issue.
> 
> It would be better to use a UINTx FixedAtBuild PCD, and 
> define a bit or a value for 32-bit access.  That way, if
> there is a device that requires 16-bit access, it can be
> added in the same PCD.
> 
OK noted. I'll update with UINT8, and set 0x0 to default 8bits and 0x1
to 32 bits access

> Also, should the new PCD be limited to MMIO?  It could be
> an access width PCD that could be applied to I/O or MMIO
> Access.
> 
I'm not sure if this should affect the I/O. I would separate the I/O
access with MMIO access with different PCD, I'll skip this for now as I
don't have platform that uses I/O space, thus I'm unable to test the
changes. 

> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> > On Behalf Of Wu, Hao A
> > Sent: Tuesday, April 23, 2019 8:20 PM
> > To: Loh, Tien Hock ;
> > devel@edk2.groups.io; thlo...@gmail.com
> > Cc: Wang, Jian J 
> > Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg:
> > BaseSerialPortLib16550: Add Mmio32 support
> > 
> > > -Original Message-
> > > From: Loh, Tien Hock
> > > Sent: Wednesday, April 24, 2019 11:05 AM
> > > To: devel@edk2.groups.io; thlo...@gmail.com
> > > Cc: Loh, Tien Hock; Wang, Jian J; Wu, Hao A
> > > Subject: [PATCH 1/1] MdeModulePkg:
> > 
> > BaseSerialPortLib16550: Add Mmio32
> > > support
> > > 
> > > From: "Tien Hock, Loh" 
> > > 
> > > Some busses doesn't allow 8 bit MMIO read/write, this
> > 
> > adds support for
> > > 32 bits read/write
> > 
> > Hello Tien Hock,
> > 
> > Your V2 patch seems to be based on your V1 patch.
> > 
> > Could you help to update the V2 patch to base on the tip
> > of the edk2
> > master branch? Thanks.
> > 
> > One easy way to do this is to squash the 2 commits into
> > one.
> > 
Yes sorry I wasn't aware I'm making patch on top of a patch. 
> > 
> > Some minor comments:
> > A. Please help to update the copyright year for the
> > files:
> >BaseSerialPortLib16550.c
> >BaseSerialPortLib16550.inf
> > 
OK noted. I'll update the copyright year.

> > B. For BaseSerialPortLib16550.inf, maybe:
> > 
> > gEfiMdeModulePkgTokenSpaceGuid.PcdSerialMmio32BitAccess
> > ## SOMETIMES_CONSUMES
> > 
OK noted.

> > is more appropriate here.
> > 
> > Best Regards,
> > Hao Wu
> > 
> > > 
> > > Signed-off-by: "Tien Hock, Loh"
> > 
> > 
> > > Cc: Jian J Wang 
> > > Cc: Hao Wu 
> > > 
> > > --
> > > v2:
> > > - Updates the Pcd name to PcdSerialMmio32BitAccess and
> > 
> > access 32 bits
> > > register if PcdSerialUseMmio and
> > 
> > PcdSerialMmio32BitAccess is set
> > > ---
> > >  .../BaseSerialPortLib16550/BaseSerialPortLib16550.c
> > > 16 
> > >  .../BaseSerialPortLib16550/BaseSerialPortLib16550.inf
> > >  2 +-
> > >  MdeModulePkg/MdeModulePkg.dec
> > > 12 +++-
> > >  3 files changed, 16 insertions(+), 14 deletions(-)
> > > 
> > > diff --git
> > > 
> > 
> > a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > ortLib16550.c
> > > 
> > 
> > b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > ortLib16550.c
> > > index b242b23..f90fb55 100644
> > > ---
> > 
> > a/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > ortLib16550.c
> > > +++
> > > 
> > 
> > b/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialP
> > ortLib16550.c
> > > @@ -76,10 +76,10 @@ SerialPortReadRegister (
> > >UINTN  Offset
> > >)
> > >  {
> > > -  if (PcdGetBool (PcdSerialUseMmio32)) {
> > > -return (UINT8) MmioRead32 (Base + Offset *
> > 
> > PcdGet32
> > > (PcdSerialRegisterStride));
> > > -  }
> > > -  else if (PcdGetBool (PcdSerialUseMmio)) {
> > > +  if (PcdGetBool (PcdSerialUseMmio)) {
> > > +if (PcdGetBool (PcdSerialMmio32BitAccess)) {
> > > +  return (UINT8) MmioRead32 (Base + Offset *
> > 
> > PcdGet32
> > > (PcdSerialRegisterStride));
> > > +}
> > >  return MmioRead8 (Base + Offset * PcdGet32
> > 
> > (PcdSerialRegisterStride));
> > >} else {
> > >  return IoRead8 (Base + Offset * PcdGet32
> > 
> > (PcdSerialRegisterStride));
> > > @@ -106,10 +106,10 @@ SerialPortWriteRegister (
> > >UINT8  Value
> > >)
> > >  {
> > > -  if (PcdGetBool (PcdSerialUseMmio32)) {
> > > -return MmioWrite32 (Base + Offset * PcdGet32
> > 
> > (PcdSerialRegisterStride),
> > > (UINT8)Value);
> > > -  }
> > > -  else if (PcdGetBool (PcdSerialUseMmio)) {
> > > +  if (PcdGetBool (PcdSerialUseMmio)) {
> > > +if (PcdGetBool (PcdSerialMmio32BitAccess)) {
> > > +  return (UINT8) MmioWrite32 (Base + Offset *
> > 
> > PcdGet32
> > > (PcdSerialRegisterStride), (UINT8)Value);
> > > +}
> > >  return MmioWrite8 (Base + Offset * PcdGet32
> > 
> > (PcdSerialRegisterStride),
> > > Value);
> > >} else {
> > >  return IoWrite8 (Base + Offset * PcdGet32

Re: [edk2-devel] [RFC] Propose to remove IpSecDxe

[Liming Gao]

Got it. Thanks!

From: Fu, Siyuan
Sent: Wednesday, April 24, 2019 2:52 PM
To: Gao, Liming ; devel@edk2.groups.io
Cc: Wu, Jiaxin 
Subject: RE: [RFC] Propose to remove IpSecDxe

Hi, Liming

Yes, Wang Fan already sent out the patch to remove both IpSecDxe and the 
IpsecConfig application. See the patch
https://edk2.groups.io/g/devel/message/39389?p=,,,20,0,0,0::relevance,,Remove+IpSec+driver+and+application,20,2,0,31305481


BestRegards
Fu Siyuan

From: Gao, Liming
Sent: Wednesday, April 24, 2019 1:56 PM
To: Fu, Siyuan mailto:siyuan...@intel.com>>; 
devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Siyuan:
  Another question here. Can NetworkPkg\Application\IpsecConfig be also 
removed? If Ipsec driver is removed, IpsecConfig application is not required.

Thanks
Liming
From: Fu, Siyuan
Sent: Monday, April 22, 2019 5:27 PM
To: Gao, Liming mailto:liming@intel.com>>; 
devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Yes, Please.

BestRegards
Fu Siyuan

From: Gao, Liming
Sent: Monday, April 22, 2019 2:13 PM
To: Fu, Siyuan mailto:siyuan...@intel.com>>; 
devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Siyuan:
  Is this change for edk2 Q2 stable tag? If yes, I will add it into edk2 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.

Thanks
Liming
From: Fu, Siyuan
Sent: Thursday, April 11, 2019 6:58 PM
To: devel@edk2.groups.io; Fu, Siyuan 
mailto:siyuan...@intel.com>>
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Bugzilla created for this https://bugzilla.tianocore.org/show_bug.cgi?id=1697

BestRegards
Fu Siyuan

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Siyuan, Fu
Sent: Thursday, April 11, 2019 6:39 PM
To: devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>
Subject: [edk2-devel] [RFC] Propose to remove IpSecDxe

All,

You might notice that some activities about reducing edk2 repo happened or are 
happening.

I propose to remove the IpSecDxe driver from NetworkPkg. Anyone who wants to 
use IpSecDxe can fetch it from stable tag
https://github.com/tianocore/edk2/releases/tag/edk2-stable201903

If you have any concern regarding this, please let me know before 4/20/2019.

Thanks,
Siyuan


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39465): https://edk2.groups.io/g/devel/message/39465
Mute This Topic: https://groups.io/mt/31029253/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [Patch] NetworkPkg: Remove IpSec driver and application

[Siyuan, Fu]

Hi, Fan

The patch is good with me. Below line is not needed in current EDK2 development.
Contributed-under: TianoCore Contribution Agreement 1.1

Reviewed-by: Siyuan Fu 



> -Original Message-
> From: Wang, Fan
> Sent: Tuesday, April 23, 2019 11:17 AM
> To: devel@edk2.groups.io
> Cc: Fu, Siyuan ; Wu, Jiaxin 
> Subject: [Patch] NetworkPkg: Remove IpSec driver and application
> 
> * REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1577
> 
> The IpSec driver in NetworkPkg is not really used by platforms
> but has security risks. So it is scheduled to be removed from
> edk2, also include IpSecConfig application.
> 
> Cc: Fu Siyuan 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Wang Fan 
> ---
>  NetworkPkg/Application/IpsecConfig/Delete.c|  104 -
>  NetworkPkg/Application/IpsecConfig/Delete.h|   36 -
>  NetworkPkg/Application/IpsecConfig/Dump.c  |  573 
>  NetworkPkg/Application/IpsecConfig/Dump.h  |   28 -
>  NetworkPkg/Application/IpsecConfig/ForEach.c   |  109 -
>  NetworkPkg/Application/IpsecConfig/ForEach.h   |   48 -
>  NetworkPkg/Application/IpsecConfig/Helper.c|  414 ---
>  NetworkPkg/Application/IpsecConfig/Helper.h|  137 -
>  NetworkPkg/Application/IpsecConfig/Indexer.c   |  249 --
>  NetworkPkg/Application/IpsecConfig/Indexer.h   |   52 -
>  NetworkPkg/Application/IpsecConfig/IpSecConfig.c   |  806 -
>  NetworkPkg/Application/IpsecConfig/IpSecConfig.h   |  143 -
>  NetworkPkg/Application/IpsecConfig/IpSecConfig.inf |   70 -
>  NetworkPkg/Application/IpsecConfig/IpSecConfig.uni |   17 -
>  .../Application/IpsecConfig/IpSecConfigExtra.uni   |   14 -
>  .../Application/IpsecConfig/IpSecConfigStrings.uni |  127 -
>  NetworkPkg/Application/IpsecConfig/Match.c |  157 -
>  NetworkPkg/Application/IpsecConfig/Match.h |   35 -
>  .../Application/IpsecConfig/PolicyEntryOperation.c | 2070 
>  .../Application/IpsecConfig/PolicyEntryOperation.h |  153 -
>  NetworkPkg/IpSecDxe/ComponentName.c|  345 --
>  NetworkPkg/IpSecDxe/IetfConstants.c|  382 ---
>  NetworkPkg/IpSecDxe/Ike.h  |  260 --
>  NetworkPkg/IpSecDxe/IkeCommon.c|  324 --
>  NetworkPkg/IpSecDxe/IkeCommon.h|  189 --
>  NetworkPkg/IpSecDxe/IkePacket.c|  259 --
>  NetworkPkg/IpSecDxe/IkePacket.h|   76 -
>  NetworkPkg/IpSecDxe/IkeService.c   |  813 -
>  NetworkPkg/IpSecDxe/IkeService.h   |  256 --
>  NetworkPkg/IpSecDxe/Ikev2/ChildSa.c|  193 --
>  NetworkPkg/IpSecDxe/Ikev2/Exchange.c   |  803 -
>  NetworkPkg/IpSecDxe/Ikev2/Ikev2.h  |  252 --
>  NetworkPkg/IpSecDxe/Ikev2/Info.c   |  403 ---
>  NetworkPkg/IpSecDxe/Ikev2/Payload.c| 3329 ---
> -
>  NetworkPkg/IpSecDxe/Ikev2/Payload.h|  437 ---
>  NetworkPkg/IpSecDxe/Ikev2/Sa.c | 2255 -
>  NetworkPkg/IpSecDxe/Ikev2/Utility.c| 2738 
>  NetworkPkg/IpSecDxe/Ikev2/Utility.h| 1061 ---
>  NetworkPkg/IpSecDxe/IpSecConfigImpl.c  | 3156 ---
>  NetworkPkg/IpSecDxe/IpSecConfigImpl.h  |  949 --
>  NetworkPkg/IpSecDxe/IpSecCryptIo.c | 1015 --
>  NetworkPkg/IpSecDxe/IpSecCryptIo.h |  821 -
>  NetworkPkg/IpSecDxe/IpSecDebug.c   |  328 --
>  NetworkPkg/IpSecDxe/IpSecDebug.h   |  101 -
>  NetworkPkg/IpSecDxe/IpSecDriver.c  |  654 
>  NetworkPkg/IpSecDxe/IpSecDxe.inf   |  104 -
>  NetworkPkg/IpSecDxe/IpSecDxe.uni   |   19 -
>  NetworkPkg/IpSecDxe/IpSecDxeExtra.uni  |   14 -
>  NetworkPkg/IpSecDxe/IpSecImpl.c| 2178 -
>  NetworkPkg/IpSecDxe/IpSecImpl.h|  384 ---
>  NetworkPkg/IpSecDxe/IpSecMain.c|  236 --
>  NetworkPkg/NetworkPkg.dec  |   31 -
>  NetworkPkg/NetworkPkg.dsc  |2 -
>  53 files changed, 29709 deletions(-)
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Delete.c
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Delete.h
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Dump.c
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Dump.h
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/ForEach.c
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/ForEach.h
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Helper.c
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Helper.h
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Indexer.c
>  delete mode 100644 NetworkPkg/Application/IpsecConfig/Indexer.h
>  delete mode 100644 

Re: [edk2-devel] [RFC] Propose to remove IpSecDxe

[Siyuan, Fu]

Hi, Liming

Yes, Wang Fan already sent out the patch to remove both IpSecDxe and the 
IpsecConfig application. See the patch
https://edk2.groups.io/g/devel/message/39389?p=,,,20,0,0,0::relevance,,Remove+IpSec+driver+and+application,20,2,0,31305481


BestRegards
Fu Siyuan

From: Gao, Liming
Sent: Wednesday, April 24, 2019 1:56 PM
To: Fu, Siyuan ; devel@edk2.groups.io
Cc: Wu, Jiaxin 
Subject: RE: [RFC] Propose to remove IpSecDxe

Siyuan:
  Another question here. Can NetworkPkg\Application\IpsecConfig be also 
removed? If Ipsec driver is removed, IpsecConfig application is not required.

Thanks
Liming
From: Fu, Siyuan
Sent: Monday, April 22, 2019 5:27 PM
To: Gao, Liming mailto:liming@intel.com>>; 
devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Yes, Please.

BestRegards
Fu Siyuan

From: Gao, Liming
Sent: Monday, April 22, 2019 2:13 PM
To: Fu, Siyuan mailto:siyuan...@intel.com>>; 
devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Siyuan:
  Is this change for edk2 Q2 stable tag? If yes, I will add it into edk2 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.

Thanks
Liming
From: Fu, Siyuan
Sent: Thursday, April 11, 2019 6:58 PM
To: devel@edk2.groups.io; Fu, Siyuan 
mailto:siyuan...@intel.com>>
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Bugzilla created for this https://bugzilla.tianocore.org/show_bug.cgi?id=1697

BestRegards
Fu Siyuan

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Siyuan, Fu
Sent: Thursday, April 11, 2019 6:39 PM
To: devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>
Subject: [edk2-devel] [RFC] Propose to remove IpSecDxe

All,

You might notice that some activities about reducing edk2 repo happened or are 
happening.

I propose to remove the IpSecDxe driver from NetworkPkg. Anyone who wants to 
use IpSecDxe can fetch it from stable tag
https://github.com/tianocore/edk2/releases/tag/edk2-stable201903

If you have any concern regarding this, please let me know before 4/20/2019.

Thanks,
Siyuan


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39463): https://edk2.groups.io/g/devel/message/39463
Mute This Topic: https://groups.io/mt/31029253/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 3/3] Marvell/Drivers: Add non-mmio mode to MvFvbDxe

[Marcin Wojtas]

From: Kornel Duleba 

This path enables support for reading variables directly from flash without
relying on it to be memory mapped. It adds PcdSpiMemoryMapped PCD that
allows to switch between the modes. When in non-memory-mapped mode the
driver will copy the variables from flash to previously allocated buffer
and set PcdFlashNvStorageVariableBase64, PcdFlashNvStorageFtwWorkingBase64
and PcdFlashNvStorageFtwSpareBase64 accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Marvell.dec   |   8 ++
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  10 +-
 Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
 Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
 Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 135 +++-
 5 files changed, 135 insertions(+), 36 deletions(-)

diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
index 7210ba2..a23c329 100644
--- a/Silicon/Marvell/Marvell.dec
+++ b/Silicon/Marvell/Marvell.dec
@@ -58,6 +58,12 @@
 
   gMarvellFvbDxeGuid = { 0x42903750, 0x7e61, 0x4aaf, { 0x83, 0x29, 0xbf, 0x42, 
0x36, 0x4e, 0x24, 0x85 } }
   gMarvellSpiFlashDxeGuid = { 0x49d7fb74, 0x306d, 0x42bd, { 0x94, 0xc8, 0xc0, 
0xc5, 0x4b, 0x18, 0x1d, 0xd7 } }
+  #
+  # Generic FaultTolerantWriteDxe driver use variables,
+  # whose setting is done in MvFvbDxe driver in case
+  # the SPI contents are not mapped in memory.
+  #
+  gFaultTolerantWriteDxeFileGuid = { 0xfe5cea76, 0x4f72, 0x49e8, { 0x98, 0x6f, 
0x2c, 0xd8, 0x99, 0xdf, 0xfe, 0x5d} }
 
 [LibraryClasses]
   ArmadaBoardDescLib|Include/Library/ArmadaBoardDescLib.h
@@ -140,6 +146,8 @@
 #SPI
   gMarvellTokenSpaceGuid.PcdSpiRegBase|0|UINT32|0x351
   gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0|UINT64|0x359
+  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE|BOOLEAN|0x360
+  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0|UINT32|0x361
   gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|0|UINT32|0x3052
   gMarvellTokenSpaceGuid.PcdSpiClockFrequency|0|UINT32|0x3053
 
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index ca3de2e..d53d128 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -256,6 +256,11 @@
   # USB support
   gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
 
+[PcdsDynamicDefault.common]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
+
 [PcdsFixedAtBuild.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"MARVELL_EFI"
   gArmPlatformTokenSpaceGuid.PcdCoreCount|4
@@ -396,11 +401,10 @@
   # Variable store - default values
   #
   gMarvellTokenSpaceGuid.PcdSpiMemoryBase|0xF900
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xF93C
+  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped|TRUE
+  gMarvellTokenSpaceGuid.PcdSpiVariableOffset|0x3C
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x0001
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xF93D
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x0001
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xF93E
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x0001
 
 !if $(CAPSULE_ENABLE)
diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf 
b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
index ef10bfd..c85e8a6 100644
--- a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
+++ b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
@@ -76,13 +76,22 @@
   gMarvellSpiMasterProtocolGuid
 
 [FixedPcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize
-  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gMarvellTokenSpaceGuid.PcdSpiMemoryBase
+  gMarvellTokenSpaceGuid.PcdSpiMemoryMapped
+  gMarvellTokenSpaceGuid.PcdSpiVariableOffset
+
+[Pcd]
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64
 
 [Depex]
-  gEfiCpuArchProtocolGuid
+  #
+  # Generic FaultTolerantWriteDxe driver use variables,
+  # whose setting is done in MvFvbDxe driver in case
+  # the SPI contents are not mapped in memory.
+  #
+  BEFORE gFaultTolerantWriteDxeFileGuid
diff --git a/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h 
b/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h
index 

[edk2-devel] [edk2-platforms: PATCH v2 2/3] Marvell/Armada7k8k: Cleanup PEI phase FV

[Marcin Wojtas]

Currently supported the capsule update scenarios on Armada
platforms require only the SystemFirmwareDescriptor to be installed
in the PEI phase. Remove redundant components and reduce
PEI phase FV footprint.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 3 ---
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index a1ebb81..ca3de2e 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -427,10 +427,7 @@
   ArmPlatformPkg/PlatformPei/PlatformPeim.inf
   ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
   ArmPkg/Drivers/CpuPei/CpuPei.inf
-  MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
 !if $(CAPSULE_ENABLE)
-  MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
-  MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
   
Silicon/Marvell/Armada7k8k/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
 !endif
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf {
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
index d739020..e90e10e 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.fdf
@@ -249,10 +249,7 @@ READ_LOCK_STATUS   = TRUE
   INF ArmPlatformPkg/PlatformPei/PlatformPeim.inf
   INF ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf
   INF ArmPkg/Drivers/CpuPei/CpuPei.inf
-  INF MdeModulePkg/Universal/Variable/Pei/VariablePei.inf
 !if $(CAPSULE_ENABLE)
-  INF MdeModulePkg/Universal/FaultTolerantWritePei/FaultTolerantWritePei.inf
-  INF MdeModulePkg/Universal/CapsulePei/CapsulePei.inf
   INF RuleOverride = FMP_IMAGE_DESC 
Silicon/Marvell/Armada7k8k/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
 !endif
   INF MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39461): https://edk2.groups.io/g/devel/message/39461
Mute This Topic: https://groups.io/mt/31319337/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v2 0/3] Armada7k8k FVB improvements

[Marcin Wojtas]

Hi,

The second version of the patchset, as a result of discussions,
abandons gate-clock handling of the SPI flash, as when booting
from UEFI the proper flow is to rely on description provided
by firmware and the clock handling itself should be left
for the OS entirely.

Instead a new patch is introduced, which removes unused
components from the PEI FV.

The patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/fvb-upstream-r20190424

I'm looking forward to your comments or remarks.

Best regards,
Marcin

Changelog:
v1->v2
 * Replace clock-enabling patch with PEI phase FV cleanup

Hanna Hawa (1):
  Marvell/Drivers: MvFvbDxe: Change Pcd parameters to be 64 bit

Kornel Duleba (1):
  Marvell/Drivers: Add non-mmio mode to MvFvbDxe

Marcin Wojtas (1):
  Marvell/Armada7k8k: Cleanup PEI phase FV

 Silicon/Marvell/Marvell.dec   |  10 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  13 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.fdf |   3 -
 Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |  17 ++-
 Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h   |   1 +
 Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c   | 149 +++-
 6 files changed, 143 insertions(+), 50 deletions(-)

-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39459): https://edk2.groups.io/g/devel/message/39459
Mute This Topic: https://groups.io/mt/31319334/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC] Propose to remove IpSecDxe

[Liming Gao]

Siyuan:
  Another question here. Can NetworkPkg\Application\IpsecConfig be also 
removed? If Ipsec driver is removed, IpsecConfig application is not required.

Thanks
Liming
From: Fu, Siyuan
Sent: Monday, April 22, 2019 5:27 PM
To: Gao, Liming ; devel@edk2.groups.io
Cc: Wu, Jiaxin 
Subject: RE: [RFC] Propose to remove IpSecDxe

Yes, Please.

BestRegards
Fu Siyuan

From: Gao, Liming
Sent: Monday, April 22, 2019 2:13 PM
To: Fu, Siyuan mailto:siyuan...@intel.com>>; 
devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Siyuan:
  Is this change for edk2 Q2 stable tag? If yes, I will add it into edk2 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning.

Thanks
Liming
From: Fu, Siyuan
Sent: Thursday, April 11, 2019 6:58 PM
To: devel@edk2.groups.io; Fu, Siyuan 
mailto:siyuan...@intel.com>>
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>
Subject: RE: [RFC] Propose to remove IpSecDxe

Bugzilla created for this https://bugzilla.tianocore.org/show_bug.cgi?id=1697

BestRegards
Fu Siyuan

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Siyuan, Fu
Sent: Thursday, April 11, 2019 6:39 PM
To: devel@edk2.groups.io
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Gao, Liming 
mailto:liming@intel.com>>
Subject: [edk2-devel] [RFC] Propose to remove IpSecDxe

All,

You might notice that some activities about reducing edk2 repo happened or are 
happening.

I propose to remove the IpSecDxe driver from NetworkPkg. Anyone who wants to 
use IpSecDxe can fetch it from stable tag
https://github.com/tianocore/edk2/releases/tag/edk2-stable201903

If you have any concern regarding this, please let me know before 4/20/2019.

Thanks,
Siyuan


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39458): https://edk2.groups.io/g/devel/message/39458
Mute This Topic: https://groups.io/mt/31029253/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-