Re: [edk2] [PATCH v9] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
> On Apr 2, 2019, at 8:18 PM, Dong, Eric wrote:
>
> Hi Andrew,
>
> I double confirmed in SDM, CR2 is not included in SMRAM State Save Map. Do
> you means we should add this info in the commit message?
>
Eric,
Sorry I was confused by the commit message. I thought the state save was being
added, vs. being removed in paths that don't modify CR2.
I realize now that the fix did not end up in SmiRendezvous() like this.
if (!mCpuSmmStaticPageTable) {
Cr2 = AsmReadCr2 ();
}
...
if (!mCpuSmmStaticPageTable) {
AsmWriteCr2 (Cr2);
}
As mCpuSmmStaticPageTable is local to X64/PageTbl.c
So we would have to do something like this to not have the functions.
Ia32/PageTbl.c
mCpuSmmStaticPageTable = FALSE;
Thus "This is not a bug but to have better improvement of code." actually means
don't save CR2 if it is not modified in SMM context vs. unconditionally saving
it.
Sorry I have a high error rate on text diffs. In my day job I always use a
difftool or grab the entire branch.
Thanks,
Andrew Fish
> Thanks
> Eric
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Tuesday, April 2, 2019 1:01 AM
> To: Laszlo Ersek
> Cc: Vanguput, Narendra K ; edk2-devel
> ; Yao, Jiewen ; Dong, Eric
>
> Subject: Re: [edk2] [PATCH v9] UefiCpuPkg\CpuSmm: Save & restore CR2
> on-demand paging in SMM
>
>
>
>
> On Apr 1, 2019, at 9:47 AM, Laszlo Ersek <mailto:ler...@redhat.com>> wrote:
>
> On 04/01/19 10:16, nkvangup wrote:
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> <https://bugzilla.tianocore.org/show_bug.cgi?id=1593>
>
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
> This is not a bug but to have better improvement of code.
>
> Patch5 is updated with separate functions for Save and Restore of CR2
> based on review feedback.
>
> Patch6 - Removed Global Cr2 instead used function parameter.
>
> Patch7 - Removed checking Cr2 with 0 as per feedback.
>
> Patch8 and 9 - Aligned with EDK2 Coding style.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K <mailto:narendra.k.vangu...@intel.com>>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Ray Ni mailto:ray...@intel.com>>
> Cc: Laszlo Ersek mailto:ler...@redhat.com>>
> Cc: Yao Jiewen mailto:jiewen@intel.com>>
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 26 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 9 ++---
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 22 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 30 ++
> 4 files changed, 84 insertions(+), 3 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index b734a1ea8c..d1e146a70c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -316,3 +316,29 @@ SetPageTableAttributes (
>
> return ;
> }
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[out] *Cr2 Pointer to variable to hold CR2 register value.
> +**/
> +VOID
> +SaveCr2 (
> + OUT UINTN *Cr2
> + )
> +{
> + return ;
> +}
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register.
> +**/
> +VOID
> +RestoreCr2 (
> + IN UINTN Cr2
> + )
> +{
> + return ;
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..ce70f77709 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1112,9 +1112,11 @@ SmiRendezvous (
> ASSERT(CpuIndex < mMaxNumberOfCpus);
>
> //
> - // Save Cr2 because Page Fault exception in SMM may override its value
> + // Save Cr2 because Page Fault exception in SMM may override its value,
> + // when using on-demand paging for above 4G memory.
> //
> - Cr2 = AsmReadCr2 ();
> + Cr2 = 0;
> + SaveCr2 ();
>
> //
> // Perform CPU specific entry hooks
> @@ -1253,10 +1255,11 @@ SmiRendezvous (
>
> Exit:
> SmmCpuFeaturesRendezvousExit (CpuIndex);
> +
> //
> // Restore Cr2
> //
> - AsmWriteCr2 (Cr2);
> + RestoreCr2 (Cr2);
> }
>
> /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 84efb22981..38f9104117 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -124
Re: [edk2] [PATCH v9] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
to hold CR2 register value.
>> +**/
>> +VOID
>> +SaveCr2 (
>> + OUT UINTN *Cr2
>> + )
>> +{
>> + if (!mCpuSmmStaticPageTable) {
>> +*Cr2 = AsmReadCr2 ();
>> + }
>> +}
>> +
>> +/**
>> + This function restores CR2 register when on-demand paging is enabled.
>> +
>> + @param[in] Cr2 Value to write into CR2 register.
>> +**/
>> +VOID
>> +RestoreCr2 (
>> + IN UINTN Cr2
>> + )
>> +{
>> + if (!mCpuSmmStaticPageTable) {
>> +AsmWriteCr2 (Cr2);
>> + }
>> +}
>>
>
> I agree *how* this patch is implemented is correct, wrt. the IA32 / X64
> split.
>
> A slight improvement for edk2 coding style would be to replace "*Cr2"
> with just "Cr2" in the @param[out] comments, but there's no need to
> repost the patch just because of that.
>
> Regarding the "what" and "why", Nate's and Andrew's comments under v8
> make me uncomfortable about the patch. While the pre-patch comments do say
>
> Save Cr2 because Page Fault exception in SMM may override its value
>
> the post-patch comment (and code) are more restricted -- they claim that
> such an exception (from which we return, anyway) may only occur when
> on-demand paging is enabled (which is in turn a pre-requisite to both
> the SMM profile feature and the SMM heap guard feature).
>
> It is this "narrowing" that concerns me (i.e. the claim that a page
> fault that we consider "expected", and return from, may only occur due
> to enabling on-demand paging). It *seems* like a correct statement, but
> I'd like other reviewers to prove (or disprove) it; so I will not give
> either A-b or R-b.
>
Laszlo,
My understanding for SMM for X64 there are 2 options page tables from 0 - 4 GB
+ making page table entries on page faults, and a pure identity mapped page
table. This behavior is controlled by a PCD setting. So that part of this patch
makes sense to me.
As I mentioned if the non SMM ring 0 CR2 is getting changed that seems like a
bug to me. If the state save of CR2 is some internal state in SMM it feels like
that should be better documented in the patch?
Thanks,
Andrew Fish
> On the testing front, I confirm the patch doesn't regress OVMF. (OVMF
> has on-demand paging *disabled* -- it uses static page tables in X64 SMM
> --, so there the patch removes the CR2 save/restore, on both IA32 and X64.)
>
> Regression-tested-by: Laszlo Ersek <mailto:ler...@redhat.com>>
>
> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
> <https://lists.01.org/mailman/listinfo/edk2-devel>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v8] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
> On Mar 29, 2019, at 2:22 PM, Desimone, Nathaniel L
> wrote:
>
> 1. Why would you do this for 64 bit but not 32 bit?
Is paging enabled on 32-bit, it is required for Long mode?
Also I'm not clear why it is an enhancement given you could take a periodic SMM
in the kernels page fault handler and trashing CR2 seems bad. Maybe there is
some behavior I'm missing?
I'm not sure how big an issue this is but if SMM is modifying CR2 it is leaking
information about SMM operations outside of SMM.
Thanks,
Andrew Fish
> 2. Why don't you add the if statement to MpService.c instead of spreading it
> to PageTbl.c?
> 3. What is the reason for this anyway? Adding the conditional is probably
> more execution time than just reading CR2 always.
>
> Thanks,
> Nate
>
> -Original Message-
> From: edk2-devel On Behalf Of nkvangup
> Sent: Friday, March 29, 2019 8:45 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Laszlo Ersek
> Subject: [edk2] [PATCH v8] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand
> paging in SMM
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
>
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
> This is not a bug but to have better improvement of code.
>
> Patch5 is updated with separate functions for Save and Restore of CR2 based
> on review feedback.
>
> Patch6 - Removed Global Cr2 instead used function parameter
>
> Patch7 - Removed checking Cr2 with 0 as per feedback
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K <mailto:narendra.k.vangu...@intel.com>
> Cc: Eric Dong <mailto:eric.d...@intel.com>
> Cc: Ray Ni <mailto:ray...@intel.com>
> Cc: Laszlo Ersek <mailto:ler...@redhat.com>
> Cc: Yao Jiewen <mailto:jiewen@intel.com>
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 26 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 9 ++---
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 22 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 30 ++
> 4 files changed, 84 insertions(+), 3 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index b734a1ea8c..d3f62ed806 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -316,3 +316,29 @@ SetPageTableAttributes (
>
> return ;
> }
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[out] *Cr2 Pointer to variable to hold CR2 register value **/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + )
> +{
> + return ;
> +}
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register **/ VOID
> +RestoreCr2 (
> + UINTN Cr2
> + )
> +{
> + return ;
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..ce70f77709 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1112,9 +1112,11 @@ SmiRendezvous (
> ASSERT(CpuIndex < mMaxNumberOfCpus);
>
> //
> - // Save Cr2 because Page Fault exception in SMM may override its value
> + // Save Cr2 because Page Fault exception in SMM may override its
> + value, // when using on-demand paging for above 4G memory.
> //
> - Cr2 = AsmReadCr2 ();
> + Cr2 = 0;
> + SaveCr2 ();
>
> //
> // Perform CPU specific entry hooks
> @@ -1253,10 +1255,11 @@ SmiRendezvous (
>
> Exit:
> SmmCpuFeaturesRendezvousExit (CpuIndex);
> +
> //
> // Restore Cr2
> //
> - AsmWriteCr2 (Cr2);
> + RestoreCr2 (Cr2);
> }
>
> /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 84efb22981..05e1b54ed2 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -1243,4 +1243,26 @@ EFIAPI
> PiSmmCpuSmiEntryFixupAddress (
> );
>
> +/**
> + This function reads CR2 register when on-demand paging is enabled
> + for 64 bit and no action for 32 bit.
> +
> + @param[out] *Cr2 Pointer to variable to hold CR2 register value **/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + );
> +
> +/**
> + This function writes into CR2 register when on-demand paging is
> +enabled
> + for 64 bit and no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register **/ VOID
> +Restore
Re: [edk2] [PATCH V2 17/17] MdeModulePkg: Add PEIM and lib to dsc file
I understand the motivation for this change as I've done something much less portable that looks a lot like this to save the PEI XIP space I seem to remember a long time ago we add a public VA_LIST to an API and we ran into an issue due to the marker format being compiler specific. You don't tend to see this on VC++ as it mostly uses a pointer to the frame, but GCC and clang can use a data structure especially not on IA32 (i386) for a VA_LIST (this is part of the reason there are so many #ifdefs in the Base.h VA_LIST section). In the past to fix this Mike Kinney added BASE_LIST. I seem to remember MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode passes a BASE_LIST into ReportStatusCode vs. a VA_LIST for this reason. Was this VA_LIST portability concern taken into consideration for this new API? In general VA_LIST is not an issue as long as all the code is compiled with the same compiler but if binaries are in play then you can have issues. So things like FSB, Option ROMs, OS Loaders, EFI Shell, EFI Apps. are when you can see the issue. Thanks, Andrew Fish > On Mar 14, 2019, at 10:17 PM, Zhichao Gao wrote: > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395 > > Add the new PEIM DebugServicePei and library instance > PeiDebugLibDebugPpi to dsc file to verify it can build > correctly. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Zhichao Gao > Cc: Jian J Wang > Cc: Hao Wu > Cc: Ray Ni > Cc: Star Zeng > Cc: Liming Gao > Cc: Sean Brogan > Cc: Michael Turner > Cc: Bret Barkelew > --- > MdeModulePkg/MdeModulePkg.dsc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc > index 6cd1727a0d..dec441e23e 100644 > --- a/MdeModulePkg/MdeModulePkg.dsc > +++ b/MdeModulePkg/MdeModulePkg.dsc > @@ -297,6 +297,7 @@ > > MdeModulePkg/Library/PlatformHookLibSerialPortPpi/PlatformHookLibSerialPortPpi.inf > MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf > > MdeModulePkg/Library/PeiDxeDebugLibReportStatusCode/PeiDxeDebugLibReportStatusCode.inf > + MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf > MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf > > MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf > MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf > @@ -423,6 +424,8 @@ > MdeModulePkg/Universal/SerialDxe/SerialDxe.inf > MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.inf > > + MdeModulePkg/Universal/DebugServicePei/DebugServicePei.inf > + > MdeModulePkg/Application/CapsuleApp/CapsuleApp.inf > MdeModulePkg/Library/FmpAuthenticationLibNull/FmpAuthenticationLibNull.inf > MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf > -- > 2.16.2.windows.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [staging/PRMCaseStudy]: Creating a new feature branch "PRMCaseStudy"
to disambiguate between UEFI Runtime and PRM drivers. As you know I'm the one always pointing out how complex it is to write EFI Runtime drivers so I'm not really pushing for an expansion of the role of EFI at OS runtime. I coined the term a long time ago that SMM was crack as the 1st time you use it fells OK, but things don't turn out well in the end. My crack commentt was even in the primitive security awareness of my younger days. Anything that helps move code out of SMM is a good thing. In the old days the only safe way to do SMM was to drop all the cores into SMM (PCI config access was via IO port 0xCF8/0xCFC), but that requires a big lock that scales very poorly when you have a lot of cores dropping into SMM (one of the cores could have been doing a cache flush and take a while to drop into SMM). So then folks try and cheat and send a directed SMI, but that yanks a single core away from the OS. Having a CPU just go away for a while is kind of a really bad thing for an OS. Thus I'd say while I share some of your concerns, anything that moves large blocks of code out of SMM is a net win for the platform. Thanks, Andrew Fish PS I was looking at the foils too, and my big question is why did they have a slide that was a picture of Ron "Cadillac Margarita" Story? > > My apologies if I've missed details, or if my comments are otherwise > misguided. > > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
> On Mar 13, 2019, at 1:16 PM, Brian J. Johnson wrote: > > On 3/12/19 12:28 PM, Andrew Fish via edk2-devel wrote: >>> On Mar 12, 2019, at 10:05 AM, Laszlo Ersek wrote: >>> >>> Hello Heyi, >>> >>> On 03/12/19 07:56, Heyi Guo wrote: >>>> Hi Laszlo, >>>> >>>> I'm thinking about a proposal as below: >>>> >>>> 1. Reuse the framework of >>>> MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf >>>> >>>> 2. The boot time behavior of this module is not changed >>>> 3. Switch to status code protocol for runtime debug >>>> 4. Use an overridden SerialPortLib instance for >>>> StatusCodeHandlerRuntimeDxe; the instance must support runtime access. >>>> >>>> Then we can have below benefits: >>>> 1. the boot time firmware log, and the OS log, went to one port; and >>>> there is no dependence for runtime drivers to output serial message at >>>> boot time. >>>> 2. By implementing different instances of SerialPortLib for >>>> StatusCodeHandlerRuntimeDxe, we can have enough flexibility to direct >>>> runtime serial message to platform specific serial port. >>> >>> This looks a bit over-engineered to me. Ultimately our goal is: >>> - for DEBUGs to reach "a" serial port at runtime -- namely one that >>> differs from the "normal" serial port. >>> >>> Given that you'd have to implement a "special" SerialPortLib instance >>> just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps: >>> >>> (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e., >>> stick universally with BaseDebugLibSerialPort, for DebugLib, >>> >>> (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both >>> (a) runtime behavior and (b) handling of a special serial port? >>> >>> In other words, push down the "runtime?" distinction from DebugLib (see >>> commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance >>> would be used only with DXE_RUNTIME_DRIVERs. >>> >>> The lib instance would prepare everything in advance for accessing the >>> "special" serial port at runtime (which could require allocating runtime >>> memory in advance). Once ExitBootServices() is called, a callback should >>> switch over the behavior of the lib instance, without allocating further >>> memory. (The switched-over behavior would not have to be functional >>> until the virtual address map is set.) >>> >> Laszlo, >> Runtime does not quite work like that. As soon as the Set Virtual Address >> map fires it is only legal to call things EFI RT from the virtual mapping. >> The last stage of the Set Virtual Address Map call is to reapply the fixups >> in the Runtime Drivers for the virtual address space. That means any >> absolute address reference in the code now points to the virtual address. >> Also the Set Virtual Address event told the Runtime Driver to convert all >> its pointers to point to the new virtual address space. >> The blackout and the fact you need to hide the hardware from the OS make >> doing things at EFI Runtime Time hard. >> I agree with you that since our logging is really just a serial stream we >> don't require Report Status Code. Report Status Code exists so that the old >> PC POST Cards could still be supported, see: >> https://en.wikipedia.org/wiki/Power-on_self-test#Error_reporting. There is >> also a Report Status Code layer that allows redirecting the stream to >> multiple agents, so for example you could send data to port 80 (POST Card) >> and write out the same values in the serial stream. I find lookup up Report >> Status Code codes very tedious and not really helpful for debugging vs. >> DEBUG prints. >> Thanks, >> Andrew Fish > > Andrew, wasn't Report Status Code also intended to reduce code size? > PeiDxeDebugLibReportStatusCode packages up DEBUG() arguments into a structure > and passes it to the status code handler. It avoids having to link a > PrintLib and SerialPortLib instance into essentially every module. At least > that was the intent... IIRC at some point a few years ago folks realized that > VA_LIST wasn't portable across compilers, so now > PeiDxeDebugLibReportStatusCode converts VA_LIST into BASE_LIST, which > requires parsing the format string much like PrintLib does. No idea if that > actually results in a space savings o
Re: [edk2] F29 Build Issue.
Andrew, This looks like a newer warning added in GCC 8 -Wall? BaseTools/Source/C/GenVtf/GenVtf.h:46:#define FIT_SIGNATURE "_FIT_ " So it looks like the intent is to copy the 8 chars in the string, but not the NULL. That is the intent of -Werror=stringop-truncation. I think this code needs to replace strncpy with memcpy. Please file a bugzilla: https://bugzilla.tianocore.org Thanks, Andrew Fish > On Mar 13, 2019, at 6:27 AM, Andrew J. Hutton > wrote: > > Unsure if this is a missing build dependency (since there doesn't appear to > be a check for this) am I missing a make dep or configure step somewhere? > > This is stock F29, following the website instructions; the make -C > BaseTools/Source/C results in the following errror: > > make[1]: Entering directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' > cc -c -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror > -Wno-deprecated-declarations -nostdlib -c -g -I .. -I ../Include/Common -I > ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I > ../Include/X64/ GenVtf.c -o GenVtf.o > GenVtf.c: In function ‘CreateFitTableAndInitialize’: > GenVtf.c:1473:3: error: ‘strncpy’ output truncated before terminating nul > copying 8 bytes from a string of the same length [-Werror=stringop-truncation] >strncpy ((CHAR8 *) >CompAddress, FIT_SIGNATURE, 8); // > "_FIT_ " >^~~ > cc1: all warnings being treated as errors > make[1]: *** [../Makefiles/footer.makefile:27: GenVtf.o] Error 1 > make[1]: Leaving directory > '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C/GenVtf' > make: *** [GNUmakefile:73: GenVtf] Error 2 > make: Leaving directory '/home/ajh/KVM/Clover/edk2/BaseTools/Source/C' > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC 0/3] Enable runtime serial debug for ArmVirtQemu
> On Mar 12, 2019, at 10:05 AM, Laszlo Ersek wrote: > > Hello Heyi, > > On 03/12/19 07:56, Heyi Guo wrote: >> Hi Laszlo, >> >> I'm thinking about a proposal as below: >> >> 1. Reuse the framework of >> MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf >> >> 2. The boot time behavior of this module is not changed >> 3. Switch to status code protocol for runtime debug >> 4. Use an overridden SerialPortLib instance for >> StatusCodeHandlerRuntimeDxe; the instance must support runtime access. >> >> Then we can have below benefits: >> 1. the boot time firmware log, and the OS log, went to one port; and >> there is no dependence for runtime drivers to output serial message at >> boot time. >> 2. By implementing different instances of SerialPortLib for >> StatusCodeHandlerRuntimeDxe, we can have enough flexibility to direct >> runtime serial message to platform specific serial port. > > This looks a bit over-engineered to me. Ultimately our goal is: > - for DEBUGs to reach "a" serial port at runtime -- namely one that > differs from the "normal" serial port. > > Given that you'd have to implement a "special" SerialPortLib instance > just for StatusCodeHandlerRuntimeDxe anyway, can we perhaps: > > (1) Undo -- dependent on a build flag? -- commit ebfca258f5d7; i.e., > stick universally with BaseDebugLibSerialPort, for DebugLib, > > (2) add a new implementation of "FdtPL011SerialPortLib.inf" with both > (a) runtime behavior and (b) handling of a special serial port? > > In other words, push down the "runtime?" distinction from DebugLib (see > commit 7f029e1b31ee) to SerialPortLib. The new SerialPortLib instance > would be used only with DXE_RUNTIME_DRIVERs. > > The lib instance would prepare everything in advance for accessing the > "special" serial port at runtime (which could require allocating runtime > memory in advance). Once ExitBootServices() is called, a callback should > switch over the behavior of the lib instance, without allocating further > memory. (The switched-over behavior would not have to be functional > until the virtual address map is set.) > Laszlo, Runtime does not quite work like that. As soon as the Set Virtual Address map fires it is only legal to call things EFI RT from the virtual mapping. The last stage of the Set Virtual Address Map call is to reapply the fixups in the Runtime Drivers for the virtual address space. That means any absolute address reference in the code now points to the virtual address. Also the Set Virtual Address event told the Runtime Driver to convert all its pointers to point to the new virtual address space. The blackout and the fact you need to hide the hardware from the OS make doing things at EFI Runtime Time hard. I agree with you that since our logging is really just a serial stream we don't require Report Status Code. Report Status Code exists so that the old PC POST Cards could still be supported, see: https://en.wikipedia.org/wiki/Power-on_self-test#Error_reporting. There is also a Report Status Code layer that allows redirecting the stream to multiple agents, so for example you could send data to port 80 (POST Card) and write out the same values in the serial stream. I find lookup up Report Status Code codes very tedious and not really helpful for debugging vs. DEBUG prints. Thanks, Andrew Fish > I've always seen status code reporting cumbersome in comparison to plain > DEBUG messages. My understanding is that status code reporting targets > devices that are even dumber than serial ports. But, we do target a > second serial port. So if we can keep the switchover internal to the > SerialPortLib class, at least for runtime DXE drivers, then I think we > should do that. > > Thanks, > Laszlo > >> On 2019/3/1 23:27, Laszlo Ersek wrote: >>> +Peter, for the last few paragraphs >>> >>> On 02/28/19 13:10, Ard Biesheuvel wrote: >>>> On Thu, 28 Feb 2019 at 09:06, Heyi Guo wrote: >>>>> Serial port output is useful when debugging UEFI runtime services in >>>>> OS runtime. >>>>> The patches are trying to provide a handy method to enable runtime >>>>> serial port >>>>> debug for ArmVirtQemu. >>>>> >>>>> Cc: Jian J Wang >>>>> Cc: Hao Wu >>>>> Cc: Laszlo Ersek >>>>> Cc: Ard Biesheuvel >>>>> Cc: Julien Grall >>>>> >>>>> Heyi Guo (3): >>>>>MdeModulePkg/StatusCode: Add PCD to enable runtime serial debug >>>>>ArmVirtPkg: add runtime insta
Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
> On Mar 11, 2019, at 9:04 AM, Yao, Jiewen wrote:
>
> Thanks Andrew.
> + More CPU people in our team.
>
> Do you want to post your patch there for reference? :-)
>
> BTW: Would you please share how to trigger such case at your side?
> Did you report above 4GB memory to be tested?
Jiewen,
I'm working on a chipset that is not open source and I or'ed in
EFI_RESOURCE_ATTRIBUTE_TESTED to the above 4GB allocation in
BuildResourceDescriptorHob(). The DXE Core then picked this area for the heap,
as I seem to remember the 1st loop favors the PHIT, and the 2nd loop favors the
largest area of free memory.
> As such all drivers are loaded to above 4GB?
DXE Core is loaded low, and all the drivers loaded by DXE are in > 4GB memory.
> Do you also allocate BIN to above 4GB?
>
No I just marked the above 4G memory as tested.
Thanks,
Andrew Fish
> Thank you
> Yao Jiewen
>
>
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Andrew Fish via edk2-devel
>> Sent: Monday, March 11, 2019 11:59 PM
>> To: Yao, Jiewen
>> Cc: edk2-devel ; Laszlo Ersek
>> Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
>>
>> Jiewen,
>>
>> These three fixes got me past the CpuDxe driver:
>> https://bugzilla.tianocore.org/show_bug.cgi?id=1613
>>
>> Now I getting page faults loading SMM
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> On Mar 8, 2019, at 7:10 PM, Andrew Fish wrote:
>>>
>>>
>>>
>>>> On Mar 8, 2019, at 7:08 AM, Laszlo Ersek > <mailto:ler...@redhat.com>> wrote:
>>>>
>>>> On 03/08/19 15:13, Yao, Jiewen wrote:
>>>>> I guess the historic reason is that AP and BSP share same GDT before. As
>> such, the GDT need to be below 4G, to let AP switch from real mode to
>> protected mode.
>>>>> We don't get issue, because Runtime memory is in BIN, and most
>> platform allocates BIN under 4G.
>>>>>
>>>>> Some thought:
>>>>> 1) I am think we not sure if AP is using same GDT as BSP today. If yes, we
>> need GDT under 4G, by using MaxAddress. If no, there should be no
>> restriction for BSP GDT. The (UINT32) case should be removed for BSP. But
>> we still AP GDT below 4G, to support wake from INIT-SIPI-SIPI.
>>>
>>> Jiewen,
>>>
>>> It looks like there are several places that assume memory is < 4 GB in the
>> CpuDxe driver.
>>>
>>> I noticed SetCodeSelector () is using a far jump to change the CS at that is
>> limited < 4 GB. I had to hack around it via:
>>> popq%rax
>>> pushq %rcx
>>> pushq %rax
>>> lretq
>>>
>>> There is some other crash later on.
>>>
>>>
>>>>> 2) I am not sure why we need runtime memory. Do we need touch GDT
>> at UEFI runtime?
>>>>
>>>> I could be confusing things *very badly*, but I vaguely remember that
>>>> APs could be woken up spuriously later, and they must be able to execute
>>>> code "enough" to go back to sleep.
>>>>
>>>> The following commits look relevant:
>>>>
>>>> - 7615702169b8 ("UefiCpuPkg/MpInitLib: Add AsmRelocateApLoop()
>> assembly
>>>> code", 2016-08-17)
>>>>
>>>> - 4d3314f69488 ("UefiCpuPkg/MpInitLib: Place APs in safe loop before
>>>> hand-off to OS", 2016-08-17)
>>>>
>>>> - bf2786dc7900 ("UefiCpuPkg/DxeMpLib: Allocate new safe stack < 4GB",
>>>> 2016-11-28)
>>>>
>>>
>>> If I'm remembering correctly there are optional idle states for the AP. I
>> think the real mode hlt loop might have used too much power on an UP OS.
>>>
>>> It is also not clear to me that we don't need the GDT when in real mode. In
>> big-real mode you go to protected mode set the GDT and then it can get
>> used for big-real so it seems like the GDT is in play even in real mode.
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>
>>>> Laszlo
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>> Yao Jiewen
>>>>>
>>>>>
>>>>>> -Original Message-
>>>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
>> <mailto:edk2-devel-boun...@lists.01.org>] On Behalf Of
>>>>>&g
Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
Jiewen,
These three fixes got me past the CpuDxe driver:
https://bugzilla.tianocore.org/show_bug.cgi?id=1613
Now I getting page faults loading SMM
Thanks,
Andrew Fish
> On Mar 8, 2019, at 7:10 PM, Andrew Fish wrote:
>
>
>
>> On Mar 8, 2019, at 7:08 AM, Laszlo Ersek > <mailto:ler...@redhat.com>> wrote:
>>
>> On 03/08/19 15:13, Yao, Jiewen wrote:
>>> I guess the historic reason is that AP and BSP share same GDT before. As
>>> such, the GDT need to be below 4G, to let AP switch from real mode to
>>> protected mode.
>>> We don't get issue, because Runtime memory is in BIN, and most platform
>>> allocates BIN under 4G.
>>>
>>> Some thought:
>>> 1) I am think we not sure if AP is using same GDT as BSP today. If yes, we
>>> need GDT under 4G, by using MaxAddress. If no, there should be no
>>> restriction for BSP GDT. The (UINT32) case should be removed for BSP. But
>>> we still AP GDT below 4G, to support wake from INIT-SIPI-SIPI.
>
> Jiewen,
>
> It looks like there are several places that assume memory is < 4 GB in the
> CpuDxe driver.
>
> I noticed SetCodeSelector () is using a far jump to change the CS at that is
> limited < 4 GB. I had to hack around it via:
>popq%rax
>pushq %rcx
>pushq %rax
>lretq
>
> There is some other crash later on.
>
>
>>> 2) I am not sure why we need runtime memory. Do we need touch GDT at UEFI
>>> runtime?
>>
>> I could be confusing things *very badly*, but I vaguely remember that
>> APs could be woken up spuriously later, and they must be able to execute
>> code "enough" to go back to sleep.
>>
>> The following commits look relevant:
>>
>> - 7615702169b8 ("UefiCpuPkg/MpInitLib: Add AsmRelocateApLoop() assembly
>> code", 2016-08-17)
>>
>> - 4d3314f69488 ("UefiCpuPkg/MpInitLib: Place APs in safe loop before
>> hand-off to OS", 2016-08-17)
>>
>> - bf2786dc7900 ("UefiCpuPkg/DxeMpLib: Allocate new safe stack < 4GB",
>> 2016-11-28)
>>
>
> If I'm remembering correctly there are optional idle states for the AP. I
> think the real mode hlt loop might have used too much power on an UP OS.
>
> It is also not clear to me that we don't need the GDT when in real mode. In
> big-real mode you go to protected mode set the GDT and then it can get used
> for big-real so it seems like the GDT is in play even in real mode.
>
> Thanks,
>
> Andrew Fish
>
>
>> Laszlo
>>
>>>
>>>
>>>
>>> Thank you
>>> Yao Jiewen
>>>
>>>
>>>> -Original Message-
>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org
>>>> <mailto:edk2-devel-boun...@lists.01.org>] On Behalf Of
>>>> Laszlo Ersek
>>>> Sent: Friday, March 8, 2019 12:00 AM
>>>> To: Andrew Fish mailto:af...@apple.com>>; edk2-devel
>>>> mailto:edk2-devel@lists.01.org>>
>>>> Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
>>>>
>>>> Hi Andrew,
>>>>
>>>> On 03/07/19 23:37, Andrew Fish via edk2-devel wrote:
>>>>> I'm trying to understand why gdtPtr.Base is casting to (UINT32)?
>>>>> 1) gdtPtr.Base is a a UINTN
>>>>> 2) It is legal for AllocateRuntimePool() to return an address > 4GB
>>>>>
>>>>> It seems like the code should just cast to (UINTN)?
>>>>>
>>>>>
>>>>>
>>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuG
>>>> <https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuG>
>>>> dt.c#L151
>>>>
>>>> I think you are right.
>>>>
>>>> I'm missing the background on this too. I tried to see if any
>>>> justification was given in a git commit message, but according to "git
>>>> blame", this code dates back to the original addition of the driver,
>>>> namely commit a47463f28382 ("Add CPU DXE driver for IA32 & X64
>>>> processor
>>>> architectures.", 2009-05-27). The commit message is unhelpful (for 3119
>>>> lines added).
>>>>
>>>> Thanks
>>>> Laszlo
>>>>
>>>>>
>>>>>
>>>>>
>>>>> VOID
>>>>> InitGlobalDescriptorTable (
>>>>> VOID
>>>>> )
>>>>> {
>>>>> GDT_ENTRIES *gdt;
>>>>> IA32_DESCRIPTOR gdtPtr;
>>>>>
>>>>> //
>>>>> // Allocate Runtime Data for the GDT
>>>>> //
>>>>> gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
>>>>> ASSERT (gdt != NULL);
>>>>> gdt = ALIGN_POINTER (gdt, 8);
>>>>>
>>>>> //
>>>>> // Initialize all GDT entries
>>>>> //
>>>>> CopyMem (gdt, , sizeof (GdtTemplate));
>>>>>
>>>>> //
>>>>> // Write GDT register
>>>>> //
>>>>> gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
>>>>> gdtPtr.Limit = (UINT16) (sizeof (GdtTemplate) - 1);
>>>>> AsmWriteGdtr ();
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Fish
>>>>> ___
>>>>> edk2-devel mailing list
>>>>> edk2-devel@lists.01.org
>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>>
>>>>
>>>> ___
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
> On Mar 8, 2019, at 7:08 AM, Laszlo Ersek wrote:
>
> On 03/08/19 15:13, Yao, Jiewen wrote:
>> I guess the historic reason is that AP and BSP share same GDT before. As
>> such, the GDT need to be below 4G, to let AP switch from real mode to
>> protected mode.
>> We don't get issue, because Runtime memory is in BIN, and most platform
>> allocates BIN under 4G.
>>
>> Some thought:
>> 1) I am think we not sure if AP is using same GDT as BSP today. If yes, we
>> need GDT under 4G, by using MaxAddress. If no, there should be no
>> restriction for BSP GDT. The (UINT32) case should be removed for BSP. But we
>> still AP GDT below 4G, to support wake from INIT-SIPI-SIPI.
Jiewen,
It looks like there are several places that assume memory is < 4 GB in the
CpuDxe driver.
I noticed SetCodeSelector () is using a far jump to change the CS at that is
limited < 4 GB. I had to hack around it via:
popq%rax
pushq %rcx
pushq %rax
lretq
There is some other crash later on.
>> 2) I am not sure why we need runtime memory. Do we need touch GDT at UEFI
>> runtime?
>
> I could be confusing things *very badly*, but I vaguely remember that
> APs could be woken up spuriously later, and they must be able to execute
> code "enough" to go back to sleep.
>
> The following commits look relevant:
>
> - 7615702169b8 ("UefiCpuPkg/MpInitLib: Add AsmRelocateApLoop() assembly
> code", 2016-08-17)
>
> - 4d3314f69488 ("UefiCpuPkg/MpInitLib: Place APs in safe loop before
> hand-off to OS", 2016-08-17)
>
> - bf2786dc7900 ("UefiCpuPkg/DxeMpLib: Allocate new safe stack < 4GB",
> 2016-11-28)
>
If I'm remembering correctly there are optional idle states for the AP. I think
the real mode hlt loop might have used too much power on an UP OS.
It is also not clear to me that we don't need the GDT when in real mode. In
big-real mode you go to protected mode set the GDT and then it can get used for
big-real so it seems like the GDT is in play even in real mode.
Thanks,
Andrew Fish
> Laszlo
>
>>
>>
>>
>> Thank you
>> Yao Jiewen
>>
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Laszlo Ersek
>>> Sent: Friday, March 8, 2019 12:00 AM
>>> To: Andrew Fish ; edk2-devel
>>> Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
>>>
>>> Hi Andrew,
>>>
>>> On 03/07/19 23:37, Andrew Fish via edk2-devel wrote:
>>>> I'm trying to understand why gdtPtr.Base is casting to (UINT32)?
>>>> 1) gdtPtr.Base is a a UINTN
>>>> 2) It is legal for AllocateRuntimePool() to return an address > 4GB
>>>>
>>>> It seems like the code should just cast to (UINTN)?
>>>>
>>>>
>>>>
>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuG
>>> dt.c#L151
>>>
>>> I think you are right.
>>>
>>> I'm missing the background on this too. I tried to see if any
>>> justification was given in a git commit message, but according to "git
>>> blame", this code dates back to the original addition of the driver,
>>> namely commit a47463f28382 ("Add CPU DXE driver for IA32 & X64
>>> processor
>>> architectures.", 2009-05-27). The commit message is unhelpful (for 3119
>>> lines added).
>>>
>>> Thanks
>>> Laszlo
>>>
>>>>
>>>>
>>>>
>>>> VOID
>>>> InitGlobalDescriptorTable (
>>>> VOID
>>>> )
>>>> {
>>>> GDT_ENTRIES *gdt;
>>>> IA32_DESCRIPTOR gdtPtr;
>>>>
>>>> //
>>>> // Allocate Runtime Data for the GDT
>>>> //
>>>> gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
>>>> ASSERT (gdt != NULL);
>>>> gdt = ALIGN_POINTER (gdt, 8);
>>>>
>>>> //
>>>> // Initialize all GDT entries
>>>> //
>>>> CopyMem (gdt, , sizeof (GdtTemplate));
>>>>
>>>> //
>>>> // Write GDT register
>>>> //
>>>> gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
>>>> gdtPtr.Limit = (UINT16) (sizeof (GdtTemplate) - 1);
>>>> AsmWriteGdtr ();
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>> ___
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
> On Mar 8, 2019, at 4:07 PM, Kinney, Michael D
> wrote:
>
> Jiewen,
>
> There are not many of those functions and they can be on speed paths.
>
> I do not recommend converting them to only NASM.
>
> I do recommend we add comments to NASM files and C files with include
> assembly that state that updates to one require updates to the others.
>
Mike,
It looks like NASM files only exist to support the INTEL compiler. Could that
be an outdated assumption? Overtime has the INTEL compiler added more
compatibility with GCC inline assembly, or VC++ intrinsics? I assume people are
still using the INTEL compiler?
Thanks,
Andrew Fish
> Mike
> <>
> From: Yao, Jiewen
> Sent: Wednesday, March 6, 2019 11:25 PM
> To: Gao, Liming ; af...@apple.com
> Cc: Kinney, Michael D ; edk2-devel-01
>
> Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline
> X86 assembly code
>
> Thanks.
>
> I also recommend to take a look at MdePkg\Library\BaseSynchronizationLib.
>
> That is also complicated and not so readable for me.
>
> And we have 8 patches to *fix* the real problem in 2018.
>
> Thank you
> Yao Jiewen
>
>
> <>From: Gao, Liming
> Sent: Wednesday, March 6, 2019 11:15 PM
> To: af...@apple.com <mailto:af...@apple.com>; Yao, Jiewen
> mailto:jiewen@intel.com>>
> Cc: Kinney, Michael D <mailto:michael.d.kin...@intel.com>>; edk2-devel-01 <mailto:edk2-devel@lists.01.org>>
> Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline
> X86 assembly code
>
> Thanks for your clarification. Now, we will focus on SetJump/LongJump() first.
>
> Thanks
> Liming
> From: af...@apple.com <mailto:af...@apple.com> [mailto:af...@apple.com
> <mailto:af...@apple.com>]
> Sent: Wednesday, March 6, 2019 10:45 PM
> To: Yao, Jiewen mailto:jiewen@intel.com>>
> Cc: Kinney, Michael D <mailto:michael.d.kin...@intel.com>>; Gao, Liming <mailto:liming@intel.com>>; edk2-devel-01 <mailto:edk2-devel@lists.01.org>>
> Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline
> X86 assembly code
>
>
>
>
> On Mar 6, 2019, at 10:09 PM, Yao, Jiewen <mailto:jiewen@intel.com>> wrote:
>
> Thanks Andrew.
> Now I 100% agree with you - I think it is fine to restrict new C inline
> assembler, or at least have a very high bar to add anything new. Any new
> inline assembler *should also be simple and just be a function abstracting a
> CPU op-code* that is not available to C. This is how we prevent the
> maintenance issues you are worrying about.
>
> And I also agree with your case.
>
> Let’s discuss another case. Below 2 functions SetJump/LongJump are updated
> recently, by me unfortunately.
>
> It is unclear to me what is the size optimization we can get by inline
> SetJump/LongJump.
> But obviously, it brings the maintenance issue to me.
> And I don’t believe it meets the criteria you mentioned above.
>
>
> Jiewen,
>
> I agree it seems like given the rules we agree on this code should be written
> in NASM.
>
> Thanks,
>
> Andrew Fish
>
>
> _declspec (naked)
> RETURNS_TWICE
> UINTN
> EFIAPI
> SetJump (
> OUT BASE_LIBRARY_JUMP_BUFFER *JumpBuffer
> )
> {
> _asm {
> push[esp + 4]
> callInternalAssertJumpBuffer
> pop ecx
> pop ecx
> mov edx, [esp]
>
> xor eax, eax
> mov [edx + 24], eax; save 0 to SSP
>
> mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
> testeax, eax
> jz CetDone
> _emit 0x0F
> _emit 0x20
> _emit 0xE0; mov eax, cr4
> bt eax, 23; check if CET is enabled
> jnc CetDone
>
> mov eax, 1
> _emit 0xF3
> _emit 0x0F
> _emit 0xAE
> _emit 0xE8; INCSSP EAX to read original SSP
> _emit 0xF3
> _emit 0x0F
> _emit 0x1E
> _emit 0xC8; READSSP EAX
> mov [edx + 0x24], eax ; save SSP
>
> CetDone:
>
> mov [edx], ebx
> mov [edx + 4], esi
> mov [edx + 8], edi
> mov [edx + 12], ebp
> mov [edx + 16], esp
> mov [edx + 20], ecx
> xor eax, eax
> jmp ecx
> }
> }
>
> __declspec (naked)
> VOID
> EFIAPI
> InternalLongJump (
> IN BASE_LIBRARY_JUMP_BUFFER *JumpBuffer,
> IN UINTN Va
Re: [edk2] UefiCpuPkg CpuDxe GDT init question?
Actually it looks like the the CpuDxe driver is coded to only run if it it is
loaded under 4 GB? Is that following the spec? Is that intentional?
I noticed that SetCodeSelector is coded to use a far jump and that is a 32-bit
absolute value? Note [rsp+4]
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/X64/CpuAsm.nasm#L28
ASM_PFX(SetCodeSelector):
sub rsp, 0x10
lea rax, [setCodeSelectorLongJump]
mov [rsp], rax
mov [rsp+4], cx
jmp dword far [rsp]
setCodeSelectorLongJump:
add rsp, 0x10
ret
Thanks,
Andrew Fish
> On Mar 7, 2019, at 2:37 PM, Andrew Fish wrote:
>
> I'm trying to understand why gdtPtr.Base is casting to (UINT32)?
> 1) gdtPtr.Base is a a UINTN
> 2) It is legal for AllocateRuntimePool() to return an address > 4GB
>
> It seems like the code should just cast to (UINTN)?
>
>
> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuGdt.c#L151
> <https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuGdt.c#L151>
>
>
>
> VOID
> InitGlobalDescriptorTable (
> VOID
> )
> {
> GDT_ENTRIES *gdt;
> IA32_DESCRIPTOR gdtPtr;
>
> //
> // Allocate Runtime Data for the GDT
> //
> gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
> ASSERT (gdt != NULL);
> gdt = ALIGN_POINTER (gdt, 8);
>
> //
> // Initialize all GDT entries
> //
> CopyMem (gdt, , sizeof (GdtTemplate));
>
> //
> // Write GDT register
> //
> gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
> gdtPtr.Limit = (UINT16) (sizeof (GdtTemplate) - 1);
> AsmWriteGdtr ();
>
> Thanks,
>
> Andrew Fish
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] UefiCpuPkg CpuDxe GDT init question?
I'm trying to understand why gdtPtr.Base is casting to (UINT32)?
1) gdtPtr.Base is a a UINTN
2) It is legal for AllocateRuntimePool() to return an address > 4GB
It seems like the code should just cast to (UINTN)?
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuGdt.c#L151
VOID
InitGlobalDescriptorTable (
VOID
)
{
GDT_ENTRIES *gdt;
IA32_DESCRIPTOR gdtPtr;
//
// Allocate Runtime Data for the GDT
//
gdt = AllocateRuntimePool (sizeof (GdtTemplate) + 8);
ASSERT (gdt != NULL);
gdt = ALIGN_POINTER (gdt, 8);
//
// Initialize all GDT entries
//
CopyMem (gdt, , sizeof (GdtTemplate));
//
// Write GDT register
//
gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt;
gdtPtr.Limit = (UINT16) (sizeof (GdtTemplate) - 1);
AsmWriteGdtr ();
Thanks,
Andrew Fish
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
> On Mar 6, 2019, at 10:09 PM, Yao, Jiewen wrote:
>
> Thanks Andrew.
> Now I 100% agree with you - I think it is fine to restrict new C inline
> assembler, or at least have a very high bar to add anything new. Any new
> inline assembler *should also be simple and just be a function abstracting a
> CPU op-code* that is not available to C. This is how we prevent the
> maintenance issues you are worrying about.
>
> And I also agree with your case.
>
> Let’s discuss another case. Below 2 functions SetJump/LongJump are updated
> recently, by me unfortunately.
>
> It is unclear to me what is the size optimization we can get by inline
> SetJump/LongJump.
> But obviously, it brings the maintenance issue to me.
> And I don’t believe it meets the criteria you mentioned above.
>
Jiewen,
I agree it seems like given the rules we agree on this code should be written
in NASM.
Thanks,
Andrew Fish
> _declspec (naked)
> RETURNS_TWICE
> UINTN
> EFIAPI
> SetJump (
> OUT BASE_LIBRARY_JUMP_BUFFER *JumpBuffer
> )
> {
> _asm {
> push[esp + 4]
> callInternalAssertJumpBuffer
> pop ecx
> pop ecx
> mov edx, [esp]
>
> xor eax, eax
> mov [edx + 24], eax; save 0 to SSP
>
> mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
> testeax, eax
> jz CetDone
> _emit 0x0F
> _emit 0x20
> _emit 0xE0; mov eax, cr4
> bt eax, 23; check if CET is enabled
> jnc CetDone
>
> mov eax, 1
> _emit 0xF3
> _emit 0x0F
> _emit 0xAE
> _emit 0xE8; INCSSP EAX to read original SSP
> _emit 0xF3
> _emit 0x0F
> _emit 0x1E
> _emit 0xC8; READSSP EAX
> mov [edx + 0x24], eax ; save SSP
>
> CetDone:
>
> mov [edx], ebx
> mov [edx + 4], esi
> mov [edx + 8], edi
> mov [edx + 12], ebp
> mov [edx + 16], esp
> mov [edx + 20], ecx
> xor eax, eax
> jmp ecx
> }
> }
>
> __declspec (naked)
> VOID
> EFIAPI
> InternalLongJump (
> IN BASE_LIBRARY_JUMP_BUFFER *JumpBuffer,
> IN UINTN Value
> )
> {
> _asm {
> mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
> testeax, eax
> jz CetDone
> _emit 0x0F
> _emit 0x20
> _emit 0xE0; mov eax, cr4
> bt eax, 23; check if CET is enabled
> jnc CetDone
>
> mov edx, [esp + 4] ; edx = JumpBuffer
> mov edx, [edx + 24]; edx = target SSP
> _emit 0xF3
> _emit 0x0F
> _emit 0x1E
> _emit 0xC8; READSSP EAX
> sub edx, eax ; edx = delta
> mov eax, edx ; eax = delta
>
> shr eax, 2 ; eax = delta/sizeof(UINT32)
> _emit 0xF3
> _emit 0x0F
> _emit 0xAE
> _emit 0xE8; INCSSP EAX
>
> CetDone:
>
> pop eax ; skip return address
> pop edx ; edx <- JumpBuffer
> pop eax ; eax <- Value
> mov ebx, [edx]
> mov esi, [edx + 4]
> mov edi, [edx + 8]
> mov ebp, [edx + 12]
> mov esp, [edx + 16]
> jmp dword ptr [edx + 20]
> }
> }
>
>
> <>
> <>From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, March 6, 2019 9:56 PM
> To: Yao, Jiewen
> Cc: Kinney, Michael D ; Gao, Liming
> ; edk2-devel-01
> Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline
> X86 assembly code
>
>
>
>
> On Mar 6, 2019, at 9:06 PM, Yao, Jiewen <mailto:jiewen@intel.com>> wrote:
>
> HI Mike and Andrew
> The problem is maintainability.
>
> If we have multiple copy of implementation, a developer need verify multiple
> copy of implementation, if we make update. Before that, a developer has to be
> aware that there is multiple copy of implementation. - That increases the
> complexity.
>
> If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS
> inline, theoretically.
> Now, we remove ASM. It is good first step.
> But we may still have 4 copies. I suggest we consider do more.
>
>
> Jiewen,
>
> I think you are trying do the right thing, but are optimize the wrong
Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
> On Mar 6, 2019, at 9:06 PM, Yao, Jiewen wrote:
>
> HI Mike and Andrew
> The problem is maintainability.
>
> If we have multiple copy of implementation, a developer need verify multiple
> copy of implementation, if we make update. Before that, a developer has to be
> aware that there is multiple copy of implementation. - That increases the
> complexity.
>
> If we have everything, there MAY be 5 copy - ASM, NASM, S, GCC inline, MS
> inline, theoretically.
> Now, we remove ASM. It is good first step.
> But we may still have 4 copies. I suggest we consider do more.
>
Jiewen,
I think you are trying do the right thing, but are optimize the wrong thing.
Most of the GCC/Clang inline assembler code is in Gccinline.c and since that
code is mostly just abstracting an x86 instruction and the functions are very
simple and thus it is NOT code that needs ongoing maintenance.
Lets look at the history:
https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/X64/GccInline.c
The last logic fix was Jun 1, 2010
https://github.com/tianocore/edk2/commits/master/MdePkg/Library/BaseLib/Ia32/GccInline.c
Ok so Mike had to make a fix in this file in 2015 to make something optional,
due to an embedded CPU defeating an instruction. But prior to that it was 2010.
The set of things that are C inline assembler we have should be static and not
require much maintenance. More complex code should be written in C and use the
C inline assembler functions we already have. If any more complex assembly code
is required we should just write it in NASM. So I think it is fine to restrict
new C inline assembler, or at least have a very high bar to add anything new.
Any new inline assembler should also be simple and just be a function
abstracting a CPU op-code that is not available to C. This is how we prevent
the maintenance issues you are worrying about.
I gave an example in this mail thread on how a Breakpoint goes from being 1
byte to 11 bytes if you remove the C inline assembler. For clang with LTO
enabled a CpuBreakpoint will always get inlined into the callers code and it
will only take the one byte for int 3 instruction. If that code moves to NASM
then it get replaces with a 5 byte call instruction and an actual C ABI
function for the breakpoint.
VOID
EFIAPI
CpuBreakpoint (
VOID
)
{
__asm__ __volatile__ ("int $3");
}
Today with clang LTO turned on calling CpuBreakpoint() looks like this from the
callers point of view.
a.out[0x1fa5] <+6>: cc int3
But if we move that to NASM:
a.out[0x1fa6] <+7>: e8 07 00 00 00 calll 0x1fb2;
CpuBreakpoint
plus:
a.out`CpuBreakpoint:
a.out[0x1f99] <+0>: 55 pushl %ebp
a.out[0x1f9a] <+1>: 89 e5 movl %esp, %ebp
a.out[0x1f9c] <+3>: cc int3
a.out[0x1f9d] <+4>: 5d popl %ebp
a.out[0x1f9e] <+5>: c3 retl
For any compiler that emits the frame pointer if you move the INT 3 to assembly
you need the frame pointer or the Exception Lib is not going to be able to
print out the stack backtrace of the code when you hit a breakpoint. So this is
how I get to 11 vs. 1 bytes.
Thanks,
Andrew Fish
PS for clang LTO the compiler compiles to bitcode and that is an abstracted
assembly language. At link time all that code gets optimized to together and
then passed through the CPU specific code gen. For C inline assembler the
assembly instructions end up in the bitcode with lots of information about the
constraints. That is why these GccInline.c functions almost always get inlined
with clang and LTO.
The CpuBreakpoint() function looks like this in bitcode, but the function call
gets optimized away by LTO in the code gen.
; Function Attrs: noinline nounwind optnone ssp uwtable
define void @CpuBreakpoint() #0 {
call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2,
!srcloc !3
ret void
}
Even something more complex like AsmReadMsr64() can get inlined, but it
contains a lot more info about the constraints:
; Function Attrs: noinline nounwind optnone ssp uwtable
define i64 @AsmReadMsr64(i32) #0 {
%2 = alloca i32, align 4
%3 = alloca i64, align 8
store i32 %0, i32* %2, align 4
%4 = load i32, i32* %2, align 4
%5 = call i64 asm sideeffect "rdmsr",
"=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
store i64 %5, i64* %3, align 8
%6 = load i64, i64* %3, align 8
ret i64 %6
}
The alloca, store, load, etc are the same bitcode instructions you would see
with C code.
> A recently case that SetJump/LongJump, I updated the NASM file for both IA32
> and X64.
>
> Later, to my surprise, only X64 version NASM works, and IA32 version NASM
> does not work.
> Then I notice that there is a different copy if IA32 Jump.c MS inline - I
> also need update. That is frustrated.
>
> I think the
Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
> On Mar 6, 2019, at 4:41 PM, Kinney, Michael D
> wrote:
>
> Liming,
>
> That does not work either because inline assembly uses compiler specific
> syntax.
>
> Please update with the specific list of functions that you think the inline
> should be removed to improve maintenance with no impacts in size/perf.
>
Mike,
It is easy to find the gcc/clang inline assembler, just `git grep "__asm__
__volatile__"`
The main files are:
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/X64/GccInline.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseLib/Ia32/GccInline.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseSynchronizationLib/Ia32/GccInline.c
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/BaseSynchronizationLib/X64/GccInline.c
This is really just compiler optimizer control.
Library/BaseSynchronizationLib/SynchronizationGcc.c:21:#define
_ReadWriteBarrier() do { __asm__ __volatile__ ("": : : "memory"); } while(0)
Looks like this is working around the alignment ASSERT in BaseIoLibIntrinsic.
OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c:43: __asm__ __volatile__ ( "outl %0, %1"
: : "a" (Value), "d" ((UINT16)Port) );
OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c:67: __asm__ __volatile__ ( "inl %1, %0"
: "=a" (Data) : "d" ((UINT16)Port) );
It seems like we have a reasonable set and should not use the inline assembly
for any more complex code.
Thanks,
Andrew Fish
> The issue you pointed to was around SetJump()/LongJump(). Can we limit this
> BZ to only those 2 functions?
>
> Mike
> <>
> From: Gao, Liming
> Sent: Wednesday, March 6, 2019 4:28 PM
> To: af...@apple.com
> Cc: Zhang, Shenglei ; edk2-devel-01
> ; Kinney, Michael D
> Subject: RE: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline
> X86 assembly code
>
> Andrew:
> I want to keep only one implementation. If inline assembly c source is
> preferred, I suggest to remove its nasm implementation.
>
> Thanks
> Liming
> <>From: af...@apple.com <mailto:af...@apple.com> [mailto:af...@apple.com
> <mailto:af...@apple.com>]
> Sent: Tuesday, March 5, 2019 2:44 PM
> To: Gao, Liming mailto:liming@intel.com>>
> Cc: Zhang, Shenglei <mailto:shenglei.zh...@intel.com>>; edk2-devel-01 <mailto:edk2-devel@lists.01.org>>; Kinney, Michael D
> mailto:michael.d.kin...@intel.com>>
> Subject: Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline
> X86 assembly code
>
>
>
>
> On Mar 5, 2019, at 1:32 PM, Gao, Liming <mailto:liming@intel.com>> wrote:
>
> Andrew:
> BZ 1163 is to remove inline X86 assembly code in C source file. But, this
> patch is wrong. I have gave my comments to update this patch.
>
>
> Why do we want to remove inline X86 assembly. As I mentioned it will lead to
> larger binaries, slower binaries, and less optimized code.
>
> For example take this simple inline assembly function:
>
> VOID
> EFIAPI
> CpuBreakpoint (
> VOID
> )
> {
> __asm__ __volatile__ ("int $3");
> }
>
>
> Today with clang LTO turned on calling CpuBreakpoint() looks like this from
> the callers point of view.
>
> a.out[0x1fa5] <+6>: cc int3
>
>
> But if we move that to NASM:
>
>
> a.out[0x1fa6] <+7>: e8 07 00 00 00 calll 0x1fb2;
> CpuBreakpoint
>
>
> plus:
> a.out`CpuBreakpoint:
> a.out[0x1fb2] <+0>: cc int3
> a.out[0x1fb3] <+1>: c3 retl
>
>
> And there is also an extra push and pop on the stack. The other issue is the
> call to the function that is unknown to the compiler will act like a
> _ReadWriteBarrier (Yikes I see _ReadWriteBarrier is deprecated in VC++ 2017).
> Is the depreciation of some of these intrinsics in VC++ driving the removal
> of inline assembly? For GCC inline assembly works great for local compile,
> and for clang LTO it works in entire program optimization.
>
> The LTO bitcode includes inline assembly and constraints so that the
> optimizer knows what to do so it can get optimized just like the abstract
> bitcode during the Link Time Optimization.
>
> This is CpuBreakpoint():
> ; Function Attrs: noinline nounwind optnone ssp uwtable
> define void @CpuBreakpoint() #0 {
> call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2,
> !srcloc !3
> ret void
> }
>
>
> This is AsmReadMsr64():
> ; Function Attrs:
Re: [edk2] Does ARM platform produce MP protocol?
> On Mar 6, 2019, at 5:22 AM, Ard Biesheuvel wrote: > > On Wed, 6 Mar 2019 at 13:41, Achin Gupta <mailto:achin.gu...@arm.com>> wrote: >> >> On Wed, Mar 06, 2019 at 10:37:58AM +0100, Ard Biesheuvel wrote: >>> (adding Achin and Charles) >>> >>> On Wed, 6 Mar 2019 at 10:16, Ni, Ray wrote: >>>> >>>>> -Original Message- >>>>> From: edk2-devel On Behalf Of Ard >>>>> Biesheuvel >>>>> Sent: Wednesday, March 6, 2019 3:38 PM >>>>> To: Ni, Ray >>>>> Cc: edk2-devel@lists.01.org >>>>> Subject: Re: [edk2] Does ARM platform produce MP protocol? >>>>> >>>>> On Wed, 6 Mar 2019 at 06:44, Ni, Ray wrote: >>>>>> >>>>>> Ard, Leif, >>>>>> I am a bit interested in how ARM platform supports the MP? >>>>>> PI Spec defines below protocol but I failed to find a driver in ARM >>>>>> platform >>>>> producing this protocol. >>>>>> Or did I miss anything? >>>>>> >>>>> >>>>> No you are right. We don't expose that on ARM, since UEFI only runs on a >>>>> single core. Bringing up and taking down cores is done via a protocol >>>>> called >>>>> PSCI, which is implemented by firmware running at a higher privilege >>>>> level. >>>>> >>>>> So while it would be possible to implement the MP protocol on top of PSCI, >>>>> we haven't identified a use case for it yet. (The OS calls PSCI directly >>>>> to boot >>>>> the secondary cores) >> >> IIUC, the MP protocol enables communication between processors that are >> already >> up instead of bringing them up or taking them down. So, it is orthogonal to >> PSCI. Is that what you meant? >> > > Surely, StartupThisAP starts up the AP, no? > > In any case, I didn't dig any deeper, but I know that PSCI can be used > (even in the UEFI context) to execute pieces of code on another core > (ACS uses this IIRC) Ard, I take it that the PSCI is replacing the INIT SIPI SIPI mechanism on x86. For PI you need to setup the APs (BSP is running EFI) and the MP protocol gets used for this on boot. Things like setting up SMM, syncing page tables, and MTRR registers. Seems like PSCI kind of replaces this usage on ARM. Since the APs don't run EFI, and it is not safe to call EFI APIs on APIs the usage for running code on the APs is limited. What I've seen is mostly utilities and diagnostics. For example you can write a utility to dump out the MTRR and MSR registers that are per CPU. From a diagnostic point of view it is easier to generate more memory and cache traffic if you have code running on the APs. Note: BSP and AP are terms from the original MP Spec on x86. BSP == Boot Strap Processor (so runs EFI) and AP == Application Processor (all the CPUs not running EFI). Note: The INIT SIPI SIPI is painful to code since the SIPI sends a real mode address for code to run so it involves a lot of complex mode transitions so this is why it makes sense to centralize that code for x86. Thanks, Andrew Fish > >>>> >>>> Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM? >>>> Or will it be implemented by an ARM module? >>> >>> No it is currently not implemented, and I am not aware of any plans to do >>> so. >> >> +1. There is no need to do this until UEFI runs on a single core on Arm. >> > > until -> as long as ?? > >>> >>>> I am asking this because MP_SERVICES protocol exposes CPU location >>>> information >>>> (Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol >>>> doesn't >>>> have a way to expose that information. >>>> If such location information isn't exposed by MM_MP, is that because ARM >>>> doesn't >>>> care about the location information? Or because ARM cares but forgot to >>>> add similar >>>> *GetProcessorInfo* interface to MM_MP when changing the PI spec? >>>> Or ARM doesn't use the MM_MP at all? >> >> Even if Arm used this protocol, it can work with the logical processor >> number. I >> don't see a need to expose the location information to the caller. It seems >> very >> Intel specific. Is the EFI_MP_SERVICES_PROTOCOL used on Arm? >> > > No, that is what started the discussion. > >>>> >>> >>> I don't know the history of this protocol and who p
Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
> On Mar 5, 2019, at 1:32 PM, Gao, Liming wrote:
>
> Andrew:
> BZ 1163 is to remove inline X86 assembly code in C source file. But, this
> patch is wrong. I have gave my comments to update this patch.
>
Why do we want to remove inline X86 assembly. As I mentioned it will lead to
larger binaries, slower binaries, and less optimized code.
For example take this simple inline assembly function:
VOID
EFIAPI
CpuBreakpoint (
VOID
)
{
__asm__ __volatile__ ("int $3");
}
Today with clang LTO turned on calling CpuBreakpoint() looks like this from the
callers point of view.
a.out[0x1fa5] <+6>: cc int3
But if we move that to NASM:
a.out[0x1fa6] <+7>: e8 07 00 00 00 calll 0x1fb2;
CpuBreakpoint
plus:
a.out`CpuBreakpoint:
a.out[0x1fb2] <+0>: cc int3
a.out[0x1fb3] <+1>: c3 retl
And there is also an extra push and pop on the stack. The other issue is the
call to the function that is unknown to the compiler will act like a
_ReadWriteBarrier (Yikes I see _ReadWriteBarrier is deprecated in VC++ 2017).
Is the depreciation of some of these intrinsics in VC++ driving the removal of
inline assembly? For GCC inline assembly works great for local compile, and for
clang LTO it works in entire program optimization.
The LTO bitcode includes inline assembly and constraints so that the optimizer
knows what to do so it can get optimized just like the abstract bitcode during
the Link Time Optimization.
This is CpuBreakpoint():
; Function Attrs: noinline nounwind optnone ssp uwtable
define void @CpuBreakpoint() #0 {
call void asm sideeffect "int $$3", "~{dirflag},~{fpsr},~{flags}"() #2,
!srcloc !3
ret void
}
This is AsmReadMsr64():
; Function Attrs: noinline nounwind optnone ssp uwtable
define i64 @AsmReadMsr64(i32) #0 {
%2 = alloca i32, align 4
%3 = alloca i64, align 8
store i32 %0, i32* %2, align 4
%4 = load i32, i32* %2, align 4
%5 = call i64 asm sideeffect "rdmsr",
"=A,{cx},~{dirflag},~{fpsr},~{flags}"(i32 %4) #2, !srcloc !4
store i64 %5, i64* %3, align 8
%6 = load i64, i64* %3, align 8
ret i64 %6
}
I agree it make sense to remove .S and .asm files and only have .nasm files.
Thanks,
Andrew Fish
PS For the Xcode clang since it emits frame pointers by default we need to add
the extra 4 bytes to save the assembly functions so the stack can get unwound.
a.out`CpuBreakpoint:
a.out[0x1f99] <+0>: 55 pushl %ebp
a.out[0x1f9a] <+1>: 89 e5 movl %esp, %ebp
a.out[0x1f9c] <+3>: cc int3
a.out[0x1f9d] <+4>: 5d popl %ebp
a.out[0x1f9e] <+5>: c3 retl
So breakpoint goes from 1 byte to 11 bytes if we get rid of the intrinsics.
> The change is to reduce the duplicated implementation. It will be good on
> the code maintain. Recently, one patch has to update .c and .nasm both.
> Please see
> https://lists.01.org/pipermail/edk2-devel/2019-February/037165.html
> <https://lists.01.org/pipermail/edk2-devel/2019-February/037165.html>. Beside
> this change, I propose to remove all GAS assembly code for IA32 and X64 arch.
> After those change, the patch owner will collect the impact of the image
> size.
>
> Thanks
> Liming
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] MdePkg/BaseSynchronizationLib: Remove inline X86 assembly code
Shenglei,
I was confused by the names of these patches. From a C point of view this is
inline assembly:
VOID
EFIAPI
CpuBreakpoint (
VOID
)
{
__asm__ __volatile__ ("int $3");
}
These patches seem to be removing GAS and MASM assembly files, but not the
inline assembly *.c files?
We don't want to remove the inline assembly from the BaseLib as that could have
size, performance, and compiler optimization impact.
For example CpuBreakpoint() for clang with LTO would end up inlining a single
byte. For i385 a call to assembler would be 5 bytes at each call location plus
the overhead of the function. So that is a size increase and a performance
overhead. For a C complier calling an assembly function is a serializing event
an that can restrict optimizations. Thus having some limited inline assembly
support is very useful.
Thanks,
Andrew Fish
> On Mar 4, 2019, at 5:40 PM, Shenglei Zhang wrote:
>
> MdePkg BaseSynchronizationLib still uses the inline X86 assembly code
> in C code files.It should be updated to consume nasm only.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1163
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> .../Library/BaseSynchronizationLib/BaseSynchronizationLib.inf | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> index 32414b29fa..719dc1938d 100755
> --- a/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> +++ b/MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> @@ -75,13 +75,11 @@
>
> [Sources.ARM]
> Synchronization.c
> - Arm/Synchronization.asm | RVCT
> Arm/Synchronization.S | GCC
>
> [Sources.AARCH64]
> Synchronization.c
> AArch64/Synchronization.S | GCC
> - AArch64/Synchronization.asm | MSFT
>
> [Packages]
> MdePkg/MdePkg.dec
> --
> 2.18.0.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers.txt: clarify Reviewer requirements and responsibilities
Reviewed-by: Andrew Fish > On Feb 27, 2019, at 5:12 PM, Gao, Liming wrote: > > Reviewed-by: Liming Gao > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Thursday, February 28, 2019 5:22 AM >> To: edk2-devel-01 >> Cc: Gao, Liming ; Kinney, Michael D >> >> Subject: [edk2] [PATCH] Maintainers.txt: clarify Reviewer requirements and >> responsibilities >> >> The current language for "Package Reviewer" only vaguely hints that >> Package Reviewers should be able to provide guidance and directions. >> Make this more obvious. >> >> Cc: Andrew Fish >> Cc: Ard Biesheuvel >> Cc: Leif Lindholm >> Cc: Liming Gao >> Cc: Michael D Kinney >> Cc: Philippe Mathieu-Daude >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Laszlo Ersek >> --- >> >> Notes: >> - this is clearly a political patch; feel free to disagree >> - I'm proposing this for the next development cycle >> >> Maintainers.txt | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/Maintainers.txt b/Maintainers.txt >> index 7772926b2fb1..ed090aeb4bdb 100644 >> --- a/Maintainers.txt >> +++ b/Maintainers.txt >> @@ -20,7 +20,10 @@ Descriptions of section entries: >> M: Package Maintainer: Cc address for patches and questions. Responsible >> for reviewing and pushing package changes to source control. >> R: Package Reviewer: Cc address for patches and questions. Reviewers help >> - maintainers review code, but don't have push access. >> + maintainers review code, but don't have push access. A designated >> Package >> + Reviewer is reasonably familiar with the Package (or some modules >> + thereof), and/or provides testing or regression testing for the Package >> + (or some modules thereof), in certain platforms and environments. >> W: Web-page with status/info >> T: SCM tree type and location. Type is one of: git, svn. >> S: Status, one of the following: >> -- >> 2.19.1.3.g30247aa5d201 >> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] OvmfPkg/Sec: Clear the Cache Disable flag in the CR0 register
> On Feb 18, 2019, at 5:23 AM, Laszlo Ersek wrote: > > generic comment (applies to all NASM usage I guess): > > On 02/18/19 11:10, Jordan Justen wrote: > >> +mov eax, cr0 >> +and eax, ~(1 << 30) >> +mov cr0, eax > >> +mov rax, cr0 >> +and eax, ~(1 << 30) >> +mov cr0, rax > > I've read up on the << and ~ operators in the NASM documentation, and I > think the above build-time calculations of the masks are well-defined > and correct. > > - bit shifts are always unsigned > - given bit position 30, ~(1 << 30) will be a value with 32 bits > - bit-neg simply flips bits (one's complement) > > On the other hand, I find these NASM specifics counter-intuitive. The > expression ~(1 << 30) looks like valid C, but in C, it means a quite > different thing. > > I think calculating the mask with "strict dword" somehow (not exactly > sure how) would make this more readable; or else the BTR instruction would. > > Opinions? (Again, pertaining to all NASM usage in edk2.) > Lazlo, I guess comments, or #defines, are other options? Thanks, Andrew Fish > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Feb 15, 2019, at 11:40 PM, Ni, Ray <mailto:ray...@intel.com>> wrote:
>
> I also met this issue.
> I found three solutions:
> 1. Forcing PeiMain CC flag to "-O0" works.
> 2. Changing EmulatorPkg/Sec to not produce TemporaryRamSupportPpi also works.
> 3. Implement the temporary migration routine as below in EmulatorPkg/Sec
> module.
>
> EFI_STATUS
> EFIAPI
> SecTemporaryRamSupport (
> IN CONST EFI_PEI_SERVICES **PeiServices,
> IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
> IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
> IN UINTNCopySize
> )
> {
> VOID *OldHeap;
> VOID *NewHeap;
> VOID *OldStack;
> VOID *NewStack;
> UINTNStackMigrateOffset;
> BASE_LIBRARY_JUMP_BUFFER JumpBuffer;
>
> DEBUG ((EFI_D_INFO,
>"TemporaryRamMigration(0x%Lx, 0x%Lx, 0x%Lx)\n",
>TemporaryMemoryBase,
>PermanentMemoryBase,
>(UINT64)CopySize
>));
>
> //
> // Assume Host prepare the stack and heap in the temprary ram that stack
> // is below heap (stack is in smaller address).
> // Stack/heap migration depends on the stack/heap location information
> // in the temporary ram.
> //
> OldStack = (VOID*)(UINTN)TemporaryMemoryBase;
> NewStack = (VOID*)((UINTN)PermanentMemoryBase);
>
> OldHeap = (VOID*)((UINTN)TemporaryMemoryBase + (CopySize >> 1));
> NewHeap = (VOID*)((UINTN)PermanentMemoryBase + (CopySize >> 1));
>
> StackMigrateOffset = (UINTN)NewStack - (UINTN)OldStack;
>
> //
> // Migrate Heap and Stack
> //
> CopyMem (NewHeap, OldHeap, CopySize >> 1);
> CopyMem (NewStack, OldStack, CopySize >> 1);
>
> //
> // Use SetJump()/LongJump() to switch to a new stack.
> //
> if (SetJump () == 0) {
> #if defined (MDE_CPU_IA32)
>JumpBuffer.Esp = JumpBuffer.Esp + StackMigrateOffset;
>JumpBuffer.Ebp = JumpBuffer.Ebp + StackMigrateOffset;
> #endif
> #if defined (MDE_CPU_X64)
>JumpBuffer.Rsp = JumpBuffer.Rsp + StackMigrateOffset;
>JumpBuffer.Rbp = JumpBuffer.Rbp + StackMigrateOffset;
> #endif
>LongJump (, (UINTN)-1);
> }
>
> ZeroMem ((VOID *)(UINTN) TemporaryMemoryBase, CopySize);
>
> return EFI_SUCCESS;
> }
>
>
> Andrew,
> I'd like to know why you chose to produce the migration PPI from
> EmulatorPkg/Sec module.
> Based on PI spec and current PeiCore implementation, PeiCore can do the
> migration when PPI is absent.
>
Ray,
Sorry I don't remember if it was due to the code being so old, or if I was
trying to better emulate a real platform.
Thanks,
Andrew Fish
>
>
> --
> Thanks,
> Ray
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
> <https://lists.01.org/mailman/listinfo/edk2-devel>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] Community Meeting Minutes
> On Feb 8, 2019, at 9:33 AM, Rebecca Cran via edk2-devel > wrote: > > > On February 8, 2019 at 2:01:59 AM, Laszlo Ersek > (ler...@redhat.com(mailto:ler...@redhat.com)) wrote: > >> I don't see the workflow modification as viable. The "patch series" >> concept is integral to every single open source project that I've ever >> worked with. The evolution of a feature or a bug fix over a series of >> patches is a core facet of programming and reviewing. It communicates a >> thinking process, and that's what programming is about. > > I don’t recall coming across the patch series (e.g. the 1/5 email patches) in > other projects. In other projects people post a single patch and then update > it following feedback on the same review. This can be either in a single, > rebased commit, or new commits on a bug/feature branch - review systems deal > with both. > Rebecca, I think the patch workflow is kind of like a coding standards. Some folks advocate for lots of small patches (common in open source projects), and some folks advocate for a patch per bug. I think the biggest upside to the patch granularity is it is much easier to bisect a failure. So I've used Bitbucket with a branch per commit (you name your branch with a standard pattern and the bugzilla ) model and if your branch has a patch series (set of commits) you can view each commit independently from the UI and the default view is the entire patch series. So you can see both. Thanks, Andrew Fish >> So how long do we wait? >> > > > Good point! > >> >> >> What I find practical at this moment is what Stephano has been working >> on (thank you for all that Stephano) -- collect & file official >> improvement requests with GitHub, and then see how those things are >> addressed. In my opinion (not having seen Gerrit anyway, which remains >> to be evaluated, but not by me), GitHub is the direct runner up to the >> mailing list, so improving GitHub would be the most practical. In >> particular I envision the context improvements for the GitHub email >> notifications as something very doable for GitHub. > > > > > > I’d certainly be happy to use Github, but I do worry about tieing ourselves > to such a closed system. > > > > > > > Rebecca > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Hello Andrew query on BdsSetMemoryTypeInformationVariable
Forwarding to the edk2 list > On Feb 8, 2019, at 8:28 AM, galla rao wrote: > > Hi Andrew, > > Am sorry for direct message! > > There is a function BdsSetMemoryTypeInformationVariable which causes a reset > when i enabled Secureboot related drivers > > Any clue why this function is added in EDK2? > Yea it writes a variable that records how many pages of each memory type are used. This variable is read in PEI and used to pass a HOB into the DXE Core. The DXE Core uses these memory buckets to preallocate ranges for each memory type. This scheme prevents memory fragmentation and makes sure the runtime memory regions are in the same location when the system does an S4 resume from disk. > is this a serious error, making the PcdResetOnMemoryTypeInformationChange to > FALSE will resolve and boots to OS > I think the idea behind that reboot, is the memory map could be different on the next boot and if that was an S4 the S4 could fail. Thanks, Andrew Fish > shed some knowledge if you are aware of this feature > > Thanks & Regards > Galla ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Self-replicating image
> On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar) > wrote: > > Hi, > > I am currently pondering the most elegant way to implement capsule update for > our devices that would work in the presence of multiple devices in the host. > > Capsule allows embedding a driver that is executed prior to the update, which > is very handy. Crypto library is quite large and would not fit into an > OptionROM, so being able to supply FMP driver in the capsule is great. > > However, if only one instance of the driver loads, the FMP upstream is > currently written to support only one device per instance. So I wonder if > there is a easy, neat way for my image to replicate on DriverBinding so that > I end up with one instance per device. > Tom, The usually model in EFI is to have one driver handle multiple things. > It looks like I should be able to do it with gBS->LoadImage() and passing > information about currently loaded image though I might have to CopyMem() the > image itself to new location. > gBS->LoadImage() will load and relocate the image to a malloced address of the correct memory type for the image. The inputs are just the source of the image, so no need to CopyMem() anything. gBS->StartImage() calls the entry point. Thanks, Andrew Fish > Thoughts? > > Cheers, > Tom > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver
> On Jan 31, 2019, at 11:57 AM, Leif Lindholm wrote: > > +Andrew, Laszlo, Mike. > > On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote: >> On Thu, 31 Jan 2019 at 16:24, Leif Lindholm wrote: >>> >>> On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote: >>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>> Signed-off-by: Pete Batard >>>> >>>> Reviewed-by: Ard Biesheuvel >>>> --- >>>> Silicon/Broadcom/Bcm283x/Bcm283x.dec | 23 ++ >>>> Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c | 367 >>>> >>>> Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf | 48 +++ >>>> Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h| 72 >>> >>> Another generic comment: "IndustryStandard" is something like ACPI, >>> SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific >>> additions to the same). >> >> Is that your interpretation? Or is this documented somewhere? > > Only in asmuch as it is a clearly descriptive name. > >> I could live with Chipset/, and I'm open to other suggestions, but the >> Library vs Protocol vs IndustryStandard distinction is very useful >> imo. > > It is useful because it is descriptive. > Pretending that an SoC hardware description or a platform description > header is an "Industry Standard" is disingenuous. > >>> I would be more comfortable with SoC-specific and Platform-specific >>> include files living directly in Include/. >> >> No, don't drop headers in Include/ please. The namespacing is one of >> the things EDK2 actually gets right (assuming you define the paths >> correctly in the package .dec file), and I'd hate to start dumping >> headers at the root level because we cannot make up our minds what to >> call the enclosing folder. > > Mike, Andrew - what is your take on this? > Is there a formal definition of not only what goes in > IndustryStandard, but where chipset and platform headers should live > in the namespace? > Leif, I kind of think IndustryStandard as things that have a public spec I don't know if we have a pedantic definition of what that means. I'm with Ard on that I like the current Include structure for the generic packages and global definitions. What seems to work poorly in our packaging scheme is the intersection of platforms and chipsets. Everything works OK is you just use PCDs, but if you try to use includes it get complicated. I guess that Library instances can help here too. An IP block for an SoC could be another example, do we need a package for each IP block? Thus any SoC that uses that IP block can depend on that package? If you don't do that you end up copies of that IP block definition in every SoC package. In a more traditional C world grabbing includes is just a matter of adding an include search path to the build, but in the edk2 it is about having the proper package definitions, and the set of packages are somewhat fixed in the INF files. But I guess after all this rambling I'm really saying it is hard to figure out what package to put a given include in. I'm not sure that impacts pathing in a single package? I think the scope of the package matters too as if you have a package to support a chipset (SoC) do you really need Include/Chipset or Include/Soc? As long as you have the Guid, Library, Ppi, Protocol, and IndustryStandard the package can dump everything in /Include or build some directory hierarchy that makes sense. But then again punting on what this hierarchy seems to not answer your question. I guess if the package has lots of functionality adding Include directory structure makes sense, if it is a smaller focused package it seems like having an extra directory for the main focus of the package could be redundant. Thanks, Andrew Fish > Regards, > > Leif > >>>> 4 files changed, 510 insertions(+) >>>> >>>> diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec >>>> b/Silicon/Broadcom/Bcm283x/Bcm283x.dec >>>> new file mode 100644 >>>> index ..d193da4c0e1e >>>> --- /dev/null >>>> +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec >>>> @@ -0,0 +1,23 @@ >>>> +## @file >>>> +# >>>> +# Copyright (c) 2019, Pete Batard >>>> +# >>>> +# This program and the accompanying materials are licensed and made >>>> available >>>> +# under the terms and conditions of the BSD License which accompanies >>>> this >>>>
Re: [edk2] [RFC] Proposal to split Pkgs
> On Jan 28, 2019, at 9:59 PM, Ni, Ray wrote: > > Hello, > I'd like to propose to split today's BIG packages in following ways: > > ==Overview = > > 1. Separate Industry standard definitions from UEFI and PI interfaces. Ray, >From a big picture point of view lets talk about customer impact Splitting the MdePkg means: 1) Every INF file needs a new [Packages] layout, so has to change. 2) Every DSC file needs to update [LibraryClasses] pathing. Moving the drivers around: 1) Every DSC file has to change to update the path to the driver 2) Every FDF file has to change to update the path to the driver. I'd point out forcing every 3rd party module (library, driver, or application) to change is a much bigger impact that forcing a change to a projects target platform (DSC, FDF). I'm trying to figure out how to make a common code base that spans several generations of vendor code. So obviously today every module depends of MdePkg, and each new product is going to require new drivers for the chipset and peripherals. So lets say I'm a 3rd party graphics vendor does this mean I need and edk2 version of an INF and an edk3 version (no more MdePkg) of the INF as my customers are going to move at different rates? On the flip side how do I make a common platform tree if my vendor for work station chipsets lags behind my other chipset vendor in regards to moving to edk3. Does that mean I have to port that vendors code to edk3, which does not sound bad until you realize that every code drop from the vendor I need to remerge my edk3 changes back on top of it. Seems like a lot of work. Thus I think we need to ask the question do we need to leave the MdePkg around for compatibility? Do we need an INF syntax that supports edk2 and edk3 (Like the #ifdef we had that supported EDK and edk2 includes back in the day). We could have edk2 and edk3 INF files for very module? Do we need to build a synthetic MdePkg that gets you the correct packages paths for the new include layout? I guess we could just make MdePkg an alias in the INF file for the 3 (?) new packages? Or do we not change all the include paths? Seems like we are creating our own Python 2.* vs. 3.* mess to make it easier to maintain the packages? I'm not saying it is wrong, but we should ask the question how is going to impact the edk2 consumers. Thanks, Andrew Fish > 2. Separate UEFI and PI interfaces from implementations. >a. Separate UEFI and PI interfaces to different packages >b. Separate PI PEI, DXE and MM phase interfaces to different packages > 3. Separate different features into feature packages. >Feature interface may be in the feature package to provide minimal >common interface packages. > > The POC code is in https://github.com/jyao1/edk2/tree/ReOrg. > It basically split the EDKII common code to three directories: > Core/, Device/, and Feature/. > The code is in very early POC phase and only code in Core/ directory > can pass the build. > I would like to gather feedbacks through this RFC to see whether > this splitting direction makes sense. > Is there any other better ways of splitting? > Or perhaps do not split in such a small granularity? > Or perhaps Mike's work to move lib-c content to edk2-libc repo, > to move real platform code to edk2-platform repo is enough for > now? > > ==More explanations = > > There are 9 packages inside Core/ directory: > 1. BasePkg > Contains industry standard definitions (exclude UEFI and PI) and base > libraries that non-UEFI and non-PI development can depend on. > UEFI or PI development can also depend on this package. > 2. UefiPkg > Contains UEFI interfaces and libraries that UEFI driver-model driver > development can depend on. > 3. PiPeiPkg > Contains PI interfaces and libraries for PEI phase that PEI module > development can depend on. > 4. PiDxePkg > Contains PI interfaces and libraries for DXE phase that DXE module > development can depend on. > 5. PiMmPkg > Contains PI interfaces and libraries for MM phase that MM/SMM > module development can depend on. > 6. MdeModulePkg (TianoPkg? Name is still TBD) > Contains Tiano implementation specific interfaces and libraries. > Developing modules for pure UEFI or PI should not depend on this package. > 7. PeiFoundationPkg > Contains the PEI foundation modules (PeiCore and DxeIpl) and supported > libraries. > 8. DxeFoundationPkg > Contains the DXE foundation modules (DxeCore and RuntimeDxe) and > supported libraries. > 9. SmmFoundationPkg > Contains the SMM foundation modules (SmmCore, SmmIpl and > SmmCommunicationBuffer) and supported libraries. > > These packages are positioned in different layers. The package in higher > layer depends on all packages that ar
Re: [edk2] [PATCH edk2-staging 10/20] IntelUndiPkg/XGigUndiDxe: drop StdLibC library class reference
> On Jan 30, 2019, at 9:26 AM, Ryszard Knop > wrote: > > That's actually not quite correct - we need this package to build on > IA32. It's named rather unfortunately, since it's not the EDK2 StdLibC, > but rather a package in this repository - see IntelUndiPkg/LibC. It > contains the bare minimum of functionality required to fix missing 64- > bit math/shifts on IA32 and missing memcpy/memset intrinsics. We can't > prevent MSVC from yielding memcpy/memset either, so this was the nasty > solution for build issues. You have included CompilerIntrinsicsLib for > the same reason, too :) > Ryszard, For IA32/X64 we avoid the compiler intrinsic libs via the coding standard. 1) If you don't assign something too large at execution time with an = the compiler will not inline memcpy()/memset() 2) BaseLib.h has all the math functions that generate intrinsics that your code can call explicitly: https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/BaseLib.h#L3533 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/BaseLib.h#L3533> UINT64 X=0x1; UINT64 Y=2; So: Y = X*Y; should be: Y = MultU64x64 (X, Y); When ARM got added much later and some versions of ARM did not even have a divide instruction we gave up on trying to add more functions into all the existing IA32 code, and add the intrinsic lib. If we are going to add an intrinsic lib for x86 then we should probably add it to the MdePkg and it needs to support MSVC and GCC (as far as I can tell clang should work with the GCC intrinsics). Thanks, Andrew Fish > I'm not aware of any X64/IA32 equivalent of your CompilerIntrinsicsLib, > but I'd be happy to be proven wrong here. I'm off for the rest of the > week - I'll continue with reviews and merging early next week. > > Thanks, Richard. > > On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote: >> StdLibc should not be used in drivers (it has dependencies on Shell >> protocols), but in fact, we don't appear to rely on it in the first >> place, so just drop the reference. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ard Biesheuvel >> --- >> IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf >> b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf >> index beee8aa8134e..b5747565fbea 100644 >> --- a/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf >> +++ b/IntelUndiPkg/XGigUndiDxe/XGigUndiDxe.inf >> @@ -132,7 +132,6 @@ GCC:*_*_*_CC_FLAGS = -DEFI32 >> PrintLib >> UefiLib >> HiiLib >> - StdLibC >> >> [LibraryClasses.X64] >> > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 07/20] IntelUndiPkg/XGigUndiDxe: drop definition of gImageHandle
> On Jan 30, 2019, at 8:05 AM, Ryszard Knop
> wrote:
>
> Hmm, is there a list/something I can generate to see which globals
> build tools emit? There are some more variables I'd happily get rid
> of, eg if I could drop gSystemTable and others.
>
Ryszard,
You need to use libs by including the include file, and listing the lib in the
INF. The library constructor initializes the globals.
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DxeServicesTableLib.h
<https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/DxeServicesTableLib.h>
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/UefiBootServicesTableLib.h
<https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/UefiBootServicesTableLib.h>
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/UefiRuntimeServicesTableLib.h
For edk2 the library constructors get called prior calling your drivers entry
point.
Thanks,
Andrew Fish
> Reviewed-by: Ryszard Knop
>
> On Wed, 2018-11-14 at 18:33 -0800, ard.biesheuvela wrote:
>> Remove duplicate definition of gImageHandle, which is emitted by
>> the build tools as well.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel
>> ---
>> IntelUndiPkg/XGigUndiDxe/Init.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/IntelUndiPkg/XGigUndiDxe/Init.c
>> b/IntelUndiPkg/XGigUndiDxe/Init.c
>> index 84e06ea071c5..03e3942a1944 100644
>> --- a/IntelUndiPkg/XGigUndiDxe/Init.c
>> +++ b/IntelUndiPkg/XGigUndiDxe/Init.c
>> @@ -47,7 +47,6 @@ UINT16 mActiveChildren= 0;
>> EFI_EVENT gEventNotifyExitBs;
>> EFI_EVENT gEventNotifyVirtual;
>>
>> -EFI_HANDLEgImageHandle;
>> EFI_SYSTEM_TABLE *gSystemTable;
>>
>> EFI_GUID gEfiNiiPointerGuid = EFI_NII_POINTER_PROTOCOL_GUID;
>> @@ -502,7 +501,6 @@ InitializeXGigUndiDriver (
>> {
>> EFI_STATUS Status;
>>
>> - gImageHandle = ImageHandle;
>> gSystemTable = SystemTable;
>>
>> Status = EfiLibInstallDriverBinding (ImageHandle, SystemTable,
>> , ImageHandle);
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
Krishna,
From an EFI point of view BackSpace 0x08, LF 0x0A, and CR 0xD are defined for a
ConOut device.
From Ascii Control Codes:
0x0C - Form Feed
0x0E - Shift Out
The Shift Out is used with graphics characters.
How did you dump the log? If EFI sends data to a serial terminal then it would
use terminal emulation and the output stream would look different.
Thanks,
Andrew Fish
> On Jan 23, 2019, at 11:07 PM, krishnaLee wrote:
>
> Andrew Fish,
> thank you,in this case,you are right.
> but I think there may be other case that the user data just contain some
> nosense-data
> such as { UINT16 MyData[]={0x000c,0x000d,0x000d,0x000e} } to the editor,
> the uefi editor may also meet this question,the editor may do not need output
> this,
> but the editor should make sure other visible chars can output normal...
>
> I don't know if it is a bug or not.
>
> Thank you very much.
> krishna.
>
>
>
>
> 在 2019-01-24 12:13:50，"Andrew Fish" 写道：
>> On Jan 23, 2019, at 7:17 PM, krishnaLee > <mailto:sssky...@163.com>> wrote:
>>
>> Hi,
>> I dumped a small log.txt from my work,but the log.txt showed in uefi
>> shell,is not the same as it showed in notepad++.
>> I had upload the log here:
>> https://github.com/krishna116/test/blob/master/log.zip
>> <https://github.com/krishna116/test/blob/master/log.zip>
>>
>>
>> it seems the log showed in uefi shell had missed some strings...I don't know
>> why,please help,
>>
>
> Krishna,
>
> Your log.txt looks like a normal UTF-16 Unicode file. The leading FF FE is
> the Byte order mark for UTF-16 Little Endian [1]. The file looks like it has
> CR line endings [2] so maybe that is confusing your editor? There seems to be
> a CR LF at the end, so the mixture of line ending may even be more likely
> confusing the editor. The byte order mark should let your editor know it is
> 16-bit Unicode and the correct endian. Hope this helps...
>
> $ hexdump -C /Users/andrewfish/Downloads/log/log.txt
> ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.|
> 0010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .|
> 0020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.|
> 0030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .|
> 0040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .|
> 0050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .|
> 0060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.|
> 0070 62 00 29 00 20 00 20 00 20 00 20 00 20 00 20 00 |b.). . . . . . .|
> 0080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 00c0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . . . .|
> 00d0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 0190 20 00 20 00 0d 00 0d 00 20 00 20 00 20 00 20 00 | . . . . . .|
> 01a0 4d 00 58 00 32 00 35 00 4c 00 36 00 34 00 37 00 |M.X.2.5.L.6.4.7.|
> 01b0 33 00 45 00 20 00 20 00 20 00 20 00 49 00 44 00 |3.E. . . . .I.D.|
> 01c0 3a 00 30 00 78 00 43 00 32 00 32 00 30 00 31 00 |:.0.x.C.2.2.0.1.|
> 01d0 37 00 20 00 20 00 20 00 20 00 53 00 69 00 7a 00 |7. . . . .S.i.z.|
> 01e0 65 00 3a 00 20 00 38 00 31 00 39 00 32 00 4b 00 |e.:. .8.1.9.2.K.|
> 01f0 42 00 20 00 28 00 36 00 35 00 35 00 33 00 36 00 |B. .(.6.5.5.3.6.|
> 0200 4b 00 62 00 29 00 20 00 20 00 20 00 20 00 20 00 |K.b.). . . . . .|
> 0210 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 0260 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . .|
> 0270 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 0320 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .|
> 0330 53 00 50 00 49 00 20 00 42 00 41 00 52 00 3a 00 |S.P.I. .B.A.R.:.|
> 0340 20 00 46 00 45 00 30 00 31 00 30 00 30 00 30 00 | .F.E.0.1.0.0.0.|
> 0350 30 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 |0. . . . . . . .|
> 0360 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 03f0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . . . .|
> 0400 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .|
> *
> 04c0 20 00 20 00 0d 00 0d 00 46 00 50 00 54 00 20 00 | . .F.P.T. .|
> 04d0 4f 00 70 00 65 00 72 00 61 00 74 00 69 00 6f 00 |O.p.e.r.a.t.i.o.|
> 04e0 6e 00 20 00 53 00 75 00 63 00 63 00 65 00 73 00 |n. .S.u.c.c.e.s.|
> 04f0 73 00 66 00 75 00 6c 00 2e 00 20 00 20 00 20 00 |s.f.u.l... .
Re: [edk2] [question] A piece of log.txt showed in uefi shell is not the same as showed in notepad++
> On Jan 23, 2019, at 7:17 PM, krishnaLee wrote: > > Hi, > I dumped a small log.txt from my work,but the log.txt showed in uefi shell,is > not the same as it showed in notepad++. > I had upload the log here: > https://github.com/krishna116/test/blob/master/log.zip > > > it seems the log showed in uefi shell had missed some strings...I don't know > why,please help, > Krishna, Your log.txt looks like a normal UTF-16 Unicode file. The leading FF FE is the Byte order mark for UTF-16 Little Endian [1]. The file looks like it has CR line endings [2] so maybe that is confusing your editor? There seems to be a CR LF at the end, so the mixture of line ending may even be more likely confusing the editor. The byte order mark should let your editor know it is 16-bit Unicode and the correct endian. Hope this helps... $ hexdump -C /Users/andrewfish/Downloads/log/log.txt ff fe 20 00 20 00 20 00 4d 00 58 00 32 00 35 00 |.. . . .M.X.2.5.| 0010 4c 00 31 00 32 00 38 00 37 00 35 00 46 00 20 00 |L.1.2.8.7.5.F. .| 0020 20 00 20 00 20 00 49 00 44 00 3a 00 30 00 78 00 | . . .I.D.:.0.x.| 0030 43 00 32 00 32 00 30 00 31 00 38 00 20 00 20 00 |C.2.2.0.1.8. . .| 0040 20 00 20 00 53 00 69 00 7a 00 65 00 3a 00 20 00 | . .S.i.z.e.:. .| 0050 31 00 36 00 33 00 38 00 34 00 4b 00 42 00 20 00 |1.6.3.8.4.K.B. .| 0060 28 00 31 00 33 00 31 00 30 00 37 00 32 00 4b 00 |(.1.3.1.0.7.2.K.| 0070 62 00 29 00 20 00 20 00 20 00 20 00 20 00 20 00 |b.). . . . . . .| 0080 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 00c0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . . . .| 00d0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 0190 20 00 20 00 0d 00 0d 00 20 00 20 00 20 00 20 00 | . . . . . .| 01a0 4d 00 58 00 32 00 35 00 4c 00 36 00 34 00 37 00 |M.X.2.5.L.6.4.7.| 01b0 33 00 45 00 20 00 20 00 20 00 20 00 49 00 44 00 |3.E. . . . .I.D.| 01c0 3a 00 30 00 78 00 43 00 32 00 32 00 30 00 31 00 |:.0.x.C.2.2.0.1.| 01d0 37 00 20 00 20 00 20 00 20 00 53 00 69 00 7a 00 |7. . . . .S.i.z.| 01e0 65 00 3a 00 20 00 38 00 31 00 39 00 32 00 4b 00 |e.:. .8.1.9.2.K.| 01f0 42 00 20 00 28 00 36 00 35 00 35 00 33 00 36 00 |B. .(.6.5.5.3.6.| 0200 4b 00 62 00 29 00 20 00 20 00 20 00 20 00 20 00 |K.b.). . . . . .| 0210 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 0260 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . .| 0270 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 0320 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .| 0330 53 00 50 00 49 00 20 00 42 00 41 00 52 00 3a 00 |S.P.I. .B.A.R.:.| 0340 20 00 46 00 45 00 30 00 31 00 30 00 30 00 30 00 | .F.E.0.1.0.0.0.| 0350 30 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 |0. . . . . . . .| 0360 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 03f0 20 00 20 00 20 00 20 00 0d 00 0d 00 20 00 20 00 | . . . . . .| 0400 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 04c0 20 00 20 00 0d 00 0d 00 46 00 50 00 54 00 20 00 | . .F.P.T. .| 04d0 4f 00 70 00 65 00 72 00 61 00 74 00 69 00 6f 00 |O.p.e.r.a.t.i.o.| 04e0 6e 00 20 00 53 00 75 00 63 00 63 00 65 00 73 00 |n. .S.u.c.c.e.s.| 04f0 73 00 66 00 75 00 6c 00 2e 00 20 00 20 00 20 00 |s.f.u.l... . . .| 0500 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 0590 0d 00 0d 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . .| 05a0 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 | . . . . . . . .| * 0650 20 00 20 00 20 00 20 00 20 00 20 00 0d 00 0d 00 | . . . . . .| 0660 0d 00 0a 00 || 0664 [1] https://en.wikipedia.org/wiki/Byte_order_mark#UTF-16 [2] https://en.wikipedia.org/wiki/Newline Thanks, Andrew Fish > > thank you, > by krishna. > > > > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Network Stack Budgeting
> On Jan 23, 2019, at 8:27 AM, Tomas Pilar (tpilar) > wrote: > > >> The set of devices connected during BDS is platform policy. It is not >> the "network stack" that calls Snp.Start(), but the platform BDS code >> that calls gBS->ConnectController() on the device, possibly without a >> good reason (e.g. without the device being present in a UEFI boot >> option). The network stack only "reacts" to that connection request. > Indeed, but even if a SNP handle is present as a boot option in a boot > manager, surely the Snp.Start() should be deferred until the user actually > chooses to boot from that handle. > Tom, You don't need to call gBS->ConnectController() on all possible boot options, just the one you are currently trying to boot. I mostly muck around in a non edk2 BDS, but in general what you do in a BDS is: 1) Connect your graphics console(s) (usually involves ConOut NVRAM) 3) Connect any serial consoles (ConIn/ConOut NVRAM). 2) Connect any built in keyboard, maybe SPI etc. (ConIn NVRAM). 4) Connect any hot pluggable console devices (Connect any existing USB HID devices). 5) Connect any other device required in the boot path (like the example entropy device. The platform can have policy to force values into ConIn/ConOut. For example on a laptop maybe you always want the built in keyboard active. As you attempt to boot a boot option you can recursively connect the device path for that boot option and attempt to boot it. If that option fails you can fall back to the next boot option and try to connect that device path and boot. Thus you don't need to start things before you are ready. If you launch Firmware Setup that usually does a Connect All. The same things happen when you launch the Shell. Also some drivers connect extra stuff. For example when you try to connect a specific PCI device all the PCI IO handles get created. This is just how you have to enumerate PCI. But the recursive connect should only happen on the PCI IO handle you care about. Thanks, Andrew Fish > A workaround that we have in the legacy implementation doesn't start the > underlying hardware datapath until the platform tries to send the first > packet (since PXE boot is always initiated by the client) but that is a > horrible hack that should not be necessary. The distinction between > Snp.Initialize() and Snp.Start() is there exactly for that reason, no? > > In other words, ConnectController() should not immediately result in > Snp.Start() being called. > > Cheers, > Tom > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Drop CSM support in OvmfPkg?
> On Jan 22, 2019, at 7:43 PM, Ni, Ray wrote: > >> -Original Message- >> From: David Woodhouse mailto:dw...@infradead.org>> >> Sent: Wednesday, January 23, 2019 12:23 AM >> To: Ni, Ray mailto:ray...@intel.com>>; Gerd Hoffmann >> mailto:kra...@redhat.com>>; >> Laszlo Ersek mailto:ler...@redhat.com>>; Richardson, >> Brian >> mailto:brian.richard...@intel.com>> >> Cc: Justen, Jordan L > <mailto:jordan.l.jus...@intel.com>>; edk2-devel@lists.01.org >> <mailto:edk2-devel@lists.01.org>; >> Kevin O'Connor mailto:ke...@koconnor.net>>; Anthony >> Perard >> mailto:anthony.per...@citrix.com>> >> Subject: Re: Drop CSM support in OvmfPkg? >> >> On Tue, 2019-01-22 at 16:13 +, Ni, Ray wrote: >>> David, >>> I'd like to re-start the discussion. >>> Could you please kindly explain the background/reason of adding CSM >>> support in OVMF? >>> Maybe knowing the reason can help to make further decisions of >>> whether to >>> A. keep it outside OvmfPkg >>> B. keep it inside OvmfPkg >>> C. maybe have a chance to just remove the CSM support after >>> revisiting >> >> >> The idea was to make it simple to have a single firmware image for >> virtual machines which would support both UEFI and Legacy boot for >> guests simultaneously. >> >> In libvirt there has been an alternative approach, where the BIOS image >> is switched between OVMF and SeaBIOS according to the configuration of >> the guest VM. >> >> That's fine for libvirt, but in situations where VM hosting is provided >> as a service, it becomes quite painful to manage the 'UEFI' vs. >> 'Legacy' flags on guest images and then switch firmware images >> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much >> preferable. > > David, > Thanks for sharing. I now understand that you do have a need of > CSM + UEFI OVMF image. > A very straightforward idea is to move all COM components you needed > into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this. > So maybe you could set up another (github) repo and clone all the CSM > components > there. > EDKII build tool supports to build firmware from multiple repos. > That's how we can have edk2-platforms and to-be-created edk2-app. > In practical, you could create a new csm repo. > Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 repo. > You can build the OVMF image from edk2 and csm repo. > Ray, I kind or agree at this point CSM is really more interesting for virtual machines vs. real platforms. I guess the interesting question to ask is do we want to start making it more part of the virtual machines that happen to be checked into TianoCore, or should we keep it more generic? The thinking being the CSM is likely upstreamed in other more commercial VMs? Can we just add a readme to the current CSM package and explain it mostly exists to support VMs? Thanks, Andrew Fish > We can have a call if you are ok. I can explain how that can work in details. > > Thanks, > Ray > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
> On Jan 22, 2019, at 9:49 AM, Kinney, Michael D
> wrote:
>
> Andrew,
>
> If we move all of those, then what are the code review rules for a lib of
> type BASE?
>
> Is there a preference to use the current BASE types? Under what conditions
> are EFI type names allowed?
>
> Is the a preference to stop using the current BASE types all together?
>
Mike,
it seems messy to add types to Base.h to support Base Libs. So for example
IPv4_ADDRESS and IPv6_ADDRESS got sucked into Base.h since an MdePkg Base Lib
got added that used it. That does not really seem to scale to Base Libs in
other packages. Thus I guess the preference would be to use the common EFI_*
names. I'd not advocate removing the old names as that is going to break other
folks Base LIbs. We could do the cleanup in TianoCore. If we want to deprecate
the old names form, I guess that could be an ifdef to allow some depreciation
in the future?
Thanks,
Andrew Fish
> Thanks,
>
> Mike
>
>> -Original Message-
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Friday, January 18, 2019 9:24 AM
>> To: Felix Poludov
>> Cc: Kinney, Michael D ;
>> edk2-devel@lists.01.org
>> Subject: Re: [edk2] History question about Base.h and
>> its alternate parallel name space Should we change
>> it?
>>
>>
>>
>>> On Jan 18, 2019, at 9:08 AM, Felix Polyudov
>> wrote:
>>>
>>> Mike,
>>>
>>> I think EFI_GUID and EFI_STATUS should cover most of
>> the use cases.
>>>
>>
>> I think I missed a couple in my original mail
>>
>> But here are the typedef and #define names that get
>> remapped (or redone) in
>> MdePkg/Include/Uefi/UefiBaseType.h
>>
>> typedef struct {
>> UINT32 Data1;
>> UINT16 Data2;
>> UINT16 Data3;
>> UINT8 Data4[8];
>> } GUID;
>>
>> typedef struct {
>> UINT8 Addr[4];
>> } IPv4_ADDRESS;
>>
>> typedef struct {
>> UINT8 Addr[16];
>> } IPv6_ADDRESS;
>>
>> typedef UINT64 PHYSICAL_ADDRESS;
>> typedef UINTN RETURN_STATUS;
>>
>> #define ENCODE_ERROR(StatusCode)
>> ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
>> #define ENCODE_WARNING(StatusCode)
>> ((RETURN_STATUS)(StatusCode))
>> #define RETURN_ERROR(StatusCode)
>> (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
>> #define RETURN_SUCCESS 0
>> #define RETURN_LOAD_ERRORENCODE_ERROR (1)
>> #define RETURN_INVALID_PARAMETER ENCODE_ERROR (2)
>>
>>
>>
>> I think the cleanup would be as simple as moving things
>> from MdePkg/Include/Uefi/UefiBaseType.h to
>> MdePkg/Include/Base.h.
>>
>> So:
>>
>> typedef struct {
>> UINT32 Data1;
>> UINT16 Data2;
>> UINT16 Data3;
>> UINT8 Data4[8];
>> } GUID;
>>
>> Becomes:
>>
>> typedef struct {
>> UINT32 Data1;
>> UINT16 Data2;
>> UINT16 Data3;
>> UINT8 Data4[8];
>> } GUID, EFI_GUID;
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>>> -Original Message-
>>> From: Kinney, Michael D
>> [mailto:michael.d.kin...@intel.com]
>>> Sent: Thursday, January 17, 2019 3:04 PM
>>> To: Felix Polyudov; 'Andrew Fish'; Kinney, Michael D
>>> Cc: edk2-devel@lists.01.org
>>> Subject: RE: [edk2] History question about Base.h and
>> its alternate parallel name space Should we change
>> it?
>>>
>>> Felix,
>>>
>>> Is there a specific set that would have the most
>> benefit?
>>>
>>> Is EFI_GUID sufficient?
>>>
>>> Mike
>>>
>>>> -Original Message-
>>>> From: Felix Polyudov [mailto:fel...@ami.com]
>>>> Sent: Wednesday, January 16, 2019 3:10 PM
>>>> To: 'Andrew Fish' ; Kinney, Michael
>> D
>>>>
>>>> Cc: edk2-devel@lists.01.org
>>>> Subject: RE: [edk2] History question about Base.h and
>>>> its alternate parallel name space Should we
>> change
>>>> it?
>>>>
>>>> I agree with Andrew.
>>>> In my opinion, moving alias types to Base.h will help
>> to
>>>> overcome certain practical inconveniences without
>>>> a significant impact on the ability to detect poorly
>>>> written Base libraries.
>>>>
>>>> -Original Message-
>>>> From: edk2-devel [mailto:edk2-devel-
>>>> boun...@lists.01.org] On Behalf Of A
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
> On Jan 18, 2019, at 9:08 AM, Felix Polyudov wrote:
>
> Mike,
>
> I think EFI_GUID and EFI_STATUS should cover most of the use cases.
>
I think I missed a couple in my original mail
But here are the typedef and #define names that get remapped (or redone) in
MdePkg/Include/Uefi/UefiBaseType.h
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
typedef struct {
UINT8 Addr[4];
} IPv4_ADDRESS;
typedef struct {
UINT8 Addr[16];
} IPv6_ADDRESS;
typedef UINT64 PHYSICAL_ADDRESS;
typedef UINTN RETURN_STATUS;
#define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT | (StatusCode)))
#define ENCODE_WARNING(StatusCode) ((RETURN_STATUS)(StatusCode))
#define RETURN_ERROR(StatusCode) (((INTN)(RETURN_STATUS)(StatusCode)) < 0)
#define RETURN_SUCCESS 0
#define RETURN_LOAD_ERRORENCODE_ERROR (1)
#define RETURN_INVALID_PARAMETER ENCODE_ERROR (2)
I think the cleanup would be as simple as moving things from
MdePkg/Include/Uefi/UefiBaseType.h to MdePkg/Include/Base.h.
So:
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
Becomes:
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID, EFI_GUID;
Thanks,
Andrew Fish
> -Original Message-
> From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
> Sent: Thursday, January 17, 2019 3:04 PM
> To: Felix Polyudov; 'Andrew Fish'; Kinney, Michael D
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] History question about Base.h and its alternate parallel
> name space Should we change it?
>
> Felix,
>
> Is there a specific set that would have the most benefit?
>
> Is EFI_GUID sufficient?
>
> Mike
>
>> -Original Message-
>> From: Felix Polyudov [mailto:fel...@ami.com]
>> Sent: Wednesday, January 16, 2019 3:10 PM
>> To: 'Andrew Fish' ; Kinney, Michael D
>>
>> Cc: edk2-devel@lists.01.org
>> Subject: RE: [edk2] History question about Base.h and
>> its alternate parallel name space Should we change
>> it?
>>
>> I agree with Andrew.
>> In my opinion, moving alias types to Base.h will help to
>> overcome certain practical inconveniences without
>> a significant impact on the ability to detect poorly
>> written Base libraries.
>>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-
>> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2-
>> devel
>> Sent: Wednesday, January 16, 2019 5:18 PM
>> To: Mike Kinney
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] History question about Base.h and
>> its alternate parallel name space Should we change
>> it?
>>
>>
>>
>>> On Jan 16, 2019, at 1:19 PM, Kinney, Michael D
>> wrote:
>>>
>>> Hi Andrew,
>>>
>>> I though the reason was a bit more technical. We have
>> a
>>> MODULE_TYPE of BASE. Library instances that use the
>> BASE
>>> MODULE_TYPE are declaring that the library interfaces
>> are
>>> safe to be linked against a module of any other type
>> (SEC,
>>> PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP).
>>>
>>> We needed to make sure that a lib of type BASE that
>>> includes Base.h as its top level include file only has
>>> visibility to the types that are safe for all the
>> other
>>> module types. It is up to the top level include files
>>> for these other module types to provide the gasket to
>>> the types in Base.h.
>>>
>>> If we add aliases in Base.h, then we may not get build
>>> breaks when a lib of type BASE includes files that are
>>> not compatible with BASE.
>>>
>>
>> Mike,
>>
>> I don't think having aliases for return types really
>> helps Base code quality as RETURN_SUCCESS is almost
>> always just a comment in a header file, and only exists
>> in a .c file. Thus RETURN_* seem like a needless
>> duplication, best case it is a comment that the code is
>> Base.
>>
>> I will agree that not having EFI_GUID defined does case
>> all the PPI and Protocol files to blow up if you try to
>> include them. The failure case I was helping explain was
>> some one trying to include a PPI, that included a
>> Protocol that contained a data structure that was
>> needed. But I would posit that the definition of a
>> (EFI_)GUID is state agnostic. Having access to a PPI or
>> Protocol definition does not break Base code, what
>> breaks Base code is trying to access some service that
>> does not exi
Re: [edk2] Query on Variable Services
> On Jan 17, 2019, at 10:26 AM, galla rao wrote:
>
> Thanks Andrew!
>
> SPI driver has failed the call to, in the log i could see the failure
>
> Status = gDS->SetMemorySpaceAttributes (
>
> BaseAddress,
>
> Length,
>
> GcdDescriptor.Attributes | EFI_MEMORY_RUNTIME
>
> );
>
> if (EFI_ERROR (Status)) {
>
> DEBUG ((DEBUG_WARN, "Variable driver failed to add EFI_MEMORY_RUNTIME
> attribute to Flash. %r \n", Status));
You should dump out the Status value. I guess you could also make sure
BaseAddress, and Length look correct.
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiDxeCis.h#L368
/**
Modifies the attributes for a memory region in the global coherency domain of
the
processor.
@param BaseAddress The physical address that is the start address of a
memory region.
@param Length The size in bytes of the memory region.
@param Attributes The bit mask of attributes to set for the memory
region.
@retval EFI_SUCCESS The attributes were set for the memory region.
@retval EFI_INVALID_PARAMETER Length is zero.
@retval EFI_UNSUPPORTED The processor does not support one or more
bytes of the memory
resource range specified by BaseAddress and
Length.
@retval EFI_UNSUPPORTED The bit mask of attributes is not support for
the memory resource
range specified by BaseAddress and Length.
@retval EFI_ACCESS_DENIED The attributes for the memory resource range
specified by
BaseAddress and Length cannot be modified.
@retval EFI_OUT_OF_RESOURCES There are not enough system resources to modify
the attributes of
the memory resource range.
@retval EFI_NOT_AVAILABLE_YET The attributes cannot be set because CPU
architectural protocol is
not available yet.
**/
typedef
EFI_STATUS
(EFIAPI *EFI_SET_MEMORY_SPACE_ATTRIBUTES)(
IN EFI_PHYSICAL_ADDRESS BaseAddress,
IN UINT64 Length,
IN UINT64 Attributes
);
Thanks,
Andrew Fish
>
> }
>
> if this call has failed SetVirtualAddress would not be useful for Virtual
> Address conversion for this region I believe
>
> Best Regards
> Ranga
>
> On Thu, Jan 17, 2019 at 5:55 PM Andrew Fish <mailto:af...@apple.com>> wrote:
> Galla,
>
> The PCD value usually get set as the result of the build.
>
> EFI_MEMORY_RUNTIME attribute is used to request a virtual mapping from the
> OS. When the variable services are called from the OS the run in a virtual
> address space provided by the OS. Thus trying to access 0xFFE0 would page
> fault.
>
> You can run the memmap command from the EFI Shell and see if bit 63 is set.
> If your SPI controller is a memory mapped hardware device you may also need
> to map the SPI register via EFI_MEMORY_RUNTIME. The SPI driver also needs to
> deal with the SetVirtualAddress map event to convert its pointers over to the
> new OS provided virtual memory space.
>
> Thanks,
>
> Andrew Fish
>
>
> > On Jan 17, 2019, at 9:23 AM, galla rao > <mailto:galla.ra...@gmail.com>> wrote:
> >
> > Hi All,
> >
> > Have a question for Variable services
> >
> > Given PCD's are initialized
> >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase | 0xFFE0
> >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase |
> > 0xFFE3E000
> >
> > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase |
> > 0xFFE4
> >
> > Do i need to make these regions as *EFI_MEMORY_RUNTIME *through
> > *gDS->SetMemorySpaceAttributes*
> >
> > SPI Flash writes within BIOS works good!
> >
> > *when trying to change BootOrder from efibootmgr, the failure is seen*
> >
> > It would be useful if someone has faced this issue earlier and can respond
> > kindly.
> >
> > Best Regards
> > Galla
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> > <https://lists.01.org/mailman/listinfo/edk2-devel>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Query on Variable Services
Galla, The PCD value usually get set as the result of the build. EFI_MEMORY_RUNTIME attribute is used to request a virtual mapping from the OS. When the variable services are called from the OS the run in a virtual address space provided by the OS. Thus trying to access 0xFFE0 would page fault. You can run the memmap command from the EFI Shell and see if bit 63 is set. If your SPI controller is a memory mapped hardware device you may also need to map the SPI register via EFI_MEMORY_RUNTIME. The SPI driver also needs to deal with the SetVirtualAddress map event to convert its pointers over to the new OS provided virtual memory space. Thanks, Andrew Fish > On Jan 17, 2019, at 9:23 AM, galla rao wrote: > > Hi All, > > Have a question for Variable services > > Given PCD's are initialized > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase | 0xFFE0 > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase | > 0xFFE3E000 > > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase | > 0xFFE4 > > Do i need to make these regions as *EFI_MEMORY_RUNTIME *through > *gDS->SetMemorySpaceAttributes* > > SPI Flash writes within BIOS works good! > > *when trying to change BootOrder from efibootmgr, the failure is seen* > > It would be useful if someone has faced this issue earlier and can respond > kindly. > > Best Regards > Galla > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
> On Jan 16, 2019, at 1:19 PM, Kinney, Michael D > wrote: > > Hi Andrew, > > I though the reason was a bit more technical. We have a > MODULE_TYPE of BASE. Library instances that use the BASE > MODULE_TYPE are declaring that the library interfaces are > safe to be linked against a module of any other type (SEC, > PEI, DXE, SMM, DXE_RUNTIME, UEFI_DRIVER, UEFI_APP). > > We needed to make sure that a lib of type BASE that > includes Base.h as its top level include file only has > visibility to the types that are safe for all the other > module types. It is up to the top level include files > for these other module types to provide the gasket to > the types in Base.h. > > If we add aliases in Base.h, then we may not get build > breaks when a lib of type BASE includes files that are > not compatible with BASE. > Mike, I don't think having aliases for return types really helps Base code quality as RETURN_SUCCESS is almost always just a comment in a header file, and only exists in a .c file. Thus RETURN_* seem like a needless duplication, best case it is a comment that the code is Base. I will agree that not having EFI_GUID defined does case all the PPI and Protocol files to blow up if you try to include them. The failure case I was helping explain was some one trying to include a PPI, that included a Protocol that contained a data structure that was needed. But I would posit that the definition of a (EFI_)GUID is state agnostic. Having access to a PPI or Protocol definition does not break Base code, what breaks Base code is trying to access some service that does not exist. To get more that EFI_GUID you are going to need to include Uefi.h, PiPei.h, PiDxe.h, etc. and that will block doing anything that is not Base. So I'm asking if redefining the name for EFI_GUID to GUID for Base is really that helpful? Thanks, Andrew Fish > Thanks, > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of Andrew Fish via edk2- >> devel >> Sent: Wednesday, January 16, 2019 1:00 PM >> To: edk2-devel >> Subject: [edk2] History question about Base.h and its >> alternate parallel name space Should we change it? >> >> I had some one ask me recently why EFI_GUID does not >> work with #include . I explained they needed to >> use GUID vs. EFI_GUID. That prompted the question of why >> we have 2 names for the same thing. Well the >> historical answer was kind of political as some team >> wanted to use edk2, but not implement EFI. Thus we have >> EFI types without the EFI_ prefix in Base.h. >> >> So all this got me thinking Maybe it makes sense to >> move some of the renaming from >> MdePkg/Include/Uefi/UefiBaseType.h to Base.h? Removing >> the Base.h duplicate types would potentially hit lots of >> code [1] and break merges with other code bases (break >> other peoples Base libs etc.). >> >> These lines in MdePkg/Include/Uefi/UefiBaseType.h would >> get moved to MdePkg/Include/Base.h: >> typedef GUID EFI_GUID; >> typedef RETURN_STATUS EFI_STATUS; >> #define EFIERR(_a)ENCODE_ERROR(_a) >> #define EFI_ERROR(A) RETURN_ERROR(A) >> >> #define EFI_SUCCESS RETURN_SUCCESS >> #define EFI_LOAD_ERRORRETURN_LOAD_ERROR >> #define EFI_INVALID_PARAMETER >> RETURN_INVALID_PARAMETER >> #define EFI_UNSUPPORTED RETURN_UNSUPPORTED >> #define EFI_BAD_BUFFER_SIZE RETURN_BAD_BUFFER_SIZE >> #define EFI_BUFFER_TOO_SMALL >> RETURN_BUFFER_TOO_SMALL >> #define EFI_NOT_READY RETURN_NOT_READY >> #define EFI_DEVICE_ERROR RETURN_DEVICE_ERROR >> #define EFI_WRITE_PROTECTED RETURN_WRITE_PROTECTED >> #define EFI_OUT_OF_RESOURCES >> RETURN_OUT_OF_RESOURCES >> #define EFI_VOLUME_CORRUPTED >> RETURN_VOLUME_CORRUPTED >> #define EFI_VOLUME_FULL RETURN_VOLUME_FULL >> #define EFI_NO_MEDIA RETURN_NO_MEDIA >> #define EFI_MEDIA_CHANGED RETURN_MEDIA_CHANGED >> #define EFI_NOT_FOUND RETURN_NOT_FOUND >> #define EFI_ACCESS_DENIED RETURN_ACCESS_DENIED >> #define EFI_NO_RESPONSE RETURN_NO_RESPONSE >> #define EFI_NO_MAPPINGRETURN_NO_MAPPING >> #define EFI_TIMEOUT RETURN_TIMEOUT >> #define EFI_NOT_STARTED RETURN_NOT_STARTED >> #define EFI_ALREADY_STARTED RETURN_ALREADY_STARTED >> #define EFI_ABORTED RETURN_ABORTED >> #define EFI_ICMP_ERRORRETURN_ICMP_ERROR >> #define EFI_TFTP_ERROR
[edk2] History question about Base.h and its alternate parallel name space.... Should we change it?
I had some one ask me recently why EFI_GUID does not work with #include . I explained they needed to use GUID vs. EFI_GUID. That prompted the question of why we have 2 names for the same thing. Well the historical answer was kind of political as some team wanted to use edk2, but not implement EFI. Thus we have EFI types without the EFI_ prefix in Base.h. So all this got me thinking Maybe it makes sense to move some of the renaming from MdePkg/Include/Uefi/UefiBaseType.h to Base.h? Removing the Base.h duplicate types would potentially hit lots of code [1] and break merges with other code bases (break other peoples Base libs etc.). These lines in MdePkg/Include/Uefi/UefiBaseType.h would get moved to MdePkg/Include/Base.h: typedef GUID EFI_GUID; typedef RETURN_STATUS EFI_STATUS; #define EFIERR(_a)ENCODE_ERROR(_a) #define EFI_ERROR(A) RETURN_ERROR(A) #define EFI_SUCCESS RETURN_SUCCESS #define EFI_LOAD_ERRORRETURN_LOAD_ERROR #define EFI_INVALID_PARAMETER RETURN_INVALID_PARAMETER #define EFI_UNSUPPORTED RETURN_UNSUPPORTED #define EFI_BAD_BUFFER_SIZE RETURN_BAD_BUFFER_SIZE #define EFI_BUFFER_TOO_SMALL RETURN_BUFFER_TOO_SMALL #define EFI_NOT_READY RETURN_NOT_READY #define EFI_DEVICE_ERROR RETURN_DEVICE_ERROR #define EFI_WRITE_PROTECTED RETURN_WRITE_PROTECTED #define EFI_OUT_OF_RESOURCES RETURN_OUT_OF_RESOURCES #define EFI_VOLUME_CORRUPTED RETURN_VOLUME_CORRUPTED #define EFI_VOLUME_FULL RETURN_VOLUME_FULL #define EFI_NO_MEDIA RETURN_NO_MEDIA #define EFI_MEDIA_CHANGED RETURN_MEDIA_CHANGED #define EFI_NOT_FOUND RETURN_NOT_FOUND #define EFI_ACCESS_DENIED RETURN_ACCESS_DENIED #define EFI_NO_RESPONSE RETURN_NO_RESPONSE #define EFI_NO_MAPPINGRETURN_NO_MAPPING #define EFI_TIMEOUT RETURN_TIMEOUT #define EFI_NOT_STARTED RETURN_NOT_STARTED #define EFI_ALREADY_STARTED RETURN_ALREADY_STARTED #define EFI_ABORTED RETURN_ABORTED #define EFI_ICMP_ERRORRETURN_ICMP_ERROR #define EFI_TFTP_ERRORRETURN_TFTP_ERROR #define EFI_PROTOCOL_ERRORRETURN_PROTOCOL_ERROR #define EFI_INCOMPATIBLE_VERSION RETURN_INCOMPATIBLE_VERSION #define EFI_SECURITY_VIOLATIONRETURN_SECURITY_VIOLATION #define EFI_CRC_ERROR RETURN_CRC_ERROR #define EFI_END_OF_MEDIA RETURN_END_OF_MEDIA #define EFI_END_OF_FILE RETURN_END_OF_FILE #define EFI_INVALID_LANGUAGE RETURN_INVALID_LANGUAGE #define EFI_COMPROMISED_DATA RETURN_COMPROMISED_DATA #define EFI_HTTP_ERRORRETURN_HTTP_ERROR #define EFI_WARN_UNKNOWN_GLYPHRETURN_WARN_UNKNOWN_GLYPH #define EFI_WARN_DELETE_FAILURE RETURN_WARN_DELETE_FAILURE #define EFI_WARN_WRITE_FAILURERETURN_WARN_WRITE_FAILURE #define EFI_WARN_BUFFER_TOO_SMALL RETURN_WARN_BUFFER_TOO_SMALL #define EFI_WARN_STALE_DATA RETURN_WARN_STALE_DATA #define EFI_WARN_FILE_SYSTEM RETURN_WARN_FILE_SYSTEM I'm interested what folks think about a change like this? This change makes the alternate names optional. I guess we could also leave the old Base.h definitions in Base.h and cleanup the code to only use the EFI form, but that is a much bigger change? [1] RETURN_SUCCSS usage: git grep -w RETURN_SUCCESS Thanks, Andrew Fish ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Missing PI definitions?
Liming, Sorry I guess I was confusing this with EFI_RESOURCE_ATTRIBUTE_TESTED. I'll a little confused that it is implementation given it is passed into gDS->AddMemorySpace() the PI Spec defines the values of Capabilities to be defined in the UEFI Spec. as the GetMemoryMap() attributes. It is not clear that the implementation actually owns these bits? Almost feels like we should update the PI spec to include these #defines. I seem to remember we have been using these bits for a long time. Thanks, Andrew Fish > On Dec 4, 2018, at 4:19 PM, Gao, Liming wrote: > > Andrew: > UEFI spec doesn't define them. They are the implement related definitions. > They are not required to be exposed to OS. We can add one header file in > MdeModulePkg to share them between DxeCore and MemoryTest driver. Besides, > ECP package will be retired. There is no change for it. > > #define EFI_MEMORY_PRESENT 0x0100ULL > #define EFI_MEMORY_INITIALIZED 0x0200ULL > #define EFI_MEMORY_TESTED 0x0400ULL > > Thanks > Liming >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org >> <mailto:edk2-devel-boun...@lists.01.org>] On Behalf Of >> Andrew Fish ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Missing PI definitions?
Anyone remember why these defines are not in a common header in the MdePkg? /Volumes/Case/UDK2018(vUDK2018)>git grep MEMORY_PRESENT -- *.h EdkCompatibilityPkg/Foundation/Include/TianoTypes.h:31:#define EFI_MEMORY_PRESENT 0x0100 MdeModulePkg/Core/Dxe/DxeMain.h:101:#define EFI_MEMORY_PRESENT 0x0100ULL MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/LightMemoryTest.h:42:#define EFI_MEMORY_PRESENT 0x0100ULL MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTest.h:33:#define EFI_MEMORY_PRESENT 0x0100ULL /Volumes/Case/UDK2018(vUDK2018)>git grep EFI_MEMORY_INITIALIZED -- *.h EdkCompatibilityPkg/Foundation/Include/TianoTypes.h:32:#define EFI_MEMORY_INITIALIZED 0x0200 MdeModulePkg/Core/Dxe/DxeMain.h:102:#define EFI_MEMORY_INITIALIZED 0x0200ULL MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/LightMemoryTest.h:43:#define EFI_MEMORY_INITIALIZED 0x0200ULL MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTest.h:34:#define EFI_MEMORY_INITIALIZED 0x0200ULL /Volumes/Case/UDK2018(vUDK2018)>git grep EFI_MEMORY_TESTED -- *.h EdkCompatibilityPkg/Foundation/Include/TianoTypes.h:33:#define EFI_MEMORY_TESTED 0x0400 MdeModulePkg/Core/Dxe/DxeMain.h:103:#define EFI_MEMORY_TESTED 0x0400ULL MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/LightMemoryTest.h:44:#define EFI_MEMORY_TESTED 0x0400ULL MdeModulePkg/Universal/MemoryTest/NullMemoryTestDxe/NullMemoryTest.h:35:#define EFI_MEMORY_TESTED 0x0400ULL Thanks, Andrew Fish ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Creating my own flashing app
On a secure platform you likely need to update using a secure capsule. https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery The capsule is the standard method, and then all the FLASH update code is part of the ROM. Generally since an EFI platform has NVRAM services in the NOR FLASH there is an SPI driver to write to FLASH. So if your platform does not secure FLASH you can use the services from the ROM. Sent from my iPhone > On Dec 3, 2018, at 8:45 PM, Guy Raviv wrote: > > a whole SPI BIOS image. > if i was not clear please tell me what i'm missing. > > Thanks! > Guy > > Virus-free. www.avg.com > >> On Tue, Dec 4, 2018 at 6:42 AM Andrew Fish wrote: >> Guy, >> >> What are you trying to FLASH? >> >> Thanks, >> >> Andrew Fish >> >> > On Dec 3, 2018, at 7:28 PM, Guy Raviv wrote: >> > >> > Hi, >> > >> > I want to create my own flashing utility. >> > Is there any EDKII App/Utilities that can help me? >> > >> > Thanks, >> > Guy >> > >> > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> >> > Virus-free. >> > www.avg.com >> > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> >> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > ___ >> > edk2-devel mailing list >> > edk2-devel@lists.01.org >> > https://lists.01.org/mailman/listinfo/edk2-devel >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Creating my own flashing app
Guy, What are you trying to FLASH? Thanks, Andrew Fish > On Dec 3, 2018, at 7:28 PM, Guy Raviv wrote: > > Hi, > > I want to create my own flashing utility. > Is there any EDKII App/Utilities that can help me? > > Thanks, > Guy > > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> > Virus-free. > www.avg.com > <http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP
Felix, I agree the obfuscation may not really be helpful. I've got a couple of thoughts. 1) I agree that I don't think the DebugLib is inherently safe on APs. I wonder if we could make a library class that was DebugLibMpSafe and have the same API as DebugLib. That way the library class matches how the module was coded. 2) If we want to enforce the rules we should add code to the PEI or DXE Core to CpuBreakpoint() etc. if an AP calls a core service. Adding detection code is possible, but it is not trivial. For example if you have remembered the BSP and if the WhoAmI returns something different you need to check to see if some one changed the BSP. I guess for PEI the other option could be to have a fake PEI Services Table that stubs out all the functions with CpuBreakpoint() or some such? Thanks, Andrew Fish > On Nov 30, 2018, at 6:33 AM, Felix Polyudov wrote: > > Ray, > > I agree with the premise that calling PEI services from AP should generally > be avoided. > However, the PEI services can be used on AP under certain special > circumstances. > A couple of examples: > 1. For debugging purposes. The MpInitLib contains 12 DEBUG calls and 19 > ASSERT calls. Depending on the DebugLib instance used in the project, these > calls may lead to PEI services invocation. > 2. MpInitLib provides ability to call AP in a serialized manner (only one AP > is running, other APs and BSP are waiting), when it is safe to call PEI > services. > > Additionally, I think even if PEI services should not be used on AP, there is > still a reason to keep PEI services table pointer initialized. > On one hand, given the complexity of modern firmware projects comprised of > modules coming from multiple vendors, making sure PEI services are not used > on AP can be a challenge. > For example, in my case the call was coming from the chipset reference code. > On the other hand, with the current implementation, when somebody does try to > use PEI services on AP the behavior is unpredictable. > Depending on the content of the uninitialized PEI service table pointer, the > system may either crash with one of the handful of different exceptions, > or it may start executing code from a random location. It's very difficult to > debug such issues. One can spend weeks chasing a problem like this. > > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org > <mailto:edk2-devel-boun...@lists.01.org>] On Behalf Of Ni, Ruiyu > Sent: Thursday, November 29, 2018 10:43 PM > To: Felix Polyudov; edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > Cc: ler...@redhat.com <mailto:ler...@redhat.com>; Dong, Eric > Subject: Re: [edk2] [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer > on AP > > Felix, > I disagree:) Sorry about that. :) > > The commit you mentioned might be made by me (didn't checked). > Because I aimed to avoid calling PEI services from AP. That's a violation of > PI spec and not safe by design. > > The AP calling standard services concern was raised by Andrew initially. > > Thanks, > Ray > >> -Original Message- >> From: Felix Polyudov [mailto:fel...@ami.com] >> Sent: Friday, November 30, 2018 8:36 AM >> To: edk2-devel@lists.01.org >> Cc: Dong, Eric ; Ni, Ruiyu ; >> ler...@redhat.com >> Subject: [Patch] UefiCpuPkg/MpLib: Fix PEI Services Table pointer on AP >> >> According to PI specification PEI Services table pointer is stored right >> before ITD >> base. Starting from commit c563077a380437c1 BSP and AP have different IDT >> instances. >> PEI Services table pointer was not initialized in the AP IDT instance. >> As a result, any attempt to use functions from PeiServicesTablePointerLib or >> PeiServicesLib on AP caused CPU exception. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Felix Polyudov >> --- >> UefiCpuPkg/Library/MpInitLib/MpLib.c | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c >> b/UefiCpuPkg/Library/MpInitLib/MpLib.c >> index 7f4d6e6..0e3e362 100644 >> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c >> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c >> @@ -1567,6 +1567,7 @@ MpInitLibInitialize ( >> BufferSize = ApStackSize * MaxLogicalProcessorNumber; >> BufferSize += MonitorFilterSize * MaxLogicalProcessorNumber; >> BufferSize += ApResetVectorSize; >> + BufferSize += sizeof(UINTN); >> BufferSize = ALIGN_VALUE (BufferSize, 8); >> BufferSize += VolatileRegisters.Idtr.Limit + 1; >> BufferSize += sizeof (CPU_MP_DATA); >> @@ -1587,6
Re: [edk2] [RFC] Proposal to add edk2-apps repository
Mike, As Krishna points out there are flavors of Apps. Do we want to have different packages for different flavor of apps, or different dirs in a more generic App package? Maybe we should define classes of UEFI Applications in the README.md and give them a place to live. I don't want to get too pedantic so we can have a 1st level of if you depend on X you go here. Maybe something if you depend on the clib you go in the Clib dir, if you depend on Shell you go in Shell. With a priority to the list so clib always means clib dir. etc.? Thanks, Andrew Fish > On Nov 29, 2018, at 5:44 PM, krishnaLee wrote: > > Kinney, > I always think there may be two kinds of apps: > 1,some apps have dependency on > uefi_shell(shell-lib,efi_shell_protocol,...they usually execute under > uefi_shell),I would call them "uefi_shell_application"; > 2,some apps have no dependency on uefi_shell(such as apps in > MdeModulePkg/Application),I would call them "standard_uefi_application". > > The "AppPkg / StdLib / StdLibPrivateInternalFiles" packages are usually used > by uefi_shell_application,I think they can all move to ShellPkg,no need to > create new package ? > > > Thanks, > krishna. > > At 2018-11-30 08:46:58, "Kinney, Michael D" > wrote: >> Leif, >> >> I did consider the edk2-libc name. The port of Python 2.7 >> is in the AppPkg as well and it uses libc. >> >> So the content of this new package is a combination of libc >> And apps that use libc. >> >> I am definitely open to alternate names. 2 options so far: >> >> * edk2-apps >> * edk2-libc >> >> Thanks, >> >> Mike >> >>> -Original Message- >>> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >>> Sent: Thursday, November 29, 2018 2:41 PM >>> To: Kinney, Michael D >>> Cc: edk2-devel@lists.01.org >>> Subject: Re: [edk2] [RFC] Proposal to add edk2-apps >>> repository >>> >>> On Thu, Nov 29, 2018 at 05:58:08PM +, Kinney, Michael >>> D wrote: >>>> Hello, >>>> >>>> I would like to propose the creation of a new >>>> repository called edk2-apps. This repository >>>> would initially be used to host the following >>>> packages from the edk2 repository: >>>> >>>> * AppPkg >>>> * StdLib >>>> * StdLibPrivateInternalFiles >>> >>> Let me start by saying I 100% back moving these out of the >>> main edk2 >>> repository. >>> >>>> These 3 packages provide support for the libc along >>>> with applications that depend on libc. None of the >>>> other packages in the edk2 repository use these >>>> packages, so these 3 package can be safely moved >>>> without any impacts to platform firmware builds. >>>> Build configurations that do use libc features can >>>> clone the edk2-apps repository and add it to >>>> PACKAGES_PATH. >>> >>> I must confess to never having properly understood the >>> scope of AppPkg >>> to begin with. >>> >>> AppPkg/Applications/Hello does not appear to have any >>> further (real) >>> dependency on libc than >>> MdeModulePkg/Application/HelloWorld/, and . >>> >>> And certainly MdeModulePkg/Applications contain plenty of >>> ... applications. >>> >>> So, if the purpose is simply to provide some examples of >>> application >>> written to libc rather than UEFI - should this be edk2- >>> libc instead? >>> >>> Best Regards, >>> >>> Leif >>> >>>> The history of these 3 packages would be preserved >>>> when importing the content into edk2-apps. After >>>> The import is verified, these 3 packages would be >>>> deleted from the edk2 repository. >>>> >>>> This proposal helps reduce the size of the edk2 >>>> repository and focuses edk2 repository on packages >>>> used to provide UEFI/PI conformant firmware. >>>> >>>> If there are no concerns with this proposal, I will >>>> enter a Tianocore BZs for the two steps. >>>> >>>> Best regards, >>>> >>>> Mike >>>> ___ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot
Udit, Memory map differences would be expected as UiApp.efi is going to allocate memory too. The OS Loader starts off as an EFI Application so it needs to know EFI time allocations in addition to what allocations are legal for the OS to use. In general how EFI communicates with the OS is via EFI NVRAM Variables. You can look at the Table in section "3.3 Globally Defined Variables" of the UEFI Spec. The OSprot will also figure out information about the platform from ACPI tables published by the EFI firmware. Also the OS Loader is an EFI App so it can access any protocol mentioned in the UEFI Spec. So form example on a Unix like OS the OS Loader may construct a Device Tree and pass it up to the kernel. It is going to be the code in the OS loader that does all this magic. If your working with a FOSS OS you may want to try and dump that device tree, and see if something is different. Then you could try to figure out the code in the OS Loader that produces that part of the device tree. Thanks, Andrew Fish > On Nov 28, 2018, at 5:42 PM, Udit Kumar wrote: > > Hi , > I am looking for information/Help. If UEFI passed different information to > OS, in below boot path > > 1. Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on > console, select device to boot OS > 2. Let the boot OS without user intervention from same device as of 1 > > I could see, UEFI pass different memory map in case of 1 and 2. > Is there some other/extra information is being shared with OS/OS Loader. > > For me, if I use 1) for booting then OS boots okay, > If I use option 2) for booting then when user-space prints are printed as > garbage. Whereas kernel space prints are good on serial console > > Thanks > Udit > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Newbie: Getting Ovmf built
> On Nov 24, 2018, at 11:46 AM, Peter Wiehe wrote:
>
> As I said: I can't run "build". That command is unkown.
>
Peter,
The build command is what is required to build the firmware.
Sourcing the edksetup.sh should set your path so build can be found.
I'm on macOS and it looks like this to me:
/Volumes/Case/UDK2018(vUDK2018)>echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware
Fusion.app/Contents/Public:/opt/appleinternal/bin:/opt/apple/bin:/opt/X11/bin:/Applications/Araxis\
Merge.app/Contents/Utilities
/Volumes/Case/UDK2018(vUDK2018)>. edksetup.sh BaseTools
WORKSPACE: /Volumes/Case/UDK2018
EDK_TOOLS_PATH: /Volumes/Case/UDK2018/BaseTools
CONF_PATH: /Volumes/Case/UDK2018/Conf
/Volumes/Case/UDK2018(vUDK2018)>echo $PATH
/Volumes/Case/UDK2018/BaseTools/Bin/Darwin-x86_64:/Volumes/Case/UDK2018/BaseTools/BinWrappers/PosixLike:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Applications/VMware
Fusion.app/Contents/Public:/opt/appleinternal/bin:/opt/apple/bin:/opt/X11/bin:/Applications/Araxis\
Merge.app/Contents/Utilities
/Volumes/Case/UDK2018(vUDK2018)>which build
/Volumes/Case/UDK2018/BaseTools/BinWrappers/PosixLike/build
/Volumes/Case/UDK2018(vUDK2018)>cat
/Volumes/Case/UDK2018/BaseTools/BinWrappers/PosixLike/build
#!/usr/bin/env bash
#python `dirname $0`/RunToolFromSource.py `basename $0` $*
# If a python2 command is available, use it in preference to python
if command -v python2 >/dev/null 2>&1; then
python_exe=python2
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")
cmd=${full_cmd##*/}
export PYTHONPATH="$dir/../../Source/Python"
exec "${python_exe:-python}" "$dir/../../Source/Python/$cmd/$cmd.py" "$@"
As you can see sourcing edksetup.sh should update your path to point to a
location for build. What happens on your system?
Thanks,
Andrew Fish
> Peter
>
> Andrew Fish mailto:af...@apple.com>> schrieb am Sa., 24.
> Nov. 2018 20:45:
> Run the build command. Conf/target.txt controls the default arguments passed
> to build.
>
> Sourcing edksetup.sh should set your path. Did you miss the “.” or get an
> error?
> . edksetup.sh BaseTools
>
> Sent from my iPad
>
> > On Nov 24, 2018, at 10:03 AM, Peter Wiehe > <mailto:peter.wie...@gmail.com>> wrote:
> >
> > OK, thanks! Done that.
> >
> > But how do I get to build the MdeModulePkg? I did setup as mentioned
> > in
> > https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions
> > <https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions>
> >
> > Peter
> >
> > 2018-11-24 18:57 GMT+01:00, stephano > <mailto:stephano.cet...@linux.intel.com>>:
> >> Hey Peter,
> >>
> >> We're still using GCC5 for most of our testing. Try building with that
> >> release:
> >>
> >> apt install gcc-5
> >>
> >> Then in Conf/target.txt:
> >> TOOL_CHAIN_TAG = GCC5
> >>
> >> Cheers,
> >> Stephano
> >>
> >>> On 11/24/2018 9:23 AM, Peter Wiehe wrote:
> >>> OK
> >>>
> >>> Building went well to a certain point. I successfully git cloned. I
> >>> built the BaseTools.
> >>>
> >>> I (seemingly successfully) setup the build shell environment. (I got no
> >>> errors.)
> >>>
> >>> In the target conf file I chose "IA32 X64" and ELFGCC (since I habe
> >>> gcc 7.3.0 installed).
> >>> When I type "build", there comes an error like "Command build not found".
> >>>
> >>> I thought that maybe it's because of the shell environment variable
> >>> $PATH. $PATH does NOT contain the edk2 source directory in any way
> >>> (despite the fact that I entered "export EDK_TOOLS_PATH...").
> >>>
> >>> What can I do?
> >>>
> >>> Greetings
> >>> Peter
> >>>
> >>> 2018-11-24 1:40 GMT+01:00, stephano >>> <mailto:stephano.cet...@linux.intel.com>>:
> >>>> Hello Peter,
> >>>>
> >>>> Thanks for giving EDK2 a try!
> >>>>
> >>>> We have a set of simple instructions for folks building on standard
> >>>> Linux distros. Please have a look at this page:
> >>>>
> >>>> https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions
> >>>>
Re: [edk2] Newbie: Getting Ovmf built
Run the build command. Conf/target.txt controls the default arguments passed to build. Sourcing edksetup.sh should set your path. Did you miss the “.” or get an error? . edksetup.sh BaseTools Sent from my iPad > On Nov 24, 2018, at 10:03 AM, Peter Wiehe wrote: > > OK, thanks! Done that. > > But how do I get to build the MdeModulePkg? I did setup as mentioned > in https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions > > Peter > > 2018-11-24 18:57 GMT+01:00, stephano : >> Hey Peter, >> >> We're still using GCC5 for most of our testing. Try building with that >> release: >> >> apt install gcc-5 >> >> Then in Conf/target.txt: >> TOOL_CHAIN_TAG = GCC5 >> >> Cheers, >> Stephano >> >>> On 11/24/2018 9:23 AM, Peter Wiehe wrote: >>> OK >>> >>> Building went well to a certain point. I successfully git cloned. I >>> built the BaseTools. >>> >>> I (seemingly successfully) setup the build shell environment. (I got no >>> errors.) >>> >>> In the target conf file I chose "IA32 X64" and ELFGCC (since I habe >>> gcc 7.3.0 installed). >>> When I type "build", there comes an error like "Command build not found". >>> >>> I thought that maybe it's because of the shell environment variable >>> $PATH. $PATH does NOT contain the edk2 source directory in any way >>> (despite the fact that I entered "export EDK_TOOLS_PATH..."). >>> >>> What can I do? >>> >>> Greetings >>> Peter >>> >>> 2018-11-24 1:40 GMT+01:00, stephano : Hello Peter, Thanks for giving EDK2 a try! We have a set of simple instructions for folks building on standard Linux distros. Please have a look at this page: https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions Note: Be sure the TARGET_ARCH is set correctly. (E.g. TARGET_ARCH = x64) Once you have built the BaseTools and MdeModulePkg without any errors, you can try building and running in OVMF: https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF Tip: Add the -j option so that you can grep through the log easily for any errors (build -j /path/to/log/file.txt). Hopefully those links help get you started. Let me know if you run into any other issues. Cheers, Stephano Stephano Cetola TianoCore Community Manager > On 11/23/2018 2:44 PM, Peter Wiehe wrote: > Hello, I'm a total newbie to Tianocore/EDK2/OVMF. > (My coding is at high school level I think, not university level. I > have some (small) experience writing in Assembler, C, C++. I wrote a > little bootloader, so I know something about filesystem in general and > ext2 and pre-kernel "environment".) > > I use xubuntu 18.04 on an AMD 64bit PC. > > I'm currently trying to > 1.) build OVMF from source > 2.) and then want to run it in/with Qemu. > 3.) Later I would like to try to write a simple ext2 "driver". Can't > guarantee I will succeed, but let's see. > > So far I have > 1.) downloaded the whole edk2 zip/tar-ball > 2.) have installed nasm and ASL (iasl) > 3.) Run "EmulatorPkg/build.sh" > 4.) Run "OvmfPkg/build.sh -a X64" > 5.) Run "OvmfPkg/build.sh -a X64 qemu" > > Then I get the error message "qemu-system-x86_64: -pflash > /home/peter/Schreibtisch/edk2-master/Build/OvmfX64/DEBUG_GCC5/QEMU/bios.bin: > Could not open > '/home/peter/Schreibtisch/edk2-master/Build/OvmfX64/DEBUG_GCC5/QEMU/bios.bin': > No such file or directory" > > So my first question is how to deal with this error. > > Kind regards > Peter Wiehe > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > >>> ___ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Proposal to remove DuetPkg
Works for me too. Thanks, Andrew Fish > On Nov 20, 2018, at 3:20 PM, Kinney, Michael D > wrote: > > I agree with this proposal. > > I also agree with Leif that large patch series > must be shared on a branch for review. > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] >> On Behalf Of Leif Lindholm >> Sent: Tuesday, November 20, 2018 1:57 AM >> To: Ni, Ruiyu >> Cc: edk2-devel@lists.01.org; Gao, Liming >> ; Richardson, Brian >> ; Cetola, Stephano >> ; Kinney, Michael D >> ; Laszlo Ersek >> >> Subject: Re: [edk2] [RFC] Proposal to remove DuetPkg >> >> On Tue, Nov 20, 2018 at 05:27:13AM +, Ni, Ruiyu >> wrote: >>> All, >>> DuetPkg depends on Legacy BIOS to provide a UEFI >> environment. It was >>> invented in the era when UEFI environment is hard to >> find. Since now >>> UEFI is very popular in PC area, we could stop the >> official support >>> of this package and remove it from the master. >>> Anyone who wants to use it still can just grab it from >> git >>> history. This is the same as what we did for IPF >> contents. >>> >>> If there is no concern by end of November, we will send >> out a formal >>> patch to remove DuetPkg. (Since DuetPkg is big, we will >> not generate >>> the huge patch using git command, instead we will just >> send out the >>> patch mail with correct title/commit message but empty >> content.) >> >> Works for me. If you could include a link to the patch in >> a branch >> where it can be reviewed, that would be ideal. >> >> / >>Leif >> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 19, 2018, at 2:29 PM, Jordan Justen wrote:
>
> On 2018-11-19 13:22:27, Andrew Fish wrote:
>>
>>
>>> On Nov 19, 2018, at 11:16 AM, Jordan Justen
>>> wrote:
>>>
>>> On 2018-11-18 17:13:21, Jordan Justen wrote:
>>>> On 2018-11-18 14:37:09, Andrew Fish wrote:
>>>>>
>>>>>
>>>>>> On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
>>>>>>
>>>>>> sorry your path can't fix this issue. if this path just turn off
>>>>>> optimization option within sec.c not global project.
>>>>>>
>>>>>> I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
>>>>>> and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
>>>>>>
>>>>>> I have traced this issue on my hand.
>>>>>>
>>>>>> you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
>>>>>>
>>>>>>
>>>>>> 790 if (StackOffsetPositive) {
>>>>>> 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
>>>>>> *)SecCoreData + StackOffset);
>>>>>> 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
>>>>>> StackOffset);
>>>>>> 793 } else {
>>>>>> 794 ..
>>>>>> 795 ..
>>>>>> 796}
>>>>>>
>>>>>> 790 --792 disassembly code
>>>>>>
>>>>>> 0x10200f2ca :test %r14b,%r14b
>>>>>> 0x10200f2cd :je 0x10200f2df
>>>>>>
>>>>>> 0x10200f2cf :mov 0x38(%rsp),%rax
>>>>>> 0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
>>>>>> 0x10200f2d9 :lea (%rbx,%rax,1),%rbp
>>>>>>
>>>>>> we can see Private value have been stored in %rbp (rbp register be
>>>>>> used as general register ) so when call
>>>>>> TemporaryRamSupportPpi->TemporaryRamMigration()
>>>>>>
>>>>>
>>>>> The calling conventions define RBP as non-volatile must be preserved
>>>>> by callee. Using RBP as the frame pointer is optional.
>>>>
>>>> This is kind of a mess. I think the definition of
>>>> EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
>>>> should not have been spec'd as 'change stack and return'. Instead, it
>>>> should have been given a new function pointer to switch-stack and call
>>>> into.
>>>
>>> Andrew, Mike,
>>>
>>> I developed a PEI Core fix for this issue, which Liu Yu verified.
>>>
>>> Unfortunately, it involves add assembly code in a key area of the PEI
>>> Core. See the top 2 commits of:
>>>
>>> https://github.com/jljusten/edk2/commits/emulator-temp-ram
>>> <https://github.com/jljusten/edk2/commits/emulator-temp-ram>
>>>
>>> I only wrote assembly for X64 nasm. But, I notice that neither the PEI
>>> or DXE Core modules include any assembly code. So, I want to make sure
>>> I'm heading in the right direction before working on it further.
>>>
>>
>> Mike,
>>
>> I seem to remember we hit an issue like this a long time ago? Do you
>> remember the details? Maybe it was we needed to write the
>> TempRamSupport code in assembly?
>
> It does also creep up there, which is why we also adjust ebp/rbp in
> the TemporaryRamMigration function in OVMF.
>
> In that case, it helps prevent the stack from reverting to the old
> stack when TemporaryRamMigration is returning to it's caller. (As
> opposed to after it returns, which I think is what is happening now.)
>
The stack is switched in both cases. The problem is the C code, for the gcc
code gen, does a leave so it moves %rbp into %rsp. The %rbp in the C code was
the temp stack frame on entry. So the leave instruction from the C code gen
reverts to the old stack.
>> The issue we are hitting is the gEfiTemporaryRamSupportPpiGuid
>> TemporaryRamMigration() function call does a stack switch, but it
>> returns. This causes an issue with the C calling conventions as RBP
>> is optionally a frame pointer. To quote the MSFT spec: "May be used
>> as a frame pointer; must be preserved by callee"
>> 1) It is used as a frame pointer. It looks like our existing code
>> fixes up the frame pointer to match the new location the s
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 19, 2018, at 2:12 PM, Laszlo Ersek wrote:
>
> Jordan wrote:
>
>>>> So, is it safe to adjust rbp? Unknown. It may not be if rbp is not
>>>> used as a frame pointer. Is it safe to *not* adjust rbp and
>>>> potentially allow the old temp ram stack to be used? Unknown.
>
> Andrew wrote:
>
>> Looks like OvmfPkg uses SetJump()/LongJump() to change the stack.
>>
>> //
>> // Use SetJump()/LongJump() to switch to a new stack.
>> //
>> if (SetJump () == 0) {
>> #if defined (MDE_CPU_IA32)
>>JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset;
>>JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateOffset;
>> #endif
>> #if defined (MDE_CPU_X64)
>>JumpBuffer.Rsp = JumpBuffer.Rsp + DebugAgentContext.StackMigrateOffset;
>>JumpBuffer.Rbp = JumpBuffer.Rbp + DebugAgentContext.StackMigrateOffset;
>> #endif
>>LongJump (, (UINTN)-1);
>> }
>>
>> SaveAndSetDebugTimerInterrupt (OldStatus);
>>
>> return EFI_SUCCESS;
>> }
>>
>> But given the above code is C code RBP is going to be restored on return.
>> This would seem to imply that the adjusting of the callers RBP is not
>> required? [...]
>
> The Ebp/Rbp assignments were added in a separate bugfix, namely
>
> https://github.com/tianocore/edk2/commit/89796c69d9fd
>
Laszlo,
This makes sense since as the post-amble when using frame pointers is either:
addq$288, %rsp ## imm = 0x120
popq%rbp
retq
or
>0xfffcd42f <+403>: c9 leaveq
>0xfffcd430 <+404>: c3 retq
I've noticed that clang does not seem to be a big fan of the leave function and
it adjusts the stack pointer using math rather than using %rbp.
The stack unwind algorithm implies that the frame point, %rbp in our case, is
valid while the function is running. Even for the clang code gen not switching
the frame point would break the stack unwind.
Thanks,
Andrew Fish
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 19, 2018, at 11:16 AM, Jordan Justen wrote:
>
> On 2018-11-18 17:13:21, Jordan Justen wrote:
>> On 2018-11-18 14:37:09, Andrew Fish wrote:
>>>
>>>
>>>> On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
>>>>
>>>> sorry your path can't fix this issue. if this path just turn off
>>>> optimization option within sec.c not global project.
>>>>
>>>> I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
>>>> and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
>>>>
>>>> I have traced this issue on my hand.
>>>>
>>>> you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
>>>>
>>>>
>>>> 790 if (StackOffsetPositive) {
>>>> 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
>>>> *)SecCoreData + StackOffset);
>>>> 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
>>>> StackOffset);
>>>> 793 } else {
>>>> 794 ..
>>>> 795 ..
>>>> 796}
>>>>
>>>> 790 --792 disassembly code
>>>>
>>>> 0x10200f2ca :test %r14b,%r14b
>>>> 0x10200f2cd :je 0x10200f2df
>>>>
>>>> 0x10200f2cf :mov 0x38(%rsp),%rax
>>>> 0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
>>>> 0x10200f2d9 :lea (%rbx,%rax,1),%rbp
>>>>
>>>> we can see Private value have been stored in %rbp (rbp register be
>>>> used as general register ) so when call
>>>> TemporaryRamSupportPpi->TemporaryRamMigration()
>>>>
>>>
>>> The calling conventions define RBP as non-volatile must be preserved
>>> by callee. Using RBP as the frame pointer is optional.
>>
>> This is kind of a mess. I think the definition of
>> EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
>> should not have been spec'd as 'change stack and return'. Instead, it
>> should have been given a new function pointer to switch-stack and call
>> into.
>
> Andrew, Mike,
>
> I developed a PEI Core fix for this issue, which Liu Yu verified.
>
> Unfortunately, it involves add assembly code in a key area of the PEI
> Core. See the top 2 commits of:
>
> https://github.com/jljusten/edk2/commits/emulator-temp-ram
> <https://github.com/jljusten/edk2/commits/emulator-temp-ram>
>
> I only wrote assembly for X64 nasm. But, I notice that neither the PEI
> or DXE Core modules include any assembly code. So, I want to make sure
> I'm heading in the right direction before working on it further.
>
Mike,
I seem to remember we hit an issue like this a long time ago? Do you remember
the details? Maybe it was we needed to write the TempRamSupport code in
assembly?
The issue we are hitting is the gEfiTemporaryRamSupportPpiGuid
TemporaryRamMigration() function call does a stack switch, but it returns. This
causes an issue with the C calling conventions as RBP is optionally a frame
pointer. To quote the MSFT spec: "May be used as a frame pointer; must be
preserved by callee"
1) It is used as a frame pointer. It looks like our existing code fixes up the
frame pointer to match the new location the stack got moved to.
2) Used as a general purpose register, and the value must be preserved.
> As I mentioned below, I think PIWG could consider an new
> TemporarayRemSupport interface that might work better, but that also
> may not be worth the effort.
If the current API is not really portable I don;t think it is a bad idea to
update it.
>
> Can something like this change be integrated into the PEI Core?
Jordan,
I'm not sure? For the RBP == frame pointer case the frame pointer is no longer
valid (it is in temp RAM, not DRAM). It seems like the point of
SecTemporaryRamSupport() fixing up the callers RBP is for the benefit of the
caller. It looks to me like your fix is just negating that fixup. So that would
imply that either we could just fix this in SecTemporaryRamSupport() or we have
2 code gen paths and we need to know how the compiler is using RBP to "do the
right thing"
Do we have other code that supports X64 PEI? Is see OvmfPkg
https://github.com/tianocore/edk2/blob/master/OvmfPkg/Sec/SecMain.c#L875
Looks like OvmfPkg uses SetJump()/LongJump() to change the stack.
//
// Use SetJump()/LongJump() to switch to a new stack.
//
if (SetJump () == 0) {
#if defined (MDE_CPU_IA32)
JumpBuffer.Esp = JumpBuffer.Esp + DebugAgentContext.StackMigrateOffset;
JumpBuffer.Ebp = JumpBuffer.Ebp + DebugAgentContext.StackMigrateO
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
> On Nov 18, 2018, at 4:07 AM, Liu Yu wrote:
>
> sorry your path can't fix this issue. if this path just turn off
> optimization option within sec.c not global project.
>
> I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
> and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
>
> I have traced this issue on my hand.
>
> you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
>
>
> 790 if (StackOffsetPositive) {
> 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
> *)SecCoreData + StackOffset);
> 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
> StackOffset);
> 793 } else {
> 794 ..
> 795 ..
> 796}
>
> 790 --792 disassembly code
>
> 0x10200f2ca :test %r14b,%r14b
> 0x10200f2cd :je 0x10200f2df
>
> 0x10200f2cf :mov 0x38(%rsp),%rax
> 0x10200f2d4 :lea 0x0(%rbp,%rax,1),%r14
> 0x10200f2d9 :lea (%rbx,%rax,1),%rbp
>
> we can see Private value have been stored in %rbp (rbp register be
> used as general register ) so when call
> TemporaryRamSupportPpi->TemporaryRamMigration()
>
The calling conventions define RBP as non-volatile must be preserved by callee.
Using RBP as the frame pointer is optional.
Is it possible the assembly coder is assuming RBP is a frame pointer? That
would imply for gcc/clang the correct answer would be to have compiler flags
force frame pointer usage?
Assuming -O 0 does something seems like we are matching an implementation at a
given point in time. I'd rather force the frame pointer usage (that is optional
in the ABI) if that fixes the RBP usage assumption. I guess the other option
would be to have different assembler if the compiler is using frame pointers or
not. and I don't think we have that concept.
Given this is the common frame pointer pattern:
pushq %rbp
movq%rsp, %rbp
...
popq%rbp
retq
It follows the calling convention rules even if the frame pointer is not in
general use. Thus it only seems like you would hit issues when you move the
stack around.
Thanks,
Andrew Fish
PS Xcode clang always emits the frame pointer.
> this function would modify rbp value because it treat rbp as "stack base
> address ".
>
> 816 MigrateMemoryPages (Private, TRUE);
>
> // Private pointer point to other address, so this function would get a
> NULL pointer that result in segment fault
>
> I think we can turn off optimization options like this.
>
> 1. modify EmulatorPkg.dsc
>
> MdeModulePkg/Core/Pei/PeiMain.inf {
>
> GCC:*_*_*_CC_FLAGS = -O0
> }
>
> Reference GCC Manual description:
>
> -O also turns on -fomit-frame-pointer on machines where doing so does
> not interfere with debugging.
>
>
>
> 在 2018/11/18 下午5:27, Jordan Justen 写道:
>> On 2018-11-17 20:51:11, Liu Yu wrote:
>>> OS: Ubuntu
>>>
>>> Toolchain:GCC48
>> I don't have gcc-4.8, so I couldn't reproduce the issue, but I wonder
>> if this branch can fix the issue for you?
>>
>> https://github.com/jljusten/edk2/tree/emulator-temp-ram
>>
>> You can fetch this branch locally to a branch named `test` with a
>> command like this:
>>
>> $ git fetch --no-tags https://github.com/jljusten/edk2.git
>> emulator-temp-ram:test
>>
>> Then checkout the `test` branch to try it.
>>
>> First, there is some patches to cleanup Sec, but then I added a patch:
>>
>> 53a432e149 "EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration
>> function"
>>
>> Which I hope might help in your case.
>>
>> -Jordan
>>
>>> Issue Description :
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>>at
>>> /home/pedroa/workspace/orign/edkcrb/MdeModulePkg/Core/Pei/Memory/MemoryServices.c:129
>>> 129 Private->MemoryPages.Size = (UINTN)
>>> (Private->HobList.HandoffInformationTable->EfiMemoryTop -
>>>
>>>
>>> if the GCC optimization option is used not -O0 so the "rbp" register will
>>> be used as "general register"
>>>
>>> in the SecTemporaryRamSupport function as below, this function will modify
>>> the rbp (as general register not stack base address pointer)value that
>>> result in program crash.
>>>
>>> ASM_PFX(SecTemporaryRamSupport):
>>> // Adjust callers %rbp to account for stack move
>>> subq%rdx, %rbp // Calc offset of %rbp in Temp Memory
>>> addq%r8, %rbp // add in permanent base to offset
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TimerLib - usable library on X64?
Ryszard, The different libraries mix timers, and TSC (for x86). For some of the timer libs there may be some PCD settings that need to get mapped to your platform. You can look in the timer libs INF to see what it depends on. PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf [Pcd] gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciBusNumber ## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciDeviceNumber ## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciFunctionNumber## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciEnableRegisterOffset ## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoBarEnableMask## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPciBarRegisterOffset ## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPortBaseAddress ## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiPm1TmrOffset ## CONSUMES gPcAtChipsetPkgTokenSpaceGuid.PcdAcpiIoPortBaseAddressMask ## CONSUMES Thanks, Andrew Fish > On Nov 6, 2018, at 6:13 AM, Knop, Ryszard wrote: > > Hi everyone, > I'm trying to use TimerLib to precisely measure time elapsed between specific > functions, and I'm having some issues trying to get it to work. On X64 > platforms all I get is (depending on the TimerLib impl I use) either zeroes > from QueryPerformanceCounter (QueryPerformanceCounterProperties returns > zeroes for all the counters, except the frequency which is always reported as > 100Hz), or the platform hangs. I've tried a few TimerLib implementations and > I'm a bit out of ideas by now. Am I doing something wrong in the code itself, > or is there any concrete implementation that is known to work well? > > Sources I'm using: > https://gist.github.com/DragoonAethis/7df6d8fb35c4f1932ec42bacbcbf73a8 > > Thanks, Richard. > > > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII > Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP > 957-07-52-316 | Kapital zakladowy 200.000 PLN. > > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i > moze zawierac informacje poufne. W razie przypadkowego otrzymania tej > wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; > jakiekolwiek > przegladanie lub rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). If you are not the intended recipient, > please contact the sender and delete all copies; any review or distribution by > others is strictly prohibited. > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Building EmulatorPkg and EDK2 project issue.
> On Nov 3, 2018, at 1:55 PM, Prem Kumar wrote:
>
> Hi Andrew,
> Thanks for your explanation.
>
> After building for x64 I could see below error.
>
> C:\UEFIWorkspace\edk2-master_2018_Latest\Build\EmulatorX64\DEBUG_VS2015x86\X64>WinHost.exe
>
> EDK II WIN Host Emulation Environment from http://www.tianocore.org/edk2/
> <http://www.tianocore.org/edk2/>
> BootMode 0x00
> OS Emulator passing in 128 KB of temp RAM at 0x65e7 to SEC
> ERROR : Can not open Firmware Device File ../FV/FV_RECOVERY.fd (0xE).
> Exiting.
>
>
> I've searched for FV_RECOVERY.fd in entire project and found no such file
> generated after built.
>
Prem,
The FD (Flash Device) image should be constructed by the build, and end up in
the generated Build directory. The start of the path is the target name, and
then a directory that represents some of the flags to the build command.
So the FD should live in: Build\EmulatorX64\DEBUG_VS2015x86\FV\FV_RECOVERY.fd.
If it is not present it would seem like your build failed? Did you get error
messages at the end of the build?
This is the fix for the Bugzilla and it does not seem to relate to your
failure.
/Volumes/Case/UDK2018(vUDK2018)>git show
f4eaaf1a6d50c761e2af9a6dd0976fb8a3bd3c08
commit f4eaaf1a6d50c761e2af9a6dd0976fb8a3bd3c08
Author: Ruiyu Ni
Date: Fri Aug 31 16:55:36 2018 +0800
Emulator/Win: Fix build failure using VS2015x86 or old WinSDK
When build with WinSDK <= Win10 TH2, the terminal over CMD.exe
doesn't work. Because Win10 later than TH2 starts to support VT
terminal.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni
Cc: Michael D Kinney
Reviewed-by: Hao A Wu
diff --git a/EmulatorPkg/Win/Host/WinHost.c b/EmulatorPkg/Win/Host/WinHost.c
index 9b98d5330f..65e8960eff 100644
--- a/EmulatorPkg/Win/Host/WinHost.c
+++ b/EmulatorPkg/Win/Host/WinHost.c
@@ -673,7 +673,7 @@ Returns:
// Transfer control to the SEC Core
//
SwitchStack (
-(SWITCH_STACK_ENTRY_POINT)SecCoreEntryPoint,
+(SWITCH_STACK_ENTRY_POINT)(UINTN)SecCoreEntryPoint,
SecCoreData,
GetThunkPpiList (),
TopOfStack
diff --git a/EmulatorPkg/Win/Host/WinThunk.c b/EmulatorPkg/Win/Host/WinThunk.c
index 306fe75ecd..6007db73b5 100644
--- a/EmulatorPkg/Win/Host/WinThunk.c
+++ b/EmulatorPkg/Win/Host/WinThunk.c
@@ -71,15 +71,23 @@ SecConfigStdIn (
//
// Disable buffer (line input), echo, mouse, window
//
-Success = SetConsoleMode (
-GetStdHandle (STD_INPUT_HANDLE),
-Mode | ENABLE_VIRTUAL_TERMINAL_INPUT & ~(ENABLE_LINE_INPUT |
ENABLE_ECHO_INPUT | ENABLE_MOUSE_INPUT | ENABLE_WINDOW_INPUT)
-);
- }
- if (Success) {
+Mode &= ~(ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT | ENABLE_MOUSE_INPUT |
ENABLE_WINDOW_INPUT);
+
+#if defined(NTDDI_VERSION) && defined (NTDDI_WIN10_TH2) && (NTDDI_VERSION >
NTDDI_WIN10_TH2)
//
-// Enable terminal mode
+// Enable virtual terminal input for Win10 above TH2
//
+Mode |= ENABLE_VIRTUAL_TERMINAL_INPUT;
+#endif
+
+Success = SetConsoleMode (GetStdHandle (STD_INPUT_HANDLE), Mode);
+ }
+
+#if defined(NTDDI_VERSION) && defined (NTDDI_WIN10_TH2) && (NTDDI_VERSION >
NTDDI_WIN10_TH2)
+ //
+ // Enable terminal mode for Win10 above TH2
+ //
+ if (Success) {
Success = GetConsoleMode (GetStdHandle (STD_OUTPUT_HANDLE), );
if (Success) {
Success = SetConsoleMode (
@@ -88,6 +96,7 @@ SecConfigStdIn (
);
}
}
+#endif
return Success ? EFI_SUCCESS : EFI_DEVICE_ERROR;
}
Thanks,
Andrew Fish
> --
> Thanks & Regards,
> Prem.
>
>
>
> On Sun, Nov 4, 2018 at 1:56 AM Andrew Fish <mailto:af...@apple.com>> wrote:
> Prem,
>
> I've not run the emulator on Windows in a very very long time. But lets take
> a look at your error message.
>
> /Volumes/Case/UDK2018(vUDK2018)>git grep "Could not allocate
> PeiServicesTablePage"
> EmulatorPkg/Unix/Host/Host.c:508: printf ("MapFd0(): Could not allocate
> PeiServicesTablePage @ %lx\n", (long unsigned int)EmuMagicPage);
>
> That seems to point to PcdPeiServicesTablePage
> /Volumes/Case/UDK2018(vUDK2018)>git grep PcdPeiServicesTablePage -- *.dec
> EmulatorPkg/EmulatorPkg.dec:73:
> gEmulatorPkgTokenSpaceGuid.PcdPeiServicesTablePage|0x100300|UINT64|0x101b
>
> Which has a default value of 0x100300. But since you built for IA32 it
> gets truncated to 0x0300
>
> Do you need 32-bit IA32? Can do a 64-bit build and use X64. Something like:
>
> build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -D WIN_SEC_BUILD -a X64 -m
> EmulatorPkg/Win/Host/WinHost.inf
>
> It looks like that is hard coded address that needs to get allocated in the
> emulator, a
Re: [edk2] Building EmulatorPkg and EDK2 project issue.
Prem,
I've not run the emulator on Windows in a very very long time. But lets take a
look at your error message.
/Volumes/Case/UDK2018(vUDK2018)>git grep "Could not allocate
PeiServicesTablePage"
EmulatorPkg/Unix/Host/Host.c:508: printf ("MapFd0(): Could not allocate
PeiServicesTablePage @ %lx\n", (long unsigned int)EmuMagicPage);
That seems to point to PcdPeiServicesTablePage
/Volumes/Case/UDK2018(vUDK2018)>git grep PcdPeiServicesTablePage -- *.dec
EmulatorPkg/EmulatorPkg.dec:73:
gEmulatorPkgTokenSpaceGuid.PcdPeiServicesTablePage|0x100300|UINT64|0x101b
Which has a default value of 0x100300. But since you built for IA32 it gets
truncated to 0x0300
Do you need 32-bit IA32? Can do a 64-bit build and use X64. Something like:
build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -D WIN_SEC_BUILD -a X64 -m
EmulatorPkg/Win/Host/WinHost.inf
It looks like that is hard coded address that needs to get allocated in the
emulator, and in your case that allocation is failing.
Thanks,
Andrew Fish
PS I'm not sure the printf is correct: printf ("MapFd0(): Could not
allocate PeiServicesTablePage @ %lx\n", (long unsigned int)EmuMagicPage);
Given the width of long is different on different platforms. UINT64 uses long
long to make sure things are 64-bits. Not to mention EmuMagicPage is a pointer,
not an long unsigned int.
> On Nov 3, 2018, at 12:26 PM, Prem Kumar wrote:
>
> Hi Andrew,
> Thanks for your reply.
>
> Below is the error when trying to launch Emulator after successful build,
>
> 1.Launching Emulator using below command:
> C:\UEFIWorkspace\edk2-master_2018_Latest>cd
> Build\EmulatorIA32\DEBUG_VS2015x86\IA32\ && WinHost.exe
>
> EDK II WIN Host Emulation Environment from http://www.tianocore.org/edk2/
> <http://www.tianocore.org/edk2/>
> BootMode 0x00
> OS Emulator passing in 128 KB of temp RAM at 0x0440 to SEC
> ERROR : Could not allocate PeiServicesTablePage @ 0300
>
> 2. Launching WinHose.exe directly:
> C:\UEFIWorkspace\edk2-master_2018_Latest\Build\EmulatorIA32\DEBUG_VS2015x86\IA32>WinHost.exe
>
> EDK II WIN Host Emulation Environment from http://www.tianocore.org/edk2/
> <http://www.tianocore.org/edk2/>
> BootMode 0x00
> OS Emulator passing in 128 KB of temp RAM at 0x04ab to SEC
> ERROR : Could not allocate PeiServicesTablePage @ 0300
>
>
>
> --
> Regards,
> Prem.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Building EmulatorPkg and EDK2 project issue.
Prem, Looks like the mailing list ate your attachment. What error did you see? Can you copy the text into an email? Thanks, Andrew Fish > On Nov 3, 2018, at 1:42 AM, Prem Kumar wrote: > > Hi All, > Any comments for this to proceed further. > > -- > Thanks & Regards, > Prem. > > On Wed, Oct 31, 2018 at 5:48 PM Prem Kumar wrote: > >> Hi Liming, >> Thanks for quick response and details, >> >> EmulatorPkg\Win >> Above folder was not present in UDK2018. But available in EDK2 master >> >> When I used below command I'm able to build success, >> build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -D WIN_SEC_BUILD -a IA32 >> -m EmulatorPkg/Win/Host/WinHost.inf >> >> But when i try to launch I'm facing below error, >> [image: image.png] >> >> >> >> -- >> Thanks, >> Prem. >> >> On Wed, Oct 31, 2018 at 5:28 AM Gao, Liming wrote: >> >>> For emulator, please type below command and see what's happen. >>> >>> build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -D WIN_SEC_BUILD -a >>> IA32 -m EmulatorPkg/Win/Host/WinHost.inf >>> >>>> -Original Message- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>> Prem Kumar >>>> Sent: Tuesday, October 30, 2018 10:04 PM >>>> To: edk2-devel@lists.01.org >>>> Subject: [edk2] Building EmulatorPkg and EDK2 project issue. >>>> >>>> Hi All, >>>> Below are the issue i'm currently facing, >>>> >>>> - EmulatorPkg: >>>> >>>> o Building of EmulatorPkg using below command >>>> >>>> § build -p EmulatorPkg\EmulatorPkg.dsc -t VS2015x86 -D WIN_SEC_BUILD -a >>>> IA32 >>>> >>>> o But when I try to launch Emulator using below command, it failed. I >>>> searched for WinHost.exe file, and it is not present in Build folder >>> also. >>>> >>>> § cd Build\EmulatorIA32\DEBUG_VS2015x86\IA32\ && WinHost.exe >>>> >>>> - Building EDK2 project for ARM using LLVM >>>> >>>> o What are the steps/changes need to do in-order to build EDK2 project >>>> for ARM+LLVM configuration. >>>> >>>> >>>> Kindly provide any comments. Any pointer is helpful. >>>> >>>> *Note:* >>>> >>>> Trying to build in Windows environment. Build and launch of Nt32Pkg is >>>> successful. >>>> >>>> -- >>>> Regards, >>>> Prem. >>>> ___ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >> > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/1] MdePkg/Base.h: Implement BASE_CR() via OFFSET_OF().
+1 Reviewed-by: Andrew Fish > On Nov 2, 2018, at 10:28 AM, Kinney, Michael D > wrote: > > Marvin, > > Thanks. This is a good improvement. > > Reviewed-by: Michael D Kinney > > Mike > >> -Original Message- >> From: Gao, Liming >> Sent: Thursday, November 1, 2018 6:33 PM >> To: marvin.haeu...@outlook.com; edk2-devel@lists.01.org >> Cc: Kinney, Michael D >> Subject: RE: [PATCH 1/1] MdePkg/Base.h: Implement >> BASE_CR() via OFFSET_OF(). >> >> The change is good. Reviewed-by: Liming Gao >> >> >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel- >> boun...@lists.01.org] On Behalf Of >>> Marvin H?user >>> Sent: Thursday, November 01, 2018 4:09 AM >>> To: edk2-devel@lists.01.org >>> Cc: Kinney, Michael D ; >> Gao, Liming >>> >>> Subject: [edk2] [PATCH 1/1] MdePkg/Base.h: Implement >> BASE_CR() via >>> OFFSET_OF(). >>> >>> Replace the current NULL pointer dereference to >> retrieve Field's >>> offset with a call to OFFSET_OF(). This is implemented >> via >>> __builtin_offsetof for GCC and Clang, which eliminates >> UB caught by >>> Clang UndefinedBehaviorSanitizer. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Marvin Haeuser >> >>> --- >>> MdePkg/Include/Base.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/MdePkg/Include/Base.h >> b/MdePkg/Include/Base.h >>> index 523192fd79fc..bc877d8125a5 100644 >>> --- a/MdePkg/Include/Base.h >>> +++ b/MdePkg/Include/Base.h >>> @@ -869,7 +869,7 @@ typedef UINTN *BASE_LIST; >>> @return A pointer to the structure from one of it's >> elements. >>> >>> **/ >>> -#define BASE_CR(Record, TYPE, Field) ((TYPE *) >> ((CHAR8 *) (Record) - >>> (CHAR8 *) &(((TYPE *) 0)->Field))) >>> +#define BASE_CR(Record, TYPE, Field) ((TYPE *) >> ((CHAR8 *) (Record) - >>> OFFSET_OF (TYPE, Field))) >>> >>> /** >>> Rounds a value up to the next boundary using a >> specified alignment. >>> -- >>> 2.19.1.windows.1 >>> >>> ___ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Reminder for deleting 3 network drivers in MdeModulePkg
> On Nov 1, 2018, at 2:01 AM, Leif Lindholm wrote: > > On Thu, Nov 01, 2018 at 06:01:31AM +, Gao, Liming wrote: >> Leif: >> If all Stewards agree this change to remove MdeModulePkg >> Tcp4Dxe/UefiPxeBcDxe/IScsiDxe, we will try to include it in >> edk2-stable201811 stable tag. >> >> Andrew and Mike: >> Do you agree this change to happen in near edk2-stable201811 >> stable tag? > > No no no. I was suggesting deleting them immediately _after_ the > stable tag (if review is complete by then). > Sounds good to me too. Thanks, Andrew Fish > Regards, > > Leif > >> >> Thanks >> Liming >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif >>> Lindholm >>> Sent: Wednesday, October 31, 2018 6:50 PM >>> To: Fu, Siyuan >>> Cc: edk2-devel@lists.01.org >>> Subject: Re: [edk2] Reminder for deleting 3 network drivers in >>> MdeModulePkg >>> >>> Hi Fu Siyuan, >>> >>> That is fine too. >>> But I expect the change to be one to go in the week after a stable tag >>> has been made. >>> >>> (My own philosophy is that one can be quite aggressive with removals, >>> because if it turns out to have been a bad idea, git revert can >>> quickly restore the tree to the state it was.) >>> >>> Best Regards, >>> >>> Leif >>> >>> On Wed, Oct 31, 2018 at 02:58:47AM +, Fu, Siyuan wrote: >>>> Hi, Leif >>>> >>>> Just notice that you are saying edk2-stable201811 tag. >>>> >>>> We need more time to collect community/marketing feedback on >>>> deleting these driver, so it may won't be able to catch the stable >>>> tag in next month. >>>> >>>> BestRegards >>>> Fu Siyuan >>>> >>>> >>>>> -Original Message- >>>>> From: Fu, Siyuan >>>>> Sent: Wednesday, October 31, 2018 8:49 AM >>>>> To: Leif Lindholm >>>>> Cc: edk2-devel@lists.01.org >>>>> Subject: RE: [edk2] Reminder for deleting 3 network drivers in >>>>> MdeModulePkg >>>>> >>>>> Hi, Leif >>>>> >>>>> I think checking the branch is a little better than the tag, because we >>>>> may still have critical bug fixes after the official release. >>>>> >>>>> While any of them are not recommended, always using the NetworkPkg >>> version >>>>> driver is the best choice. >>>>> >>>>> I will modify the edk2 network wiki page for an updated sample DSC/FDF >>>>> section, if this patch could pass review w/o objection. >>>>> https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg- >>> Getting- >>>>> Started-Guide >>>>> >>>>> >>>>> BestRegards >>>>> Fu Siyuan >>>>> >>>>> >>>>>> -Original Message- >>>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >>> Of >>>>>> Leif Lindholm >>>>>> Sent: Tuesday, October 30, 2018 6:47 PM >>>>>> To: Fu, Siyuan >>>>>> Cc: edk2-devel@lists.01.org >>>>>> Subject: Re: [edk2] Reminder for deleting 3 network drivers in >>>>>> MdeModulePkg >>>>>> >>>>>> Hi Fu Siyan, >>>>>> >>>>>> On Tue, Oct 30, 2018 at 08:11:52AM +, Fu, Siyuan wrote: >>>>>>> People who want to continue use these deleted drivers could go to >>>>>>> edk2/UDK2018 branch to get them, but it's *highly not recommended*. >>>>>> >>>>>> They should also be able to use edk2-stable201811, right? >>>>>> >>>>>>> *If you have any opposition on deleting these drivers, please let me >>>>>>> know before this weekend, thanks.* >>>>>> >>>>>> I am all for this change. The diffstat is very nice :) >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Leif >>>>>> ___ >>>>>> edk2-devel mailing list >>>>>> edk2-devel@lists.01.org >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>> ___ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] IntelFsp2Pkg: FSP should not override IDT
> On Oct 23, 2018, at 2:33 AM, Chasel, Chiu wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1265
>
> FSP should not override IDT table when it is initialized
> by boot loader. IDT should be re-initialized in FSP only
> when it is invalid.
> To mitigate temporary memory usage a PCD
> PcdFspMaxInterruptSupported created for platform to decide
> how many interrupts the FSP IDT table can support.
>
> Test: Verified on internal platform and boots successfully.
>
> Cc: Jiewen Yao
> Cc: Desimone Nathaniel L
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf | 1 +
> IntelFsp2Pkg/FspSecCore/SecMain.c | 24 +++-
> IntelFsp2Pkg/FspSecCore/SecMain.h | 6 ++
> IntelFsp2Pkg/IntelFsp2Pkg.dec | 4
> 4 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf
> b/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf
> index c61af10b8a..dafe6f5993 100644
> --- a/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf
> +++ b/IntelFsp2Pkg/FspSecCore/FspSecCoreM.inf
> @@ -62,6 +62,7 @@
> gIntelFsp2PkgTokenSpaceGuid.PcdTemporaryRamSize ## CONSUMES
> gIntelFsp2PkgTokenSpaceGuid.PcdFspTemporaryRamSize ## CONSUMES
> gIntelFsp2PkgTokenSpaceGuid.PcdFspHeapSizePercentage ## CONSUMES
> + gIntelFsp2PkgTokenSpaceGuid.PcdFspMaxInterruptSupported ## CONSUMES
>
> [Ppis]
> gEfiTemporaryRamSupportPpiGuid ## PRODUCES
> diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.c
> b/IntelFsp2Pkg/FspSecCore/SecMain.c
> index 37fd4dfdeb..ddbfc4fcdf 100644
> --- a/IntelFsp2Pkg/FspSecCore/SecMain.c
> +++ b/IntelFsp2Pkg/FspSecCore/SecMain.c
> @@ -70,6 +70,7 @@ SecStartup (
> UINT32 Index;
> FSP_GLOBAL_DATA PeiFspData;
> UINT64 ExceptionHandler;
> + UINTN IdtSize;
>
> //
> // Process all libraries constructor function linked to SecCore.
> @@ -98,13 +99,26 @@ SecStartup (
> // | |
> // |---|> TempRamBase
> IdtTableInStack.PeiService = NULL;
> - ExceptionHandler = FspGetExceptionHandler(mIdtEntryTemplate);
> - for (Index = 0; Index < SEC_IDT_ENTRY_COUNT; Index ++) {
> -CopyMem ((VOID*)[Index],
> (VOID*), sizeof (UINT64));
> + AsmReadIdtr ();
> + if ((IdtDescriptor.Base == 0) && (IdtDescriptor.Limit == 0x)) {
Are these architectural value at reset?
Thanks,
Andrew Fish
> +ExceptionHandler = FspGetExceptionHandler(mIdtEntryTemplate);
> +for (Index = 0; Index < FixedPcdGet8(PcdFspMaxInterruptSupported); Index
> ++) {
> + CopyMem ((VOID*)[Index],
> (VOID*), sizeof (UINT64));
> +}
> +IdtSize = sizeof (IdtTableInStack.IdtTable);
> + } else {
> +if (IdtDescriptor.Limit + 1 > sizeof (IdtTableInStack.IdtTable)) {
> + //
> + // ERROR: IDT table size from boot loader is larger than FSP can
> support, DeadLoop here!
> + //
> + CpuDeadLoop();
> +} else {
> + IdtSize = IdtDescriptor.Limit + 1;
> +}
> +CopyMem ((VOID *) (UINTN) , (VOID *)
> IdtDescriptor.Base, IdtSize);
> }
> -
> IdtDescriptor.Base = (UINTN)
> - IdtDescriptor.Limit = (UINT16)(sizeof (IdtTableInStack.IdtTable) - 1);
> + IdtDescriptor.Limit = (UINT16)(IdtSize - 1);
>
> AsmWriteIdtr ();
>
> diff --git a/IntelFsp2Pkg/FspSecCore/SecMain.h
> b/IntelFsp2Pkg/FspSecCore/SecMain.h
> index 291bc5ca5c..19ac2fbfc1 100644
> --- a/IntelFsp2Pkg/FspSecCore/SecMain.h
> +++ b/IntelFsp2Pkg/FspSecCore/SecMain.h
> @@ -1,6 +1,6 @@
> /** @file
>
> - Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> + Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> @@ -29,8 +29,6 @@
> #include
> #include
>
> -#define SEC_IDT_ENTRY_COUNT34
> -
> typedef VOID (*PEI_CORE_ENTRY) ( \
> IN CONST EFI_SEC_PEI_HAND_OFF*SecCoreData, \
> IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList \
> @@ -38,7 +36,7 @@ typedef VOID (*PEI_CORE_ENTRY) ( \
>
> typedef struct _SEC_IDT_TABLE {
> EFI_PEI_SERVICES *PeiService;
> - UINT64IdtTable[SEC_IDT_ENTRY_COUNT];
> + UINT64IdtTable[FixedPcdGet8 (PcdFspMaxInterruptSupported)];
> } SEC_IDT_TABLE;
>
> /**
> diff --git a/IntelFsp2Pkg/IntelFsp2Pkg.dec b/IntelFsp2Pkg/Inte
Re: [edk2] Community Discussion: General Code and Commit message standards
> On Oct 18, 2018, at 9:43 AM, stephano wrote: > > On 10/18/2018 4:49 PM, Andrew Fish wrote: >>> On Oct 18, 2018, at 7:22 AM, Carsey, Jaben wrote: >>> >>> I would like to know when a patch fixes a BZ. Subject/body I have less >>> strong opinion about. >>> >> +1 >> Thanks, >> Andrew Fish > This is always a point of contention with mailing list style patch-workflows > in my experience. I know some groups have had success with patchwork, but I > am hoping whatever workflow we choose will support this idea. > S, What I've done in the past on a branch based github PR flow is have a naming convention for the branch. For example eng/PR--. Then we have a git hook that looks at the branch name and if it sees a Bugzilla number it inserts the Bugzilla reference in the bottom of every commit message for that branch. The CI also played tricks with the branch names and could update the bug tracker with CI results, and the process status of the bug. Thanks, Andrew Fish > I'll add this to our list of features for our upcoming discussions. Thanks > guys! > > --S > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Community Discussion: General Code and Commit message standards
> On Oct 18, 2018, at 7:22 AM, Carsey, Jaben wrote: > > I would like to know when a patch fixes a BZ. Subject/body I have less strong > opinion about. > +1 Thanks, Andrew Fish >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> stephano >> Sent: Thursday, October 18, 2018 2:13 AM >> To: edk2-devel@lists.01.org >> Subject: [edk2] Community Discussion: General Code and Commit message >> standards >> >> This discussion was tabled as it will probably be its own meeting rather >> than part of our general discussions this month. >> >> Recently on the list Laszlo and Star agreed that we should be adding the >> CVE to the subject of any patch that fixes a CVE. I will be documenting >> this in the wiki as well as Contributions.txt. >> >> This thread is meant as a chance to begin discussions before we meet to >> formally review the topic. It will give folks a chance to research any >> known pain points or suggested solutions. >> >> Cheers, >> Stephano >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] FatBinPkg: Remove FatBinPkg and modify document
> On Oct 17, 2018, at 6:08 PM, Ard Biesheuvel wrote: > > On 17 October 2018 at 19:18, Laszlo Ersek wrote: >> On 10/16/18 09:11, shenglei wrote: >>> Remove FatBinPkg and modify Maintainers.txt. >>> https://bugzilla.tianocore.org/show_bug.cgi?id=1105 >>> >>> Cc: Ruiyu Ni >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Shenglei Zhang >>> --- >>> FatBinPkg/EnhancedFatDxe/AArch64/Fat.efi | Bin 26752 -> 0 bytes >>> FatBinPkg/EnhancedFatDxe/Arm/Fat.efi | Bin 17152 -> 0 bytes >>> FatBinPkg/EnhancedFatDxe/Ebc/Fat.efi | Bin 79136 -> 0 bytes >>> FatBinPkg/EnhancedFatDxe/Fat.inf | 48 --- >>> FatBinPkg/EnhancedFatDxe/Ia32/Fat.efi| Bin 21088 -> 0 bytes >>> FatBinPkg/EnhancedFatDxe/Ipf/Fat.efi | Bin 154400 -> 0 bytes >>> FatBinPkg/EnhancedFatDxe/X64/Fat.efi | Bin 28576 -> 0 bytes >>> FatBinPkg/FatBinPkg.dec | 20 -- >>> FatBinPkg/ReadMe.txt | 9 - >>> Maintainers.txt | 2 +- >>> 10 files changed, 1 insertion(+), 78 deletions(-) >>> delete mode 100644 FatBinPkg/EnhancedFatDxe/AArch64/Fat.efi >>> delete mode 100755 FatBinPkg/EnhancedFatDxe/Arm/Fat.efi >>> delete mode 100644 FatBinPkg/EnhancedFatDxe/Ebc/Fat.efi >>> delete mode 100644 FatBinPkg/EnhancedFatDxe/Fat.inf >>> delete mode 100644 FatBinPkg/EnhancedFatDxe/Ia32/Fat.efi >>> delete mode 100644 FatBinPkg/EnhancedFatDxe/Ipf/Fat.efi >>> delete mode 100644 FatBinPkg/EnhancedFatDxe/X64/Fat.efi >>> delete mode 100644 FatBinPkg/FatBinPkg.dec >>> delete mode 100644 FatBinPkg/ReadMe.txt >> >> I'm happy about this patch. >> >> Reviewed-by: Laszlo Ersek >> > > Reviewed-by: Ard Biesheuvel Reviewed-by: Andrew Fish ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools/ build broken due to unreviewed patch - PLEASE FIX
> On Oct 13, 2018, at 5:18 AM, Ard Biesheuvel wrote: > > On 13 October 2018 at 11:23, Gao, Liming wrote: >> Ard: >> I know the failure reason. . edksetup.sh must be called in edk2 before >> enter BaseTools with make. edksetup.sh is used to detect the python3 and set >> PYTHON3 env. This env is used in GNUmakefile. >> >> I don't aware this change before. Because we usually call edksetup.sh, then >> make BaseTools. We will try to find the way to handle it. >> > > Thanks for diagnosing that. As Leif points out, this deviates from the > instructions on the wiki. It also deviates from the build script I use > in my CI environment, hence the breakage. > > Unfortunately, our CI environment is based on Debian Stretch, which > provides Python 3.5.3 only not Python 3.6 or later. I will work with > our infrastructure team to find out if we can support Python 3.6 as > well, but it will probably take time. > > What is the reason we need 3.6 or later? > All the macOS based builds are broken too. Python 2.7.* comes with macOS. The instructions are broken for macOS as you never had to install Python before. I'm not able to install an alternate version of Python in our internal CI infrastructure (You build the OS with tools from the OS). This will likely force me to have to check in a version of Python 3.6 into the edk2 tree to keep the build working, or fork off an older version of the build system that works with Python 2.7.*. What problem are we solving by forcing everyone to be on Python 3.6 or later? I understand on Widows you have to install Python, but a lot of the Unix installs you can get an older version of Python installed for free. Thanks, Andrew Fish > >>> -Original Message- >>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >>> Sent: Saturday, October 13, 2018 4:46 PM >>> To: Gao, Liming >>> Cc: edk2-devel-01 ; Laszlo Ersek >>> ; Leif Lindholm ; Kinney, >>> Michael D ; Zhu, Yonghong >>> ; stephano.cet...@linux.intel.com >>> Subject: Re: [edk2] BaseTools/ build broken due to unreviewed patch - >>> PLEASE FIX >>> >>> On 13 October 2018 at 10:44, Gao, Liming wrote: >>>> Ard: >>>> I pull the latest edk2 code. I can find RunTests.py in BaseTools/Tests. >>>> The below error message shows RunTests.py is not found. But, >>> this file is in BaseTools/Tests. I also run Make command in BaseTools >>> directory. It can work in my Ubuntu machine. I install Python37. Do >>> you install Python36 or Python37 in your machine? >>>> >>>> Yonghong has sent the mail to notify BaseTools Python3 migration is done. >>>> Python3.6 or the above is required. >>>> >>> >>> I have python3 on my machine, yes. But that does not mean it is the >>> default for everyone. >>> >>> >>>>> -Original Message- >>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>>> Ard Biesheuvel >>>>> Sent: Saturday, October 13, 2018 4:18 PM >>>>> To: edk2-devel-01 ; Gao, Liming >>>>> ; Laszlo Ersek ; Leif >>> Lindholm >>>>> ; Kinney, Michael D >>>>> ; Zhu, Yonghong ; >>>>> stephano.cet...@linux.intel.com >>>>> Subject: [edk2] BaseTools/ build broken due to unreviewed patch - PLEASE >>>>> FIX >>>>> >>>>> Commit ea787b6b55499e8f931201f8f49daaaeb2e4409f >>>>> >>>>> "BaseTools: update Test scripts support python3" >>>>> >>>>> [which has never been sent out for review to the mailing list, as far >>>>> as I can tell] is breaking the BaseTools build >>>>> >>>>> make -C Tests >>>>> make[1]: Entering directory '/home/ard/build/edk2/BaseTools/Tests' >>>>> /bin/sh: 1: RunTests.py: not found >>>>> GNUmakefile:17: recipe for target 'test' failed >>>>> make[1]: *** [test] Error 127 >>>>> make[1]: Leaving directory '/home/ard/build/edk2/BaseTools/Tests' >>>>> GNUmakefile:25: recipe for target 'Tests' failed >>>>> make: *** [Tests] Error 2 >>>>> make: Leaving directory '/home/ard/build/edk2/BaseTools' >>>>> >>>>> I tried reverting that patch alone, but that gives me >>>>> >>>>> make -C Tests >>>>> make[1]: Entering directory '/home/ard/build/edk2/BaseTools/Tests' >>>>> Traceback (most recent call
Re: [edk2] TianoCore Community Meeting Minutes
> On Oct 11, 2018, at 10:43 AM, stephano > wrote: > > Thank you all for a great set of meetings! > > This is an overview of the topics discussed and the tasks that were assigned. > Please feel free to send me any questions or comments. > ... > Improvements to the Build Process > > We would like to gather a list of concrete specific proposals. Nate mentioned > that there will always be some specialized tooling because of the nature of > BIOS. Shawn mentioned that we need to keep in mind that making development > easier for current developers should be a priority over making the processes > easier for newcomers. I will send out emails asking for specific feedback on > some of these topics: > > -Which toolchains are being used, which are validated, and which are known to > create reproducible builds. > -When toolchains are known to be orphaned, should they be archived or simply > removed. > -Could we add some kconfig-like tool that allows introspection into what type > of builds are available. > -How can we better track the code quality of BaseTools and the current build > system on the whole. Should we add a "requires documentation change" flag to > BZ so that it will be easier to compile a list of required doc changes. > Stephano, I'll help start the conversation on the build. 1) Making the process easier for newcomers. a) Getting it to build the 1st time I think we could aspire to a more Unix like flow: git clone ./configure make ovmf make ovmf.run The ./config step would automate resolving dependencies. Things like figuring out what compiler is installed, what extra tools need to be installed etc. It could be interactive? make would build all the build tools, and do what ever local config is required to get the build working. Then build the requested target. make .run is more of an optional step. It could do things like launch Ovmf with your new ROM you just constructed. b) Debugging failures. Better quality error messages. Making the build.log from the build command a default setting(or have an abstracted defined database that can be queried), and add documentation on how to use it. Maybe make the output easier to consume? c) Making changes. That can be a phase 2. 2) Build performance, complexity, and maintainability. I'm about to complain about the build system, but I was around when it was first invented so I'm to blame as much as anyone We have way too much custom Python that is very complex, hard to maintain, and slow. One thing we did better on the EDK was break up the build tools into smaller chunks (maybe too small in some cases) and I always found I could figure things out, but then again all the code was C. Another interesting data point is we added parallel build, via makefiles, to the EDK. When we moved from the EDK to the edk2 we noticed the builds slowed down a lot. I did some profiling on the edk2 build and I noticed 1,000,000 calls to regex (part of that long . sequence on a build of a complex platform). It turns out we have custom Python code that is generating the makefile dependencies so it was scanning all the C code. The other issue I see is build parallelism is controlled from the Python code. It also seems the edk2 build system is not a complete solution and a lot of full platform implementations have shell scripts or batch files, that wrap the calls to build. So I'd like to see a build system: 1) Start with a top level makefile in the root of the tree. 2) Replaces custom batch or shell scripts with makefiles to handle pre and post build tasks. 3) Use a tool to construct a parser for the ekd2 build files (INF, DSC, DEC). Use this data to construct the makefiles and build a database for other build components to use. Chris Roberts has messed around and built an Earley parser using the EBNF in the build documents. There are some problematic issues in the grammar, but some grammar streamlining might make it possible to use tooling to construct a parser vs. writing one from scratch in Python. 4) Move to using the compiler to generate dependencies. gcc/clang support this via -M*. I think it may be a little more complex for NMAKE but there is a /showIncludes compiler flag. 5) Have the build tool terminate after parallel makefile generation 6) Top level makefile can invoke parallel build on generated makefiles. 7) Invoke build tool to generate FVs and FDs from makefile. 8) Invoke custom post processing steps in the makefile. Thanks, Andrew Fish ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TianoCore Community Meeting Minutes
> On Oct 12, 2018, at 11:30 AM, Kinney, Michael D > wrote: > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org >> <mailto:edk2-devel-boun...@lists.01.org>] >> On Behalf Of Leif Lindholm >> Sent: Friday, October 12, 2018 11:06 AM >> To: Laszlo Ersek mailto:ler...@redhat.com>> >> Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> >> Subject: Re: [edk2] TianoCore Community Meeting Minutes >> >> On Fri, Oct 12, 2018 at 06:07:01PM +0200, Laszlo Ersek >> wrote: >>> On 10/12/18 15:27, Leif Lindholm wrote: >>>> On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano >> wrote: >>> >>>>> Switching to Standard C Types >>>>> - >>>>> Both Shawn and Nate mentioned that the current >> system has been in place for >>>>> a long time and some people prefer the current >> setup. I can start an email >>>>> discussion around this issue specifically if anyone >> feels strongly that we >>>>> should be using standard types. >>>> >>>> So, I don't think we made it this far down the agenda >> on the US-EU >>>> call. >>>> >>>> One way would be to simply explicitly permit it, >> possibly with the >>>> constraint that every module needs to pick one and >> stick with it, >>>> unless people object. >>>> >>>> I think we'll want to discuss this in a US-EU call as >> well. >>> >>> I'm playing devil's advocate here -- because, in >> general, I'm a fan of >>> sticking with standard C as much as possible --, but I >> see a big >>> obstacle in the way. >>> >>> That obstacle is "Table 5. Common UEFI Data Types", in >> the UEFI spec. >>> Until a good portion of that table is expressed in >> terms of standard C >>> types as well (expanding upon the current definitions), >> possibly in an >>> edk2-level spec (i.e. not necessarily in the UEFI spec >> itself), I think >>> there's no chance to enable standard C types in edk2 >> *meaningfully*. >>> >>> Because, as soon as you have to call a PI or UEFI >> interface, you'll have >>> to stick with the PI/UEFI spec types anyway. >> >> I don't necessarily see that as an issue. But it is a >> good point that >> it can't just be the codebase changing. >> >> Since we are however extremely specificly not looking to >> change the >> underlying storage types, all it would take would be to >> make a >> 2-column table into a 3-column table in both specs. Or >> just add a >> separate table for the mapping. Then edk2 could adopt the >> "permitted" >> rule as soon as the specs were out. Arguably (because >> we're not >> changing underlying types) we could do it before, but we >> _are_ >> supposed to be the reference implementation, so it would >> be poor form. > > I agree that it would be best if the specs list synonymous > type names. We would have to guarantee in the edk2 implementation > that they types are identical. One potential issue is support > for really old compilers. If we can decide to only support > compilers that fully support the synonymous types, then that > would be clean. Not sure what the ANSI C equivalents are for > INTN/UINTN on all compilers. > Mike, INTN -> intptr_t UINTN -> uintptr_t If I understand correctly the types we are talking about are defined via stdint.h. Thus if we are a freestanding (__STDC_HOSTED__ == 0) project and we did not include stdint.h we would need to define them in the edk2 headers? If the edk2 App/Driver is also including stdint.h we would need some way to avoid conflicts. Likely including stdint.h from ProcessorBind.h in place of defining the values. Thanks, Andrew Fish >> >>>>> Using Git Submodules (like we do with OpenSSL) >>>>> >>>> >>>> We didn't make it here either. What would we use it >> _for_? >>>> I think the openssl case makes a lot of sense, but >> what else? >>> >>> We embed a bunch of other projects (libraries, mainly): >>> - Oniguruma >>> - Brotli >>> - fdt >>> - LZMA SDK >>> - ... >> >> Sure. But do we know that is what was meant? >> >> I certainly recall the "each package should be a >> submodule" idea from >> a (much) earlier conversation, and would like to ensure >> we're not >> resurrecting that. > > Yes. Those other projects was the brief discussion. > Not submodule per package. > >> >> Regards, >> >> Leif >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> >> https://lists.01.org/mailman/listinfo/edk2-devel >> <https://lists.01.org/mailman/listinfo/edk2-devel> > ___ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TianoCore Community Meeting Minutes
> On Oct 12, 2018, at 9:07 AM, Laszlo Ersek wrote: > > On 10/12/18 15:27, Leif Lindholm wrote: >> On Thu, Oct 11, 2018 at 10:43:57AM -0700, stephano wrote: > >>> Switching to Standard C Types >>> - >>> Both Shawn and Nate mentioned that the current system has been in place for >>> a long time and some people prefer the current setup. I can start an email >>> discussion around this issue specifically if anyone feels strongly that we >>> should be using standard types. >> >> So, I don't think we made it this far down the agenda on the US-EU >> call. >> >> One way would be to simply explicitly permit it, possibly with the >> constraint that every module needs to pick one and stick with it, >> unless people object. >> >> I think we'll want to discuss this in a US-EU call as well. > > I'm playing devil's advocate here -- because, in general, I'm a fan of > sticking with standard C as much as possible --, but I see a big > obstacle in the way. > > That obstacle is "Table 5. Common UEFI Data Types", in the UEFI spec. > Until a good portion of that table is expressed in terms of standard C > types as well (expanding upon the current definitions), possibly in an > edk2-level spec (i.e. not necessarily in the UEFI spec itself), I think > there's no chance to enable standard C types in edk2 *meaningfully*. > > Because, as soon as you have to call a PI or UEFI interface, you'll have > to stick with the PI/UEFI spec types anyway. > Lazlo, Given there is also a C ABI for each supported processor architecture in the UEFI spec it should be possible to define the EFI types in terms of C types. The only potential issue is I'm not sure BOOLEAN maps to bool in all cases? https://github.com/tianocore/edk2/blob/master/MdePkg/Include/X64/ProcessorBind.h#L188 So typedef __int64UINT64; or typedef long long INT64; becomes: typedef int64_tINT64; Thus we could move the definition of UINT64, INT64, UINT32, INT32, UINT16, INT16, UINT8, INT8, CHAR, and CHAR16 to Base.h and have ProcessorBind.h just define the C standard types for a given architecture. The tricky part is when there are different answers to the question are you using a standard C lib. Basically the definitions in MdePkg/Include/X64/ProcessorBind.h could conflict with stdint.h. Almost seems like you would need a build flag to control if you use stdint.h. I think the bigger question is what problem are we trying to solve? If some one is programming with uint32_t are they going to expect printf(), memcpy(), etc. We solve that problem today StdLib? I guess we only have an option of the full pedantic C lib (I can't remember if StdLib depends on the shell?), or nothing. Are we trying to define a light weight C lib that works in the firmware code? How much of the C lib do we need to make that useful? Thanks, Andrew Fish PS Speaking of printf() != Print() or DEBUG()... I see a lot of people botching Print() in EFI. It would nice if we could get compiler warnings for miss use. You can add printf warnings to any functing in int my_printf (void *my_object, const char *my_format, ...) __attribute__ ((format (printf, 2, 3))); It would be awesome if we could add edk2_print to at least gcc and clang. Given they are open source projects anything is possible. Not sure how this works on VC++? > >>> Using Git Submodules (like we do with OpenSSL) >>> >> >> We didn't make it here either. What would we use it _for_? >> I think the openssl case makes a lot of sense, but what else? > > We embed a bunch of other projects (libraries, mainly): > - Oniguruma > - Brotli > - fdt > - LZMA SDK > - ... > > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment variable
> On Oct 4, 2018, at 10:07 AM, Laszlo Ersek wrote: > > On 10/03/18 20:17, Carsey, Jaben wrote: >> Pushed. >> c0b1f749ef1304810ed4ea58ded65b7f41d79d3e > > Please give other reviewers a bit more time than ~2 hours, to comment on > the patch. :) > > I think I would have suggested an improvement (or a clarification about) > the commit message. It says: > >>> -Original Message- >>> From: Carsey, Jaben >>> Sent: Wednesday, October 03, 2018 11:15 AM >>> To: 'jim.dai...@dell.com' ; edk2-devel@lists.01.org >>> Subject: RE: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment >>> variable >>> >>> Reviewed-by: Jaben Carsey >>> >>>> -Original Message- >>>> From: jim.dai...@dell.com [mailto:jim.dai...@dell.com] >>>> Sent: Wednesday, October 03, 2018 9:02 AM >>>> To: edk2-devel@lists.01.org >>>> Cc: Carsey, Jaben ; Ni, Ruiyu >>> >>>> Subject: [edk2] [PATCH] ShellPkg: Create a homefilesystem environment >>>> variable >>>> Importance: High >>>> >>>> Create a homefilesystem environment variable whose value is the file >>>> system on which the executing shell is located. For example: "FS14:". > > that the file system in question contains the *shell*. > > So my first question would have been, what if the shell is memory mapped > (from a firmware volume), but the platform doesn't expose firmware > filesystems (FFSs) as EFI simple file system protocol instances? In that > case, the "file system on which the executing shell is located" seems > ill-defined. > Same if the Shell was network booted. Thanks, Andrew Fish >>>> >>>> This eliminates the need for people to have to try and find the "boot" >>>> file system in their startup script. After this change they can simply > > Note, here the commit message refers to the startup script, not the > shell itself. > >>>> execute %homefilesystem% to set the cwd to the root of the file system >>>> where the shell is located. > > I think the commit message here misses a "CD" command. > >>>> >>>> A future enhancement could be to add "homefilesystem" to the list of >>>> predefined, read-only variables listed in the EfiShellSetEnv function of >>>> file ShellProtocol.c > > Is it OK with the UEFI shell spec to define a shell variable called > "homefilesystem"? I seem to remember that edk2-specific options for > standard UEFI shell commands generally start with an underscore, to > avoid clashing with the standard namespace. Does that apply to shell > variables perhaps? (This is mostly for my own education.) > >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>> Signed-off-by: Jim Dailey >>>> --- >>>> ShellPkg/Application/Shell/Shell.c | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/ShellPkg/Application/Shell/Shell.c >>>> b/ShellPkg/Application/Shell/Shell.c >>>> index 3f3bcbb4b0..6185b6ac80 100644 >>>> --- a/ShellPkg/Application/Shell/Shell.c >>>> +++ b/ShellPkg/Application/Shell/Shell.c >>>> @@ -1169,6 +1169,8 @@ LocateStartupScript ( >>>> *TempSpot = CHAR_NULL; >>>> } >>>> >>>> +InternalEfiShellSetEnv(L"homefilesystem", StartupScriptPath, TRUE); >>>> + > > Again, this refers to the startup script, not the shell itself. > >>>> StartupScriptPath = StrnCatGrow (, , >>>> ((FILEPATH_DEVICE_PATH *)FileDevicePath)->PathName, 0); >>>> PathRemoveLastItem (StartupScriptPath); >>>> StartupScriptPath = StrnCatGrow (, , >>>> mStartupScript, 0); >>>> -- >>>> 2.17.0.windows.1 >> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> >> https://lists.01.org/mailman/listinfo/edk2-devel >> <https://lists.01.org/mailman/listinfo/edk2-devel> >> > > Thanks > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] How to correctly sign EFI Firmware Volume?
Petr, Mike Kinney and I just had an interesting conversation that relates to your question. It has to do with the FV being a file system and not really the FLASH layout. In the UEFI PI Spec and edk2 lingo you produce and FD (Flash Device) that consists of a set of FVs. There is not a standard way to discover the FVs in an FD, and this is something that is missing in the PI Spec. On most platforms there are multiple FVs so there should be a defined signing scheme for the entire FD. > On Oct 2, 2018, at 2:12 PM, Petr Vandrovec wrote: > > Hi, > I've sent this ot fw_os_forum, and was redirected here. Sorry if you are > receiving this twice. > > > I'm looking at options how to sign our EFI firmware through some > industry-standard embedded signature option, and signing whole firmware > volume as described in Platform Initialization spec would definitely fit the > bill. > > Unfortunately problem is that I cannot make sense of what should be actually > signed. Chapter 3.2.1.1 of PI_Spec_1_6.pdf says: > > > 3.2.1.1 EFI Signed Firmware Volumes > > There may be one or more headers with a FormatType of value > EFI_FIRMWARE_CONTENTS_SIGNED_GUID. > > A signed firmware volume is a cryptographic signature across the entire > volume. To process the contents and verify the integrity of the volume, the > EFI_FIRMWARE_VOLUME_EXT_ENTRY_GUID_TYPE Data[] shall contain an instance of > WIN_CERTIFICATE_UEFI_GUID where the CertType = EFI_CERT_TYPE_PKCS7_GUID or > EFI_CERT_TYPE_RSA2048_SHA256_GUID. > > > Part about WIN_CERTIFICATE_UEFI_GUID is easy. But what should be signed? > > Text says 'A signed firmware volume is a cryptographic signature across the > entire volume.' - beside that 'firmware volume' is not a signature, what is > 'the entire volume' ? Clearly Data[] entry holding signature cannot be part > of the signature, as otherwise adding signature would invalidate that very > same signature, so it cannot be signature of entire volume from first 16 > reserved bytes in the header to the last byte of the image, but something > else. > > Can someone provide clarification what should be signed? It seems to me like > that intention is to only sign data portion of the volume, from the end of > extended header to the end of volume. But that means that anyone can modify > anything in the header or extended header without breaking signature. > > Are there any examples of signed firmware volumes? Unfortunately there does > not seem to be any code in UDK for this feature. > > > On fw_os_forum I got recommendation to use EFI capsule format for signing. > > Unfortunately I cannot figure out how to make out-of-band signatures work for > firmware volumes in a secure way: firmware module has to be multiple of (at > least) 4KB, and must cover last 16 bytes of ROM (as that is where execution > starts). Then I need to prepend capsule header (or wrapping firmware volume > header) and signature in front of that. Dual SHA1/256 signing with > timestamps takes about 5KB, so there are 3KB of free unsigned space left. > > If I leave those 3KB unsigned, anybody can remove them, shift signed image > down by 3KB, and then have 3KB of unsigned code running at the reset vector > :-( If some one can write your FLASH device they can just skip checking the result of your HASH, no need to shift things about. A really secure boot usually requires a mask ROM that checks the NOR FLASH. Something akin to Intel Boot Guard. Thanks, Andrew Fish > > Or I can do trial signing, figure out how long signature will probably be, > and then extend signed area so that only capsule header and signature > unsigned. That could work, but then I'm not signing firmware volume, but > firmware volume with 3KB of data prepended to it (or firmware volume that is > not multiple of 4KB, if I let our firmware volume to have arbitrary size), > which is not exactly industry standard. > > And even if I do this, as image is dual signed, someone can remove SHA1 > signature, shift rest down, and get about 1KB for the malicious code. > > So for all non-embedded signatures I'm always coming up with standard thing> and require that signed payload ends with end of ROM, while > I'm looking for just , without strings attached. > > > Thanks, > Petr Vandrovec > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg XhciDxe: Set HSEE Bit if SERR# Enable Bit is set
> On Sep 25, 2018, at 8:41 AM, Marcin Wojtas wrote:
>
> Hi Star, Ard
>
> With this patch, my platforms which use NonDiscoverableDevices layer
> for supporting generic Xhci controller, fail in a strange way:
> "Synchronous Exception at 0x3F910AFC
> PC 0x3F910AFC (0x3F908000+0x8AFC) [ 0] DxeCore.dll
> PC 0x3F910AE0 (0x3F908000+0x8AE0) [ 0] DxeCore.dll
> PC 0x3F91BDF4 (0x3F908000+0x00013DF4) [ 0] DxeCore.dll
> PC 0xBF5BD000 (0xBF5AF000+0xE000) [ 1] XhciDxe.dll
> PC 0xAFAFAFAFAFAFAFAF
>
Marcin,
A lot of times 0xAFAFAFAFAFAFAFAF is related to using freed memory.
See this PCD and its use in the DebugLib:
MdePkg.dec:2168:
gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF|UINT8|0x0008
On an X86 system 0xAFAFAFAFAFAFAFAF is a non canonical address and it will
generate a general Protection Fault exception 13 (0xD) on access.
Thanks,
Andrew Fish
> Recursive exception occurred while dumping the CPU state"
>
> I've quickly checked and although XhcSetHsee() is eventually called
> from XhcDriverBindingStart() sequence,
> below line is not even executed:
> XhcSetOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_HSEE);
> The XhcDriverBindingStart() returns EFI_SUCCESS and we get the sync
> abort right afterwards (haven't found exact place yet).
>
> What makes the difference is commenting out in XhcSetHsee():
> // Status = PciIo->Pci.Read (
> //PciIo,
> // EfiPciIoWidthUint16,
> //PCI_COMMAND_OFFSET,
> // sizeof (XhciCmd),
> //
> //);
>
> With that everything keeps working as usual. I'd appreciate any hint.
>
> Best regards.
> Marcin
>
> wt., 11 wrz 2018 o 04:30 Ni, Ruiyu <mailto:ruiyu...@intel.com>> napisał(a):
>>
>> Reviewed-by: Ruiyu Ni
>>
>> Thanks/Ray
>>
>>> -Original Message-
>>> From: Zeng, Star
>>> Sent: Tuesday, September 11, 2018 10:04 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: Zeng, Star ; Ni, Ruiyu ; Wang,
>>> Jian J ; Wang, Fei1
>>> Subject: [PATCH] MdeModulePkg XhciDxe: Set HSEE Bit if SERR# Enable Bit is
>>> set
>>>
>>> When the HSEE in the USBCMD bit is a '1' and the HSE bit in the USBSTS
>>> register is a '1', the xHC shall assert out-of-band error signaling to the
>>> host
>>> and assert the SERR# pin.
>>> To prevent masking any potential issues with SERR, this patch is to set
>>> USBCMD Host System Error Enable(HSEE) Bit if PCICMD SERR# Enable Bit is
>>> set.
>>>
>>> Cc: Ruiyu Ni
>>> Cc: Jian J Wang
>>> Cc: Fei1 Wang
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Star Zeng
>>> ---
>>> MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 41
>>> ++
>>> 1 file changed, 41 insertions(+)
>>>
>>> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> index 5f0736a516b6..89f073e1d83f 100644
>>> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> @@ -587,6 +587,39 @@ XhcIsSysError (
>>> }
>>>
>>> /**
>>> + Set USBCMD Host System Error Enable(HSEE) Bit if PCICMD SERR# Enable
>>> Bit is set.
>>> +
>>> + The USBCMD HSEE Bit will be reset to default 0 by USBCMD Host Controller
>>> Reset(HCRST).
>>> + This function is to set USBCMD HSEE Bit if PCICMD SERR# Enable Bit is
>>> set.
>>> +
>>> + @param XhcThe XHCI Instance.
>>> +
>>> +**/
>>> +VOID
>>> +XhcSetHsee (
>>> + IN USB_XHCI_INSTANCE *Xhc
>>> + )
>>> +{
>>> + EFI_STATUSStatus;
>>> + EFI_PCI_IO_PROTOCOL *PciIo;
>>> + UINT16XhciCmd;
>>> +
>>> + PciIo = Xhc->PciIo;
>>> + Status = PciIo->Pci.Read (
>>> +PciIo,
>>> +EfiPciIoWidthUint16,
>>> +PCI_COMMAND_OFFSET,
>>> +sizeof (XhciCmd),
>>> +
>>> +);
>>> + if (!EFI_ERROR (Status)) {
>>> +if ((XhciCmd & EFI_PCI_COMMAND_SERR) != 0) {
>>> + XhcSetOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_HSEE);
>>> +}
>>> + }
>>> +}
>>> +
>>
Re: [edk2] Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform
with regards to
>>>>> whether
>>>>> what is popped from the stack is actually what we pushed when we
>>>>> entered
>>>>> the function.
>>>>
>>>> OK, thank you for explanation.
>>>> But this call returns back into ResetLib implementation as it should,
>>>> and
>>>> then there is a direct jump to the start of FV.
>>>> Am I doing anything wrong here?
>>>> Then, up to the point of enabling of MMU the stack is OK. But right
>>>> after
>>>> enabling MMU it points at _ModuleEntryPoint end of function in
>>>> DxeCoreEntryPoint.c
>>>> Am I missing anything? Maybe some stack cleanup before jumping to the
>>>> start
>>>> of FV?
>>>
>>> When the MMU is enabled, does the mapping for the stack pages change? That
>>> is,
>>> could the stack now be mapped to different physical page now?
>> Thanks for ideas Bill,
>> No, the mapping stays the same.
>> The issue is only with warm reset, and only on an A72 board.
>> There is another platform on A53 sharing the same code, which has no issues
>> with warm reset.
>> I cannot explain why.
>>>
>>> Instead of showing a stack trace, can you dump the stack pages and compare
>>> the
>>> before and after contents?
>> I can clearly see that before and after contents are different.
>>>
>>> Assuming the same physical memory pages are still being used, then there
>>> could
>>> be a cache flushing problem. What could happen is:
>>>
>>> - some stack memory has been touched recently and is now in the data cache
>>> - changes are made, which are written to the cache, but not yet flushed
>>> out to
>>> RAM
>>> - enabling the MMU causes a full invalidate of the cache
>>>
>>> Now when you look at the stack, you see the earlier contents that were in
>>> RAM
>>> -- the changes previously only written to the cache have been lost.
>>>
>>> Enabling/disabling caches and MMU is always tricky. I can't say for sure,
>>> but
>>> I wouldn't be surprised if there's some subtle bug that causes a flush
>>> operation to be missed and things may just work by coincidence in the cold
>>> start case.
>> I might be missing something preparing for warm reset.
>> Disabling interrupts does not help though.
>> Ard, I switched off all DMA-capable devices, so am just booting into UEFI
>> with no disks or network,
>> disabled interrupts. The issue is here. Any ideas on how to debug it and
>> fix?
> Update: when I add this as an experiment:
> UINTN StackBottom;
>
> __asm__ volatile ("mov %0,SP" : "=r"(StackBottom));
> WriteBackInvalidateDataCacheRange((VOID *)StackBottom,
>PcdGet64(PcdSystemMemorySize) +
>PcdGet64(PcdSystemMemoryBase) - StackBottom);
> then the stack data were not corrupted anymore on the next ArmEnableMmu()
> call,
> and warm reset worked (though unreliably, can throw exception on
> memcpy down the road on UEFI boot; probably because I invalidated only
> the stack area in the experiment).
> Considering that A53 board does not have issues, does this means that
> ArmInvalidateDataCache() implementation is useless for A72?
> Based on this, should the approach be "find all data regions and
> invalidate them using InvalidateDataCacheRange()"?
Vladimir,
We hit an issue like this a while back on x86 and it turned out our sequence
was dependent on the C compiler code generation not touching a specific
register. It might be worth while to disassemble this code and take a look at
the assembler. I'd also point out the __asm__ volatile is a serializing event
to the C memory model so it could change how the C code was optimized. You
could try __asm__ volatile with a no-op instruction to see if it really is the
SP read at this point that fixes the issue. But it is likely the bug will be
more obvious if you look at the assembly.
Thanks,
Andrew Fish
>>>
>>> -Bill
>>>
>>>>>> Then jump to start of FV:
>>>>>>
>>>>>> typedef
>>>>>> VOID
>>>>>>
>>>>>> (EFIAPI *START_FV)(
>>>>>>
>>>>>> VOID
>>>>>>
>>>>>> );
>>>>>> StartOfFv = (START_FV)(UINTN)PcdGet64(PcdFvBaseAddress);
>>>>>> StartOfFv ();
>>>>>>
>>>>>> Now this is what happens on warm reset:
>>>>>> reset -c warm
>>>>>> 1. Until ArmEnableMmu() gets called, everything works as expected.
>>>>>>
>>>>>> Here is the stack right before ArmEnableMmu() is called:
>>>>>>ArmConfigureMmu+0x4f8
>>>>>>InitMmu+0x24
>>>>>>MemoryPeim+0x440
>>>>>>PrePiMain+0x114
>>>>>>PrimaryMain+0x68
>>>>>>CEntryPoint+0xC4
>>>>>>EL2:0x88BC
>>>>>>- End of stack info -
>>>>>>
>>>>>> 2. Here is the stack as soon as Mmu is enabled with ArmEnableMmu() :
>>>>>> ArmConfigureMmu+0x4fc <-- This one is correct, at line 745 in
>>>>>>
>>>>>> ArmConfigureMmu() in ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c
>>>>>> (return EFI_SUCCESS)
>>>>>>
>>>>>> _ModuleEntryPoint+0x24 <-- Wrong. This points directly to
>>>>>>
>>>>>> ASSERT(FALSE); and to CpuDeadLoop() in DxeCoreEntryPoint.c, lines
>>>>>> 59-60.
>>>>>>
>>>>>> El2:0x8E5E8300 <-- Absolutely bogus
>>>>>>
>>>>>> --- End of stack info ---
>>>>>>
>>>>>> So, as soon as ArmEnableMmu() exits, execution jumps directly to
>>>>>> CpuDeadLoop() in DxeCoreEntryPoint of _ModuleEntryPoint().
>>>>>>
>>>>>> Would be grateful for any advice.
>>>>>>
>>>>>> Thank you,
>>>>>> Vladimir
>>>>
>>>> ___
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>> --
>>> =
>>> -Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
>>> wp...@windriver.com | Master of Unix-Fu - Wind River
>>> Systems
>>> =
>>> "I put a dollar in a change machine. Nothing changed." - George Carlin
>>> =
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching foreign arch PE/COFF images
> On Sep 19, 2018, at 1:43 PM, Ard Biesheuvel wrote: > > On 19 September 2018 at 12:35, Andrew Fish <mailto:af...@apple.com>> wrote: >> >> >>> On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel >>> wrote: >>> >>> On 13 September 2018 at 19:20, Kinney, Michael D >>> wrote: >>>> Ard, >>>> >>>> I think there is a fundamental assumption that >>>> the sizeof(UINTN) and size of pointers of >>>> the native CPU are the same as the emulated CPU. >>>> If that is not the case, then I would like to see >>>> more details. Otherwise that is a significant >>>> restriction that needs to be clearly documented. >>>> >>> >>> There is no such assumption. The PE/COFF emulator protocol is an >>> abstract protocol that leaves it fully up to the implementation to >>> decide whether it can support images of machine type X and image type >>> Y. >>> >> >> Ard, >> >> Not knowing the size of UINTN or a pointer was very painful in terms of how >> EBC worked. The compiler was forced to generate code for sizeof vs. >> resolving it at compile time. >> > > Oh, I'm sure - but my point is that whether architecture X can be > emulated on architecture Y and how is a limitation that affects some > implementations of the protocol, but at the abstract level that we > deal with in the core code, it is not a concern. > >>>> Protocols that only allow a single instance need to >>>> clearly document that assumption. >>>> >>> >>> I will remove that restriction. >>> >>>> If we decide to treat EBC as an emulated CPU, then >>>> we would want to support multiple instances of the >>>> protocol. The updates to the DXE Core are a bit >>>> confusing because it has separate handling of EBC >>>> and emulated CPUs. I think it would make the DXE >>>> Core logic simpler and easier to understand if they >>>> were combined. >>>> >>> >>> Yes, excellent idea, and it results in a nice cleanup as well >>> >>>> I asked about the startup case because if we do EBC, >>>> then we may need more services in the protocol because >>>> of the thunk code between native and EBC code. At the >>>> time EBC was originally implemented, we did not have >>>> paging enabled and the EBC interpreter work without >>>> depending on a page fault handler. >>>> >>>> The way the protocol is currently defined, I believe it >>>> fundamentally assumes paging is enabled. If paging is >>>> not enabled, then the current protocol services are not >>>> sufficient for any emulated CPU. Do we want this to work >>>> for paging disabled cases? If not, another assumption >>>> to clearly document. >>>> >>> >>> The paging disabled case is interesting. Does the UEFI spec even >>> permit running in DXE with paging disabled? >> >> Paging is a function of the processor binding in the UEFI spec. It is not >> required for IA32. For X64 you have to have paging enable to enter long >> mode. On other processors you need to turn on paging to control the cache. >> So I guess the no paging is likely more of a i386 issue? >> > > Michael spotted yesterday that RISC-V mandates paging disabled, which > is peculiar in itself. But again, whether a certain implementation of > the protocol relies on paging or not is an implementation detail. > >>> >>> In any case, I will send out a v2 as the basis for further discussion. >>> We can also sit down and discuss it in Vancouver the coming week. >> >> I'd suggest passing an EFI device path to IS_PECOFF_IMAGE_SUPPORTED. At some >> point it might be useful for the emulator to know what device is being >> emulated. >> > > I guess you mean for which device we are loading a driver that relies > on emulation? I guess that makes sense for option ROMs, which is the > primary use case, so yes, I can add that. > >> For bonus points we could check IsPecoffImageSupported() prior to the native >> check. Never say never, some one may want to have emulator run on native >> images for debugging etc. >> > > Peter brought this up as well - in some cases, you may want to sandbox > X86 drivers running on X86 by running them on an emulator. If you > think the overhead of performing this check for each image rather than > only for images that have already been found to be for a foreign > architecture is acceptables then I'm happy to change this. But we can > easily do that later as well. Ard, I vote for the flexibility. Given ImageType is passed into IsImageSupported() in the simple case it is just going to be checking a register (argument) against a constant. Thanks, Andrew Fish ' ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Question] Testing environment regarding SMM driver
> On Sep 21, 2018, at 11:15 AM, poxyran wrote: > > Hello again, > > my question is: is it possible to create a SMM driver that > installs/register a SMI handler (in order to call it from a usermode app > in the OS) and test it in the UEFI Shell poxyran, Does "test it in the UEFI Shell" mean load the SMM driver from the UEFI Shell? The answer to that is no. It should be possible to communicate with SMM code from the UEFI Shell. The difference in testing from the OS is gEfiEventExitBootServicesGuid has fired an a lot of the UEFI Boot Services have been freed when running from an OS. It is also much easier to test the ACPI flows like S3 (suspend to RAM) from an OS. On edk2 systems that support UEFI Secure Boot the UEFI Variable Services make SMM calls, since the variable write code lives in SMM. So when you write a variable at the UEFI Shell there is an SMM call going on. See: https://github.com/tianocore/edk2/blob/UDK2018/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmmRuntimeDxe.inf Thanks, Andrew Fish > or do I need to setup up a > dedicated machine with the SMM stack as described in official EDK II > documentation [1]? > > [1] > > https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt > > On 9/20/2018 6:09 PM, Andrew Fish wrote: >> >>> On Sep 20, 2018, at 7:30 AM, poxyran wrote: >>> >>> Hello, >>> >>> I have a specific question regarding SMM drivers. I'm trying to create a >>> mixed driver as mentioned here >>> http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html >>> and my first try is to create a kind of 'Hello World'. My try is to >>> install a SMI handler and call it from a user-mode app once the OS >>> booted up. The testing aproach mentioned in the blog post is not >>> practical, from my pooint of view. My question is, is it possible to >>> test this kind of drivers from the UEFI shell? or do I need to setup a >>> dedicated machine as mentioned here >> poxyran, >> >> I'm not sure what you are asking? Indirectly referencing a 10,000 word >> article is not very helpful. Feel free to ask a specific question. >> >> Thanks, >> >> Andrew Fish >> >>> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt? >>> >>> BR, >>> poxyran >>> >>> ___ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SPI Flash Corruption
From a design point of view VPD == Vital Product Data. The idea behind VPD was to be a place to store platform unique information generally programmed in the factory. So things like serial number, system UUID, mac address, etc. Usually VPD is programmed in the factory and never updated, thus it is a good idea to put the VPD data in its own FLASH block, and always keep that block locked. It is not uncommon for a FLASH update utility to not update that block when the FD is updated. Thanks, Andrew Fish > On Sep 21, 2018, at 2:26 AM, Wei, David wrote: > > More comments: > > The NV Variable region starts from 0x4. Is there any data remains within > 0x4 - 0x44000 region? Could you dump the flash image and share it with > us, and also file a bug in https://bugzilla.tianocore.org as Jiewen > mentioned? > > It occurred to me that on some old version of Minnowboard Max BIOS, the NV > variable reclaiming process would take a long time ,so that inpatient user > may think the system is stuck and cut the power. This will break the NV > variable region. And in old version of Minnowboard Max BIOS, FTW driver is > not added for PEI stage, so system may not recover if PEI stage depends on NV > variable. > > Newer version of Minnowboard Max BIOS re-configures SPI flash clock to make > the NV Variable reclaiming process more faster, and also adds FTW for PEI > stage. I will check which version of Minnowboard Max BIOS has added this fix. > > Thanks, > David Wei > > Intel SSG/STO/UEFI BIOS > > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, > Jiewen > Sent: Friday, September 21, 2018 7:44 AM > To: Samah Mansour > Cc: edk2-devel@lists.01.org; ler...@redhat.com > Subject: Re: [edk2] SPI Flash Corruption > Importance: High > > thank you, Samah. > Would you please file a tracker in edkii bugzilla ? > > The term VPD might lead confusion here. > Ideally VPD region is independent with UEFI variable region. It is a special > region to hold PCD with VPD type. > I just look at the code. The open source minnowmax puts variable region in > the VPD region. As such there is discussion about variable atomicity. But the > variable atomicity cannot guarantee the integrity of FV header. Additional > check need to be done in platform FVB driver. > > If you can add a detailed reproducing step in the bugzilla, it will be > helpful for us to understand the problem. > > thank you! > Yao, Jiewen > > >> 在 2018年9月20日，下午11:47，Samah Mansour 写道： >> >> Hi Laszlo, >> Thanks for your reply. >> Actually what I see is that VPD (Vital Product Area between addresses >> 44000->47DFF0 ) is completely wiped which causes the failure to boot! >> Without the VPD unit cannot boot. >> I will take a look at the white paper. >> It would be helpful to know what's the impact of disabling the ability of >> the firmware to write those non volatile variables to flash. >> >> Samah >> >> >>> On Thu, Sep 20, 2018 at 9:48 AM Laszlo Ersek wrote: >>> >>>> On 09/19/18 16:26, Samah Mansour wrote: >>>> Hello, >>>> >>>> >>>> Our product uses a Baytrail with Minnowboard Max bios firmware ( version >>>> 0.93). Every now and then we see SPI flash corruption due to power cuts >>>> while the unit is booting which causes the unit not to boot anymore. >>> After >>>> investigation we noticed that the VPD area is all FFs (address >>>> 44000->47DFF0). >>>> >>>> >>>> We have noticed that the Bios while booting writes to the flash from >>>> several places in the code, which is if interrupted most probably is >>>> causing the corruption. >>>> >>>> >>>> Why is the bios writing all these configurations to flash while booting, >>> is >>>> it to optimize boot time? is it ok if we disable the bios writing to >>> flash >>>> completely to protect ourselves from corruption? >>> >>> The firmware is at liberty to write various non-volatile UEFI variables >>> during boot. Some of those variables are standardized, some others may >>> be specific to UEFI drivers (with correspondingly private namespace >>> GUIDs for the variables). >>> >>> Power loss during flash write (and resultant flash corruption) is >>> expected. My understanding is that the Fault Tolerant Write protocol / >>> driver, sitting between the FVB (firmware volume block, i.e
Re: [edk2] [Question] Testing environment regarding SMM driver
> On Sep 20, 2018, at 7:30 AM, poxyran wrote: > > Hello, > > I have a specific question regarding SMM drivers. I'm trying to create a > mixed driver as mentioned here > http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html > and my first try is to create a kind of 'Hello World'. My try is to > install a SMI handler and call it from a user-mode app once the OS > booted up. The testing aproach mentioned in the blog post is not > practical, from my pooint of view. My question is, is it possible to > test this kind of drivers from the UEFI shell? or do I need to setup a > dedicated machine as mentioned here poxyran, I'm not sure what you are asking? Indirectly referencing a 10,000 word article is not very helpful. Feel free to ask a specific question. Thanks, Andrew Fish > https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt? > > BR, > poxyran > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] MdeModulePkg: add support for dispatching foreign arch PE/COFF images
> On Sep 15, 2018, at 6:28 AM, Ard Biesheuvel wrote: > > On 13 September 2018 at 19:20, Kinney, Michael D > wrote: >> Ard, >> >> I think there is a fundamental assumption that >> the sizeof(UINTN) and size of pointers of >> the native CPU are the same as the emulated CPU. >> If that is not the case, then I would like to see >> more details. Otherwise that is a significant >> restriction that needs to be clearly documented. >> > > There is no such assumption. The PE/COFF emulator protocol is an > abstract protocol that leaves it fully up to the implementation to > decide whether it can support images of machine type X and image type > Y. > Ard, Not knowing the size of UINTN or a pointer was very painful in terms of how EBC worked. The compiler was forced to generate code for sizeof vs. resolving it at compile time. >> Protocols that only allow a single instance need to >> clearly document that assumption. >> > > I will remove that restriction. > >> If we decide to treat EBC as an emulated CPU, then >> we would want to support multiple instances of the >> protocol. The updates to the DXE Core are a bit >> confusing because it has separate handling of EBC >> and emulated CPUs. I think it would make the DXE >> Core logic simpler and easier to understand if they >> were combined. >> > > Yes, excellent idea, and it results in a nice cleanup as well > >> I asked about the startup case because if we do EBC, >> then we may need more services in the protocol because >> of the thunk code between native and EBC code. At the >> time EBC was originally implemented, we did not have >> paging enabled and the EBC interpreter work without >> depending on a page fault handler. >> >> The way the protocol is currently defined, I believe it >> fundamentally assumes paging is enabled. If paging is >> not enabled, then the current protocol services are not >> sufficient for any emulated CPU. Do we want this to work >> for paging disabled cases? If not, another assumption >> to clearly document. >> > > The paging disabled case is interesting. Does the UEFI spec even > permit running in DXE with paging disabled? Paging is a function of the processor binding in the UEFI spec. It is not required for IA32. For X64 you have to have paging enable to enter long mode. On other processors you need to turn on paging to control the cache. So I guess the no paging is likely more of a i386 issue? > > In any case, I will send out a v2 as the basis for further discussion. > We can also sit down and discuss it in Vancouver the coming week. I'd suggest passing an EFI device path to IS_PECOFF_IMAGE_SUPPORTED. At some point it might be useful for the emulator to know what device is being emulated. For bonus points we could check IsPecoffImageSupported() prior to the native check. Never say never, some one may want to have emulator run on native images for debugging etc. Thanks, Andrew Fish > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Updating/adding video mode
Prabin, There is not an easy answer to your question. 1) What video resolution is available can be a function of what monitor is plugged in to the graphics card. 2) The monitor can publish an EDID that defines what resolutions the monitor supports. EDID is a VESA standard. 3) An EFI Platform can provide an EFI_EDID_OVERRIDE_PROTOCOL that can impact the available video modes that get published. 4) The GOP card will publish EDID information via the EFI_EDID_DISCOVERED_PROTOCOL. As I mentioned the EDID data structure is defined by a VESA standard, but it also has to be valid for what the monitor can support. Basically you can override the EDID and tell the GOP card to does something the monitor can not support. Some platforms use the ConSpliter and it produces a virtual GOP protocol that will aggregate hardware GOPs. So for example if you system has an internal panel and an external monitor installed you could end up with 2 HW GOP protocols and a virtual GOP protocol that represents the ConSpliter. Thanks, Andrew Fish > On Sep 15, 2018, at 10:37 PM, prabin ca wrote: > > Any points on this really helpful for me. > >> On 15-Sep-2018, at 6:46 AM, prabin ca wrote: >> >> Hi Team, >> I’m working with a platform having UHD (3840X2160as native resolution) >> display screen. I have dump the video modes using EFI_GRAPHICS_PROTOCOL. >> >> Following are the dump result >> >> Mode 0 : hRes = 3840 Vres=2160 >> Mode 1 : hRes = 640 Vres = 480 >> Mode 2 : hRes = 800 Vres = 600 >> Mode 3 : hRes = 1024 Vres = 768 >> Mode 4 : hRes = 1280 Vres = 1024 >> Mode 5 : hRes = 1600 Vres = 1200 >> Mode 6 : hRes = 1920 Vres = 1440 >> >> In the supported video mode list, 1920X1080 is not there. Is there any way >> to add support for this resolution. I have checked UEFI spec but didn’t find >> any useful API/protocol >> Any help really appreciate. > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainer.txt: Add Ray to be co-maintainer of EmulatorPkg
Reviewed-by: Andrew Fish mailto:jordan.l.jus...@intel.com>pple.com> > On Sep 6, 2018, at 6:27 AM, Ruiyu Ni wrote: > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ruiyu Ni > Cc: Jordan Justen > Cc: Andrew Fish > --- > Maintainers.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 61df6e198b..7ebd53f662 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -124,6 +124,7 @@ EmulatorPkg > W: https://github.com/tianocore/tianocore.github.io/wiki/EmulatorPkg > M: Jordan Justen > M: Andrew Fish > +M: Ruiyu Ni > S: Maintained > > FatPkg, FatBinPkg > -- > 2.16.1.windows.1 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Performance enabling of Event handler
Prabin, Last time I looked every call to PERF_START()/PERF_END() creates a new performance record. So it does not work well for a function that is called a large number of times. Thanks, Andrew Fish > On Sep 6, 2018, at 7:30 PM, prabin ca wrote: > > Hi, > PerformancePkg is not working with event handlers, but it’s working with > normal functions handlers. > >> On 06-Sep-2018, at 3:28 PM, Laszlo Ersek wrote: >> >>> On 09/06/18 08:10, prabin ca wrote: >>> Hi Team, >>> >>> I’m used edk2 PerformancePkg for profiling cpu execution time taken by a >>> event handler. Event is created successfully and event handler is also >>> called successfully, but I can capture the performance of this event >>> handler with PerformancePkg (by using perf_start and perf_end check >>> points). This PerformancePkg is working fine with normal function calls. >> >> Do you mean "can not", instead of "can"? (Sorry, I don't understand.) >> >>> >>> Please help me to enable PerformancePkg action on event handler also. >>> >> >> Hmmm, even with the suggested typo correction, I wouldn't know what to >> suggest. Sorry! >> >> Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] portability of ShellPkg
Mike, More possible ideas I think from a 10,000 foot level the issue is the Public definition of the HOB lib calls out the ASSERT behavior 5) Make the ASSERT() conditional via a PCD and update the HOB lib definition. For platforms that make HOBs options GetHobList() must be called 1st, and non of the other APIs can be called on platforms that don't support HOBs. That has the upside of only needing to make the Lib constructor and GetHobList() ASSERTs conditional onPCDs. 6) Split the existing UefiBootManagerLib in a backwards compatible way by making a new UefiBootLib. UefiBootManagerLib.h can include UefiBootLib.h and UefiBootManagerLib.inf could depend on UefiBootLib. This would only require adding UefiBootLib to the library class of existing DSC files. Thanks, Andrew Fish > On Sep 6, 2018, at 10:17 AM, Kinney, Michael D > wrote: > > Ray, > > I have a few ideas here. > > 1) Add a new UefiHobLib instance that is only for > use by UEFI Drivers and UEFI Applications. It fails > gracefully if the HOB List is not in the UEFI System > Configuration Table. BootMode if HobList is not present > can be BOOT_WITH_FULL_CONFIGURATION. > > 2) Remove ASSERT() from the CONSTRUCTOR and a return > NULL from the Get*() functions if mHobList is NULL. > BootMode can be BOOT_WITH_FULL_CONFIGURATION if > mHobList is NULL. > > 3) Update UEFI Shell to not use the UefiBootManagerLib. > This would add duplicate code to the UEFI Shell. > > 4) Update UefiBootManagerLib to not use the HobLib. > Instead look for HobList in UEFI System Configuration > Table and fail gracefully if it is not present. > This would add some duplicate code to the > UefiBootManagerLib to parse the Hob List. > > Best regards, > > Mike > >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Thursday, September 6, 2018 2:57 AM >> To: Ni, Ruiyu ; Andrew Fish >> >> Cc: Leif Lindholm ; edk2- >> de...@lists.01.org; Carsey, Jaben >> ; Alexander Graf >> ; Heinrich Schuchardt >> ; AKASHI Takahiro >> ; Kinney, Michael D >> >> Subject: Re: portability of ShellPkg >> >> On 09/06/18 04:34, Ni, Ruiyu wrote: >>> On 9/6/2018 3:47 AM, Andrew Fish wrote: >>>> >>>> Laszlo, >>>> >>>> gEfiMemoryTypeInformationGuid is an edk2/MdeModulePkg >> concept used to >>>> give the DXE Core hints on how to reduce >> fragmentation in the memory >>>> map. Typically there is code in PEI that creates a >> HOB and may consume >>>> a variable written by the BDS. This library seems to >> be the generic >>>> way to do it on an edk2 platform. >>>> >>>> Thus this library is not just PI but edk2 >> MdeModulePkg specific in >>>> some of its assumptions. In general this >> UefiBootManagerLib seems >>>> focused on construction and edk2 BDS. It would >> probably make more >>>> sense to break out the UEFI Spec related bits so they >> could be used in >>>> generic UEFI Applications. >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>> >>> >>> Andrew, >>> I agree refactoring UefiBootManagerLib to separate the >> pure UEFI, pure >>> PI and EDKII specific looks much more cleaner. >>> So far the PI related bits in UefiBootManagerLib may >> include: >>> 1. Hob access for S4 support (memory type information >> HOB). >>> 2. Boot from Firmware Volume support. >>> >>> But that requires introducing two or more library >> classes so affecting >>> all existing platforms. EfiCreateEventLegacyBootEx() >> in UefiLib also >>> touches PI event gEfiEventLegacyBootGuid. >>> >>> And I think the value of refactor might be small. >>> >>> I think root cause of this problem is not >> UefiBootManagerLib includes >>> PI, it's the assertion in DxeHobLib. >>> So I am thinking maybe a very light fix is to remove >> the constructor of >>> DxeHobLib. >>> >>> I talked with Liming about this and he suggested that >> instead of >>> removing the constructor, it's safer to just remove >> the assertion in the >>> constructor. Because removing the constructor of >> HobLib may cause >>> AutoGen process generates a different order of library >> constructors >>> calling sequence, which may break the platform. >>> >>> So I propose to just remove the assertion in DxeHobLib >> constructor. >>> Thoughts? >> >> I think keeping the constructor itself is important and >> a good idea. >> >> I also think that we should *perhaps* keep the assertion >> *somewhere*, >> just not in the constructor. Because, at least some of >> the HobLib APIs >> cannot return errors (and their callers expect them to >> succeed at all >> times). This suggests we should still trip assertions >> when a HobLib API >> is called *in practice* on a non-PI UEFI platform. >> >> Thanks >> Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] portability of ShellPkg
Jaben,
Sorry to test compile a library just list the library in the [Components]
section of the DSC file. MdePkg/MdePkg.dsc is an example of this.
Thanks,
Andrew Fish
> On Sep 5, 2018, at 11:23 AM, Carsey, Jaben wrote:
>
> Aha. So that is very different from a non NULL library when listed in the
> components section. The goal is to test compile the library but not use I
> think. Is there any way to do that?
>
> Jaben
>
> On Sep 5, 2018, at 11:21 AM, Andrew Fish <mailto:af...@apple.com>> wrote:
>
>>
>>
>>> On Sep 5, 2018, at 11:05 AM, Carsey, Jaben >> <mailto:jaben.car...@intel.com>> wrote:
>>>
>>> But a NULL lib listed in components section shouldn’t be linked in to
>>> anything...
>>>
>>
>> Jaben,
>>
>> A NULL library class means force it to be linked in.
>>
>> ShellPkg/ShellPkg.dsc:70: # [LibraryClasses.ARM] and NULL mean link this
>> library into all ARM images.
>> ShellPkg/ShellPkg.dsc:72:
>> NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>> ShellPkg/ShellPkg.dsc:75:
>> NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
>> ShellPkg/ShellPkg.dsc:78:
>> NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
>> ShellPkg/ShellPkg.dsc:110:
>> NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:111:
>> NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:112:
>> NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:114:
>> NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:115:
>> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:116:
>> NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:117:
>> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>> ShellPkg/ShellPkg.dsc:118:
>> NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
>>
>> Libraries can get pulled in via other libraries. The only way to tell for
>> sure is to look at the build report.
>>
>> $ build -p ShellPkg/ShellPkg.dec -a X64 -t XCODE5 --report-file=report.txt
>> $ cat report.txt | grep HobLib
>> /Volumes/Case/UDK2018/MdePkg/Library/DxeHobLib/DxeHobLib.inf
>> {HobLib: C = HobLibConstructor Time = 19ms}
>>
>> You can comment out the HobLib reference in the ShellPkg.dsc file and figure
>> out who is using it " ffHobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf"
>> $ build -p ShellPkg/ShellPkg.dec -a X64 -t XCODE5 --report-file=report.txt
>> ...
>> build.py...
>> /Volumes/Case/UDK2018/ShellPkg/ShellPkg.dsc(...): error 4000: Instance of
>> library class [HobLib] is not found
>> in
>> [/Volumes/Case/UDK2018/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf]
>> [X64]
>> consumed by module
>> [/Volumes/Case/UDK2018/ShellPkg/Application/Shell/Shell.inf]
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Unless is listed below with the shell INF also, it just test compiles it...
>>>
>>> Or so I thought.
>>>
>>> On Sep 5, 2018, at 11:04 AM, Andrew Fish >> <mailto:af...@apple.com>> wrote:
>>>
>>>>
>>>>
>>>>> On Sep 5, 2018, at 10:30 AM, Carsey, Jaben >>>> <mailto:jaben.car...@intel.com>> wrote:
>>>>>
>>>>> How does removing a lib from the components section affect the shell
>>>>> binary output?
>>>>>
>>>>> Is the asset at compile time?
>>>>
>>>> Jaben,
>>>>
>>>> The issue is likely with the HOB lib constructor in the Shell iASSERTing.
>>>> Leif's example platform supports UEFI, but not PI so it is not expected
>>>> that HOBs exist.
>>>>
>>>> The library has an explicit assumption that HOBs exist, and that is not
>>>> the case in Leif's platform.
>>>>
>>>> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/DxeHobLib/HobLib.c#L54
>>>>
>>>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/DxeHobLib/HobLib.c#L54>
>>>>
>>>>
>>>> VOID *mHobList =
>&g
Re: [edk2] portability of ShellPkg
> On Sep 5, 2018, at 11:05 AM, Carsey, Jaben wrote:
>
> But a NULL lib listed in components section shouldn’t be linked in to
> anything...
>
Jaben,
A NULL library class means force it to be linked in.
ShellPkg/ShellPkg.dsc:70: # [LibraryClasses.ARM] and NULL mean link this
library into all ARM images.
ShellPkg/ShellPkg.dsc:72:
NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
ShellPkg/ShellPkg.dsc:75:
NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
ShellPkg/ShellPkg.dsc:78:
NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
ShellPkg/ShellPkg.dsc:110:
NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
ShellPkg/ShellPkg.dsc:111:
NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
ShellPkg/ShellPkg.dsc:112:
NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
ShellPkg/ShellPkg.dsc:114:
NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
ShellPkg/ShellPkg.dsc:115:
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
ShellPkg/ShellPkg.dsc:116:
NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
ShellPkg/ShellPkg.dsc:117:
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
ShellPkg/ShellPkg.dsc:118:
NULL|ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsLib.inf
Libraries can get pulled in via other libraries. The only way to tell for sure
is to look at the build report.
$ build -p ShellPkg/ShellPkg.dec -a X64 -t XCODE5 --report-file=report.txt
$ cat report.txt | grep HobLib
/Volumes/Case/UDK2018/MdePkg/Library/DxeHobLib/DxeHobLib.inf
{HobLib: C = HobLibConstructor Time = 19ms}
You can comment out the HobLib reference in the ShellPkg.dsc file and figure
out who is using it " ffHobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf"
$ build -p ShellPkg/ShellPkg.dec -a X64 -t XCODE5 --report-file=report.txt
...
build.py...
/Volumes/Case/UDK2018/ShellPkg/ShellPkg.dsc(...): error 4000: Instance of
library class [HobLib] is not found
in
[/Volumes/Case/UDK2018/MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf]
[X64]
consumed by module
[/Volumes/Case/UDK2018/ShellPkg/Application/Shell/Shell.inf]
Thanks,
Andrew Fish
> Unless is listed below with the shell INF also, it just test compiles it...
>
> Or so I thought.
>
> On Sep 5, 2018, at 11:04 AM, Andrew Fish <mailto:af...@apple.com>> wrote:
>
>>
>>
>>> On Sep 5, 2018, at 10:30 AM, Carsey, Jaben >> <mailto:jaben.car...@intel.com>> wrote:
>>>
>>> How does removing a lib from the components section affect the shell binary
>>> output?
>>>
>>> Is the asset at compile time?
>>
>> Jaben,
>>
>> The issue is likely with the HOB lib constructor in the Shell iASSERTing.
>> Leif's example platform supports UEFI, but not PI so it is not expected that
>> HOBs exist.
>>
>> The library has an explicit assumption that HOBs exist, and that is not the
>> case in Leif's platform.
>>
>> https://github.com/tianocore/edk2/blob/master/MdePkg/Library/DxeHobLib/HobLib.c#L54
>>
>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Library/DxeHobLib/HobLib.c#L54>
>>
>>
>> VOID *mHobList =
>> NULL;
>>
>>
>> /**
>>
>> Returns the pointer to the HOB list.
>>
>>
>> This function returns the pointer to first HOB in the list.
>>
>> For PEI phase, the PEI service GetHobList() can be used to retrieve the
>> pointer
>>
>> to the HOB list. For the DXE phase, the HOB list pointer can be retrieved
>> through
>>
>> the EFI System Table by looking up theHOB list GUID in the System
>> Configuration Table.
>>
>> Since the System Configuration Table does not exist that the time the DXE
>> Core is
>>
>> launched, the DXE Core uses a global variable from the DXE Core Entry Point
>> Library
>>
>> to manage the pointer to the HOB list.
>>
>>
>> If the pointer to the HOB list is NULL, then ASSERT().
>>
>>
>> This function also caches the pointer to the HOB list retrieved.
>>
>>
>> @return The pointer to the HOB list.
>>
>>
>> **/
>>
>> VOID *
>>
>> EFIAPI
>>
>> GetHobList (
>>
>> VOID
>>
>> )
>>
>> {
>>
>> EFI_STATUS Status;
>>
>>
>> if (mHobList ==
>> NULL) {
>>
>> Status =
>> EfiGetSystemConfigurationTable
Re: [edk2] portability of ShellPkg
> On Sep 5, 2018, at 10:30 AM, Carsey, Jaben wrote:
>
> How does removing a lib from the components section affect the shell binary
> output?
>
> Is the asset at compile time?
Jaben,
The issue is likely with the HOB lib constructor in the Shell iASSERTing.
Leif's example platform supports UEFI, but not PI so it is not expected that
HOBs exist.
The library has an explicit assumption that HOBs exist, and that is not the
case in Leif's platform.
https://github.com/tianocore/edk2/blob/master/MdePkg/Library/DxeHobLib/HobLib.c#L54
VOID *mHobList = NULL;
/**
Returns the pointer to the HOB list.
This function returns the pointer to first HOB in the list.
For PEI phase, the PEI service GetHobList() can be used to retrieve the
pointer
to the HOB list. For the DXE phase, the HOB list pointer can be retrieved
through
the EFI System Table by looking up theHOB list GUID in the System
Configuration Table.
Since the System Configuration Table does not exist that the time the DXE
Core is
launched, the DXE Core uses a global variable from the DXE Core Entry Point
Library
to manage the pointer to the HOB list.
If the pointer to the HOB list is NULL, then ASSERT().
This function also caches the pointer to the HOB list retrieved.
@return The pointer to the HOB list.
**/
VOID *
EFIAPI
GetHobList (
VOID
)
{
EFI_STATUS Status;
if (mHobList == NULL) {
Status = EfiGetSystemConfigurationTable (, );
ASSERT_EFI_ERROR (Status);
ASSERT (mHobList != NULL);
}
return mHobList;
}
/**
The constructor function caches the pointer to HOB list by calling
GetHobList()
and will always return EFI_SUCCESS.
@param ImageHandle The firmware allocated handle for the EFI image.
@param SystemTable A pointer to the EFI System Table.
@retval EFI_SUCCESS The constructor successfully gets HobList.
**/
EFI_STATUS
EFIAPI
HobLibConstructor (
IN EFI_HANDLEImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
GetHobList ();
return EFI_SUCCESS;
}
/**
Returns the next instance of a HOB type from the starting HOB.
This function searches the first instance of a HOB type from the starting HOB
pointer.
If there does not exist such HOB type from the starting HOB pointer, it will
return NULL.
In contrast with macro GET_NEXT_HOB(), this function does not skip the
starting HOB pointer
unconditionally: it returns HobStart back if HobStart itself meets the
requirement;
caller is required to use GET_NEXT_HOB() if it wishes to skip current
HobStart.
If HobStart is NULL, then ASSERT().
@param Type The HOB type to return.
@param HobStart The starting HOB pointer to search from.
@return The next instance of a HOB type from the starting HOB.
**/
VOID *
EFIAPI
GetNextHob (
IN UINT16 Type,
IN CONST VOID *HobStart
)
{
EFI_PEI_HOB_POINTERS Hob;
ASSERT (HobStart != NULL);
Hob.Raw = (UINT8 *) HobStart;
//
// Parse the HOB list until end of list or matching type is found.
//
while (!END_OF_HOB_LIST (Hob)) {
if (Hob.Header->HobType == Type) {
return Hob.Raw;
}
Hob.Raw = GET_NEXT_HOB (Hob);
}
return NULL;
}
Thanks,
Andrew Fish
>
> Jaben
>
>> On Sep 5, 2018, at 10:26 AM, Leif Lindholm wrote:
>>
>> Hi all,
>>
>> (This is partly a summary of discussions that have been held on IRC
>> and offline, with Alex Graf and Mike Kinney.)
>>
>> The UEFI Shell, as produced by the contents of ShellPkg, is needed for
>> running the UEFI SCT. This has never been problematic before - but now
>> we are starting to run SCT on the U-Boot implementation of the UEFI
>> interfaces, certain implicit assumptions may need to be made explicit,
>> and perhaps reevaluated.
>>
>> My feeling is the following:
>> - The MinUefiShell variant should be sufficient to run SCT.
>> - The UEFI Shell as provided by ShellPkg (any flavour) should run on
>> any valid UEFI implementation. Where underlying functionality is
>> missing for certain commands, those commands should be
>> degraded/disabled to let remaining commands function.
>>
>> Ideally, I would like to see a Readme.md in ShellPkg, basically
>> providing a mission statement. I could write one, but I expect the
>> people who actually maintain it would be better suited :)
>>
>> We currently have an issue with running the shell on U-Boot because
>> even MinUefiShell pulls in UefiShellDebug1CommandsLib.inf. This
>> appears to be inadvertent, since it is also included a few lines
>> further down inside an !ifndef $(NO_SHELL_PROFILES) guard.
>> So I would propose the following patch (and can send it out properly
>> if the maintainers agree):
>>
>> diff --git a/ShellPkg/ShellPkg.dsc b/ShellPkg/ShellPkg.dsc
>> index
Re: [edk2] GOP Console Driver
JD, Glad to see you are getting use out of your 10 year old Mac. Here are the supported graphics cards: https://support.apple.com/en-gb/HT201805 <https://support.apple.com/en-gb/HT201805> The EFI on your Mac Pro3,1 requires a Mac Edition card. Some of those cards had an EFI Firmware Switch to change the ROM mode. Mac Pro 2010 is the oldest Mac that is still supported: https://support.apple.com/macos/mojave <https://support.apple.com/macos/mojave>. The Mac Edition cards produce an API that is lower level than UGA or GOP so that all the policy can be driven Mac and not the video card. Thanks, Andrew Fish > On Aug 19, 2018, at 4:34 AM, Jd Lyons wrote: > > > >> Begin forwarded message: >> >> From: Jd Lyons >> Subject: GOP Console Driver >> Date: August 18, 2018 at 11:31:50 PM EDT >> To: edk2-devel@lists.01.org >> >> I’ve been trying to hack together GOP support for Apples EFI 1.1 on my Mac >> Pro3,1. Apple uses a somewhat mix of EFI 1.x and UEFi2.x. >> >> I’m able to get the GOP rom for my graphics card to load and link to the >> device, Apple’s firmware takes care of that much, and I have some custom >> code for rEFInd boot loader that makes the graphics card work in graphics >> mode. However I can’t get back to a shell nor can I boot Windows or the Mac >> OS in this mode. >> >> I think the trouble with booting the macOS is Apple’s boot.efi can’t get the >> console, Apple has a UGA Console driver but no GOP Console driver in my >> firmware. I tried extracting the Graphics Console Driver from OVMF and it >> does load, but doesn’t link to any devices, even when I try to connect it >> with my device handle, I.E. >> >> connect DA 129 >> >> Returns success, but invoking drivers shows the Graphics Console Driver is >> still not linked to any devices. >> >> Can anyone point me in the right direction on how to get a proper GOP >> Console Driver? >> >> Thanks, >> JD > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
> On Aug 8, 2018, at 10:31 AM, Rafael Machado > wrote: > > Hi everyone > > One question that was not answered and that could help us, is about skipping > the MemoryTypeInfo variable usage. > Is there any way to do this skip at a UEFI App ? > Simple erasing the MemoryTypeInfo var seems a little to violent from our > perspective. What do you think? > > Seems the system we're having this problem has some inconsistency when > filling the MemoryTypeInfo var before exiting the previous boot, and seems > to consider the BootServices memory type also to be stored at the var. Does > anyone remember of this kind of issue on some system in the past? > No we do that all the time to remove fragmentation from the memory map and it does not Thanks, Andrew Fish > Thanks and Regards > Rafael > > Em qua, 8 de ago de 2018 às 08:55, Rafael Machado > <mailto:rafaelrodrigues.mach...@gmail.com>> escreveu: > Hi Jiewen > > Thanks for highlighting this. > Just checked and we just add the Reserved/Acpi/Runtime types. > > Seems the guess that this would be related to the MemoryTypeInfo var is not > the correct way to follow. > > We'll keep working on it, maybe asking more questions to the community in > future. > Thank you all for the help and guidance! > In case someone has any comment or idea, please feel free to share. > > Rafael > > > > Em ter, 7 de ago de 2018 às 19:42, Yao, Jiewen <mailto:jiewen@intel.com>> escreveu: > Hi > > It is unclear to me that which type you have put to MemoryTypeInfo table. > > > > By design, we only need put Reserved/Acpi/Runtime, which should be quite > small. > > > > Do you put any other type into MemoryTypeInfo table? > > > > Thank you > > Yao Jiewen > > <> > <>From: Rafael Machado [mailto:rafaelrodrigues.mach...@gmail.com > <mailto:rafaelrodrigues.mach...@gmail.com>] > Sent: Wednesday, August 8, 2018 3:12 AM > To: Laszlo Ersek mailto:ler...@redhat.com>> > Cc: Andrew Fish mailto:af...@apple.com>>; Ni, Ruiyu > mailto:ruiyu...@intel.com>>; edk2-devel@lists.01.org > <mailto:edk2-devel@lists.01.org>; Yao, Jiewen <mailto:jiewen@intel.com>> > > > Subject: Re: [edk2] Question about memory map entries > > > > > Hi everyone > > > > Based on the information shared by the members, the understanding is that the > current state of the system may impact fuutre boots. > > The problem is that in my case, due to specific requirements, before booting > we need to stress the system's memory, allocating a big amount of memory and > doing some memory validation algorithms. > > So the high number of allocations and frees is by choice and not by mistakes. > > > > Considering this. Is there any way to bypass the MemoryTypeInformation var > store actions? > > > > Thanks and Regards > > Rafael > > > > Em qui, 2 de ago de 2018 às 17:39, Laszlo Ersek <mailto:ler...@redhat.com>> escreveu: > > On 08/02/18 21:18, Rafael Machado wrote: > > Just found something interesting. > > Based on the logs from the serial port. > > > > This system works fine: > > > > "PeiInstallPeiMemory MemoryBegin 0x93D5, MemoryLength 0xA2B > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x93D5 Length=0x8 > > Heap Offset = 0x9395 Stack Offset = 0x9395 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > > "CoreInitializeMemoryServices: > > BaseAddress - 0x93DE1000 Length - 0x8135000 MinimalMemorySizeNeeded - > > 0x5AC" > > > > This one is bricked: > > > > "PeiInstallPeiMemory MemoryBegin 0x9C9000, MemoryLength 0x9D637000 > > Temp Stack : BaseAddress=0x40 Length=0x8 > > Temp Heap : BaseAddress=0x48 Length=0x8 > > Total temporary memory:1048576 bytes. > > temporary memory stack ever used: 524288 bytes. > > temporary memory heap used: 63304 bytes. > > Old Stack size 524288, New stack size 524288 > > Stack Hob: BaseAddress=0x9C9000 Length=0x8 > > Heap Offset = 0x5C9000 Stack Offset = 0x5C9000 > > Loading PEIM at 0x0009DFF4000 EntryPoint=0x0009DFF4260 PeiCore.efi" > > ... > &g
Re: [edk2] PerformancePkg on multiple platform -
Prabin, There is a PCD setting to configure performance collection. PCDs are defined in the .DEC file and it looks like the default is zero and that means disabled. MdePkg/MdePkg.dec ... ## The mask is used to control PerformanceLib behavior. # BIT0 - Enable Performance Measurement. # @Prompt Performance Measurement Property. # @Expression 0x8002 | (gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask & 0xFE) == 0 gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0|UINT8|0x0009 If you search the code you will see some platforms enabling performance measurement in their DSC files. /Volumes/Case/UDK2018(vUDK2018)>git grep gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask -- *.dsc BeagleBoardPkg/BeagleBoardPkg.dsc:272: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|1 EmbeddedPkg/EmbeddedPkg.dsc:175: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0 QuarkPlatformPkg/Quark.dsc:373: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x1 QuarkPlatformPkg/Quark.dsc:376: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x00 QuarkPlatformPkg/QuarkMin.dsc:334: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x1 QuarkPlatformPkg/QuarkMin.dsc:337: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x00 Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:682: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x1 Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:682: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x1 Vlv2TbltDevicePkg/PlatformPkgX64.dsc:682: gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x1 So I'd check that 1st. If that does not work I recommend adding -report-file=build.log to your build command. You can look at the given driver/app you care about and see what the PCD settings are and which instance of the PerformanceLib got linked. Thanks, Andrew Fish > On Aug 3, 2018, at 11:17 AM, Laszlo Ersek wrote: > > Hi Prabin, > > On 08/03/18 09:29, prabin ca wrote: >> Hi Team, >> >> I’m new to uefi and edk. Currently I’m trying to get performance of my dxe >> driver using PerformancePkg of EDK source code. >> >> I’m using perf_start and perf_end T respected check points, it’s hot build >> and tested well in 2/3 platform. It’s giving proper response. >> >> But when I’m Checking with multiple platform, in some of platforms it’s not >> working and got hang in uefi she’ll itself. >> >> Please help me to resolve asap, it will be really helpful. > > I can only give you some hints, because thus far I have also failed to > figure out how performance measurements should be enabled for a platform > from scratch. > > Earlier I thought that an interested platform should include modules > from PerformancePkg. I got some good results that way; however: > > - it wouldn't work for AARCH64, and so I filed > <https://bugzilla.tianocore.org/show_bug.cgi?id=679> > > - ultimately PerformancePkg was removed in commit 922c1e94e4bb > completely. (And for that reason I now closed TianoCore#679 as > WONTFIX.) > > Commit 922c1e94e4bb doesn't really give pointers for enabling > performance measurements in a platform -- it refers the user to the DP > shell command instead of the standalone DP application, but that's only > for displaying the stats, not for recording them. > > One document where I found information is the Intel whitepaper > > A Tour Beyond BIOS > Implementing Profiling in with EDK II > > (just google it). "Part III – Performance Profile" is relevant. > > The first section of that talks about enabling ACPI FPDT (ACPI Firmware > Performance Data Table) support in edk2, for exposing firmware > performance data to the OS. Again, that's not about *recording* the stats. > > The second section of the same chapter seems to describe how stats can > be recorded however. AIUI, the DXE Core can provide the PERFORMANCE[_EX] > protocols, if the DxeCorePerformanceLib instance is linked into it by > the platform DSC file. In turn DXE modules can send measurements to the > protocol via the PerformanceLib APIs / DxePerformanceLib instance. > > In fact, the relevant library INF files have good documentation, we just > have to know what to look at. > > Recording stats in the PEI phase, via HOBs: > - MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf > > Recording stats in the DXE phase (protocol provider and consumer): > - MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.inf > - MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf > > Recording stats in SMM (protocol provider and consumer): > - MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.inf > - MdeModule
Re: [edk2] Question about memory map entries
> On Aug 2, 2018, at 5:39 AM, Rafael Machado
> wrote:
>
> Hi everyone
>
> After some other tasks I am back to this case :)
>
> After some debug, we detected the moment where things start to go wrong, but
> I am not sure what may cause this.
>
> What we noticed is that the following assert is reached:
> https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L21
>
> <https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L21>h
>
> <https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199>99
>
> <https://github.com/tianocore/edk2/blob/87acb6e298e718250dd8b741b6888a3a54c7cb5a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2199>
> Just to remember, this assert is reached with the following steps:
> 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick
> 2 - Execute the application tasks
> 3 - exit the application (free everything, all events closed and no memory
> leaks detected as suggested to check by Andrew on the previous e-mail, then
> return efi_success)
> 4 - the system will reboot and reach the assert
>
> But it does not happen with the following scenario:
> 1 - Boot the application (renamed to BOOTX64.efi) from a usb stick
> 2 - Execute the application tasks
> 3 - Power off the system
>
> As far as I could understand (please correct my understanding that may be
> wrong since is the first time I look at this part of the code), at this point
> the HOBs passed from sec phase are processed by PEI so the memory could be
> "detected/mapped/initialized" correctly. But for some reason the required HOB
> is no present at the list.
>
> Could someone with more experience at this part of the code please confirm my
> understanding, and if possible give some guesses about what could cause this
> scenario?
>
> My guess is that some memory cleanup that should be done by the bios after
> the application exits is not being done correctly. So I believe the problem
> is not at the application, but at the BIOS. A friend here mentioned about the
> MemoryTypeInformation efi var, that may be corrupted, and considering it's
> used to guide the boot process it may impact the boot, but I am not sure if
> this is the case and also I didn't find to much information about this var
> and it's usage, so any help about this would be well received also.
>
> Any ideas?
>
Rafael,
The gEfiMemoryTypeInformationGuid HOB is optional and used to defragment the
EFI Memory Map. While it is copied it is not really in use at the point of your
ASSERT.
The PHIT HOB[1] must be the 1st HOB entry and it is the layout of the memory
that was in use by the PEI phase. At this point int he boot it is likely the
memory registered in PEI via the InstallPeiMemory() PEI Service. The error is
the memory in the PHIT hob does not have a corresponding
EFI_HOB_TYPE_RESOURCE_DESCRIPTOR of type EFI_RESOURCE_SYSTEM_MEMORY.
Here is an example of code doing the registration. As you can see it calls
PeiServicesInstallPeiMemory() and also generates the Resource HOB.
https://github.com/tianocore/edk2/blob/master/QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c#L738
You could try to track down the code in your code base doing the above
operation, and if that looks OK maybe add DEBUG prints and dump out the HOBs to
see if the got corrupted some how?
[1] PHIT HOB
///
/// Contains general state information used by the HOB producer phase.
/// This HOB must be the first one in the HOB list.
///
typedef struct {
///
/// The HOB generic header. Header.HobType = EFI_HOB_TYPE_HANDOFF.
///
EFI_HOB_GENERIC_HEADER Header;
///
/// The version number pertaining to the PHIT HOB definition.
/// This value is four bytes in length to provide an 8-byte aligned entry
/// when it is combined with the 4-byte BootMode.
///
UINT32 Version;
///
/// The system boot mode as determined during the HOB producer phase.
///
EFI_BOOT_MODE BootMode;
///
/// The highest address location of memory that is allocated for use by the
HOB producer
/// phase. This address must be 4-KB aligned to meet page restrictions of
UEFI.
///
EFI_PHYSICAL_ADDRESSEfiMemoryTop;
///
/// The lowest address location of memory that is allocated for use by the
HOB producer phase.
///
EFI_PHYSICAL_ADDRESSEfiMemoryBottom;
///
/// The highest address location of free memory that is currently available
/// for use by the HOB producer phase.
///
EFI_PHYSICAL_ADDRESSEfiFreeMemoryTop;
///
/// The lowest address location of free memory that is available for use by
the HOB producer phase.
///
EFI_PHYSICAL_ADDRESSEfiFreeMemo
Re: [edk2] Question About DxeDriver load process
Rafael, Since it is useful to also understand this when you are bringing up a platform SEC generally contains the hardware reset vector. SEC hands off to the PEI Core. Generally there is some build magic to help SEC find the PEI Core. Worst case you can walk the BFV (Boot Firmware Volume) and find it. SEC hands the PEI Core the EFI_SEC_PEI_HAND_OFF structure. This is how the PEI Core knows about stack, heap, and the location of the BFV to find PEIMs https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiPeiCis.h#L967 The PEI Core has a PPI Notify Callback for gEfiPeiFirmwareVolumeInfoPpiGuid, and gEfiPeiFirmwareVolumeInfo2PpiGuid to discover new FVs. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/FwVol/FwVol.c#L547 PEI Code writes hobs, EFI_HOB_TYPE_FV and EFI_HOB_TYPE_FV3, to help DXE discover FVs. When the DXE Core is started it will call FwVolBlockDriverInit() and all the EFI_HOB_TYPE_FV, and optionally pick up the authentication status from EFI_HOB_TYPE_FV3, will get processed. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L625 via calling ProduceFVBProtocolOnBuffer(). ProduceFVBProtocolOnBuffer() can also be called gBS->ProcessFirmwareVolume(). https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L452 https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c#L687 Loading drivers from the FV is the job of the DXE Dispatcher. The DXE Dispatcher has protocol notify event on gEfiFirmwareVolume2ProtocolGuid that will get the executables in the Dispatch list, mDiscoveredList. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dispatcher.c#L1193 So adding a gEfiFirmwareVolume2ProtocolGuid driver, or calling gBS->ProcessFirmwareVolume() is how you would make an FV show up that was not listed in the HOBs. In the DXE Phase security is handle by gBS->LoadImage() and it uses gEfiSecurity2ArchProtocolGuid and gEfiSecurityArchProtocolGuid to validate the image. This makes sense as a signed EFI PE/COFF image has the signature in the PE/COFF image, so you have to start the PE/COFF loading process to verify that signature. gEfiSecurity2ArchProtocolGuid lets you build security policy based on the location of the driver. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Image/Image.c#L1041 When the Dispatcher runs of things to Dispatch it returns and the DXE Core calls the BDS to process platform Boot Device Selection. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L550 After BDS starts the only way to run code from an FV would be to call gDS->Dispatcher(). Likely you would call gDS->ProcessFirmwareVolume() and then gDS->Dispatcher(). To speed boot it is not uncommon to have multiple FVs. For example you could have an FV that contained all the setup resources and only call gDS->ProcessFirmwareVolume() on that FV if the user hit the Setup hot key. Thanks, Andrew Fish PS For x86 (0xFFF0 reset vector) and any other architectures that have the reset vector at the end there is a special file name in the FV called gEfiFirmwareVolumeTopFileGuid that tells the FV creation tools to put that file at the very end of the FV, so the end of that file would end up at the reset vector location. > On Jul 27, 2018, at 11:12 AM, Rafael Machado > wrote: > > Hi everyone > > I have a question. > Let's suppose I have a BIOS with several FV regions. Between these FV there > is one that is empty. > > My question is: > In case I get this BIOS and inject a dxe driver at this FV. Would it be > executed, or there are specific FVs that are considered as containers to > executable code avoiding other FVs content to be executed? > > In case the answer comes with some code examples from edk2 tree it would be > amazing :) > > Thanks and Regards > Rafael > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Help on AutoGen Files
Udit,
As Marvin points out the [LibraryClasses] section of the INF file are going to
imply the order of the library constructor calls in the AutoGen
Worst case you can demote FpgaInterfaceInit () from being a constructor to just
being a public library function that the other lib can call explicitly from its
constructor. Maybe that is too drastic and you could must move a function out
of FpgaInterfaceInit () and make that function part of the Public library
interface?
Thanks,
Andrew Fish
> On Jul 19, 2018, at 11:14 AM, Marvin H?user
> wrote:
>
> Hey Udit,
>
> You cannot explicitly influence the order of the calls, but implicitly via
> the dependency tree, which means you need to make SerialPortLib depend on
> your LibraryClass instance.
> You did not mention which SerialPortLib instance you use, but probably you
> need to execute FpgaInterfaceInit() earlier in platform code or fork
> SerialPortLib for now.
>
> Regards,
> Marvin
>
>> -Original Message-
>> From: edk2-devel On Behalf Of Udit
>> Kumar
>> Sent: Thursday, July 19, 2018 9:33 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Help on AutoGen Files
>>
>> Hi Experts,
>> How I can change the order of initialization in Constructor list of autogen
>> file.
>> In my build system, if I look at
>> MdeModulePkg/Universal/PCD/Pei/Pcd/DEBUG/AutoGen.c
>> Below is function of Library Constructor List
>>
>> VOID
>> EFIAPI
>> ProcessLibraryConstructorList (
>> IN EFI_PEI_FILE_HANDLE FileHandle,
>> IN CONST EFI_PEI_SERVICES **PeiServices
>> )
>> {
>> EFI_STATUS Status;
>>
>> Status = BaseDebugLibSerialPortConstructor ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = PeiServicesTablePointerLibConstructor (FileHandle, PeiServices);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = TimerConstructor ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = FpgaInterfaceInit ();
>> ASSERT_EFI_ERROR (Status);
>>
>> }
>>
>>
>> My problem is SerialPortConstructor needs frequency, which can be
>> retrieved after FpgaInterfaceInit() Therefore, my preferred way for this
>> constructor list will be
>> FpgaInterfaceInit() followed by BaseDebugLibSerialPortConstructor()
>>
>> how I can achieve this.
>>
>>
>> Many Thanks
>> Udit
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] question about uefi shell pipe.
Krishnal,
Thanks for including the code. You are overflowing the buffer. In C
sizeof(Buffer) will be 80*25*4*2 since sizeof(UINT16) is 2. Your code is
passing in double the size of the buffer.
UINT16 Buffer[80*25*4]; //tool's buffer;
UINTN BufferSize=sizeof(Buffer);
UINTN BufferByteSize=BufferSize*sizeof(UINT16);
This should work:
UINT16 Buffer[80*25*4]; //tool's buffer;
UINTN BufferByteSize = sizeof(Buffer);
Thanks,
Andrew Fish
> On Jul 4, 2018, at 2:15 AM, krishnaLee wrote:
>
> Hi,
> I wrote this shell application(smalltest.efi),did some pipe function
> test,find some strange result.
> boot into shell:
>
>
> # test-1,the follow two command should has the same output ,but infact not
> the same in QEMU,and the second command failed WriteFile in real machine(AMI
> bios uefi 2.6):
> ls | smalltest.efi
> ls | smalltest.efi | smalltest.efi # the ls command directory
> only has one file(this tool),so the tool's buffer 80x25*4 won't overflow.
>
>
> #test-2
> run smalltest.efi,
> just key in some chars and Enter,nothing output,why?
>
>
> my test environment:
> UDK2018 + vs2015
> QEMU emulator version 2.10.95
> OVMF_X64.fd( x64,release build)
>
>
> the tool's build command:
> D:\edk2-vUDK2018>build -p ShellPkg\ShellPkg.dsc -m
> ShellPkg\Application2\smalltest\smalltest.inf -a X64 -b RELEASE
>
>
> //code---smalltest.c-
>
>
> #include
> #include
> #include
> #include //global gST gBS gImageHandle
> #include
> #include
>
>
> #include
> #include
>
>
>
> EFI_STATUS
> EFIAPI
> UefiMain (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> EFI_STATUS status;
> EFI_SHELL_PROTOCOL* gShell;
> EFI_SHELL_PARAMETERS_PROTOCOL*gParameters;
> UINT16 Buffer[80*25*4]; //tool's buffer;
> UINTN BufferSize=sizeof(Buffer);
> UINTN BufferByteSize=BufferSize*sizeof(UINT16);
>
>
> status=gBS->HandleProtocol(gImageHandle,,);
> if(status!=EFI_SUCCESS)
> {
> Print(L"locate gEfiShellParametersProtocolGuid failed.\n");
> return status;
> }
>
>
> status=gBS->LocateProtocol(,NULL,);
> if(status!=EFI_SUCCESS)
> {
> Print(L"locate gEfiShellProtocolGuid failed.\n");
> return status;
> }
>
>
> status=gShell->ReadFile(gParameters->StdIn,,(VOID*)Buffer);
> if(status!=EFI_SUCCESS)
> {
> Print(L"read from gParameters->StdIn failed.\n");
> return status;
> }
>
>
> status=gShell->WriteFile(gParameters->StdOut,,(VOID*)Buffer);
> if(status!=EFI_SUCCESS)
> {
> Print(L"wirte gParameters->StdOut failed\n");
> return status;
> }
>
>
> gShell->FlushFile(gParameters->StdOut);
>
>
> return EFI_SUCCESS;
> }
>
>
> //code---smalltest.inf-
>
>
> [Defines]
> INF_VERSION= 0x00010005
> BASE_NAME = smalltest
> FILE_GUID = 8F7D7B1D-0E1C-4c98-B12E-4EC99C400704
> MODULE_TYPE= UEFI_APPLICATION
> VERSION_STRING = 1.0
> ENTRY_POINT= UefiMain
>
>
> [Sources]
> smalltest.c
>
>
> [Packages]
> MdePkg/MdePkg.dec
>
>
> [Protocols]
> gEfiShellProtocolGuid
> gEfiShellParametersProtocolGuid
>
>
> [LibraryClasses]
> UefiApplicationEntryPoint
> UefiLib
> //code---end--
>
>
>
>
>
>
> thank you,
> by krishna.
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] gRT->SetVariable ACCESS DENIED error
Toan,
gEfiGlobalVariableGuid means it is defined in section 3.3, Globally Defined
Variables, in the UEFI Spec:
Identifies the level of hardware error record persistence support implemented
by the platform. This variable is only modified by firmware and is read-only to
the OS.
As you see it is defined as read only, so it is a special variable. Lets search
the UDK2018 for it and look for it being special cased
/Volumes/Case/UDK2018(vUDK2018)>git grep EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME
-- *.h
MdePkg/Include/Guid/GlobalVariable.h:121:#define
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAMEL"HwErrRecSupport"
/Volumes/Case/UDK2018(vUDK2018)>git grep EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME
-- *.c
MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c:407:
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
MdeModulePkg/Universal/BdsDxe/BdsEntry.c:48:
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
/Volumes/Case/UDK2018(vUDK2018)>git grep 'L"HwErrRecSupport"' -- *.c
IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:48: L"HwErrRecSupport",
IntelFrameworkModulePkg/Universal/BdsDxe/HwErrRecSupport.c:37:// define
same behavior between no value or 0 value for L"HwErrRecSupport".
IntelFrameworkModulePkg/Universal/BdsDxe/HwErrRecSupport.c:40:
L"HwErrRecSupport",
MdeModulePkg/Universal/BdsDxe/HwErrRecSupport.c:37:// define same behavior
between no value or 0 value for L"HwErrRecSupport".
MdeModulePkg/Universal/BdsDxe/HwErrRecSupport.c:40:
L"HwErrRecSupport",
Yep looks like some locking happens in the BDS, so maybe you are writing after
the lock event?
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L44
///
/// The read-only variables defined in UEFI Spec.
///
CHAR16 *mReadOnlyVariables[] = {
EFI_PLATFORM_LANG_CODES_VARIABLE_NAME,
EFI_LANG_CODES_VARIABLE_NAME,
EFI_BOOT_OPTION_SUPPORT_VARIABLE_NAME,
EFI_HW_ERR_REC_SUPPORT_VARIABLE_NAME,
EFI_OS_INDICATIONS_SUPPORT_VARIABLE_NAME
};
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L754
//
// Mark the read-only variables if the Variable Lock protocol exists
//
Status = gBS->LocateProtocol (, NULL, (VOID
**) );
DEBUG ((EFI_D_INFO, "[BdsDxe] Locate Variable Lock protocol - %r\n", Status));
if (!EFI_ERROR (Status)) {
for (Index = 0; Index < ARRAY_SIZE (mReadOnlyVariables); Index++) {
Status = VariableLock->RequestToLock (VariableLock,
mReadOnlyVariables[Index], );
ASSERT_EFI_ERROR (Status);
}
}
Maybe you missed it due the mixing of the #define and the architectural name
from the UEFI Spec?
Thanks,
Andrew Fish
PS
I really hate when folks take the architecturally defined strings in the
gEfiGlobalVariableGuid name space and obfuscate them with #defines. Especially
when it is not done in a non-consistent way. The #define solves nothing, and
obfuscates reading the code. In general in the edk2 we follow the type system
in the UEFI spec, and there is is only the Unicode string for variables, not a
#define value.
Lets be real if the UEFI spec ever changed the L"HwErrRecSupport" it would
have to be tied to spec version, so all the places that used that variable
would need the spec revision check and the #define is still just obfuscation
and the code is not constructed with a version check.
> On Jul 3, 2018, at 6:21 PM, Toan Le manh wrote:
>
> Hi Andrew,
>
> I'm trying to set some variables to NVRAM at the beginning of BDS phase.
> For example, this function returned EFI_ACCESS_DENIED
>Status = gRT->SetVariable (
>L"HwErrRecSupport",
>,
>EFI_VARIABLE_BOOTSERVICE_ACCESS |
> EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
>sizeof (UINT16),
>
>);
>
> Thanks & BRs,
> Toan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] GPT Partitions on RAID Disks
> On Jul 3, 2018, at 10:12 AM, Robinson, Herbie
> wrote:
>
> Background:
>
> I have been tasked with implementing UEFI boot in our VOS operating system.
> We've been using GPT partitions for more than 15 years, but only within our
> own OS... We haven't had to interact with any other software before this.
> We have a fault tolerant OS; so, all disks are RAID1 (software supported).
> We don't expose the GPT partitioning to our user interface: We have just use
> it as a wrapper for boot support to keep BIOS from being confused. The
> intent was to set it up to boot with either the legacy BIOS or UEFI. At the
> time, we only had a legacy BIOS to test with; so, we never finished the UEFI
> boot.
>
> I've reviewed our current implementation and found a few minor things wrong;
> so, I have been working on a utility to fix them. But the might be some more
> issues. I have three questions, but relating to RAID 1.
>
>
> 1. We have historically paired entire disks when we do RAID1, not
> partitions (we have never supported multiple file system partitions on one
> disk, because it didn't make sense from a performance standpoint). I believe
> the current initialization uses the same DiskGUID in the GPT header for both
> disks. I'm assuming that is not going to work properly. Is that correct?
>
Herbie,
I'm not sure that a unique DiskGUID is required for RAID1 given the disks are
mirrors. I think the ask is that each unique GPT (some software has to create
it) always gets a new GUID/UUID.
> 2. The spec also seems to say that the UniquePartitionGUID should also
> be different for RAID 1 pairs. Is that correct?
>
Same as DiskGUID is it a true mirror or unique disk? In a practical sense if
some one could bit copy a disk you could have duplicates. The hope is that any
software that is GPT aware would fix up the Unique GUID/UUID values as part of
the cloning operation.
> 3. We have learned over the years that one doesn't allocate an entire
> disk for a RAID (because one may have to replace a drive and replacement may
> not come with exactly the same ending LBA). We are currently leaving off
> some space at the end. When we do that, we are not putting the backup GPT
> header at the last LBA the devices. By my reading of the spec, that is a
> mistake. I do believe the spec allows me to leave a large gap between the
> LastUsableLBA in the backup GPT header with the backup table placed anywhere
> within that gap. Is that correct?
>
There has been language added over the years to try to help people deal with
issues like this. The ATA8-ACS language and this section:
"To avoid the need to determine the physical block size and the optimal
transfer length granularity, software may align GPT partitions at significantly
larger boundaries. For example, assuming logical block 0 is aligned, it may use
LBAs that are multiples of 2,048 to align to 1,048,576 byte (1 MiB) boundaries,
which supports most common physical block sizes and RAID stripe sizes."
I think the "software may align GPT partitions at significantly larger
boundaries." in the section above grants you a lot of latitude about how you
layout the disks.
Caveat Emptor if you need to be interoperable with other chunks of software as
there can be extra non-spec assumptions that leak into implementations. The
last one that I got hit by was most of the EFI code in the world require a
protective MBR, but the spec uses may (not required) when talking about if a
protective MBR is required.
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c#L265
//
// Verify that the Protective MBR is valid
//
for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
) {
break;
}
}
if (Index == MAX_MBR_PARTITIONS) {
goto Done;
}
Thanks,
Andrew Fish
> Thanks in advance for your guidance.
> Herbie Robinson
> Software Architect
> Stratus Technologies | www.stratus.com
> 5 Mill and Main Place, Suite 500 | Maynard, MA 01754
> T: +1-978-461-7531 | E: herbie.robin...@stratus.com
> [Stratus Technologies]<http://go.stratus.com/US>
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] gRT->SetVariable ACCESS DENIED error
Toan, What arguments did you pass to gRT->SetVariable()? What implementation did you test on? In general there are "wiggle words" in the UEFI Spec that make it legal to return other error codes. Back in the day when NOR FLASH was expensive and EFI was size constrained we did not want to have to filter every return value from a lower level to convert it to a spec required return code. Thanks, Andrew Fish > On Jul 3, 2018, at 2:10 AM, Toan Le manh wrote: > > Dear all, > > I'm facing the Status EFI_ACCESS_DENIED when using gRT->SetVariable() > method. > There is no description of this returned status for SetVariable() in UEFI > spec. > Have you ever faced this type of error? Could you please give me any idea > on how this happen? > Sorry for any inconvenience, I'm newbie in EDK2. > > Thanks & Best Regards, > Toan > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question about memory map entries
> On Jun 30, 2018, at 5:02 AM, Rafael Machado > wrote: > > Hi everyone. Thanks for the answers! > In this case, I just executed 3 shell command: > > memmap >> before.txt > app.efi > memmap >> after.txt > > Does anyone could clarify what could cause a new entry to be created at the > memmap output command? There is fragmentation caused the Apps high usage of memory and this can cause a lot more entries. I guess the DXE Core might also need to allocate some extra pages to track the fragmentation of the memory pool caused by the App. > My understanding was that the entries at the memmap command reflect the GCD > (global coherence domain), that is something that should not change too > much after the system is already at BDS phase. It is not really showing you GCD, it is showing the UEFI memory map. GCD implies the memory is being used as DRAM by the CPU , the UEFI memory map tracks the type of allocation and what areas of memory are free. That usage patter is changed by your App running. > As mentioned, the > application does a lot of AllocatePool() FreePool() calls. And these calls > are, as far as I could understand, creating a lot of entries of type "BS_Data" > and "Available". > Shouldn't the bios allocation routines try to reuse the pools already used > and freed to avoid massing and fragmenting the memory? > > Besides that, we just found a system that hangs on the subsequent boot > after executing the application. The strange is that the system just hangs > if you do the following steps: > > 1 - execute the application: app.efi > 2 - exit the shell with the command: exit > 3 - boot hangs not presenting the shell prompt > > > In case you do the following steps the hang doesn't happen: > > 1 - execute the application: app.efi > 2 - shut down the system by pressing the power button > 3 - boots normally entering at the shell prompt > > Any idea about what could cause this strange behavior, and if this may have > some relation with the increase of the memmap output entries? A common bug is for an Application to not clean up something and have the resource get freed. For example the App starts a timer event, forgets to stop it and when the App exits the memory gets freed back and if some one else allocates that memory they overwrite the code that executes in the timer event and kaboom. Same goes for publishing a protocol, etc. Given the issue is only with your App I'd focus on the App and not the delta in the memory map. On thing that may be helpful is to turn on this property it will cause the freed pool to get filled with 0xAF. 0xAFAFAFAFAFAFAFAF will GP fault if it is used as a memory address so this helps catch using freed resources closer to the source. PcdDebugPropertyMask set DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED Thanks, Andrew Fish > (maybe > something related with the MemoryTypeInformation information that seems to > be saved to make the subsequent boots easier from the bios perspective. > This guess is based on [1] page 19, that explains the creation of the > BIN.DXE, but things are a little dark to me yet. Not sure if my > understanding is correct.) > > [1] > https://firmware.intel.com/sites/default/files/resources/A_Tour_Beyond_BIOS_Memory_Map_in%20UEFI_BIOS.pdf > > Thanks and Regards > Rafael R. Machado > > Em sex, 29 de jun de 2018 às 22:31, Ni, Ruiyu escreveu: > >> Yes. >> Check the PCD PcdShellMaxHistoryCommandCount (0x20) which sets >> the maximum command history. >> The memmap output should be stable after you run more than >> 0x20 commands. >> >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Yao, >>> Jiewen >>> Sent: Saturday, June 30, 2018 3:28 AM >>> To: Rafael Machado ; edk2- >>> de...@lists.01.org >>> Subject: Re: [edk2] Question about memory map entries >>> >>> Shell itself may allocate internal buffer to save something, such as >> history. >>> >>> Thank you >>> Yao Jiewen >>> >>>> -Original Message- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>> Rafael Machado >>>> Sent: Friday, June 29, 2018 12:06 PM >>>> To: edk2-devel@lists.01.org >>>> Subject: [edk2] Question about memory map entries >>>> >>>> Hi everyone >>>> >>>> I have a question related to the memory map entries. >>>> Doing some tests, we noticed that if I have an application that has a >>>> lot of allocatepool() and freepool() calls, when this app is closed >>>>
Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: AP uses memory preceding IDT to store CpuMpData
%cr8,%rax >>626f: 50 push %rax >>6270: 0f 20 e0mov%cr4,%rax >>6273: 48 0d 08 02 00 00 or $0x208,%rax >>6279: 0f 22 e0mov%rax,%cr4 >>627c: 50 push %rax >>627d: 0f 20 d8mov%cr3,%rax >>6280: 50 push %rax >>6281: 0f 20 d0mov%cr2,%rax >>6284: 50 push %rax >>6285: 48 31 c0xor%rax,%rax >>6288: 50 push %rax >>6289: 0f 20 c0mov%cr0,%rax >>628c: 50 push %rax >>628d: 0f 21 f8mov%db7,%rax < here >>6290: 50 push %rax >>6291: 0f 21 f0mov%db6,%rax >>6294: 50 push %rax >>6295: 0f 21 d8mov%db3,%rax >>6298: 50 push %rax >>6299: 0f 21 d0mov%db2,%rax >>629c: 50 push %rax >>629d: 0f 21 c8mov%db1,%rax >>62a0: 50 push %rax >>62a1: 0f 21 c0mov%db0,%rax >>62a4: 50 push %rax >>62a5: 48 81 ec 00 02 00 00sub$0x200,%rsp >>62ac: 48 89 e7mov%rsp,%rdi >>62af: 0f ae 07fxsave (%rdi) >>62b2: fc cld >>62b3: ff 75 10pushq 0x10(%rbp) >>62b6: 48 8b 4d 08 mov0x8(%rbp),%rcx >>62ba: 48 89 e2mov%rsp,%rdx >>62bd: 48 83 ec 28 sub$0x28,%rsp >>62c1: e8 61 0c 00 00 callq 6f27 >> 62c2: R_X86_64_PC32 CommonExceptionHandler-0x4 >>62c6: 48 83 c4 28 add$0x28,%rsp >>62ca: fa cli >>62cb: 48 83 c4 08 add$0x8,%rsp >>62cf: 48 89 e6mov%rsp,%rsi >>62d2: 0f ae 0efxrstor (%rsi) >>62d5: 48 81 c4 00 02 00 00add$0x200,%rsp >>62dc: 48 83 c4 30 add$0x30,%rsp >>62e0: 58 pop%rax >>62e1: 0f 22 c0mov%rax,%cr0 >>62e4: 48 83 c4 08 add$0x8,%rsp >>62e8: 58 pop%rax >>62e9: 0f 22 d0mov%rax,%cr2 >>62ec: 58 pop%rax >>62ed: 0f 22 d8mov%rax,%cr3 >>62f0: 58 pop%rax >>62f1: 0f 22 e0mov%rax,%cr4 >>62f4: 58 pop%rax >>62f5: 44 0f 22 c0 mov%rax,%cr8 >>62f9: 8f 45 28popq 0x28(%rbp) >>62fc: 48 83 c4 30 add$0x30,%rsp >>6300: 8f 45 18popq 0x18(%rbp) >>6303: 58 pop%rax >>6304: 58 pop%rax >>6305: 58 pop%rax >>6306: 8e c0 mov%eax,%es >>6308: 58 pop%rax >>6309: 8e d8 mov%eax,%ds >>630b: 8f 45 20popq 0x20(%rbp) >>630e: 8f 45 38popq 0x38(%rbp) >>6311: 5f pop%rdi >>6312: 5e pop%rsi >>6313: 48 83 c4 08 add$0x8,%rsp >>6317: 8f 45 30popq 0x30(%rbp) >>631a: 5b pop%rbx >>631b: 5a pop%rdx >>631c: 59 pop%rcx >>631d: 58 pop%rax >>631e: 41 58 pop%r8 >>6320: 41 59 pop%r9 >>6322: 41 5a pop%r10 >>6324: 41 5b pop%r11 >>6326: 41 5c pop%r12 >>6328: 41 5d pop%r13 >>632a: 41 5e pop%r14 >>632c: 41 5f pop%r15 >>632e: 48 89 ecmov%rbp,%rsp >>6331: 5d
Re: [edk2] 答复: Is the PEI Core MP Safe? UefiCpuPkg seems to think so calling GetFirstGuidHob on the APs?
Jeff,
I forgot to mention I found this issue by inspection, but I I'm chasing 2 MP
issues in our internal code base. I'm not sure if it is the UefiCpuPkg code,
the consumers code, or something else that is causing the issues.
1) I'm seeing an intermittent issue in PEI and it looks like one of the APs is
getting disabled, and a required configuration step is being skipped.
2) I turned on the mwait AP Idle (I also add BSP mwait idle) and one of our
very complicated DXE MP functions started failing.
I'm hoping to get an ITP (JTAG debugger) setup next week and get more info on
what is happening.
Thanks,
Andrew Fish
> On Jun 21, 2018, at 11:52 PM, Fan Jeff wrote:
>
> Andrew,
>
> Not all services are permitted for AP routines. For example, MP->WhoAmI()
> could be invoked by AP by specified
>
> Current implementation should be safe. I also agree with IDT entry solution,
> as we did in DebugAgentLib.
>
> Thanks!
> Jeff
>
> 发件人: Andrew Fish<mailto:af...@apple.com>
> 发送时间: 2018年6月21日 11:25
> 收件人: Ni, Ruiyu<mailto:ruiyu...@intel.com>
> 抄送: edk2-devel<mailto:edk2-devel@lists.01.org>
> 主题: Re: [edk2] Is the PEI Core MP Safe? UefiCpuPkg seems to think so calling
> GetFirstGuidHob on the APs?
>
>
>
>> On Jun 20, 2018, at 8:06 PM, Ni, Ruiyu wrote:
>>
>> Andrew,
>> Good catch! It does break the rule that AP shouldn't call PEI services.
>> But considering the specific case, it should be safe.
>> Because:
>> 1. HOB only stores a pointer to the buffer that contains all the MP
>> information.
>> 2. BSP modifies the HOB by only appending data to the end. It may modifies
>> some HOB content. But MpInitLib
>> implementation itself doesn't modify the pointer value stored in HOB.
>>
>
> Ray,
>
> I think the should be safe is also making assumptions about the debug and a
> few other library instances that got tested against. It is not really an
> architectural guaranty against the library classes that could be linked. We
> don't use the default
>
> It would be good to use an IDT entry, or optionally a global variable if
> memory is present, longer term.
>
> Thanks,
>
> Andrew Fish
>
>> In PEI environment where global variable is read-only, it's hard to not rely
>> on HOB.
>> I guess that's the reason of today's tricky implementation.
>>
>> Thanks/Ray
>>
>>> -Original Message-
>>> From: edk2-devel On Behalf Of Andrew
>>> Fish
>>> Sent: Thursday, June 21, 2018 1:23 AM
>>> To: edk2-devel
>>> Subject: [edk2] Is the PEI Core MP Safe? UefiCpuPkg seems to think so
>>> calling
>>> GetFirstGuidHob on the APs?
>>>
>>> Is there some MP safe contract with the PEI Core implementation I don't
>>> know about?
>>>
>>> Looks like the APs are calling PeiServicesGetHobList() to figure out "who
>>> they
>>> are"? How does this work? Or am I missing something?
>>>
>>>
>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpIni
>>> tLib/MpLib.c#L1945
>>>
>>> /**
>>> This return the handle number for the calling processor. This service may
>>> be
>>> called from the BSP and APs.
>>> @param[out] ProcessorNumber Pointer to the handle number of AP.
>>> The range is from 0 to the total number of
>>> logical processors minus 1. The total number of
>>> logical processors can be retrieved by
>>> MpInitLibGetNumberOfProcessors().
>>> @retval EFI_SUCCESS The current processor handle number was
>>> returned
>>> in ProcessorNumber.
>>> @retval EFI_INVALID_PARAMETER ProcessorNumber is NULL.
>>> @retval EFI_NOT_READY MP Initialize Library is not initialized.
>>> **/
>>> EFI_STATUS
>>> EFIAPI
>>> MpInitLibWhoAmI (
>>> OUT UINTN*ProcessorNumber
>>> )
>>> {
>>> CPU_MP_DATA *CpuMpData;
>>>
>>> if (ProcessorNumber == NULL) {
>>> return EFI_INVALID_PARAMETER;
>>> }
>>>
>>> CpuMpData = GetCpuMpData ();
>>>
>>> return GetProcessorNumber (CpuMpData, ProcessorNumber); }
>>>
>>>
>>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpIni
>>> tLib/PeiMpLib.c#L34
>>>
>>> /**
>>> Get pointer to CPU MP Data structure.
>>&
Re: [edk2] Is the PEI Core MP Safe? UefiCpuPkg seems to think so calling GetFirstGuidHob on the APs?
> On Jun 20, 2018, at 8:06 PM, Ni, Ruiyu wrote:
>
> Andrew,
> Good catch! It does break the rule that AP shouldn't call PEI services.
> But considering the specific case, it should be safe.
> Because:
> 1. HOB only stores a pointer to the buffer that contains all the MP
> information.
> 2. BSP modifies the HOB by only appending data to the end. It may modifies
> some HOB content. But MpInitLib
> implementation itself doesn't modify the pointer value stored in HOB.
>
Ray,
I think the should be safe is also making assumptions about the debug and a few
other library instances that got tested against. It is not really an
architectural guaranty against the library classes that could be linked. We
don't use the default
It would be good to use an IDT entry, or optionally a global variable if memory
is present, longer term.
Thanks,
Andrew Fish
> In PEI environment where global variable is read-only, it's hard to not rely
> on HOB.
> I guess that's the reason of today's tricky implementation.
>
> Thanks/Ray
>
>> -Original Message-
>> From: edk2-devel On Behalf Of Andrew
>> Fish
>> Sent: Thursday, June 21, 2018 1:23 AM
>> To: edk2-devel
>> Subject: [edk2] Is the PEI Core MP Safe? UefiCpuPkg seems to think so calling
>> GetFirstGuidHob on the APs?
>>
>> Is there some MP safe contract with the PEI Core implementation I don't
>> know about?
>>
>> Looks like the APs are calling PeiServicesGetHobList() to figure out "who
>> they
>> are"? How does this work? Or am I missing something?
>>
>>
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpIni
>> tLib/MpLib.c#L1945
>>
>> /**
>> This return the handle number for the calling processor. This service may
>> be
>> called from the BSP and APs.
>> @param[out] ProcessorNumber Pointer to the handle number of AP.
>> The range is from 0 to the total number of
>> logical processors minus 1. The total number of
>> logical processors can be retrieved by
>> MpInitLibGetNumberOfProcessors().
>> @retval EFI_SUCCESS The current processor handle number was
>> returned
>> in ProcessorNumber.
>> @retval EFI_INVALID_PARAMETER ProcessorNumber is NULL.
>> @retval EFI_NOT_READY MP Initialize Library is not initialized.
>> **/
>> EFI_STATUS
>> EFIAPI
>> MpInitLibWhoAmI (
>> OUT UINTN*ProcessorNumber
>> )
>> {
>> CPU_MP_DATA *CpuMpData;
>>
>> if (ProcessorNumber == NULL) {
>>return EFI_INVALID_PARAMETER;
>> }
>>
>> CpuMpData = GetCpuMpData ();
>>
>> return GetProcessorNumber (CpuMpData, ProcessorNumber); }
>>
>>
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpIni
>> tLib/PeiMpLib.c#L34
>>
>> /**
>> Get pointer to CPU MP Data structure.
>> @return The pointer to CPU MP Data structure.
>> **/
>> CPU_MP_DATA *
>> GetCpuMpData (
>> VOID
>> )
>> {
>> CPU_MP_DATA *CpuMpData;
>>
>> CpuMpData = GetCpuMpDataFromGuidedHob ();
>> ASSERT (CpuMpData != NULL);
>> return CpuMpData;
>> }
>>
>> https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpIni
>> tLib/MpLib.c#L2302
>>
>>
>> /**
>> Get pointer to CPU MP Data structure from GUIDed HOB.
>> @return The pointer to CPU MP Data structure.
>> **/
>> CPU_MP_DATA *
>> GetCpuMpDataFromGuidedHob (
>> VOID
>> )
>> {
>> EFI_HOB_GUID_TYPE *GuidHob;
>> VOID*DataInHob;
>> CPU_MP_DATA *CpuMpData;
>>
>> CpuMpData = NULL;
>> GuidHob = GetFirstGuidHob ();
>> if (GuidHob != NULL) {
>>DataInHob = GET_GUID_HOB_DATA (GuidHob);
>>CpuMpData = (CPU_MP_DATA *) (*(UINTN *) DataInHob);
>> }
>> return CpuMpData;
>> }
>>
>> Thanks,
>>
>> Andrew Fish
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Query about variable initialization
> On Jun 20, 2018, at 12:01 PM, Ard Biesheuvel > wrote: > > On 20 June 2018 at 20:57, Laszlo Ersek <mailto:ler...@redhat.com>> wrote: >> On 06/20/18 20:03, Ard Biesheuvel wrote: >>> On 20 June 2018 at 19:48, Evan Lloyd wrote: >>>> Hi Ard, Leif. >>>> I've noticed a number of comments like Ard's recent "We don't permit >>>> initialized automatic variables.", >>>> and similar changes have been made to Sami's AcpiView. Note: I'm not >>>> objecting to doing it the way maintainers prefer, which is why this is not >>>> a response. >>>> >>>> My understanding was that the CCS was changed some time back to remove the >>>> restriction on initializing variables (and I further think I remember Leif >>>> being a prime mover in that). >>> >>> I don't remember, to be honest. But I think it is a stupid rule, and >>> so if we haven't already, I hope we can get rid of it. >>> >>> IIRC, this limitation had something to do with a particularly nice >>> exhibit in the Tianocore toolchain museum that generated bigger >>> binaries for initialized automatic variables (as compared to >>> assignments performed separately). But let's not get into the >>> toolchain situation, shall we? >> >> One special case of initialization is when the variable in question has >> structure type. For such initialization the compiler may generate calls >> to internal helper functions (memset and friends), and then the module >> fails to link. I've seen this myself earlier, although I can't tell >> whether on gcc-4.4 or gcc-4.8. >> > > That is a very good point. Note that this does not affect ARM, given > that we already have to provide the AEABI intrinsics (and memset and > memcpy for GCC), but I can see how other architectures may be bitten > by this. > > I suppose the compiler is free to apply the same optimization to a > block of automatic POD type variables, although I'd be surprised if > that ever occurs in practice. What I find is it breaks NOOPT builds, -O0 for clang specifically. Especially for projects that don't have a global NOOPT build due to FLASH Size. That common place I hit this it trying to turn off optimization to walk some code in the debugger to understand how it works and now it does not link. Usually I'm doing something like this in the INF, or the equivalent in the DSC, and boom. [BuildOptions] XCODE:*_*_*_CC_FLAGS = -O0 -fno-lto Thanks, Andrew Fish > ___ > edk2-devel mailing list > edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> > https://lists.01.org/mailman/listinfo/edk2-devel > <https://lists.01.org/mailman/listinfo/edk2-devel> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Is the PEI Core MP Safe? UefiCpuPkg seems to think so calling GetFirstGuidHob on the APs?
Is there some MP safe contract with the PEI Core implementation I don't know
about?
Looks like the APs are calling PeiServicesGetHobList() to figure out "who they
are"? How does this work? Or am I missing something?
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpInitLib/MpLib.c#L1945
/**
This return the handle number for the calling processor. This service may be
called from the BSP and APs.
@param[out] ProcessorNumber Pointer to the handle number of AP.
The range is from 0 to the total number of
logical processors minus 1. The total number of
logical processors can be retrieved by
MpInitLibGetNumberOfProcessors().
@retval EFI_SUCCESS The current processor handle number was
returned
in ProcessorNumber.
@retval EFI_INVALID_PARAMETER ProcessorNumber is NULL.
@retval EFI_NOT_READY MP Initialize Library is not initialized.
**/
EFI_STATUS
EFIAPI
MpInitLibWhoAmI (
OUT UINTN*ProcessorNumber
)
{
CPU_MP_DATA *CpuMpData;
if (ProcessorNumber == NULL) {
return EFI_INVALID_PARAMETER;
}
CpuMpData = GetCpuMpData ();
return GetProcessorNumber (CpuMpData, ProcessorNumber);
}
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpInitLib/PeiMpLib.c#L34
/**
Get pointer to CPU MP Data structure.
@return The pointer to CPU MP Data structure.
**/
CPU_MP_DATA *
GetCpuMpData (
VOID
)
{
CPU_MP_DATA *CpuMpData;
CpuMpData = GetCpuMpDataFromGuidedHob ();
ASSERT (CpuMpData != NULL);
return CpuMpData;
}
https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/Library/MpInitLib/MpLib.c#L2302
/**
Get pointer to CPU MP Data structure from GUIDed HOB.
@return The pointer to CPU MP Data structure.
**/
CPU_MP_DATA *
GetCpuMpDataFromGuidedHob (
VOID
)
{
EFI_HOB_GUID_TYPE *GuidHob;
VOID*DataInHob;
CPU_MP_DATA *CpuMpData;
CpuMpData = NULL;
GuidHob = GetFirstGuidHob ();
if (GuidHob != NULL) {
DataInHob = GET_GUID_HOB_DATA (GuidHob);
CpuMpData = (CPU_MP_DATA *) (*(UINTN *) DataInHob);
}
return CpuMpData;
}
Thanks,
Andrew Fish
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
