Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Why not move to edk2 repo? Thanks, Hot -Original Message- From: devel@edk2.groups.io On Behalf Of Leif Lindholm Sent: Friday, October 02, 2020 7:26 To: Desimone, Nathaniel L Cc: r...@edk2.groups.io; devel@edk2.groups.io; Laszlo Ersek ; Ard Biesheuvel ; Kirkendall, Garrett ; Lendacky,

Re: [edk2-devel] [PATCH 1/1] Silicon/SiFive: Handle case of NULL FirmwareContext

Merged to edk2-platforms. > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Abner Chang > Sent: Wednesday, September 30, 2020 9:37 PM > To: Schaefer, Daniel ; devel@edk2.groups.io > Cc: Leif Lindholm > Subject: Re: [edk2-devel] [PATCH 1/1] Sili

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

Hi Folks, Thanks for good discussions around this topic. The purpose of this document "Who we are" is intended to remain high level to introduce the community members and their roles. Please note that some of the feedback is very detailed that probably fits into the TianoCore development pro

Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hey Laszlo, On 9/30/20, 11:54 PM, Laszlo Ersek wrote: > > Since I've been CC'd -- the MinPlatformPkg move seems logical to me. > Regarding the tools, I guess it depends on how many Intel-specific quirks > they contain. I guess they could be moved too after a potential refactoring / > splitting.

Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

On Thu, Oct 01, 2020 at 23:20:01 +, Desimone, Nathaniel L wrote: > > One thing I think is needed for this to move out of Platform/Intel would be > > a > > ReadMe.rst describing the intended real-world use. > > Some of this lives in Platform/Intel/Readme.md today. > > Could we start with a set

Re: [edk2-devel] [edk2-rfc] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hey Leif, On 10/1/20, 4:52 AM, " Leif Lindholm" wrote: > > Very positive to this on the whole. Happy to hear! > I have only been following MinPlatformPkg peripherally - at the time it was > merged, I did not have the bandwidth to look into it and help make it cross- > architecture from the sta

[edk2-devel] [PATCH edk2-platforms v1 1/1] Platform/ARM: TimerLib based RngLib for CryptoPkg

The commit at "b5701a4c7a0f CryptoPkg: OpensslLib: Use RngLib to generate entropy in rand_pool" updated CryptoPkg\OpenSSL to no longer depend on TimerLib and instead use RngLib. This is done so that platforms can choose the desired entropy source. However, this change breaks the builds for platform

Re: [edk2-devel] [edk2-platforms] [PATCH V1 0/2] MinPlatformPkg: Minor fixes in CompressLib

Series pushed: ~b9f61c0..46df7b2 > -Original Message- > From: devel@edk2.groups.io On Behalf Of Nate > DeSimone > Sent: Tuesday, September 29, 2020 5:15 PM > To: devel@edk2.groups.io > Cc: Chiu, Chasel ; Liming Gao > ; Dong, Eric > Subject: [edk2-devel] [edk2-platforms] [PATCH V1 0/2] Mi

[edk2-devel] [edk2-platforms][PATCH v1 1/1] Vlv2TbltDevicePkg/FmpDeviceLib: Add LastAttemptStatus compatibility

From: Michael Kubacki Makes the changes necessary for these library instances of FmpDeviceLib to be compatible with new functions added recently to FmpDeviceLib. Two new functions were introduced in FmpDeviceLib to allow a library instance to return a Last Attempt Status code during check image

Re: [edk2-devel] [PATCH 2/5] MdePkg/BaseLib: add ASSERT in ARM* SetJump implementations

On 10/1/20 10:55 PM, Leif Lindholm wrote: On Thu, Oct 01, 2020 at 22:49:05 +0200, Ard Biesheuvel wrote: On 10/1/20 8:37 PM, Leif Lindholm wrote: The SetJump comment header states that: If JumpBuffer is NULL, then ASSERT(). However, this was not currently done. Add a call to InternalAssertJ

Re: [edk2-devel] [PATCH 2/5] MdePkg/BaseLib: add ASSERT in ARM* SetJump implementations

On Thu, Oct 01, 2020 at 22:49:05 +0200, Ard Biesheuvel wrote: > On 10/1/20 8:37 PM, Leif Lindholm wrote: > > The SetJump comment header states that: > >If JumpBuffer is NULL, then ASSERT(). > > > > However, this was not currently done. > > Add a call to InternalAssertJumpBuffer. > > > > Signe

Re: [edk2-devel] [PATCH 2/5] MdePkg/BaseLib: add ASSERT in ARM* SetJump implementations

On 10/1/20 8:37 PM, Leif Lindholm wrote: The SetJump comment header states that: If JumpBuffer is NULL, then ASSERT(). However, this was not currently done. Add a call to InternalAssertJumpBuffer. Signed-off-by: Leif Lindholm --- MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S | 3 +++

[edk2-devel] [PATCH 1/5] MdePkg/BaseLib: fix comments in ARM* SetJump/LongJump implementations

Drop redundant comment about IPF (clearly copied across from now deleted code). Also change "Instead is resumes execution" -> "Instead it resumes execution" Signed-off-by: Leif Lindholm --- MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S | 3 +-- MdePkg/Library/BaseLib/AArch64/SetJumpLongJum

[edk2-devel] [PATCH 4/5] MdePkg/BaseLib: correct register sizes in AArch64 SetJump/LongJump

Both in SetJump and in InternalLongJump, 32-bit w register views were used for the UINTN return value. In SetJump, this did not cause errors; it was only counterintuitive. But in InternalLongJump, it meant the top 32 bits of Value were stripped off. Change all of these to use the 64-bit x register

[edk2-devel] [PATCH 3/5] MdePkg/BaseLib: use normal register init in ARM SetJump implementations

There may be architectures on which there are benefits to eor r0, r0(, r0) but ARM was never one of them. Change to more readable mov r0, #0 instead. Signed-off-by: Leif Lindholm --- MdePkg/Library/BaseLib/Arm/SetJumpLongJump.S | 2 +- MdePkg/Library/BaseLib/Arm/SetJumpLongJump.asm | 2 +-

[edk2-devel] [PATCH 0/5] MdePkg: various fixes to ARM/AArch64 SetJump/LongJump

Jan's submission earlier today unfortunately made me go have a look at the ARM/AARCH64 implementations, and there were plenty of other things to improve: - Fix comments (drop Itanium mention, correct spelling) - Make code match existing comments - Don't try to optimise ARM for executing on the 8088

[edk2-devel] [PATCH 5/5] MdePkg/BaseLib: ensure ARM LongJump never returns 0

The ARM implementation of of InternalLongJump always returned the value Value - but it is not supposed to ever return 0. Add the test to prevent that, and return 1 if Value is 0 - as is already present in AArch64. Signed-off-by: Leif Lindholm --- MdePkg/Library/BaseLib/Arm/SetJumpLongJump.S |

[edk2-devel] [PATCH 2/5] MdePkg/BaseLib: add ASSERT in ARM* SetJump implementations

The SetJump comment header states that: If JumpBuffer is NULL, then ASSERT(). However, this was not currently done. Add a call to InternalAssertJumpBuffer. Signed-off-by: Leif Lindholm --- MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S | 3 +++ MdePkg/Library/BaseLib/AArch64/SetJumpLongJu

Re: [edk2-devel] [edk2-platforms] [PATCH V1 2/2] MinPlatformPkg: Coding style cleanups in CompressLib

Reviewed-by: Chasel Chiu > -Original Message- > From: Nate DeSimone > Sent: Wednesday, September 30, 2020 8:15 AM > To: devel@edk2.groups.io > Cc: Chiu, Chasel ; Liming Gao > ; Dong, Eric > Subject: [edk2-platforms] [PATCH V1 2/2] MinPlatformPkg: Coding style > cleanups in CompressLi

Re: [edk2-devel] [edk2-platforms] [PATCH V1 1/2] MinPlatformPkg: Add missing bounds checks to CompressLib

Reviewed-by: Chasel Chiu > -Original Message- > From: Nate DeSimone > Sent: Wednesday, September 30, 2020 8:15 AM > To: devel@edk2.groups.io > Cc: Chiu, Chasel ; Liming Gao > ; Dong, Eric > Subject: [edk2-platforms] [PATCH V1 1/2] MinPlatformPkg: Add missing bounds > checks to Compre

Re: [edk2-devel] [edk2-discuss] SmmSwDispatch2Protocol - Registering an SMI - Can't find protocol with OVMF

Hi, (cross-posting to edk2-devel, comments below) On 09/29/20 14:32, Simon McMillan wrote: > Trying to register a SMI in my custom SMM module I'm running into > issues. > > Before registering the SMI, the code looks for the specific protocol > this way: > Status = gSmst->SmmLocateProtocol(

[edk2-devel] [PATCH v2 0/1] MdePkg/BaseLib: AArch64 SetJump/LongJump bugfix

Hello, sending a v2 of my patch after following the instructions Laszlo Ersek gave me in response to the v1. Best, -Jan Jan Bobek (1): MdePkg/BaseLib: Fix invalid memory access in AArch64 SetJump/LongJump MdePkg/Library/BaseLib/AArch64/SetJumpLongJump.S | 8 MdePkg/Library/BaseLi

[edk2-devel] [PATCH v2 1/1] MdePkg/BaseLib: Fix invalid memory access in AArch64 SetJump/LongJump

Correct the memory offsets used in REG_ONE/REG_PAIR macros to synchronize them with definition of the BASE_LIBRARY_JUMP_BUFFER structure on AArch64. The REG_ONE macro declares only a single 64-bit register be read/written; however, the subsequent offset is 16 bytes larger, creating an unused memor

Re: [edk2-devel] [PATCH 1/1] MdePkg/BaseLib: Fix invalid memory access in AArch64 SetJump/LongJump

Ard Biesheuvel writes: > On 10/1/20 3:04 PM, Laszlo Ersek wrote: >> On 09/29/20 03:12, Jan Bobek wrote: >>> Correct the memory offsets used in REG_ONE/REG_PAIR macros to >>> synchronize them with definition of the BASE_LIBRARY_JUMP_BUFFER >>> structure on AArch64. >>> >>> The REG_ONE macro declar

Re: [edk2-devel] [PATCH 1/1] NetworkPkg: Fix possible infinite loop in HTTP msg body parser

Hi Maciej, Thank you for looking into this. Vladimir > -Original Message- > From: Rabeda, Maciej > Sent: Wednesday, September 30, 2020 2:57 AM > To: devel@edk2.groups.io; vladimir.olovyanni...@broadcom.com > Cc: Jiaxin Wu ; Siyuan Fu ; > Laszlo Ersek > Subject: Re: [edk2-devel] [PATCH 1

Re: [edk2-devel] [PATCH 1/1] MdePkg/BaseLib: Fix invalid memory access in AArch64 SetJump/LongJump

On 10/1/20 3:04 PM, Laszlo Ersek wrote: On 09/29/20 03:12, Jan Bobek wrote: Correct the memory offsets used in REG_ONE/REG_PAIR macros to synchronize them with definition of the BASE_LIBRARY_JUMP_BUFFER structure on AArch64. The REG_ONE macro declares only a single 64-bit register be read/writt

Re: [edk2-devel] [PATCH 1/1] MdePkg/BaseLib: Fix invalid memory access in AArch64 SetJump/LongJump

On 09/29/20 03:12, Jan Bobek wrote: > Correct the memory offsets used in REG_ONE/REG_PAIR macros to > synchronize them with definition of the BASE_LIBRARY_JUMP_BUFFER > structure on AArch64. > > The REG_ONE macro declares only a single 64-bit register be > read/written; however, the subsequent off

Re: [edk2-devel] [PATCH 0/1] MdePkg/BaseLib: AArch64 SetJump/LongJump bugfix

On 09/29/20 03:12, Jan Bobek wrote: > Hi all, > > I have recently discovered a bug in the BaseLib's implementation of > SetJump and LongJump; the offsets listed in the assembly files are 8 > bytes off, causing the functions to read/write 8 bytes past the end of > the jump buffer. More details can

Re: [edk2-devel] [PATCH v2 1/2] CryptoPkg/OpensslLib: Add native instruction support for X64

(refreshing Ard's address, comments below) On 09/29/20 23:08, Zurcher, Christopher J wrote: > The GCC build fails with this error: > > `OPENSSL_ia32cap_P' referenced in section `.text.OPENSSL_cpuid_setup' > of /tmp/ccIIRAYs.ltrans20.ltrans.o: defined in discarded section > `COMMON' of > /mnt/c/mss

Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hi Nate, On Wed, Sep 30, 2020 at 23:17:15 +, Desimone, Nathaniel L wrote: > This has come up informally a couple of times already, but I do > think that it would be beneficial to move MinPlatformPkg out of the > Platform/Intel folder and into a vendor neutral folder. MinPlatform > really isn't

Re: [edk2-devel] [PATCH v2 0/2] Enable HttpDynamicCommand for ArmVirtPkg and OvmfPkg

On 07/22/20 22:54, Vladimir Olovyannikov via groups.io wrote: > Hi, > > This patchset enables HttpDynamicCommand (Shell command "http") which can be > used on ArmVirt and Ovmf platforms. HttpDynamicCommand needs to be available > in the tree before this patchset can be applied. The patchset needs

Re: [EXTERNAL] Re: [edk2-devel] Ecc style errors when running EDK2 CI locally without specifying a target (NO-TARGET)

On 10/01/20 04:25, Rebecca Cran wrote: > Ah, thanks. I made a wrong assumption about how it works. So I can get > it to fail faster by running "stuart_ci_build -c .pytool/CISettings.py > TOOL_CHAIN_TAG=GCC5 -t NO-TARGET" - i.e. running NO-TARGET without also > running DEBUG,RELEASE,NOOPT too. > >

Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

We have recently been evaluating the merits of MinPlatformPkg. We would welcome a MinPlatformPkg that is more accessible. GARRETT KIRKENDALL SMTS Firmware Engineer 7171 Southwest Parkway, Austin, TX 78735 USA AMD   facebook  |  amd.com > -Original Message- > From: Desimone, Nathaniel L

Re: [edk2-devel] Cannot build due to recent change

On Thu, Oct 01, 2020 at 12:06:07 +0100, Andrew Goodbody wrote: > > Anyway, yes - commit b5701a4c7a0f ("CryptoPkg: OpensslLib: Use RngLib > > to generate entropy in rand_pool"), merged through > > https://github.com/tianocore/edk2/pull/938 broke EmulatorPkg, and most > > platforms outside the main e

Re: [edk2-devel] Cannot build due to recent change

Hi All, I am looking into this and will provide a fix shortly. Regards, Sami Mujawar -Original Message- From: devel@edk2.groups.io On Behalf Of Leif Lindholm via groups.io Sent: 01 October 2020 11:44 AM To: devel@edk2.groups.io; andrew.goodb...@linaro.org Cc: Ard Biesheuvel ; Thomas A

Re: [edk2-devel] Cannot build due to recent change

On 01/10/2020 11:43, Leif Lindholm wrote: Hi Andrew, Welcome to the list. Thank you. I did BIOS work and some UEFI in a previous role but have been out of the loop for some years. First of all, it helps to cc maintainers of the bits you're having issues with. The GetMaintainer.py script c

[edk2-devel] smartcardreaderprotocol

Hi, this is Naveen, I am doing a EFI application development using EDK2. my EFI is based on smart card reader. i am able import smartcardreader protocol. here the smartcardconnect it self getting fail. it basically there is no supported driver. i am using epass2003 auto token. could suggest so

Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hi Nate, totally agree with you. Best, Chris On 10/1/20 9:43 AM, Wim Vervoorn wrote: > Hi Nate, > > I agree this sounds like a good plan. The MinPlatform should be as generic as > possible and suitable for all architectures. > > In fact it is similar to the UEFIPayload package wich is also sta

Re: [edk2-devel] Cannot build due to recent change

Hi Andrew, Welcome to the list. First of all, it helps to cc maintainers of the bits you're having issues with. The GetMaintainer.py script can look these up for you automatically for a given path: python ../edk2/BaseTools/Scripts/GetMaintainer.py -l Platform/ARM/JunoPkg/ArmJuno.dsc Platform/AR

Re: [edk2-devel] [PATCH v1 1/1] UefipayloadPkg: Protect coreboot tables

On 09/14/20 19:32, Guo Dong wrote: > > OK. Let me merge this patch firstly. /Guo The PR at failed 17 days ago and there have been no updates since, as far as I can tell. I've closed the PR for now. Thanks Laszlo > > From: Marcello Sylvester Bauer >

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

On Thu, Oct 01, 2020 at 10:44:10 +0200, Laszlo Ersek wrote: > On 09/30/20 12:13, Leif Lindholm wrote: > > Agreed. > > > > Reviever or Maintainer can approve a patch. Any Maintainer can push a > > patch that has been approved. > > I disagree. > > Assume Ard and myself are away and Jordan fails to

Re: [edk2-devel] [PATCH v13 1/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

On 09/30/20 03:04, Gao, Zhichao wrote: > If the maintainers/reviewers don't have response for more than two weeks, you > can always push them. If initial feedback does not appear in *one* week, pinging the maintainer is justified. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You rec

[edk2-devel] Cannot build due to recent change

Looks like a recent change is not working for AARCH64 https://github.com/tianocore/edk2/commit/b5701a4c7a0fb185e0c5b9db9525939c78664bfd edk2-platforms/Platform/ARM/JunoPkg/ArmJuno.dsc(...): error 4000: Instance of library class [RngLib] is not found in [/home/andrew/src/edk2/CryptoPkg/Library/

[edk2-devel] [ann] OvmfPkg: support VCPU hotplug with -D SMM_REQUIRE

Hello Jiaxin, On 07/29/20 10:37, Wu, Jiaxin wrote: > Hi Laszlo, > > Appreciate your feedback! Thank you very much. if you are still interested in using this feature, I have some good news. As of current edk2 master (to be entirely precise: as of edk2 commit cbccf995920a), and as of upstream QEMU

Re: [edk2-devel] [RedfishPkg PATCH v2 1/4] RedfishPkg: Initial commit of RedfishPkg.

On 09/30/20 03:56, changab wrote: > Initial version of RedfishPkg. > > Signed-off-by: Wu Jiaxin > Signed-off-by: Fu Siyuan > Signed-off-by: Wang Fan > Signed-off-by: Chang Abner > Cc: Nickle Wang > Cc: Andrew Fish > Cc: Laszlo Ersek > Cc: Leif Lindholm > Cc: Michael D Kinney > --- > Redf

Re: [edk2-devel] [PATCH] Update Who we are Wiki

The content looks great; some superficial comments: On 09/30/20 11:40, Liming Gao wrote: > 1. Highlight incompatible change > 2. Define Release Maintainer Role can we split this in two patches? > > Signed-off-by: Liming Gao > Cc: Laszlo Ersek > Cc: Leif Lindholm > Cc: Michael D Kinney > Cc:

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

On 10/01/20 10:44, Laszlo Ersek wrote: > I've been *really* disliking that, for example, the chief MdeModulePkg > reviewers oops, this was a meaning-destroying typo. I meant: "chief maintainers". > don't regularly ACK patches that have been reviewed by > designated reviewers. If those reviewers

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

On 09/30/20 12:13, Leif Lindholm wrote: > Agreed. > > Reviever or Maintainer can approve a patch. Any Maintainer can push a > patch that has been approved. I disagree. Assume Ard and myself are away and Jordan fails to report back in a week or so, but Rebecca or Peter have reviewed a patch on th

Re: 回复: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

On 09/30/20 11:25, gaoliming wrote: > Jiewen: > Frankly speaking, I don't know this rule that the patch needs to get review > or ack from the maintainer. When the reviewer name is formally added into > maintainers.txt, I think the maintainer has delegated the approval work to > reviewers. So,

Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

On 09/30/20 04:11, Yao, Jiewen wrote: > Hi Leif and Liming > I have double checked with Mike Kinney on the role and responsibility of > reviewers. > Mike and I reach the consensus below (a short version, detail will be added > to the wiki page later): > > 1) Maintainers are the ONLY ones who can

Re: [edk2-devel] [RFC] Request to move MinPlatformPkg out of the Intel folder

Hi Nate, I agree this sounds like a good plan. The MinPlatform should be as generic as possible and suitable for all architectures. In fact it is similar to the UEFIPayload package wich is also standalone. Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands