Re: [edk2-devel] [PATCH edk2-platforms 1/5] Silicon/NXP/LS1043A: Fix the Platform PLL calculation

[Pankaj Bansal]

Hi Leif,

Sorry for late reply.
Actually I had asked the design team to check this point.
I am waiting for their reply.
I will add comments in code based on their reply and send new version.

Regards,
Pankaj Bansal

> -Original Message-
> From: Leif Lindholm 
> Sent: Friday, June 12, 2020 8:41 PM
> To: Pankaj Bansal (OSS) 
> Cc: Meenakshi Aggarwal ; Michael D Kinney
> ; devel@edk2.groups.io; Varun Sethi
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Augustine Philips ; Ard
> Biesheuvel ; Arokia Samy
> ; kuldip dwivedi
> 
> Subject: Re: [PATCH edk2-platforms 1/5] Silicon/NXP/LS1043A: Fix the Platform
> PLL calculation
> 
> Hi Pankaj,
> 
> Apologies for delay in responding, this message got lost from my inbox.
> On a sidenote, I think this has something to do with the email
> moderation. Could you possibly subscribe the @oss.nxp.com address to
> the list? You can set it not to deliver email, under
> https://edk2.groups.io/g/devel/editsub, but I can't whitelist
> addresses that are not subscribed.
> 
> On Mon, Jun 08, 2020 at 19:56:35 +, Pankaj Bansal (OSS) wrote:
> > > > > OK, now I'm confused.
> > > > > DCFG is read using the DcfgRead32 function, which is supposed to
> > > > > handle the endianness issue.
> > > > >
> > > > > Ls1043a builds with
> > > > >   gNxpQoriqLsTokenSpaceGuid.PcdDcfgBigEndian|TRUE
> > > > > which means GetMmioOperations() returns the byte-swapping versions.
> > > > >
> > > > > Please clarify.
> > > >
> > > > OK. so this might be little confusing, so bear with me.
> > > > The reset configuration word (RCW) is 512 bits (1024 bits in LS2088
> > > > / LS2160) long and contains all necessary configuration information
> > > > for the chip. RCW data is read from external memory (Nor flash or
> > > > SD/eMMC card or I2c eeprom) and written to the RCW status registers
> > > > (RCWSR) contained in the Device Configuration and Pin Control module
> > > > (DCSR), after which the device is configured as specified in the
> > > > RCW.
> > > >
> > > > The PreBoot Loader (PBL) fetches RCW data from the source memory
> > > > device and writes it to the RCW status registers.
> > > > Now the PBL fetches the data from flash in little endian format and
> > > > writes it to the DCSR registers in little endian format always.
> > > > This steps is same for all SOCs (LX2160 / LS1043 / LS1046 / LS2088).
> > >
> > > This PBL is a ROM executing before the EDK2 code?
> >
> > Yes
> >
> > >
> > > > Now in SOCs where DCSR space is big endian (LS1043 / LS1046), we
> > > > read the RCWSR registers in big endian fashion.
> > > > This causes the bit position to be reversed.
> > >
> > > I'm still not following.
> > >
> > > We've set up this elaborate Rube Goldberg machine to be able to *not*
> > > have to carry separate header files for devices with individual
> > > components with registers that may be big- or little-endian depending
> > > on which SoC/version they are in.
> > >
> > > And now we have an implementation that states that its DcfgRead
> > > operations need to happan as big-endian. And the *only* time the Dcfg
> > > registers are accessed, we immediately need to change the header file
> > > to treat it as little-endian?
> >
> > The RCW Status registers are a special case and a subset of DCFG
> > address space. The whole DCFG address space is big endian itself,
> > and should be read as such.
> 
> So the RCW status registers are in effect just temporary storage for
> data, as opposed to having any effect on the hw? Whereas other parts
> of DCFG *do* affect (and reflect) hw, and are big-endian?
> 
> If so, ok, I understand. And I think your platform designers owe me
> (and you, if so inclined) a beer.
> 
> > if it makes more sense, then I can swap the RCW status registers
> > after being read from DCFG space.
> > And I can put the explanation I wrote above in the code where I swap
> > RCW SR registers ?
> 
> Yes, I think manually swapping the words make more sense. This is a
> *weird* thing - it helps to call it out explicitly rather than try to
> make it look normal.
> 
> Please do that, and drop the .h change, and I'm happy with that.
> 
> > > What is the situation where Dcfg accesses *need* to be big-endian?
> >
> > Apart from RCWSR registers the DCFG space contains following
> > registers as well, which we need to access in boot firmware:
> >
> > - SVR (SOC Version Register)
> > - to retrieve Core and Cluster Information (which I plan to send shortly)
> > - To set the ICID of DMA connected devices like USB, SATA, SD/EMMC
> > - to retrieve the clock frequency of serial flash controller (qspi/flexspi)
> 
> Understood - thanks!
> 
> /
> Leif

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

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

Re: [edk2-devel] [PATCH v2 0/2] IntelFsp2Pkg: Add FSP*_ARCH_UPD.

[Nate DeSimone]

For the series...

Reviewed-by: Nate DeSimone 

On 6/18/20, 6:28 AM, "Chiu, Chasel"  wrote:

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

Introduce FSPT_ARCH_UPD and FSPS_ARCH_UPD to support debug events
and multi-phase silicon initialization.

In V2 backward compatibility support is added, the original
structures are kept and new ARCH_UPD structures will be
included only when UPD header revision equal or greater than 2.

GenCfgOpt script also updated to prevent from generating duplicate
FSPT_ARCH_UPD and FSPS_ARCH_UPD typedef structures.

Cc: Maurice Ma 
Cc: Nate DeSimone 
Cc: Star Zeng 
Signed-off-by: Chasel Chiu 

Chasel Chiu (2):
  IntelFsp2Pkg: Add FSP*_ARCH_UPD.
  IntelFsp2WrapperPkg: Add FSP*_ARCH_UPD.

 
IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c 
| 26 --
 IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm 
| 78 
+-
 IntelFsp2Pkg/Include/FspEas/FspApi.h   
| 81 
-
 IntelFsp2Pkg/Tools/GenCfgOpt.py
|  6 +++---
 4 files changed, 180 insertions(+), 11 deletions(-)

-- 
2.13.3.windows.1



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

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

Re: [edk2-devel] [PATCH v2 0/2] AMD procesor MSR_IA32_MISC_ENABLE

[Dong, Eric]

Hi Garrett,

I create a pull request to verify your changes and it reports some errors for 
your changes. 
https://github.com/tianocore/edk2/pull/710

please help to resolve these errors before sending your new version changes, 
also you can create your PR to verify your new changes.

Thanks,
Eric

> -Original Message-
> From: Garrett Kirkendall 
> Sent: Thursday, June 18, 2020 11:23 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric ; Ni, Ray ; Laszlo
> Ersek 
> Subject: [PATCH v2 0/2] AMD procesor MSR_IA32_MISC_ENABLE
> 
> AMD processor does not support MSR_IA32_MISC_ENABLE register.
> Accessing this register on AMD causes an unhandled exception in
> SmmEntry.nasm and a subsequent failure to boot since this is too early in
> SMM path for the exception handler to be loaded.
> 
> First, to distinguish between AMD and other processors, refactor
> StandardSignatureIsAuthenticAMD into BaseUefiCpuLib.  So there is only one
> copy in the source. All changed modules already include UefiCpuLib either
> directly or indirectly so could not easly split first patch.
> 
> Second, Skip manipulation of MSR_IA32_MISC_ENABLE register if running on
> an AMD processor.
> 
> Tested on AMD X64 hardware.
> OvmfIa32 and OvmfIa32X64 on Intel hardware.
> 
> Garrett Kirkendall (2):
>   UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to BaseUefiCpuLib
>   UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE
> manipulation on
> AMD
> 
>  UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf |  7 
>  UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf |  2 ++
>  UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf |  2 ++
>  UefiCpuPkg/Include/Library/UefiCpuLib.h  | 14 
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h   |  3 ++
>  UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c   | 38
> 
>  UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c   | 25 
> ++---
>  UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c   | 25 ++--
> -
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 
> 
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c   |  9 -
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 19
> --
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm  | 20
> +--
>  12 files changed, 113 insertions(+), 74 deletions(-)  create mode 100644
> UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c
> 
> Changes at:
> https://github.com/gkirkendall-
> amd/edk2/tree/smmentry_nasm_skip_msr_xd_bit_on_amd_v2
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Garrett Kirkendall 
> 
> --
> 2.27.0


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

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

Re: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI external definitions for RISC-V assembly build

[Yuwei Chen]

Hi, Abner

The patch looks good.

Thanks,
Yuwei

> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist) 
> Sent: Thursday, June 18, 2020 9:41 AM
> To: devel@edk2.groups.io; Chen, Yuwei 
> Cc: Feng, Bob C ; Gao, Liming
> ; Schaefer, Daniel (DualStudy)
> ; Leif Lindholm 
> Subject: RE: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI
> external definitions for RISC-V assembly build
> 
> Sure YuWei,  v2 patch is sent.
> 
> Thanks
> Abner
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Yuwei Chen
> > Sent: Wednesday, June 17, 2020 4:51 PM
> > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > 
> > Cc: Feng, Bob C ; Gao, Liming
> > ; Schaefer, Daniel (DualStudy)
> > ; Leif Lindholm 
> > Subject: Re: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI
> > external definitions for RISC-V assembly build
> >
> > Hi, abner
> >
> > I have a little suggestion for the patch format, it would be better if
> > the length of each commit line is less than 70 characters.
> > You can follow the Commit Message Format in the wiki of tianocore.
> >
> > Thanks,
> > Yuwei
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of
> Abner
> > > Chang
> > > Sent: Friday, June 12, 2020 9:57 AM
> > > To: devel@edk2.groups.io
> > > Cc: abner.ch...@hpe.com; Feng, Bob C ; Gao,
> > > Liming ; Daniel Schaefer
> > > ; Leif Lindholm 
> > > Subject: [edk2-devel] [BaseTools PATCH v1] BaseTools: Add OpenSBI
> > > external definitions for RISC-V assembly build
> > >
> > > Add opensbi external definitions to RISC-V build for assembly code.
> > > Use GCC5_RISCV_OPENSBI_TYPES to refer to edk2 data type for
> assembly
> > > files instead of using opensbi data type.
> > >
> > > Signed-off-by: Abner Chang 
> > >
> > > Cc: Bob Feng 
> > > Cc: Liming Gao 
> > > Cc: Daniel Schaefer 
> > > Cc: Leif Lindholm 
> > > ---
> > >  BaseTools/Conf/tools_def.template | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/BaseTools/Conf/tools_def.template
> > > b/BaseTools/Conf/tools_def.template
> > > index 923517b5c2..8aeb8a2a64 100755
> > > --- a/BaseTools/Conf/tools_def.template
> > > +++ b/BaseTools/Conf/tools_def.template
> > > @@ -2037,6 +2037,7 @@ DEFINE GCC5_RISCV64_CC_FLAGS   =
> > > DEF(GCC5_RISCV_ALL_CC_FLAGS) DEF(GC
> > >  DEFINE GCC5_RISCV64_DLINK_FLAGS=
> > > DEF(GCC5_RISCV_ALL_DLINK_FLAGS) -Wl,-melf64lriscv,--oformat=elf64-
> > > littleriscv,--no-relax DEFINE GCC5_RISCV64_DLINK2_FLAGS   =
> > > DEF(GCC5_RISCV_ALL_DLINK2_FLAGS) DEFINE
> > GCC5_RISCV64_ASM_FLAGS =
> > > DEF(GCC5_RISCV_ALL_ASM_FLAGS) -march=DEF(GCC5_RISCV64_ARCH)
> -
> > > mcmodel=medany -mabi=lp64+DEFINE GCC_PP_FLAGS= -E 
> > > -x
> > > assembler-with-cpp -include AutoGen.h
> DEF(GCC5_RISCV_OPENSBI_TYPES)
> > >
> >
> ##
> > > ## #--
> > > 2.25.0
> > >
> > >
> > > -=-=-=-=-=-=
> > > Groups.io Links: You receive all messages sent to this group.
> > >
> > > View/Reply Online (#61183):
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__edk2.groups.io_g_
> > >
> >
> devel_message_61183=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_SN
> > 6FZBN4Vgi4U
> > >
> >
> lkskz6qU3NYRO03nHp9P7Z5q59A3E=HQziIqz4xGRFswhRjSdNcWvHjUyN5
> > ERpayXlIA
> > > wzXVQ=zErLdJ3LY3S3GTWvOAUkqNPWIFoCzpYBs1z5cDrsVCY=
> > > Mute This Topic:
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__groups.io_mt_7483
> > >
> >
> 2499_4546272=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_SN6FZBN4V
> > gi4Ulkskz6q
> > >
> >
> U3NYRO03nHp9P7Z5q59A3E=HQziIqz4xGRFswhRjSdNcWvHjUyN5ERpayXl
> > IAwzXVQ
> > > =UG89s-i8w3cuIc12SggVYjjyUFkm-qVV0jHf1QBpgJc=
> > > Group Owner: devel+ow...@edk2.groups.io
> > > Unsubscribe:
> > > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__edk2.groups.io_g_
> > >
> >
> devel_unsub=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_SN6FZBN4Vgi
> > 4Ulkskz6qU
> > >
> >
> 3NYRO03nHp9P7Z5q59A3E=HQziIqz4xGRFswhRjSdNcWvHjUyN5ERpayXlI
> > AwzXVQ=
> > > fL7a3sHzOxEGfYK7Nw8RAwRqQhjuOfNdhjyiGAlamyc=
> > > [yuwei.c...@intel.com] -=-=-=-=-=-=
> >
> >
> > 
> 


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

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

Re: [edk2-devel] [patch] MdeModulePkg/DisplayEngine: Add Debug message to show mismatch menu info

[Dong, Eric]

Hi Dandan,

Thanks for your detail explanation, add my comments below.

Thanks,
Eric
From: Bi, Dandan 
Sent: Thursday, June 18, 2020 4:39 PM
To: Dong, Eric ; devel@edk2.groups.io
Cc: Gao, Liming 
Subject: RE: [patch] MdeModulePkg/DisplayEngine: Add Debug message to show 
mismatch menu info

Hi Eric,

For example:

For one of, if its current value is 4, but there is no option with value 4, 
then it will pop up mismatch window and the debug message like below.
[DisplayEngine]: Mismatch Error: Current value not exists in the option 
list. <= it's better to add this line to show an 
overview of error info.
[DisplayEngine]: Mismatch Formset: Formset Guid = 
9E0C30BC-3F06-4BA6-8288-09179B855DBE.   Formset title = ""<= 
Title also needs if save happen in system level.
[DisplayEngine]: Mismatch Form : FormId = 4096,  Form title = Front 
Page.
[DisplayEngine]: Mismatch OneOf  : Named = Select Language.
[DisplayEngine]: Mismatch OneOf  : Current value = 4.
[DisplayEngine]: Option 0 : Option Name = Standard English. 
Option Value = 0.
[DisplayEngine]: Option 1 : Option Name = Standard 
Franτais. Option Value = 1.
[DisplayEngine]: Option 2 : Option Name = English. Option 
Value = 2.
[DisplayEngine]: Option 3 : Option Name = Franτais. Option 
Value = 3.

For OrderedList, its value is in the type of array, if one of array value is 4, 
but there is no option with value 4, then it will pop up mismatch window and 
the debug message like below.
[DisplayEngine]: Mismatch Error: Current one value not exists in 
the option list. <= same as above reason, you can 
provide better words if you have.
[DisplayEngine]: Mismatch Formset   : Formset Guid = 
A04A27F4-DF00-4D42-B552-39511302113D. Formset title = ""<= 
Title also needs if save happen in system level.
[DisplayEngine]: Mismatch Form: FormId = 1,  Form title = My First 
Setup Page.
[DisplayEngine]: Mismatch OrderedList: Name = Boot Order.
[DisplayEngine]: Mismatch OrderedList: Value Arrary:

Value[0] =4.

Value[1] =1.

Value[2] =3.

Value[3] =0.

Value[4] =0.

Value[5] =0.

Value[6] =0.

Value[7] =0.
[DisplayEngine]: Option 0: Option Name = ATAPI CD. 
Option Value = 2.
[DisplayEngine]: Option 1: Option Name = IDE HDD. 
Option Value = 1.
[DisplayEngine]: Option 2: Option Name = PXE. Option 
Value = 3.


Thanks,
Dandan
> -Original Message-
> From: Dong, Eric mailto:eric.d...@intel.com>>
> Sent: Thursday, June 18, 2020 2:28 PM
> To: Bi, Dandan mailto:dandan...@intel.com>>; 
> devel@edk2.groups.io
> Cc: Gao, Liming mailto:liming@intel.com>>
> Subject: RE: [patch] MdeModulePkg/DisplayEngine: Add Debug message to
> show mismatch menu info
>
> Hi Dandan,
>
> It's good to show more info about the mismatch error. Current end user
> doesn't know which question need to check if this error appears.
>
> Can you post an example about the error message for one of and for
> ordered list? We need to make sure the message is easy to be understood
> and the end user knows what need to do to fix this error.
>
> Thanks,
> Eric
>
> > -Original Message-
> > From: Bi, Dandan mailto:dandan...@intel.com>>
> > Sent: Thursday, June 18, 2020 11:24 AM
> > To: devel@edk2.groups.io
> > Cc: Gao, Liming mailto:liming@intel.com>>; Dong, 
> > Eric
> > mailto:eric.d...@intel.com>>
> > Subject: [patch] MdeModulePkg/DisplayEngine: Add Debug message to
> show
> > mismatch menu info
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2326
> >
> > Currently when meet mismatch case for one-of and ordered-list menu,
> > just show a popup window to indicate mismatch, no more info for
> debugging.
> > This patch is to add more debug message about mismatch menu info which
> > is helpful to debug.
> >
> > Cc: Liming Gao mailto:liming@intel.com>>
> > Cc: Eric Dong mailto:eric.d...@intel.com>>
> > Signed-off-by: Dandan Bi mailto:dandan...@intel.com>>
> > ---
> >  .../DisplayEngineDxe/ProcessOptions.c | 78 +++
> >  1 file changed, 78 insertions(+)
> >
> > diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> > 

Re: [edk2-devel] Build error for UefiPayloadPkgIa32.dsc

[Guo Dong]

Thanks Pierre to report this build failure.
The failure is caused by FV size increase when using build parameter "-b NOOPT".
Given this build option would almost double the build size and it is  seldom 
used, I prefer you update the FDF file to increase the FV size to solve it 
locally.

BTW, from your build command, you are trying to build a pure IA32 UEFI payload 
image,  are you still using pure IA32 UEFI payload?
I ask this question because I plan to add pure X64 UEFI payload support and 
drop pure IA32 UEFI payload if possible.
Of course UEFI payload will continue support IA32 entrypoint and switch to X64 
before DXE core.

Thanks,
Guo

From: devel@edk2.groups.io  On Behalf Of PierreGondois
Sent: Thursday, June 18, 2020 7:55 AM
To: Ma, Maurice ; Dong, Guo ; You, 
Benjamin ; devel@edk2.groups.io; nd 
Subject: [edk2-devel] Build error for UefiPayloadPkgIa32.dsc

Hello,
I am not actively using this platform, but I wanted to report an error when 
building one of the DSC files in the UefiPayloadPkg with the following 
configuration:
build -b NOOPT -a IA32 -t VS2017 -p edk2 
edk2\UefiPayloadPkg\UefiPayloadPkgIa32.dsc

The following error occurs:
Generating PEIFV FV
 ['GenFv', '-a', 
'Build\\UefiPayloadPkgIA32\\NOOPT_VS2017\\FV\\Ffs\\PEIFV.inf', '-o', 
'Build\\UefiPayloadPkgIA32\\NOOPT_VS2017\\FV\\PEIFV.Fv', '-i', 
Build\\UefiPayloadPkgIA32\\NOOPT_VS2017\\FV\\PEIFV.inf']
Return Value = 2
GenFv: ERROR 3000: Invalid
the required fv image size 0x406c8 exceeds the set fv image size 0x3

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

[edk2-devel] Does anyone know the history of LzmaF86Compress.bat?

[Andrew Fish via groups.io]

I can’t understand why we have LzmaF86Compress.bat that gets copied by the 
nmake file.

BaseTools/Conf/tools_def.template
*_*_*_LZMAF86_PATH = LzmaF86Compress

It would work for all toolchains if we did this:
*_*_*_LZMAF86_FLAGS= --f86
*_*_*_LZMAF86_PATH   = LzmaCompress

I tried it with Xcode (clang should work this way too) and it saved about 4.65% 
in DXE FV and 1% in the PEI FV. 

I also noticed for a very small size penalty you could support 
gLzmaF86CustomDecompressGuid and gLzmaCustomDecompressGuid at the same time. 
Most of the code is common and LzmaF86 just calls x86_Convert_Init() and 
x86_Convert() to post process the buffer. 

Thanks,

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

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

Re: [edk2-devel] [PATCH v4 1/1] ProcessorPkg/Library: Add RiscVEdk2SbiLib

[Leif Lindholm]

On Tue, Jun 02, 2020 at 18:51:52 +0200, Daniel Schaefer wrote:
> Library provides interfaces to invoke SBI ecalls.
> 
> Signed-off-by: Daniel Schaefer 

All of my feedback on previous revision addressed - where to actually
*merge* it remains undecided, but for the contents:
Reviewed-by: Leif Lindholm 

Thanks!

> Cc: Leif Lindholm 
> Cc: Gilbert Chen 
> Cc: Abner Chang 
> Cc: Michael D. Kinney 
> ---
>  Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf |  
> 28 +
>  Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h   | 
> 563 
>  Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c   | 
> 897 
>  3 files changed, 1488 insertions(+)
> 
> diff --git 
> a/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf 
> b/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf
> new file mode 100644
> index ..665dcbf40e01
> --- /dev/null
> +++ b/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.inf
> @@ -0,0 +1,28 @@
> +## @file
> +# RISC-V Library to call SBI ecalls
> +#
> +#  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x0001001b
> +  BASE_NAME  = RiscVEdk2SbiLib
> +  FILE_GUID  = 0DF1BBBD-F7E5-4E8A-BCF1-9D63D2DD9FDD
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = RiscVEdk2SbiLib
> +
> +[Sources]
> +  RiscVEdk2SbiLib.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  Silicon/RISC-V/ProcessorPkg/RiscVProcessorPkg.dec
> +  Platform/RISC-V/PlatformPkg/RiscVPlatformPkg.dec
> +
> +[LibraryClasses]
> +  BaseLib
> +  RiscVOpensbiLib
> diff --git a/Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h 
> b/Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h
> new file mode 100644
> index ..c1ae3176147f
> --- /dev/null
> +++ b/Silicon/RISC-V/ProcessorPkg/Include/Library/RiscVEdk2SbiLib.h
> @@ -0,0 +1,563 @@
> +/** @file
> +  Library to call the RISC-V SBI ecalls
> +
> +  Copyright (c) 2020, Hewlett Packard Development LP. All rights 
> reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +  @par Glossary:
> +- Hart - Hardware Thread, similar to a CPU core
> +**/
> +
> +#ifndef RISCV_SBI_LIB_H_
> +#define RISCV_SBI_LIB_H_
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +//
> +// EDK2 OpenSBI Firmware extension.
> +//
> +#define SBI_EDK2_FW_EXT (SBI_EXT_FIRMWARE_CODE_BASE_START | 
> SBI_OPENSBI_IMPID)
> +//
> +// EDK2 OpenSBI Firmware extension functions.
> +//
> +#define SBI_EXT_FW_MSCRATCH_FUNC0
> +#define SBI_EXT_FW_MSCRATCH_HARTID_FUNC 1
> +
> +//
> +// EDK2 OpenSBI firmware extension return status.
> +//
> +typedef struct {
> +  UINTN Error;   ///< SBI status code
> +  UINTN Value;   ///< Value returned
> +} SbiRet;
> +
> +/**
> +  Get the implemented SBI specification version
> +
> +  The minor number of the SBI specification is encoded in the low 24 bits,
> +  with the major number encoded in the next 7 bits.  Bit 32 must be 0 and is
> +  reserved for future expansion.
> +
> +  @param[out] SpecVersion  The Version of the SBI specification.
> +**/
> +VOID
> +EFIAPI
> +SbiGetSpecVersion (
> +  OUT UINTN   *SpecVersion
> +  );
> +
> +/**
> +  Get the SBI implementation ID
> +
> +  This ID is used to idenetify a specific SBI implementation in order to work
> +  around any quirks it might have.
> +
> +  @param[out] ImplId   The ID of the SBI implementation.
> +**/
> +VOID
> +EFIAPI
> +SbiGetImplId (
> +  OUT UINTN  *ImplId
> +  );
> +
> +/**
> +  Get the SBI implementation version
> +
> +  The version of this SBI implementation.
> +  The encoding of this number is determined by the specific SBI 
> implementation.
> +
> +  @param[out] ImplVersion  The version of the SBI implementation.
> +**/
> +VOID
> +EFIAPI
> +SbiGetImplVersion (
> +  OUT UINTN   *ImplVersion
> +  );
> +
> +/**
> +  Probe whether an SBI extension is available
> +
> +  ProbeResult is set to 0 if the extension is not available or to an 
> extension
> +  specified value if it is available.
> +
> +  @param[in]  ExtensionId  The extension ID.
> +  @param[out] ProbeResult  The return value of the probe.
> +**/
> +VOID
> +EFIAPI
> +SbiProbeExtension (
> +  IN  INTN ExtensionId,
> +  OUT INTN*ProbeResult
> +  );
> +
> +/**
> +  Get the CPU's vendor ID
> +
> +  Reads the mvendorid CSR.
> +
> +  @param[out] MachineVendorId  The CPU's vendor ID.
> +**/
> +VOID
> +EFIAPI
> +SbiGetMachineVendorId (
> +  OUT UINTN   *MachineVendorId
> +  );
> +
> +/**
> +  Get the CPU's architecture ID
> +
> +  Reads the marchid CSR.
> +
> +  @param[out] MachineArchIdThe CPU's architecture ID.
> +**/
> 

Re: [edk2-devel] [PATCH edk2-platforms 2/8] Silicon/NXP: Chassis2: define SVR macros

[Leif Lindholm]

On Thu, Jun 18, 2020 at 09:59:28 +, Wasim Khan (OSS) wrote:
> 
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Wednesday, June 17, 2020 8:24 PM
> > To: Wasim Khan (OSS) 
> > Cc: devel@edk2.groups.io; Meenakshi Aggarwal
> > ; Varun Sethi ;
> > ard.biesheu...@arm.com; Wasim Khan 
> > Subject: Re: [PATCH edk2-platforms 2/8] Silicon/NXP: Chassis2: define SVR
> > macros
> > 
> > On Wed, Jun 10, 2020 at 02:50:53 +0530, Wasim Khan wrote:
> > > From: Wasim Khan 
> > >
> > > Define macros to retrieve System Version Register(SVR) related
> > > information
> > >
> > > Signed-off-by: Wasim Khan 
> > > ---
> > >  Silicon/NXP/Chassis2/Include/Chassis.h | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/Silicon/NXP/Chassis2/Include/Chassis.h
> > > b/Silicon/NXP/Chassis2/Include/Chassis.h
> > > index e5edd80134a4..7e8bf224884b 100644
> > > --- a/Silicon/NXP/Chassis2/Include/Chassis.h
> > > +++ b/Silicon/NXP/Chassis2/Include/Chassis.h
> > > @@ -12,6 +12,10 @@
> > >
> > >  #define  NXP_LAYERSCAPE_CHASSIS2_DCFG_ADDRESS  0x1EE
> > >
> > > +#define SVR_SOC_VER(svr)(((svr) >> 8) & 0xFE)
> > > +#define SVR_MAJOR(svr)  (((svr) >> 4) & 0xf)
> > > +#define SVR_MINOR(svr)  (((svr) >> 0) & 0xf)
> > > +
> > >  /* SMMU Defintions */
> > >  #define SMMU_BASE_ADDR 0x0900
> > >  #define SMMU_REG_SCR0  (SMMU_BASE_ADDR + 0x0)
> > 
> > These macros are identical between Chassis2 and Chassis3V2, and they also 
> > look
> > like exactly the sort of thing you want identical across different chassis. 
> > Is there
> > a common header file they can use?
> 
> Thank you Leif for the review. 
> These MACROS are chassic specific. Upper 24 bits representation is
> different in Chassis2 and Chassis3V2 (although not used currently
> and masked for SVR calculation but we may need it in future).
> SVR representation may further change for future SoC, so we would
> like to keep them in chassis specific header file.

OK, understood.
Yes, this is fine then.
For the series:
Reviewed-by: Leif Lindholm 
Pushed as 8dd78ea11a38..14e47144ffc6.

/
Leif
> 
> 
> > 
> > (The set is straightforward, I have no other comments on it.)
> > 
> > /
> > Leif
> > 
> > > --
> > > 2.7.4
> > >

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

View/Reply Online (#61501): https://edk2.groups.io/g/devel/message/61501
Mute This Topic: https://groups.io/mt/74793024/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 0/7] NXP: Add PCIe Support for LX2160aRdbPkg

[Leif Lindholm]

On Wed, Jun 10, 2020 at 03:47:23 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> This patch series adds PCIe support for LX2160aRdbPkg.
> LX2160-Rev1 and LX2160-Rev2 has different PCIe controller. Platform
> driver checks the SoC version and enable corresponding PCIe controller
> and its feature using dynamic PCDs. 
> 
> PciHostBridgeLib and PciSegmentLib already has support for both
> PCIe controllers.
> 
> 
> This patch series dependes on below patch series:
> 1 - Silicon/NXP: LX2160A: Add SerDes Support
> 2 - Silicon/NXP: Add SVR and DEVDISRn config configuration

No further comments on this set.
You can consider any patch without a comment as:
Reviewed-by: Leif Lindholm 

Now, I'm going to take some time off - I'll be back 29/6 and will look
at any new revisions then if this hasn't been merged yet..

> Wasim Khan (7):
>   Platform/NXP: LX2160aRdbPkg: Add PCIe space in VirtualMemoryMap
>   Silicon/NXP: LX2160A: Define PCIe related PCDs
>   Platform/NXP: LX2160aRdbPkg: Add PlatformDxe driver
>   Platform/NXP: LX2160aRdbPkg: Enable PlatformDxe driver
>   Platform/NXP: LX2160aRdbPkg: Hide Root Port for LX2160A-Rev2
>   Platform/NXP: LX2160aRdbPkg: Enable NetworkPkg
>   Platform/NXP: LX2160aRdbPkg: Enable PCIE support
> 
>  Silicon/NXP/NxpQoriqLs.dec|  1 +
>  Silicon/NXP/LX2160A/LX2160A.dsc.inc   |  5 +
>  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc  | 22 
> +
>  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf  | 15 
> +++
>  Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf| 36 
> 
>  Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.inf |  1 +
>  Silicon/NXP/Include/Pcie.h|  1 +
>  Silicon/NXP/LX2160A/Include/Soc.h |  8 ++
>  Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.c  | 96 
> 
>  Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c | 38 
> +++-
>  Silicon/NXP/Library/PciHostBridgeLib/PciHostBridgeLib.c   |  6 +-
>  11 files changed, 227 insertions(+), 2 deletions(-)
>  create mode 100644 
> Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf
>  create mode 100644 
> Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.c
> 
> -- 
> 2.7.4
> 

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

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

[edk2-devel] [PATCH v2 0/2] AMD procesor MSR_IA32_MISC_ENABLE

[Kirkendall, Garrett]

AMD processor does not support MSR_IA32_MISC_ENABLE register.  Accessing
this register on AMD causes an unhandled exception in SmmEntry.nasm and
a subsequent failure to boot since this is too early in SMM path for the
exception handler to be loaded.

First, to distinguish between AMD and other processors, refactor
StandardSignatureIsAuthenticAMD into BaseUefiCpuLib.  So there is only
one copy in the source. All changed modules already include UefiCpuLib
either directly or indirectly so could not easly split first patch.

Second, Skip manipulation of MSR_IA32_MISC_ENABLE register if running
on an AMD processor.

Tested on AMD X64 hardware.
OvmfIa32 and OvmfIa32X64 on Intel hardware.

Garrett Kirkendall (2):
  UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to BaseUefiCpuLib
  UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE manipulation on
AMD

 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf |  7 
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf |  2 ++
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf |  2 ++
 UefiCpuPkg/Include/Library/UefiCpuLib.h  | 14 
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h   |  3 ++
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c   | 38 

 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c   | 25 ++---
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c   | 25 ++---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c   |  9 -
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 19 --
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm  | 20 +--
 12 files changed, 113 insertions(+), 74 deletions(-)
 create mode 100644 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c

Changes at:
https://github.com/gkirkendall-amd/edk2/tree/smmentry_nasm_skip_msr_xd_bit_on_amd_v2

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Garrett Kirkendall 

-- 
2.27.0


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

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

[edk2-devel] [PATCH v2 1/2] UefiCpuPkg: Move StandardSignatureIsAuthenticAMD to BaseUefiCpuLib

[Kirkendall, Garrett]

Refactor StandardSignatureIsAuthenticAMD into BaseUefiCpuLib from
separate copies in BaseXApicLib, BaseXApicX2ApicLib, and MpInitLib.
This allows for future use of StandarSignatureIsAuthinticAMD without
creating more instances in other modules.

This function allows IA32/X64 code to determine if it is running on an
AMD brand processor.

UefiCpuLib is already included directly or indirectly in all modified
modules.  Complete move is made in this change.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Garrett Kirkendall 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Eric Dong 
---
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf |  7 
 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf |  2 ++
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf |  2 ++
 UefiCpuPkg/Include/Library/UefiCpuLib.h  | 14 
 UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c   | 38 

 UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c   | 25 ++---
 UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.c   | 25 ++---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 23 
 8 files changed, 67 insertions(+), 69 deletions(-)

diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf 
b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
index 006b7acbf14e..34d3a7bb4303 100644
--- a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
+++ b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.inf
@@ -4,6 +4,7 @@
 #  The library routines are UEFI specification compliant.

 #

 #  Copyright (c) 2009 - 2018, Intel Corporation. All rights reserved.

+#  Copyright (c) 2020, AMD Inc. All rights reserved.

 #  SPDX-License-Identifier: BSD-2-Clause-Patent

 #

 ##

@@ -29,6 +30,12 @@ [Sources.IA32]
 [Sources.X64]

   X64/InitializeFpu.nasm

 

+[Sources]

+  BaseUefiCpuLib.c

+

 [Packages]

   MdePkg/MdePkg.dec

   UefiCpuPkg/UefiCpuPkg.dec

+

+[LibraryClasses]

+  BaseLib

diff --git a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf 
b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
index bdb2ff372677..561baa44b0e6 100644
--- a/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
+++ b/UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.inf
@@ -5,6 +5,7 @@
 #  where local APIC is disabled.

 #

 #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.

+#  Copyright (c) 2020, AMD Inc. All rights reserved.

 #  SPDX-License-Identifier: BSD-2-Clause-Patent

 #

 ##

@@ -37,6 +38,7 @@ [LibraryClasses]
   TimerLib

   IoLib

   PcdLib

+  UefiCpuLib

 

 [Pcd]

   gUefiCpuPkgTokenSpaceGuid.PcdCpuInitIpiDelayInMicroSeconds  ## 
SOMETIMES_CONSUMES

diff --git a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf 
b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
index ac1e0a1c9896..1e2a4f8b790f 100644
--- a/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
+++ b/UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
@@ -5,6 +5,7 @@
 #  where local APIC is disabled.

 #

 #  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.

+#  Copyright (c) 2020, AMD Inc. All rights reserved.

 #  SPDX-License-Identifier: BSD-2-Clause-Patent

 #

 ##

@@ -37,6 +38,7 @@ [LibraryClasses]
   TimerLib

   IoLib

   PcdLib

+  UefiCpuLib

 

 [Pcd]

   gUefiCpuPkgTokenSpaceGuid.PcdCpuInitIpiDelayInMicroSeconds  ## 
SOMETIMES_CONSUMES

diff --git a/UefiCpuPkg/Include/Library/UefiCpuLib.h 
b/UefiCpuPkg/Include/Library/UefiCpuLib.h
index 82e53bab3a0f..5326e7246301 100644
--- a/UefiCpuPkg/Include/Library/UefiCpuLib.h
+++ b/UefiCpuPkg/Include/Library/UefiCpuLib.h
@@ -5,6 +5,7 @@
   to be UEFI specification compliant.

 

   Copyright (c) 2009, Intel Corporation. All rights reserved.

+  Copyright (c) 2020, AMD Inc. All rights reserved.

   SPDX-License-Identifier: BSD-2-Clause-Patent

 

 **/

@@ -29,4 +30,17 @@ InitializeFloatingPointUnits (
   VOID

   );

 

+/**

+  Determine if the standard CPU signature is "AuthenticAMD".

+

+  @retval TRUE  The CPU signature matches.

+  @retval FALSE The CPU signature does not match.

+

+**/

+BOOLEAN

+EFIAPI

+StandardSignatureIsAuthenticAMD (

+  VOID

+  );

+

 #endif

diff --git a/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c 
b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c
new file mode 100644
index ..c2cc3ff9a709
--- /dev/null
+++ b/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib.c
@@ -0,0 +1,38 @@
+/** @file

+  This library defines some routines that are generic for IA32 family CPU.

+

+  The library routines are UEFI specification compliant.

+

+  Copyright (c) 2020, AMD Inc. All rights reserved.

+  SPDX-License-Identifier: BSD-2-Clause-Patent

+

+**/

+

+#include 

+#include 

+

+#include 

+#include 

+

+/**

+  Determine if the standard CPU signature is "AuthenticAMD".

+

+  @retval TRUE  The CPU signature matches.

+  @retval FALSE The CPU signature does not match.

+

[edk2-devel] [PATCH v2 2/2] UefiCpuPkg: PiSmmCpuDxeSmm skip MSR_IA32_MISC_ENABLE manipulation on AMD

[Kirkendall, Garrett]

AMD does not support MSR_IA32_MISC_ENABLE.  Accessing that register
causes and exception on AMD processors.  If Execution Disable is
supported, but if the processor is an AMD processor, skip manipulating
MSR_IA32_MISC_ENABLE[34] XD Disable bit.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Signed-off-by: Garrett Kirkendall 
---

Notes:
Tested on Intel hardware with Laszlo Ersek's help

(1) downloaded two Linux images from provided links.
(2) Test using a 32-bit guest on an Intel host (standing in your edk2 tree, 
with the patches applied):

$ build -a IA32 -b DEBUG -p OvmfPkg/OvmfPkgIa32.dsc -t GCC5 -D SMM_REQUIRE

$ qemu-system-i386 \
-cpu coreduo,-nx \
-machine q35,smm=on,accel=kvm \
-m 4096 \
-smp 4 \
-global driver=cfi.pflash01,property=secure,value=on \
-drive 
if=pflash,format=raw,unit=0,readonly=on,file=Build/OvmfIa32/DEBUG_GCC5/FV/OVMF_CODE.fd
 \
-drive 
if=pflash,format=raw,unit=1,snapshot=on,file=Build/OvmfIa32/DEBUG_GCC5/FV/OVMF_VARS.fd
 \
-drive 
id=hdd,if=none,format=qcow2,snapshot=on,file=fedora-30-efi-systemd-i686.qcow2 \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=hdd,bus=scsi0.0,bootindex=1

(Once you get a login prompt, feel free to interrupt QEMU with Ctrl-C.)

(3) Test using a 64-bit guest on an Intel host:

$ build -a IA32 -a X64 -b DEBUG -p OvmfPkg/OvmfPkgIa32X64.dsc -t GCC5 -D 
SMM_REQUIRE

$ qemu-system-x86_64 \
-cpu host \
-machine q35,smm=on,accel=kvm \
-m 4096 \
-smp 4 \
-global driver=cfi.pflash01,property=secure,value=on \
-drive 
if=pflash,format=raw,unit=0,readonly=on,file=Build/Ovmf3264/DEBUG_GCC5/FV/OVMF_CODE.fd
 \
-drive 
if=pflash,format=raw,unit=1,snapshot=on,file=Build/Ovmf3264/DEBUG_GCC5/FV/OVMF_VARS.fd
 \
-drive 
id=hdd,if=none,format=qcow2,snapshot=on,file=fedora-31-efi-grub2-x86_64.qcow2 \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,drive=hdd,bus=scsi0.0,bootindex=1

Tested on real AMD Hardware

 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h |  3 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c |  9 -
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm   | 19 +--
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm| 20 ++--
 4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
index 43f6935cf9dc..993360a8a8c1 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h
@@ -2,6 +2,7 @@
 SMM profile internal header file.

 

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

+Copyright (c) 2020, AMD Incorporated. All rights reserved.

 SPDX-License-Identifier: BSD-2-Clause-Patent

 

 **/

@@ -13,6 +14,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 

 #include 

 #include 

+#include 

 #include 

 

 #include "SmmProfileArch.h"

@@ -99,6 +101,7 @@ extern SMM_S3_RESUME_STATE   *mSmmS3ResumeState;
 extern UINTN gSmiExceptionHandlers[];

 extern BOOLEAN   mXdSupported;

 X86_ASSEMBLY_PATCH_LABEL gPatchXdSupported;

+X86_ASSEMBLY_PATCH_LABEL gPatchMsrIa32MiscEnableSupported;

 extern UINTN *mPFEntryCount;

 extern UINT64(*mLastPFEntryValue)[MAX_PF_ENTRY_COUNT];

 extern UINT64*(*mLastPFEntryPointer)[MAX_PF_ENTRY_COUNT];

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
index c47b5573e366..d7ed9ab7a770 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c
@@ -2,7 +2,7 @@
 Enable SMM profile.

 

 Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.

-Copyright (c) 2017, AMD Incorporated. All rights reserved.

+Copyright (c) 2017 - 2020, AMD Incorporated. All rights reserved.

 

 SPDX-License-Identifier: BSD-2-Clause-Patent

 

@@ -1015,6 +1015,13 @@ CheckFeatureSupported (
   mXdSupported = FALSE;

   PatchInstructionX86 (gPatchXdSupported, mXdSupported, 1);

 }

+

+if (StandardSignatureIsAuthenticAMD ()) {

+  //

+  // AMD processors do not support MSR_IA32_MISC_ENABLE

+  //

+  PatchInstructionX86 (gPatchMsrIa32MiscEnableSupported, FALSE, 1);

+}

   }

 

   if (mBtsSupported) {

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
index f96de9bdeb43..167f5e14dbd4 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm
@@ -1,5 +1,6 @@
 
;-- 
;

 ; Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.

+; Copyright (c) 2020, AMD Incorporated. All rights reserved.

 ; 

Re: [edk2-devel] [PATCH edk2-platforms 6/7] Platform/NXP: LX2160aRdbPkg: Enable NetworkPkg

[Leif Lindholm]

On Wed, Jun 10, 2020 at 03:47:29 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> Enable NetworkPkg for LX2160aRdbPkg Platform.

This is done as part of a pacthset called "enable PCIe support
for...".
Again, I understand why you're doing this, but it is far from obvious.
Please add a note to the commit message explaining *why*.
(Also, this deserves explicit pointing out in cover letter.)

> Signed-off-by: Wasim Khan 
> ---
>  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc | 11 +++
>  Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf |  5 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc 
> b/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc
> index d0ec7b5a8906..c73f9fd4d393 100644
> --- a/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc
> +++ b/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.dsc
> @@ -22,6 +22,13 @@ [Defines]
>OUTPUT_DIRECTORY   = Build/LX2160aRdbPkg
>FLASH_DEFINITION   = 
> Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.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/LX2160A/LX2160A.dsc.inc
>  
> @@ -45,4 +52,8 @@ [Components.common]
>  
>Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf
>  
> +  #
> +  # Networking stack
> +  #
> +!include NetworkPkg/Network.dsc.inc
>   ##
> diff --git a/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf 
> b/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf
> index 41b8f1ececa4..4c9cab5d0938 100644
> --- a/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf
> +++ b/Platform/NXP/LX2160aRdbPkg/LX2160aRdbPkg.fdf
> @@ -116,6 +116,11 @@ [FV.FvMain]
>INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
>  
>#
> +  # Networking stack
> +  #
> +!include NetworkPkg/Network.fdf.inc
> +
> +  #
># FAT filesystem + GPT/MBR partitioning
>#
>INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
> -- 
> 2.7.4
> 

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

View/Reply Online (#61496): https://edk2.groups.io/g/devel/message/61496
Mute This Topic: https://groups.io/mt/74793007/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 2/7] Silicon/NXP: LX2160A: Define PCIe related PCDs

[Leif Lindholm]

On Thu, Jun 18, 2020 at 10:33:05 +, Wasim Khan (OSS) wrote:
> 
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Thursday, June 18, 2020 3:38 PM
> > To: Wasim Khan (OSS) 
> > Cc: devel@edk2.groups.io; Meenakshi Aggarwal
> > ; Varun Sethi ;
> > ard.biesheu...@arm.com; Wasim Khan 
> > Subject: Re: [PATCH edk2-platforms 2/7] Silicon/NXP: LX2160A: Define PCIe
> > related PCDs
> > 
> > On Wed, Jun 10, 2020 at 03:47:25 +0530, Wasim Khan wrote:
> > > From: Wasim Khan 
> > >
> > > Define PCIe related PCDs for LX2160A.
> > >
> > > Signed-off-by: Wasim Khan 
> > > ---
> > >  Silicon/NXP/LX2160A/LX2160A.dsc.inc | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > > b/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > > index fe8ed402fc4e..43e361464c8e 100644
> > > --- a/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > > +++ b/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > > @@ -38,6 +38,11 @@ [PcdsFixedAtBuild.common]
> > >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
> > >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x21C
> > >
> > > +  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr|0x80
> > 
> > This is already provided by LX2160A_PCI1_PHYS_ADDRESS in
> > Silicon/NXP/LX2160A/Include/Soc.h, and PCI_SEG0_MMIO_MEMBASE would be
> > better described as an alias of that. Unless the NXP
> > PciHostBridgeLib/PciSegmentLib is intended to be shared with SoCs where 
> > these
> > base addresses can be different in different platforms.
> 
> Yes, PciHostBridgeLib/PciSegmentLib are shared with different SoC
> with different base address and number of PCIe controllers.

Yes. What I meant was whether the base address could change for the
SoC depending on which platform it is integrated in?

> > If so, the PHYS_ADDRESSES would be better defined as derivatives of
> > PcdPciExp1BaseAddr.
> 
> OK, I will use PcdPciExp1BaseAddr and PcdNumPciController for PHYS_ADDRESSES
> 
> > 
> > > +  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|6
> > 
> > Is this number possible to be different for different platforms based on 
> > the same
> > SoC?
> 
> This is the total number of PCIe controller on a SoC (for LS1043 its
> 3, for LX2160 its 6)
> A platform may use few of them based on the RCW (For Ex:
> LX2160aRdbPkg has only PEX3 and PEX5 . LX2160aQdsPkg may have all 6
> controller enabled).

OK, then the use of the Pcd is definitely the right way to go, but
yes, please do as you suggest above to avoid multiple (and potentially
conflicting) definitions for the same address.

Regards,

Leif

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

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

[edk2-devel] Build error for UefiPayloadPkgIa32.dsc

[PierreGondois]

Hello,
I am not actively using this platform, but I wanted to report an error when 
building one of the DSC files in the UefiPayloadPkg with the following 
configuration:
build -b NOOPT -a IA32 -t VS2017 -p edk2 
edk2\UefiPayloadPkg\UefiPayloadPkgIa32.dsc

The following error occurs:
Generating PEIFV FV
 ['GenFv', '-a', 
'Build\\UefiPayloadPkgIA32\\NOOPT_VS2017\\FV\\Ffs\\PEIFV.inf', '-o', 
'Build\\UefiPayloadPkgIA32\\NOOPT_VS2017\\FV\\PEIFV.Fv', '-i', 
Build\\UefiPayloadPkgIA32\\NOOPT_VS2017\\FV\\PEIFV.inf']
Return Value = 2
GenFv: ERROR 3000: Invalid
the required fv image size 0x406c8 exceeds the set fv image size 0x3
Regards,
Pierre
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 (#61494): https://edk2.groups.io/g/devel/message/61494
Mute This Topic: https://groups.io/mt/74960189/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v9 43/46] OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector

[Lendacky, Thomas]

On 6/18/20 2:43 AM, Dong, Eric wrote:

Hi Tom,


Hi Eric,



We use GCC5 to build the OVMF platform and report below errors, please help to 
check and fix it.


That's what I use when I build and have never encountered these errors. I 
also ran the patches through the EDK2 CI and didn't get any errors.


I've noticed that the dependencies aren't always handle properly for these 
files. Are you doing a clean build or an incremental build for this patch? 
Can you delete your Build directory and rebuild and see if you still get 
the errors?





I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/MdeModulePkg/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/MdeModulePkg/Include/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/UefiCpuPkg/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/UefiCpuPkg/Include/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/UefiCpuPkg/ResetVector/Vtf0/ -o 
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin
 
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii:72:
 error: expression syntax error
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii:74: error: label or instruction expected at start of line > Ia32/PageTables64.asm:27: error: label or instruction expected at start 

of line

Ia32/PageTables64.asm:29: error: label or instruction expected at start of line
Ia32/PageTables64.asm:30: error: label or instruction expected at start of line
Ia32/PageTables64.asm:369: error: expression syntax error


Can you paste the relevant portion of these files in an email or send 
copies of those files to me?


Thanks,
Tom


GNUmakefile:319: recipe for target 
'/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin'
 failed
make: *** 
[/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin]
 Error 1


build.py...
  : error 7000: Failed to execute command
make tbuild 
[/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector]


build.py...
  : error F002: Failed to build module

/opt/TCAgent/work/f9b29f3e80472c44/Edk2/OvmfPkg/ResetVector/ResetVector.inf 
[X64, GCC5, DEBUG]


Related platform build configuration like below:

WORKSPACE= /opt/TCAgent/work/f9b29f3e80472c44/Edk2
EDK_TOOLS_PATH   = /opt/TCAgent/work/f9b29f3e80472c44/Edk2/BaseTools
CONF_PATH= /opt/TCAgent/work/f9b29f3e80472c44/Edk2/Conf
PYTHON_COMMAND   = /usr/bin/python3.5

Architecture(s)  = X64
Build target = DEBUG
Toolchain= GCC5

Active Platform  = 
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/OvmfPkg/OvmfPkgX64.dsc


Thanks,
Eric

-Original Message-
From: Tom Lendacky 
Sent: Friday, June 5, 2020 9:28 PM
To: devel@edk2.groups.io
Cc: Brijesh Singh ; Ard Biesheuvel
; Dong, Eric ; Justen,
Jordan L ; Laszlo Ersek ;
Gao, Liming ; Kinney, Michael D
; Ni, Ray 
Subject: [PATCH v9 43/46] OvmfPkg: Use the SEV-ES work area for the SEV-
ES AP reset vector

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%7C68b736db1acf4493c24308d8135b4a75%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637280630097752935sdata=R8sYtSa7bQXgeW4tiSAxDdwcoZaldq4%2BoN2Xn378JMc%3Dreserved=0

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 the SEV-ES work area for the reset vector code that contains support
to jump to the desired RIP location after having been started. This is
required for only the very first AP reset.

This new OVMF source file, ResetVectorVtf0.asm, is used in place of the
original file through the use of the include path order set in
OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]".

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Signed-off-by: Tom Lendacky 
---
  OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 100

  OvmfPkg/ResetVector/ResetVector.nasmb|   1 +
  2 files changed, 101 insertions(+)

diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
new file mode 100644
index ..980e0138e7fe
--- /dev/null
+++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
@@ -0,0 +1,100 @@

Re: [edk2-devel] [PATCH v2 0/4] Compile AML bytecode array into OBJ file

[PierreGondois]

Hello Bob,
As discussed, I have created a pull request on the edk2 github. It is available 
here:
https://github.com/tianocore/edk2/pull/700
Feel free to delete it.

I have tested the patch set on the following confifurations, with the following 
formating for each line:
[DSC file] [Build environment (Linux/Windows)] [Arch] [Toolchain] [Build type 
(DEBUG, ...)]

ArmCrashDumpDxe_dsc LinuxEnv AARCH64 GCC5 DEBUG
ArmPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
ArmPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
ArmPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
ArmPlatformPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
ArmPlatformPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
ArmPlatformPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
ArmVirtQemuKernel_dsc LinuxEnv AARCH64 GCC5 DEBUG
ArmVirtQemuKernel_dsc LinuxEnv AARCH64 GCC5 NOOPT
ArmVirtQemuKernel_dsc LinuxEnv AARCH64 GCC5 RELEASE
ArmVirtQemu_dsc LinuxEnv AARCH64 GCC5 DEBUG
ArmVirtQemu_dsc LinuxEnv AARCH64 GCC5 NOOPT
ArmVirtQemu_dsc LinuxEnv AARCH64 GCC5 RELEASE
ArmVirtXen_dsc LinuxEnv AARCH64 GCC5 DEBUG
ArmVirtXen_dsc LinuxEnv AARCH64 GCC5 NOOPT
ArmVirtXen_dsc LinuxEnv AARCH64 GCC5 RELEASE
CryptoPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
CryptoPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
CryptoPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
DynamicTablesPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
DynamicTablesPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
DynamicTablesPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
EmbeddedPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
EmbeddedPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
EmbeddedPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
FatPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
FatPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
FatPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
FmpDevicePkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
FmpDevicePkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
FmpDevicePkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
MdeModulePkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
MdeModulePkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
MdeModulePkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
MdePkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
MdePkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
MdePkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
NetworkPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
NetworkPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
NetworkPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
SecurityPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
SecurityPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
SecurityPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
ShellPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
ShellPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
ShellPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
SignedCapsulePkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
SignedCapsulePkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
SignedCapsulePkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
StandaloneMmPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
StandaloneMmPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
UnitTestFrameworkPkg_dsc LinuxEnv AARCH64 GCC5 DEBUG
UnitTestFrameworkPkg_dsc LinuxEnv AARCH64 GCC5 NOOPT
UnitTestFrameworkPkg_dsc LinuxEnv AARCH64 GCC5 RELEASE
edk2_ArmPkg_ArmPkg_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_ArmPkg_ArmPkg_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_ArmPkg_ArmPkg_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_ArmPkg_Drivers_ArmCrashDumpDxe_ArmCrashDumpDxe_dsc WindowsEnv AARCH64 GCC5 
DEBUG
edk2_ArmPkg_Drivers_ArmCrashDumpDxe_ArmCrashDumpDxe_dsc WindowsEnv AARCH64 
VS2017 DEBUG
edk2_ArmPlatformPkg_ArmPlatformPkg_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_ArmPlatformPkg_ArmPlatformPkg_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_ArmPlatformPkg_ArmPlatformPkg_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_ArmVirtPkg_ArmVirtQemuKernel_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_ArmVirtPkg_ArmVirtQemuKernel_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_ArmVirtPkg_ArmVirtQemuKernel_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_ArmVirtPkg_ArmVirtQemu_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_ArmVirtPkg_ArmVirtQemu_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_ArmVirtPkg_ArmVirtQemu_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_ArmVirtPkg_ArmVirtXen_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_ArmVirtPkg_ArmVirtXen_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_ArmVirtPkg_ArmVirtXen_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv IA32 VS2017 DEBUG
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv IA32 VS2017 NOOPT
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv IA32 VS2017 RELEASE
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv X64 VS2017 DEBUG
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv X64 VS2017 NOOPT
edk2_CryptoPkg_CryptoPkg_dsc WindowsEnv X64 VS2017 RELEASE
edk2_DynamicTablesPkg_DynamicTablesPkg_dsc WindowsEnv AARCH64 GCC5 DEBUG
edk2_DynamicTablesPkg_DynamicTablesPkg_dsc WindowsEnv AARCH64 GCC5 NOOPT
edk2_DynamicTablesPkg_DynamicTablesPkg_dsc WindowsEnv AARCH64 GCC5 RELEASE
edk2_DynamicTablesPkg_DynamicTablesPkg_dsc WindowsEnv AARCH64 VS2017 DEBUG
edk2_DynamicTablesPkg_DynamicTablesPkg_dsc WindowsEnv AARCH64 VS2017 NOOPT
edk2_DynamicTablesPkg_DynamicTablesPkg_dsc WindowsEnv AARCH64 VS2017 RELEASE
edk2_EmulatorPkg_EmulatorPkg_dsc WindowsEnv IA32 VS2017 DEBUG

[edk2-devel] [PATCH v2 2/4] BaseTools: Rename AmlToHex script to AmlToC

[PierreGondois]

From: Pierre Gondois 

The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.

The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.

This patch renames the script as AmlToC. It is posted as
a separate patch to prevent git from seeing the renaming
as a deletion plus addition of a new file.
The ending line of the posix-like bin-wrapper script has
also been corrected.

This is a first step toward generating a C file containing
the AML bytecode from an ASL file. This C file will then
be handled by the EDK2 build system to generate an object
file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.

To summarize, the flow goes as:
 -1. ASL file is compiled to AML;
 -2. AML file is copied to a ".amli" intermediate file;
 -3. EDK2 build system applies the rule relevant to ".amli"
 files. This is, calling the "AmlToC" script, generating
 a C file from the ".amli" file;
 -4. EDK2 build system applies the rule relevant to C files.
 This is creating an object file.
 -5. EDK2 build system links the object file containing the
 AML bytecode with the object file requiring it.

Signed-off-by: Pierre Gondois 
Signed-off-by: Tomas Pilar 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/commits/pg/803_Compile_AML_bytecode_array_into_OBJ_file_v2

Notes:
Notes:
  v1:
   - Rename AmlToHex scripts to AmlToC, and change line
 endings of the PosixLike bin-wrapper. [Pierre]
  v2:
   - No modification. [Pierre]

 BaseTools/BinWrappers/PosixLike/{AmlToHex => AmlToC}   | 28 
++--
 BaseTools/BinWrappers/WindowsLike/{AmlToHex.bat => AmlToC.bat} |  0
 BaseTools/Source/Python/{AmlToHex/AmlToHex.py => AmlToC/AmlToC.py} |  0
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/BaseTools/BinWrappers/PosixLike/AmlToHex 
b/BaseTools/BinWrappers/PosixLike/AmlToC
similarity index 97%
rename from BaseTools/BinWrappers/PosixLike/AmlToHex
rename to BaseTools/BinWrappers/PosixLike/AmlToC
index 
9fb68299e4c67d1f332cd883fd348a896f1bdc50..1dd28e966288f6ea4fc52d42e2dc7b1f74226c23
 100755
--- a/BaseTools/BinWrappers/PosixLike/AmlToHex
+++ b/BaseTools/BinWrappers/PosixLike/AmlToC
@@ -1,14 +1,14 @@
-#!/usr/bin/env bash
-#python `dirname $0`/RunToolFromSource.py `basename $0` $*
-
-# If a ${PYTHON_COMMAND} command is available, use it in preference to python
-if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
-python_exe=${PYTHON_COMMAND}
-fi
-
-full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
-dir=$(dirname "$full_cmd")
-exe=$(basename "$full_cmd")
-
-export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
-exec "${python_exe:-python}" "$dir/../../Source/Python/$exe/$exe.py" "$@"
+#!/usr/bin/env bash
+#python `dirname $0`/RunToolFromSource.py `basename $0` $*
+
+# If a ${PYTHON_COMMAND} command is available, use it in preference to python
+if command -v ${PYTHON_COMMAND} >/dev/null 2>&1; then
+python_exe=${PYTHON_COMMAND}
+fi
+
+full_cmd=${BASH_SOURCE:-$0} # see http://mywiki.wooledge.org/BashFAQ/028 for a 
discussion of why $0 is not a good choice here
+dir=$(dirname "$full_cmd")
+exe=$(basename "$full_cmd")
+
+export PYTHONPATH="$dir/../../Source/Python${PYTHONPATH:+:"$PYTHONPATH"}"
+exec "${python_exe:-python}" "$dir/../../Source/Python/$exe/$exe.py" "$@"
diff --git a/BaseTools/BinWrappers/WindowsLike/AmlToHex.bat 
b/BaseTools/BinWrappers/WindowsLike/AmlToC.bat
similarity index 100%
rename from BaseTools/BinWrappers/WindowsLike/AmlToHex.bat
rename to BaseTools/BinWrappers/WindowsLike/AmlToC.bat
diff --git a/BaseTools/Source/Python/AmlToHex/AmlToHex.py 
b/BaseTools/Source/Python/AmlToC/AmlToC.py
similarity index 100%
rename from BaseTools/Source/Python/AmlToHex/AmlToHex.py
rename to BaseTools/Source/Python/AmlToC/AmlToC.py
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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

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

[edk2-devel] [PATCH v2 4/4] BaseTools: Fix string concatenation

[PierreGondois]

From: Pierre Gondois 

Using Python 3.7.2 on win32, when printing a FileBuildRule
instance, the following error occurs:
File "edk2\BaseTools\Source\Python\AutoGen\BuildEngine.py",
line 177, in __str__
  DestString = ", ".join(self.DestFileList)
  TypeError: sequence item 0: expected str instance, PathClass found

This patch converts each PathClass element of the list to a string
instance before concatenating them.

Signed-off-by: Pierre Gondois 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/commits/pg/803_Compile_AML_bytecode_array_into_OBJ_file_v2

Notes:
Notes:
  v2:
   - No v1 for this patch. Fix a __str__ method. [Pierre]

 BaseTools/Source/Python/AutoGen/BuildEngine.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/AutoGen/BuildEngine.py 
b/BaseTools/Source/Python/AutoGen/BuildEngine.py
index 
d602414ca41f37155c9c6d00eec54ea3918840c3..722fead75af6d60aa82365d999837cd5ac3299af
 100644
--- a/BaseTools/Source/Python/AutoGen/BuildEngine.py
+++ b/BaseTools/Source/Python/AutoGen/BuildEngine.py
@@ -172,7 +172,7 @@ class FileBuildRule:
 def __str__(self):
 SourceString = ""
 SourceString += " %s %s %s" % (self.SourceFileType, " 
".join(self.SourceFileExtList), self.ExtraSourceFileList)
-DestString = ", ".join(self.DestFileList)
+DestString = ", ".join([str(i) for i in self.DestFileList])
 CommandString = "\n\t".join(self.CommandList)
 return "%s : %s\n\t%s" % (DestString, SourceString, CommandString)
 
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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

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

[edk2-devel] [PATCH v2 1/4] BaseTools: Generate multiple rules when multiple output files

[PierreGondois]

From: Pierre Gondois 

This patch modifies the Makefile generation not to stop
adding Makfile rules when the first final target is found.
E.g.:
If the following rules are described in build_rule.txt:
 -[Rule1]: .X files generate .Y and .Z files;
 -[Rule2]: .Z files generate .Z1 files.
Currently, if a File1.X file was part of the sources of a
module, only [Rule1] would be generated in the Makefile.
Indeed, there are no rules to apply to .Y files: .Y files
are a final target. However, there is still [Rule2] to
apply to .Z files.

This patch also adds a dependency between the first
ouput file of a rule and the other output files.
For instance, with the same example as above, File1.Y
and File1.Z are generated by the following rule:
File1.Y: File1.X



and the new dependency is:
File1.Z: File1.Y

This is necessary to keep a dependency order during the
execution of the Makefile. Indeed, .Y and .Z files are
generated by the execution of a common set of commands,
and without this rule, there is no explicit dependency
relation between them.

Signed-off-by: Pierre Gondois 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/commits/pg/803_Compile_AML_bytecode_array_into_OBJ_file_v2

Notes:
Notes:
  v1:
   - Generate multiple rules when multiple output files
 are specified in the build_rule.txt file. [Pierre]
  v2:
   - Use the "FileType" variable in the _ApplyBuildRule
 function as it is in the current state. [Pierre]

 BaseTools/Source/Python/AutoGen/GenMake.py   |  6 
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 38 +++-
 2 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py 
b/BaseTools/Source/Python/AutoGen/GenMake.py
index 
bbb3c29446f53fa7f2cb61a216a5b119f72c3fbc..0314d0ea34d99a014379e8d30c46ac0f0a7068ce
 100755
--- a/BaseTools/Source/Python/AutoGen/GenMake.py
+++ b/BaseTools/Source/Python/AutoGen/GenMake.py
@@ -1054,6 +1054,12 @@ cleanlib:
 TargetDict = {"target": self.PlaceMacro(T.Target.Path, 
self.Macros), "cmd": "\n\t".join(T.Commands),"deps": Deps}
 
self.BuildTargetList.append(self._BUILD_TARGET_TEMPLATE.Replace(TargetDict))
 
+# Add a Makefile rule for targets generating multiple 
files.
+# The main output is a prerequisite for the other output 
files.
+for i in T.Outputs[1:]:
+AnnexeTargetDict = {"target": self.PlaceMacro(i.Path, 
self.Macros), "cmd": "", "deps": self.PlaceMacro(T.Target.Path, self.Macros)}
+
self.BuildTargetList.append(self._BUILD_TARGET_TEMPLATE.Replace(AnnexeTargetDict))
+
 def ParserCCodeFile(self, T, Type, CmdSumDict, CmdTargetDict, CmdCppDict, 
DependencyDict):
 if not CmdSumDict:
 for item in self._AutoGenObject.Targets[Type]:
diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 
aad591de65f086043d55aeea5661f59c53792e7c..dc8b1fe3d160cac2da7fc233e3aa0d92cb1e
 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -860,7 +860,8 @@ class ModuleAutoGen(AutoGen):
 SubDirectory = os.path.join(self.OutputDir, File.SubDir)
 if not os.path.exists(SubDirectory):
 CreateDirectory(SubDirectory)
-LastTarget = None
+TargetList = set()
+FinalTargetName = set()
 RuleChain = set()
 SourceList = [File]
 Index = 0
@@ -870,6 +871,9 @@ class ModuleAutoGen(AutoGen):
 self.BuildOption
 
 while Index < len(SourceList):
+# Reset the FileType if not the first iteration.
+if Index > 0:
+FileType = TAB_UNKNOWN_FILE
 Source = SourceList[Index]
 Index = Index + 1
 
@@ -886,29 +890,25 @@ class ModuleAutoGen(AutoGen):
 elif Source.Ext in self.BuildRules:
 RuleObject = self.BuildRules[Source.Ext]
 else:
-# stop at no more rules
-if LastTarget:
-self._FinalBuildTargetList.add(LastTarget)
-break
+# No more rule to apply: Source is a final target.
+FinalTargetName.add(Source)
+continue
 
 FileType = RuleObject.SourceFileType
 self._FileTypes[FileType].add(Source)
 
 # stop at STATIC_LIBRARY for library
 if self.IsLibrary and FileType == TAB_STATIC_LIBRARY:
-if LastTarget:
-self._FinalBuildTargetList.add(LastTarget)
-break
+FinalTargetName.add(Source)
+continue
 
 Target = RuleObject.Apply(Source, self.BuildRuleOrder)
 if not Target:
-if LastTarget:
-

[edk2-devel] [PATCH v2 0/4] Compile AML bytecode array into OBJ file

[PierreGondois]

Following the BZ at https://bugzilla.tianocore.org/show_bug.cgi?id=2425
This patch serie is a another way to solve the dependency
of C files over ASL files. With this new method, the
dependency is resolved at the linking stage.

The last method to solve this dependency was to add
the possibility to modify INF files to depict such a
dependency. This method was not accepted. The discussion
is available at https://edk2.groups.io/g/devel/topic/72655342#56658

The last patch modifying the INF specification and INF
parsing are available at:
https://edk2.groups.io/g/devel/topic/72655342#56658
https://edk2.groups.io/g/devel/topic/72656060#56662

Pierre Gondois (4):
  BaseTools: Generate multiple rules when multiple output files
  BaseTools: Rename AmlToHex script to AmlToC
  BaseTools: Compile AML bytecode arrays into .obj file
  BaseTools: Fix string concatenation

 BaseTools/BinWrappers/PosixLike/{AmlToHex => AmlToC}   | 28 +++
 BaseTools/BinWrappers/WindowsLike/{AmlToHex.bat => AmlToC.bat} |  0
 BaseTools/Conf/build_rule.template | 15 +++-
 BaseTools/Source/Python/{AmlToHex/AmlToHex.py => AmlToC/AmlToC.py} | 82 

 BaseTools/Source/Python/AutoGen/BuildEngine.py |  2 +-
 BaseTools/Source/Python/AutoGen/GenMake.py |  6 ++
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py   | 38 
+
 7 files changed, 89 insertions(+), 82 deletions(-)
 rename BaseTools/BinWrappers/PosixLike/{AmlToHex => AmlToC} (97%)
 rename BaseTools/BinWrappers/WindowsLike/{AmlToHex.bat => AmlToC.bat} (100%)
 rename BaseTools/Source/Python/{AmlToHex/AmlToHex.py => AmlToC/AmlToC.py} (52%)

-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'


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

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

[edk2-devel] [PATCH v2 3/4] BaseTools: Compile AML bytecode arrays into .obj file

[PierreGondois]

From: Pierre Gondois 

The AmlToHex script and Posix/WindowsLike wrappers convert
an AML file to a .hex file, containing a C array storing
AML bytecode. This ".hex" file can then be included in a
C file, allowing to access the AML bytecode from this C
file.

The EDK2 build system doesn't allow to a depict dependency
orders between files of different languages. For instance,
in a module containing a ".c" file and a ".asl", the ".c"
file may or may not be built prior to the ".asl" file.
This prevents any inclusion of a generated ".hex" in a
".c" file since this later ".hex" file may or may not
have been created yet.

This patch modifies the AmlToC script to generate a C file
instead of a ".hex" file.
It also adds the generation of an intermediate ".amli" file
when compiling an ASL file, and adds a rule to convert this
".amli" to a C file.

This allows to generate a C file containing the AML bytecode
from an ASL file. This C file will then be handled by the EDK2
build system to generate an object file.
Thus, no file inclusion will be required anymore. The C file
requiring the AML bytecode as a C array, and the ASL file,
will be compiled independently. The C array must be defined
as an external symbol. The linker is resolving the
reference to the C array symbol.

To summarize, the flow goes as:
 -1. ASL file is compiled to AML;
 -2. AML file is copied to a ".amli" intermediate file;
 -3. EDK2 build system applies the rule relevant to ".amli"
 files. This is, calling the "AmlToC" script, generating
 a C file from the ".amli" file;
 -4. EDK2 build system applies the rule relevant to C files.
 This is creating an object file.
 -5. EDK2 build system links the object file containing the
 AML bytecode with the object file requiring it.

Signed-off-by: Pierre Gondois 
Signed-off-by: Tomas Pilar 
---

The changes can be seen at 
https://github.com/PierreARM/edk2/commits/pg/803_Compile_AML_bytecode_array_into_OBJ_file_v2

Notes:
Notes:
  v1:
   - Add a new rule to the build_rule.template file to
 generate ".obj" files from .asl files, and modify
 the AmlToC script accordingly. [Pierre]
  v2:
   - Restrict the rule to DXE_DRIVER. This allows to build
 the OvmfPkg, which was not the case in v1. [Pierre]

 BaseTools/Conf/build_rule.template   | 15 +++-
 BaseTools/Source/Python/AmlToC/AmlToC.py | 82 
 2 files changed, 47 insertions(+), 50 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 
0822b681fcd9f61c6508e6f93ffc31fa70fd7059..c034869915914936e28f64a6aadba08e0169da44
 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -419,6 +419,7 @@
 
 
 $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
+$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.amli
 
 
 $(MAKE_FILE)
@@ -428,14 +429,24 @@
 "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) /I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
--AmlToHex $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
+$(CP) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.amli
 
 
 Trim --asl-file --asl-deps -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i 
-i $(INC_LIST) ${src}
 "$(ASLPP)" $(DEPS_FLAGS) $(ASLPP_FLAGS) $(INC) -I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
--AmlToHex $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml
+$(CP) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.amli
+
+[Acpi-Machine-Language-File-to-C.DXE_DRIVER]
+
+?.amli
+
+
+${s_path}(+)${s_base}.c
+
+
+-AmlToC ${src}
 
 [C-Code-File.AcpiTable]
 
diff --git a/BaseTools/Source/Python/AmlToC/AmlToC.py 
b/BaseTools/Source/Python/AmlToC/AmlToC.py
index 
643db2910e37acfdd80ac18d288c921320a79ce1..346de7159de702d860bbd809ddbe8175f1493cfb
 100644
--- a/BaseTools/Source/Python/AmlToC/AmlToC.py
+++ b/BaseTools/Source/Python/AmlToC/AmlToC.py
@@ -1,9 +1,9 @@
 ## @file
 #
-# Convert an AML file to a .hex file containing the AML bytecode stored in a
+# Convert an AML file to a .c file containing the AML bytecode stored in a
 # C array.
-# By default, "Tables\Dsdt.aml" will generate "Tables\Dsdt.hex".
-# "Tables\Dsdt.hex" will contain a C array named "dsdt_aml_code" that contains
+# By default, "Tables\Dsdt.aml" will generate "Tables\Dsdt.c".
+# "Tables\Dsdt.c" will contain a C array named 

Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement library support for VMGEXIT

[Lendacky, Thomas]

On 6/18/20 2:23 AM, Dong, Eric wrote:
> Hi Tom,
> 
> When use VS2015 to build this code, it reports below error. Please help to 
> fix it.
> 
> k:\edk2\UefiCpuPkg\Include\Library/VmgExitLib.h: error C2220: warning treated 
> as error - no 'object' file generated
> k:\edk2\UefiCpuPkg\Include\Library/VmgExitLib.h: warning C4335: Mac file 
> format detected: please convert the source file to either DOS or UNIX format

That is strange...  I didn't see this when I ran through the CI. When I do
a file command against the file it reports:

UefiCpuPkg/Include/Library/VmgExitLib.h: C source, ASCII text, with CRLF line 
terminators

I'll investigate this and try and figure out what's going on, but if
anyone else has some ideas, please let me know.

Thanks,
Tom

> 
> Thanks,
> Eric
> 
>> -Original Message-
>> From: Tom Lendacky 
>> Sent: Friday, June 5, 2020 9:27 PM
>> To: devel@edk2.groups.io
>> Cc: Brijesh Singh ; Ard Biesheuvel
>> ; Dong, Eric ; Justen,
>> Jordan L ; Laszlo Ersek ;
>> Gao, Liming ; Kinney, Michael D
>> ; Ni, Ray 
>> Subject: [PATCH v9 08/46] UefiCpuPkg: Implement library support for
>> VMGEXIT
>>
>> 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%7Cd75554da4959407c967608d8135877be%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637280617975250842sdata=fBlK2BFkRdAS5EWcM8YShf1ZswfRN%2F41L7XeUsb4ZCs%3Dreserved=0
>>
>> To support handling #VC exceptions and issuing VMGEXIT instructions,
>> create a library with functions that can be used to perform these
>> #VC/VMGEXIT related operations. This includes functions for:
>>- Handling #VC exceptions
>>- Preparing for and issuing a VMGEXIT
>>- Performing MMIO-related write operations to support flash emulation
>>- Performing AP related boot opeations
>>
>> The base functions in this driver will not do anything and will return
>> an error if a return value is required. It is expected that other packages
>> (like OvmfPkg) will create a version of the library to fully support an
>> SEV-ES guest.
>>
>> Cc: Eric Dong 
>> Cc: Ray Ni 
>> Cc: Laszlo Ersek 
>> Signed-off-by: Tom Lendacky 
>> ---
>>   UefiCpuPkg/UefiCpuPkg.dec|   3 +
>>   UefiCpuPkg/UefiCpuPkg.dsc|   2 +
>>   UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf |  27 +
>>   UefiCpuPkg/Include/Library/VmgExitLib.h  | 103 
>> +
>>   UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.c   | 121
>> 
>>   UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.uni |  15 +++
>>   6 files changed, 271 insertions(+)
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
>> index df5d02bae6b4..cb92f34b6f55 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dec
>> +++ b/UefiCpuPkg/UefiCpuPkg.dec
>> @@ -53,6 +53,9 @@ [LibraryClasses.IA32, LibraryClasses.X64]
>> ##
>>
>> MpInitLib|Include/Library/MpInitLib.h
>>
>>
>>
>> +  ##  @libraryclass  Provides function to support VMGEXIT processing.
>>
>> +  VmgExitLib|Include/Library/VmgExitLib.h
>>
>> +
>>
>>   [Guids]
>>
>> gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa,
>> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
>>
>> gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 
>> 0x30,
>> 0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
>> index afa304128221..f0e58b90ff0a 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dsc
>> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
>> @@ -56,6 +56,7 @@ [LibraryClasses]
>>
>> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/Base
>> PeCoffGetEntryPointLib.inf
>>
>>
>> PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BaseP
>> eCoffExtraActionLibNull.inf
>>
>>
>> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/Tp
>> mMeasurementLibNull.inf
>>
>> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
>>
>>
>>
>>   [LibraryClasses.common.SEC]
>>
>>
>> PlatformSecLib|UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.i
>> nf
>>
>> @@ -143,6 +144,7 @@ [Components.IA32, Components.X64]
>>
>> UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLib
>> Null.inf
>>
>> UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
>>
>> UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
>>
>> +  UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
>>
>> UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
>>
>> UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
>>
>> UefiCpuPkg/SecCore/SecCore.inf
>>
>> diff --git a/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
>> b/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
>> new file mode 100644
>> index ..d8770a21c355
>> --- /dev/null
>> +++ b/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
>> @@ -0,0 +1,27 @@
>> +## @file
>>
>> +#  

[edk2-devel] [PATCH v2 0/2] IntelFsp2Pkg: Add FSP*_ARCH_UPD.

[Chiu, Chasel]

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

Introduce FSPT_ARCH_UPD and FSPS_ARCH_UPD to support debug events
and multi-phase silicon initialization.

In V2 backward compatibility support is added, the original
structures are kept and new ARCH_UPD structures will be
included only when UPD header revision equal or greater than 2.

GenCfgOpt script also updated to prevent from generating duplicate
FSPT_ARCH_UPD and FSPS_ARCH_UPD typedef structures.

Cc: Maurice Ma 
Cc: Nate DeSimone 
Cc: Star Zeng 
Signed-off-by: Chasel Chiu 

Chasel Chiu (2):
  IntelFsp2Pkg: Add FSP*_ARCH_UPD.
  IntelFsp2WrapperPkg: Add FSP*_ARCH_UPD.

 IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c 
| 26 --
 IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm 
| 78 
+-
 IntelFsp2Pkg/Include/FspEas/FspApi.h   
| 81 
-
 IntelFsp2Pkg/Tools/GenCfgOpt.py
|  6 +++---
 4 files changed, 180 insertions(+), 11 deletions(-)

-- 
2.13.3.windows.1


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

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

[edk2-devel] [PATCH v2 1/2] IntelFsp2Pkg: Add FSP*_ARCH_UPD.

[Chiu, Chasel]

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

Introduce FSPT_ARCH_UPD and FSPS_ARCH_UPD to support debug events
and multi-phase silicon initialization.
For backward compatibility the original structures are kept and
new ARCH_UPD structures will be included only when UPD header
revision equal or greater than 2.

GenCfgOpt script also updated to prevent from generating duplicate
FSPT_ARCH_UPD and FSPS_ARCH_UPD typedef structures.

Cc: Maurice Ma 
Cc: Nate DeSimone 
Cc: Star Zeng 
Signed-off-by: Chasel Chiu 
---
 IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 78 
+-
 IntelFsp2Pkg/Include/FspEas/FspApi.h   | 81 
-
 IntelFsp2Pkg/Tools/GenCfgOpt.py|  6 +++---
 3 files changed, 156 insertions(+), 9 deletions(-)

diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm 
b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
index e354870a1d..7934eab6d7 100644
--- a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
+++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
@@ -1,7 +1,7 @@
 ;; @file
 ;  Provide FSP API entry points.
 ;
-; Copyright (c) 2016, Intel Corporation. All rights reserved.
+; Copyright (c) 2016 - 2020, Intel Corporation. All rights reserved.
 ; SPDX-License-Identifier: BSD-2-Clause-Patent
 ;;
 
@@ -78,6 +78,23 @@ struc LoadMicrocodeParams
 .size:
 endstruc
 
+struc LoadMicrocodeParamsFsp22
+; FSP_UPD_HEADER {
+.FspUpdHeaderSignature:   resd2
+.FspUpdHeaderRevision:resb1
+.FspUpdHeaderReserved:resb   23
+; }
+; FSPT_ARCH_UPD{
+.FsptArchUpd: resd8
+; }
+; FSPT_CORE_UPD {
+.MicrocodeCodeAddr:   resd1
+.MicrocodeCodeSize:   resd1
+.CodeRegionBase:  resd1
+.CodeRegionSize:  resd1
+; }
+.size:
+endstruc
 
 ;
 ; Define SSE macros
@@ -169,6 +186,11 @@ ASM_PFX(LoadMicrocodeDefault):
 
; skip loading Microcode if the MicrocodeCodeSize is zero
; and report error if size is less than 2k
+   ; first check UPD header revision
+   cmpbyte [esp + LoadMicrocodeParamsFsp22.FspUpdHeaderRevision], 2
+   jaeFsp22UpdHeader
+
+   ; UPD structure is compliant with FSP spec 2.0/2.1
moveax, dword [esp + LoadMicrocodeParams.MicrocodeCodeSize]
cmpeax, 0
jz Exit2
@@ -178,6 +200,19 @@ ASM_PFX(LoadMicrocodeDefault):
movesi, dword [esp + LoadMicrocodeParams.MicrocodeCodeAddr]
cmpesi, 0
jnzCheckMainHeader
+   jmpParamError
+
+Fsp22UpdHeader:
+   ; UPD structure is compliant with FSP spec 2.2
+   moveax, dword [esp + LoadMicrocodeParamsFsp22.MicrocodeCodeSize]
+   cmpeax, 0
+   jz Exit2
+   cmpeax, 0800h
+   jl ParamError
+
+   movesi, dword [esp + LoadMicrocodeParamsFsp22.MicrocodeCodeAddr]
+   cmpesi, 0
+   jnzCheckMainHeader
 
 ParamError:
moveax, 08002h
@@ -276,6 +311,11 @@ CheckAddress:
cmp   dword [esi + MicrocodeHdr.MicrocodeHdrVersion], 0h
jzDone
 
+   ; Check UPD header revision
+   cmpbyte [esp + LoadMicrocodeParamsFsp22.FspUpdHeaderRevision], 2
+   jaeFsp22UpdHeader1
+
+   ; UPD structure is compliant with FSP spec 2.0/2.1
; Is automatic size detection ?
mov   eax, dword [esp + LoadMicrocodeParams.MicrocodeCodeSize]
cmp   eax, 0h
@@ -287,6 +327,19 @@ CheckAddress:
jae   Done;Jif address is outside of microcode region
jmp   CheckMainHeader
 
+Fsp22UpdHeader1:
+   ; UPD structure is compliant with FSP spec 2.2
+   ; Is automatic size detection ?
+   mov   eax, dword [esp + LoadMicrocodeParamsFsp22.MicrocodeCodeSize]
+   cmp   eax, 0h
+   jzLoadMicrocodeDefault4
+
+   ; Address >= microcode region address + microcode region size?
+   add   eax, dword [esp + LoadMicrocodeParamsFsp22.MicrocodeCodeAddr]
+   cmp   esi, eax
+   jae   Done;Jif address is outside of microcode region
+   jmp   CheckMainHeader
+
 LoadMicrocodeDefault4:
 LoadCheck:
; Get the revision of the current microcode update loaded
@@ -349,11 +402,26 @@ ASM_PFX(EstablishStackFsp):
 
   push  DATA_LEN_OF_MCUD ; Size of the data region
   push  4455434Dh; Signature of the  data region 'MCUD'
-  push  dword [edx + 2Ch]; Code size   sizeof(FSPT_UPD_COMMON) + 12
-  push  dword [edx + 28h]; Code base   sizeof(FSPT_UPD_COMMON) + 8
-  push  dword [edx + 24h]; Microcode size  sizeof(FSPT_UPD_COMMON) + 4
-  push  dword [edx + 20h]; Microcode base  sizeof(FSPT_UPD_COMMON) + 0
 
+  ; check UPD structure revision (edx + 8)
+  cmp   byte [edx + LoadMicrocodeParamsFsp22.FspUpdHeaderRevision], 2
+  jae   Fsp22UpdHeader2
+
+  ; UPD structure is compliant with FSP spec 2.0/2.1
+  push  dword [edx + LoadMicrocodeParams.CodeRegionSize] ; Code size   
sizeof(FSPT_UPD_COMMON) + 12
+  

[edk2-devel] [PATCH v2 2/2] IntelFsp2WrapperPkg: Add FSP*_ARCH_UPD.

[Chiu, Chasel]

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

Provides sample code to include FSPT_ARCH_UPD initial values with
UPD header revision set to 2.

Cc: Maurice Ma 
Cc: Nate DeSimone 
Cc: Star Zeng 
Signed-off-by: Chasel Chiu 
---
 IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c 
| 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
index 2d1368c3ed..96b47e23da 100644
--- 
a/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
+++ 
b/IntelFsp2WrapperPkg/Library/SecFspWrapperPlatformSecLibSample/SecRamInitData.c
@@ -1,7 +1,7 @@
 /** @file
   Sample to provide TempRamInitParams data.
 
-  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2014 - 2020, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -18,17 +18,39 @@ typedef struct {
 
 typedef struct {
   FSP_UPD_HEADERFspUpdHeader;
+  //
+  // If platform does not support FSP spec 2.2 remove FSPT_ARCH_UPD structure.
+  //
+  FSPT_ARCH_UPD FsptArchUpd;
   FSPT_CORE_UPD FsptCoreUpd;
 } FSPT_UPD_CORE_DATA;
 
 GLOBAL_REMOVE_IF_UNREFERENCED CONST FSPT_UPD_CORE_DATA FsptUpdDataPtr = {
   {
 0x4450555F54505346,
-0x00,
+//
+// UPD header revision must be equal or greater than 2 when the structure 
is compliant with FSP spec 2.2.
+//
+0x02,
 { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
 }
   },
+  //
+  // If platform does not support FSP spec 2.2 remove FSPT_ARCH_UPD structure.
+  //
+  {
+0x01,
+{
+  0x00, 0x00, 0x00
+},
+0x0020,
+0x,
+{
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+  },
   {
 ((UINT32)FixedPcdGet64 (PcdCpuMicrocodePatchAddress) + FixedPcdGet32 
(PcdFlashMicrocodeOffset)),
 ((UINT32)FixedPcdGet64 (PcdCpuMicrocodePatchRegionSize) - FixedPcdGet32 
(PcdFlashMicrocodeOffset)),
-- 
2.13.3.windows.1


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

View/Reply Online (#61485): https://edk2.groups.io/g/devel/message/61485
Mute This Topic: https://groups.io/mt/74958115/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 3/7] Platform/NXP: LX2160aRdbPkg: Add PlatformDxe driver

[Leif Lindholm]

On Wed, Jun 10, 2020 at 03:47:26 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> Add PlatformDxe to do platform specific work.
> At present it perform platform specific Pci initialization.
 
> Signed-off-by: Wasim Khan 
> ---
>  Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf | 35 +
>  Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.c   | 78 
> 
>  2 files changed, 113 insertions(+)
> 
> diff --git a/Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf 
> b/Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf
> new file mode 100644
> index ..2514adf1d69d
> --- /dev/null
> +++ b/Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.inf
> @@ -0,0 +1,35 @@
> +## @file
> +#
> +#  Copyright 2020 NXP
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION   = 0x00010019
> +  BASE_NAME = PlatformDxe
> +  FILE_GUID = C4063EBA-7729-11EA-BC55-0232AC130003
> +  MODULE_TYPE   = DXE_DRIVER
> +  VERSION_STRING= 1.0
> +  ENTRY_POINT   = PlatformDxeEntryPoint
> +
> +[Sources]
> +  PlatformDxe.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  Silicon/NXP/Chassis3V2/Chassis3V2.dec
> +  Silicon/NXP/LX2160A/LX2160A.dec
> +  Silicon/NXP/NxpQoriqLs.dec
> +
> +[LibraryClasses]
> +  PcdLib
> +  UefiDriverEntryPoint
> +
> +[Pcd]
> +  gNxpQoriqLsTokenSpaceGuid.PcdPciCfgShiftEnable
> +  gNxpQoriqLsTokenSpaceGuid.PcdPciLsGen4Ctrl
> +
> +[Depex]
> +  TRUE
> diff --git a/Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.c 
> b/Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.c
> new file mode 100644
> index ..73599aaeb7bf
> --- /dev/null
> +++ b/Platform/NXP/LX2160aRdbPkg/Drivers/PlatformDxe/PlatformDxe.c
> @@ -0,0 +1,78 @@
> +/** @file
> +*
> +*  Copyright 2020 NXP
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Enable PciCfgShift feature for LX2160-Rev2

... which means what?

> +
> +**/
> +VOID
> +EnableCfgShift (

But even more importantly, that isn't what this function does:

> +  VOID
> +  )
> +{
> +  UINT32 Svr;
> +
> +  Svr = SocGetSvr ();
> +  if ((SVR_SOC_VER(Svr) == SVR_LX2160A) && (SVR_MAJOR(Svr) == 0x2)) {

... it performs variant/version detection and sets feature flags based
on it. The fact that it currently happens to be setting only a single
flag shouldn't mean that in order to understand what PlatformPciInit()
does even at a high level, I need to know what an "EnableCfgShift" is.

The function should be called something like DetectSocVersion,
EnableSocRevisionWorkarounds, or something other descriptive.

*Then* there should be a comment here describing what
PcdPciCfgShiftEnable is and what it does.

> +PcdSetBoolS (PcdPciCfgShiftEnable, TRUE);
> +  }
> +}
> +
> +/**
> +  Enable Layerscape Gen4 controller for LX2160A-Rev1
> +
> +**/
> +VOID
> +EnablePciController (
> +  VOID
> +  )
> +{
> +  UINT32 Svr;
> +
> +  Svr = SocGetSvr ();
> +  if ((SVR_SOC_VER(Svr) == SVR_LX2160A) && (SVR_MAJOR(Svr) == 0x1)) {
> +PcdSetBoolS (PcdPciLsGen4Ctrl, TRUE);

Again, this doesn't *enable* a controller, which is what the function
name says it does. It sets a Pcd, which is then used by subsequent
code. I don't know if this function should be smashed together with
the previous one under an even more generic name, but this too
motivates a comment on what a PcdPciLsGen4Ctrl is.

> +  }
> +}
> +
> +/**
> +  Platfrom Specific PCI Initialization

Platform

/
Leif

> +
> +**/
> +VOID
> +PlatformPciInit (
> +  VOID
> +  )
> +{
> +  EnableCfgShift ();
> +  EnablePciController ();
> +}
> +
> +/**
> +  The entry point for PlatformDxe driver. This driver
> +  intends to perform platform specific initialization.
> +
> +  @param[in] ImageHandle The image handle of the driver.
> +  @param[in] SystemTable The system table.
> +
> +  @retval EFI_SUCCESS Driver initialization success.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +PlatformDxeEntryPoint (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *SystemTable
> +  )
> +{
> +  // Platfrom Specific PCI Initialization
> +  PlatformPciInit ();
> +  return EFI_SUCCESS;
> +}
> -- 
> 2.7.4
> 

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

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

Re: [edk2-devel] [patch] MdeModulePkg/DisplayEngine: Add Debug message to show mismatch menu info

[Laszlo Ersek]

On 06/18/20 05:24, Dandan Bi wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2326
> 
> Currently when meet mismatch case for one-of and ordered-list
> menu, just show a popup window to indicate mismatch, no more
> info for debugging. This patch is to add more debug message
> about mismatch menu info which is helpful to debug.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Signed-off-by: Dandan Bi 
> ---
>  .../DisplayEngineDxe/ProcessOptions.c | 78 +++
>  1 file changed, 78 insertions(+)
> 
> diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c 
> b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> index e7306f6d04..4331b2903c 100644
> --- a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> +++ b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> @@ -911,10 +911,73 @@ PasswordProcess (
>FreePool (StringPtr);
>  
>return Status;
>  }
>  
> +/**
> +  Print some debug message about mismatched menu info.
> +
> +  @param  MenuOption The MenuOption for this Question.
> +
> +**/
> +VOID
> +PrintMismatchMenuInfo (
> +  IN  UI_MENU_OPTION  *MenuOption
> +)
> +{
> +  CHAR16  *FormTitleStr;
> +  CHAR16  *OneOfOptionStr;
> +  CHAR16  *QuestionName;
> +  LIST_ENTRY  *Link;
> +  FORM_DISPLAY_ENGINE_STATEMENT   *Question;
> +  EFI_IFR_ORDERED_LIST*OrderList;
> +  UINTN   Index;
> +  EFI_HII_VALUE   HiiValue;
> +  EFI_HII_VALUE   *QuestionValue;
> +  DISPLAY_QUESTION_OPTION *Option;
> +  UINT8   *ValueArray;
> +  UINT8   ValueType;
> +
> +  Question = MenuOption->ThisTag;
> +  FormTitleStr = GetToken (gFormData->FormTitle, gFormData->HiiHandle);
> +
> +  DEBUG ((DEBUG_ERROR, "\n[DisplayEngine]: Mismatch Formset: Formset 
> Guid = %g.\n", >FormSetGuid));

I suggest replacing the open-coded "[DisplayEngine]" strings in this
patch with "[%a]", and passing gEfiCallerBaseName.

This will make no difference in practice (given "BASE_NAME =
DisplayEngine" in "DisplayEngineDxe.inf"), but it's a better pattern --
the resultant debug strings are less verbose, and they'd update
themselves if we ever changed BASE_NAME.

No other comments from me.

Thanks,
Laszlo

> +  DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch Form   : FormId = %d,  
> Form title = %s.\n", gFormData->FormId, FormTitleStr));
> +
> +  if (Question->OpCode->OpCode == EFI_IFR_ORDERED_LIST_OP) {
> +QuestionName = GetToken 
> (((EFI_IFR_ORDERED_LIST*)MenuOption->ThisTag->OpCode)->Question.Header.Prompt,
>  gFormData->HiiHandle);
> +Link = GetFirstNode (>OptionListHead);
> +Option = DISPLAY_QUESTION_OPTION_FROM_LINK (Link);
> +ValueType = Option->OptionOpCode->Type;
> +
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OrderedList: Name = 
> %s.\n", QuestionName));
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OrderedList: Value 
> Arrary:\n"));
> +
> +OrderList = (EFI_IFR_ORDERED_LIST *) Question->OpCode;
> +for (Index = 0; Index < OrderList->MaxContainers; Index++) {
> +  ValueArray = Question->CurrentValue.Buffer;
> +  HiiValue.Value.u64 = GetArrayData (ValueArray, ValueType, Index);
> +  DEBUG ((DEBUG_ERROR, "   Value[%d] 
> =%d.\n",Index, HiiValue.Value.u64));
> +}
> +  } else if (Question->OpCode->OpCode == EFI_IFR_ONE_OF_OP) {
> +QuestionName = GetToken 
> (((EFI_IFR_ONE_OF*)MenuOption->ThisTag->OpCode)->Question.Header.Prompt, 
> gFormData->HiiHandle);
> +QuestionValue = >CurrentValue;;
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OneOf  : Named = 
> %s.\n", QuestionName));
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OneOf  : Current 
> value = %d.\n",QuestionValue->Value.u8));
> +  }
> +
> +  Index = 0;
> +  Link = GetFirstNode (>OptionListHead);
> +  while (!IsNull (>OptionListHead, Link)) {
> +Option = DISPLAY_QUESTION_OPTION_FROM_LINK (Link);
> +OneOfOptionStr = GetToken (Option->OptionOpCode->Option, 
> gFormData->HiiHandle);
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Option %d: Option 
> Name = %s. Option Value = 
> %d.\n",Index,OneOfOptionStr,Option->OptionOpCode->Value.u8));
> +Link = GetNextNode (>OptionListHead, Link);
> +Index++;
> +  }
> +}
> +
>  /**
>Process a Question's Option (whether selected or un-selected).
>  
>@param  MenuOption The MenuOption for this Question.
>@param  Selected   TRUE: if Question is selected.
> @@ -1010,10 +1073,15 @@ ProcessOptions (
>break;
>  }
>  
>  OneOfOption = ValueToOption (Question, );
>  if (OneOfOption == NULL) {
> +  //
> +  // Print debug msg for the mistach menu.
> +  //
> +  PrintMismatchMenuInfo (MenuOption);
> +
>   

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Laszlo Ersek]

On 06/17/20 19:23, Igor Druzhinin wrote:
> On 17/06/2020 17:59, Paolo Bonzini wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
>> unless you have verified the sender and know the content is safe.
>>
>> On 17/06/20 17:46, Laszlo Ersek wrote:
 That said, Igor's patch seems correct to me.  In fact, I'd even move
 DisableInterrupts before gBS->RestoreTPL unless there's a good reason
 not to do so.
>>> OK, thank you!
>>>
>>> Igor, please confirm if you'd like to submit v2 with the update
>>> suggested by Paolo, or if you prefer the current version. We're at the
>>> beginning of the current development cycle, so I guess we can apply the
>>> patch and see how it works in practice. If it ends up wreaking havoc on
>>> some platforms, we can always revert the patch in time for the next
>>> stable tag (edk2-stable202008).
>>
>> For what it's worth "correct" means that I don't see anything that could
>> break and in fact I find it good policy hygienic not to allow recursive
>> interrupts.
>>
>> v1 is okay for me too, so:
>>
>> Reviewed-by: Paolo Bonzini 
> 
> Thanks, unfortunately it's not possible to move DisableInterrupts inside
> TPL block as RestoreTPL would immediately enable them according to current
> logic.
> 
> IMO RaiseTPL could technically save interrupt state inside it (in that
> case it was disabled) and then honor it in RestoreTPL but that might have
> more surprise consequences than the proposed change I reckon.
> 
> I will create a BZ ticket as requested.

Merged via  as commit
239b50a86370, with the following updates:

[ler...@redhat.com: add BZ ref; rewrap msg to silence PatchCheck.py]

Thanks!
Laszlo


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

View/Reply Online (#61480): https://edk2.groups.io/g/devel/message/61480
Mute This Topic: https://groups.io/mt/74913405/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/7] Platform/NXP: LX2160aRdbPkg: Add PCIe space in VirtualMemoryMap

[Wasim Khan (OSS)]

> -Original Message-
> From: Leif Lindholm 
> Sent: Thursday, June 18, 2020 3:22 PM
> To: Wasim Khan (OSS) 
> Cc: devel@edk2.groups.io; Meenakshi Aggarwal
> ; Varun Sethi ;
> ard.biesheu...@arm.com; Wasim Khan 
> Subject: Re: [PATCH edk2-platforms 1/7] Platform/NXP: LX2160aRdbPkg: Add
> PCIe space in VirtualMemoryMap
> 
> On Wed, Jun 10, 2020 at 03:47:24 +0530, Wasim Khan wrote:
> > From: Wasim Khan 
> >
> > Add PCIe space in VirtualMemoryMap
> 
> You appear to be adding six spaces to the memory map, not one.
> 
> I may know why, but most people do not. Please describe in the commit
> message what the spaces are and why there's six of them.

Thank for the review.
We have six PCIe controller on LX2160 SoC. Multiple PCIe controller may get 
enabled based on RCW.
OK, I will update the commit message.

> 
> /
> Leif
> 
> > Signed-off-by: Wasim Khan 
> > ---
> >  Silicon/NXP/LX2160A/Include/Soc.h |  8 
> > +
> >
> Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c
> > | 38 +++-
> >  2 files changed, 45 insertions(+), 1 deletion(-)
> >
> > diff --git a/Silicon/NXP/LX2160A/Include/Soc.h
> > b/Silicon/NXP/LX2160A/Include/Soc.h
> > index 6c745d580a6d..7e6359485aaf 100644
> > --- a/Silicon/NXP/LX2160A/Include/Soc.h
> > +++ b/Silicon/NXP/LX2160A/Include/Soc.h
> > @@ -26,6 +26,14 @@
> >  #define LX2160A_FSPI0_PHYS_ADDRESS   (BASE_512MB)
> >  #define LX2160A_FSPI0_SIZE   (SIZE_256MB)
> >
> > +#define LX2160A_PCI1_PHYS_ADDRESS0x80
> > +#define LX2160A_PCI2_PHYS_ADDRESS0x88
> > +#define LX2160A_PCI3_PHYS_ADDRESS0x90
> > +#define LX2160A_PCI4_PHYS_ADDRESS0x98
> > +#define LX2160A_PCI5_PHYS_ADDRESS0xa0
> > +#define LX2160A_PCI6_PHYS_ADDRESS0xa8
> > +#define LX2160A_PCI_SIZE SIZE_32GB
> > +
> >  #define LX2160A_DCFG_ADDRESS
> NXP_LAYERSCAPE_CHASSIS3V2_DCFG_ADDRESS
> >
> >  // SVR
> > diff --git
> >
> a/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.
> > c
> >
> b/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.
> > c index 391dab265ad7..c03bc23f4a1d 100644
> > ---
> >
> a/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.
> > c
> > +++ b/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLib
> > +++ Mem.c
> > @@ -12,7 +12,7 @@
> >  #include   #include 
> >
> > -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  6
> > +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  12
> >
> >  /**
> >Return the Virtual Memory Map of your platform @@ -71,6 +71,42 @@
> > ArmPlatformGetVirtualMemoryMap (
> >VirtualMemoryTable[Index].Length   = LX2160A_FSPI0_SIZE;
> >VirtualMemoryTable[Index++].Attributes =
> > ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> >
> > +  // PCIe1
> > +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI1_PHYS_ADDRESS;
> > + VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI1_PHYS_ADDRESS;
> > +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> > +  VirtualMemoryTable[Index++].Attributes   =
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  // PCIe2
> > +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI2_PHYS_ADDRESS;
> > + VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI2_PHYS_ADDRESS;
> > +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> > +  VirtualMemoryTable[Index++].Attributes   =
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  // PCIe3
> > +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI3_PHYS_ADDRESS;
> > + VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI3_PHYS_ADDRESS;
> > +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> > +  VirtualMemoryTable[Index++].Attributes   =
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  // PCIe4
> > +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI4_PHYS_ADDRESS;
> > + VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI4_PHYS_ADDRESS;
> > +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> > +  VirtualMemoryTable[Index++].Attributes   =
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  // PCIe5
> > +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI5_PHYS_ADDRESS;
> > + VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI5_PHYS_ADDRESS;
> > +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> > +  VirtualMemoryTable[Index++].Attributes   =
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  // PCIe6
> > +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI6_PHYS_ADDRESS;
> > + VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI6_PHYS_ADDRESS;
> > +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> > +  VirtualMemoryTable[Index++].Attributes   =
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> >// End of Table
> >ZeroMem ([Index], sizeof
> > (ARM_MEMORY_REGION_DESCRIPTOR));
> >
> > --
> > 2.7.4
> >

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

View/Reply 

Re: [edk2-devel] [PATCH edk2-platforms 2/7] Silicon/NXP: LX2160A: Define PCIe related PCDs

[Wasim Khan (OSS)]

> -Original Message-
> From: Leif Lindholm 
> Sent: Thursday, June 18, 2020 3:38 PM
> To: Wasim Khan (OSS) 
> Cc: devel@edk2.groups.io; Meenakshi Aggarwal
> ; Varun Sethi ;
> ard.biesheu...@arm.com; Wasim Khan 
> Subject: Re: [PATCH edk2-platforms 2/7] Silicon/NXP: LX2160A: Define PCIe
> related PCDs
> 
> On Wed, Jun 10, 2020 at 03:47:25 +0530, Wasim Khan wrote:
> > From: Wasim Khan 
> >
> > Define PCIe related PCDs for LX2160A.
> >
> > Signed-off-by: Wasim Khan 
> > ---
> >  Silicon/NXP/LX2160A/LX2160A.dsc.inc | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > b/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > index fe8ed402fc4e..43e361464c8e 100644
> > --- a/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > +++ b/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> > @@ -38,6 +38,11 @@ [PcdsFixedAtBuild.common]
> >gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
> >gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x21C
> >
> > +  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr|0x80
> 
> This is already provided by LX2160A_PCI1_PHYS_ADDRESS in
> Silicon/NXP/LX2160A/Include/Soc.h, and PCI_SEG0_MMIO_MEMBASE would be
> better described as an alias of that. Unless the NXP
> PciHostBridgeLib/PciSegmentLib is intended to be shared with SoCs where these
> base addresses can be different in different platforms.

Yes, PciHostBridgeLib/PciSegmentLib are shared with different SoC with 
different base address and number of PCIe controllers.

> 
> If so, the PHYS_ADDRESSES would be better defined as derivatives of
> PcdPciExp1BaseAddr.

OK, I will use PcdPciExp1BaseAddr and PcdNumPciController for PHYS_ADDRESSES

> 
> > +  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|6
> 
> Is this number possible to be different for different platforms based on the 
> same
> SoC?

This is the total number of PCIe controller on a SoC (for LS1043 its 3, for 
LX2160 its 6)
A platform may use few of them based on the RCW (For Ex: LX2160aRdbPkg has only 
PEX3 and PEX5 . LX2160aQdsPkg may have all 6 controller enabled).

> 
> /
> Leif
> 
> > +  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase|0x8
> > +  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg|0x407FC
> > +
> >  [PcdsFeatureFlag]
> >gNxpQoriqLsTokenSpaceGuid.PcdI2cErratumA009203|TRUE
> >
> > --
> > 2.7.4
> >

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

View/Reply Online (#61477): https://edk2.groups.io/g/devel/message/61477
Mute This Topic: https://groups.io/mt/74793011/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 2/8] Silicon/NXP: Chassis2: define SVR macros

[Wasim Khan (OSS)]

> -Original Message-
> From: Leif Lindholm 
> Sent: Wednesday, June 17, 2020 8:24 PM
> To: Wasim Khan (OSS) 
> Cc: devel@edk2.groups.io; Meenakshi Aggarwal
> ; Varun Sethi ;
> ard.biesheu...@arm.com; Wasim Khan 
> Subject: Re: [PATCH edk2-platforms 2/8] Silicon/NXP: Chassis2: define SVR
> macros
> 
> On Wed, Jun 10, 2020 at 02:50:53 +0530, Wasim Khan wrote:
> > From: Wasim Khan 
> >
> > Define macros to retrieve System Version Register(SVR) related
> > information
> >
> > Signed-off-by: Wasim Khan 
> > ---
> >  Silicon/NXP/Chassis2/Include/Chassis.h | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Silicon/NXP/Chassis2/Include/Chassis.h
> > b/Silicon/NXP/Chassis2/Include/Chassis.h
> > index e5edd80134a4..7e8bf224884b 100644
> > --- a/Silicon/NXP/Chassis2/Include/Chassis.h
> > +++ b/Silicon/NXP/Chassis2/Include/Chassis.h
> > @@ -12,6 +12,10 @@
> >
> >  #define  NXP_LAYERSCAPE_CHASSIS2_DCFG_ADDRESS  0x1EE
> >
> > +#define SVR_SOC_VER(svr)(((svr) >> 8) & 0xFE)
> > +#define SVR_MAJOR(svr)  (((svr) >> 4) & 0xf)
> > +#define SVR_MINOR(svr)  (((svr) >> 0) & 0xf)
> > +
> >  /* SMMU Defintions */
> >  #define SMMU_BASE_ADDR 0x0900
> >  #define SMMU_REG_SCR0  (SMMU_BASE_ADDR + 0x0)
> 
> These macros are identical between Chassis2 and Chassis3V2, and they also look
> like exactly the sort of thing you want identical across different chassis. 
> Is there
> a common header file they can use?

Thank you Leif for the review. 
These MACROS are chassic specific. Upper 24 bits representation is different in 
Chassis2 and Chassis3V2 (although not used currently and masked for SVR 
calculation but we may need it in future). 
SVR representation may further change for future SoC, so we would like to keep 
them in chassis specific header file.


> 
> (The set is straightforward, I have no other comments on it.)
> 
> /
> Leif
> 
> > --
> > 2.7.4
> >

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

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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Regenerate boot options on boot failure

[Ard Biesheuvel]

On 6/17/20 11:33 PM, Samer El-Haj-Mahmoud wrote:

Port tianocore/edk2@2d233af64b8f73d1b1e138b302e6344f7c2e0f4e

This enables network boot by default on RPi first boot, when all other
boot options fail. This is required for unattended/headless boot cases.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 


'Series' pushed as

d2c797e22184 Platforms/RaspberryPi: Fix SMBIOS Type 9
b2bc8596e2ac Platforms/RaspberryPi: Add SMBIOS Type 11
8dd78ea11a38 Platforms/RaspberryPi: Regenerate boot options on boot failure

Thanks,



---
  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c | 36 
+++-
  1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
index cb74d65b7f91..fa46be791732 100644
--- a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
@@ -4,7 +4,7 @@
   *  Copyright (c) 2017-2018, Andrei Warkentin 
   *  Copyright (c) 2016, Linaro Ltd. All rights reserved.
   *  Copyright (c) 2015-2016, Red Hat, Inc.
- *  Copyright (c) 2014, ARM Ltd. All rights reserved.
+ *  Copyright (c) 2014-2020, ARM Ltd. All rights reserved.
   *  Copyright (c) 2004-2016, Intel Corporation. All rights reserved.
   *
   *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -700,6 +700,40 @@ PlatformBootManagerUnableToBoot (
EFI_INPUT_KEYKey;
EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
UINTNIndex;
+  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;
+  UINTNOldBootOptionCount;
+  UINTNNewBootOptionCount;
+
+  //
+  // Record the total number of boot configured boot options
+  //
+  BootOptions = EfiBootManagerGetLoadOptions (,
+  LoadOptionTypeBoot);
+  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);
+
+  //
+  // Connect all devices, and regenerate all boot options
+  //
+  EfiBootManagerConnectAll ();
+  EfiBootManagerRefreshAllBootOption ();
+
+  //
+  // Record the updated number of boot configured boot options
+  //
+  BootOptions = EfiBootManagerGetLoadOptions (,
+  LoadOptionTypeBoot);
+  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);
+
+  //
+  // If the number of configured boot options has changed, reboot
+  // the system so the new boot options will be taken into account
+  // while executing the ordinary BDS bootflow sequence.
+  //
+  if (NewBootOptionCount != OldBootOptionCount) {
+DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot options\n",
+  __FUNCTION__));
+gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
+  }
  
//

// BootManagerMenu doesn't contain the correct information when return 
status




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

View/Reply Online (#61476): https://edk2.groups.io/g/devel/message/61476
Mute This Topic: https://groups.io/mt/74947044/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] Silicon/Broadcom/BcmGenetDxe: implement media state adapter info protocol

[Ard Biesheuvel]

On 6/17/20 8:22 PM, Samer El-Haj-Mahmoud wrote:

Tested on RPi4 w/ 4GB

Reviewed-by: Samer El-Haj-Mahmoud 



Thanks

Pushed as 743f501b66db712d486347ddca781ffc705c1766


-Original Message-
From: Ard Biesheuvel 
Sent: Wednesday, June 17, 2020 2:15 PM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Pete Batard
; Andrei Warkentin (awarken...@vmware.com)
; Samer El-Haj-Mahmoud 
Subject: [PATCH edk2-platforms v2] Silicon/Broadcom/BcmGenetDxe:
implement media state adapter info protocol

NetLibDetectMedia () in DxeNetLib is used as a fallback on implementations
of the SNP protocol that do not also carry an implementation of the adapter
info protocol to provide media state information, and it does all kinds of
terrible things to the network interface (stopping and restarting multiple
times, reprogramming the multicast filters etc etc) to workaround some
alleged UNDI shortcoming.

Although our GENET code should be bullet proof and therefore able to take
this kind of abuse, it is better to avoid it, and provide an implementation
of the adapter info protocol that returns the media state directly, without
the need to mistreat the SNP layer.


Cc: Pete Batard 

Cc: Andrei Warkentin (awarken...@vmware.com)


Cc: Samer El-Haj-Mahmoud 

Signed-off-by: Ard Biesheuvel 
---

v2:

- use the correct accessor to retrieve the GENET_PRIVATE_DATA pointer

- call into the PHY routines to get the state, to ensure it is not stale


  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf |   3 +
  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h   |   5 +
  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c   | 106

  Silicon/Broadcom/Drivers/Net/BcmGenetDxe/DriverBinding.c |  12 ++-
  4 files changed, 121 insertions(+), 5 deletions(-)

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
index 28f3e66ebaf0..89dee9f10c83 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf
@@ -19,6 +19,7 @@ [Defines]
UNLOAD_IMAGE   = GenetUnload



  [Sources]

+  AdapterInfo.c

BcmGenetDxe.h

ComponentName.c

DriverBinding.c

@@ -49,10 +50,12 @@ [LibraryClasses]


  [Protocols]

gBcmGenetPlatformDeviceProtocolGuid ## TO_START

+  gEfiAdapterInformationProtocolGuid  ## BY_START

gEfiDevicePathProtocolGuid  ## BY_START

gEfiSimpleNetworkProtocolGuid   ## BY_START



  [Guids]

+  gEfiAdapterInfoMediaStateGuid

gEfiEventExitBootServicesGuid



  [FixedPcd]

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
index 0af9d5209cf2..1a117b25f87f 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.h
@@ -14,6 +14,7 @@
  #include 

  #include 

  #include 

+#include 

  #include 

  #include 

  #include 

@@ -209,6 +210,8 @@ typedef struct {
EFI_SIMPLE_NETWORK_PROTOCOL Snp;

EFI_SIMPLE_NETWORK_MODE SnpMode;



+  EFI_ADAPTER_INFORMATION_PROTOCOLAip;

+

BCM_GENET_PLATFORM_DEVICE_PROTOCOL  *Dev;



GENERIC_PHY_PRIVATE_DATAPhy;

@@ -234,9 +237,11 @@ extern EFI_COMPONENT_NAME_PROTOCOL
gGenetComponentName;
  extern EFI_COMPONENT_NAME2_PROTOCOL
gGenetComponentName2;



  extern CONST EFI_SIMPLE_NETWORK_PROTOCOL
gGenetSimpleNetworkTemplate;

+extern CONST EFI_ADAPTER_INFORMATION_PROTOCOL
gGenetAdapterInfoTemplate;



  #define GENET_DRIVER_SIGNATURESIGNATURE_32('G', 'N', 'E', 'T')

  #define GENET_PRIVATE_DATA_FROM_SNP_THIS(a)   CR(a,
GENET_PRIVATE_DATA, Snp, GENET_DRIVER_SIGNATURE)

+#define GENET_PRIVATE_DATA_FROM_AIP_THIS(a)   CR(a,
GENET_PRIVATE_DATA, Aip, GENET_DRIVER_SIGNATURE)



  #define GENET_RX_BUFFER(g, idx)   ((UINT8 *)(UINTN)(g)->RxBuffer +
GENET_MAX_PACKET_SIZE * (idx))



diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
new file mode 100644
index ..4b42b2bba67a
--- /dev/null
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/AdapterInfo.c
@@ -0,0 +1,106 @@
+/** @file

+

+  Copyright (c) 2020 Arm, Limited. All rights reserved.

+

+  SPDX-License-Identifier: BSD-2-Clause-Patent

+

+**/

+

+#include 

+#include 

+#include 

+#include 

+

+#include "BcmGenetDxe.h"

+

+STATIC

+EFI_STATUS

+EFIAPI

+GenetAipGetInformation (

+  IN  EFI_ADAPTER_INFORMATION_PROTOCOL  *This,

+  IN  EFI_GUID  *InformationType,

+  OUT VOID  **InformationBlock,

+  OUT UINTN *InformationBlockSize

+  )

+{

+  EFI_ADAPTER_INFO_MEDIA_STATE  *AdapterInfo;

+  GENET_PRIVATE_DATA*Genet;

+

+  if (This == NULL || InformationBlock == NULL ||

+  InformationBlockSize == NULL) {

+

Re: [edk2-devel] [PATCH edk2-platforms 2/7] Silicon/NXP: LX2160A: Define PCIe related PCDs

[Leif Lindholm]

On Wed, Jun 10, 2020 at 03:47:25 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> Define PCIe related PCDs for LX2160A.
> 
> Signed-off-by: Wasim Khan 
> ---
>  Silicon/NXP/LX2160A/LX2160A.dsc.inc | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Silicon/NXP/LX2160A/LX2160A.dsc.inc 
> b/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> index fe8ed402fc4e..43e361464c8e 100644
> --- a/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> +++ b/Silicon/NXP/LX2160A/LX2160A.dsc.inc
> @@ -38,6 +38,11 @@ [PcdsFixedAtBuild.common]
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x21C
>  
> +  gNxpQoriqLsTokenSpaceGuid.PcdPciExp1BaseAddr|0x80

This is already provided by LX2160A_PCI1_PHYS_ADDRESS in
Silicon/NXP/LX2160A/Include/Soc.h, and PCI_SEG0_MMIO_MEMBASE would be
better described as an alias of that. Unless the NXP
PciHostBridgeLib/PciSegmentLib is intended to be shared with SoCs
where these base addresses can be different in different platforms.

If so, the PHYS_ADDRESSES would be better defined as derivatives of
PcdPciExp1BaseAddr.

> +  gNxpQoriqLsTokenSpaceGuid.PcdNumPciController|6

Is this number possible to be different for different platforms based
on the same SoC?

/
Leif

> +  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutBase|0x8
> +  gNxpQoriqLsTokenSpaceGuid.PcdPcieLutDbg|0x407FC
> +
>  [PcdsFeatureFlag]
>gNxpQoriqLsTokenSpaceGuid.PcdI2cErratumA009203|TRUE
>  
> -- 
> 2.7.4
> 

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

View/Reply Online (#61474): https://edk2.groups.io/g/devel/message/61474
Mute This Topic: https://groups.io/mt/74793011/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/7] Platform/NXP: LX2160aRdbPkg: Add PCIe space in VirtualMemoryMap

[Leif Lindholm]

On Wed, Jun 10, 2020 at 03:47:24 +0530, Wasim Khan wrote:
> From: Wasim Khan 
> 
> Add PCIe space in VirtualMemoryMap

You appear to be adding six spaces to the memory map, not one.

I may know why, but most people do not. Please describe in the commit
message what the spaces are and why there's six of them.

/
Leif

> Signed-off-by: Wasim Khan 
> ---
>  Silicon/NXP/LX2160A/Include/Soc.h |  8 
> +
>  Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c | 38 
> +++-
>  2 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/Silicon/NXP/LX2160A/Include/Soc.h 
> b/Silicon/NXP/LX2160A/Include/Soc.h
> index 6c745d580a6d..7e6359485aaf 100644
> --- a/Silicon/NXP/LX2160A/Include/Soc.h
> +++ b/Silicon/NXP/LX2160A/Include/Soc.h
> @@ -26,6 +26,14 @@
>  #define LX2160A_FSPI0_PHYS_ADDRESS   (BASE_512MB)
>  #define LX2160A_FSPI0_SIZE   (SIZE_256MB)
>  
> +#define LX2160A_PCI1_PHYS_ADDRESS0x80
> +#define LX2160A_PCI2_PHYS_ADDRESS0x88
> +#define LX2160A_PCI3_PHYS_ADDRESS0x90
> +#define LX2160A_PCI4_PHYS_ADDRESS0x98
> +#define LX2160A_PCI5_PHYS_ADDRESS0xa0
> +#define LX2160A_PCI6_PHYS_ADDRESS0xa8
> +#define LX2160A_PCI_SIZE SIZE_32GB
> +
>  #define LX2160A_DCFG_ADDRESS NXP_LAYERSCAPE_CHASSIS3V2_DCFG_ADDRESS
>  
>  // SVR
> diff --git 
> a/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c 
> b/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c
> index 391dab265ad7..c03bc23f4a1d 100644
> --- a/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c
> +++ b/Platform/NXP/LX2160aRdbPkg/Library/ArmPlatformLib/ArmPlatformLibMem.c
> @@ -12,7 +12,7 @@
>  #include 
>  #include 
>  
> -#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  6
> +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  12
>  
>  /**
>Return the Virtual Memory Map of your platform
> @@ -71,6 +71,42 @@ ArmPlatformGetVirtualMemoryMap (
>VirtualMemoryTable[Index].Length   = LX2160A_FSPI0_SIZE;
>VirtualMemoryTable[Index++].Attributes = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>  
> +  // PCIe1
> +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI1_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI1_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> +  VirtualMemoryTable[Index++].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> +
> +  // PCIe2
> +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI2_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI2_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> +  VirtualMemoryTable[Index++].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> +
> +  // PCIe3
> +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI3_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI3_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> +  VirtualMemoryTable[Index++].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> +
> +  // PCIe4
> +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI4_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI4_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> +  VirtualMemoryTable[Index++].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> +
> +  // PCIe5
> +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI5_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI5_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> +  VirtualMemoryTable[Index++].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> +
> +  // PCIe6
> +  VirtualMemoryTable[Index].PhysicalBase = LX2160A_PCI6_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].VirtualBase  = LX2160A_PCI6_PHYS_ADDRESS;
> +  VirtualMemoryTable[Index].Length   = LX2160A_PCI_SIZE;
> +  VirtualMemoryTable[Index++].Attributes   = 
> ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> +
>// End of Table
>ZeroMem ([Index], sizeof 
> (ARM_MEMORY_REGION_DESCRIPTOR));
>  
> -- 
> 2.7.4
> 

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

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

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Laszlo Ersek]

On 06/18/20 10:36, Laszlo Ersek wrote:
> On 06/17/20 19:23, Igor Druzhinin wrote:

>> I will create a BZ ticket as requested.
> 
> Thanks -- please follow up with the URL

nevermind, I've found, in my bugmail:

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

Thanks
Laszlo


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

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

Re: [edk2-devel] [patch] MdeModulePkg/DisplayEngine: Add Debug message to show mismatch menu info

[Dandan Bi]

Hi Eric,

For example:

For one of, if its current value is 4, but there is no option with value 4, 
then it will pop up mismatch window and the debug message like below.
[DisplayEngine]: Mismatch Formset: Formset Guid = 
9E0C30BC-3F06-4BA6-8288-09179B855DBE.
[DisplayEngine]: Mismatch Form : FormId = 4096,  Form title = Front 
Page.
[DisplayEngine]: Mismatch OneOf  : Named = Select Language.
[DisplayEngine]: Mismatch OneOf  : Current value = 4.
[DisplayEngine]: Option 0 : Option Name = Standard English. 
Option Value = 0.
[DisplayEngine]: Option 1 : Option Name = Standard 
Franτais. Option Value = 1.
[DisplayEngine]: Option 2 : Option Name = English. Option 
Value = 2.
[DisplayEngine]: Option 3 : Option Name = Franτais. Option 
Value = 3.

For OrderedList, its value is in the type of array, if one of array value is 4, 
but there is no option with value 4, then it will pop up mismatch window and 
the debug message like below.
[DisplayEngine]: Mismatch Formset   : Formset Guid = 
A04A27F4-DF00-4D42-B552-39511302113D.
[DisplayEngine]: Mismatch Form: FormId = 1,  Form title = My First 
Setup Page.
[DisplayEngine]: Mismatch OrderedList: Name = Boot Order.
[DisplayEngine]: Mismatch OrderedList: Value Arrary:

Value[0] =4.

Value[1] =1.

Value[2] =3.

Value[3] =0.

Value[4] =0.

Value[5] =0.

Value[6] =0.

Value[7] =0.
[DisplayEngine]: Option 0: Option Name = ATAPI CD. 
Option Value = 2.
[DisplayEngine]: Option 1: Option Name = IDE HDD. 
Option Value = 1.
[DisplayEngine]: Option 2: Option Name = PXE. Option 
Value = 3.


Thanks,
Dandan
> -Original Message-
> From: Dong, Eric 
> Sent: Thursday, June 18, 2020 2:28 PM
> To: Bi, Dandan ; devel@edk2.groups.io
> Cc: Gao, Liming 
> Subject: RE: [patch] MdeModulePkg/DisplayEngine: Add Debug message to
> show mismatch menu info
> 
> Hi Dandan,
> 
> It's good to show more info about the mismatch error. Current end user
> doesn't know which question need to check if this error appears.
> 
> Can you post an example about the error message for one of and for
> ordered list? We need to make sure the message is easy to be understood
> and the end user knows what need to do to fix this error.
> 
> Thanks,
> Eric
> 
> > -Original Message-
> > From: Bi, Dandan 
> > Sent: Thursday, June 18, 2020 11:24 AM
> > To: devel@edk2.groups.io
> > Cc: Gao, Liming ; Dong, Eric
> > 
> > Subject: [patch] MdeModulePkg/DisplayEngine: Add Debug message to
> show
> > mismatch menu info
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2326
> >
> > Currently when meet mismatch case for one-of and ordered-list menu,
> > just show a popup window to indicate mismatch, no more info for
> debugging.
> > This patch is to add more debug message about mismatch menu info which
> > is helpful to debug.
> >
> > Cc: Liming Gao 
> > Cc: Eric Dong 
> > Signed-off-by: Dandan Bi 
> > ---
> >  .../DisplayEngineDxe/ProcessOptions.c | 78 +++
> >  1 file changed, 78 insertions(+)
> >
> > diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> > b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> > index e7306f6d04..4331b2903c 100644
> > --- a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> > +++ b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> > @@ -911,10 +911,73 @@ PasswordProcess (
> >FreePool (StringPtr);
> >
> >return Status;
> >  }
> >
> > +/**
> > +  Print some debug message about mismatched menu info.
> > +
> > +  @param  MenuOption The MenuOption for this Question.
> > +
> > +**/
> > +VOID
> > +PrintMismatchMenuInfo (
> > +  IN  UI_MENU_OPTION  *MenuOption
> > +)
> > +{
> > +  CHAR16  *FormTitleStr;
> > +  CHAR16  *OneOfOptionStr;
> > +  CHAR16  *QuestionName;
> > +  LIST_ENTRY  *Link;
> > +  FORM_DISPLAY_ENGINE_STATEMENT   *Question;
> > +  EFI_IFR_ORDERED_LIST*OrderList;
> > +  UINTN   Index;
> > +  EFI_HII_VALUE   HiiValue;
> > +  EFI_HII_VALUE   *QuestionValue;
> > +  DISPLAY_QUESTION_OPTION *Option;
> > +  UINT8   *ValueArray;
> > +  UINT8  

Re: [edk2-devel] [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load

[Laszlo Ersek]

On 06/17/20 19:23, Igor Druzhinin wrote:
> On 17/06/2020 17:59, Paolo Bonzini wrote:
>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments 
>> unless you have verified the sender and know the content is safe.
>>
>> On 17/06/20 17:46, Laszlo Ersek wrote:
 That said, Igor's patch seems correct to me.  In fact, I'd even move
 DisableInterrupts before gBS->RestoreTPL unless there's a good reason
 not to do so.
>>> OK, thank you!
>>>
>>> Igor, please confirm if you'd like to submit v2 with the update
>>> suggested by Paolo, or if you prefer the current version. We're at the
>>> beginning of the current development cycle, so I guess we can apply the
>>> patch and see how it works in practice. If it ends up wreaking havoc on
>>> some platforms, we can always revert the patch in time for the next
>>> stable tag (edk2-stable202008).
>>
>> For what it's worth "correct" means that I don't see anything that could
>> break and in fact I find it good policy hygienic not to allow recursive
>> interrupts.
>>
>> v1 is okay for me too, so:
>>
>> Reviewed-by: Paolo Bonzini 

Thank you, Paolo!

> Thanks, unfortunately it's not possible to move DisableInterrupts inside
> TPL block as RestoreTPL would immediately enable them according to current
> logic.
> 
> IMO RaiseTPL could technically save interrupt state inside it (in that
> case it was disabled) and then honor it in RestoreTPL but that might have
> more surprise consequences than the proposed change I reckon.
> 
> I will create a BZ ticket as requested.

Thanks -- please follow up with the URL, and then I'll pick up your
current patch, with Paolo's R-b and the BZ URL added to the commit message.

Acked-by: Laszlo Ersek 

Thanks
Laszlo


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

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

Re: [edk2-devel] [PATCH v9 43/46] OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector

[Dong, Eric]

Hi Tom,

We use GCC5 to build the OVMF platform and report below errors, please help to 
check and fix it.


I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/MdeModulePkg/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/MdeModulePkg/Include/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/UefiCpuPkg/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/UefiCpuPkg/Include/ 
-I/opt/TCAgent/work/f9b29f3e80472c44/Edk2/UefiCpuPkg/ResetVector/Vtf0/ -o 
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin
 
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii:72:
 error: expression syntax error
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.iii:74:
 error: label or instruction expected at start of line
Ia32/PageTables64.asm:27: error: label or instruction expected at start of line
Ia32/PageTables64.asm:29: error: label or instruction expected at start of line
Ia32/PageTables64.asm:30: error: label or instruction expected at start of line
Ia32/PageTables64.asm:369: error: expression syntax error
GNUmakefile:319: recipe for target 
'/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin'
 failed
make: *** 
[/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector/OUTPUT/ResetVector.bin]
 Error 1


build.py...
 : error 7000: Failed to execute command
make tbuild 
[/opt/TCAgent/work/f9b29f3e80472c44/Edk2/Build/OvmfX64/DEBUG_GCC5/X64/OvmfPkg/ResetVector/ResetVector]


build.py...
 : error F002: Failed to build module

/opt/TCAgent/work/f9b29f3e80472c44/Edk2/OvmfPkg/ResetVector/ResetVector.inf 
[X64, GCC5, DEBUG]


Related platform build configuration like below:

WORKSPACE= /opt/TCAgent/work/f9b29f3e80472c44/Edk2
EDK_TOOLS_PATH   = /opt/TCAgent/work/f9b29f3e80472c44/Edk2/BaseTools
CONF_PATH= /opt/TCAgent/work/f9b29f3e80472c44/Edk2/Conf
PYTHON_COMMAND   = /usr/bin/python3.5

Architecture(s)  = X64
Build target = DEBUG
Toolchain= GCC5

Active Platform  = 
/opt/TCAgent/work/f9b29f3e80472c44/Edk2/OvmfPkg/OvmfPkgX64.dsc


Thanks,
Eric
> -Original Message-
> From: Tom Lendacky 
> Sent: Friday, June 5, 2020 9:28 PM
> To: devel@edk2.groups.io
> Cc: Brijesh Singh ; Ard Biesheuvel
> ; Dong, Eric ; Justen,
> Jordan L ; Laszlo Ersek ;
> Gao, Liming ; Kinney, Michael D
> ; Ni, Ray 
> Subject: [PATCH v9 43/46] OvmfPkg: Use the SEV-ES work area for the SEV-
> ES AP reset vector
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> 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 the SEV-ES work area for the reset vector code that contains support
> to jump to the desired RIP location after having been started. This is
> required for only the very first AP reset.
> 
> This new OVMF source file, ResetVectorVtf0.asm, is used in place of the
> original file through the use of the include path order set in
> OvmfPkg/ResetVector/ResetVector.inf under "[BuildOptions]".
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Reviewed-by: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 100
> 
>  OvmfPkg/ResetVector/ResetVector.nasmb|   1 +
>  2 files changed, 101 insertions(+)
> 
> diff --git a/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> new file mode 100644
> index ..980e0138e7fe
> --- /dev/null
> +++ b/OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
> @@ -0,0 +1,100 @@
> +;--
> 
> +; @file
> 
> +; First code executed by processor after resetting.
> 
> +; Derived from UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
> 
> +;
> 
> +; Copyright (c) 2008 - 2014, Intel Corporation. All rights reserved.
> 
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +;
> 
> +;--
> 
> +
> 
> +BITS16
> 
> +
> 
> +ALIGN   16
> 
> +
> 
> +;
> 
> +; Pad the image size to 4k when page tables are in VTF0
> 
> +;
> 
> +; If the VTF0 image has page tables built in, then we need to make
> 
> +; sure the end of VTF0 is 4k above where the page tables end.
> 
> +;
> 
> +; This is required so the page tables will be 4k 

Re: [edk2-devel] [PATCH v9 08/46] UefiCpuPkg: Implement library support for VMGEXIT

[Dong, Eric]

Hi Tom,

When use VS2015 to build this code, it reports below error. Please help to fix 
it.

k:\edk2\UefiCpuPkg\Include\Library/VmgExitLib.h: error C2220: warning treated 
as error - no 'object' file generated
k:\edk2\UefiCpuPkg\Include\Library/VmgExitLib.h: warning C4335: Mac file format 
detected: please convert the source file to either DOS or UNIX format

Thanks,
Eric

> -Original Message-
> From: Tom Lendacky 
> Sent: Friday, June 5, 2020 9:27 PM
> To: devel@edk2.groups.io
> Cc: Brijesh Singh ; Ard Biesheuvel
> ; Dong, Eric ; Justen,
> Jordan L ; Laszlo Ersek ;
> Gao, Liming ; Kinney, Michael D
> ; Ni, Ray 
> Subject: [PATCH v9 08/46] UefiCpuPkg: Implement library support for
> VMGEXIT
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> To support handling #VC exceptions and issuing VMGEXIT instructions,
> create a library with functions that can be used to perform these
> #VC/VMGEXIT related operations. This includes functions for:
>   - Handling #VC exceptions
>   - Preparing for and issuing a VMGEXIT
>   - Performing MMIO-related write operations to support flash emulation
>   - Performing AP related boot opeations
> 
> The base functions in this driver will not do anything and will return
> an error if a return value is required. It is expected that other packages
> (like OvmfPkg) will create a version of the library to fully support an
> SEV-ES guest.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  UefiCpuPkg/UefiCpuPkg.dec|   3 +
>  UefiCpuPkg/UefiCpuPkg.dsc|   2 +
>  UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf |  27 +
>  UefiCpuPkg/Include/Library/VmgExitLib.h  | 103 +
>  UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.c   | 121
> 
>  UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.uni |  15 +++
>  6 files changed, 271 insertions(+)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index df5d02bae6b4..cb92f34b6f55 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -53,6 +53,9 @@ [LibraryClasses.IA32, LibraryClasses.X64]
>##
> 
>MpInitLib|Include/Library/MpInitLib.h
> 
> 
> 
> +  ##  @libraryclass  Provides function to support VMGEXIT processing.
> 
> +  VmgExitLib|Include/Library/VmgExitLib.h
> 
> +
> 
>  [Guids]
> 
>gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa,
> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
> 
>gMsegSmramGuid = { 0x5802bce4, 0x, 0x4e33, { 0xa1, 
> 0x30,
> 0xeb, 0xad, 0x27, 0xf0, 0xe4, 0x39 }}
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
> index afa304128221..f0e58b90ff0a 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dsc
> +++ b/UefiCpuPkg/UefiCpuPkg.dsc
> @@ -56,6 +56,7 @@ [LibraryClasses]
> 
> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/Base
> PeCoffGetEntryPointLib.inf
> 
> 
> PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BaseP
> eCoffExtraActionLibNull.inf
> 
> 
> TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/Tp
> mMeasurementLibNull.inf
> 
> +  VmgExitLib|UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
> 
> 
> 
>  [LibraryClasses.common.SEC]
> 
> 
> PlatformSecLib|UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.i
> nf
> 
> @@ -143,6 +144,7 @@ [Components.IA32, Components.X64]
> 
> UefiCpuPkg/Library/SmmCpuPlatformHookLibNull/SmmCpuPlatformHookLib
> Null.inf
> 
>UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf
> 
>UefiCpuPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLibStm.inf
> 
> +  UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
> 
>UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationPei.inf
> 
>UefiCpuPkg/PiSmmCommunication/PiSmmCommunicationSmm.inf
> 
>UefiCpuPkg/SecCore/SecCore.inf
> 
> diff --git a/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
> b/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
> new file mode 100644
> index ..d8770a21c355
> --- /dev/null
> +++ b/UefiCpuPkg/Library/VmgExitLibNull/VmgExitLibNull.inf
> @@ -0,0 +1,27 @@
> +## @file
> 
> +#  VMGEXIT Support Library.
> 
> +#
> 
> +#  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
> 
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
> +#
> 
> +##
> 
> +
> 
> +[Defines]
> 
> +  INF_VERSION= 0x00010005
> 
> +  BASE_NAME  = VmgExitLibNull
> 
> +  MODULE_UNI_FILE= VmgExitLibNull.uni
> 
> +  FILE_GUID  = 3cd7368f-ef9b-4a9b-9571-2ed93813677e
> 
> +  MODULE_TYPE= BASE
> 
> +  VERSION_STRING = 1.0
> 
> +  LIBRARY_CLASS  = VmgExitLib
> 
> +
> 
> +[Sources.common]
> 
> +  VmgExitLibNull.c
> 
> +
> 
> +[Packages]
> 
> +  MdePkg/MdePkg.dec
> 
> +  UefiCpuPkg/UefiCpuPkg.dec
> 
> +
> 
> +[LibraryClasses]
> 
> +  BaseLib
> 
> +
> 
> 

[edk2-devel] [edk2-rfc] MdeModulePkg/StatusCodeHandler: Separate NULL class libraries for Memory and serial handlers from MdeModulePkg/Universal/StatusCodeHandler modules

[Dandan Bi]

Hi All,

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

We plan to separate two kinds of NULL class libraries for Memory and serial 
handlers from MdeModulePkg/Universal/StatusCodeHandler/.../ 
StatusCodeHandlerPei/RuntimeDxe/Smm modules.
The benefit we want to gain from this separation is to 1) make the code clear 
and easy to maintain, 2) make platform flexible to choose any handler library 
they need, and it also can reduce image size since the unused handlers can be 
excluded.
If you have any concern or comments for this separation, please let me know.

We plan to add new separated NULL class library MemoryStausCodeHandlerLib and 
SerialStatusCodeHandlerLib with different phase implementation into 
MdeModulePkg\Library\ directory.
The main tree structure may like below:
MdeModulePkg\Library
|--MemoryStausCodeHandlerLib
|--|-- PeiMemoryStausCodeHandlerLib.inf
|--|-- RuntimeDxeMemoryStatusCodeHandlerLib.inf
|--|-- SmmMemoryStausCodeHandlerLib.inf
|--SerialStatusCodeHandlerLib
|--|-- PeiSerialStatusCodeHandlerLib.inf
|--|-- RuntimeDxeSerialStatusCodeHandlerLib.inf
|--|-- SmmSerialStatusCodeHandlerLib.inf


We will update existing platform use cases in edk2 and edk2-platform repo to 
cover the new NULL class library to make sure this change doesn't impact any 
platform.
After this separation, StatusCodeHandler module usage will like below, and it's 
also very flexible for platform to cover more handler libraries to meet their 
requirements.
MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf {
  
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/PeiMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/PeiSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/RuntimeDxe/StatusCodeHandlerRuntimeDxe.inf
  {
  
NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/RuntimeDxeMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/RuntimeDxeSerialStatusCodeHandlerLib.inf
...
}

MdeModulePkg/Universal/StatusCodeHandler/Smm/StatusCodeHandlerSmm.inf {
  

NULL|MdeModulePkg/Library/MemoryStausCodeHandlerLib/SmmMemoryStausCodeHandlerLib.inf
NULL|MdeModulePkg/Library/SerialStatusCodeHandlerLib/SmmSerialStatusCodeHandlerLib.inf
...
}


Thanks,
Dandan

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

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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Regenerate boot options on boot failure

[Andrei Warkentin]

Reviewed-by: Andrei Warkentin 

From: Samer El-Haj-Mahmoud 
Sent: Wednesday, June 17, 2020 4:33 PM
To: devel@edk2.groups.io 
Cc: Ard Biesheuvel ; Leif Lindholm ; 
Andrei Warkentin ; Pete Batard 
Subject: [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Regenerate boot 
options on boot failure

Port tianocore/edk2@2d233af64b8f73d1b1e138b302e6344f7c2e0f4e

This enables network boot by default on RPi first boot, when all other
boot options fail. This is required for unattended/headless boot cases.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c | 36 
+++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c 
b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
index cb74d65b7f91..fa46be791732 100644
--- a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
@@ -4,7 +4,7 @@
  *  Copyright (c) 2017-2018, Andrei Warkentin 
  *  Copyright (c) 2016, Linaro Ltd. All rights reserved.
  *  Copyright (c) 2015-2016, Red Hat, Inc.
- *  Copyright (c) 2014, ARM Ltd. All rights reserved.
+ *  Copyright (c) 2014-2020, ARM Ltd. All rights reserved.
  *  Copyright (c) 2004-2016, Intel Corporation. All rights reserved.
  *
  *  SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -700,6 +700,40 @@ PlatformBootManagerUnableToBoot (
   EFI_INPUT_KEYKey;
   EFI_BOOT_MANAGER_LOAD_OPTION BootManagerMenu;
   UINTNIndex;
+  EFI_BOOT_MANAGER_LOAD_OPTION *BootOptions;
+  UINTNOldBootOptionCount;
+  UINTNNewBootOptionCount;
+
+  //
+  // Record the total number of boot configured boot options
+  //
+  BootOptions = EfiBootManagerGetLoadOptions (,
+  LoadOptionTypeBoot);
+  EfiBootManagerFreeLoadOptions (BootOptions, OldBootOptionCount);
+
+  //
+  // Connect all devices, and regenerate all boot options
+  //
+  EfiBootManagerConnectAll ();
+  EfiBootManagerRefreshAllBootOption ();
+
+  //
+  // Record the updated number of boot configured boot options
+  //
+  BootOptions = EfiBootManagerGetLoadOptions (,
+  LoadOptionTypeBoot);
+  EfiBootManagerFreeLoadOptions (BootOptions, NewBootOptionCount);
+
+  //
+  // If the number of configured boot options has changed, reboot
+  // the system so the new boot options will be taken into account
+  // while executing the ordinary BDS bootflow sequence.
+  //
+  if (NewBootOptionCount != OldBootOptionCount) {
+DEBUG ((DEBUG_WARN, "%a: rebooting after refreshing all boot options\n",
+  __FUNCTION__));
+gRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL);
+  }

   //
   // BootManagerMenu doesn't contain the correct information when return status
--
2.17.1


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

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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Add SMBIOS Type 11

[Andrei Warkentin]

Reviewed-by: Andrei Warkentin 

From: Samer El-Haj-Mahmoud 
Sent: Wednesday, June 17, 2020 11:22 PM
To: devel@edk2.groups.io 
Cc: Ard Biesheuvel ; Leif Lindholm ; 
Andrei Warkentin ; Pete Batard 
Subject: [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Add SMBIOS Type 11

SMBIOS Type 11 (OEM Strings) is recommended in SBBR 1.2.
Add a simlpe implementation to the RPi.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 27 

 1 file changed, 27 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index 7b86e76a1248..f336084520a9 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -389,6 +389,20 @@ CHAR8 *mSysSlotInfoType9Strings[] = {
   NULL
 };

+
+/***
+SMBIOS data definition  TYPE 11  OEM Strings
+/
+
+SMBIOS_TABLE_TYPE11 mOemStringsType11 = {
+  { EFI_SMBIOS_TYPE_OEM_STRINGS, sizeof (SMBIOS_TABLE_TYPE11), 
SMBIOS_HANDLE_PI_RESERVED },
+  1 // StringCount
+};
+CHAR8 *mOemStringsType11Strings[] = {
+  "https://github/tianocore/edk2-platforms/Platform/RaspberryPi/;,
+  NULL
+};
+
 /***
 SMBIOS data definition  TYPE16  Physical Memory ArrayInformation
 /
@@ -854,6 +868,17 @@ SysSlotInfoUpdateSmbiosType9 (
   LogSmbiosData ((EFI_SMBIOS_TABLE_HEADER*), 
mSysSlotInfoType9Strings, NULL);
 }

+/***
+SMBIOS data update  TYPE11  OEM Strings
+/
+VOID
+OemStringsUpdateSmbiosType11 (
+  VOID
+  )
+{
+  LogSmbiosData ((EFI_SMBIOS_TABLE_HEADER*), 
mOemStringsType11Strings, NULL);
+}
+
 /***
 SMBIOS data update  TYPE16  Physical Memory Array Information
 /
@@ -961,6 +986,8 @@ PlatformSmbiosDriverEntryPoint (

   SysSlotInfoUpdateSmbiosType9 ();

+  OemStringsUpdateSmbiosType11 ();
+
   PhyMemArrayInfoUpdateSmbiosType16 ();

   MemDevInfoUpdateSmbiosType17 ();
--
2.17.1


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

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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix SMBIOS Type 9

[Andrei Warkentin]

Reviewed-by: Andrei Warkentin 

A

From: Samer El-Haj-Mahmoud 
Sent: Wednesday, June 17, 2020 11:16 PM
To: devel@edk2.groups.io 
Cc: Ard Biesheuvel ; Leif Lindholm ; 
Andrei Warkentin ; Pete Batard 
Subject: [edk2-platform][PATCH v1 1/1] Platforms/RaspberryPi: Fix SMBIOS Type 9

FWTS reports an error with SMBIOS Type 9 Segment-Bus-DevFunc fields.
The SMBIOS specification requires that for non-PCIe slot devices to have
these fields reported as 0xF-0xFF-xFF. Instead, they were being
reported as 0x-0x00-0x00.

This fixes the FWTS SMBIOS Type 9 failure reported here:
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpftf%2FRPi4%2Fissues%2F75data=02%7C01%7Cawarkentin%40vmware.com%7C12c3f18cf4c542508b1008d8133e6ec5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637280506159613646sdata=SOdVyajdUz021jZ9PrJMTSw%2B3zef8FR88WMRp6Xckio%3Dreserved=0

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c 
b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
index 7b86e76a1248..78bdda18eb2d 100644
--- a/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
+++ b/Platform/RaspberryPi/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c
@@ -380,9 +380,9 @@ SMBIOS_TABLE_TYPE9  mSysSlotInfoType9 = {
 0,  // SmbusSignalSupported:1;
 0,  // Reserved:5;  ///< Set to 0.
   },
-  0,// SegmentGroupNum;
-  0,// BusNum;
-  0,// DevFuncNum;
+  0x, // SegmentGroupNum;
+  0xFF,   // BusNum;
+  0xFF,   // DevFuncNum;
 };
 CHAR8 *mSysSlotInfoType9Strings[] = {
   "SD Card",
--
2.17.1


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

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

Re: [edk2-devel] [patch] MdeModulePkg/DisplayEngine: Add Debug message to show mismatch menu info

[Dong, Eric]

Hi Dandan,

It's good to show more info about the mismatch error. Current end user doesn't 
know which question need to check if this error appears.

Can you post an example about the error message for one of and for ordered 
list? We need to make sure the message is easy to be understood and the end 
user knows what need to do to fix this error.

Thanks,
Eric

> -Original Message-
> From: Bi, Dandan 
> Sent: Thursday, June 18, 2020 11:24 AM
> To: devel@edk2.groups.io
> Cc: Gao, Liming ; Dong, Eric 
> Subject: [patch] MdeModulePkg/DisplayEngine: Add Debug message to
> show mismatch menu info
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2326
> 
> Currently when meet mismatch case for one-of and ordered-list menu, just
> show a popup window to indicate mismatch, no more info for debugging.
> This patch is to add more debug message about mismatch menu info which is
> helpful to debug.
> 
> Cc: Liming Gao 
> Cc: Eric Dong 
> Signed-off-by: Dandan Bi 
> ---
>  .../DisplayEngineDxe/ProcessOptions.c | 78 +++
>  1 file changed, 78 insertions(+)
> 
> diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> index e7306f6d04..4331b2903c 100644
> --- a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> +++ b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> @@ -911,10 +911,73 @@ PasswordProcess (
>FreePool (StringPtr);
> 
>return Status;
>  }
> 
> +/**
> +  Print some debug message about mismatched menu info.
> +
> +  @param  MenuOption The MenuOption for this Question.
> +
> +**/
> +VOID
> +PrintMismatchMenuInfo (
> +  IN  UI_MENU_OPTION  *MenuOption
> +)
> +{
> +  CHAR16  *FormTitleStr;
> +  CHAR16  *OneOfOptionStr;
> +  CHAR16  *QuestionName;
> +  LIST_ENTRY  *Link;
> +  FORM_DISPLAY_ENGINE_STATEMENT   *Question;
> +  EFI_IFR_ORDERED_LIST*OrderList;
> +  UINTN   Index;
> +  EFI_HII_VALUE   HiiValue;
> +  EFI_HII_VALUE   *QuestionValue;
> +  DISPLAY_QUESTION_OPTION *Option;
> +  UINT8   *ValueArray;
> +  UINT8   ValueType;
> +
> +  Question = MenuOption->ThisTag;
> +  FormTitleStr = GetToken (gFormData->FormTitle, gFormData->HiiHandle);
> +
> +  DEBUG ((DEBUG_ERROR, "\n[DisplayEngine]: Mismatch Formset:
> Formset Guid = %g.\n", >FormSetGuid));
> +  DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch Form   : FormId
> = %d,  Form title = %s.\n", gFormData->FormId, FormTitleStr));
> +
> +  if (Question->OpCode->OpCode == EFI_IFR_ORDERED_LIST_OP) {
> +QuestionName = GetToken (((EFI_IFR_ORDERED_LIST*)MenuOption-
> >ThisTag->OpCode)->Question.Header.Prompt, gFormData->HiiHandle);
> +Link = GetFirstNode (>OptionListHead);
> +Option = DISPLAY_QUESTION_OPTION_FROM_LINK (Link);
> +ValueType = Option->OptionOpCode->Type;
> +
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OrderedList: Name
> = %s.\n", QuestionName));
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OrderedList: Value
> + Arrary:\n"));
> +
> +OrderList = (EFI_IFR_ORDERED_LIST *) Question->OpCode;
> +for (Index = 0; Index < OrderList->MaxContainers; Index++) {
> +  ValueArray = Question->CurrentValue.Buffer;
> +  HiiValue.Value.u64 = GetArrayData (ValueArray, ValueType, Index);
> +  DEBUG ((DEBUG_ERROR, "   Value[%d] 
> =%d.\n",Index,
> HiiValue.Value.u64));
> +}
> +  } else if (Question->OpCode->OpCode == EFI_IFR_ONE_OF_OP) {
> +QuestionName = GetToken (((EFI_IFR_ONE_OF*)MenuOption->ThisTag-
> >OpCode)->Question.Header.Prompt, gFormData->HiiHandle);
> +QuestionValue = >CurrentValue;;
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OneOf  : Named
> = %s.\n", QuestionName));
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Mismatch OneOf  : Current
> value = %d.\n",QuestionValue->Value.u8));
> +  }
> +
> +  Index = 0;
> +  Link = GetFirstNode (>OptionListHead);
> +  while (!IsNull (>OptionListHead, Link)) {
> +Option = DISPLAY_QUESTION_OPTION_FROM_LINK (Link);
> +OneOfOptionStr = GetToken (Option->OptionOpCode->Option,
> gFormData->HiiHandle);
> +DEBUG ((DEBUG_ERROR, "[DisplayEngine]: Option %d: Option
> Name = %s. Option Value = %d.\n",Index,OneOfOptionStr,Option-
> >OptionOpCode->Value.u8));
> +Link = GetNextNode (>OptionListHead, Link);
> +Index++;
> +  }
> +}
> +
>  /**
>Process a Question's Option (whether selected or un-selected).
> 
>@param  MenuOption The MenuOption for this Question.
>@param  Selected   TRUE: if Question is selected.
> @@ -1010,10 +1073,15 @@ ProcessOptions (
>break;
>  }
> 
>  OneOfOption = ValueToOption (Question, );
>  if (OneOfOption ==