[edk2] [PATCH] OvmfPkg: raise DXEFV size to 10 MB

We reached the size limit again. Building OVMF with the following command $ ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D HTTP_BOOT_ENABLE and it ended up with GenFds.py... GenFv: ERROR 3000: Invalid : error 7000: Failed to generate FV the required fv image size 0x900450

[edk2] [PATCH v2] OvmfPkg/PlatformBootManagerLib: Connect the Xen drivers before loading NvVars

When OVMF tried to load the file-based NvVars, it checked all the PCI instances and connected the drivers to the mass storage device. However, Xen registered its PCI device with a special class id (0xFF80), so ConnectRecursivelyIfPciMassStorage() couldn't recognize it and skipped the driver

Re: [edk2] UDK2015 Source Line Debugging

On 2016-05-30 08:07:33, Laszlo Ersek wrote: > On 05/30/16 04:13, Gary Lin wrote: > > On Sun, May 29, 2016 at 07:58:56PM +0200, Laszlo Ersek wrote: > >> On 05/28/16 02:38, Rall wrote: > >>> I installed UDK2015 on Windows 10 (64 Bit) and made HelloWorld running. > >>> > >>> > >>> > >>> Now I

[edk2] [PATCH v2] MdeModulePkg: Fix SNP.Initialize() spec conformance issue

v2: *Refine the coding style according edk2 community's feedback. Current SNP UNDI Initialize command does not follow the UEFI Spec to update the SNP MediaPresent field. The result for the Initialize command execution check should be: StatFlags: (1) Monitor the upper two bits (14 & 15) in the

Re: [edk2] edk2 llvm branch

Hi Andrew, > jmpq *.LJTI3_0(,%rcx,8) > jmpq 0xfffcdd54(,%rcx,8) > > It seems like this code is saying go backwards 200K which seems broken in > general (How big is your SEC?). So this is likely a code gen bug. [Steven]: OK, Let me explain the details about how the wrong

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

> -Original Message- > From: af...@apple.com [mailto:af...@apple.com] > Sent: Monday, May 30, 2016 1:14 PM > To: Vladimir Olovyannikov > Cc: edk2-de...@ml01.01.org > Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address return > EFI_NOT FOUND > > > > On May 30, 2016, at 12:29

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

> On May 30, 2016, at 12:29 PM, Vladimir Olovyannikov > wrote: > >> -Original Message- >> From: af...@apple.com [mailto:af...@apple.com] >> Sent: Monday, May 30, 2016 11:53 AM >> To: Vladimir Olovyannikov >> Cc: edk2-de...@ml01.01.org >> Subject: Re:

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

> -Original Message- > From: af...@apple.com [mailto:af...@apple.com] > Sent: Monday, May 30, 2016 11:53 AM > To: Vladimir Olovyannikov > Cc: edk2-de...@ml01.01.org > Subject: Re: [edk2] EfiConvertPointer/AllocatePages for an address return > EFI_NOT FOUND > > > > On May 30, 2016, at 11:38

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

Hi Andrew, Please see below. The region of interest is marked as "Reserved". Thanks, Vladimir > -Original Message- > From: af...@apple.com [mailto:af...@apple.com] > Sent: Monday, May 30, 2016 11:32 AM > To: Vladimir Olovyannikov > Cc: edk2-de...@ml01.01.org > Subject: Re: [edk2]

Re: [edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

> On May 30, 2016, at 10:37 AM, Vladimir Olovyannikov > wrote: > > > Hello All, > > I faced an issue with my UEFI implementation (Armv8 64 bit platform). > I need to convert a device physical address to the virtual on > VirtualAddressChange event. >

Re: [edk2] UDK2015 Source Line Debugging

On 05/30/16 20:01, Kinney, Michael D wrote: > Laszlo, > > Finished description below. Thanks! > I also want to mention that I have successfully used Com0Com to do this in the > past. I just found remapping to TCPIP was much, much faster, so once I > figured > that out I have never gone back

Re: [edk2] [PATCH v1 1/1] MdePkg/DebugLib: Ignore DEBUG variables in RELEASE builds.

Hey Laszlo, Thanks for your comment. To be honest, I was not aware of any side effects when casting to VOID - that's what I have been used to in the past and also saw it in several sources, including Microsoft (yes, not a good example for good src :) ). But as the issue is obviously known

Re: [edk2] UDK2015 Source Line Debugging

Laszlo, Finished description below. I also want to mention that I have successfully used Com0Com to do this in the past. I just found remapping to TCPIP was much, much faster, so once I figured that out I have never gone back to Com0Com. Probably should add both the Com0Com and TCPIP mapping

Re: [edk2] [RFC V2] Proposal to organize packages into directories

Bhupesh, There were some previous discussions on this RFC that packages such as MdeModulePkg do contain many drivers that may fit into the Driver category. Today, the MdeModulePkg contains the PEI Core, DXE Core, and SMM Core, so that is why that package is in the Core category. We will

Re: [edk2] UDK2015 Source Line Debugging

On 05/30/16 19:49, Kinney, Michael D wrote: > Laszlo, > > I have used the UART based source level debug using QEMU on Windows with UDK > Debugger > Tool and WinDbg. I configure QEMU to redirect UART to TCPIP port on the same > system > that is running QEMU. This is the fastest debug

Re: [edk2] UDK2015 Source Line Debugging

Laszlo, I have used the UART based source level debug using QEMU on Windows with UDK Debugger Tool and WinDbg. I configure QEMU to redirect UART to TCPIP port on the same system that is running QEMU. This is the fastest debug environment for UDK Debugger Tool I have used because the UART to

[edk2] EfiConvertPointer/AllocatePages for an address return EFI_NOT FOUND

Hello All, I faced an issue with my UEFI implementation (Armv8 64 bit platform). I need to convert a device physical address to the virtual on VirtualAddressChange event. EfiConvertPointer always returns EFI_NOT_FOUND. I tried to allocate just an address: gBS->AllocatePages(AllocateAddress,

Re: [edk2] some questions about UEFI Extract & DXE drivers' memory address

> On May 30, 2016, at 12:26 AM, Li Hongcheng wrote: > > Hello everyone, >My name is Owen and I am a senior student from Renmin University of China. > Recently I used a tool named UEFI Extract to parse my UEFI ROM file. There is > a “info.txt” file for every DXE PE

Re: [edk2] edk2 llvm branch

> On May 29, 2016, at 10:47 PM, Shi, Steven wrote: > > Hi Andrew, > > I think I root cause the issue that Clang LTO X64 OVMF hang in Sec. It is > related to the LLVM LTO has not supported the large code model yet which > cause X64 LTO code cannot be loaded to run at

Re: [edk2] [PATCH v1 1/1] MdePkg/DebugLib: Ignore DEBUG variables in RELEASE builds.

On 05/30/16 15:22, Marvin Häuser wrote: > When the only point of use of a variable is a DEBUG() or ASSERT() > expression, most compilers will issue a warning when targeting > RELEASE. Cast the parameters to VOID to silence these warnings. > > Contributed-under: TianoCore Contribution Agreement

Re: [edk2] UDK2015 Source Line Debugging

On 05/30/16 04:13, Gary Lin wrote: > On Sun, May 29, 2016 at 07:58:56PM +0200, Laszlo Ersek wrote: >> On 05/28/16 02:38, Rall wrote: >>> I installed UDK2015 on Windows 10 (64 Bit) and made HelloWorld running. >>> >>> >>> >>> Now I followed all instructions of 'Intel UEFI Development Kit Debugger

[edk2] [PATCH] OvmfPkg/PlatformBootManagerLib: Connect the Xen drivers before loading NvVars

When OVMF tried to load the file-based NvVars, it checked all the PCI instances and connected the drivers to the mass storage device. However, Xen registered its PCI device with a special class id (0xFF80), so ConnectRecursivelyIfPciMassStorage() couldn't recognize it and skipped the driver

Re: [edk2] UDK2015 Source Line Debugging

> Anyway, I have tried the UDK Debugger once before, between two QEMU > virtual machines whose serial ports I connected. Unfortunately the setup > didn't work for me, the initial handshake never seemed to complete > between the debug agent and the debugger. > > For debugging OVMF (and perhaps

[edk2] some questions about UEFI Extract & DXE drivers' memory address

Hello everyone, My name is Owen and I am a senior student from Renmin University of China. Recently I used a tool named UEFI Extract to parse my UEFI ROM file. There is a “info.txt” file for every DXE PE file, and many of these “info.txt” files contains a item called “Data memory address”,