[edk2-devel] Please re-sync your calendar to get meeting updates

[Soumya Guptha]

Dear community members,
The groups.io calendar 
(https://edk2.groups.io/g/devel/calendar?calstart=2020-06-04) has shown some 
issues in displaying the correct meeting time. When I sync to my outlook, it is 
off by an hour.
I figured that this is a reported bug in group.io. I worked around it and 
adjusted the calendar so that it accurately displays the time.

Please resync your calendar by subscribing to the calendar  
(https://edk2.groups.io/g/devel/ics/7722204/1063275740/feed.ics), so that it 
will show the correct meeting time.

Please note that there is no change to our community meetings, they are 
scheduled on the first Thursday of every month from 9am-10am (PST) and 
7.30pm-8.30pm (PST).

Thanks,
Soumya

Soumya Guptha
Open Source Firmware PM, SFP/IAGS




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

View/Reply Online (#60317): https://edk2.groups.io/g/devel/message/60317
Mute This Topic: https://groups.io/mt/74494316/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/5] ArmPkg/PlatformBootManagerLib: play nice without ConnectAll()

[Ard Biesheuvel]

On 5/27/20 12:01 AM, Leif Lindholm via groups.io wrote:

On Tue, May 26, 2020 at 18:13:54 +0200, Ard Biesheuvel wrote:

Currently, Armpkg's PlatformBootManagerLib connects all controller to
their drivers recursively, even if the active boot option does not
require it. There are some historical reasons for this, some of which are
being addressed in separate patches.

This series addresses the way ArmPkg's PlatformBootManagerLib implementation
deals with the UEFI Shell and the UiApp: currently, the shell is always
added as an ordinary boot option, which will be started if no other boot
options can be started, or if it is the first one in the boot order.

Once we remove the ConnectAll() call from PlatformBootManagerLib, those shells
will be launched without any block or other devices connected, which may
confuse novice users. So before doing so, let's make the handling a bit more
sane:
- add a 's' hotkey that enters the UEFI shell regardless of its priority
   in the BootOrder - this shell will be entered with no devices connected
   after patch #4
- enter the UiApp as a last resort if no boot options can be started
- make the UEFI Shell boot option hidden, so it is not started by default
   (only by hotkey or BootNext)
- remove the ConnectAll() call from PlatformBootManagerLib
- finally, add a plugin library for UiApp to expose the UEFI Shell via an
   ordinary main menu option (this works around the fact that patch #3 will
   result in the UEFI Shell disappearing from the Boot Manager list).
   Entering the shell this way will resemble the old situation, given that
   UiApp connects all devices and refreshes all boot options etc at launch.


I get why this set was sent in isolation, but could we also discuss
somewhat what we would plan to do with the edk2-platforms that make
use of the ArmPkg PlatformBootManagerLib?

Not attempting a fallback boot onto network is probably an acceptable
change to pick up, but having an undocumented hotkey as the only way
into a shell that now doesn't map devices could be a bit aggravating.



It is not the only way, and it is not even the preferred way. Patch 5/5 
adds an option to the UiApp root menu to enter the UEFI Shell, in a way 
that is independent from boot option handling. Since you enter UiApp 
first, all handles will be connected and boot options refreshed as usual.


In cases where you want to avoid this from happening, you can use the 
's' key to drop into a shell directly.



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

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

[edk2-devel] Updated Event: TianoCore Community Meeting - EMEA/NAMO #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:sb9i.157386325130551.t...@groups.io
DTSTAMP:20200527T051825Z
ORGANIZER;CN=Brian Richardson:mailto:brian.richard...@intel.com
DTSTART;TZID=America/Los_Angeles:20191205T09
DTEND;TZID=America/Los_Angeles:20191205T10
RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=1TH;UNTIL=20200604T155959Z
SUMMARY:TianoCore Community Meeting - EMEA/NAMO
DESCRIPTION:Meeting URL\n\nhttps://bluejeans.com/889357567?src=join_info\
 n\nMeeting ID\n\n889 357 567\n\nWant to dial in from a phone?\n\nDial one
  of the following numbers:\n\n+1.408.740.7256 (US (San Jose))\n\n+1.408.3
 17.9253 (US (Primary, San Jose))\n\n(see all numbers - https://www.blueje
 ans.com/numbers )\n\nEnter the meeting ID and passcode followed by #
LOCATION:https://bluejeans.com/889357567?src=join_info
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

[edk2-devel] Updated Event: TianoCore Community Meeting - APAC/NAMO #cal-invite

[devel@edk2.groups.io Calendar]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:gdko.1573863427728520321.j...@groups.io
DTSTAMP:20200527T051839Z
ORGANIZER;CN=Brian Richardson:mailto:brian.richard...@intel.com
DTSTART;TZID=America/Los_Angeles:20191205T193000
DTEND;TZID=America/Los_Angeles:20191205T203000
RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=1TH;UNTIL=20200605T022959Z
SUMMARY:TianoCore Community Meeting - APAC/NAMO
DESCRIPTION:Meeting URL\n\nhttps://bluejeans.com/889357567?src=join_info\
 n\nMeeting ID\n\n889 357 567\n\nWant to dial in from a phone?\n\nDial one
  of the following numbers:\n\n+1.408.740.7256 (US (San Jose))\n\n+1.408.3
 17.9253 (US (Primary, San Jose))\n\n(see all numbers - https://www.blueje
 ans.com/numbers )\n\nEnter the meeting ID and passcode followed by #
LOCATION:https://bluejeans.com/889357567?src=join_info
SEQUENCE:0
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH 1/3] BaseTools/GenFv: Add PE/COFF resource sections injection to GenFw

[Bob Feng]

Hi Andrew,

This patch cause building GenFw failure.

cl.exe -c  /nologo /Zi /c /O2 /MT /W4 /WX /D _CRT_SECURE_NO_DEPRECATE /D 
_CRT_NONSTDC_NO_DEPRECATE -I . -I 
D:\Edk2Maintain\edk2head\edk2\BaseTools\Source\C\Include -I 
D:\Edk2Maintain\edk2head\edk2\BaseTools\Source\C\Include\Ia32 -I 
D:\Edk2Maintain\edk2head\edk2\BaseTools\Source\C\Common  GenFw.c -FoGenFw.obj
GenFw.c
GenFw.c(3047): error C2220: the following warning is treated as an error
GenFw.c(3047): warning C4244: '=': conversion from 'UINT32' to 'UINT16', 
possible loss of data
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\HostX86\x86\cl.exe"' : 
return code '0x2'
Stop.

The possible fix could be change the parameter Type as UINT16 data type. Would 
you update the patch?

+
+STATIC
+EFI_STATUS
+PatchResourceData (
+  IN UINT32  Type,
+  IN UINT8   *ResourceData,
+  IN UINT32  ResourceDataSize,
+  IN OUT UINT8   **PeCoff,
+  IN OUT UINT32  *PeCoffSize
+  )
+/*++

And a minor comment is about the commit message.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=557 should change to REF: 
https://bugzilla.tianocore.org/show_bug.cgi?id=557 


Thanks,
Bob

-Original Message-
From: Andrew Fish  
Sent: Monday, May 25, 2020 5:20 AM
To: devel@edk2.groups.io
Cc: Andrew Fish ; Feng, Bob C ; Gao, 
Liming 
Subject: [PATCH 1/3] BaseTools/GenFv: Add PE/COFF resource sections injection 
to GenFw

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

The XCODE toolchain does not suport injecting resource sections via libraries 
so add --rc to GenFw to inject $(MODULE_NAME)hii.rc into the final PE/COFF 
image.

Since moving exiting code around would break source level debugging we must 
reuse an existing empty section, or add a new section header.
If there is not space to add a new section header append to the last section. 
The resource entry if found via a directory entry so the PE/COFF loading code 
does not depend on the section type.

Signed-off-by: Andrew Fish 
Cc: Bob Feng 
Cc: Liming Gao 
---
 BaseTools/Source/C/GenFw/GenFw.c | 370 +++
 1 file changed, 370 insertions(+)

diff --git a/BaseTools/Source/C/GenFw/GenFw.c b/BaseTools/Source/C/GenFw/GenFw.c
index 8cab70ba4d5f..748af5dff259 100644
--- a/BaseTools/Source/C/GenFw/GenFw.c
+++ b/BaseTools/Source/C/GenFw/GenFw.c
@@ -96,6 +96,16 @@ ZeroDebugData (
   BOOLEANZeroDebug   ); +STATIC+EFI_STATUS+PatchResourceData (+  IN
 UINT32  Type,+  IN UINT8   *ResourceData,+  IN UINT32  
ResourceDataSize,+  IN OUT UINT8   **PeCoff,+  IN OUT UINT32  *PeCoffSize+  );+ 
STATIC EFI_STATUS SetStamp (@@ -267,6 +277,11 @@ Returns:
 except for -o option. It is a action option.\n\
 If it is combined with other action options, the later\n\  
   input action option will override the previous one.\n");+  
fprintf (stdout, "  --rc FlieName Append a Hii resource section to 
the\n\+last PE/COFF section. The FileName is the 
resource section to append\n\+If FileName does not 
exist this operation is skipped. This feature is\n\+
only intended for toolchains, like XCODE, that don't suport $(RC).\n\+  
  This option can only be combined with -e\n");   fprintf (stdout, 
"  --rebase NewAddress   Rebase image to new base address. New address \n\  
   is also set to the first none code section header.\n\
 It can't be combined with other action options\n\@@ -1059,10 
+1074,12 @@ Returns:
   CHAR8**InputFileName;   char 
*OutImageName;   char *ModuleType;+  char   
  *RcFileName;   CHAR8
*TimeStamp;   FILE *fpIn;   FILE
 *fpOut;   FILE *fpInOut;+  FILE
 *fpRc;   UINT32   Data;   UINT32   
*DataPointer;   UINT32   
*OldDataPointer;@@ -1080,6 +1097,8 @@ Returns:
   UINT32   OutputFileLength;   UINT8   
 *InputFileBuffer;   UINT32   InputFileLength;+ 
 UINT8*RcFileBuffer;+  UINT32   
RcFileLength;   RUNTIME_FUNCTION *RuntimeFunction;   
UNWIND_INFO  *UnwindInfo;   STATUS  
 Status;@@ -1116,6 +1135,7 @@ Returns:
   time_t   OutputFileTime;   struct stat   
   Stat_Buf;   BOOLEAN  ZeroDebugFlag;+  BOOLEAN
  InsertRcFile;SetUtilityName (UTILITY_NAME); @@ 
-1128,6 +1148,7 @@ Returns:
   mInImageName  = NULL; 

Re: [edk2-devel] [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005

[Bret Barkelew via groups.io]

Thanks!

- Bret


From: devel@edk2.groups.io  on behalf of Liming Gao via 
groups.io 
Sent: Tuesday, May 26, 2020 7:21:00 PM
To: Bret Barkelew ; Laszlo Ersek 
; devel@edk2.groups.io ; 
annou...@edk2.groups.io 
Cc: Leif Lindholm ; af...@apple.com ; 
Kinney, Michael D 
Subject: Re: [edk2-devel] [EXTERNAL] Re: Hard Feature Freeze starts now for 
edk2-stable202005


I create PR 
https://github.com/tianocore/edk2/pull/644
 for this patch.



Thanks

Liming

From: Bret Barkelew 
Sent: Wednesday, May 27, 2020 6:11 AM
To: Laszlo Ersek ; devel@edk2.groups.io; Gao, Liming 
; annou...@edk2.groups.io
Cc: Leif Lindholm ; af...@apple.com; Kinney, Michael D 

Subject: Re: [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005



I just looked into it, and I think that AsciiStrCpyS() was the wrong function 
to call in this loop anyway. AsciiStrCpyS() will fail without copying any 
characters.

AsciiStrnCpyS() will perform the string "slicing"/"chunking" that the loop 
seems to expect.



The bug stands and we should try to get that bug fix into the stable tag. 
Thanks!



- Bret





From: Laszlo Ersek mailto:ler...@redhat.com>>
Sent: Monday, May 25, 2020 10:46 AM
To: Bret Barkelew 
mailto:bret.barke...@microsoft.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; liming.gao 
mailto:liming@intel.com>>; 
annou...@edk2.groups.io 
mailto:annou...@edk2.groups.io>>
Cc: Leif Lindholm mailto:l...@nuviainc.com>>; 
af...@apple.com 
mailto:af...@apple.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005



Hi Bret,

On 05/22/20 17:11, Bret Barkelew wrote:
> We’d like to ask that this patch be considered for the stable tag:
> [PATCH v1 1/1] UnitTestFrameworkPkg/UnitTestResultReportLib: Use 
> AsciiStrnCpyS()
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2721data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2698d0e553c04b47194c08d800d398b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260256091133309sdata=MDKQ1CKq9%2B9AfPML0JxcND47UIcQUAibUSAVlfW5iZc%3Dreserved=0
>
> The patch was reviewed prior to the hard freeze date, and is a small change 
> that affects new(ish) code that is not heavily utilized yet.

does the original issue (reported in TianoCore#2721) persist with
TianoCore#2054 fixed?

My understanding (from TianoCore#2721) is that the original
AsciiStrCpyS() call is not buggy, it just triggers a (per spec) error
condition in AsciiStrCpyS(). Previously, that would indeed trip an
ASSERT(), but AIUI that issue has been resolved generally with
TianoCore#2054.

If the AsciiStrCpyS() call remains an issue with the ASSERT() removed,
then replacing the call with AsciiStrnCpyS() still seems like a bugfix
to me, not a "feature", so I think the patch is eligible for merging
during the HFF.

Mike, can you please merge the patch (if it's still needed)?

Thanks
Laszlo


>
> - Bret
>
> From: Liming Gao via groups.io
> Sent: Friday, May 22, 2020 1:01 AM
> To: 
> devel@edk2.groups.io>;
>  
> annou...@edk2.groups.io>
> Cc: Laszlo Ersek; Leif 
> Lindholm; af...@apple.com; 
> Kinney, Michael D
> Subject: [EXTERNAL] [edk2-devel] Hard Feature Freeze starts now for 
> edk2-stable202005
>
> Hi, all
>   Today, we enter into Hard Feature Freeze phase until edk2-stable202005 tag 
> is created at 2020-05-29. In this phase, there is no feature to be pushed. 
> The critical bug fix is still allowed.
>
>   If the patch is sent after Hard Feature Freeze, and plans to catch this 
> stable tag, please add edk2-stable202005 key words in the patch title and BZ, 
> and also cc to Tianocore Stewards, then Stewards can give the comments.
>
> Below is edk2-stable202005 tag planning.
> Date (00:00:00 UTC-8) Description
> 2020-03-04  Beginning of development
> 2020-05-08  Feature Planning Freeze
> 2020-05-15  Soft 

Re: [edk2-devel] [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005

[Liming Gao]

I create PR https://github.com/tianocore/edk2/pull/644 for this patch.

Thanks
Liming
From: Bret Barkelew 
Sent: Wednesday, May 27, 2020 6:11 AM
To: Laszlo Ersek ; devel@edk2.groups.io; Gao, Liming 
; annou...@edk2.groups.io
Cc: Leif Lindholm ; af...@apple.com; Kinney, Michael D 

Subject: Re: [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005

I just looked into it, and I think that AsciiStrCpyS() was the wrong function 
to call in this loop anyway. AsciiStrCpyS() will fail without copying any 
characters.
AsciiStrnCpyS() will perform the string "slicing"/"chunking" that the loop 
seems to expect.

The bug stands and we should try to get that bug fix into the stable tag. 
Thanks!


- Bret


From: Laszlo Ersek mailto:ler...@redhat.com>>
Sent: Monday, May 25, 2020 10:46 AM
To: Bret Barkelew 
mailto:bret.barke...@microsoft.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; liming.gao 
mailto:liming@intel.com>>; 
annou...@edk2.groups.io 
mailto:annou...@edk2.groups.io>>
Cc: Leif Lindholm mailto:l...@nuviainc.com>>; 
af...@apple.com 
mailto:af...@apple.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005

Hi Bret,

On 05/22/20 17:11, Bret Barkelew wrote:
> We'd like to ask that this patch be considered for the stable tag:
> [PATCH v1 1/1] UnitTestFrameworkPkg/UnitTestResultReportLib: Use 
> AsciiStrnCpyS()
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2721data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2698d0e553c04b47194c08d800d398b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260256091133309sdata=MDKQ1CKq9%2B9AfPML0JxcND47UIcQUAibUSAVlfW5iZc%3Dreserved=0
>
> The patch was reviewed prior to the hard freeze date, and is a small change 
> that affects new(ish) code that is not heavily utilized yet.

does the original issue (reported in TianoCore#2721) persist with
TianoCore#2054 fixed?

My understanding (from TianoCore#2721) is that the original
AsciiStrCpyS() call is not buggy, it just triggers a (per spec) error
condition in AsciiStrCpyS(). Previously, that would indeed trip an
ASSERT(), but AIUI that issue has been resolved generally with
TianoCore#2054.

If the AsciiStrCpyS() call remains an issue with the ASSERT() removed,
then replacing the call with AsciiStrnCpyS() still seems like a bugfix
to me, not a "feature", so I think the patch is eligible for merging
during the HFF.

Mike, can you please merge the patch (if it's still needed)?

Thanks
Laszlo


>
> - Bret
>
> From: Liming Gao via groups.io
> Sent: Friday, May 22, 2020 1:01 AM
> To: 
> devel@edk2.groups.io>;
>  
> annou...@edk2.groups.io>
> Cc: Laszlo Ersek; Leif 
> Lindholm; af...@apple.com; 
> Kinney, Michael D
> Subject: [EXTERNAL] [edk2-devel] Hard Feature Freeze starts now for 
> edk2-stable202005
>
> Hi, all
>   Today, we enter into Hard Feature Freeze phase until edk2-stable202005 tag 
> is created at 2020-05-29. In this phase, there is no feature to be pushed. 
> The critical bug fix is still allowed.
>
>   If the patch is sent after Hard Feature Freeze, and plans to catch this 
> stable tag, please add edk2-stable202005 key words in the patch title and BZ, 
> and also cc to Tianocore Stewards, then Stewards can give the comments.
>
> Below is edk2-stable202005 tag planning.
> Date (00:00:00 UTC-8) Description
> 2020-03-04  Beginning of development
> 2020-05-08  Feature Planning Freeze
> 2020-05-15  Soft Feature Freeze
> 2020-05-22  Hard Feature Freeze
> 2020-05-29  Release
>
> Thanks
> Liming
>
> 
>
>

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

View/Reply Online (#60311): https://edk2.groups.io/g/devel/message/60311
Mute This Topic: https://groups.io/mt/74488317/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] BaseTools: Turn on Link Time Optimization (LTO) for XCOODE

[Bob Feng]

Andrew,

Would you please update the BZ status to IN_PROGRESS? And paste the patch 
review link to the comments?

Reviewed-by: Bob Feng 

Thanks,
Bob
-Original Message-
From: devel@edk2.groups.io  On Behalf Of Andrew Fish via 
groups.io
Sent: Monday, May 25, 2020 10:38 AM
To: devel@edk2.groups.io
Cc: Andrew Fish ; Gao, Liming ; Liu, 
Zhiguang 
Subject: [edk2-devel] [PATCH 1/1] BaseTools: Turn on Link Time Optimization 
(LTO) for XCOODE

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

Turn on LTO for XCODE.

We need to pass -object_path_lto  to the linker to keep source level 
debugging working.

OVMF X64 before:
SECFV [14%Full] 212992 total, 30224 used, 182768 free PEIFV [29%Full] 917504 
total, 273256 used, 644248 free DXEFV [40%Full] 12582912 total, 5096904 used, 
7486008 free FVMAIN_COMPACT [37%Full] 3440640 total, 1290240 used, 2150400 free

After:
SECFV [10%Full] 212992 total, 23064 used, 189928 free PEIFV [20%Full] 917504 
total, 192328 used, 725176 free DXEFV [33%Full] 12582912 total, 4193632 used, 
8389280 free FVMAIN_COMPACT [33%Full] 3440640 total, 1165352 used, 2275288 free

Signed-off-by: Andrew Fish 
Cc: Liming Gao 
Cc: Zhiguang Liu 
---
 BaseTools/Conf/tools_def.template | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 923517b5c296..efe8e47af851 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2927,9 +2927,9 @@ RELEASE_XCODE5_*_MTOC_FLAGS = -align 0x20
  # IA-32 definitions -  
DEBUG_XCODE5_IA32_DLINK_FLAGS  = -arch i386 -u _$(IMAGE_ENTRY_POINT) -e 
_$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  -pie -all_load -dead_strip 
-seg1addr 0x240 -read_only_relocs suppress -map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map+  DEBUG_XCODE5_IA32_DLINK_FLAGS  = -arch 
i386 -u _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
-pie -all_load -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map -object_path_lto 
$(DEST_DIR_DEBUG)/$(BASE_NAME).lto   NOOPT_XCODE5_IA32_DLINK_FLAGS  = -arch 
i386 -u _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
-pie -all_load -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map-RELEASE_XCODE5_IA32_DLINK_FLAGS  = -arch 
i386 -u _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
-pie -all_load -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map+RELEASE_XCODE5_IA32_DLINK_FLAGS  = -arch 
i386 -u _$(IMAGE_ENTRY_POINT) -e _$(IMAGE_ENTRY_POINT) -preload -segalign 0x20  
-pie -all_load -dead_strip -seg1addr 0x240 -read_only_relocs suppress -map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map -object_path_lto 
$(DEST_DIR_DEBUG)/$(BASE_NAME).lto  *_XCODE5_IA32_SLINK_FLAGS  = -static -o 
  DEBUG_XCODE5_IA32_ASM_FLAGS  = -arch i386 -g@@ -2938,16 +2938,16 @@ 
RELEASE_XCODE5_IA32_ASM_FLAGS  = -arch i386
   *_XCODE5_IA32_NASM_FLAGS = -f macho32  -  DEBUG_XCODE5_IA32_CC_FLAGS   = 
-arch i386 -c -g -Os   -Wall -Werror -include AutoGen.h -funsigned-char 
-fno-stack-protector -fno-builtin -fshort-wchar -fasm-blocks -mdynamic-no-pic 
-mno-implicit-float -mms-bitfields -msoft-float -Wno-unused-parameter 
-Wno-missing-braces -Wno-missing-field-initializers -Wno-tautological-compare 
-Wno-sign-compare -Wno-varargs 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
$(PLATFORM_FLAGS)-RELEASE_XCODE5_IA32_CC_FLAGS   = -arch i386 -c-Os   
-Wall -Werror -include AutoGen.h -funsigned-char -fno-stack-protector 
-fno-builtin -fshort-wchar -fasm-blocks -mdynamic-no-pic -mno-implicit-float 
-mms-bitfields -msoft-float -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs -Wno-unused-const-variable 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
$(PLATFORM_FLAGS)+  DEBUG_XCODE5_IA32_CC_FLAGS   = -arch i386 -c -g -Os -flto 
-Wall -Werror -include AutoGen.h -funsigned-char -fno-stack-protector 
-fno-builtin -fshort-wchar -fasm-blocks -mdynamic-no-pic -mno-implicit-float 
-mms-bitfields -msoft-float -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs 
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
$(PLATFORM_FLAGS)+RELEASE_XCODE5_IA32_CC_FLAGS   = -arch i386 -c-Os -flto 
-Wall -Werror -include AutoGen.h -funsigned-char -fno-stack-protector 
-fno-builtin -fshort-wchar -fasm-blocks -mdynamic-no-pic -mno-implicit-float 
-mms-bitfields -msoft-float -Wno-unused-parameter -Wno-missing-braces 
-Wno-missing-field-initializers -Wno-tautological-compare -Wno-sign-compare 
-Wno-varargs -Wno-unused-const-variable 

[edk2-devel] Upcoming Event: TianoCore Bug Triage - APAC / NAMO - Tue, 05/26/2020 6:30pm-7:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Tuesday, 26 May 2020, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

*Where:* https://bluejeans.com/889357567?src=join_info

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=816009 )

*Organizer:* Brian Richardson brian.richard...@intel.com ( 
brian.richard...@intel.com?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

*Description:*

https://www.tianocore.org/bug-triage

Meeting URL

https://bluejeans.com/889357567?src=join_info

Meeting ID

889 357 567

Want to dial in from a phone?

Dial one of the following numbers:

+1.408.740.7256 (US (San Jose))

+1.408.317.9253 (US (Primary, San Jose))

(see all numbers - https://www.bluejeans.com/numbers)

Enter the meeting ID and passcode followed by #

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

View/Reply Online (#60308): https://edk2.groups.io/g/devel/message/60308
Mute This Topic: https://groups.io/mt/74491376/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 01/11] PcAtChipsetPkg: Add MMIO Support to RTC driver

[Guomin Jiang]

I am interest with the patch,

I am busy and may review it after August.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of André
> Przywara
> Sent: Friday, May 15, 2020 6:51 PM
> To: Sami Mujawar ; devel@edk2.groups.io
> Cc: ard.biesheu...@arm.com; l...@nuviainc.com; Ni, Ray
> ; alexandru.eli...@arm.com; matteo.carl...@arm.com;
> laura.more...@arm.com; n...@arm.com
> Subject: Re: [edk2-devel] [PATCH v2 01/11] PcAtChipsetPkg: Add MMIO
> Support to RTC driver
> 
> On 14/05/2020 09:40, Sami Mujawar wrote:
> 
> Hi Sami,
> 
> many thanks for your work on that!
> 
> > Some virtual machine managers like kvmtool emulate the MC146818 RTC
> > controller in the MMIO space so that architectures that do not support
> > I/O Mapped I/O can use the RTC. This patch adds MMIO support to the
> > RTC controller driver.
> 
> Is there any chance you could read the MMIO base address from the DT? I
> sent a kvmtool patch to add the missing DT node[1].
> The compatible string would be "motorola,mc146818", with just the usual reg
> property.
> Maybe you could fall back to the current 0x70/0x71, if there is no DT node?
> 
> For a start, this low address (0x70/0x71) causes issues, so we probably need
> to move this permanently.
> But also we want to introduce a more flexible memory layout, so devices can
> move depending on command line parameters.
> 
> It would be great if EDK-2 could cover that from the beginning, so that we
> don't end up with compatibility issues.
> 
> Cheers,
> Andre
> 
> [1] https://lists.cs.columbia.edu/pipermail/kvmarm/2020-May/040703.html
> >
> > The PCD PcdRtcUseMmio has been added to select I/O or MMIO support.
> >   If PcdRtcUseMmio is:
> > TRUE  - Indicates the RTC port registers are in MMIO space.
> > FALSE - Indicates the RTC port registers are in I/O space.
> > Default is I/O space.
> >
> > When MMIO support is selected (PcdRtcUseMmio == TRUE) the driver
> maps
> > the MMIO region used by the RTC as runtime memory so that the RTC
> > registers are accessible post ExitBootServices.
> >
> > Signed-off-by: Sami Mujawar 
> > ---
> >
> > Notes:
> > v2:
> >   - Code review comments incorporated.  
> > [Sami]
> >
> > v1:
> >   - Add support to read/write from RTC registers using MMIO access
> [Sami]
> >   - Use wrapper functions for RtcRead/Write accessors   
> > [Leif]
> > Ref: https://edk2.groups.io/g/devel/topic/30915281#30695
> >
> >  PcAtChipsetPkg/PcAtChipsetPkg.dec  
> > |   8 ++
> >  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c 
> > | 117
> --
> >  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.h 
> > |  31
> +
> >  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
> > |
> 130 +++-
> >
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntime
> Dxe.inf |   8 ++
> >  5 files changed, 280 insertions(+), 14 deletions(-)
> >
> > diff --git a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > index
> >
> 88de5cceea593176c3a2425a5963b66b789f2b9e..76d0c7eda69bb505914ba904
> e09c
> > 89de170f69ae 100644
> > --- a/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > +++ b/PcAtChipsetPkg/PcAtChipsetPkg.dec
> > @@ -6,6 +6,7 @@
> >  #
> >  # Copyright (c) 2009 - 2019, Intel Corporation. All rights
> > reserved.  # Copyright (c) 2017, AMD Inc. All rights reserved.
> > +# Copyright (c) 2018, ARM Limited. All rights reserved.
> >  #
> >  # SPDX-License-Identifier: BSD-2-Clause-Patent  # @@ -142,5 +143,12
> > @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
> ># @Prompt RTC Update Timeout Value.
> >
> >
> gPcAtChipsetPkgTokenSpaceGuid.PcdRealTimeClockUpdateTimeout|10
> |UIN
> > T32|0x0020
> >
> > +  ## Indicates the RTC port registers are in MMIO space, or in I/O space.
> > +  #  Default is I/O space.
> > +  #   TRUE  - RTC port registers are in MMIO space.
> > +  #   FALSE - RTC port registers are in I/O space.
> > +  # @Prompt RTC port registers use MMIO.
> > +
> > +
> gPcAtChipsetPkgTokenSpaceGuid.PcdRtcUseMmio|FALSE|BOOLEAN|0x
> 0021
> > +
> >  [UserExtensions.TianoCore."ExtraFiles"]
> >PcAtChipsetPkgExtra.uni
> > diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
> > b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
> > index
> >
> 52af17941786ef81c3911512ee64551724e67209..df8dea83ab27bbba12351096d
> 1bf
> > d9ea31accb60 100644
> > --- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
> > +++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
> > @@ -3,6 +3,7 @@
> >
> >  Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > reserved.  Copyright (c) 2017, AMD Inc. All rights reserved.
> > +Copyright (c) 2018 - 2020, ARM Limited. All rights reserved.
> >
> >  SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> > @@ -10,6 +11,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  

Re: [edk2-devel] Using debugger to debug UEFI application?

[Lee Fisher]

> [...]I just found the Intel UDK debugger and hopping to use it [...]

I may be wrong, but I think Intel has put the Intel UDK debugger
solution as End-Of-Life. I'm not sure it's worth spending any time using
an end-of-life'd debugger solution. I think the main 2 alternatives to
the Intel UDK solution are: Intel System Studio (ISS), or Tianocore's
SourceLevelDebugPkg.

Over time, ISS has only been available if you registered, or not even as
freeware, so was only an option for some. But currently ISS is
freely-available without registration. ISS is not end-of-life, and I
presume they have a tech support team to help paying users with
questions, if that helps with your current situation.

There is at least one gdb-server project for UEFI outside the Intel UDK
solution and outside Tianocore:

https://github.com/night199uk/edk2-gdb-server

I think there is a second one, but I can't find it at the moment. I wish
Intel would open-source the Intel UDK debugger code, including it's
gdb-server, instead of just killing it off. Perhaps the Tiancore
community would make use of some of the code. Anything to improve UEFI
debugging is a worthy effort. 

Servers aside, I really I wish there there was an lldb.efi and a gdb.efi...


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

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

Re: [edk2-devel] [RFC edk2 v1 1/1] MdeModulePkg/Variable: Move FindVariable after AutoUpdateLangVariable

[Guomin Jiang]

Hi Huangming,

I will clarify it when I am free, please be patient.

If it is urgent for you, I suggest that you can use your patch temporarily.

Any other thing, I check your patch in the mail, it seem that not any change in 
code, can you double confirm it?

Best Regards
> -Original Message-
> From: Ming Huang 
> Sent: Tuesday, May 26, 2020 2:08 PM
> To: Jiang, Guomin ; devel@edk2.groups.io; Wang,
> Jian J ; Wu, Hao A ; Gao,
> Liming 
> Cc: lidongz...@huawei.com; songdongku...@huawei.com;
> wanghuiqi...@huawei.com; qiulian...@huawei.com;
> shenli...@huawei.com
> Subject: Re: [edk2-devel] [RFC edk2 v1 1/1] MdeModulePkg/Variable: Move
> FindVariable after AutoUpdateLangVariable
> 
> 
> 
> 在 2020/5/26 8:39, Jiang, Guomin 写道:
> > Hi Huangming,
> >
> > I am taking the bugzilla and I am sorry that I haven't provide you with
> productive comment.
> >
> > I am still busy until August.
> >
> > I just want to know that:
> > 1. Have you verified that the symptom will disappear after invoked
> FindVariable() function?
> 
> Yes, the symptom will disappeare after add this patch.
> 
> > 2. Is it your suggestion that the FindVariable() need to be invoked but you
> have no idea that how to fix it?
> 
> This patch can fix this issue, and I guess this issue was resulted by adding
> AutoUpdateLangVariable feature.
> I hope this patch can be merged to edk2 master.
> 
> Thanks
> Ming
> 
> >
> > Best Regards
> > Guomin
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of Ming
> >> Huang
> >> Sent: Monday, May 25, 2020 7:34 PM
> >> To: devel@edk2.groups.io; Wang, Jian J ; Wu,
> >> Hao A ; Gao, Liming 
> >> Cc: lidongz...@huawei.com; huangmin...@huawei.com;
> >> songdongku...@huawei.com; wanghuiqi...@huawei.com;
> >> qiulian...@huawei.com; shenli...@huawei.com
> >> Subject: [edk2-devel] [RFC edk2 v1 1/1] MdeModulePkg/Variable: Move
> >> FindVariable after AutoUpdateLangVariable
> >>
> >> When occur reclaim in AutoUpdateLangVariable(), the CurrPtr of
> >> Variable is invalid. The State will be update with wrong position
> >> after UpdateVariable in this situation and two valid PlatformLang or Lang
> variables will exist.
> >> BmForEachVariable() will enter endless loop while exist two valid
> >> PlatformLang variables. So FindVariable() should be invoked atfer
> >> AutoUpdateLangVariable().
> >>
> >> https://bugzilla.tianocore.org/show_bug.cgi?id=2667
> >>
> >> Signed-off-by: Ming Huang 
> >> ---
> >>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 26
> >> ++--
> >>  1 file changed, 13 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> >> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> >> index 1e71fc6..0cec981 100644
> >> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> >> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
> >> @@ -2741,6 +2741,19 @@ VariableServiceSetVariable (
> >>  mVariableModuleGlobal->NonVolatileLastVariableOffset = (UINTN)
> >> NextVariable - (UINTN) Point;
> >>}
> >>
> >> +  if (!FeaturePcdGet (PcdUefiVariableDefaultLangDeprecate)) {
> >> +//
> >> +// Hook the operation of setting PlatformLangCodes/PlatformLang
> >> + and
> >> LangCodes/Lang.
> >> +//
> >> +Status = AutoUpdateLangVariable (VariableName, Data, DataSize);
> >> +if (EFI_ERROR (Status)) {
> >> +  //
> >> +  // The auto update operation failed, directly return to avoid
> >> inconsistency between PlatformLang and Lang.
> >> +  //
> >> +  goto Done;
> >> +}
> >> +  }
> >> +
> >>//
> >>// Check whether the input variable is already existed.
> >>//
> >> @@ -2763,19 +2776,6 @@ VariableServiceSetVariable (
> >>  }
> >>}
> >>
> >> -  if (!FeaturePcdGet (PcdUefiVariableDefaultLangDeprecate)) {
> >> -//
> >> -// Hook the operation of setting PlatformLangCodes/PlatformLang and
> >> LangCodes/Lang.
> >> -//
> >> -Status = AutoUpdateLangVariable (VariableName, Data, DataSize);
> >> -if (EFI_ERROR (Status)) {
> >> -  //
> >> -  // The auto update operation failed, directly return to avoid
> inconsistency
> >> between PlatformLang and Lang.
> >> -  //
> >> -  goto Done;
> >> -}
> >> -  }
> >> -
> >>if (mVariableModuleGlobal->VariableGlobal.AuthSupport) {
> >>  Status = AuthVariableLibProcessVariable (VariableName,
> >> VendorGuid, Data, DataSize, Attributes);
> >>} else {
> >> --
> >> 2.8.1
> >>
> >>
> >> 
> >
> >
> >


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

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

Re: [edk2-devel] Updating to latest EDK2 and now get NMAKE: fatal error U1073: Don't know how to make.. on some items?

[Guomin Jiang]

Hi David,

I saw the below sentence from you.
I got the edk2-libc repo from GIT.  The edk2 repo I still use svn update to 
update it.  Using tortoise tools on windows.

As I know, we not maintain the edk2 in svn from long ago, you can see the svn 
last update data to confirm it.
I suggest that you use the edk2 repo from GIT and try again.

Best Regards
From: David F. 
Sent: Tuesday, May 26, 2020 3:18 PM
To: Jiang, Guomin ; devel@edk2.groups.io
Subject: Re: [edk2-devel] Updating to latest EDK2 and now get NMAKE: fatal 
error U1073: Don't know how to make.. on some items?

Let me start by what I did to get the build working with the old BaseTools.   I 
renamed BaseTools and put back the prior BaseTools from Nov 29 2018 (build.exe 
date).  It started building out of the gate, then hit nasm.inc not found, so 
digging around end up comparing old and new for things and brought over new 
NASM items from new GenMake.py to the old one.  Tried again, same thing, ended 
up fixing by bringing over the new build_rule.txt.  Now everything is building 
fine using VS2008 but the old BaseTools.

I can try using VS2017, I though I was staying with VS2008 is VS2017 added more 
behind the scenes stuff that I have to add replacements for (already have what 
I need for VS2008).  But I really don't remember. I'll do that when I get a 
chance once I catch up on things.


Okay, now on to Guomin message,  Those messages are saying it's not in the 
.inf, which looking in the .inf, they are not.  Although the headers themselves 
exist.  I got the edk2-libc repo from GIT.  The edk2 repo I still use svn 
update to update it.  Using tortoise tools on windows.


Thanks.

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

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

Re: [edk2-devel] Using debugger to debug UEFI application?

[Guomin Jiang]

I will debug the UEFI application without Secure Boot in this case.
Any specific reason that force you debug in Secure Boot environment?

From you comment, it is need that figure out why hang in 
ippsEncodeLZ77DynamicHuff_8u function, I am sorry that I have no knowledge 
about the module and the function.

Best Regards
From: devel@edk2.groups.io  On Behalf Of David F.
Sent: Tuesday, May 26, 2020 3:32 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Using debugger to debug UEFI application?


Hi,

I just found the Intel UDK debugger and hopping to use it to debug my UEFI 
application.  Basically, the function ippsEncodeLZ77DynamicHuff_8u in Intel IPP 
7 (tried 7.1 as well) used in my application will hang if secure boot is 
enabled on most systems (disabled runs fine - someone with vmware workstation 
15 sees same thing as physical system - I can't enable vmware secure boot 
because not running system in UEFI mode) - the source is shared with 
dos/linux/windows and all those work fine.  I'm not sure why it hangs in that 
case, exception? stack? nothing I tried to do like force the stack size helped.

So using this Lenovo laptop sitting next to me, can I use this Intel UDK 
debugger to connect via USB crossover cable  and debug the application.  I 
don't want to spend a bunch of time to only find out you can't do that and need 
special hardware.  If not going to work then I'll have to spend time 
disassembling the application, injecting things in to the 
ippsEncodeLZ77DynamicHuff_8u to see what' up (a lot more work).

Anyone feel free to chime in on what you think may be causing a problem when 
secure boot is enabled?

TIA!!


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

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

Re: [edk2-devel] [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005

[Bret Barkelew via groups.io]

I just looked into it, and I think that AsciiStrCpyS() was the wrong function 
to call in this loop anyway. AsciiStrCpyS() will fail without copying any 
characters.
AsciiStrnCpyS() will perform the string "slicing"/"chunking" that the loop 
seems to expect.

The bug stands and we should try to get that bug fix into the stable tag. 
Thanks!


- Bret


From: Laszlo Ersek 
Sent: Monday, May 25, 2020 10:46 AM
To: Bret Barkelew ; devel@edk2.groups.io 
; liming.gao ; 
annou...@edk2.groups.io 
Cc: Leif Lindholm ; af...@apple.com ; 
Kinney, Michael D 
Subject: [EXTERNAL] Re: Hard Feature Freeze starts now for edk2-stable202005

Hi Bret,

On 05/22/20 17:11, Bret Barkelew wrote:
> We’d like to ask that this patch be considered for the stable tag:
> [PATCH v1 1/1] UnitTestFrameworkPkg/UnitTestResultReportLib: Use 
> AsciiStrnCpyS()
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2721data=02%7C01%7Cbret.barkelew%40microsoft.com%7C2698d0e553c04b47194c08d800d398b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260256091133309sdata=MDKQ1CKq9%2B9AfPML0JxcND47UIcQUAibUSAVlfW5iZc%3Dreserved=0
>
> The patch was reviewed prior to the hard freeze date, and is a small change 
> that affects new(ish) code that is not heavily utilized yet.

does the original issue (reported in TianoCore#2721) persist with
TianoCore#2054 fixed?

My understanding (from TianoCore#2721) is that the original
AsciiStrCpyS() call is not buggy, it just triggers a (per spec) error
condition in AsciiStrCpyS(). Previously, that would indeed trip an
ASSERT(), but AIUI that issue has been resolved generally with
TianoCore#2054.

If the AsciiStrCpyS() call remains an issue with the ASSERT() removed,
then replacing the call with AsciiStrnCpyS() still seems like a bugfix
to me, not a "feature", so I think the patch is eligible for merging
during the HFF.

Mike, can you please merge the patch (if it's still needed)?

Thanks
Laszlo


>
> - Bret
>
> From: Liming Gao via groups.io
> Sent: Friday, May 22, 2020 1:01 AM
> To: devel@edk2.groups.io; 
> annou...@edk2.groups.io
> Cc: Laszlo Ersek; Leif 
> Lindholm; af...@apple.com; 
> Kinney, Michael D
> Subject: [EXTERNAL] [edk2-devel] Hard Feature Freeze starts now for 
> edk2-stable202005
>
> Hi, all
>   Today, we enter into Hard Feature Freeze phase until edk2-stable202005 tag 
> is created at 2020-05-29. In this phase, there is no feature to be pushed. 
> The critical bug fix is still allowed.
>
>   If the patch is sent after Hard Feature Freeze, and plans to catch this 
> stable tag, please add edk2-stable202005 key words in the patch title and BZ, 
> and also cc to Tianocore Stewards, then Stewards can give the comments.
>
> Below is edk2-stable202005 tag planning.
> Date (00:00:00 UTC-8) Description
> 2020-03-04  Beginning of development
> 2020-05-08  Feature Planning Freeze
> 2020-05-15  Soft Feature Freeze
> 2020-05-22  Hard Feature Freeze
> 2020-05-29  Release
>
> Thanks
> Liming
>
> 
>
>


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

View/Reply Online (#60302): https://edk2.groups.io/g/devel/message/60302
Mute This Topic: https://groups.io/mt/74488317/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/5] ArmPkg/PlatformBootManagerLib: play nice without ConnectAll()

[Leif Lindholm]

On Tue, May 26, 2020 at 18:13:54 +0200, Ard Biesheuvel wrote:
> Currently, Armpkg's PlatformBootManagerLib connects all controller to
> their drivers recursively, even if the active boot option does not
> require it. There are some historical reasons for this, some of which are
> being addressed in separate patches.
> 
> This series addresses the way ArmPkg's PlatformBootManagerLib implementation
> deals with the UEFI Shell and the UiApp: currently, the shell is always
> added as an ordinary boot option, which will be started if no other boot
> options can be started, or if it is the first one in the boot order.
> 
> Once we remove the ConnectAll() call from PlatformBootManagerLib, those shells
> will be launched without any block or other devices connected, which may
> confuse novice users. So before doing so, let's make the handling a bit more
> sane:
> - add a 's' hotkey that enters the UEFI shell regardless of its priority
>   in the BootOrder - this shell will be entered with no devices connected
>   after patch #4
> - enter the UiApp as a last resort if no boot options can be started
> - make the UEFI Shell boot option hidden, so it is not started by default
>   (only by hotkey or BootNext)
> - remove the ConnectAll() call from PlatformBootManagerLib
> - finally, add a plugin library for UiApp to expose the UEFI Shell via an
>   ordinary main menu option (this works around the fact that patch #3 will
>   result in the UEFI Shell disappearing from the Boot Manager list).
>   Entering the shell this way will resemble the old situation, given that
>   UiApp connects all devices and refreshes all boot options etc at launch.

I get why this set was sent in isolation, but could we also discuss
somewhat what we would plan to do with the edk2-platforms that make
use of the ArmPkg PlatformBootManagerLib?

Not attempting a fallback boot onto network is probably an acceptable
change to pick up, but having an undocumented hotkey as the only way
into a shell that now doesn't map devices could be a bit aggravating.

/
Leif

> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> 
> Ard Biesheuvel (5):
>   ArmPkg/PlatformBootManagerLib: register 's' as UEFI Shell hotkey
>   ArmPkg/PlatformBootManagerLib: fall back to the UiApp on boot failure
>   ArmPkg/PlatformBootManagerLib: hide UEFI Shell as a regular boot
> option
>   ArmPkg/PlatformBootManagerLib: don't connect all devices on each boot
>   ShellPkg: add BootManager library to add UEFI Shell menu option
> 
>  .../ShellBootManagerLib.inf   |  45 +++
>  .../ShellBootManagerLib/ShellBootManagerLib.h |  44 +++
>  .../PlatformBootManagerLib/PlatformBm.c   |  37 ++-
>  .../ShellBootManagerLib/ShellBootManagerLib.c | 258 ++
>  .../ShellBootManagerLib/ShellBmStrings.uni|  17 ++
>  .../ShellBootManagerLib/ShellBmVfr.Vfr|  37 +++
>  6 files changed, 425 insertions(+), 13 deletions(-)
>  create mode 100644 
> ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.inf
>  create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.h
>  create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.c
>  create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBmStrings.uni
>  create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBmVfr.Vfr
> 
> -- 
> 2.17.1
> 

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

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

Re: [edk2-devel] [PATCH v8 34/46] OvmfPkg: Reserve a page in memory for the SEV-ES usage

[Lendacky, Thomas]

On 5/26/20 9:28 AM, Tom Lendacky wrote:

On 5/25/20 11:00 AM, Laszlo Ersek wrote:

On 05/19/20 23:51, Lendacky, Thomas wrote:
BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C498df3e8d335449e596508d800c4c955%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260192476035384sdata=UKux5gXwpNe59RKQHTyk577b%2B%2FBmTIdblij8JWhXBG4%3Dreserved=0 



Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.

This area will be used by SEV-ES support for two purposes:
   1. Communicating the SEV-ES status during BSP boot to SEC:
  Using a byte of memory from the page, the BSP reset vector code can
  communicate the SEV-ES status to SEC for use before exception
  handling can be enabled in SEC. After SEC, this field is no longer
  valid and the standard way of determine if SEV-ES is active should
  be used.

   2. Establishing an area of memory for AP boot support:
  A hypervisor is not allowed to update an SEV-ES guest's register
  state, so when booting an SEV-ES guest AP, the hypervisor is not
  allowed to set the RIP to the guest requested value. Instead an
  SEV-ES AP must be re-directed from within the guest to the actual
  requested staring location as specified in the INIT-SIPI-SIPI
  sequence.

  Use this memory for reset vector code that can be programmed to have
  the AP jump to the desired RIP location after starting the AP. This
  is required for only the very first AP reset.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/OvmfPkgX64.fdf    |  3 +++
  OvmfPkg/ResetVector/ResetVector.inf   |  1 +
  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 11 +++
  OvmfPkg/ResetVector/ResetVector.nasmb |  1 +
  4 files changed, 16 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 88b1e880e603..8836b30a0cef 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -82,6 +82,9 @@ [FD.MEMFD]
  0x009000|0x002000
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize 


+0x00B000|0x001000
+gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize 


+
  0x01|0x01
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize 

diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf

index 483fd90fe785..e94e1bfcce7e 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -34,6 +34,7 @@ [BuildOptions]
 *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
  [Pcd]
+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
    gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm

index c3587a1b7814..73a4eaadb1b6 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -89,6 +89,10 @@ SevExit:
  ; If SEV-ES is disabled then EAX will be zero.
  ;
  CheckSevEsFeature:
+    ; Initialize the first byte of the workarea to zero to communicate to
+    ; the SEC phase that SEV-ES is not enabled.
+    mov byte[SEV_ES_WORK_AREA], 0
+
  xor   eax, eax
  ; SEV-ES can't be enabled if SEV isn't, so first check the 
encryption

@@ -108,6 +112,13 @@ CheckSevEsFeature:
  ; Restore encryption mask
  mov   edx, ebx
+    test  eax, eax
+    jz    NoSevEs
+
+    ; Set the first byte of the workarea to one to communicate to the SEC
+    ; phase that SEV-ES is enabled.
+    mov   byte[SEV_ES_WORK_AREA], 1
+
  NoSevEs:
  OneTimeCallRet CheckSevEsFeature
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb 
b/OvmfPkg/ResetVector/ResetVector.nasmb

index bfb77e439105..2967617bfaa0 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -72,6 +72,7 @@
    %define GHCB_PT_ADDR (FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase))
    %define GHCB_BASE (FixedPcdGet32 (PcdOvmfSecGhcbBase))
    %define GHCB_SIZE (FixedPcdGet32 (PcdOvmfSecGhcbSize))
+  %define SEV_ES_WORK_AREA (FixedPcdGet32 (PcdSevEsWorkAreaBase))
  %include "Ia32/PageTables64.asm"
  %endif



The OvmfPkg/ResetVector modifications have been moved to this patch, at
least in part, from patch "OvmfPkg/ResetVector: Add support for a 32-bit
SEV check".

And I don't understand why.


I was trying to keep everything logically grouped. The early use of this 
area is to communicate the SEV-ES status to SEC and so logically I thought 
that should be done when the area was introduced.




I mean it's possible that 

Re: [edk2-devel] [PATCH 3/5] ArmPkg/PlatformBootManagerLib: hide UEFI Shell as a regular boot option

[Leif Lindholm]

On Tue, May 26, 2020 at 18:13:57 +0200, Ard Biesheuvel wrote:
> Without ConnectAll() being called on the boot path, the UEFI shell will
> be entered with no block devices or anything else connected, and so for
> the novice user, this is not a very accommodating environment. Now that
> we have made the UiApp the last resort when on boot failure, and made
> the UEFI Shell accessible directly via the 's hotkey if you really need

Typo 's -> 's'.

/
Leif

> it, let's hide it as an ordinary boot option.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index f91f7cd09ca1..b465f9ff388f 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -778,7 +778,7 @@ PlatformBootManagerAfterConsole (
>Key.ScanCode = SCAN_NULL;
>Key.UnicodeChar  = L's';
>PlatformRegisterFvBootOption (
> -, L"UEFI Shell", LOAD_OPTION_ACTIVE, 
> +, L"UEFI Shell", LOAD_OPTION_HIDDEN, 
>  );
>  }
>  
> -- 
> 2.17.1
> 
> 
> 
> 

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

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

Re: [edk2-devel] [PATCH 2/5] ArmPkg/PlatformBootManagerLib: fall back to the UiApp on boot failure

[Leif Lindholm]

On Tue, May 26, 2020 at 18:13:56 +0200, Ard Biesheuvel wrote:
> As a last resort, drop into the UiApp application when no active boot
> options could be started. Doing so will connect all devices, and so
> it will allow the user to enter the Boot Manager submenu and pick a
> network or removable disk option. With the right UiApp library added
> in, the UiApp also gives access to the UEFI Shell.
>
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 23c925bbdb9c..f91f7cd09ca1 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -830,5 +830,19 @@ PlatformBootManagerUnableToBoot (
>VOID
>)
>  {
> -  return;
> +  EFI_STATUS   Status;
> +  EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
> +
> +  //
> +  // BootManagerMenu doesn't contain the correct information when return 
> status
> +  // is EFI_NOT_FOUND.
> +  //
> +  Status = EfiBootManagerGetBootManagerMenu ();
> +  if (EFI_ERROR (Status)) {

Nitpick: comment explicitly mentions EFI_NOT_FOUND, but code checks
for any EFI_ERROR match. Since there are various other error codes
that could be returned, change the comment to "when return status is
not EFI_SUCCESS"?

/
Leif

> +return;
> +  }
> +
> +  for (;;) {
> +EfiBootManagerBoot ();
> +  }
>  }
> -- 
> 2.17.1
> 
> 
> 
> 

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

View/Reply Online (#60298): https://edk2.groups.io/g/devel/message/60298
Mute This Topic: https://groups.io/mt/74481034/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 1/1] Silicon/SynQuacer: use correct argument count for _EVT ACPI method

[Leif Lindholm]

On Mon, May 25, 2020 at 20:24:55 +0200, Ard Biesheuvel wrote:
> The _EVT method on the ACPI0013 Generic Event device takes a single
> argument. Even though we are not interested in its value (given that
> there is only one interrupt source), we still have to declare the
> prototype correctly, or the OS might complain and refuse to call it.
> 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

> ---
>  Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl 
> b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> index 0ea8ce6d5f44..50f1753c3565 100644
> --- a/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> +++ b/Silicon/Socionext/SynQuacer/AcpiTables/Dsdt.asl
> @@ -226,7 +226,7 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "SNI", 
> "SYNQUACR",
>  MASK = 0xfeff
>}
>  
> -  Method (_EVT) {
> +  Method (_EVT, 0x1) {
>  REQC = 0x100
>  Notify (\_SB.PWRB, 0x80)
>}
> -- 
> 2.17.1
> 

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

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

Re: [edk2-devel] [RFC edk2-platforms v1 3/3] Silicon/Hisilicon: Rename EthMac files

[Leif Lindholm]

On Thu, May 21, 2020 at 22:43:04 +0800, Ming Huang wrote:
> As not only update mac address feature in EthMac files, so rename
> them to UpdateDsdt.
> 
> Signed-off-by: Ming Huang 
> ---
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c  |   2 +-
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf |   8 +-
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c| 612 
> 
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.h|  16 -
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/UpdateDsdt.c| 612 
> 
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/UpdateDsdt.h|  16 +
>  6 files changed, 633 insertions(+), 633 deletions(-)
> 
> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c 
> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> index d3ea051..fd67677 100644
> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> @@ -21,7 +21,7 @@
>  #include 
>  #include 
>  #include 
> -#include "EthMac.h"
> +#include "UpdateDsdt.h"
>  
>  EFI_EVENT   mUpdateAcpiDsdtTableEvent;
>  
> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf 
> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
> index 53da731..a2b669d 100644
> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf
> @@ -1,8 +1,8 @@
>  ## @file
>  #
> -#  Copyright (c) 2014, Applied Micro Curcuit Corp. All rights reserved.
> -#  Copyright (c) 2015, Hisilicon Limited. All rights reserved.
> -#  Copyright (c) 2015, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2014 - 2020, Applied Micro Curcuit Corp. All rights 
> reserved.
> +#  Copyright (c) 2015 - 2020, Hisilicon Limited. All rights reserved.
> +#  Copyright (c) 2015 - 2020, Linaro Limited. All rights reserved.

Same comment on copyright as on 1/3 and 2/3.

/
Leif

>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -18,7 +18,7 @@
>  
>  [Sources]
>AcpiPlatform.c
> -  EthMac.c
> +  UpdateDsdt.c
>  
>  [Packages]
>MdePkg/MdePkg.dec
> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c 
> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> deleted file mode 100644
> index 205f2f9..000
> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> +++ /dev/null
> @@ -1,612 +0,0 @@
> -/** @file
> -
> -  Copyright (c) 2014 - 2020, Applied Micro Curcuit Corporation. All rights 
> reserved.
> -  Copyright (c) 2015 - 2020, Hisilicon Limited. All rights reserved.
> -  Copyright (c) 2015 - 2020, Linaro Limited. All rights reserved.
> -  SPDX-License-Identifier: BSD-2-Clause-Patent
> -
> -  This driver is called to initialize the FW part of the PHY in preparation
> -  for the OS.
> -
> -**/
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -
> -// Turn on debug message by enabling below define
> -//#define ACPI_DEBUG
> -
> -#ifdef ACPI_DEBUG
> -#define DBG(arg...) DEBUG((EFI_D_ERROR,## arg))
> -#else
> -#define DBG(arg...)
> -#endif
> -
> -#define EFI_ACPI_MAX_NUM_TABLES 20
> -#define DSDT_SIGNATURE  0x54445344
> -
> -#define ACPI_ETH_MAC_KEY"local-mac-address"
> -#define ACPI_ETH_SAS_KEY "sas-addr"
> -
> -#define PREFIX_VARIABLE_NAMEL"MAC"
> -#define PREFIX_VARIABLE_NAME_COMPAT L"RGMII_MAC"
> -#define ADDRESS_MAX_LEN 30
> -
> -CHAR8 *mHisiAcpiDevId[] = {"HISI00C1","HISI00C2","HISI0162"};
> -
> -typedef enum {
> -  DsdtDeviceUnknown,
> -  DsdtDeviceLan,
> -  DsdtDeviceSas
> -} DSDT_DEVICE_TYPE;
> -
> -EFI_STATUS GetEnvMac(
> -  IN  UINTNMacNextID,
> -  IN OUT  UINT8*MacBuffer)
> -{
> -  EFI_MAC_ADDRESS Mac;
> -  EFI_STATUS Status;
> -  HISI_BOARD_NIC_PROTOCOL *OemNic = NULL;
> -
> -  Status = gBS->LocateProtocol(, NULL, (VOID 
> **));
> -  if(EFI_ERROR(Status))
> -  {
> -DEBUG((EFI_D_ERROR, "[%a]:[%dL] LocateProtocol failed %r\n", 
> __FUNCTION__, __LINE__, Status));
> -return Status;
> -  }
> -
> -  Status = OemNic->GetMac(, MacNextID);
> -  if(EFI_ERROR(Status))
> -  {
> -DEBUG((EFI_D_ERROR, "[%a]:[%dL] GetMac failed %r\n", __FUNCTION__, 
> __LINE__, Status));
> -return Status;
> -  }
> -
> -  CopyMem (MacBuffer, , 6);
> -  DEBUG((EFI_D_ERROR, "Port %d MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
> -MacNextID,
> -MacBuffer[0],
> -MacBuffer[1],
> -MacBuffer[2],
> -MacBuffer[3],
> -MacBuffer[4],
> -MacBuffer[5]
> -));
> -
> -  return EFI_SUCCESS;
> -}
> -
> -EFI_STATUS GetSasAddress (
> -  IN UINT8Index,
> -  IN OUT UINT8

Re: [edk2-devel] [RFC edk2-platforms v1 2/3] Silicon/Hisilicon/Acpi: Add update sas address feature

[Leif Lindholm]

On Thu, May 21, 2020 at 22:43:03 +0800, Ming Huang wrote:
> The updating sas address feature is similar with apdating mac address.
> Modify updating dsdt flow for add this feature.
> 
> Signed-off-by: Ming Huang 
> ---
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c |   2 +-
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c   | 200 
> +++-
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.h   |   2 +-
>  3 files changed, 158 insertions(+), 46 deletions(-)
> 
> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c 
> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> index 1ab55bc..d3ea051 100644
> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> @@ -46,7 +46,7 @@ UpdateAcpiDsdt (
>  return;
>}
>  
> -  Status = EthMacInit ();
> +  Status = UpdateAcpiDsdtTable ();
>if (EFI_ERROR (Status)) {
>  DEBUG ((DEBUG_ERROR, " UpdateAcpiDsdtTable Failed, Status = %r\n", 
> Status));
>}
> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c 
> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> index cd98506..205f2f9 100644
> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
> @@ -1,8 +1,8 @@
>  /** @file
>  
> -  Copyright (c) 2014, Applied Micro Curcuit Corporation. All rights 
> reserved.
> -  Copyright (c) 2015, Hisilicon Limited. All rights reserved.
> -  Copyright (c) 2015, Linaro Limited. All rights reserved.
> +  Copyright (c) 2014 - 2020, Applied Micro Curcuit Corporation. All rights 
> reserved.
> +  Copyright (c) 2015 - 2020, Hisilicon Limited. All rights reserved.
> +  Copyright (c) 2015 - 2020, Linaro Limited. All rights reserved.

Same comment as for 1/3.

>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>This driver is called to initialize the FW part of the PHY in preparation
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Good lord this include block is a mess.
Nevertheless, a less offensive place to insert this new header would
be between
#include 
and
#include 
.

>  
>  #include 
>  
> @@ -45,13 +46,20 @@
>  #define EFI_ACPI_MAX_NUM_TABLES 20
>  #define DSDT_SIGNATURE  0x54445344
>  
> -#define D03_ACPI_ETH_ID "HISI00C2"
> -
>  #define ACPI_ETH_MAC_KEY"local-mac-address"
> +#define ACPI_ETH_SAS_KEY "sas-addr"

Please consider column alignment.

>  
>  #define PREFIX_VARIABLE_NAMEL"MAC"
>  #define PREFIX_VARIABLE_NAME_COMPAT L"RGMII_MAC"
> -#define MAC_MAX_LEN 30
> +#define ADDRESS_MAX_LEN 30

Please consider column alignment.

>
> +CHAR8 *mHisiAcpiDevId[] = {"HISI00C1","HISI00C2","HISI0162"};
> +
> +typedef enum {
> +  DsdtDeviceUnknown,
> +  DsdtDeviceLan,
> +  DsdtDeviceSas
> +} DSDT_DEVICE_TYPE;
>  
>  EFI_STATUS GetEnvMac(
>IN  UINTNMacNextID,
> @@ -89,12 +97,35 @@ EFI_STATUS GetEnvMac(
>return EFI_SUCCESS;
>  }
>  
> -EFI_STATUS _SearchReplacePackageMACAddress(
> +EFI_STATUS GetSasAddress (

Function name should be on separate line.
If only used in this module, function should also be STATIC.

> +  IN UINT8Index,
> +  IN OUT UINT8*SasAddrBuffer
> +  )
> +{
> +  if (SasAddrBuffer == NULL) {
> +  return EFI_INVALID_PARAMETER;
> +  }
> +
> +  SasAddrBuffer[0] = 0x50;
> +  SasAddrBuffer[1] = 0x01;
> +  SasAddrBuffer[2] = 0x88;
> +  SasAddrBuffer[3] = 0x20;
> +  SasAddrBuffer[4] = 0x16;
> +  SasAddrBuffer[5] = 0x00;
> +  SasAddrBuffer[6] = 0x00;
> +  SasAddrBuffer[7] = Index;

What does the above do?
What are the hardcoded values?

> +
> +  return EFI_SUCCESS;
> +}
> +
> +EFI_STATUS _SearchReplacePackageAddress(

Function name should be on separate line.
If only used in this module, function should also be STATIC.
Functions should not have names starting with _.

>IN EFI_ACPI_SDT_PROTOCOL  *AcpiTableProtocol,
>IN EFI_ACPI_HANDLEChildHandle,
>IN UINTN  Level,
>IN OUT BOOLEAN*Found,
> -  IN UINTN  MacNextID)
> +  IN UINTN  DevNextID,
> +  IN DSDT_DEVICE_TYPE   FoundDev
> +  )
>  {
>// ASL template for ethernet driver:
>  /*
> @@ -117,12 +148,18 @@ EFI_STATUS _SearchReplacePackageMACAddress(
>UINTN   Count;
>EFI_ACPI_HANDLE CurrentHandle;
>EFI_ACPI_HANDLE NextHandle;
> -  UINT8   MACBuffer[MAC_MAX_LEN];
> +  EFI_ACPI_HANDLE Level1Handle;
> +  UINT8   *AddressBuffer;
> +  UINT8   AddressByte = 0;
>  
>DBG("In Level:%d\n", Level);
> +  Level1Handle = NULL;
>Status = EFI_SUCCESS;
>for (CurrentHandle = NULL; ;) {
>  Status = AcpiTableProtocol->GetChild(ChildHandle, );
> +if (Level == 1) {
> +  Level1Handle = CurrentHandle;
> +}
>  if (Level != 3 && (EFI_ERROR(Status) || 

Re: [edk2-devel] [RFC edk2-platforms v1 0/3] Improve D0x

[Leif Lindholm]

On trying to build the resulting output, I found the build breaks with
/work/git/edk2-platforms/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c:
In function ‘FlashFvbInitialize’:
/work/git/edk2-platforms/Silicon/Hisilicon/Drivers/FlashFvbDxe/FlashFvbDxe.c:1231:20:
error: ‘gEfiEventVirtualAddressChangeGuid’ undeclared (first use in
this function); did you mean ‘EfiSetVirtualAddressMap’?
   ,
   ^
   
EfiSetVirtualAddressMap

The error would appear identical to that resolved by
commit a327627dd3f9edc113b1de6d897222d0517834db

Could you please provide a corresponding fix?

Best Regards,

Leif

On Thu, May 21, 2020 at 22:43:01 +0800, Ming Huang wrote:
> Main Changes:
> Add update sas address feature in AcpiPlatformDxe.
> 
> Ming Huang (3):
>   Silicon/Hisilicon: Change updating dsdt in ready to boot event
>   Silicon/Hisilicon/Acpi: Add update sas address feature
>   Silicon/Hisilicon: Rename EthMac files
> 
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c  |  62 +-
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatformDxe.inf |   8 +-
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c| 500 
> 
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.h|  16 -
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/UpdateDsdt.c| 612 
> 
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/UpdateDsdt.h|  16 +
>  6 files changed, 689 insertions(+), 525 deletions(-)
>  delete mode 100644 Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.c
>  delete mode 100644 Silicon/Hisilicon/Drivers/AcpiPlatformDxe/EthMac.h
>  create mode 100644 Silicon/Hisilicon/Drivers/AcpiPlatformDxe/UpdateDsdt.c
>  create mode 100644 Silicon/Hisilicon/Drivers/AcpiPlatformDxe/UpdateDsdt.h
> 
> -- 
> 2.8.1
> 

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

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

Re: [edk2-devel] [RFC edk2-platforms v1 1/3] Silicon/Hisilicon: Change updating dsdt in ready to boot event

[Leif Lindholm]

Please call your patches PATCH. RFC is when a potential solution
is put up for discussion, not for changing platform code.

On Thu, May 21, 2020 at 22:43:02 +0800, Ming Huang wrote:
> The better time for updating dsdt is in ready to boot event,
> so change the updating time.

The commit message should explain *why* it is better.

> 
> Signed-off-by: Ming Huang 
> ---
>  Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c | 60 
> ++--
>  1 file changed, 56 insertions(+), 4 deletions(-)
> 
> diff --git a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c 
> b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> index b888cb1..1ab55bc 100644
> --- a/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> +++ b/Silicon/Hisilicon/Drivers/AcpiPlatformDxe/AcpiPlatform.c
> @@ -1,8 +1,8 @@
>  /** @file
>  
> -  Copyright (c) 2014, Applied Micro Curcuit Corporation. All rights 
> reserved.
> -  Copyright (c) 2015, Hisilicon Limited. All rights reserved.
> -  Copyright (c) 2015, Linaro Limited. All rights reserved.
> +  Copyright (c) 2014 - 2020, Applied Micro Curcuit Corporation. All rights 
> reserved.
> +  Copyright (c) 2015 - 2020, Hisilicon Limited. All rights reserved.
> +  Copyright (c) 2015 - 2020, Linaro Limited. All rights reserved.

Only the Hisilicon copyright should be updated (or a Huawei one added,
given that this is the address used for submitting).

/
Leif

>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  **/
> @@ -23,6 +23,38 @@
>  #include 
>  #include "EthMac.h"
>  
> +EFI_EVENT   mUpdateAcpiDsdtTableEvent;
> +
> +VOID
> +EFIAPI
> +UpdateAcpiDsdt (
> +  IN EFI_EVENT Event,
> +  IN VOID  *Context
> +  )
> +{
> +  EFI_ACPI_TABLE_PROTOCOL *AcpiTableProtocol;
> +  EFI_STATUS  Status;
> +
> +  Status = gBS->LocateProtocol (
> +  ,
> +  NULL,
> +  (VOID**)
> +  );
> +
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, " Unable to locate ACPI table protocol\n"));
> +return;
> +  }
> +
> +  Status = EthMacInit ();
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, " UpdateAcpiDsdtTable Failed, Status = %r\n", 
> Status));
> +  }
> +
> +  gBS->CloseEvent (Event);
> +  return;
> +}
> +
>  EFI_STATUS
>  EFIAPI
>  AcpiPlatformEntryPoint (
> @@ -30,5 +62,25 @@ AcpiPlatformEntryPoint (
>IN EFI_SYSTEM_TABLE   *SystemTable
>)
>  {
> -  return EthMacInit();
> +  EFI_STATUS Status;
> +
> +  //
> +  // Register notify function
> +  //
> +  Status = gBS->CreateEventEx (
> +  EVT_NOTIFY_SIGNAL,
> +  TPL_CALLBACK,
> +  UpdateAcpiDsdt,
> +  NULL,
> +  ,
> +  
> +  );
> +
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Create ReadyToBoot event for UpdateAcpiDsdt 
> failed.\n"));
> +  } else {
> +DEBUG ((DEBUG_INFO, "Create ReadyToBoot event for UpdateAcpiDsdt 
> success.\n"));
> +  }
> +
> +  return Status;
>  }
> -- 
> 2.8.1
> 

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

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

Re: [edk2-devel] [PATCH v8 36/46] OvmfPkg/ResetVector: Add support for a 32-bit SEV check

[Lendacky, Thomas]

On 5/25/20 11:50 AM, Laszlo Ersek wrote:

Tom,

On 05/19/20 23:51, Lendacky, Thomas wrote:

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C4fe7191ef9fe43793eb408d800cbbb44%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260222303712873sdata=DJP9%2Fbe1ttZ%2FGEwqZ2Flv5z4dTV0T8QkYdeSnaIGWcY%3Dreserved=0

During BSP startup, the reset vector code will issue a CPUID instruction
while in 32-bit mode. When running as an SEV-ES guest, this will trigger
a #VC exception.

Add exception handling support to the early reset vector code to catch
these exceptions.  Also, since the guest is in 32-bit mode at this point,
writes to the GHCB will be encrypted and thus not able to be read by the
hypervisor, so use the GHCB CPUID request/response protocol to obtain the
requested CPUID function values and provide these to the guest.

The exception handling support is active during the SEV check and uses the
OVMF temporary RAM space for a stack. After the SEV check is complete, the
exception handling support is removed and the stack pointer cleared.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/ResetVector/ResetVector.inf   |   2 +
  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 329 +++---
  OvmfPkg/ResetVector/ResetVector.nasmb |   1 +
  3 files changed, 294 insertions(+), 38 deletions(-)


this doesn't work for me.

Under your v5 posting, I reviewed those OvmfPkg patches that still
needed my review.

The v6 posting carried all my R-b's; all OvmfPkg patches had been
reviewed. I trusted you and I only verified the commit messages for my
R-b's. I thought the OvmfPkg state was final.

The v7 posting again carried my R-b's; I briefly checked the v6->v7
changes in the blurb, and re-checked my R-b's on the OvmfPkg patches.
This was in the v7 blurb:


Changes since v6:
- Add function comments to all functions, including local functions
- Add function parameter direction to all functions (in/out)
- Add support for MMIO MOVZX/MOVSX instructions
- Ensure the per-CPU variable page remains encrypted
- Coding-style fixes as identified by Ecc


This summary didn't indicate I'd have to go through the OvmfPkg patches
again -- and the presence of my R-b's on all the OvmfPkg patches
supported that impression.

I commented on v7 only later, independently; namely on two topics:

- on one of the S3 reservation aspects,
- on the upcoming / requested movement of VmgExitLib to OvmfPkg.

These were the two updates I was going to expect in v8.

So, in order to "page in" your work again, in preparation for reviewing
v8, I decided to review the v5->v6 changes in more detail -- the code
too (incrementally), not just the picking up of my R-b's, like I had
originally done under v6. I was happy with v6, after performing this
review; see 
.

Now I'm reviewing the differences (incrementally from v6 to v8), and I'm
shocked how many changes you incorporated into preexistent patches,
while keeping my R-b's.


My apologies for this. I was experimenting with cleaning things up and 
making the code more readable and I guess I forgot to either remove it or 
note it as a change to be re-reviewed - thinking I had done one or the other.




On this patch, you significantly changed the logic from v6 to v7, and I
don't have the slightest clue why. I don't feel inclined to
reverse-engineer the logic change from the v6->v7 interdiff. The right
way to present a significant change is to (a) drop the existent R-b's
from the patch, and (b) spell out the news in the blurb and/or in the
"notes" section of the individual patch. If you had dropped the R-b in
v7, then I would have known to review the changes in v7 at once (rather
than let it accumulate to v8). And if you had explained the updates, I
may have started with a re-review of the patch from scratch (and
wouldn't be stuck with an incremental one / interdiff now, between v6
and v8).

Then, the patch changed *again*, from v7 to v8; and my R-b (which only
applied to v6) got carried forward again.

Consider the v7->v8 changes noted in the blurb:


Changes since v7:
- Reserve the SEV-ES workarea when S3 is enabled
- Fix warnings issued by the Visual Studio compiler
- Create a NULL VmgExitLib instance that is used for VMGEXIT
   related operations as well as #VC handling. Then create the full
   VmgExitLib support only in OvmfPkg - where it will be used. This
   removes a bunch of implementation code from platforms that will
   not be using the functionality.
- Remove single use interfaces from 

Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

[Bret Barkelew via groups.io]

Samer,

Have you had a chance to review Mike’s PR process? Any thoughts as comparison?

- Bret

From: devel@edk2.groups.io  on behalf of Samer 
El-Haj-Mahmoud via groups.io 
Sent: Tuesday, May 26, 2020 7:39:55 AM
To: r...@edk2.groups.io ; ler...@redhat.com 
; Andrew Fish 
Cc: Bret Barkelew ; devel@edk2.groups.io 
; spbro...@outlook.com ; Desimone, 
Nathaniel L ; Kinney, Michael D 
; Leif Lindholm (Nuvia address) 
; Samer El-Haj-Mahmoud 
Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code 
Review Process

I agree with Andrew. I also found Laszlo's "unkempt guide" very useful. In 
addition, there is a short page by Peter Batard that adds more details on the 
commits validation, patchset generation, and e-mail submission: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fpbatard%2Fec1c9d1dd6e7144b07a09b057b1735a8data=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdca587d1198049354a6f08d80182b15a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261008123224059sdata=e%2Bk1gQubOWY8gWlQAUAmjIIaqQMv6p%2FMqjUHcntVm1g%3Dreserved=0


> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of Laszlo Ersek
> via groups.io
> Sent: Tuesday, May 26, 2020 7:18 AM
> To: Andrew Fish 
> Cc: Bret Barkelew ; devel@edk2.groups.io;
> spbro...@outlook.com; r...@edk2.groups.io; Desimone, Nathaniel L
> ; Mike Kinney
> ; Leif Lindholm (Nuvia address)
> 
> Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based
> Code Review Process
>
> On 05/25/20 20:28, Andrew Fish wrote:
> >
> >
> >> On May 25, 2020, at 11:10 AM, Laszlo Ersek  wrote:
> >>
> >> Hi Andrew,
> >>
> >> On 05/25/20 06:09, Andrew Fish wrote:
> >>
> >>> I also found I had to Bing/Google to find the detailed instructions
> >>> I needed as a developer, as the Wiki seems to assume you just know
> >>> the Linux kernel patch process. That feels like an area we can improve.
> >>
> >> (apologies if I've lost context; please disregard my message below in
> >> that case).
> >>
> >> I wrote the following wiki article originally in 2016:
> >>
> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FLaszlo%27s-unkempdata=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdca587d1198049354a6f08d80182b15a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261008123224059sdata=hwAXd7kabi4mQyTEr7AWlEyA4yHDkdwG8zr1lirgmA4%3Dreserved=0
> >> t-git-guide-for-edk2-contributors-and-maintainers
> >>
> >> I wrote it specifically for developers & maintainers with no (or
> >> almost
> >> no) prior git / mailing list experience. Multiple developers
> >> confirmed later that the article had helped them.
> >>
> >
> > Laszlo,
> >
> > Your wiki article was very very helpful. I just could not find it from the
> Tianocre wiki. It would be good if we could link to it from here [1], maybe as
> add to this: "Are you new to using git? If so, then the New to git page may be
> helpful."?
>
> The article at [1] is an official document, while the "unkempt guide" is not
> official. The unkempt guide starts by deferring to [1]. I didn't think the 
> official
> document should point to my unofficial one, and/or we should create a loop
> of links.
>
> That said, if someone else updates [1] with a pointer, I won't protest.
> That's just something that I (having authored the unkempt guide) would not
> propose myself.
>
> I do agree that the wiki search facilities on github are basic. What has 
> mostly
> worked for me is clicking the Pages arrow, and then entering a *very simple*
> search term in the drop-down search box. For example, if I do that now, and
> only enter "git", then the "unkempt guide" is listed (with other hits of
> course). I think this search box is basically for searching article titles.
>
> >
> > There are a lot folks who use git but don't use the email based review so
> they have never setup git with emali before. Your wiki, plus me figuring out
> the magic internal SMTP reflector (I reached out on an internal git malling 
> list)
> is what got me unblocked.
>
> It's great that you have access to such infrastructure at Apple!
>
> Thanks!
> Laszlo
>
>
> >
> > [1]
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Ftianocore.github.io%2Fwiki%2FEDK-II-Developmedata=02%7C01%7Cbret.barkelew%40microsoft.com%7Cdca587d1198049354a6f08d80182b15a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261008123234063sdata=UqY5uoxqMamf5PkFLOJ20YKE1aWTZRqGnEYuK93AxiA%3Dreserved=0
> > nt-Process
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >> Thanks
> >> Laszlo
> >>
> >
>
>
>

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.

[edk2-devel] [PATCH 1/5] ArmPkg/PlatformBootManagerLib: register 's' as UEFI Shell hotkey

[Ard Biesheuvel]

In preparation of hiding the UEFI Shell boot option as an ordinary
boot option, make sure we can invoke it directly using the 's'
hotkey. Without ConnectAll() having been called, this results in
a shell that may have no block devices or other things connected,
so don't advertise the 's' in the console string that is printed
at boot - for novice users, we will go through the UiApp which
connects everything first. For advanced use, having the ability
to invoke the UEFI shell without any devices connected may be an
advantage, so let's keep this behavior as is for now.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 4aca1382b042..23c925bbdb9c 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -357,7 +357,8 @@ VOID
 PlatformRegisterFvBootOption (
   CONST EFI_GUID   *FileGuid,
   CHAR16   *Description,
-  UINT32   Attributes
+  UINT32   Attributes,
+  EFI_INPUT_KEY*Key
   )
 {
   EFI_STATUSStatus;
@@ -409,6 +410,9 @@ PlatformRegisterFvBootOption (
   if (OptionIndex == -1) {
 Status = EfiBootManagerAddLoadOptionVariable (, MAX_UINTN);
 ASSERT_EFI_ERROR (Status);
+Status = EfiBootManagerAddKeyOptionVariable (NULL,
+   (UINT16)NewOption.OptionNumber, 0, Key, NULL);
+ASSERT (Status == EFI_SUCCESS || Status == EFI_ALREADY_STARTED);
   }
   EfiBootManagerFreeLoadOption ();
   EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount);
@@ -721,6 +725,7 @@ PlatformBootManagerAfterConsole (
   UINTN FirmwareVerLength;
   UINTN PosX;
   UINTN PosY;
+  EFI_INPUT_KEY Key;
 
   FirmwareVerLength = StrLen (PcdGetPtr (PcdFirmwareVersionString));
 
@@ -770,8 +775,10 @@ PlatformBootManagerAfterConsole (
   //
   // Register UEFI Shell
   //
+  Key.ScanCode = SCAN_NULL;
+  Key.UnicodeChar  = L's';
   PlatformRegisterFvBootOption (
-, L"UEFI Shell", LOAD_OPTION_ACTIVE
+, L"UEFI Shell", LOAD_OPTION_ACTIVE, 
 );
 }
 
-- 
2.17.1


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

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

[edk2-devel] [PATCH 5/5] ShellPkg: add BootManager library to add UEFI Shell menu option

[Ard Biesheuvel]

Add a plug-in library for UiApp that creates a 'UEFI Shell' menu
option at the root level which gives access to a form that allows
the UEFI Shell to be launched.

This gives the PlatformBootManagerLib implementation of the platform
more flexibility in the way it handles boot options pointing to the
UEFI Shell, which will typically be invoked with only the boot path
connected on fast boots.

This library may be incorporated to a platform build by adding a
NULL resolution to the  section of the UiApp.inf
{} block in the platform .DSC

Signed-off-by: Ard Biesheuvel 
---
 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.inf |  45 
 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.h   |  44 
 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.c   | 258 

 ShellPkg/Library/ShellBootManagerLib/ShellBmStrings.uni  |  17 ++
 ShellPkg/Library/ShellBootManagerLib/ShellBmVfr.Vfr  |  37 +++
 5 files changed, 401 insertions(+)

diff --git a/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.inf 
b/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.inf
new file mode 100644
index ..d8b56268c08f
--- /dev/null
+++ b/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.inf
@@ -0,0 +1,45 @@
+## @file
+#
+#  Boot Maintenance Manager Library to add a 'UEFI Shell' option to UiApp
+#
+#  Copyright (c) 2020, Arm Ltd. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 1.27
+  BASE_NAME  = ShellBootManagerLib
+  FILE_GUID  = f84d949a-1ffd-447e-903d-5def3c34040b
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = NULL|DXE_DRIVER UEFI_APPLICATION
+  CONSTRUCTOR= ShellBootManagerLibConstructor
+  DESTRUCTOR = ShellBootManagerLibDestructor
+
+[Sources]
+  ShellBootManagerLib.c
+  ShellBootManagerLib.h
+  ShellBmVfr.Vfr
+  ShellBmStrings.uni
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ShellPkg/ShellPkg.dec
+
+[LibraryClasses]
+  DebugLib
+  DevicePathLib
+  DxeServicesLib
+  HiiLib
+  MemoryAllocationLib
+  UefiBootServicesTableLib
+
+[Guids]
+  gEfiIfrFrontPageGuid  ## CONSUMES ## GUID
+  gUefiShellFileGuid## CONSUMES ## GUID
+
+[Protocols]
+  gEfiHiiConfigAccessProtocolGuid   ## PRODUCES
+  gEfiDevicePathProtocolGuid## PRODUCES
diff --git a/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.h 
b/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.h
new file mode 100644
index ..e9cdfb6a8a64
--- /dev/null
+++ b/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.h
@@ -0,0 +1,44 @@
+/** @file
+
+  Boot Maintenance Manager Library to add a 'UEFI Shell' option to UiApp
+
+  Copyright (c) 2020, Arm Ltd. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include 
+#include 
+
+extern UINT8 ShellBmVfrBin[];
+
+#define FORMSET_GUID  { 0x54335e64, 0x4ebc, 0x4f7d, { 0x8a, 0x9a, 0x94, 0x10, 
0xf5, 0x53, 0xae, 0x9d } }
+
+///
+/// HII specific Vendor Device Path definition.
+///
+#pragma pack(1)
+typedef struct {
+  VENDOR_DEVICE_PATH VendorDevicePath;
+  EFI_DEVICE_PATH_PROTOCOL   End;
+} HII_VENDOR_DEVICE_PATH;
+#pragma pack()
+
+#define SHELL_BM_CALLBACK_DATA_SIGNATURE  SIGNATURE_32 ('S', 'B', 'C', 'D')
+
+typedef struct {
+  UINTN   Signature;
+
+  //
+  // HII relative handles
+  //
+  EFI_HII_HANDLE  HiiHandle;
+  EFI_HANDLE  DriverHandle;
+
+  //
+  // Produced protocols
+  //
+  EFI_HII_CONFIG_ACCESS_PROTOCOL   ConfigAccess;
+} SHELL_BM_CALLBACK_DATA;
diff --git a/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.c 
b/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.c
new file mode 100644
index ..195f50601dc0
--- /dev/null
+++ b/ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.c
@@ -0,0 +1,258 @@
+/** @file
+
+  Boot Maintenance Manager Library to add a 'UEFI Shell' option to UiApp
+
+  Copyright (c) 2020, Arm Ltd. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ShellBootManagerLib.h"
+
+STATIC CONST EFI_GUID mFormsetGuid = FORMSET_GUID;
+STATIC EFI_DEVICE_PATH_PROTOCOL   *mShellFileDevicePath;
+
+STATIC HII_VENDOR_DEVICE_PATH mShellBmHiiVendorDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+//
+// File GUID: f84d949a-1ffd-447e-903d-5def3c34040b
+//
+{ 0xf84d949a, 0x1ffd, 0x447e, { 0x90, 0x3d, 0x5d, 0xef, 0x3c, 0x34, 0x04, 
0x0b } }
+  },

[edk2-devel] [PATCH 4/5] ArmPkg/PlatformBootManagerLib: don't connect all devices on each boot

[Ard Biesheuvel]

In order to avoid boot delays from devices such as network controllers
that may not even be involved in booting at all, drop the call to
EfiBootManagerConnectAll () from the boot path. It will be called by
UiApp, so when going through the menu, all devices will be connected
as usual, but for the default boot, it is really not necessary so
let's get rid of this.

Enumerating all possible boot options and creating Boot variables
for them is equally unnecessary in the default case, and also happens
automatically in UiApp, so drop that as well.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index b465f9ff388f..618072405a50 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -753,11 +753,6 @@ PlatformBootManagerAfterConsole (
 }
   }
 
-  //
-  // Connect the rest of the devices.
-  //
-  EfiBootManagerConnectAll ();
-
   //
   // On ARM, there is currently no reason to use the phased capsule
   // update approach where some capsules are dispatched before EndOfDxe
@@ -767,11 +762,6 @@ PlatformBootManagerAfterConsole (
   //
   HandleCapsules ();
 
-  //
-  // Enumerate all possible boot options.
-  //
-  EfiBootManagerRefreshAllBootOption ();
-
   //
   // Register UEFI Shell
   //
-- 
2.17.1


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

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

[edk2-devel] [PATCH 0/5] ArmPkg/PlatformBootManagerLib: play nice without ConnectAll()

[Ard Biesheuvel]

Currently, Armpkg's PlatformBootManagerLib connects all controller to
their drivers recursively, even if the active boot option does not
require it. There are some historical reasons for this, some of which are
being addressed in separate patches.

This series addresses the way ArmPkg's PlatformBootManagerLib implementation
deals with the UEFI Shell and the UiApp: currently, the shell is always
added as an ordinary boot option, which will be started if no other boot
options can be started, or if it is the first one in the boot order.

Once we remove the ConnectAll() call from PlatformBootManagerLib, those shells
will be launched without any block or other devices connected, which may
confuse novice users. So before doing so, let's make the handling a bit more
sane:
- add a 's' hotkey that enters the UEFI shell regardless of its priority
  in the BootOrder - this shell will be entered with no devices connected
  after patch #4
- enter the UiApp as a last resort if no boot options can be started
- make the UEFI Shell boot option hidden, so it is not started by default
  (only by hotkey or BootNext)
- remove the ConnectAll() call from PlatformBootManagerLib
- finally, add a plugin library for UiApp to expose the UEFI Shell via an
  ordinary main menu option (this works around the fact that patch #3 will
  result in the UEFI Shell disappearing from the Boot Manager list).
  Entering the shell this way will resemble the old situation, given that
  UiApp connects all devices and refreshes all boot options etc at launch.

Cc: Laszlo Ersek 
Cc: Leif Lindholm 
Cc: Ray Ni 
Cc: Zhichao Gao 

Ard Biesheuvel (5):
  ArmPkg/PlatformBootManagerLib: register 's' as UEFI Shell hotkey
  ArmPkg/PlatformBootManagerLib: fall back to the UiApp on boot failure
  ArmPkg/PlatformBootManagerLib: hide UEFI Shell as a regular boot
option
  ArmPkg/PlatformBootManagerLib: don't connect all devices on each boot
  ShellPkg: add BootManager library to add UEFI Shell menu option

 .../ShellBootManagerLib.inf   |  45 +++
 .../ShellBootManagerLib/ShellBootManagerLib.h |  44 +++
 .../PlatformBootManagerLib/PlatformBm.c   |  37 ++-
 .../ShellBootManagerLib/ShellBootManagerLib.c | 258 ++
 .../ShellBootManagerLib/ShellBmStrings.uni|  17 ++
 .../ShellBootManagerLib/ShellBmVfr.Vfr|  37 +++
 6 files changed, 425 insertions(+), 13 deletions(-)
 create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.inf
 create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.h
 create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBootManagerLib.c
 create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBmStrings.uni
 create mode 100644 ShellPkg/Library/ShellBootManagerLib/ShellBmVfr.Vfr

-- 
2.17.1


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

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

[edk2-devel] [PATCH 3/5] ArmPkg/PlatformBootManagerLib: hide UEFI Shell as a regular boot option

[Ard Biesheuvel]

Without ConnectAll() being called on the boot path, the UEFI shell will
be entered with no block devices or anything else connected, and so for
the novice user, this is not a very accommodating environment. Now that
we have made the UiApp the last resort when on boot failure, and made
the UEFI Shell accessible directly via the 's hotkey if you really need
it, let's hide it as an ordinary boot option.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index f91f7cd09ca1..b465f9ff388f 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -778,7 +778,7 @@ PlatformBootManagerAfterConsole (
   Key.ScanCode = SCAN_NULL;
   Key.UnicodeChar  = L's';
   PlatformRegisterFvBootOption (
-, L"UEFI Shell", LOAD_OPTION_ACTIVE, 
+, L"UEFI Shell", LOAD_OPTION_HIDDEN, 
 );
 }
 
-- 
2.17.1


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

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

[edk2-devel] [PATCH 2/5] ArmPkg/PlatformBootManagerLib: fall back to the UiApp on boot failure

[Ard Biesheuvel]

As a last resort, drop into the UiApp application when no active boot
options could be started. Doing so will connect all devices, and so
it will allow the user to enter the Boot Manager submenu and pick a
network or removable disk option. With the right UiApp library added
in, the UiApp also gives access to the UEFI Shell.

Signed-off-by: Ard Biesheuvel 
---
 ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
index 23c925bbdb9c..f91f7cd09ca1 100644
--- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -830,5 +830,19 @@ PlatformBootManagerUnableToBoot (
   VOID
   )
 {
-  return;
+  EFI_STATUS   Status;
+  EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
+
+  //
+  // BootManagerMenu doesn't contain the correct information when return status
+  // is EFI_NOT_FOUND.
+  //
+  Status = EfiBootManagerGetBootManagerMenu ();
+  if (EFI_ERROR (Status)) {
+return;
+  }
+
+  for (;;) {
+EfiBootManagerBoot ();
+  }
 }
-- 
2.17.1


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

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

Re: [edk2-devel] [PATCH v8 29/46] OvmfPkg: Create a GHCB page for use during Sec phase

[Lendacky, Thomas]

On 5/26/20 10:41 AM, Tom Lendacky wrote:

On 5/25/20 10:07 AM, Laszlo Ersek wrote:

On 05/19/20 23:50, Lendacky, Thomas wrote:
BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C39b71c622d2d4bbf9e5b08d800bd69a5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260160817275268sdata=hz43pd7UO60%2FWfNALLyUuUax8KX%2Bpq4SyU9NIN32Pfc%3Dreserved=0 



A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since the GHCB must be marked as an un-encrypted,
or shared, page, an additional pagetable page is required to break down
the 2MB region where the GHCB page lives into 4K pagetable entries.

Create a new entry in the OVMF memory layout for the new page table
page and for the SEC GHCB and per-CPU variable pages. After breaking down
the 2MB page, update the GHCB page table entry to remove the encryption
mask.

The GHCB page will be used by the SEC #VC exception handler. The #VC
exception handler will fill in the necessary fields of the GHCB and exit
to the hypervisor using the VMGEXIT instruction. The hypervisor then
accesses the GHCB in order to perform the requested function.

Two new fixed PCDs are needed to support the SEC GHCB page:
   - PcdOvmfSecGhcbBase  UINT64 value that is the base address of the
 GHCB used during the SEC phase.
   - PcdOvmfSecGhcbSize  UINT64 value that is the size, in bytes, of the
 GHCB area used during the SEC phase.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/OvmfPkg.dec   |  9 +++
  OvmfPkg/OvmfPkgX64.fdf    |  6 ++
  OvmfPkg/ResetVector/ResetVector.inf   |  5 ++
  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 70 +++
  OvmfPkg/ResetVector/ResetVector.nasmb | 17 ++
  5 files changed, 107 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 65bb2bb0eb4c..02ad62ed9f43 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -281,6 +281,15 @@ [PcdsFixedAtBuild]
    ## Number of page frames to use for storing grant table entries.
    gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
+  ## Specify the extra page table needed to mark the GHCB as unencrypted.
+  #  The value should be a multiple of 4KB for each.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|0x0|UINT32|0x3a
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize|0x0|UINT32|0x3b
+
+  ## The base address of the SEC GHCB page used by SEV-ES.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0|UINT32|0x3c
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0|UINT32|0x3d
+
  [PcdsDynamic, PcdsDynamicEx]
    gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2

gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10


OK, the token values have been updated, due to:

- commit 7efce2e59c20 ("OvmfPkg/PvScsiDxe: Report the number of targets
and LUNs", 2020-03-30)

- commit c4c15b870239 ("OvmfPkg/PvScsiDxe: Support sending SCSI request
and receive response", 2020-03-30)

- commit 093cceaf79b5 ("OvmfPkg/MptScsiDxe: Report targets and one LUN",
2020-05-05)

(Independently, when I reviewed what would become 505812ae1d2d
("OvmfPkg/MptScsiDxe: Implement the PassThru method", 2020-05-05), I
missed that 0x39 is followed by 0x3A, not 0x40. Oh well.)



diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index bfca1eff9e83..88b1e880e603 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -76,6 +76,12 @@ [FD.MEMFD]
  0x007000|0x001000
  
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize 


+0x008000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize 


+
+0x009000|0x002000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize 


+
  0x01|0x01
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize 

diff --git a/OvmfPkg/ResetVector/ResetVector.inf 
b/OvmfPkg/ResetVector/ResetVector.inf

index b0ddfa5832a2..483fd90fe785 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -26,6 +26,7 @@ [Sources]
  [Packages]
    OvmfPkg/OvmfPkg.dec
    MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
    UefiCpuPkg/UefiCpuPkg.dec
  [BuildOptions]
@@ -33,5 +34,9 @@ [BuildOptions]
 *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
  [Pcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
+  

Re: [edk2-devel] [PATCH v8 29/46] OvmfPkg: Create a GHCB page for use during Sec phase

[Lendacky, Thomas]

On 5/25/20 10:07 AM, Laszlo Ersek wrote:

On 05/19/20 23:50, Lendacky, Thomas wrote:

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C39b71c622d2d4bbf9e5b08d800bd69a5%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260160817275268sdata=hz43pd7UO60%2FWfNALLyUuUax8KX%2Bpq4SyU9NIN32Pfc%3Dreserved=0

A GHCB page is needed during the Sec phase, so this new page must be
created. Since the #VC exception handler routines assume that a per-CPU
variable area is immediately after the GHCB, this per-CPU variable area
must also be created. Since the GHCB must be marked as an un-encrypted,
or shared, page, an additional pagetable page is required to break down
the 2MB region where the GHCB page lives into 4K pagetable entries.

Create a new entry in the OVMF memory layout for the new page table
page and for the SEC GHCB and per-CPU variable pages. After breaking down
the 2MB page, update the GHCB page table entry to remove the encryption
mask.

The GHCB page will be used by the SEC #VC exception handler. The #VC
exception handler will fill in the necessary fields of the GHCB and exit
to the hypervisor using the VMGEXIT instruction. The hypervisor then
accesses the GHCB in order to perform the requested function.

Two new fixed PCDs are needed to support the SEC GHCB page:
   - PcdOvmfSecGhcbBase  UINT64 value that is the base address of the
 GHCB used during the SEC phase.
   - PcdOvmfSecGhcbSize  UINT64 value that is the size, in bytes, of the
 GHCB area used during the SEC phase.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/OvmfPkg.dec   |  9 +++
  OvmfPkg/OvmfPkgX64.fdf|  6 ++
  OvmfPkg/ResetVector/ResetVector.inf   |  5 ++
  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 70 +++
  OvmfPkg/ResetVector/ResetVector.nasmb | 17 ++
  5 files changed, 107 insertions(+)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 65bb2bb0eb4c..02ad62ed9f43 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -281,6 +281,15 @@ [PcdsFixedAtBuild]
## Number of page frames to use for storing grant table entries.
gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
  
+  ## Specify the extra page table needed to mark the GHCB as unencrypted.

+  #  The value should be a multiple of 4KB for each.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|0x0|UINT32|0x3a
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize|0x0|UINT32|0x3b
+
+  ## The base address of the SEC GHCB page used by SEV-ES.
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|0|UINT32|0x3c
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize|0|UINT32|0x3d
+
  [PcdsDynamic, PcdsDynamicEx]
gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10


OK, the token values have been updated, due to:

- commit 7efce2e59c20 ("OvmfPkg/PvScsiDxe: Report the number of targets
and LUNs", 2020-03-30)

- commit c4c15b870239 ("OvmfPkg/PvScsiDxe: Support sending SCSI request
and receive response", 2020-03-30)

- commit 093cceaf79b5 ("OvmfPkg/MptScsiDxe: Report targets and one LUN",
2020-05-05)

(Independently, when I reviewed what would become 505812ae1d2d
("OvmfPkg/MptScsiDxe: Implement the PassThru method", 2020-05-05), I
missed that 0x39 is followed by 0x3A, not 0x40. Oh well.)



diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index bfca1eff9e83..88b1e880e603 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -76,6 +76,12 @@ [FD.MEMFD]
  0x007000|0x001000
  
gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
  
+0x008000|0x001000

+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableSize
+
+0x009000|0x002000
+gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
+
  0x01|0x01
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
  
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/ResetVector.inf

index b0ddfa5832a2..483fd90fe785 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -26,6 +26,7 @@ [Sources]
  [Packages]
OvmfPkg/OvmfPkg.dec
MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
UefiCpuPkg/UefiCpuPkg.dec
  
  [BuildOptions]

@@ -33,5 +34,9 @@ [BuildOptions]
 *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
  
  [Pcd]

+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
+  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
+  

Re: [edk2-devel] [PATCH v8 26/46] OvmfPkg/VmgExitLib: Add support for DR7 Read/Write NAE events

[Lendacky, Thomas]

On 5/25/20 9:47 AM, Laszlo Ersek wrote:

On 05/19/20 23:50, Lendacky, Thomas wrote:

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C8d75a8b2107f4def062c08d800ba8795%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260148432921212sdata=WNj6rvvOB%2FeVbeozpvRTXmrqFZEQuEjzEOGIU9KvJVs%3Dreserved=0

Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
The #VC handler must provide special support to the guest for this. On
a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
to notify the hypervisor of the write. However, the #VC handler must
not actually set the value of the DR7 register. On a DR7 read, the #VC
handler must return the cached value of the DR7 register to the guest.
VMGEXIT is not invoked for a DR7 register read.

To avoid exception recursion, a #VC exception will not try to read and
push the actual debug registers into the EFI_SYSTEM_CONTEXT_X64 struct
and instead push zeroes. The #VC exception handler does not make use of
the debug registers from saved context.


AFAICS the following patches introcuce / reiterate the per-CPU page concept:

- "MdeModulePkg/DxeIplPeim: Support GHCB pages when creating page
tables" (v8 05/46)
- "OvmfPkg: Create a GHCB page for use during Sec phase" (v8 29/46)
- "OvmfPkg: Create GHCB pages for use during Pei and Dxe phase" (v8 31/46)

I find it somewhat difficult to locate those patches and to learn about
the per-cpu pages from them. The first patch listed above belongs to a
different package. And the two other patches listed above do not precede
(but follow) the present patch.

(1) Therefore please include a paragraph about the per-cpu pages in the
commit message of this patch.


Will do.





Cc: Eric Dong 
Cc: Ray Ni 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Signed-off-by: Tom Lendacky 
---
  .../Library/VmgExitLib/X64/VmgExitVcHandler.c | 105 ++
  .../X64/ExceptionHandlerAsm.nasm  |  17 +++
  .../X64/Xcode5ExceptionHandlerAsm.nasm|  17 +++
  3 files changed, 139 insertions(+)


Please pass "--stat=1000 --stat-graph-width=20" to git-format-patch;
that way, the pathnames will not be truncated, and the graph to the
right will still not be wider than 20 chars.

Why I'm requesting this (and unfortunately there is no way to make the
second switch above permanent, in the git config): because I almost
missed that this patch modifies both UefiCpuPkg and OvmfPkg. It would
have been obvious from the diffstat (if the pathnames had not been
truncated).

(2) Please split the UefiCpuPkg hunks to a separate patch, if possible.

(Or maybe consider squashing those hunks into patch
"UefiCpuPkg/CpuExceptionHandler: Add base support for the #VC exception"
(v8 11/46), if the UefiCpuPkg owners prefer that.)


It would probably fit nicely into the existing patch. I'll look and either 
move it to there or create a new patch.






diff --git a/OvmfPkg/Library/VmgExitLib/X64/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/X64/VmgExitVcHandler.c
index b028b20f255a..e4072d79d704 100644
--- a/OvmfPkg/Library/VmgExitLib/X64/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/X64/VmgExitVcHandler.c
@@ -14,6 +14,16 @@
  
  #define CR4_OSXSAVE (1 << 18)
  
+#define DR7_RESET_VALUE 0x400


(3) From the Intel SDM, this looks like a standard value. I'd say if we
deem it important enough for turning into a macro, then it belongs
elsewhere (in some more visible header file).

Otherwise (given that we only use it once, below), I think we could
simply open-code it at the location of use, with a comment.


I'll do the latter.




+
+//
+// Per-CPU data mapping structure
+//
+typedef struct {
+  BOOLEAN  Dr7Cached;
+  UINT64   Dr7;
+} SEV_ES_PER_CPU_DATA;
+
  //
  // Instruction execution mode definition
  //
@@ -1494,6 +1504,93 @@ RdtscExit (
return 0;
  }
  
+/**

+  Handle a DR7 register write event.
+
+  Use the VMGEXIT instruction to handle a DR7 write event.
+
+  @param[in, out] Ghcb Pointer to the Guest-Hypervisor 
Communication
+   Block
+  @param[in, out] Regs x64 processor context
+  @param[in]  InstructionData  Instruction parsing context
+
+  @retval 0Event handled successfully
+  @retval Others   New exception value to propagate
+
+**/
+STATIC
+UINT64
+Dr7WriteExit (
+  IN OUT GHCB *Ghcb,
+  IN OUT EFI_SYSTEM_CONTEXT_X64   *Regs,
+  IN SEV_ES_INSTRUCTION_DATA  *InstructionData
+  )
+{
+  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext;
+  SEV_ES_PER_CPU_DATA*SevEsData;
+  INTN   *Register;


(4) This should be UINT64, per my earlier request.


+  UINT64 Status;
+
+  Ext = >Ext;
+  SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb + 1);
+
+  DecodeModRm (Regs, InstructionData);
+
+  /* MOV DRn always treats MOD == 3 no matter 

Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

[Samer El-Haj-Mahmoud]

I agree with Andrew. I also found Laszlo's "unkempt guide" very useful. In 
addition, there is a short page by Peter Batard that adds more details on the 
commits validation, patchset generation, and e-mail submission: 
https://gist.github.com/pbatard/ec1c9d1dd6e7144b07a09b057b1735a8


> -Original Message-
> From: r...@edk2.groups.io  On Behalf Of Laszlo Ersek
> via groups.io
> Sent: Tuesday, May 26, 2020 7:18 AM
> To: Andrew Fish 
> Cc: Bret Barkelew ; devel@edk2.groups.io;
> spbro...@outlook.com; r...@edk2.groups.io; Desimone, Nathaniel L
> ; Mike Kinney
> ; Leif Lindholm (Nuvia address)
> 
> Subject: Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based
> Code Review Process
>
> On 05/25/20 20:28, Andrew Fish wrote:
> >
> >
> >> On May 25, 2020, at 11:10 AM, Laszlo Ersek  wrote:
> >>
> >> Hi Andrew,
> >>
> >> On 05/25/20 06:09, Andrew Fish wrote:
> >>
> >>> I also found I had to Bing/Google to find the detailed instructions
> >>> I needed as a developer, as the Wiki seems to assume you just know
> >>> the Linux kernel patch process. That feels like an area we can improve.
> >>
> >> (apologies if I've lost context; please disregard my message below in
> >> that case).
> >>
> >> I wrote the following wiki article originally in 2016:
> >>
> >> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkemp
> >> t-git-guide-for-edk2-contributors-and-maintainers
> >>
> >> I wrote it specifically for developers & maintainers with no (or
> >> almost
> >> no) prior git / mailing list experience. Multiple developers
> >> confirmed later that the article had helped them.
> >>
> >
> > Laszlo,
> >
> > Your wiki article was very very helpful. I just could not find it from the
> Tianocre wiki. It would be good if we could link to it from here [1], maybe as
> add to this: "Are you new to using git? If so, then the New to git page may be
> helpful."?
>
> The article at [1] is an official document, while the "unkempt guide" is not
> official. The unkempt guide starts by deferring to [1]. I didn't think the 
> official
> document should point to my unofficial one, and/or we should create a loop
> of links.
>
> That said, if someone else updates [1] with a pointer, I won't protest.
> That's just something that I (having authored the unkempt guide) would not
> propose myself.
>
> I do agree that the wiki search facilities on github are basic. What has 
> mostly
> worked for me is clicking the Pages arrow, and then entering a *very simple*
> search term in the drop-down search box. For example, if I do that now, and
> only enter "git", then the "unkempt guide" is listed (with other hits of
> course). I think this search box is basically for searching article titles.
>
> >
> > There are a lot folks who use git but don't use the email based review so
> they have never setup git with emali before. Your wiki, plus me figuring out
> the magic internal SMTP reflector (I reached out on an internal git malling 
> list)
> is what got me unblocked.
>
> It's great that you have access to such infrastructure at Apple!
>
> Thanks!
> Laszlo
>
>
> >
> > [1]
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developme
> > nt-Process
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >> Thanks
> >> Laszlo
> >>
> >
>
>
> 

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 (#60281): https://edk2.groups.io/g/devel/message/60281
Mute This Topic: https://groups.io/mt/74450665/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] MdePkg/Include: AARCH64: disable outline atomics on GCC 10.2+

[Leif Lindholm]

On Sat, May 23, 2020 at 00:09:52 +0200, Ard Biesheuvel wrote:
> > > > diff --git a/MdePkg/Include/AArch64/ProcessorBind.h 
> > > > b/MdePkg/Include/AArch64/ProcessorBind.h
> > > > index 896bf273ac7a..a3ca8f09e51c 100644
> > > > --- a/MdePkg/Include/AArch64/ProcessorBind.h
> > > > +++ b/MdePkg/Include/AArch64/ProcessorBind.h
> > > > @@ -24,6 +24,17 @@
> > > >   #pragma pack()
> > > >   #endif
> > > > +#if defined(__GNUC__) && !defined(__clang__)
> > > > +
> > > > +//
> > > > +// Disable GCC outline atomics
> > > > +// Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2723
> > > > +//
> > > > +#if __GNUC__ > 10 || (__GNUC__ == 10 && __GNUC_MINOR__ >= 2)
> > > > +#pragma GCC target "no-outline-atomics"
> > > > +#endif
> > > > +#endif
> > > > +
> > > >   #if defined(_MSC_EXTENSIONS)
> > > >   //
> > > 
> > > Reviewed-by: Laszlo Ersek 
> > > 
> > > But I think it should be merged later, after GCC 10.2 is out.
> > > 
> > > (Obviously I don't "insist" that we follow this approach, I'm just OK
> > > with it.)
> > 
> > Oh and I think both this patch and the assembly language implementation
> > for the atomics should be delayed after the stable tag. gcc-10 is a new
> > toolchain; so even if we don't introduce a new toolchain tag such as
> > GCC10 for it, whatever we do in order to make it work, that's feature
> > enablement in my book.
> 
> Works for me. By the time the next stable tag comes around, early adopters
> that are now on GCC 10.1 will likely have moved to 10.2 by that time, and so
> we may not need the assembly patch at all.

I'm not ecstatic that we'll be releasing the first stable tag known to
break with current toolchains.

This isn't just affecting random crazies pulling latest toolchains
down, but people using their distro defaults (native or cross).
I don't recall if 10.1 ended up being default in F32, but it was
definitely included. In Arch, it does appear default.

Debian/Ubuntu are unaffected in their stable releases.

I agree it's a transitional issue, but I would really prefer to have
the intrinsics included in the release.

/
Leif

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

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

Re: [edk2-devel] [PATCH v8 34/46] OvmfPkg: Reserve a page in memory for the SEV-ES usage

[Lendacky, Thomas]

On 5/25/20 11:00 AM, Laszlo Ersek wrote:

On 05/19/20 23:51, Lendacky, Thomas wrote:

BZ: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D2198data=02%7C01%7Cthomas.lendacky%40amd.com%7C498df3e8d335449e596508d800c4c955%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260192476035384sdata=UKux5gXwpNe59RKQHTyk577b%2B%2FBmTIdblij8JWhXBG4%3Dreserved=0

Reserve a fixed area of memory for SEV-ES use and set a fixed PCD,
PcdSevEsWorkAreaBase, to this value.

This area will be used by SEV-ES support for two purposes:
   1. Communicating the SEV-ES status during BSP boot to SEC:
  Using a byte of memory from the page, the BSP reset vector code can
  communicate the SEV-ES status to SEC for use before exception
  handling can be enabled in SEC. After SEC, this field is no longer
  valid and the standard way of determine if SEV-ES is active should
  be used.

   2. Establishing an area of memory for AP boot support:
  A hypervisor is not allowed to update an SEV-ES guest's register
  state, so when booting an SEV-ES guest AP, the hypervisor is not
  allowed to set the RIP to the guest requested value. Instead an
  SEV-ES AP must be re-directed from within the guest to the actual
  requested staring location as specified in the INIT-SIPI-SIPI
  sequence.

  Use this memory for reset vector code that can be programmed to have
  the AP jump to the desired RIP location after starting the AP. This
  is required for only the very first AP reset.

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/OvmfPkgX64.fdf|  3 +++
  OvmfPkg/ResetVector/ResetVector.inf   |  1 +
  OvmfPkg/ResetVector/Ia32/PageTables64.asm | 11 +++
  OvmfPkg/ResetVector/ResetVector.nasmb |  1 +
  4 files changed, 16 insertions(+)

diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 88b1e880e603..8836b30a0cef 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -82,6 +82,9 @@ [FD.MEMFD]
  0x009000|0x002000
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
  
+0x00B000|0x001000

+gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase|gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
+
  0x01|0x01
  
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
  
diff --git a/OvmfPkg/ResetVector/ResetVector.inf b/OvmfPkg/ResetVector/ResetVector.inf

index 483fd90fe785..e94e1bfcce7e 100644
--- a/OvmfPkg/ResetVector/ResetVector.inf
+++ b/OvmfPkg/ResetVector/ResetVector.inf
@@ -34,6 +34,7 @@ [BuildOptions]
 *_*_X64_NASMB_FLAGS = -I$(WORKSPACE)/UefiCpuPkg/ResetVector/Vtf0/
  
  [Pcd]

+  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbBase
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbSize
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecGhcbPageTableBase
diff --git a/OvmfPkg/ResetVector/Ia32/PageTables64.asm 
b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
index c3587a1b7814..73a4eaadb1b6 100644
--- a/OvmfPkg/ResetVector/Ia32/PageTables64.asm
+++ b/OvmfPkg/ResetVector/Ia32/PageTables64.asm
@@ -89,6 +89,10 @@ SevExit:
  ; If SEV-ES is disabled then EAX will be zero.
  ;
  CheckSevEsFeature:
+; Initialize the first byte of the workarea to zero to communicate to
+; the SEC phase that SEV-ES is not enabled.
+mov byte[SEV_ES_WORK_AREA], 0
+
  xor   eax, eax
  
  ; SEV-ES can't be enabled if SEV isn't, so first check the encryption

@@ -108,6 +112,13 @@ CheckSevEsFeature:
  ; Restore encryption mask
  mov   edx, ebx
  
+test  eax, eax

+jzNoSevEs
+
+; Set the first byte of the workarea to one to communicate to the SEC
+; phase that SEV-ES is enabled.
+mov   byte[SEV_ES_WORK_AREA], 1
+
  NoSevEs:
  OneTimeCallRet CheckSevEsFeature
  
diff --git a/OvmfPkg/ResetVector/ResetVector.nasmb b/OvmfPkg/ResetVector/ResetVector.nasmb

index bfb77e439105..2967617bfaa0 100644
--- a/OvmfPkg/ResetVector/ResetVector.nasmb
+++ b/OvmfPkg/ResetVector/ResetVector.nasmb
@@ -72,6 +72,7 @@
%define GHCB_PT_ADDR (FixedPcdGet32 (PcdOvmfSecGhcbPageTableBase))
%define GHCB_BASE (FixedPcdGet32 (PcdOvmfSecGhcbBase))
%define GHCB_SIZE (FixedPcdGet32 (PcdOvmfSecGhcbSize))
+  %define SEV_ES_WORK_AREA (FixedPcdGet32 (PcdSevEsWorkAreaBase))
  %include "Ia32/PageTables64.asm"
  %endif
  



The OvmfPkg/ResetVector modifications have been moved to this patch, at
least in part, from patch "OvmfPkg/ResetVector: Add support for a 32-bit
SEV check".

And I don't understand why.


I was trying to keep everything logically grouped. The early use of this 
area is to communicate the SEV-ES status to SEC and so logically I thought 
that should be done when the area was introduced.




I mean it's possible that setting the first byte of the work 

Re: [edk2-devel] BuildTools Broken

[Laszlo Ersek]

On 05/26/20 15:05, Gao, Liming wrote:
> To update Conf, you can type edksetup.bat Reconfig command, and then try 
> build again.

Ah indeed, thank you for the reminder!

Laszlo

>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
>> Sent: Tuesday, May 26, 2020 8:43 PM
>> To: devel@edk2.groups.io; df7...@gmail.com
>> Subject: Re: [edk2-devel] BuildTools Broken
>>
>> On 05/25/20 18:55, David F. wrote:
>>> Last night through the forums I sent a problem with NMAKE U1073 trying
>>> to build. Some things built fine, but not others.   I think my
>>> original message with all the details is still awaiting moderation.
>>> To follow up on that.  I simply renamed BaseTools and restored the
>>> other one I had before updating back (which was older one where
>>> build.exe is Nov 29 2018), but now it starts building fine.   Only
>>> breaks on some new items like longjump.nasm can't find nasm.inc which
>>> didn't exist back in the version I had.
>>
>> Your "Conf" directory was likely out-of-date, please delete it and let
>> edksetup.sh re-populate it from under BaseTools/Conf.
>>
>> An earlier report about the (apparently) same "Nasm.inc" symptom:
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=2719
>>
>> Thanks
>> Laszlo
>>
>>> So I'll have to figure that
>>> out, but I guess I'll used the old BaseTools since the new one doesn't
>>> work either because I need to do something or it needs to be fixed.
>>> Building on Win10 but all that is in the other message.  Using email
>>> now to see if it goes through faster.
>>>
>>>
>>>
>>
>>
>> 
> 


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

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

Re: [edk2-devel] [PATCH v8 46/46] Maintainers.txt: Add reviewers for the OvmfPkg SEV-related files

[Laszlo Ersek]

On 05/20/20 18:56, Lendacky, Thomas wrote:
> Register reviewers for the SEV-related files in OvmfPkg.
> 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Brijesh Singh 
> Signed-off-by: Tom Lendacky 
> ---
>  Maintainers.txt | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 896ac5821fc6..76f336b7dcc4 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -441,6 +441,16 @@ F: OvmfPkg/PvScsiDxe/
>  R: Liran Alon 
>  R: Nikita Leshenko 
>  
> +OvmfPkg: SEV-related modules
> +F: OvmfPkg/AmdSevDxe/
> +F: OvmfPkg/Include/Library/MemEncryptSevLib.h
> +F: OvmfPkg/IoMmuDxe/AmdSevIoMmu.*
> +F: OvmfPkg/Library/BaseMemEncryptSevLib/
> +F: OvmfPkg/Library/VmgExitLib

(1) Please append a slash character here -- it has a particular meaning:

  F: Files and directories with wildcard patterns.
 A trailing slash includes all files and subdirectory files.

With that:

Reviewed-by: Laszlo Ersek 

... I think I've covered everything I needed to review in this
iteration. I'm happy to continue the discussion of course, just stating
that I've finished looking for v8 patches to review.

Thanks!
Laszlo

> +F: OvmfPkg/PlatformPei/AmdSev.c
> +R: Tom Lendacky 
> +R: Brijesh Singh 
> +
>  PcAtChipsetPkg
>  F: PcAtChipsetPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/PcAtChipsetPkg
> 


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

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

Re: [edk2-devel] [PATCH v8 39/46] OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with SEV-ES

[Laszlo Ersek]

On 05/19/20 23:51, Lendacky, Thomas wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> The flash detection routine will attempt to determine how the flash
> device behaves (e.g. ROM, RAM, Flash). But when SEV-ES is enabled and
> the flash device behaves as a ROM device (meaning it is marked read-only
> by the hypervisor), this check may result in an infinite nested page fault
> because of the attempted write. Since the instruction cannot be emulated
> when SEV-ES is enabled, the RIP is never advanced, resulting in repeated
> nested page faults.
> 
> When SEV-ES is enabled, exit the flash detection early and assume that
> the FD behaves as Flash. This will result in QemuFlashWrite() being called
> to store EFI variables, which will also result in an infinite nested page
> fault when the write is performed. In this case, update QemuFlashWrite()
> to use the VMGEXIT MMIO write support to have the hypervisor perform the
> write without having to emulate the instruction.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  .../FvbServicesRuntimeDxe.inf |  2 +
>  .../QemuFlash.h   | 13 ++
>  .../QemuFlash.c   | 23 +--
>  .../QemuFlashDxe.c| 40 +++
>  .../QemuFlashSmm.c| 16 
>  5 files changed, 91 insertions(+), 3 deletions(-)

- subject line has been cleaned up relative to v6, OK

- commit message updated in sync with open-coding VmgMmioWrite() in this
patch; and VmgMmioWrite() has been documented in the v8 blurb -- OK

> 
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> index 72cabba4357d..8bb2325157ea 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
> @@ -38,6 +38,7 @@ [Sources]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
>OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
> @@ -52,6 +53,7 @@ [LibraryClasses]
>UefiBootServicesTableLib
>UefiDriverEntryPoint
>UefiRuntimeLib
> +  VmgExitLib
>  
>  [Guids]
>gEfiEventVirtualAddressChangeGuid   # ALWAYS_CONSUMED
> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
> index f1afabcbe6ae..219d0d6e83cf 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.h
> @@ -89,5 +89,18 @@ QemuFlashBeforeProbe (
>IN  UINTN   FdBlockCount
>);
>  
> +/**
> +  Write to QEMU Flash
> +
> +  @param[in] PtrPointer to the location to write.
> +  @param[in] Value  The value to write.
> +
> +**/
> +VOID
> +QemuFlashPtrWrite (
> +  INvolatile UINT8*Ptr,
> +  INUINT8 Value
> +  );
> +
>  #endif
>  

- New comment, OK.

> diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c 
> b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
> index 1b0d6c053f1a..0d29bf701aca 100644
> --- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
> +++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c
> @@ -9,6 +9,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "QemuFlash.h"
> @@ -80,6 +81,21 @@ QemuFlashDetected (
>  
>DEBUG ((DEBUG_INFO, "QEMU Flash: Attempting flash detection at %p\n", 
> Ptr));
>  
> +  if (MemEncryptSevEsIsEnabled ()) {
> +//
> +// When SEV-ES is enabled, the check below can result in an infinite
> +// loop with respect to a nested page fault. When the memslot is mapped
> +// read-only, the nested page table entry is read-only. The check below
> +// will cause a nested page fault that cannot be emulated, causing
> +// the instruction to retried over and over. For SEV-ES, acknowledge that
> +// the FD appears as ROM and not as FLASH, but report FLASH anyway 
> because
> +// FLASH behavior can be simulated using VMGEXIT.
> +//
> +DEBUG ((DEBUG_INFO,
> +  "QEMU Flash: SEV-ES enabled, assuming FD behaves as FLASH\n"));
> +return TRUE;
> +  }
> +
>OriginalUint8 = *Ptr;
>*Ptr = CLEAR_STATUS_CMD;
>ProbeUint8 = *Ptr;
> @@ -181,8 +197,9 @@ QemuFlashWrite (
>//
>Ptr = QemuFlashPtr (Lba, Offset);
>for (Loop = 0; Loop < *NumBytes; Loop++) {
> -*Ptr = WRITE_BYTE_CMD;
> -*Ptr = Buffer[Loop];
> +QemuFlashPtrWrite (Ptr, WRITE_BYTE_CMD);
> +QemuFlashPtrWrite (Ptr, Buffer[Loop]);
> +
>  Ptr++;
>}
>  
> @@ -190,7 +207,7 @@ QemuFlashWrite (
>// Restore flash to read mode
>//
>if (*NumBytes > 0) {
> -*(Ptr - 1) = READ_ARRAY_CMD;
> +QemuFlashPtrWrite (Ptr - 1, READ_ARRAY_CMD);
>}
>  
>return EFI_SUCCESS;
> diff --git 

Re: [edk2-devel] Upcoming Event: TianoCore Bug Triage - APAC / NAMO - Tue, 05/26/2020 6:30pm-7:30pm #cal-reminder

[Liming Gao]

The following BZ will be discussed this week Bug Triage meeting.

2725
EDK2
Code
michael.d.kin...@intel.com
UNCO
---
WinHost.exe exits after launching after SEC 
core.
09:39:26
2767
EDK2
Document
michael.d.kin...@intel.com
UNCO
---
PatchCheck.py does not detect you did not configure 
"BaseTools/Scripts/SetupGit.py
00:07:45
2729
EDK2
Code
michael.d.kin...@intel.com
UNCO
---
UnitTest for BaseLib needs better structuring to support all BaseLib 
functions
Fri 04:52
2763
EDK2
Code
michael.d.kin...@intel.com
UNCO
---
Inconsistent Shell File Info state 
assumptions
Fri 04:13
2762
EDK2
Code
michael.d.kin...@intel.com
UNCO
---
Adding Guid name support in GenFfs to prevent hard coding GUID vaule on fdf 
file
Fri 01:39
2753
EDK2
Code
michael.d.kin...@intel.com
UNCO
---
Tcg2Dxe Invoke Exit Boot Services should be hashed into PCR on failure and 
success case
Thu 13:39
2751
EDK2 Pla
Whiskeyl
chasel.c...@intel.com
UNCO
---
WhiskeylakeOpenBoardPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:56
2750
EDK2 Pla
UserInte
rangasai.v.chaga...@intel.com
UNCO
---
UserInterfaceFeaturePkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:55
2749
EDK2 Pla
SimicsX5
prince.agye...@intel.com
UNCO
---
SimicsX58SktPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:53
2748
EDK2 Pla
SimicsOp
prince.agye...@intel.com
UNCO
---
SimicsOpenBoardPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:52
2747
EDK2 Pla
SimicsIc
prince.agye...@intel.com
UNCO
---
SimicsIch10Pkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:51
2745
EDK2 Pla
MinPlatf
nathaniel.l.desim...@intel.com
UNCO
---
MinPlatformPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:50
2743
EDK2 Pla
Minnowbo
zailiang@intel.com
UNCO
---
Minnowboard 3: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:48
2744
EDK2 Pla
Minnowbo
yi.q...@intel.com
UNCO
---
Minnowboard Max: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:48
2742
EDK2 Pla
Kabylake
chasel.c...@intel.com
UNCO
---
KabylakeSiliconPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:44
2741
EDK2 Pla
Kabylake
chasel.c...@intel.com
UNCO
---
KabylakeOpenBoardPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:43
2740
EDK2 Pla
DebugFea
rangasai.v.chaga...@intel.com
UNCO
---
(Acpi|Usb3)DebugFeaturePkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:42
2739
EDK2 Pla
Cometlak
nathaniel.l.desim...@intel.com
UNCO
---
CometlakeOpenBoardPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:40
2738
EDK2 Pla
Coffelak
chasel.c...@intel.com
UNCO
---
CoffeelakeSiliconPkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:38
2737
EDK2 Pla
BoardMod
eric.d...@intel.com
UNCO
---
BoardModulePkg: Add the VariablePolicy engine to your EDK2 
platform
Thu 05:37

Re: [edk2-devel] [PATCH v8 37/46] OvmfPkg/Sec: Add #VC exception handling for Sec phase

[Laszlo Ersek]

On 05/19/20 23:51, Lendacky, Thomas wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> An SEV-ES guest will generate a #VC exception when it encounters a
> non-automatic exit (NAE) event. It is expected that the #VC exception
> handler will communicate with the hypervisor using the GHCB to handle
> the NAE event.
> 
> NAE events can occur during the Sec phase, so initialize exception
> handling early in the OVMF Sec support.
> 
> Before establishing the exception handling, validate that the supported
> version of the SEV-ES protocol in OVMF is supported by the hypervisor.
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/Sec/SecMain.inf |   4 +
>  OvmfPkg/Sec/SecMain.c   | 181 +---
>  2 files changed, 172 insertions(+), 13 deletions(-)

Nice comments relative to v6, my R-b stands.

Thanks,
Laszlo


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

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

Re: [edk2-devel] SbsaQemu: Initial support for static ACPI tables

[Graeme Gregory]

On Mon, May 25, 2020 at 03:44:24AM +0530, Tanmay Jagdale wrote:
> Add the following static ACPI tables for the SBSA Qemu platform
>   - DSDT
>   - FADT
>   - GTDT
>   - MADT

Comment below on MADT

>   - MCFG
>   - SPCR
> 
> Currently we support 4 CPUs.
> 
> Co-authored-by: Graeme Gregory 
> Co-authored-by: Jonathan Cameron 
> Co-authored-by: Tanmay Jagdale 
> Signed-off-by: Tanmay Jagdale 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   11 +-
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   14 +
>  Silicon/Qemu/SbsaQemu/Acpi.dsc.inc|   42 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/AcpiTables.h |   61 +
>  .../Qemu/SbsaQemu/AcpiTables/AcpiTables.inf   |   47 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 1400 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/Fadt.aslc|   85 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc|   71 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/Madt.aslc|   85 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc|   50 +
>  Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc|  122 ++
>  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c |6 +
>  .../SbsaQemuPlatformDxe.inf   |   10 +
>  13 files changed, 2003 insertions(+), 1 deletion(-)
>  create mode 100644 Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/AcpiTables.h
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/AcpiTables.inf
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Fadt.aslc
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Madt.aslc
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Mcfg.aslc
>  create mode 100644 Silicon/Qemu/SbsaQemu/AcpiTables/Spcr.aslc
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 4db3ab4651..ac1398af8f 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -300,6 +300,10 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0
>gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320
>  
> +  # Core and Cluster Count
> +  gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> +  gArmPlatformTokenSpaceGuid.PcdClusterCount|1
> +
># DEBUG_ASSERT_ENABLED   0x01
># DEBUG_PRINT_ENABLED0x02
># DEBUG_CODE_ENABLED 0x04
> @@ -376,7 +380,6 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>#
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|TRUE
>  
> -  gArmPlatformTokenSpaceGuid.PcdCoreCount|1
>gArmTokenSpaceGuid.PcdVFPEnabled|1
>  
># System Memory Base -- fixed
> @@ -516,6 +519,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>ShellPkg/Application/Shell/Shell.inf {
>  
>
> ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
> +  
> NULL|ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf
>
> NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
>
> NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
>
> NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
> @@ -675,3 +679,8 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
> +
> +  #
> +  # ACPI Support
> +!include Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
> +  
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> index be7c78aceb..7f1a60e3ee 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> @@ -227,6 +227,14 @@ READ_LOCK_STATUS   = TRUE
>INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
>INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
>  
> +  #
> +  # ACPI support
> +  #
> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +  INF MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
> +  INF RuleOverride = ACPITABLE 
> Silicon/Qemu/SbsaQemu/AcpiTables/AcpiTables.inf
> +  INF 
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> +
>#
># PCI support
>#
> @@ -301,3 +309,9 @@ READ_LOCK_STATUS   = TRUE
>}
>  
>  !include ArmVirtPkg/ArmVirtRules.fdf.inc
> +
> +[Rule.Common.USER_DEFINED.ACPITABLE]
> +  FILE FREEFORM = $(NAMED_GUID) {
> +RAW ACPI   |.acpi
> +RAW ASL|.aml
> +  }
> diff --git a/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc 
> b/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
> new file mode 100644
> index 00..76d0fac079
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Acpi.dsc.inc
> @@ -0,0 +1,42 @@
> +#

Re: [edk2-devel] BuildTools Broken

[Liming Gao]

To update Conf, you can type edksetup.bat Reconfig command, and then try build 
again.

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Tuesday, May 26, 2020 8:43 PM
> To: devel@edk2.groups.io; df7...@gmail.com
> Subject: Re: [edk2-devel] BuildTools Broken
> 
> On 05/25/20 18:55, David F. wrote:
> > Last night through the forums I sent a problem with NMAKE U1073 trying
> > to build. Some things built fine, but not others.   I think my
> > original message with all the details is still awaiting moderation.
> > To follow up on that.  I simply renamed BaseTools and restored the
> > other one I had before updating back (which was older one where
> > build.exe is Nov 29 2018), but now it starts building fine.   Only
> > breaks on some new items like longjump.nasm can't find nasm.inc which
> > didn't exist back in the version I had.
> 
> Your "Conf" directory was likely out-of-date, please delete it and let
> edksetup.sh re-populate it from under BaseTools/Conf.
> 
> An earlier report about the (apparently) same "Nasm.inc" symptom:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2719
> 
> Thanks
> Laszlo
> 
> > So I'll have to figure that
> > out, but I guess I'll used the old BaseTools since the new one doesn't
> > work either because I need to do something or it needs to be fixed.
> > Building on Win10 but all that is in the other message.  Using email
> > now to see if it goes through faster.
> >
> >
> >
> 
> 
> 


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

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

Re: [edk2-devel] BuildTools Broken

[Laszlo Ersek]

On 05/25/20 18:55, David F. wrote:
> Last night through the forums I sent a problem with NMAKE U1073 trying
> to build. Some things built fine, but not others.   I think my
> original message with all the details is still awaiting moderation.
> To follow up on that.  I simply renamed BaseTools and restored the
> other one I had before updating back (which was older one where
> build.exe is Nov 29 2018), but now it starts building fine.   Only
> breaks on some new items like longjump.nasm can't find nasm.inc which
> didn't exist back in the version I had.

Your "Conf" directory was likely out-of-date, please delete it and let
edksetup.sh re-populate it from under BaseTools/Conf.

An earlier report about the (apparently) same "Nasm.inc" symptom:

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

Thanks
Laszlo

> So I'll have to figure that
> out, but I guess I'll used the old BaseTools since the new one doesn't
> work either because I need to do something or it needs to be fixed.
> Building on Win10 but all that is in the other message.  Using email
> now to see if it goes through faster.
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH 3/3] OvmfwPkg: Don't exclude XCODE Modules

[Laszlo Ersek]

On 05/26/20 06:10, Andrew Fish wrote:
> 
> 
>> On May 25, 2020, at 12:31 PM, Laszlo Ersek  wrote:
>>
>> Hi Andrew,
>>
>> On 05/24/20 23:20, Andrew Fish via groups.io  wrote:
>>> With this BZ getting fixed we no longer need to special case XCODE.
>>>
>>> Cc: Ard Biesheuvel 
>>> Cc: Jiewen Yao 
>>> Cc: Jordan Justen 
>>> Cc: Philippe Mathieu-Daudé 
>>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=557
>>> Signed-off-by: Andrew Fish 
>>>
>>> Signed-off-by: Andrew Fish 
>>> ---
>>> OvmfPkg/OvmfPkgIa32.dsc| 3 +--
>>> OvmfPkg/OvmfPkgIa32.fdf| 2 --
>>> OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++--
>>> OvmfPkg/OvmfPkgIa32X64.fdf | 2 --
>>> OvmfPkg/OvmfPkgX64.dsc | 3 +--
>>> OvmfPkg/OvmfPkgX64.fdf | 2 --
>>> OvmfPkg/OvmfXen.dsc| 3 +--
>>> OvmfPkg/OvmfXen.fdf| 2 --
>>> 8 files changed, 5 insertions(+), 16 deletions(-)
>>
> 
> Laszlo,
> 
> Thanks for the feedback. 
> 
> Can I ask that you go to https://www.tianocore.org, click on How to 
> Contribute and point me at the chain of links I did not follow, if I missed 
> it tit is likely due to too many links and too much information being vended.

You didn't miss anything, starting from that page, I think. I don't
remember ever clicking "How to Contribute" on that page. :)

In fact if I grep the current edk2-wiki project source, at commit
de8fae02bbcc ("Add acknowledgements page", 2020-05-21), I find no
references to "SetupGit.py".

> When people are starting out we should vend them the instructions that work 
> and let them opt in to learning more.

"Working instructions" is a moving target. When I wrote the unkempt
guide, it was serious work, I had to set aside resources. When we
changed the workflow to replace "git-push" (by maintainers) with github
PRs (to trigger CI), documenting that was again serious work (for Mike
-- Mike updated both the official workflow article and the unkempt
guide, as I couldn't volunteer for the latter).

The more documentation we add, the larger the burden to update them
grows. It's an on-going commitment. Given the constant scarcity of
developer (and reviewer) cycles, we can only choose between:

- "code, plus more or less up-to-date docs", and
- "code, plus no docs".

Leif wrote SetupGit.py in the first place to save people the effort of
going through some of the unkempt guide steps.

If we decide that no SetupGit.py (or similar utilities) should be
written without documenting them in the wiki, that won't force
contributors to document their workflow-related contributions; it will
cause them to not writing the utilities in the first place.

Open source development communities teach contributors the workflow by
doing. For example, I have contributed to two open source projects that
are *exclusively* managed on github.com, using "github native" pull
requests and such. (Namely, openssl, and "p11-glue/p11-kit".) I'm the
kind of guy that very carefully reads the documentation first, and
starts pushing the buttons only second, and I *still* got wrong my
initial contributions to both projects.

With OpenSSL, I missed details of how review worked and details about
the CLA. Maintainers taught me those bits on the PR, while they were
reviewing my code.

With p11-kit, I had missed that I was expected to write a unit test at
once, for the new code. Maintainers pointed that out in my PR.

I posit that virtually no up-to-date technical documentation exists
unless an organization treats that documentation as a *product* (with
its own resource allocations, technical writers, subject matter expert
reviewers, project managers, and so on).

> 
>> (1) Please run "BaseTools/Scripts/SetupGit.py" in your edk2 clone,
>> because right now, the patch is formatted/posted with too many CR
>> characters.
>>
> 
> I filed https://bugzilla.tianocore.org/show_bug.cgi?id=2767 since I passed 
> PatchCheck.py but did not run  BaseTools/Scripts/SetupGit.py

Thanks.

For the record: I didn't reject your contribution (I'm very happy you
posted a patch series); instead, I asked for an update.

In particular, the number of empty lines inserted into the DSC files is
not consistent across the OVMF DSC files, and that fact has nothing to
do with git configuration -- it would need fixing identically even if
the series had been submitted via a github.com PR.

Thanks
Laszlo


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

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

Re: [edk2-devel] OVMF gdb seems to require "stone knives and bearskins" to debug code?

[Laszlo Ersek]

On 05/26/20 01:14, Andrew Fish wrote:
> 
> 
>> On May 25, 2020, at 12:15 PM, Laszlo Ersek  wrote:
>>
>> (+Rebecca, +Andrei)
>>
>> On 05/25/20 05:30, Andrew Fish via groups.io wrote:
>>> The full Star Trek quote from Spock is:  " I am endeavoring, ma'am, to 
>>> construct a mnemonic memory circuit using stone knives and bearskins.", but 
>>> I ran across this [1], and it felt like "stone knives and bearskins." vs my 
>>> experience with lldb debugging EFI. 
>>>
>>> So a few questions:
>>> 1) Is this Wiki [1]  actually up to date? 
>>> 2) Do we have a location to add debugger scripts to the edk2? If not what 
>>> location should we chose?
>>> 3) Is anyone interested in writing gdb scripts to do better?
>>
>> Andrei used to have some utilities / scripts at
>> , and
>> Rebecca used to host an article on her website about those tools. Hm
>> the URL seems to be:
>> .
>>
>> I have those utilities (somewhat refreshed?) in one of my (frequently
>> rebased) local branches, but I've never tried to upstream them (it's not
>> my work, after all). But, I use gdb really rarely anyway; mostly I use
>> DEBUGs. :)
>>
>>
>> I think the last time we discussed this was in this thread:
>>
>> https://edk2.groups.io/g/devel/message/40061
>>
>> (alt link:
>> )
>>
> 
> Laszlo,
> 
> I was thinking more of a workflow that looks like:
> $ gdb -ex " target remote localhost:1234" -ex " source efi_symbolicate.py" 
> 
> And then you are sitting at a symbolicated stack frame when gdb launches.

Yes, that's how I use Andrei's DebugPkg. There are 4 patches related to
that on my local branch:

(1) import Andrei's DebugPkg:

 DebugPkg/DebugPkg.dec|  34 
 DebugPkg/GdbSyms/GdbSyms.inf |  57 ++
 DebugPkg/GdbSyms/GdbSyms.c   |  70 +++
 DebugPkg/Scripts/gdb_uefi.py | 348 +++
 4 files changed, 509 insertions(+)

(2) add "DebugPkg/GdbSyms/GdbSyms.inf" (from the previous patch) to the
OvmfPkg DSC files (but not the FDF files),

(3) "DebugPkg: load unstripped image from *.debug" -- a tweak to
Andrei's DebugPkg code

(4) "DebugPkg: add localized gdb startup scripts for debugging":

 DebugPkg/Scripts/commands-32.gdb   | 7 +++
 DebugPkg/Scripts/commands-3264.gdb | 7 +++
 DebugPkg/Scripts/commands.gdb  | 7 +++

I do invoke these with "gdb -x". Unfortunately, they do contain absolute
pathnames that are specific to my home directory.

> This is what I have working with lldb and OVMF. I'll see if I can abstract 
> out the debugger from my script and make it easy to port to gdb.
> 
> This would imply we need a location to store the debugger script, and maybe a 
> script to launch the debugger if the command line gets long, but we could 
> land that convenience script in OvmfPkg/.

Sure, I think it's OK to check those in under OvmfPkg.

> I see Andrei's warning about needing to load a module to get gdb to behave. 
> We might be able to load the DXE Core or some other module at its linked 
> address (around zero) and then unloaded when we detect its actual load 
> address. I've got something like this working in lldb. 

Thanks
Laszlo


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

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

Re: [EXTERNAL] [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

[Laszlo Ersek]

On 05/25/20 20:28, Andrew Fish wrote:
> 
> 
>> On May 25, 2020, at 11:10 AM, Laszlo Ersek  wrote:
>>
>> Hi Andrew,
>>
>> On 05/25/20 06:09, Andrew Fish wrote:
>>
>>> I also found I had to Bing/Google to find the detailed instructions I
>>> needed as a developer, as the Wiki seems to assume you just know the
>>> Linux kernel patch process. That feels like an area we can improve.
>>
>> (apologies if I've lost context; please disregard my message below in
>> that case).
>>
>> I wrote the following wiki article originally in 2016:
>>
>> https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers
>>
>> I wrote it specifically for developers & maintainers with no (or almost
>> no) prior git / mailing list experience. Multiple developers confirmed
>> later that the article had helped them.
>>
> 
> Laszlo,
> 
> Your wiki article was very very helpful. I just could not find it from the 
> Tianocre wiki. It would be good if we could link to it from here [1], maybe 
> as add to this: "Are you new to using git? If so, then the New to git page 
> may be helpful."?

The article at [1] is an official document, while the "unkempt guide" is
not official. The unkempt guide starts by deferring to [1]. I didn't
think the official document should point to my unofficial one, and/or we
should create a loop of links.

That said, if someone else updates [1] with a pointer, I won't protest.
That's just something that I (having authored the unkempt guide) would
not propose myself.

I do agree that the wiki search facilities on github are basic. What has
mostly worked for me is clicking the Pages arrow, and then entering a
*very simple* search term in the drop-down search box. For example, if I
do that now, and only enter "git", then the "unkempt guide" is listed
(with other hits of course). I think this search box is basically for
searching article titles.

> 
> There are a lot folks who use git but don't use the email based review so 
> they have never setup git with emali before. Your wiki, plus me figuring out 
> the magic internal SMTP reflector (I reached out on an internal git malling 
> list) is what got me unblocked.

It's great that you have access to such infrastructure at Apple!

Thanks!
Laszlo


> 
> [1] 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process
> 
> Thanks,
> 
> Andrew Fish
> 
>> Thanks
>> Laszlo
>>
> 


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

View/Reply Online (#60268): https://edk2.groups.io/g/devel/message/60268
Mute This Topic: https://groups.io/mt/74450665/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 1/1] NetworkPkg/HttpBootDxe: handle servers which may FIN after file sizing in HttpBootLoadFile

[Maciej Rabeda]

I wanted to know whether the manual change to Python's http.server I 
have proposed worked for you. Did it?


Patch you have proposed, while being functional, is still a work-around. 
HttpBootDxe supports HTTP/1.1 with an assumption of TCP connections 
being persistent. Python HTTP server implementation does not support 
HTTP/1.1 by default but does contain support for it. Plus, changing it 
to operate on HTTP/1.1 is trivial and from what code suggests - it 
should work just fine.


If we were to discuss how to tackle the issue on HTTP client side, we 
have two potential options:
1. Detect HTTP version in HTTP response from server and add alternate 
path to the whole HTTP I/O if the version reported by the server is 
lower than 1.1. Large change to HttpBootDxe.


2. Add 'keep-alive' header to HTTP requests. I see two problems here:
a. Python server support does seem to contain proper support for that 
header when self.protocol_version == "HTTP/1.0". That will not solve the 
problem in your use case.
b. I have no idea whether other HTTP server implementations will reject 
the request altogether based on that 'keep-alive' header (HTTP/2.x case).


I will not opt for any of them. Adding support for pre-1997 features is 
something I would like to avoid.


Nevertheless, subject of informing the user about lack of support for 
HTTP/1.1 on server-side still stands. We should definitely handle and 
report EFI_CONNECTION_FIN (server terminated the connection). 
Additionally, HTTP client should terminate the connection when it 
detects that the server is responding to it with HTTP version lower than 
1.1 (no TCP connection persistence).


Summary & my suggestions:
1. I would like to drop the patch and close this issue as a problem on 
server-side (lack of support for HTTP/1.1, which is supported by 
HttpBootDxe).


2. I would like to open a new Bugzilla to directly state that 
HttpBootDxe does not correctly report lack of support for at least 
HTTP/1.1 on server-side and also does not report termination of the TCP 
connection.
Based on this Bugzilla, we could properly submit reporting of lack of 
support for servers not supporting at least HTTP/1.1.


Looking forward to your response.

On 26-May-20 08:13, Andrei Warkentin wrote:

Hi Maciej,

Thanks for your analysis.

The way I see it, there are many people out there expecting HttpBoot 
to work with the Python server - which without manual hacking is 
HTTP/1.0 and not HTTP/1.1. I think it's fine to reject 1.0 but then 
HttpBoot should explicitly reject 1.0 with an appropriate message and 
*refuse* to boot. Today it's in the area where it may work and may not.


1.1 vs 1.0 aside, don't you think there should be a bit of resiliency 
to the client? As it stands right now, an arbitrary FIN  between the 
requests gets the user an "unexpected network error" (or similar), 
with no clear indication it's a server misconfiguration, a network 
error (which one?) or some such. With that in mind I see the proposed 
fix as being a lesser evil (friendly to end user) than creating a 
pedantic HttpBoot client which will fail because it doesn't operate in 
an ideal environment.


What do you think?

A

*From:* devel@edk2.groups.io  on behalf of 
Maciej Rabeda via groups.io 

*Sent:* Monday, May 25, 2020 7:49 AM
*To:* devel@edk2.groups.io ; 
andrey.warken...@gmail.com 
*Cc:* jiaxin...@intel.com ; siyuan...@intel.com 

*Subject:* Re: [edk2-devel] [edk2][PATCH 1/1] NetworkPkg/HttpBootDxe: 
handle servers which may FIN after file sizing in HttpBootLoadFile

Copying my comments from Bugzilla:
I have gone through the Wireshark trace that you have provided. It 
seems to be all clear now and the approach to the issue must change. 
HttpBootDxe supports HTTP 1.1 and assumes that the HTTP session stays 
persistent (single TCP connection for multiple requests instead of one 
for each HTTP request/response pair). 
https://en.wikipedia.org/wiki/HTTP_persistent_connection 
 
I am hesitant to introduce HTTP/1.0 keep-alive additions to the 
header. Kindly request more debugging on Python server side whether to 
confirm that implementation you are using supports HTTP/1.1. From what 
I see in here: 
https://github.com/python/cpython/blob/master/Lib/http/server.py 
 
http.server has support for HTTP/1.1 and 

Re: [edk2-devel] Updating to latest EDK2 and now get NMAKE: fatal error U1073: Don't know how to make.. on some items?

[Tomas Pilar (tpilar)]

Based on the output, am I correct in assuming that the generated 
ABCPPSupportLib makefile does not have a rule for making ABCPPSupportLib.obj?

Tom

From: devel@edk2.groups.io  On Behalf Of David F. via 
groups.io
Sent: 25 May 2020 08:56
To: devel@edk2.groups.io
Subject: [edk2-devel] Updating to latest EDK2 and now get NMAKE: fatal error 
U1073: Don't know how to make.. on some items?

Hi,

I haven't updated the edk2 in quite a while, I went ahead and did it tonight, 
stdlib was removed so I had to move stuff around.  Where I used to have 
C:\EDK2, I now have C:\EDK\EDK2 and C:\EDK\EDK2-CLIB.   My private directory is 
still under C:\EDK\EDK2\Acme.   After figuring out how to get stdlib on its own 
repository by using the new directory, I then had to setup a batch file to do 
my edksetup in a different way.  Now has:
set WORKSPACE=%CD%
set PACKAGES_PATH=%WORKSPACE%\edk2-libc;%WORKSPACE%\edk2
set EDK_TOOLS_PATH=%WORKSPACE%\edk2\BaseTools
cd %WORKSPACE%\edk2
edksetup.bat

It's all looking pretty good.  I am using VS2008 for my EDK builds, I decided 
to stay with my old build_rule.txt, target.txt and tools_def.txt which has some 
older stuff in it that doesn't apply (I looked at the new stuff, but I have 
some custom switches and it wasn't much different).   So I run my build switch 
to build my UEFI application and it starts and builds some items, but then dies 
with the NMAKE failure and I have no clue why.   Here are some of the details 
after deleting c:\edk\build which is where it wants to go.
Build environment: Windows-10-10.0.18362
Build start time: 00:33:37, May.25 2020
WORKSPACE= c:\edk
PACKAGES_PATH= c:\edk\edk2-libc;c:\edk\edk2
EDK_TOOLS_PATH   = c:\edk\edk2\basetools
EDK_TOOLS_BIN= c:\edk\edk2\basetools\bin\win32
CONF_PATH= c:\edk\edk2\conf
PYTHON_COMMAND   = C:\python27-x64\python.exe
Architecture(s)  = X64
Build target = RELEASE
Toolchain= VS2008x86
Active Platform  = c:\edk\edk2\Acme\Acme.dsc
build: : warning: Module MetaFile [Sources] is missing local header!
Local Header: c:\edk\edk2-libc\stdlib\libc\gdtoa\gdtoaimp.h not found in 
c:\edk\edk2-libc\StdLib\LibC\gdtoa\gdtoa.inf
build: : warning: Module MetaFile [Sources] is missing local header!
Local Header: c:\edk\edk2-libc\stdlib\libc\gdtoa\gdtoa.h not found in 
c:\edk\edk2-libc\StdLib\LibC\gdtoa\gdtoa.inf
build: : warning: Module MetaFile [Sources] is missing local header!
Local Header: c:\edk\edk2-libc\stdlib\libc\time\tzfile.h not found in 
c:\edk\edk2-libc\StdLib\LibC\Time\Time.inf
build: : warning: Module MetaFile [Sources] is missing local header!
   Several more like this from stdlib 
Building ... c:\edk\edk2\Acme\Library\ABLegacySpeakerLib\ABLegacySpeakerLib.inf 
[X64]
Building ... c:\edk\edk2\Acme\Library\ABMemDumpLib\ABMemDumpLib.inf [X64]
Building ... c:\edk\edk2\Acme\Library\ABVSSupportLib\ABVSSupportLib.inf [X64]
"C:\Program Files (x86)\Microsoft Visual Studio 
9.0\Vc\bin\x86_amd64\cl.exe" 
/Foc:\edk\Build\Acme\RELEASE_VS2008x86\X64\Acme\Library\ABLegacySpeakerLib\ABLegacySpeakerLib\OUTPUT\.\
 /nologo /c /WX /GS- /X /W4 /Gs32768 /O1ib2s /GL- /Gy /FIAutoGen.h /EHs-c- /GR- 
/GF /X /Zc:wchar_t- /D UEFI_C_SOURCE /D MDEPKG_NDEBUG /D NDEBUG 
/Ic:\edk\edk2\Acme\Library\ABLegacySpeakerLib  
/Ic:\edk\Build\Acme\RELEASE_VS2008x86\X64\Acme\Library\ABLegacySpeakerLib\ABLegacySpeakerLib\DEBUG
  /Ic:\edk\edk2\MdePkg  /Ic:\edk\edk2\MdePkg\Include  
/Ic:\edk\edk2\MdePkg\Include\X64  /Ic:\edk\edk2\Acme  
/Ic:\edk\edk2\Acme\Include  /Ic:\edk\edk2\Acme\Include\AB\UEFI  
/Ic:\edk\edk2\Acme\Include\AB\fastgui  /Ic:\edk\edk2\Acme\Include\AB  
/Ic:\edk\edk2\Acme\Include\IPP 
c:\edk\edk2\Acme\Library\ABLegacySpeakerLib\ABLegacySpeakerLib.c
Building ... 
c:\edk\edk2\Acme\Library\ABMountedCPPEntryLib\ABMountedCPPEntryLib.inf [X64]
Building ... 
c:\edk\edk2\Acme\Library\ABSafeOpenProtocolLib\ABSafeOpenProtocolLib.inf [X64]
"C:\Program Files (x86)\Microsoft Visual Studio 
9.0\Vc\bin\x86_amd64\cl.exe" 
/Foc:\edk\Build\Acme\RELEASE_VS2008x86\X64\Acme\Library\ABMemDumpLib\ABMemDumpLib\OUTPUT\.\
 /nologo /c /WX /GS- /X /W4 /Gs32768 /O1ib2s /GL- /Gy /FIAutoGen.h /EHs-c- /GR- 
/GF /X /Zc:wchar_t- /D UEFI_C_SOURCE /D MDEPKG_NDEBUG /D NDEBUG 
/Ic:\edk\edk2\Acme\Library\ABMemDumpLib  
/Ic:\edk\Build\Acme\RELEASE_VS2008x86\X64\Acme\Library\ABMemDumpLib\ABMemDumpLib\DEBUG
  /Ic:\edk\edk2\MdePkg  /Ic:\edk\edk2\MdePkg\Include  
/Ic:\edk\edk2\MdePkg\Include\X64  /Ic:\edk\edk2\Acme  
/Ic:\edk\edk2\Acme\Include  /Ic:\edk\edk2\Acme\Include\AB\UEFI  
/Ic:\edk\edk2\Acme\Include\AB\fastgui  /Ic:\edk\edk2\Acme\Include\AB  
/Ic:\edk\edk2\Acme\Include\IPP 
c:\edk\edk2\Acme\Library\ABMemDumpLib\ABMemDumpLib.c
Building ... 
c:\edk\edk2\MdePkg\Library\UefiApplicationEntryPoint\UefiApplicationEntryPoint.inf
 [X64]
ABLegacySpeakerLib.c
Building ... 
c:\edk\edk2\MdePkg\Library\BaseIoLibIntrinsic\BaseIoLibIntrinsic.inf [X64]
"C:\Program Files (x86)\Microsoft Visual Studio 
9.0\Vc\bin\x86_amd64\cl.exe" 

Re: [edk2-devel] [PATCH edk2-platforms v2 00/16] Add PCIe Support

[Ard Biesheuvel]

On 5/26/20 11:53 AM, Ard Biesheuvel wrote:

On 5/26/20 10:37 AM, Wasim Khan wrote:

From: Wasim Khan 

Add PCIe Support for NXP Layerscape SoC which supports
different PCIe controllers.
Use generic PCIe drivers and wire up PciHostBridgeLib,
PciSegmentLib and PciCpuIo2Dxe driver for controller
specific implementation.

V1 Series can be referred here:
https://edk2.groups.io/g/devel/message/60116?p=,,,20,0,0,0::relevance,,PCIe+Support,20,2,0,74395799 




Changes in V2:
- Addressed review comments received on V1.



Thanks Wasim

Reviewed-by: Ard Biesheuvel 

I took some liberties with the PciSegmentLib code to get rid of the 
inline functions in Pcie.h - please double check whether that code is 
still correct, and rebase your code before sending new work that applies 
on top of these changes.


Also, I failed to spot this in review, but preprocessor macros that 
resolve to values that are used in arithmetic expressions should really 
all contain outer (), or you will be pulling your hair out figuring out 
where the unexpected values are coming from. I fixed this up while 
committing (all in Pcie.h)


Pushed as 7a4035e9efd8..7121691cfcbc



One thing I realized is that this method of accessing config space is 
not reentrant. This could potentially cause problems, e.g., when some 
notification callback accesses the PCI config space, and reprograms some 
of these windows. If such a callback interrupts an ordinary config space 
access between the time it programs the window and the time it does the 
access, you may be accessing the wrong part of config space.


The usual way of dealing with this is to raise the TPL (Thread Priority 
Level) to TPL_NOTIFY while performing the accesses. So please take this 
into consideration for a followup series.



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

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

Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based Code Review Process

[Tomas Pilar (tpilar)]

I actually agree with you, when we migrated from reviewboard to github pull 
requests, I was sorely disappointed with the PR functionality and ergonomics.

Tomas Pilar

-Original Message-
From: r...@edk2.groups.io  On Behalf Of Rebecca Cran via 
groups.io
Sent: 14 May 2020 22:47
To: r...@edk2.groups.io; bret.barke...@microsoft.com; Kinney, Michael D 
; devel@edk2.groups.io; ler...@redhat.com
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2-rfc] GitHub Pull Request based 
Code Review Process

On 5/14/20 3:26 PM, Bret Barkelew via groups.io wrote:

> I feel like this process is a good compromise. It�s not perfect (frankly, 
> I�m a fan of enforced squash merges, which can maintain bisectability if 
> managed well), but it allows for rapid iteration, ease of contribution, and 
> approaches the workflow that many who have never used email to maintain a 
> project would be familiar with.
>
> It�s code management for the Instagram generation, and I for one welcome 
> our new insect overlords.

Or at least, that's what Microsoft is betting on! :D

Personally, I remain unconvinced about the usability of Github Pull Requests 
for a project the size of EDK2, but I hope to be proven wrong.


--
Rebecca Cran





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 (#60264): https://edk2.groups.io/g/devel/message/60264
Mute This Topic: https://groups.io/mt/74144675/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 v2 00/16] Add PCIe Support

[Ard Biesheuvel]

On 5/26/20 10:37 AM, Wasim Khan wrote:

From: Wasim Khan 

Add PCIe Support for NXP Layerscape SoC which supports
different PCIe controllers.
Use generic PCIe drivers and wire up PciHostBridgeLib,
PciSegmentLib and PciCpuIo2Dxe driver for controller
specific implementation.

V1 Series can be referred here:
https://edk2.groups.io/g/devel/message/60116?p=,,,20,0,0,0::relevance,,PCIe+Support,20,2,0,74395799


Changes in V2:
- Addressed review comments received on V1.



Thanks Wasim

Reviewed-by: Ard Biesheuvel 

I took some liberties with the PciSegmentLib code to get rid of the 
inline functions in Pcie.h - please double check whether that code is 
still correct, and rebase your code before sending new work that applies 
on top of these changes.


Also, I failed to spot this in review, but preprocessor macros that 
resolve to values that are used in arithmetic expressions should really 
all contain outer (), or you will be pulling your hair out figuring out 
where the unexpected values are coming from. I fixed this up while 
committing (all in Pcie.h)


Pushed as 7a4035e9efd8..7121691cfcbc



Meenakshi Aggarwal (1):
   Platform/NXP: LS1043aRdbPkg: Enable NetworkPkg

Wasim Khan (15):
   Silicon/NXP/NxpQoriqLs.dec: Add PCIe related PCDs.
   Silicon/NXP: LS1043A: Define PCIe related PCDs
   Silicon/NXP: Implement PciHostBridgeLib support
   Silicon/NXP: PciHostBridgeLib: CFG Shift feature support for PCIeLS
 Ctrl
   Silicon/NXP: PciHostBridgeLib: Setup PCIe LsGen4 Controller and ATU
 Windows
   Silicon/NXP: PciHostBridgeLib: add Workaround for A-011451
   Silicon/NXP: PciHostBridgeLib: Dump Layerscale Gen4 ATU windows
   Silicon/NXP: PciHostBridgeLib: Dump Layerscale iATU windows
   Silicon/NXP: Implement PciSegmentLib for PCIe Layerscape Controller
   Silicon/NXP: PciSegmentLib: Add ECAM config support for PCIe LS
 Controller
   Silicon/NXP: PciSegmentLib: Add support PCIe LsGen4 Controller
   Silicon/NXP: PciSegmentLib: LsGen4Ctrl: Add Workaround for A-011264
   Silicon/NXP/Drivers: Implement PciCpuIo2Dxe Driver
   Platform/NXP: LS1043aRdbPkg: Enable PCIE support
   Platform/NXP: LS1043aRdbPkg : Increase fv image size

  Silicon/NXP/NxpQoriqLs.dec|  12 +
  Silicon/NXP/LS1043A/LS1043A.dsc.inc   |   7 +
  Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc  |  20 +
  Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf  |  20 +-
  Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf |  40 +
  Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf |  43 +
  Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf   |  36 +
  Silicon/NXP/Include/Pcie.h| 228 ++
  Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c   | 628 
+++
  Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 830 

  Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c | 699 
+
  11 files changed, 2560 insertions(+), 3 deletions(-)
  create mode 100755 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
  create mode 100644 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
  create mode 100755 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
  create mode 100755 Silicon/NXP/Include/Pcie.h
  create mode 100755 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c
  create mode 100644 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
  create mode 100755 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c




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

View/Reply Online (#60263): https://edk2.groups.io/g/devel/message/60263
Mute This Topic: https://groups.io/mt/74474406/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 12/16] Silicon/NXP: PciSegmentLib: LsGen4Ctrl: Add Workaround for A-011264

[Wasim Khan]

From: Wasim Khan 

With PCIe LsGen4 controller, clearing the Bus Master Enable bit in
Command register blocks all outbound transactions to be sent out
in RC mode.

According to PCI Express base specification, the Command register’s
Bus Master Enable bit of a PCI Express RC controller can only
control the forwarding of memory requests received at its root port
in the upstream direction. In other words, clearing the Bus Master
Enable bit must not block all outbound transactions to be sent out
toward RC’s downstream devices. Due to this erratum, when the
Command register’s Bus Master Enable bit is cleared, all the outbound
transactions from the device’s internal bus masters, including but
not limited to configuration read and write transactions, are
terminated with the slave error (SLVERR) response status on the PCI
Express RC controller’s internal AXI bus interface.

Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Addressed review comments to:
  - Drop outer () while calculating Target
  - Use (Bus > 0) instead of (Bus)

 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
index 09ce620ef988..572fbb195c19 100755
--- a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
@@ -39,6 +39,21 @@ static BOOLEAN PciLsGen4Ctrl;
 
 STATIC
 VOID
+PciLsGen4SetBusMaster (
+  IN EFI_PHYSICAL_ADDRESS Dbi
+  )
+{
+  UINT32 Val;
+
+  //Make sure the Master Enable bit not cleared
+  Val = PciLsGen4Read32 ((UINTN)Dbi, PCI_COMMAND_OFFSET);
+  if (!(Val & EFI_PCI_COMMAND_BUS_MASTER)) {
+PciLsGen4Write32 ((UINTN)Dbi, PCI_COMMAND_OFFSET, Val | 
EFI_PCI_COMMAND_BUS_MASTER);
+  }
+}
+
+STATIC
+VOID
 PcieCfgSetTarget (
   IN EFI_PHYSICAL_ADDRESS Dbi,
   IN UINT32 Target)
@@ -71,6 +86,8 @@ PciLsGen4GetConfigBase (
   UINT32 Target;
 
   if (Bus > 0) {
+PciLsGen4SetBusMaster (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF* Segment);
+
 Target = (((Address >> 20) & 0xFF) << 24) |
  (((Address >> 15) & 0x1F) << 19) |
  (((Address >> 12) & 0x7) << 16);
-- 
2.7.4


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

View/Reply Online (#60260): https://edk2.groups.io/g/devel/message/60260
Mute This Topic: https://groups.io/mt/74474418/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 01/16] Silicon/NXP/NxpQoriqLs.dec: Add PCIe related PCDs.

[Wasim Khan]

From: Wasim Khan 

Add PCIe related PCDs.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Droped PcdPciDebug

 Silicon/NXP/NxpQoriqLs.dec | 8 
 1 file changed, 8 insertions(+)

diff --git a/Silicon/NXP/NxpQoriqLs.dec b/Silicon/NXP/NxpQoriqLs.dec
index 0722f59ef4f6..9ff5ce8a1c6e 100644
--- a/Silicon/NXP/NxpQoriqLs.dec
+++ b/Silicon/NXP/NxpQoriqLs.dec
@@ -27,3 +27,11 @@ [Guids.common]
 [PcdsFeatureFlag]
   gNxpQoriqLsTokenSpaceGuid.PcdI2cErratumA009203|FALSE|BOOLEAN|0x0315
   gNxpQoriqLsTokenSpaceGuid.PcdDcfgBigEndian|FALSE|BOOLEAN|0x0316
+  gNxpQoriqLsTokenSpaceGuid.PcdPciLutBigEndian|FALSE|BOOLEAN|0x0317
+
+[PcdsFixedAtBuild.common]
+  # Pcds for PCI Express
+  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr|0x0|UINT64|0x0500
+  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|0|UINT32|0x0501
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase|0x0|UINT32|0x0502
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg|0x0|UINT32|0x0503
-- 
2.7.4


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

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

Re: [edk2-devel] [RFC edk2 v1 1/1] MdeModulePkg/Variable: Move FindVariable after AutoUpdateLangVariable

[Ming Huang]

在 2020/5/26 8:39, Jiang, Guomin 写道:
> Hi Huangming,
> 
> I am taking the bugzilla and I am sorry that I haven't provide you with 
> productive comment.
> 
> I am still busy until August.
> 
> I just want to know that:
> 1. Have you verified that the symptom will disappear after invoked 
> FindVariable() function?

Yes, the symptom will disappeare after add this patch.

> 2. Is it your suggestion that the FindVariable() need to be invoked but you 
> have no idea that how to fix it?

This patch can fix this issue, and I guess this issue was resulted by adding 
AutoUpdateLangVariable feature.
I hope this patch can be merged to edk2 master.

Thanks
Ming

> 
> Best Regards
> Guomin
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Ming
>> Huang
>> Sent: Monday, May 25, 2020 7:34 PM
>> To: devel@edk2.groups.io; Wang, Jian J ; Wu, Hao A
>> ; Gao, Liming 
>> Cc: lidongz...@huawei.com; huangmin...@huawei.com;
>> songdongku...@huawei.com; wanghuiqi...@huawei.com;
>> qiulian...@huawei.com; shenli...@huawei.com
>> Subject: [edk2-devel] [RFC edk2 v1 1/1] MdeModulePkg/Variable: Move
>> FindVariable after AutoUpdateLangVariable
>>
>> When occur reclaim in AutoUpdateLangVariable(), the CurrPtr of Variable is
>> invalid. The State will be update with wrong position after UpdateVariable in
>> this situation and two valid PlatformLang or Lang variables will exist.
>> BmForEachVariable() will enter endless loop while exist two valid
>> PlatformLang variables. So FindVariable() should be invoked atfer
>> AutoUpdateLangVariable().
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=2667
>>
>> Signed-off-by: Ming Huang 
>> ---
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 26
>> ++--
>>  1 file changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>> b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>> index 1e71fc6..0cec981 100644
>> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
>> @@ -2741,6 +2741,19 @@ VariableServiceSetVariable (
>>  mVariableModuleGlobal->NonVolatileLastVariableOffset = (UINTN)
>> NextVariable - (UINTN) Point;
>>}
>>
>> +  if (!FeaturePcdGet (PcdUefiVariableDefaultLangDeprecate)) {
>> +//
>> +// Hook the operation of setting PlatformLangCodes/PlatformLang and
>> LangCodes/Lang.
>> +//
>> +Status = AutoUpdateLangVariable (VariableName, Data, DataSize);
>> +if (EFI_ERROR (Status)) {
>> +  //
>> +  // The auto update operation failed, directly return to avoid
>> inconsistency between PlatformLang and Lang.
>> +  //
>> +  goto Done;
>> +}
>> +  }
>> +
>>//
>>// Check whether the input variable is already existed.
>>//
>> @@ -2763,19 +2776,6 @@ VariableServiceSetVariable (
>>  }
>>}
>>
>> -  if (!FeaturePcdGet (PcdUefiVariableDefaultLangDeprecate)) {
>> -//
>> -// Hook the operation of setting PlatformLangCodes/PlatformLang and
>> LangCodes/Lang.
>> -//
>> -Status = AutoUpdateLangVariable (VariableName, Data, DataSize);
>> -if (EFI_ERROR (Status)) {
>> -  //
>> -  // The auto update operation failed, directly return to avoid 
>> inconsistency
>> between PlatformLang and Lang.
>> -  //
>> -  goto Done;
>> -}
>> -  }
>> -
>>if (mVariableModuleGlobal->VariableGlobal.AuthSupport) {
>>  Status = AuthVariableLibProcessVariable (VariableName, VendorGuid,
>> Data, DataSize, Attributes);
>>} else {
>> --
>> 2.8.1
>>
>>
>> 
> 
> 
> 


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

View/Reply Online (#60261): https://edk2.groups.io/g/devel/message/60261
Mute This Topic: https://groups.io/mt/74462883/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 11/16] Silicon/NXP: PciSegmentLib: Add support PCIe LsGen4 Controller

[Wasim Khan]

From: Wasim Khan 

PCIe Layerscape Gen4 controller is not ECAM compliant and have
different PCI config space region for bus 0 (Controller space) and
bus[0x1-0xff] on NXP SoCs.

For config transactions for Bus0:
  - Config transaction address = PCIe controller address + offset

For config transactions for Bus[0x1-0xff]:
  - PCIe IP requires target BDF to be written at bit[31:16] of PCIe
outbound configuration window.

PCIe LsGen4 controller uses paging mechanism to access registers.
To access PCIe CCSR registers which are above 3KB offset, page number
must be set in Bridge Control Register.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- fix typo in commit message
- Removed Signed-off and added Co-authored-by for co-author
- Addressed review comments to:
  - Drop outer () while calulating Target
  - Use (Bus > 0) instead of (Bus)

 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf |  1 +
 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c   | 60 +++-
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
index 936213dc8a9d..d6d7ea6e3b6b 100755
--- a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
@@ -33,3 +33,4 @@ [FixedPcd]
 
 [Pcd]
   gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable
+  gNxpQoriqLsTokenSpaceGuid.PcdPciLsGen4Ctrl
diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
index e5251ecf0dd8..09ce620ef988 100755
--- a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
@@ -35,6 +35,58 @@ typedef enum {
   ASSERT (((A) & (0xf000ULL | (M))) == 0)
 
 static BOOLEAN CfgShiftEnable;
+static BOOLEAN PciLsGen4Ctrl;
+
+STATIC
+VOID
+PcieCfgSetTarget (
+  IN EFI_PHYSICAL_ADDRESS Dbi,
+  IN UINT32 Target)
+{
+PciLsGen4Write32 ((UINTN)Dbi, PAB_AXI_AMAP_PEX_WIN_L(0), Target);
+PciLsGen4Write32 ((UINTN)Dbi, PAB_AXI_AMAP_PEX_WIN_H(0), 0);
+}
+
+/**
+  Function to return PCIe Physical Address(PCIe view) or Controller
+  Address(CPU view) for NXP Layerscape Gen4 SoC
+
+  @param  Address Address passed from bus layer.
+  @param  Segment Segment number for Root Complex.
+  @param  Offset  Config space register offset.
+  @param  Bus PCIe Bus number.
+
+  @return Return PCIe CPU or Controller address.
+
+**/
+STATIC
+UINT64
+PciLsGen4GetConfigBase (
+  IN  UINT64  Address,
+  IN  UINT16  Segment,
+  IN  UINT16  Offset,
+  IN  UINT8   Bus
+  )
+{
+  UINT32 Target;
+
+  if (Bus > 0) {
+Target = (((Address >> 20) & 0xFF) << 24) |
+ (((Address >> 15) & 0x1F) << 19) |
+ (((Address >> 12) & 0x7) << 16);
+
+PcieCfgSetTarget ((PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF* Segment), 
Target);
+return PCI_SEG0_MMIO_MEMBASE + Offset + PCI_BASE_DIFF * Segment;
+  } else {
+  if (Offset < INDIRECT_ADDR_BNDRY) {
+PciLsGen4SetPg (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment, 0);
+return (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment + Offset);
+  }
+  PciLsGen4SetPg (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment, 
OFFSET_TO_PAGE_IDX (Offset));
+  Offset = OFFSET_TO_PAGE_ADDR (Offset);
+  return (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment + Offset);
+  }
+}
 
 STATIC
 UINT64
@@ -129,7 +181,12 @@ PciSegmentLibGetConfigBase (
   UINT8  Bus;
 
   Bus = ((UINT32)Address >> 20) & 0xff;
-  return PciLsGetConfigBase (Address, Segment, Offset, Bus);
+
+  if (PciLsGen4Ctrl) {
+return PciLsGen4GetConfigBase (Address, Segment, Offset, Bus);
+  } else {
+return PciLsGetConfigBase (Address, Segment, Offset, Bus);
+  }
 }
 
 /**
@@ -620,5 +677,6 @@ PciSegLibInit (
   )
 {
   CfgShiftEnable = CFG_SHIFT_ENABLE;
+  PciLsGen4Ctrl = PCI_LS_GEN4_CTRL;
   return EFI_SUCCESS;
 }
-- 
2.7.4


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

View/Reply Online (#60259): https://edk2.groups.io/g/devel/message/60259
Mute This Topic: https://groups.io/mt/74474417/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 03/16] Silicon/NXP: Implement PciHostBridgeLib support

[Wasim Khan]

From: Wasim Khan 

Implement PciHostBridgeLib that exposes the PCIe root complexes to
the generic PCI host bridge driver.

Setup PCIe Layerscape Controller and setup CFG, IO,
MMIO and MMIO64 iATU windows.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Added logic to create MMIO64 windows based on MMIO64 available space
- Drop EmbeddedPkg/EmbeddedPkg.dec
- Removed "__" from header file inclusion

 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf |  39 ++
 Silicon/NXP/Include/Pcie.h|  80 +++
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 558 

 3 files changed, 677 insertions(+)

diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
new file mode 100644
index ..aa4802b019f6
--- /dev/null
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
@@ -0,0 +1,39 @@
+## @file
+#  PCI Host Bridge Library instance for NXP ARM SOC
+#
+#  Copyright 2018-2020 NXP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = PciHostBridgeLib
+  FILE_GUID  = f4c99bcc-5c95-49ad-b0f3-fc5b611dc9c1
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PciHostBridgeLib
+
+[Sources]
+  PciHostBridgeLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  Silicon/NXP/NxpQoriqLs.dec
+
+[LibraryClasses]
+  DebugLib
+  DevicePathLib
+  IoAccessLib
+  MemoryAllocationLib
+  PcdLib
+
+[FeaturePcd]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciLutBigEndian
+
+[FixedPcd]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr
+  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg
diff --git a/Silicon/NXP/Include/Pcie.h b/Silicon/NXP/Include/Pcie.h
new file mode 100755
index ..9dbe876b9c1a
--- /dev/null
+++ b/Silicon/NXP/Include/Pcie.h
@@ -0,0 +1,80 @@
+/** @file
+  PCI memory configuration for NXP
+
+  Copyright 2018-2020 NXP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef PCI_H
+#define PCI_H
+
+#define PCI_SEG0_NUM  0
+#define PCI_SEG1_NUM  1
+#define PCI_SEG2_NUM  2
+#define PCI_SEG3_NUM  3
+#define PCI_SEG4_NUM  4
+#define PCI_SEG5_NUM  5
+#define PCI_SEG0_MMIO_MEMBASE FixedPcdGet64 (PcdPciExp1BaseAddr)
+#define PCI_SEG0_DBI_BASE 0x0340
+
+#define PCI_LINK_DOWN 0x0
+#define PCI_LINK_UP   0x1
+
+// Segment configuration
+#define PCI_SEG_BUSNUM_MIN0x0
+#define PCI_SEG_BUSNUM_MAX0xff
+#define PCI_SEG_PORTIO_MIN0x0
+#define PCI_SEG_PORTIO_MAX0x
+#define SEG_CFG_SIZE  0x1000
+#define SEG_MEM_BASE  0x4000
+#define SEG_MEM_SIZE  0xC000
+#define SEG_MEM_LIMIT SEG_MEM_BASE + (SEG_MEM_SIZE -1)
+#define SEG_IO_BASE   0x1000
+#define SEG_MEM64_BASE0x4
+#define PCI_BASE_DIFF 0x8
+#define PCI_DBI_SIZE_DIFF 0x10
+#define PCI_SEG0_PHY_CFG0_BASEPCI_SEG0_MMIO_MEMBASE
+#define PCI_SEG0_PHY_CFG1_BASEPCI_SEG0_PHY_CFG0_BASE + SEG_CFG_SIZE
+#define PCI_SEG0_PHY_MEM_BASE PCI_SEG0_MMIO_MEMBASE + SEG_MEM_BASE
+#define PCI_SEG0_PHY_MEM64_BASE   PCI_SEG0_MMIO_MEMBASE + SEG_MEM64_BASE
+#define PCI_MMIO64_WIN_SIZE   SIZE_16GB
+#define PCI_SEG0_PHY_IO_BASE  PCI_SEG0_MMIO_MEMBASE + SEG_IO_BASE
+
+// PCIe Controller configuration
+#define NUM_PCIE_CONTROLLER   FixedPcdGet32 (PcdNumPciController)
+#define PCI_LUT_DBG   FixedPcdGet32 (PcdPcieLutDbg)
+#define PCI_LUT_BASE  FixedPcdGet32 (PcdPcieLutBase)
+#define LTSSM_PCIE_L0 0x11
+
+#define PCI_CLASS_BRIDGE_PCI  0x0604
+#define PCI_CLASS_DEVICE  0x8
+#define PCI_DBI_RO_WR_EN  0x8bc
+#define CLASS_CODE_MASK   0x
+#define CLASS_CODE_SHIFT  0x10
+
+// PCIe Layerscape Controller
+#define IATU_VIEWPORT_OFF0x900
+#define IATU_REGION_CTRL_1_OFF_OUTBOUND_00x904
+#define IATU_REGION_CTRL_2_OFF_OUTBOUND_00x908
+#define IATU_LWR_BASE_ADDR_OFF_OUTBOUND_00x90C
+#define IATU_UPPER_BASE_ADDR_OFF_OUTBOUND_0  0x910
+#define IATU_LIMIT_ADDR_OFF_OUTBOUND_0   0x914
+#define IATU_LWR_TARGET_ADDR_OFF_OUTBOUND_0  0x918
+#define IATU_UPPER_TARGET_ADDR_OFF_OUTBOUND_00x91C
+#define IATU_VIEWPORT_OUTBOUND   0x0
+#define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN  BIT31
+
+// ATU Programming
+#define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_MEM   0x0
+#define 

[edk2-devel] [PATCH edk2-platforms v2 16/16] Platform/NXP: LS1043aRdbPkg : Increase fv image size

[Wasim Khan]

From: Wasim Khan 

Increase fv image size to pass debug build.

Signed-off-by: Wasim Khan 
Acked-by: Ard Biesheuvel 
---

Notes:
V2:
- No change

 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
index 81142f217a63..1c160e349eb9 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
@@ -24,10 +24,12 @@
 
 [FD.LS1043ARDB_EFI]
 BaseAddress   = 0x8200|gArmTokenSpaceGuid.PcdFdBaseAddress  #The base 
address of the FLASH Device.
-Size  = 0x0014|gArmTokenSpaceGuid.PcdFdSize #The size in 
bytes of the FLASH Device
+Size  = 0x0018|gArmTokenSpaceGuid.PcdFdSize #The size in 
bytes of the FLASH Device
 ErasePolarity = 1
+
+# This one is tricky, it must be: BlockSize * NumBlocks = Size
 BlockSize = 0x4
-NumBlocks = 0x5
+NumBlocks = 0x6
 
 

 #
@@ -44,7 +46,7 @@ [FD.LS1043ARDB_EFI]
 # RegionType 
 #
 

-0x|0x0014
+0x|0x0018
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
 FV = FVMAIN_COMPACT
 
-- 
2.7.4


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

View/Reply Online (#60255): https://edk2.groups.io/g/devel/message/60255
Mute This Topic: https://groups.io/mt/74474413/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 07/16] Silicon/NXP: PciHostBridgeLib: Dump Layerscale Gen4 ATU windows

[Wasim Khan]

From: Wasim Khan 

Dump ATU windows for PCIe LsGen4 controller.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Drop PcdPciDebug and use DEBUG_CODE_BEGIN/DEBUG_CODE_END
- Passing Max window number as argument to LsGen4DumpAtu()

 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c | 36 

 1 file changed, 36 insertions(+)

diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
index 339a3d9bffa6..53b93e2b6f23 100644
--- a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -399,6 +399,38 @@ PcieLsSetupAtu (
 }
 
 /**
+  Dump PCIe LsGen4 ATU
+
+  @param Pcie Address of PCIe host controller.
+  @param CountNumber of Windows
+**/
+VOID LsGen4DumpAtu (
+  IN EFI_PHYSICAL_ADDRESS Pcie,
+  IN UINT32 Count
+  )
+{
+  UINT32 Cnt;
+  for (Cnt = 0; Cnt < Count; Cnt++) {
+DEBUG ((DEBUG_INFO,"APIO WINDOW%d:\n", Cnt));
+DEBUG ((DEBUG_INFO,"\tLOWER PHYS 0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_AXI_AMAP_AXI_WIN (Cnt;
+DEBUG ((DEBUG_INFO,"\tUPPER PHYS 0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_EXT_AXI_AMAP_AXI_WIN (Cnt;
+DEBUG ((DEBUG_INFO,"\tLOWER BUS  0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_AXI_AMAP_PEX_WIN_L (Cnt;
+DEBUG ((DEBUG_INFO,"\tUPPER BUS  0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_AXI_AMAP_PEX_WIN_H (Cnt;
+DEBUG ((DEBUG_INFO,"\tSIZE  0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_AXI_AMAP_CTRL (Cnt)) &
+(AXI_AMAP_CTRL_SIZE_MASK << AXI_AMAP_CTRL_SIZE_SHIFT)));
+DEBUG ((DEBUG_INFO,"\tEXT_SIZE0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_EXT_AXI_AMAP_SIZE (Cnt;
+DEBUG ((DEBUG_INFO,"\tCTRL:0x%08x\n",
+PciLsGen4Read32 ((UINTN)Pcie, PAB_AXI_AMAP_CTRL (Cnt;
+  }
+}
+
+/**
   Function to set-up ATU windows for PCIe LayerscapeGen4 controller
 
   @param Pcie  Address of PCIe host controller
@@ -462,6 +494,10 @@ PcieLsGen4SetupAtu (
 
 Mem64Base += SIZE_4GB;
   }
+
+  DEBUG_CODE_BEGIN ();
+  LsGen4DumpAtu (Pcie, Index);
+  DEBUG_CODE_END ();
 }
 
 /**
-- 
2.7.4


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

View/Reply Online (#60258): https://edk2.groups.io/g/devel/message/60258
Mute This Topic: https://groups.io/mt/74474416/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 06/16] Silicon/NXP: PciHostBridgeLib: add Workaround for A-011451

[Wasim Khan]

From: Wasim Khan 

When PCIe Layerscape Gen4 controller is sending multiple split
completions and ACK latency expires indicating that ACK should
be send at priority. But because of large number of split completions
and FC update DLLP,the controller does not give priority to ACK
transmission. This results into ACK latency timer timeout error
at the link partner and the pending TLPs are replayed by the
link partner again.

Workaround:
Reduce the ACK latency timeout value.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author

 Silicon/NXP/Include/Pcie.h  | 4 
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/Silicon/NXP/Include/Pcie.h b/Silicon/NXP/Include/Pcie.h
index b7d46f3a3bd2..210e4c3cf5e7 100755
--- a/Silicon/NXP/Include/Pcie.h
+++ b/Silicon/NXP/Include/Pcie.h
@@ -202,4 +202,8 @@ STATIC inline VOID PciLsGen4Write32 (
 MmioWrite32 (Dbi + OFFSET_TO_PAGE_ADDR (Offset), Value);
   }
 }
+
+#define GPEX_ACK_REPLAY_TO  0x438
+#define ACK_LAT_TO_VAL_SHIFT0
+#define ACK_LAT_TO_VAL_MASK 0x1fff
 #endif
diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
index 8e39fb25f83e..339a3d9bffa6 100644
--- a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -534,6 +534,12 @@ PcieSetupCntrl (
   if (PCI_LS_GEN4_CTRL) {
 // PCIe LsGen4 Controller Setup
 
+// Workaround for A-011451
+Val = PciLsGen4Read32 ((UINTN)Pcie, GPEX_ACK_REPLAY_TO);
+Val &= ~(ACK_LAT_TO_VAL_MASK << ACK_LAT_TO_VAL_SHIFT);
+Val |= (4 << ACK_LAT_TO_VAL_SHIFT);
+PciLsGen4Write32 ((UINTN)Pcie, GPEX_ACK_REPLAY_TO, Val);
+
 //Fix Class Code
 Val = PciLsGen4Read32 ((UINTN)Pcie, GPEX_CLASSCODE);
 Val &= ~(GPEX_CLASSCODE_MASK << GPEX_CLASSCODE_SHIFT);
-- 
2.7.4


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

View/Reply Online (#60262): https://edk2.groups.io/g/devel/message/60262
Mute This Topic: https://groups.io/mt/74474419/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 00/16] Add PCIe Support

[Wasim Khan]

From: Wasim Khan 

Add PCIe Support for NXP Layerscape SoC which supports
different PCIe controllers.
Use generic PCIe drivers and wire up PciHostBridgeLib,
PciSegmentLib and PciCpuIo2Dxe driver for controller
specific implementation.

V1 Series can be referred here:
https://edk2.groups.io/g/devel/message/60116?p=,,,20,0,0,0::relevance,,PCIe+Support,20,2,0,74395799


Changes in V2:
- Addressed review comments received on V1.

Meenakshi Aggarwal (1):
  Platform/NXP: LS1043aRdbPkg: Enable NetworkPkg

Wasim Khan (15):
  Silicon/NXP/NxpQoriqLs.dec: Add PCIe related PCDs.
  Silicon/NXP: LS1043A: Define PCIe related PCDs
  Silicon/NXP: Implement PciHostBridgeLib support
  Silicon/NXP: PciHostBridgeLib: CFG Shift feature support for PCIeLS
Ctrl
  Silicon/NXP: PciHostBridgeLib: Setup PCIe LsGen4 Controller and ATU
Windows
  Silicon/NXP: PciHostBridgeLib: add Workaround for A-011451
  Silicon/NXP: PciHostBridgeLib: Dump Layerscale Gen4 ATU windows
  Silicon/NXP: PciHostBridgeLib: Dump Layerscale iATU windows
  Silicon/NXP: Implement PciSegmentLib for PCIe Layerscape Controller
  Silicon/NXP: PciSegmentLib: Add ECAM config support for PCIe LS
Controller
  Silicon/NXP: PciSegmentLib: Add support PCIe LsGen4 Controller
  Silicon/NXP: PciSegmentLib: LsGen4Ctrl: Add Workaround for A-011264
  Silicon/NXP/Drivers: Implement PciCpuIo2Dxe Driver
  Platform/NXP: LS1043aRdbPkg: Enable PCIE support
  Platform/NXP: LS1043aRdbPkg : Increase fv image size

 Silicon/NXP/NxpQoriqLs.dec|  12 +
 Silicon/NXP/LS1043A/LS1043A.dsc.inc   |   7 +
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc  |  20 +
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf  |  20 +-
 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf |  40 +
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf |  43 +
 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf   |  36 +
 Silicon/NXP/Include/Pcie.h| 228 ++
 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c   | 628 +++
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 830 

 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c | 699 
+
 11 files changed, 2560 insertions(+), 3 deletions(-)
 create mode 100755 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
 create mode 100644 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
 create mode 100755 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
 create mode 100755 Silicon/NXP/Include/Pcie.h
 create mode 100755 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c
 create mode 100644 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
 create mode 100755 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c

-- 
2.7.4


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

View/Reply Online (#60249): https://edk2.groups.io/g/devel/message/60249
Mute This Topic: https://groups.io/mt/74474406/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 02/16] Silicon/NXP: LS1043A: Define PCIe related PCDs

[Wasim Khan]

From: Wasim Khan 

Define PCIe related PCDs for LS1043A.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Dropped PcdPciDebug

 Silicon/NXP/LS1043A/LS1043A.dsc.inc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Silicon/NXP/LS1043A/LS1043A.dsc.inc 
b/Silicon/NXP/LS1043A/LS1043A.dsc.inc
index 67f5ba68dcd5..e023bfbc7c04 100644
--- a/Silicon/NXP/LS1043A/LS1043A.dsc.inc
+++ b/Silicon/NXP/LS1043A/LS1043A.dsc.inc
@@ -30,4 +30,11 @@ [PcdsFixedAtBuild.common]
 
 [PcdsFeatureFlag]
   gNxpQoriqLsTokenSpaceGuid.PcdDcfgBigEndian|TRUE
+  gNxpQoriqLsTokenSpaceGuid.PcdPciLutBigEndian|TRUE
+
+[PcdsFixedAtBuild.common]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr|0x40
+  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|3
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase|0x1
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg|0x7FC
 ##
-- 
2.7.4


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

View/Reply Online (#60251): https://edk2.groups.io/g/devel/message/60251
Mute This Topic: https://groups.io/mt/74474409/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 09/16] Silicon/NXP: Implement PciSegmentLib for PCIe Layerscape Controller

[Wasim Khan]

From: Wasim Khan 

We have different PCI config space region for bus 0 (Controller space) and
bus[0x1-0xff] on NXP SoCs with PCIe LS controller.
Add PciSegmentLib for PCIe LS controller.

For config transactions for Bus0:
  - Config transaction address = PCIe controller address + offset

For config transactions for Bus[0x1-0xff]:
  - PCIe IP requires target BDF to be written at bit[31:16] of PCIe
type0/type1 outbound window.
  - Config transaction address = PCIe config space address + offset

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Incorporated review comments:
  - Remove outer () while calculating Target
  - Use (Bus > 0) instead of (Bus)

 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf |  32 +
 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c   | 612 
 2 files changed, 644 insertions(+)

diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
new file mode 100755
index ..a36e79239b33
--- /dev/null
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
@@ -0,0 +1,32 @@
+## @file
+#  PCI Segment Library for NXP SoCs with multiple RCs
+#
+#  Copyright 2018-2020 NXP
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = PciSegmentLib
+  FILE_GUID  = c9f59261-5a60-4a4c-82f6-1f520442e100
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PciSegmentLib|DXE_DRIVER
+  CONSTRUCTOR= PciSegLibInit
+
+[Sources]
+  PciSegmentLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  Silicon/NXP/NxpQoriqLs.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  IoLib
+  PcdLib
+
+[FixedPcd]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr
diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
new file mode 100755
index ..d0bacca3d0d7
--- /dev/null
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
@@ -0,0 +1,612 @@
+/** @file
+  PCI Segment Library for NXP SoCs with multiple RCs
+
+  Copyright 2018-2020 NXP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef enum {
+  PciCfgWidthUint8  = 0,
+  PciCfgWidthUint16,
+  PciCfgWidthUint32,
+  PciCfgWidthMax
+} PCI_CFG_WIDTH;
+
+/**
+  Assert the validity of a PCI Segment address.
+  A valid PCI Segment address should not contain 1's in bits 28..31 and 48..63
+
+  @param  A The address to validate.
+  @param  M Additional bits to assert to be zero.
+
+**/
+#define ASSERT_INVALID_PCI_SEGMENT_ADDRESS(A,M) \
+  ASSERT (((A) & (0xf000ULL | (M))) == 0)
+
+STATIC
+UINT64
+PciLsCfgTarget (
+  IN  EFI_PHYSICAL_ADDRESS Dbi,
+  IN  UINT64   Address,
+  IN  UINT16   Segment,
+  IN  UINT8Bus,
+  IN  UINT16   Offset
+  )
+{
+  UINT32 Target;
+
+  Target = (((Address >> 20) & 0xFF) << 24) |
+   (((Address >> 15) & 0x1F) << 19) |
+   (((Address >> 12) & 0x7) << 16);
+
+  if (Bus > 1) {
+MmioWrite32 ((UINTN)Dbi + IATU_VIEWPORT_OFF, IATU_VIEWPORT_OUTBOUND | 
IATU_REGION_INDEX1);
+  } else {
+MmioWrite32 ((UINTN)Dbi + IATU_VIEWPORT_OFF, IATU_VIEWPORT_OUTBOUND | 
IATU_REGION_INDEX0);
+  }
+
+  MmioWrite32 ((UINTN)Dbi + IATU_LWR_TARGET_ADDR_OFF_OUTBOUND_0, Target);
+
+  if (Bus > 1) {
+return PCI_SEG0_MMIO_MEMBASE + PCI_BASE_DIFF * Segment + SEG_CFG_SIZE + 
Offset;
+  } else {
+return PCI_SEG0_MMIO_MEMBASE + PCI_BASE_DIFF * Segment + Offset;
+  }
+}
+
+/**
+  Function to return PCIe Physical Address(PCIe view) or Controller
+  Address(CPU view) for different RCs
+
+  @param  Address Address passed from bus layer.
+  @param  Segment Segment number for Root Complex.
+  @param  Offset  Config space register offset.
+  @param  Bus PCIe Bus number.
+
+  @return Return PCIe CPU or Controller address.
+
+**/
+STATIC
+UINT64
+PciLsGetConfigBase (
+  IN  UINT64  Address,
+  IN  UINT16  Segment,
+  IN  UINT16  Offset,
+  IN  UINT8   Bus
+  )
+{
+  UINT32 CfgAddr;
+
+  CfgAddr = (UINT16)Offset;
+  if (Bus > 0) {
+return PciLsCfgTarget (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment, 
Address, Segment, Bus, Offset);
+  } else {
+return PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment + CfgAddr;
+  }
+}
+
+/**
+  Function to return PCIe Physical Address(PCIe view) or Controller
+  Address(CPU view) for different RCs
+
+  @param  Address Address passed from bus layer.
+  @param  Segment Segment number for Root Complex.
+  @param  Offset  Config space register offset.
+
+  @return Return PCIe CPU or Controller address.
+
+**/
+STATIC
+UINT64

[edk2-devel] [PATCH edk2-platforms v2 05/16] Silicon/NXP: PciHostBridgeLib: Setup PCIe LsGen4 Controller and ATU Windows

[Wasim Khan]

From: Wasim Khan 

Setup PCIe LayerscapeGen4 controller and setup CFG, IO,
MMIO and MMIO64 iATU windows.
Check for PcdPciLsGen4Ctrl to enable LsGen4 PCIe
controller.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Added logic to create MMIO64 ATU windows as per MMIO64 available space

 Silicon/NXP/NxpQoriqLs.dec|   1 +
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf |   1 +
 Silicon/NXP/Include/Pcie.h| 120 ++
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 247 

 4 files changed, 328 insertions(+), 41 deletions(-)

diff --git a/Silicon/NXP/NxpQoriqLs.dec b/Silicon/NXP/NxpQoriqLs.dec
index 5358aaeb037e..d4d3057af509 100644
--- a/Silicon/NXP/NxpQoriqLs.dec
+++ b/Silicon/NXP/NxpQoriqLs.dec
@@ -38,3 +38,4 @@ [PcdsFixedAtBuild.common]
 
 [PcdsDynamic.common]
   gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable|FALSE|BOOLEAN|0x0600
+  gNxpQoriqLsTokenSpaceGuid.PcdPciLsGen4Ctrl|FALSE|BOOLEAN|0x0601
diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
index 99807d5beb1f..aa5a9dec7c34 100644
--- a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
@@ -40,3 +40,4 @@ [FixedPcd]
 
 [Pcd]
   gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable
+  gNxpQoriqLsTokenSpaceGuid.PcdPciLsGen4Ctrl
diff --git a/Silicon/NXP/Include/Pcie.h b/Silicon/NXP/Include/Pcie.h
index f7c18c3aa094..b7d46f3a3bd2 100755
--- a/Silicon/NXP/Include/Pcie.h
+++ b/Silicon/NXP/Include/Pcie.h
@@ -81,5 +81,125 @@
 #define SEG_IO_BUS0x0
 
 #define CFG_SHIFT_ENABLE  (PcdGetBool (PcdPciCfgShiftEnable))
+#define PCI_LS_GEN4_CTRL  (PcdGetBool (PcdPciLsGen4Ctrl))
 
+// PCIe Layerscape Gen4 Controller
+#define GPEX_CLASSCODE  0x474
+#define GPEX_CLASSCODE_SHIFT16
+#define GPEX_CLASSCODE_MASK 0x
+#define PAB_AXI_PIO_CTRL(Idx)   (0x840 + 0x10 * Idx)
+#define APIO_EN 0x1
+#define MEM_WIN_EN  0x1 << 1
+#define IO_WIN_EN   0x1 << 2
+#define CFG_WIN_EN  0x1 << 3
+#define PAB_PEX_PIO_CTRL(Idx)   (0x8c0 + 0x10 * Idx)
+#define PPIO_EN (0x1 << 0)
+#define PAB_PEX_PIO_STAT(Idx)   (0x8c4 + 0x10 * Idx)
+#define PAB_PEX_PIO_MT_STAT(Idx)(0x8c8 + 0x10 * Idx)
+#define PEX_AMAP_CTRL_TYPE_SHIFT0x1
+#define PEX_AMAP_CTRL_EN_SHIFT  0x0
+#define PEX_AMAP_CTRL_TYPE_MASK 0x3
+#define PEX_AMAP_CTRL_EN_MASK   0x1
+#define PAB_PEX_AMAP_CTRL(Idx)  (0x4ba0 + 0x10 * Idx)
+#define PAB_EXT_PEX_AMAP_SIZE(Idx)  (0xbef0 + 0x04 * Idx)
+#define PAB_PEX_AMAP_AXI_WIN(Idx)   (0x4ba4 + 0x10 * Idx)
+#define PAB_EXT_PEX_AMAP_AXI_WIN(Idx)   (0xb4a0 + 0x04 * Idx)
+#define PAB_PEX_AMAP_PEX_WIN_L(Idx) (0x4ba8 + 0x10 * Idx)
+#define PAB_PEX_AMAP_PEX_WIN_H(Idx) (0x4bac + 0x10 * Idx)
+#define PAB_CTRL0x808
+#define PAB_CTRL_APIO_EN0x1
+#define PAB_CTRL_PPIO_EN(0x1 << 1)
+#define PAB_CTRL_PAGE_SEL_SHIFT 13
+#define PAB_CTRL_PAGE_SEL_MASK  0x3f
+#define INDIRECT_ADDR_BNDRY 0xc00
+#define PAGE_IDX_SHIFT  10
+#define PAGE_ADDR_MASK  0x3ff
+#define PAB_AXI_AMAP_CTRL(Idx)  (0xba0 + 0x10 * Idx)
+#define PAB_EXT_AXI_AMAP_SIZE(Idx)  (0xbaf0 + 0x4 * Idx)
+#define PAB_AXI_AMAP_AXI_WIN(Idx)   (0xba4 + 0x10 * Idx)
+#define PAB_EXT_AXI_AMAP_AXI_WIN(Idx)   (0x80a0 + 0x4 * Idx)
+#define PAB_AXI_AMAP_PEX_WIN_L(Idx) (0xba8 + 0x10 * Idx)
+#define PAB_AXI_AMAP_PEX_WIN_H(Idx) (0xbac + 0x10 * Idx)
+#define PAB_AXI_TYPE_CFG0x00
+#define PAB_AXI_TYPE_IO 0x01
+#define PAB_AXI_TYPE_MEM0x02
+#define AXI_AMAP_CTRL_EN0x1
+#define AXI_AMAP_CTRL_TYPE_SHIFT1
+#define AXI_AMAP_CTRL_TYPE_MASK 0x3
+#define AXI_AMAP_CTRL_SIZE_SHIFT10
+#define AXI_AMAP_CTRL_SIZE_MASK 0x3f
+
+
+#define OFFSET_TO_PAGE_IDX(Off) ((Off >> PAGE_IDX_SHIFT) \
+& PAB_CTRL_PAGE_SEL_MASK)
+
+#define OFFSET_TO_PAGE_ADDR(Off)((Off & PAGE_ADDR_MASK) \
+| INDIRECT_ADDR_BNDRY)
+/**
+  Function to set page for LsGen4 

[edk2-devel] [PATCH edk2-platforms v2 14/16] Platform/NXP: LS1043aRdbPkg: Enable NetworkPkg

[Wasim Khan]

From: Meenakshi Aggarwal 

Enable NetworkPkg for LS1043aRdb Platform.

Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Change author

 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc | 11 +++
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf |  5 +
 2 files changed, 16 insertions(+)

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
index d45fd67c03b5..8f7f9d171587 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
@@ -22,6 +22,13 @@ [Defines]
   OUTPUT_DIRECTORY   = Build/LS1043aRdbPkg
   FLASH_DEFINITION   = Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
 
+  #
+  # Network definition
+  #
+  DEFINE NETWORK_TLS_ENABLE = FALSE
+  DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
+  DEFINE NETWORK_ISCSI_ENABLE   = FALSE
+
 !include Silicon/NXP/NxpQoriqLs.dsc.inc
 !include Silicon/NXP/LS1043A/LS1043A.dsc.inc
 
@@ -54,4 +61,8 @@ [Components.common]
   Silicon/NXP/Drivers/I2cDxe/I2cDxe.inf
   Platform/NXP/LS1043aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf
 
+  #
+  # Networking stack
+  #
+!include NetworkPkg/Network.dsc.inc
  ##
diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
index 931d0bb14f9b..59691e8c 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
@@ -119,6 +119,11 @@ [FV.FvMain]
   INF EmbeddedPkg/SimpleTextInOutSerial/SimpleTextInOutSerial.inf
 
   #
+  # Networking stack
+  #
+!include NetworkPkg/Network.fdf.inc
+
+  #
   # FAT filesystem + GPT/MBR partitioning
   #
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-- 
2.7.4


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

View/Reply Online (#60248): https://edk2.groups.io/g/devel/message/60248
Mute This Topic: https://groups.io/mt/74474405/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 08/16] Silicon/NXP: PciHostBridgeLib: Dump Layerscale iATU windows

[Wasim Khan]

From: Wasim Khan 

Dump ATU windows for PCIe Layerscape controller.

Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Drop PcdPciDebug and use DEBUG_CODE_BEGIN/DEBUG_CODE_END
- Passing Max window number as argument to LsDumpAtu()

 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c | 44 

 1 file changed, 44 insertions(+)

diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
index 53b93e2b6f23..670353b6c8d4 100644
--- a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -297,6 +297,46 @@ PcieOutboundSet (
 }
 
 /**
+  Dump PCIe Layerscape ATU
+
+  @param Pcie Address of PCIe host controller.
+  @param CountNumber of Windows
+**/
+VOID LsDumpAtu (
+  IN EFI_PHYSICAL_ADDRESS Pcie,
+  IN UINT32 Count
+  )
+{
+  UINT32 Cnt;
+  for (Cnt = 0; Cnt < Count; Cnt++) {
+MmioWrite32 ((UINTN)Pcie + IATU_VIEWPORT_OFF,
+  (UINT32)(IATU_VIEWPORT_OUTBOUND | Cnt));
+
+DEBUG ((DEBUG_INFO, "iATU%d:\n",Cnt));
+DEBUG ((DEBUG_INFO, "\tLOWER PHYS 0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_LWR_BASE_ADDR_OFF_OUTBOUND_0)));
+
+DEBUG ((DEBUG_INFO, "\tUPPER PHYS 0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_UPPER_BASE_ADDR_OFF_OUTBOUND_0)));
+
+DEBUG ((DEBUG_INFO, "\tLOWER BUS 0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_LWR_TARGET_ADDR_OFF_OUTBOUND_0)));
+
+DEBUG ((DEBUG_INFO, "\tUPPER BUS 0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_UPPER_TARGET_ADDR_OFF_OUTBOUND_0)));
+
+DEBUG ((DEBUG_INFO, "\tLIMIT 0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_LIMIT_ADDR_OFF_OUTBOUND_0)));
+
+DEBUG ((DEBUG_INFO, "\tCR1   0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_REGION_CTRL_1_OFF_OUTBOUND_0)));
+
+DEBUG ((DEBUG_INFO, "\tCR2   0x%08x\n",
+MmioRead32 ((UINTN)Pcie + IATU_REGION_CTRL_2_OFF_OUTBOUND_0)));
+  }
+}
+
+/**
   Function to set-up iATU windows for Layerscape PCIe controller
 
   @param Pcie  Address of PCIe host controller
@@ -396,6 +436,10 @@ PcieLsSetupAtu (
 SEG_IO_BUS,
 SEG_IO_SIZE
 );
+
+  DEBUG_CODE_BEGIN ();
+  LsDumpAtu (Pcie, Index);
+  DEBUG_CODE_END ();
 }
 
 /**
-- 
2.7.4


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

View/Reply Online (#60252): https://edk2.groups.io/g/devel/message/60252
Mute This Topic: https://groups.io/mt/74474410/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 13/16] Silicon/NXP/Drivers: Implement PciCpuIo2Dxe Driver

[Wasim Khan]

From: Wasim Khan 

NXP SoC has multiple PCIe RCs and there is no fix translation
offset between I/O port accesses and MMIO accesses.
Add PciCpuIo2Dxe driver to implement EFI_CPU_IO2_PROTOCOL
to add the translation for different RCs for IO access.

Signed-off-by: Wasim Khan 
Reviewed-by: Ard Biesheuvel 
---

Notes:
V2:
- No change

 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf |  40 ++
 Silicon/NXP/Include/Pcie.h|  19 +
 Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c   | 628 
 3 files changed, 687 insertions(+)

diff --git a/Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf 
b/Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
new file mode 100755
index ..0ee470e41d5e
--- /dev/null
+++ b/Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
@@ -0,0 +1,40 @@
+## @file
+#  Produces the CPU I/O 2 Protocol by using the services of the I/O Library.
+#
+# Copyright 2018, 2020 NXP
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = PciCpuIo2Dxe
+  FILE_GUID  = 7bff18d7-9aae-434b-9c06-f10a7e157eac
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= PciCpuIo2Initialize
+
+[Sources]
+  PciCpuIo2Dxe.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  Silicon/NXP/NxpQoriqLs.dec
+
+[LibraryClasses]
+  BaseLib
+  DebugLib
+  IoLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Pcd]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr
+  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController
+
+[Protocols]
+  gEfiCpuIo2ProtocolGuid ## PRODUCES
+
+[Depex]
+  TRUE
diff --git a/Silicon/NXP/Include/Pcie.h b/Silicon/NXP/Include/Pcie.h
index 210e4c3cf5e7..14cf385df7eb 100755
--- a/Silicon/NXP/Include/Pcie.h
+++ b/Silicon/NXP/Include/Pcie.h
@@ -42,6 +42,25 @@
 #define PCI_SEG0_PHY_MEM64_BASE   PCI_SEG0_MMIO_MEMBASE + SEG_MEM64_BASE
 #define PCI_MMIO64_WIN_SIZE   SIZE_16GB
 #define PCI_SEG0_PHY_IO_BASE  PCI_SEG0_MMIO_MEMBASE + SEG_IO_BASE
+#define PCI_SEG0_PORTIO_MIN   0x0
+#define PCI_SEG0_PORTIO_MAX   0x
+#define PCI_SEG0_PORTIO_OFFSET0x0
+#define PCI_SEG1_PORTIO_MIN   0x0
+#define PCI_SEG1_PORTIO_MAX   0x
+#define PCI_SEG1_PORTIO_OFFSET0x1
+#define PCI_SEG2_PORTIO_MIN   0x0
+#define PCI_SEG2_PORTIO_MAX   0x
+#define PCI_SEG2_PORTIO_OFFSET0x2
+#define PCI_SEG3_PORTIO_MIN   0x0
+#define PCI_SEG3_PORTIO_MAX   0x
+#define PCI_SEG3_PORTIO_OFFSET0x3
+#define PCI_SEG4_PORTIO_MIN   0x0
+#define PCI_SEG4_PORTIO_MAX   0x
+#define PCI_SEG4_PORTIO_OFFSET0x4
+#define PCI_SEG5_PORTIO_MIN   0x0
+#define PCI_SEG5_PORTIO_MAX   0x
+#define PCI_SEG5_PORTIO_OFFSET0x5
+#define PCI_SEG_PORTIO_LIMIT  PCI_SEG5_PORTIO_MAX + PCI_SEG5_PORTIO_OFFSET
 
 // PCIe Controller configuration
 #define NUM_PCIE_CONTROLLER   FixedPcdGet32 (PcdNumPciController)
diff --git a/Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c 
b/Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c
new file mode 100755
index ..17db44a8b510
--- /dev/null
+++ b/Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.c
@@ -0,0 +1,628 @@
+/** @file
+  Produces the CPU I/O 2 Protocol.
+
+  Copyright (c) 2009 - 2012, Intel Corporation. All rights reserved.
+  Copyright (c) 2016, Linaro Ltd. All rights reserved.
+  Copyright 2018-2020 NXP
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_IO_PORT_ADDRESS PCI_SEG_PORTIO_LIMIT
+
+//
+// Handle for the CPU I/O 2 Protocol
+//
+STATIC EFI_HANDLE  mHandle = NULL;
+
+//
+// Lookup table for increment values based on transfer widths
+//
+STATIC CONST UINT8 mInStride[] = {
+  1, // EfiCpuIoWidthUint8
+  2, // EfiCpuIoWidthUint16
+  4, // EfiCpuIoWidthUint32
+  8, // EfiCpuIoWidthUint64
+  0, // EfiCpuIoWidthFifoUint8
+  0, // EfiCpuIoWidthFifoUint16
+  0, // EfiCpuIoWidthFifoUint32
+  0, // EfiCpuIoWidthFifoUint64
+  1, // EfiCpuIoWidthFillUint8
+  2, // EfiCpuIoWidthFillUint16
+  4, // EfiCpuIoWidthFillUint32
+  8  // EfiCpuIoWidthFillUint64
+};
+
+//
+// Lookup table for increment values based on transfer widths
+//
+STATIC CONST UINT8 mOutStride[] = {
+  1, // EfiCpuIoWidthUint8
+  2, // EfiCpuIoWidthUint16
+  4, // EfiCpuIoWidthUint32
+  8, // EfiCpuIoWidthUint64
+  1, // EfiCpuIoWidthFifoUint8
+  2, // EfiCpuIoWidthFifoUint16
+  4, // EfiCpuIoWidthFifoUint32
+  8, // EfiCpuIoWidthFifoUint64
+  0, // EfiCpuIoWidthFillUint8
+  0, // EfiCpuIoWidthFillUint16
+  0, // EfiCpuIoWidthFillUint32
+  0  // EfiCpuIoWidthFillUint64
+};
+
+/**
+  Check parameters to a CPU I/O 2 Protocol service request.
+
+  The I/O operations are carried out exactly as requested. The caller is 
responsible
+  for satisfying any alignment and I/O width restrictions that a PI System on a
+  

[edk2-devel] [PATCH edk2-platforms v2 10/16] Silicon/NXP: PciSegmentLib: Add ECAM config support for PCIe LS Controller

[Wasim Khan]

From: Wasim Khan 

PCIe Layerscape controller can be enabled for ECAM style
configuration access using CFG SHIFT Feature.

Check for PcdPciCfgShiftEnable to decide the configuration access
scheme to be used with PCIe LS controller.

Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Addressed review comment to use (Bus > 0) instead of (Bus)

 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf |  3 +++
 Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c   | 20 
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
index a36e79239b33..936213dc8a9d 100755
--- a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
@@ -30,3 +30,6 @@ [LibraryClasses]
 
 [FixedPcd]
   gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr
+
+[Pcd]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable
diff --git a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c 
b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
index d0bacca3d0d7..e5251ecf0dd8 100755
--- a/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
+++ b/Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.c
@@ -34,6 +34,8 @@ typedef enum {
 #define ASSERT_INVALID_PCI_SEGMENT_ADDRESS(A,M) \
   ASSERT (((A) & (0xf000ULL | (M))) == 0)
 
+static BOOLEAN CfgShiftEnable;
+
 STATIC
 UINT64
 PciLsCfgTarget (
@@ -88,11 +90,20 @@ PciLsGetConfigBase (
 {
   UINT32 CfgAddr;
 
-  CfgAddr = (UINT16)Offset;
-  if (Bus > 0) {
-return PciLsCfgTarget (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment, 
Address, Segment, Bus, Offset);
+  if (CfgShiftEnable) {
+CfgAddr = (UINT32)Address;
+if (Bus > 0) {
+  return PCI_SEG0_MMIO_MEMBASE + PCI_BASE_DIFF * Segment + CfgAddr;
+} else {
+  return PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment + CfgAddr;
+}
   } else {
-return PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment + CfgAddr;
+CfgAddr = (UINT16)Offset;
+if (Bus > 0) {
+  return PciLsCfgTarget (PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment, 
Address, Segment, Bus, Offset);
+} else {
+  return PCI_SEG0_DBI_BASE + PCI_DBI_SIZE_DIFF * Segment + CfgAddr;
+}
   }
 }
 
@@ -608,5 +619,6 @@ PciSegLibInit (
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
+  CfgShiftEnable = CFG_SHIFT_ENABLE;
   return EFI_SUCCESS;
 }
-- 
2.7.4


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

View/Reply Online (#60247): https://edk2.groups.io/g/devel/message/60247
Mute This Topic: https://groups.io/mt/74474404/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 04/16] Silicon/NXP: PciHostBridgeLib: CFG Shift feature support for PCIeLS Ctrl

[Wasim Khan]

From: Wasim Khan 

PCIe layerscape controller supports CFG Shift feature. It can be
enabled by setting BIT[28] of iATU Control 2 Register.
Check PcdPciCfgShiftEnable to enable 'CFG Shift feature' in
PCIe controller.
if enable, PCIe layerscape controller shifts BDF from bits[27:12] to
bits[31:16] and supports Enhanced Configuration Address Mapping (ECAM)
mechanism.

PCIe layerscape controller is ECAM complaint for bus[0x1-0xff].
So create outbound CFG windows from 1MB-256MB (255 buses) for
type0/type1 configuration access.
PCIe layerscape controller is Non-ECAM complaint for bus 0.It does
not support device > 0 on bus 0. PciSegmentLib should handles this
limitation.

Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 
---

Notes:
V2:
- Removed Signed-off and added Co-authored-by for co-author
- Introduced ECAM_BUS_SIZE and ECAM_CFG_REGION_SIZE for CFG
  region size and added comments for same.

 Silicon/NXP/NxpQoriqLs.dec|  3 ++
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf |  3 ++
 Silicon/NXP/Include/Pcie.h|  5 +++
 Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c   | 37 
+++-
 4 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/Silicon/NXP/NxpQoriqLs.dec b/Silicon/NXP/NxpQoriqLs.dec
index 9ff5ce8a1c6e..5358aaeb037e 100644
--- a/Silicon/NXP/NxpQoriqLs.dec
+++ b/Silicon/NXP/NxpQoriqLs.dec
@@ -35,3 +35,6 @@ [PcdsFixedAtBuild.common]
   gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|0|UINT32|0x0501
   gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase|0x0|UINT32|0x0502
   gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg|0x0|UINT32|0x0503
+
+[PcdsDynamic.common]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable|FALSE|BOOLEAN|0x0600
diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
index aa4802b019f6..99807d5beb1f 100644
--- a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
@@ -37,3 +37,6 @@ [FixedPcd]
   gNxpQoriqLsTokenSpaceGuid.PcdNumPciController
   gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase
   gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg
+
+[Pcd]
+  gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable
diff --git a/Silicon/NXP/Include/Pcie.h b/Silicon/NXP/Include/Pcie.h
index 9dbe876b9c1a..f7c18c3aa094 100755
--- a/Silicon/NXP/Include/Pcie.h
+++ b/Silicon/NXP/Include/Pcie.h
@@ -27,6 +27,8 @@
 #define PCI_SEG_PORTIO_MIN0x0
 #define PCI_SEG_PORTIO_MAX0x
 #define SEG_CFG_SIZE  0x1000
+#define ECAM_BUS_SIZE SIZE_1MB
+#define ECAM_CFG_REGION_SIZE  SIZE_256MB
 #define SEG_MEM_BASE  0x4000
 #define SEG_MEM_SIZE  0xC000
 #define SEG_MEM_LIMIT SEG_MEM_BASE + (SEG_MEM_SIZE -1)
@@ -64,6 +66,7 @@
 #define IATU_UPPER_TARGET_ADDR_OFF_OUTBOUND_00x91C
 #define IATU_VIEWPORT_OUTBOUND   0x0
 #define IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN  BIT31
+#define IATU_ENABLE_CFG_SHIFT_FEATUREBIT28
 
 // ATU Programming
 #define IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_MEM   0x0
@@ -77,4 +80,6 @@
 #define SEG_IO_SIZE   0x1
 #define SEG_IO_BUS0x0
 
+#define CFG_SHIFT_ENABLE  (PcdGetBool (PcdPciCfgShiftEnable))
+
 #endif
diff --git a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c 
b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
index 230fcf57690e..9fae19095cba 100644
--- a/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
+++ b/Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c
@@ -259,8 +259,17 @@ PcieOutboundSet (
   MmioWrite32 (Dbi + IATU_REGION_CTRL_1_OFF_OUTBOUND_0,
 (UINT32)Type);
 
-  MmioWrite32 (Dbi + IATU_REGION_CTRL_2_OFF_OUTBOUND_0,
-IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN);
+  if (CFG_SHIFT_ENABLE &&
+ ((Type == IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_CFG0) ||
+ (Type == IATU_REGION_CTRL_1_OFF_OUTBOUND_0_TYPE_CFG1))) {
+   MmioWrite32 (Dbi + IATU_REGION_CTRL_2_OFF_OUTBOUND_0,
+ (IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN |
+ IATU_ENABLE_CFG_SHIFT_FEATURE)
+ );
+  } else {
+MmioWrite32 (Dbi + IATU_REGION_CTRL_2_OFF_OUTBOUND_0,
+  IATU_REGION_CTRL_2_OFF_OUTBOUND_0_REGION_EN);
+  }
 }
 
 /**
@@ -293,12 +302,24 @@ PcieLsSetupAtu (
   UINT64 Mem64End;
   UINT32 Index;
 
-  Cfg0BaseAddr = Cfg0Base;
-  Cfg1BaseAddr = Cfg1Base;
-  Cfg0BusAddress = SEG_CFG_BUS;
-  Cfg1BusAddress = SEG_CFG_BUS;
-  Cfg0Size = SEG_CFG_SIZE;
-  Cfg1Size = SEG_CFG_SIZE;
+  if (CFG_SHIFT_ENABLE) {
+DEBUG ((DEBUG_INFO, "PCIe: CFG Shift Method Enabled \n"));
+Cfg0BaseAddr = Cfg0Base + SIZE_1MB;
+Cfg1BaseAddr = Cfg0Base + SIZE_2MB;
+Cfg0BusAddress = SIZE_1MB;
+Cfg1BusAddress = SIZE_2MB;
+// Region for type0 CFG transactions (only for 

[edk2-devel] [PATCH edk2-platforms v2 15/16] Platform/NXP: LS1043aRdbPkg: Enable PCIE support

[Wasim Khan]

From: Wasim Khan 

Enable generic PCIe drivers and Wire up PciHostBridgeLib,
PciSegmentLib and PciCpuIo2Dxe.

Signed-off-by: Wasim Khan 
---

Notes:
V2:
- No change

 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc | 9 +
 Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf | 7 +++
 2 files changed, 16 insertions(+)

diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
index 8f7f9d171587..6d07d5164002 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc
@@ -35,6 +35,8 @@ [Defines]
 [LibraryClasses.common]
   
ArmPlatformLib|Platform/NXP/LS1043aRdbPkg/Library/ArmPlatformLib/ArmPlatformLib.inf
   RealTimeClockLib|Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
+  PciSegmentLib|Silicon/NXP/Library/PciSegmentLib/PciSegmentLib.inf
+  PciHostBridgeLib|Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf
 
 [PcdsFixedAtBuild.common]
   #
@@ -62,6 +64,13 @@ [Components.common]
   Platform/NXP/LS1043aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf
 
   #
+  # PCI
+  #
+  Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
+  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
+  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
+
+  #
   # Networking stack
   #
 !include NetworkPkg/Network.dsc.inc
diff --git a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf 
b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
index 59691e8c..81142f217a63 100644
--- a/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
+++ b/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.fdf
@@ -124,6 +124,13 @@ [FV.FvMain]
 !include NetworkPkg/Network.fdf.inc
 
   #
+  # PCI
+  #
+  INF Silicon/NXP/Drivers/PciCpuIo2Dxe/PciCpuIo2Dxe.inf
+  INF MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
+  INF MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
+
+  #
   # FAT filesystem + GPT/MBR partitioning
   #
   INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
-- 
2.7.4


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

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

Re: [edk2-devel] [PATCH v8 35/46] OvmfPkg/PlatformPei: Reserve SEV-ES work area if S3 is supported

[Laszlo Ersek]

On 05/19/20 23:51, Lendacky, Thomas wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> Protect the SEV-ES work area memory used by an SEV-ES guest.
> 
> Regarding the lifecycle of the SEV-ES memory area:
>   PcdSevEsWorkArea
> 
> (a) when and how it is initialized after first boot of the VM
> 
>   If SEV-ES is enabled, the SEV-ES area is initialized during
>   the SEC phase [OvmfPkg/ResetVector/Ia32/PageTables64.asm].
> 
> (b) how it is protected from memory allocations during DXE
> 
>   If SEV-ES is enabled, then InitializeRamRegions()
>   [OvmfPkg/PlatformPei/MemDetect.c] protects the ranges with either
>   an AcpiNVS (S3 enabled) or BootServicesData (S3 disabled) memory
>   allocation HOB, in PEI.
> 
> (c) how it is protected from the OS
> 
>   If S3 is enabled, then (b) reserves it from the OS too.
> 
>   If S3 is disabled, then the range needs no protection.
> 
> (d) how it is accessed on the S3 resume path
> 
>   It is rewritten same as in (a), which is fine because (b) reserved it.
> 
> (e) how it is accessed on the warm reset path
> 
>   It is rewritten same as in (a).
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/PlatformPei/PlatformPei.inf |  2 ++
>  OvmfPkg/PlatformPei/MemDetect.c | 20 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index 4742e1bdf42b..c53be2f4925c 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -118,6 +118,8 @@ [FixedPcd]
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData
> +  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaBase
> +  gUefiCpuPkgTokenSpaceGuid.PcdSevEsWorkAreaSize
>  
>  [FeaturePcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdCsmEnable
> diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
> index 6b5fee166b5d..ffbbef891a11 100644
> --- a/OvmfPkg/PlatformPei/MemDetect.c
> +++ b/OvmfPkg/PlatformPei/MemDetect.c
> @@ -940,5 +940,25 @@ InitializeRamRegions (
>);
>}
>  }
> +
> +#ifdef MDE_CPU_X64
> +if (MemEncryptSevEsIsEnabled ()) {
> +  //
> +  // If SEV-ES is enabled, reserve the SEV-ES work area.
> +  //
> +  // Since this memory range will be used by the Reset Vector on S3
> +  // resume, it must be reserved as ACPI NVS.
> +  //
> +  // If S3 is unsupported, then various drivers might still write to the
> +  // work area. We ought to prevent DXE from serving allocation requests
> +  // such that they would overlap the work area.
> +  //
> +  BuildMemoryAllocationHob (
> +(EFI_PHYSICAL_ADDRESS)(UINTN) FixedPcdGet32 (PcdSevEsWorkAreaBase),
> +(UINT64)(UINTN) FixedPcdGet32 (PcdSevEsWorkAreaSize),
> +mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData
> +);
> +}
> +#endif
>}
>  }
> 

Reviewed-by: Laszlo Ersek 


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

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

[edk2-devel] Using debugger to debug UEFI application?

[David F.]

Hi,

I just found the Intel UDK debugger and hopping to use it to debug my UEFI 
application.  Basically, the function ippsEncodeLZ77DynamicHuff_8u in Intel IPP 
7 (tried 7.1 as well) used in my application will hang if secure boot is 
enabled on most systems (disabled runs fine - someone with vmware workstation 
15 sees same thing as physical system - I can't enable vmware secure boot 
because not running system in UEFI mode) - the source is shared with 
dos/linux/windows and all those work fine.  I'm not sure why it hangs in that 
case, exception? stack? nothing I tried to do like force the stack size helped.

So using this Lenovo laptop sitting next to me, can I use this Intel UDK 
debugger to connect via USB crossover cable  and debug the application.  I 
don't want to spend a bunch of time to only find out you can't do that and need 
special hardware.  If not going to work then I'll have to spend time 
disassembling the application, injecting things in to the 
ippsEncodeLZ77DynamicHuff_8u to see what' up (a lot more work).

Anyone feel free to chime in on what you think may be causing a problem when 
secure boot is enabled?

TIA!!

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

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

Re: [edk2-devel] Updating to latest EDK2 and now get NMAKE: fatal error U1073: Don't know how to make.. on some items?

[David F.]

Let me start by what I did to get the build working with the old BaseTools.   I 
renamed BaseTools and put back the prior BaseTools from Nov 29 2018 (build.exe 
date).  It started building out of the gate, then hit nasm.inc not found, so 
digging around end up comparing old and new for things and brought over new 
NASM items from new GenMake.py to the old one.  Tried again, same thing, ended 
up fixing by bringing over the new build_rule.txt.  Now everything is building 
fine using VS2008 but the old BaseTools.

I can try using VS2017, I though I was staying with VS2008 is VS2017 added more 
behind the scenes stuff that I have to add replacements for (already have what 
I need for VS2008).  But I really don't remember. I'll do that when I get a 
chance once I catch up on things.

Okay, now on to Guomin message,  Those messages are saying it's not in the 
.inf, which looking in the .inf, they are not.  Although the headers themselves 
exist.  I got the edk2-libc repo from GIT.  The edk2 repo I still use svn 
update to update it.  Using tortoise tools on windows.

Thanks.

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

View/Reply Online (#60242): https://edk2.groups.io/g/devel/message/60242
Mute This Topic: https://groups.io/mt/74462877/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 01/16] Silicon/NXP/NxpQoriqLs.dec: Add PCIe related PCDs.

[Ard Biesheuvel]

On 5/24/20 8:31 PM, Wasim Khan (OSS) wrote:




-Original Message-
From: Ard Biesheuvel 
Sent: Friday, May 22, 2020 2:42 PM
To: Wasim Khan (OSS) ; devel@edk2.groups.io;
Meenakshi Aggarwal ; Vabhav Sharma
; Varun Sethi ;
l...@nuviainc.com; j...@solid-run.com
Cc: Wasim Khan 
Subject: Re: [PATCH edk2-platforms 01/16] Silicon/NXP/NxpQoriqLs.dec: Add
PCIe related PCDs.

On 5/22/20 1:02 AM, Wasim Khan wrote:

From: Wasim Khan 

Add PCIe related PCDs.

Signed-off-by: Vabhav Sharma 


Please drop this signoff. This is not the correct way to acknowledge (co-
)authorship.


Co-authored-by: Vabhav Sharma 
Co-authored-by: Wasim Khan 
Signed-off-by: Wasim Khan 

Is this OK ?



Yes that is fine.




Signed-off-by: Wasim Khan 
---
   Silicon/NXP/NxpQoriqLs.dec | 9 +
   1 file changed, 9 insertions(+)

diff --git a/Silicon/NXP/NxpQoriqLs.dec b/Silicon/NXP/NxpQoriqLs.dec
index 0722f59ef4f6..bafdfd9f4298 100644
--- a/Silicon/NXP/NxpQoriqLs.dec
+++ b/Silicon/NXP/NxpQoriqLs.dec
@@ -27,3 +27,12 @@ [Guids.common]
   [PcdsFeatureFlag]


gNxpQoriqLsTokenSpaceGuid.PcdI2cErratumA009203|FALSE|BOOLEAN|0x
0315




gNxpQoriqLsTokenSpaceGuid.PcdDcfgBigEndian|FALSE|BOOLEAN|0x0316

+
+

gNxpQoriqLsTokenSpaceGuid.PcdPciLutBigEndian|FALSE|BOOLEAN|0x031

+ 7
+
+[PcdsFixedAtBuild.common]
+  # Pcds for PCI Express
+

gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr|0x0|UINT64|0x0500

+  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|0|UINT32|0x0501
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase|0x0|UINT32|0x0502
+  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg|0x0|UINT32|0x0503
+  gNxpQoriqLsTokenSpaceGuid.PcdPciDebug|FALSE|BOOLEAN|0x0504






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

View/Reply Online (#60241): https://edk2.groups.io/g/devel/message/60241
Mute This Topic: https://groups.io/mt/74395372/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 1/1] NetworkPkg/HttpBootDxe: handle servers which may FIN after file sizing in HttpBootLoadFile

[Andrei Warkentin]

Hi Maciej,

Thanks for your analysis.

The way I see it, there are many people out there expecting HttpBoot to work 
with the Python server - which without manual hacking is HTTP/1.0 and not 
HTTP/1.1. I think it's fine to reject 1.0 but then HttpBoot should explicitly 
reject 1.0 with an appropriate message and *refuse* to boot. Today it's in the 
area where it may work and may not.

1.1 vs 1.0 aside, don't you think there should be a bit of resiliency to the 
client? As it stands right now, an arbitrary FIN  between the requests gets the 
user an "unexpected network error" (or similar), with no clear indication it's 
a server misconfiguration, a network error (which one?) or some such. With that 
in mind I see the proposed fix as being a lesser evil (friendly to end user) 
than creating a pedantic HttpBoot client which will fail because it doesn't 
operate in an ideal environment.

What do you think?

A

From: devel@edk2.groups.io  on behalf of Maciej Rabeda 
via groups.io 
Sent: Monday, May 25, 2020 7:49 AM
To: devel@edk2.groups.io ; andrey.warken...@gmail.com 

Cc: jiaxin...@intel.com ; siyuan...@intel.com 

Subject: Re: [edk2-devel] [edk2][PATCH 1/1] NetworkPkg/HttpBootDxe: handle 
servers which may FIN after file sizing in HttpBootLoadFile

Copying my comments from Bugzilla:

I have gone through the Wireshark trace that you have provided. It seems to be 
all clear now and the approach to the issue must change.

HttpBootDxe supports HTTP 1.1 and assumes that the HTTP session stays 
persistent (single TCP connection for multiple requests instead of one for each 
HTTP request/response pair). 
https://en.wikipedia.org/wiki/HTTP_persistent_connection

I am hesitant to introduce HTTP/1.0 keep-alive additions to the header. Kindly 
request more debugging on Python server side whether to confirm that 
implementation you are using supports HTTP/1.1.

>From what I see in here: 
>https://github.com/python/cpython/blob/master/Lib/http/server.py

http.server has support for HTTP/1.1 and assumption on not closing the 
connection. At the time of writing this comment, it is line 311:

if version_number >= (1, 1) and self.protocol_version >= "HTTP/1.1":
self.close_connection = False

Putting the patch on hold (with trend for rejecting with no support for 
HTTP/1.0 keep-alive).

Additional comment:

https://github.com/python/cpython/blob/master/Lib/http/server.py

Line 616:

# The version of the HTTP protocol we support.
# Set this to HTTP/1.1 to enable automatic keepalive
protocol_version = "HTTP/1.0"

Please modify it that variable to "HTTP/1.1". Your scenario should start 
working.

Please come back to me with confirmation.


Thanks,
Maciej

On 22-May-20 21:46, Andrei Warkentin wrote:

This is v2 with Maciej Rabeda's feedback.

Python http.server seems to FIN after the first HEAD request to size
the loaded file is completed and ACKed. What happens next is interesting.
On low latency connections, the GET request to download may get sent
after the server sends the FIN but before the client has a chance to
process it. The net result is:
- Server ignores GET
- HttpBootLoadFile returns EFI_CONNECTION_FIN. Boot fails.

In the other case, client handles the FIN before attempting the GET,
so there's a proper three-way handshake as part of GET.

The solution is to retry HttpBootLoadFile 2 times if it returns
EFI_CONNECTION_FIN. This is because HttpBootLoadFile may issue up to
3 requests: HEAD/GET to get size and final GET to load. Some servers
may send a FIN after each request. The first request (HEAD) is not
supposed to fail this way, so only the two subsequent GET request
may result in a FIN.

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

This