Re: [edk2-devel] Edk2 BaseTools Patches.

ndencies, given they may been caused by a faulty high level design decision made long ago. At some point refactoring the build system from the top might be the right approach. Thanks, Andrew Fish > -Michael > >   <> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io&g

Re: [edk2-devel] [PATCH v1 1/1] CryptoPkg/IntrinsicLib: Fix CLANG38 IA32 build problem

> On Jun 4, 2019, at 11:33 PM, Xiaoyu Lu wrote: > > Hi Liming, > >> -Original Message- >> From: Gao, Liming >> Sent: Wednesday, June 5, 2019 1:57 PM >> To: devel@edk2.groups.io ; Lu, XiaoyuX >> mailto:xiaoyux...@intel.com>> >> Cc: Bi, Dandan

Re: [edk2-devel] Edk2 BaseTools Patches.

> On May 30, 2019, at 9:37 AM, Leif Lindholm wrote: > > Thanks Bob, Christian, > > On Thu, May 30, 2019 at 03:06:48PM +, Feng, Bob C wrote: >> Thanks Christian. I add some short description for the patches. >> >> These 5 patches are all for binary cache feature. >> >> [Patch V4 2/2]

Re: [edk2-devel] Help needed in building UEFI qcow2 images

serve > > > > > > /usr/libexec/qemu-kvm > > > > > > [ADDRESS] > > > > > > > > > > > > > > > > > > > > > > > >primary='yes'/> > >

Re: [edk2-devel] Help needed in building UEFI qcow2 images

Tom, Looks like the mailing list stripped your attachment. Thanks, Andrew Fish > On May 22, 2019, at 4:19 AM, Tomas Pilar (tpilar) > wrote: > > Hi Pavan, > > I am currently playing around with setting up a OVMF based test framework > myself. You likely need to tell qemu to use OVMF as

Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

> On Apr 3, 2019, at 8:42 PM, Ni, Ray wrote: > > Mike, Laszlo, > It's a good idea to store the shell binaries into the assets of each stable > tag. > > If we go in this way, it means "build" requires network connection to > download the > shell binary from the assets of a certain release. >

Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

> On Apr 4, 2019, at 3:45 AM, Laszlo Ersek wrote: > > On 04/04/19 06:09, Andrew Fish wrote: >> >> >>> On Apr 3, 2019, at 8:42 PM, Ni, Ray wrote: >>> >>> Mike, Laszlo, >>> It's a good idea to store the shell binaries into the assets of each stable >>> tag. >>> >>> If we go in this way, it

Re: [edk2-devel] [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

> On Apr 4, 2019, at 9:06 AM, Laszlo Ersek wrote: > > On 04/04/19 17:10, Andrew Fish wrote: >> >> >>> On Apr 4, 2019, at 3:45 AM, Laszlo Ersek wrote: >>> >>> On 04/04/19 06:09, Andrew Fish wrote: > On Apr 3, 2019, at 8:42 PM, Ni, Ray wrote: > > Mike, Laszlo, >

Re: [edk2-devel] Why is specified -mno-sse on clang x64?

Gary, The edk2 is freestanding UEFI firmware and the runtime does not support floating point exceptions. I think a long time ago there was an optimization bug and the -mno-sse fixed it. The UEFI x64 ABI is Windows like and not Sys V like. Thanks, Andrew Fish > On Apr 4, 2019, at 10:13

Re: [edk2-devel] Why is specified -mno-sse on clang x64?

> On Apr 4, 2019, at 1:09 PM, Gary Zibrat via Groups.Io > wrote: > > It seems like the "-mno-mmx -msoft-float -mno-implicit-float" part of the > flags should be enough to handle that now. > Is it ok to take -mno-sse out (in my local branch) for new versions of clang > without having to

Re: [edk2-devel] [PATCH 02/10] MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

> On Apr 17, 2019, at 3:29 AM, Laszlo Ersek wrote: > > Hi Andrew, > > On 04/17/19 01:25, Andrew Fish wrote: >> >> >>> On Apr 16, 2019, at 11:48 AM, Jordan Justen >>> wrote: >>> >>> On 2019-04-16 03:59:48, Laszlo Ersek wrote: On 04/16/19 11:04, Jordan Justen wrote: > On

Re: [edk2-devel] [PATCH v1] MdeModulePkg/DxeCore: Please static checker for false report

> On Apr 22, 2019, at 3:02 PM, Ard Biesheuvel wrote: > > On Mon, 22 Apr 2019 at 23:53, Michael D Kinney > wrote: >> >> Ard, >> >> This seems to be a common limitation seen in some >> static analyzers. We have not found a workaround >> that does not involve code changes to quiet the >>

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

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

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

c, but as a customer I'd much rather that the Firmware update actually complete if at all possible. Thanks, Andrew Fish >   <> > <>From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of

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

> On Apr 26, 2019, at 6:55 AM, rebe...@bluestop.org wrote: > > On 2019-04-24 13:17, Laszlo Ersek wrote: >> >> And, again, that's exactly how the sender is displayed to me by >> Thunderbird, in my list folder only: >> >> From: Rebecca via Groups.Io >> >> Again, in email that I get directly

Re: [edk2-devel] [Patch v3 2/3] NetworkPkg: Add DSC/FDF include segment files to NetworkPkg.

> On May 6, 2019, at 11:23 AM, Laszlo Ersek wrote: > > On 05/05/19 17:21, Liming Gao wrote: >> Reply for the comments in the patch content. >>> -Original Message- >>> From: Laszlo Ersek [mailto:ler...@redhat.com] >>> Sent: Monday, April 29, 2019 9:05 PM >>> To: devel@edk2.groups.io;

Re: [edk2-devel] [PATCH V2] BaseTools:improve code to support C files with .C suffixes

This brings up a question? Do we tests on a file system that is case sensitive? Is this just lack of a test case? Thanks, Andrew Fish > On May 6, 2019, at 7:22 PM, Fan, ZhijuX wrote: > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1773 > > Build break if C file suffixes of named .C

Re: [edk2-devel] [PATCH V2] BaseTools:improve code to support C files with .C suffixes

> On May 7, 2019, at 7:40 AM, Leif Lindholm wrote: > > Hi Fan Zhiju, > > But where does the string come from that contains a .C suffix? > Is the tool internally converting things to uppercase, or is some > source file in the build incorrectly named? > Leif, Our build system defines .C as

Re: [edk2-devel] [PATCH V2] BaseTools:improve code to support C files with .C suffixes

> On May 8, 2019, at 5:08 AM, Leif Lindholm wrote: > > Hi Fan Zhiju, > > I understand your reasoning, but that strengthens my view that we > should leave this change out. > > Actually, could we consider *dropping* support for .C files > altogether, since we are striving to support multiple

Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain for new LLVM/CLANG8

> On May 20, 2019, at 6:47 AM, Liming Gao wrote: > > Jordan: > >> -Original Message- >> From: Justen, Jordan L >> Sent: Monday, May 20, 2019 4:15 AM >> To: Ard Biesheuvel ; Gao, Liming >> ; edk2-devel-groups-io >> Subject: Re: [edk2-devel] [Patch 0/7] Add new CLANG8ELF tool chain

Re: [edk2-devel] [PATCH V2] ShellPkg/Type.c: Add value check before (LoopVar - 1)

Reviewed-by: Andrew Fish Thanks, Andrew Fish > On Jul 16, 2019, at 9:58 AM, Carsey, Jaben wrote: > > Reviewed-by: Jaben Carsey > > > Thanks > -Jaben > >> -Original Message- >> From: Gao, Zhichao >> Sent: Tuesday, July 16, 2019 2:12 AM >> To:

Re: [edk2-devel] [Patch V4 06/10] EmulatorPkg: Fix XCODE5 lldb issues

Tested-by: Andrew Fish I tested the XCODE builds of the emulator and made sure that source level debugging worked probably for builds that generate symbols. Thanks, Andrew Fish > On Aug 16, 2019, at 8:09 AM, Michael D Kinney > wrote: > > Jordan, > > It is not a typo. > > Andrew

[edk2-devel] BaseTools/BinWrappers question?

Why does BaseTools/BinWrappers/WindowsLike only have wrappers for Python commands, while BaseTools/BinWrappers/PosixLike has wrappers for C based tools too? Thanks, Andrew Fish -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45832):

Re: [edk2-devel] Determining TSC frequency programmatically

Vitaly, As Mike mentioned platforms can know more info about how they are constructed thus you may not want to have a lot of generic discovery code floating about if you don't really need it. One option could be to pass up the TSC Frequency/Period via some EFI mechanism so generic code can

Re: [edk2-devel] BaseTools/BinWrappers question?

s. the wrappers? Thanks, Andrew Fish > Thanks > Liming >> -Original Message- >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew >> Fish via Groups.Io >> Sent: Saturday, August 17, 2019 1:01 AM >> To: devel@edk2.groups.io >>

[edk2-devel] gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate definition confusion?

I was tracking down a Platform C state bug and I noticed the platform code was using this definition [1] for PcdCpuApTargetCstate and wrote that actual value used for Mwait. But the MpInitLIb seems to assume that PcdCpuApTargetCstate is eax[7:4] and it shifts the data left. This ends up with

Re: [edk2-devel] static data in dxe_runtime modules

> On Aug 14, 2019, at 8:16 AM, Laszlo Ersek wrote: > > On 08/13/19 13:23, Roman Kagan wrote: >> On Tue, Aug 13, 2019 at 11:10:27AM +0200, Laszlo Ersek wrote: >>> On 08/12/19 20:43, Roman Kagan wrote: On Fri, Aug 09, 2019 at 04:07:00PM +, Roman Kagan via Groups.Io wrote: > On Thu,

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

> On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io > wrote: > > Mike, > > I missed your message while writing mine, but I am afraid I disagree with the > functional macro usage for this feature. > > I explicitly quoted C standard static_assert definition in one of my previous >

Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro

> On Aug 16, 2019, at 5:01 PM, Rebecca Cran wrote: > > On 2019-08-16 16:58, Andrew Fish via Groups.Io wrote: >> >> I'm all for modernization of the C code as long we are thoughtful >> about compatibility. For example I still see that VS2008 is a >> supported

Re: [edk2-devel] Memory Operation Mode

> On Aug 21, 2019, at 11:55 AM, Rafael Machado > wrote: > > Hi everyone > > I would like to ask for some help regarding one question. > How do I know how the memory communication was set by the BIOS/MRC/FSP during > the initialization process? > For example, I would like to know if the

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim, Sounds like you are on to something The Unix side [1] does a dlclose() to undo a dlsym(). I seem to remember this code flow is very very old, I wonder if it is possible to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and wrote a debugger script to load

Re: [edk2-devel] Patch List for 201908 stable tag

My vote is Yes. Thanks, Andrew Fish > On Aug 20, 2019, at 10:02 AM, Ni, Ray wrote: > > Ray, > > With your review, my vote is yes. > > Mike -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46120):

Re: [edk2-devel] [Patch][edk2-stable201908 0/2] EmulatorPkg/Win/Host: Fix image unload regression

Mike, I'm OK with it going in. Thanks, Andrew Fish > On Aug 26, 2019, at 2:01 PM, Kinney, Michael D > wrote: > > Ray, > > Laszlo and I are OK with this change going into the stable tag. > > I would like to a response from Andrew or Leif. > > Mike > >> -Original Message- >> From:

Re: [edk2-devel] git submodule update --init --recursive

com >> Sent: Saturday, August 24, 2019 6:24 AM >> To: devel@edk2.groups.io; af...@apple.com >> Subject: Re: [edk2-devel] git submodule update --init --recursive >> >> On 2019-08-23 14:41, Andrew Fish via Groups.Io wrote: >>> I was following the instructions

Re: [edk2-devel] git submodule update --init --recursive

e developer know when it is required. > > Mike >   <> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of > Andrew Fish via Groups.Io > Sent: Monday, August 26, 2019 2:59 PM

[edk2-devel] git submodule update --init --recursive

I was following the instructions on how to build OVMF and my build failed. It looks like the reason it failed was because I did not do a `git submodule update --init --recursive`. It would be good if we could make how to clone the edk2 instructions a bit more obvious. Thanks, Andrew Fish

Re: [edk2-devel] Mappings and StdLib

Tim, I don't know about the plans with the StdLib, but I do remember a long time ago with the old shell there was a protocol that let you translate volume names (mappings) into handles and device paths. So you could write a simple library that has 2 styles of APIs: 1) Handle + FilePath in

Re: [edk2-devel] [PATCH 09/11] OvmfPkg/XenBusDxe: Fix NotifyExitBoot to avoid Memory Allocation Services

> On Sep 16, 2019, at 12:31 PM, Laszlo Ersek wrote: > > On 09/16/19 20:36, Andrew Fish wrote: >> >> >>> On Sep 16, 2019, at 10:36 AM, Laszlo Ersek wrote: >>> >>> On 09/13/19 16:50, Anthony PERARD wrote: This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid using the

Re: [edk2-devel] [PATCH 09/11] OvmfPkg/XenBusDxe: Fix NotifyExitBoot to avoid Memory Allocation Services

> On Sep 16, 2019, at 10:36 AM, Laszlo Ersek wrote: > > On 09/13/19 16:50, Anthony PERARD wrote: >> This patch fix the EVT_SIGNAL_EXIT_BOOT_SERVICES handler to avoid >> using the Memory Allocation Services. >> >> This comes with a new interface named RegisterExitCallback so that PV >>

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

> On Sep 17, 2019, at 1:06 PM, Ni, Ray wrote: > > Laszlo, > Thank you very much for this work. > They are quite helpful to detect potential issues. > > But without this specific patch being checked in, future break will still > happen. > I don't want it to be checked in ASAP because I know

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

> code.  > Ray, I'm flexible on the name, I was just trying to give a good example of what I was suggesting. Thanks, Andrew Fish > Thanks, > Ray > >> -----Original Message- >> From: devel@edk2.groups.io On Behalf Of Andrew Fish >> via Groups.Io >>

Re: [edk2-devel] [edk2] DxeIpl : create page table, occupied too much memory range

> On Sep 18, 2019, at 3:50 AM, Tiger Liu(BJ-RD) wrote: > > Hi, Laszlo: > Thanks for your reply! > > Is Using PcdUse5LevelPageTable also a method to reduce paging table's memory > requirement? > Tiger, No the 5-level page tables [1] are about increasing the size of the virtual addresses

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

> On Sep 18, 2019, at 1:41 AM, Laszlo Ersek wrote: > > On 09/17/19 22:22, Andrew Fish wrote: >> >> >>> On Sep 17, 2019, at 1:06 PM, Ni, Ray wrote: >>> >>> Laszlo, >>> Thank you very much for this work. >>> They are quite helpful to detect potential issues. >>> >>> But without this

Re: [edk2-devel] static data in dxe_runtime modules

> On Aug 7, 2019, at 10:29 AM, Laszlo Ersek wrote: > > ummm... not sure why, but I never got this email in my inbox. I only see > it in my list folder. I see myself addressed on it as: > > Laszlo Ersek via Groups.Io > > > which could be the reason. > >

Re: [edk2-devel] [Patch 0/2] UefiCpuPkg: Default avoid print.

> On Jul 31, 2019, at 9:34 AM, Brian J. Johnson wrote: > > On 7/31/19 7:43 AM, Laszlo Ersek wrote: >> (adding Mike) >> On 07/31/19 09:35, Eric Dong wrote: >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1984 >>> >>> Current debug message brings much restriction for the platform >>>

Re: [edk2-devel] [Patch 0/2] UefiCpuPkg: Default avoid print.

> On Aug 1, 2019, at 1:20 PM, Brian J. Johnson wrote: > > On 7/31/19 1:58 PM, Laszlo Ersek wrote: >> On 07/31/19 18:34, Brian J. Johnson wrote: >>> I do wonder if there would be a clean way to let a DebugLib instance >>> itself declare that AP_DEBUG() is safe. That way a platform would >>>

Re: [edk2-devel] Build New Package with EDKII OVMF

> On Aug 6, 2019, at 3:15 AM, via Groups.Io > wrote: > >Hello All, > >I am new to EDKII (UEFI) development. Cloned UDK2018 branch and modified > Conf/target.txt to build OVMF package. OVMF.fd boots up fine on QEMU > Shakthi, Conf/target.txt is just the default arguments for the

Re: [edk2-devel] [Patch 3/3] BaseTools/PatchCheck: Disable text conversion in 'git show'

> On Aug 8, 2019, at 2:08 PM, Michael D Kinney > wrote: > > Laszlo, > > This sounds like a good improvement. > > Do you have a recommended set of settings you would like > to see checked in to the root of each EDK II related > repository that would be required settings for all EDK II >

Re: [edk2-devel] [PATCH 0/3] Arm builds on Visual Studio

> On Sep 19, 2019, at 12:24 PM, Laszlo Ersek wrote: > > On 09/19/19 11:44, Leif Lindholm wrote: >> Hi Liming, >> >> On Thu, Sep 19, 2019 at 06:19:42AM +, Gao, Liming wrote: >>> I add my comments. >>> -Original Message- From: Baptiste Gerondeau

Re: [edk2-devel] [Patch 05/12] MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO functions

> On Sep 30, 2019, at 3:35 PM, Laszlo Ersek wrote: > > Hi Liming, > > On 09/27/19 09:46, Liming Gao wrote: >> __inline__ attribute will make the functions not be exposed as the >> library interface. It will cause CLANG9 compiler fail. >> >> Signed-off-by: Liming Gao >

Re: [edk2-devel] CR WhitleyRp BIOS build failure

Fei, I took a quick look and I did not see a Python stack trace. I'm not sure if your build wrapper ate it, or it does not exist? If I had to randomly guess there is some syntax error in your .INF file is crashing the Python that is parsing that INF file. Seems like you may have an issue with

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v2 09/29] MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.

> On Oct 2, 2019, at 11:14 AM, Abner Chang wrote: > > Thanks Leif, let me check with maintainers. > > Hi Mike and Liming, > How do you think about to use IoLibArm as the I/O lib instance for RISC-V > arch? I personally don't like to use IoLibArm.c in [Source.RISCV64] section, > instead I

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

> On Nov 4, 2019, at 11:42 PM, Ashish Singhal wrote: > > Hi Andrew, > > I have a use case where I install Load File protocol on a handle and want to > expose that as a boot option through platform boot manager driver as I need > it to have a custom description and custom option data along

Re: [edk2-devel] [edk2] NOOPT and PcdOptimizeCompilerEnable

e VS command > line warning. > > Thanks > Liming > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of > Andrew Fish via Groups.Io > Sent: Thursday, October 31, 2019 10:07 AM > To: deve

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

> On Nov 4, 2019, at 9:24 PM, Ashish Singhal wrote: > > Hi Ray, > > I did not see any example with which one can tell BDS not to enumerate a boot > option. Can you please point me to an example where a protocol (Block IO, > Simple FS or Load File) does not get enumerated as a boot option? >

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Ashish, Just to be clear on your definition of enumerate. In this case it means the Boot Manager lib that is just one of may implementations a platform could use to manage its boot options. 3rd party code, or an OS boot loader could try to boot your handle since by definition of the UEFI spec

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

> On Nov 5, 2019, at 7:34 PM, Jeff Brasen wrote: > > > Wouldn't having a variable that we create and delete on every boot put > unnecessary stress on the SPI-NOR that the variable store lives on? > What about the alternative approach where we allow the platform code to > modify the

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Either works for me too. I like the PDE ending a little more, but agree it is a little more obscure. > On Nov 11, 2019, at 8:39 AM, Leif Lindholm wrote: > > On Fri, Nov 08, 2019 at 03:34:59AM +, Ni, Ray wrote: >> Liming, >> PE is UEFI spec required executable binary format. I like CLANGPDB

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Either works for me too. I like the PDE ending a little more, but agree it is a little more obscure. > On Nov 11, 2019, at 8:39 AM, Leif Lindholm wrote: > > On Fri, Nov 08, 2019 at 03:34:59AM +, Ni, Ray wrote: >> Liming, >> PE is UEFI spec required executable binary format. I like CLANGPDB

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Leif, I think I proposed CLANG_PDB or CLANG_PECOFF. I seem to like CLANG_PDB as assuming the PDE debugging experience is awesome/exists on Linux and macOS is not a given. Thanks, Andrew Fish > On Nov 7, 2019, at 11:19 AM, Leif Lindholm wrote: > > Oops, sorry, missed this in search. > >

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

> On Nov 5, 2019, at 3:54 AM, Laszlo Ersek wrote: > > On 11/05/19 07:15, Andrew Fish via Groups.Io wrote: > >> You could also edit any existing variables that point to your Load File to >> make sure they follow the rules you care about? >> >> It is l

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

> On Nov 6, 2019, at 3:56 AM, Laszlo Ersek wrote: > > On 11/06/19 00:19, Jeff Brasen wrote: >> Wouldn't having a variable that we create and delete on every boot put >> unnecessary stress on the SPI-NOR that the variable store lives on? > > Yes, it most likely would. Should we write a BZ

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Ray, Is there an obvious hook point we could point Jeff and Ashish at? Long term it would be a good idea to have a Wiki page to give some guidance on how to customize the BDS. Thanks, Andrew Fish > On Nov 5, 2019, at 9:20 PM, Ni, Ray wrote: > > Andrew, > I agree with your opinion. > It’s

Re: [edk2-devel] Question regarding MMIO address space exposed from GetMemoryMap

Jon, Its a little confusing but gBS->GetMemoryMap () only returns information about DRAM and any address that requires a kernel virtual address mapping in EFI. The OS calls EFI Runtime Services from a kernel virtual mapping so the memory map is also involved in the hand shake to communicate

Re: [edk2-devel] [edk2] [EmulatorPkg] using __debugbreak()

Mike, On the Unix side the strategy was to launch via the debugger [1], and also pass EFI specific debugger scripts into the debuggers on launch. I've played with trick with OS apps by using CpuDeadLoop(). To get unstuck you just need to update Index to be non Zero. I've also used this

Re: [edk2-devel] [edk2] NOOPT and PcdOptimizeCompilerEnable

Liming, For gcc/clang if you repeat an argument the last argument wins. This is the default behavior and it does not warn, as it is designed to work with features like PcdOptimizeCompilerEnable. If VC++ warns for this behavior should we disable D9025 for VC++ so all the toolchains have the

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

> On Nov 7, 2019, at 12:37 PM, Leif Lindholm wrote: > > Hi Andrew, > > Yeah, I'm pretty easy with regards to what we change it to. > Although if we're bikeshedding, I would prefer not using _ in the > toolchain profile name. > > I'm ... optimistic ... it won't break any of my existing

Re: [edk2-devel] EDK2 Host-Based Unit Test RFC (Now with docs!)

Mike, I like and agree with your comments. On the UnitTestPkg(s) dependency issue I think it would make sense to move as much as possible into the *Pkg/Test/ ( *Pkg/HostLibrary, MdePkg/MdePkgTest.dsc, etc.) directory structure. It looks like for implementation specific tests we skip the Test

Re: [edk2-devel] [Patch 0/1] BaseTools: Using compiler to generate source code dependency files.

The .d is the default file name extension used by GCC for dependency files. Given the dependency files are in the build output and the makefiles reference them explicitly I'm not sure there is going to be lots of confusion. But I think it is likely the default dependency file name is mostly

Re: [edk2-devel] EDK2 UEFI Specification and Revision

The header in the EFI_SYSTEM_TABLE (gST) carries the UEFI Specification version. It is filled in by the DXE Core when it produces the EFI System Table. $ git grep EFI_SYSTEM_TABLE_REVISION MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:126:EFI_SYSTEM_TABLE_REVISION,

Re: [edk2-devel] [Patch 0/1] BaseTools: Using compiler to generate source code dependency files.

Bob, I was trying to point out the .d file extension also implies a C dependency file in Gcc world. So to me I would have picked .d. But other choices are OK too. > On Oct 28, 2019, at 6:12 PM, Feng, Bob C wrote: > >  > Yes. For Gcc and Clang, we can use –MMD –MF to generate > custom name

Re: [edk2-devel] [Patch v3 10/11] EmulatorPkg: Enable CLANG9 tool chain

Ray, Sorry I'm coming a little late to this and I'm confused. I have some questions? 1) Does CLANG9 imply CLANGPE? 2) Does CLANGPE work on Linux and macOS? Can you pass the Windows style arguments to CLANGPE linker on Linux and macOS? 3) For the EmulatorPkg don't you have the extra requirement

[edk2-devel] [staging/master]:master on edk2-staging is out of date.

I was looking at creating a staging branch to work on Bz2387. The README [1] for edk2-staging (about branch) mentions that edk2-staging/master tracks edk2/master, but I see it was last synced in June? I'm not clear on the process for updating the edk2-staging/master? It is not setup to

Re: [edk2-devel] build error

> On Dec 2, 2019, at 12:29 PM, Li, Jun J wrote: > > Hi, > Could you please help to take a look at the error? Thanks! > > : error C0DE: Unknown fatal error when processing > [c:\src\bios\intel\ServerRasPkg\Library\PlatMemTopoLib\SmmPlatMemTopologyLib.inf > [X64, VS2015x86, RELEASE]] > >

Re: [edk2-devel] EDK2 SimpleTextIn Backspace

Minh, What APIs are you using to do Console IO? At the EFI layer you don't think of SimpleTxtInEx/SimpleTextIn and SimpleTxtOut as a single console device. You need to think of them as the driver providing the service. So for example SimpleTxtInEx/SimpleTextIn could be produced by the USB

Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain

Liming, I'm OK with not regressing OVMF, I understand the concept of technical debt. I'd point out that this is likely a generic issue with the SecurityPkg that was worked around in OVMF. Also it looks to me like passing those flags violate the calling convention [1]. Maybe that is why the

Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES

> On Oct 10, 2019, at 4:17 PM, Lendacky, Thomas wrote: > > On 10/3/19 10:12 AM, Tom Lendacky wrote: >> >> >> On 10/3/19 5:32 AM, Laszlo Ersek wrote: >>> On 10/03/19 12:12, Laszlo Ersek wrote: >>> UINT32 ApEntryPoint; EFI_GUID SevEsFooterGuid; UINT16 Size; >>> >>>

[edk2-devel] OVMF is crashing for me in master

This is my flavor of OVMF: build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t XCODE5 It looks like I took an exception? Is it expected that an unhandled exception just hang in a dead loop? I would have expected some serial output about the failure? Looks like a divide by zero exception. The

Re: [edk2-devel] OVMF is crashing for me in master

el@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew > Fish via Groups.Io > Sent: Friday, October 11, 2019 5:12 AM > To: devel@edk2.groups.io; Pete Batard > Subject: [edk2-devel] OVMF is crashing for me in master > > This is my flavor of OVMF: build -p Ov

Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain -

> On Oct 9, 2019, at 7:44 AM, Gao, Liming wrote: > > Laszlo: > >> -Original Message- >> From: Laszlo Ersek >> Sent: Wednesday, October 9, 2019 9:44 PM >> To: Andrew Fish ; devel@edk2.groups.io >> Cc: Gao, Liming >> Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool

Re: [edk2-devel] [PATCH V2 8/9] MdeModulePkg/Variable: Add RT GetNextVariableName() cache support

> On Oct 3, 2019, at 1:52 PM, Kubacki, Michael A > wrote: > >>> -Done: >>> + mVariableRuntimeCacheReadLock = FALSE; >> >> >> Similar to the previous patch (7/9), >> if timeout occurs when acquiring the read lock, should this flag be set to >> FALSE in such case? >> > > Given that the

Re: [edk2-devel] [edk2-platforms][PATCH V1 0/3] Add FW Boot Media Device Indicator

Since I was around back in the Intel Tiano days and I've worked on all the PI specs I can share the history. The reset vector is a hardware thing. It is usually at the top or bottom of the address space. For x86 it is at the TOP of the ROM and that is why the FV has a VoluteTop file GUID that

Re: [edk2-devel] OVMF is crashing for me in master

> On Oct 11, 2019, at 9:33 AM, Laszlo Ersek wrote: > > Hi Andrew, > > On 10/11/19 15:13, Andrew Fish wrote: > >> I'm with Pete on this as my expectation would be the progress bar >> completes when you are done. I'd also point out that a common progress >> bar UI implementation is to show

Re: [edk2-devel] [PATCH 1/1] OvmfPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0

Pete, I agree I was also thinking that and forgot to mention it in my email. Not enough coffee in my system. Thanks, Andrew Fish > On Oct 11, 2019, at 8:24 AM, Pete Batard wrote: > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266 > > Independently of how we decide to address

Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES

Laszlo, For 2) this is very unfortunate. I think the root cause is for those of us who work on x86 hardware day to day we get programed that SEC/PEI is IA32 and DXE is X64, and this can lead to some unfortunate coding outcomes. I'm guessing this code probably got ported from the DXE CPU

Re: [edk2-devel] question about qemu+kvm+ovmf+winxp

Junhao FYI there is a regression in master for OVFM right now: https://bugzilla.tianocore.org/show_bug.cgi?id=2266 so you might be hitting that. Thanks, Andrew Fish > On Oct 11, 2019, at 11:13 PM, Junhao Gao wrote: > > > >> -Original Message- >> From: David Woodhouse

Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES

m: devel@edk2.groups.io <mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of > Andrew Fish via Groups.Io > Sent: Saturday, October 12, 2019 2:43 PM > To: devel@edk2.groups.io <mailto:devel@edk2.groups.i

Re: [edk2-devel] OVMF is crashing for me in master

> On Oct 11, 2019, at 4:53 AM, Laszlo Ersek wrote: > > On 10/11/19 06:59, Andrew Fish via Groups.Io wrote: >> Liming, >> >> Thanks for looking into this! >> >> Can someone also answer my question about the expected behavior of taking an >> exce

Re: [edk2-devel] OVMF is crashing for me in master

> On Oct 11, 2019, at 4:50 AM, Laszlo Ersek wrote: > > Hi, > > On 10/11/19 03:19, Liming Gao wrote: >> Andrew: >> I verify the change (2de1f611be06ded3a59726a4052a9039be7d459b >> MdeModulePkg/BdsDxe: Also call PlatformBootManagerWaitCallback on 0) >> in Emulator. >> It works, because PCD

Re: [edk2-devel] [RFC PATCH v2 38/44] UefiCpuPkg: Allow AP booting under SEV-ES

> On Oct 14, 2019, at 6:11 AM, Laszlo Ersek wrote: > > On 10/12/19 08:42, Andrew Fish wrote: >> Laszlo, >> >> For 2) this is very unfortunate. I think the root cause is for those >> of us who work on x86 hardware day to day we get programed that >> SEC/PEI is IA32 and DXE is X64, and this

[edk2-devel] Shell feature?

I wanted to start a conversation on the mailing list prior to writing up a BZ, to make sure I'm not missing anything, or in case there is a better way to implement this. I was thinking it would be good to have a Shell API that lets you associate a file type with an internal or external shell

Re: [edk2-devel] Shell feature?

ilar to shell >> variables) so that the change could be installed and survive a reboot. I also >> think there can be a simple shell command that manages extensions (so that >> they can be installed by a script) >> >> Tim >> >> -Original Message- &

Re: [edk2-devel] PCD Migration issue

vel@edk2.groups.io On Behalf Of Andrew Fish >> via Groups.Io >> Sent: Tuesday, February 11, 2020 1:39 AM >> To: devel@edk2.groups.io >> Subject: [edk2-devel] PCD Migration issue >> >> We recently hit an issue when updating our UDK version in our common code >

Re: [edk2-devel] A problem with live migration of UEFI virtual machines

Laszlo, If I understand this correctly is it not more complicated than just size. It also assumes the memory layout is the same? The legacy BIOS used fixed magic address ranges, but UEFI uses dynamically allocated memory so addresses are not fixed. While the UEFI firmware does try to keep S3

Re: [edk2-devel] A problem with live migration of UEFI virtual machines

> On Feb 25, 2020, at 12:40 PM, Laszlo Ersek wrote: > > Hi Andrew, > > On 02/25/20 19:56, Andrew Fish wrote: >> Laszlo, >> >> If I understand this correctly is it not more complicated than just size. It >> also assumes the memory layout is the same? > > Yes. > >> The legacy BIOS used

Re: [edk2-devel] [Patch] IntelSiliconPkg/ShadowMicrocodePei: Fix GCC build error.

> On Mar 1, 2020, at 3:41 PM, Michael D Kinney > wrote: > > Andrew, > > Thanks. I did not realize this was a struct with > a single flexible array member. I agree that does > not make sense. > > The top level struct here is a HOB that must be in > contiguous memory. The HOB can vary in

Re: [edk2-devel] Disabling safe string constraint assertions

> On Mar 4, 2020, at 5:33 AM, Laszlo Ersek wrote: > > On 03/03/20 22:12, Vitaly Cheptsov wrote: >> Hello, >> >> I am creating a new thread for this issue, as for some reason half of my >> messages do not display in the web-interface and some of e-mail clients in >> the previous one. It

Re: [edk2-devel] Disabling safe string constraint assertions

> On Mar 4, 2020, at 10:18 AM, Laszlo Ersek wrote: > > On 03/04/20 18:53, Andrew Fish wrote: >> >> >>> On Mar 4, 2020, at 5:33 AM, Laszlo Ersek wrote: >>> >>> On 03/03/20 22:12, Vitaly Cheptsov wrote: Hello, I am creating a new thread for this issue, as for some reason half

Re: [edk2-devel] Disabling safe string constraint assertions

Vitaly, I was planing on bringing it up at the Stewards meeting that was scheduled for today, but it got rescheduled to next week. So if we don't get traction on the mailing list I'll bring it up in the meeting. > On Mar 3, 2020, at 1:12 PM, Vitaly Cheptsov wrote: > > Hello, > > I am

Re: [edk2-devel] [PATCH v3 0/1] Add PCD to disable safe string constraint assertions

inc by declaring them after the !include statement, >>> please correct me if I'm wrong. If so, I strongly agree and think it >>> should be the case for all packages, so one only overrides the defaults >>> when something specific (debugging, performance-optimized versions,

  1   2   3   4   5   >