Re: [edk2] investigate features differences between ovmf and seabios with QEMU

Hi Laszlo, at first, thank you for your important feedback. On Mon, 2014-02-24 at 12:59 +0100, Laszlo Ersek wrote: > On 02/24/14 05:19, Chen Fan wrote: > > Hi all, > > I'm a novice with OVMF, so please pardon me if I make any mistake. > > > > I have made a list about the feature diffe

Re: [edk2] investigate features differences between ovmf and seabios with QEMU

Hi Andrew, On Mon, 2014-02-24 at 21:28 -0800, Andrew Fish wrote: > Chen, > > > You also have to remember that BIOS requires a mixture of 16-bit > assembly APIs and 1970s (and early 1980s) hardware devices to exist. > These 1970’s hardware devices still exist in hardware (or are emulated > in SMM

Re: [edk2] investigate features differences between ovmf and seabios with QEMU

On 02/26/14 09:43, Chen Fan wrote: > On Mon, 2014-02-24 at 12:59 +0100, Laszlo Ersek wrote: >> On 02/24/14 05:19, Chen Fan wrote: >>> 26. smbios >> >> The SMBIOS integration that you might have become accustomed to between >> qemu and SeaBIOS is not upstream OVMF. > I'm confused, I have seen the "

[edk2] SetupBrowser validation for Inconsistent/Warning If

While playing with the latest EDK2 HII browser code, we ran into something interesting. The order of ValidateQuestion (which handles inconsistent-if and warning-if) and ConfigAccess->Callback() seems to be incorrect. The ValidateQuestion() is called after the user changes the value, but befor

Re: [edk2] DevicePathToStr

On 02/25/2014 07:14 PM, John Davis wrote: > Hello Jaben, > > No I did not. Its odd. Sometimes you add packages and it seems to > compile and link. Other times I have to add a library package. In this > case, I added the GenericBdsLib in the [LibraryClasses] and now it > links. Many thanks. I'l

Re: [edk2] [PATCH 2/1] MdeModulePkg: TerminalDxe: actually set resolution of PC ANSI type terms

On 02/25/2014 04:04 PM, Laszlo Ersek wrote: > The > >CSI Ps ; Ps ; Ps t > > escape sequence serves for window manipulation. We can use the > >CSI 8 ; ; t > > sequence to adapt eg. the xterm window size to the selected console mode. > I'd suggest *not* committing this patch, or at least l

Re: [edk2] [PATCH 2/1] MdeModulePkg: TerminalDxe: actually set resolution of PC ANSI type terms

On 02/25/2014 07:18 PM, Laszlo Ersek wrote: > On 02/26/14 01:05, Andrew Fish wrote: >> >> On Feb 25, 2014, at 2:04 PM, Laszlo Ersek > > wrote: >> >>> The >>> >>> CSI Ps ; Ps ; Ps t >>> >>> escape sequence serves for window manipulation. We can use the >>> >>> CSI 8 ;

Re: [edk2] [PATCH 2/1] MdeModulePkg: TerminalDxe: actually set resolution of PC ANSI type terms

On 02/26/14 16:39, Brian J. Johnson wrote: > On 02/25/2014 04:04 PM, Laszlo Ersek wrote: >> The >> >>CSI Ps ; Ps ; Ps t >> >> escape sequence serves for window manipulation. We can use the >> >>CSI 8 ; ; t >> >> sequence to adapt eg. the xterm window size to the selected console mode. >>

Re: [edk2] [PATCH 2/1] MdeModulePkg: TerminalDxe: actually set resolution of PC ANSI type terms

On 02/26/14 16:57, Laszlo Ersek wrote: > On 02/26/14 16:39, Brian J. Johnson wrote: >> On 02/25/2014 04:04 PM, Laszlo Ersek wrote: >>> The >>> >>>CSI Ps ; Ps ; Ps t >>> >>> escape sequence serves for window manipulation. We can use the >>> >>>CSI 8 ; ; t >>> >>> sequence to adapt eg. the

Re: [edk2] DevicePathToStr

Hello Brian, That is a good explanation and guideline. Many thanks. I'll add this to my notes. John On Wed, Feb 26, 2014 at 7:25 AM, Brian J. Johnson wrote: > On 02/25/2014 07:14 PM, John Davis wrote: > > Hello Jaben, > > > > No I did not. Its odd. Sometimes you add packages and it seems t

Re: [edk2] [PATCH 2/1] MdeModulePkg: TerminalDxe: actually set resolution of PC ANSI type terms

On Feb 26, 2014, at 7:39 AM, Brian J. Johnson wrote: > On 02/25/2014 04:04 PM, Laszlo Ersek wrote: >> The >> >> CSI Ps ; Ps ; Ps t >> >> escape sequence serves for window manipulation. We can use the >> >> CSI 8 ; ; t >> >> sequence to adapt eg. the xterm window size to the selected co

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

Laszlo: Is this patch also for QEMU other VGA type: cirrus, std? Or is it only for QXL VGA type? After apply this patch, we can enable high resolution in firmware, right? And, you mention Win8 QXL XDDM driver doesn't work with OVMF. I also notice the guest WIN8 can't change the video resol

Re: [edk2] DevicePathToStr

As a follow up, here is the complete code and a summary write up of the info. https://sourceforge.net/p/uefinotes/wiki/Application%20Notes/ On Wed, Feb 26, 2014 at 8:22 AM, John Davis wrote: > Hello Brian, > > That is a good explanation and guideline. Many thanks. I'll add this to > my note

[edk2] Locating a file in the file system

Hello Is there an example someplace for accessing a file in the filesystem? I would like to be able to read a file into a buffer as a simple exercise. I saw the earlier notes about doing this via stdlib/posix api calls. I figure there is a similar method to do this via uefi api. Later I want to

Re: [edk2] [PATCH v2 05/19] OvmfPkg: QemuVideoDxe: tidy up error checking/handling in & under Start()

On Fri, Feb 21, 2014 at 3:58 PM, Laszlo Ersek wrote: > In QemuVideoControllerDriverStart(): > - remove redundant zero-initialization of: > - Private->Handle (2 locations) > - Private->GopDevicePath (when at devpath end) > > - remove fields used for error handling only: > - PciAttributesSaved

Re: [edk2] Locating a file in the file system

You should look at the Shell Package of UDK (ShellPkg) . UEFI Shell has commands which works with a File System. Igor Sharovar On Wed, Feb 26, 2014 at 11:30 AM, John Davis wrote: > Hello > > Is there an example someplace for accessing a file in the filesystem? I > would like to be able to re

Re: [edk2] Locating a file in the file system

On Feb 26, 2014, at 10:30 AM, John Davis wrote: > Hello > > Is there an example someplace for accessing a file in the filesystem? I > would like to be able to read a file into a buffer as a simple exercise. I > saw the earlier notes about doing this via stdlib/posix api calls. I figure > t

Re: [edk2] [PATCH v2 10/19] OvmfPkg: QemuVideoDxe: clarify QEMU_VIDEO_MODE_DATA.ModeNumber

On Fri, Feb 21, 2014 at 3:58 PM, Laszlo Ersek wrote: > The field name "ModeNumber" in QEMU_VIDEO_MODE_DATA is misleading -- it is > not immediately obvious whether this field carries a client-visible mode > number, in the GOP sense, or an internal, card type specific mode index. > After checking a

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

Commonly a platform will have a PlatformDxe driver. It has kind of surprised me how long OVMF has lived without one. One of the main things that lived in the PlatformDxe driver is the setup form data. So, rather than PlatformConfigDxe, could you add PlatformDxe? PlatformDxe can also look at the s

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

On 02/26/14 17:37, Gao, Liming wrote: > Laszlo: > Is this patch also for QEMU other VGA type: cirrus, std? Or is it > only for QXL VGA type? After apply this patch, we can enable high > resolution in firmware, right? It is independent of video card or video driver. It works with Cirrus, QXL etc. I

Re: [edk2] [PATCH v2 01/19] OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxe

On Fri, Feb 21, 2014 at 3:58 PM, Laszlo Ersek wrote: > GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console) > determines the preferred video resolution from the dynamic PCDs > - gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution > - gEfiMdeModulePkgTokenSpaceGuid.PcdVid

Re: [edk2] [PATCH 2/1] MdeModulePkg: TerminalDxe: actually set resolution of PC ANSI type terms

On 02/26/14 17:16, Andrew Fish wrote: > > On Feb 26, 2014, at 7:39 AM, Brian J. Johnson wrote: > >> On 02/25/2014 04:04 PM, Laszlo Ersek wrote: >>> The >>> >>> CSI Ps ; Ps ; Ps t >>> >>> escape sequence serves for window manipulation. We can use the >>> >>> CSI 8 ; ; t >>> >>> sequence to

Re: [edk2] Locating a file in the file system

Hello Andrew, The link there has a second link which says: Looking for the latest version? *Download UDK2010.SR1.UP1.P1.Complete.MyWorkSpace.zip (88.1 MB) * *When I downloaded that zip file it has a lot of .chm files in the

Re: [edk2] [PATCH v2 01/19] OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxe

On 02/26/14 20:25, Jordan Justen wrote: > On Fri, Feb 21, 2014 at 3:58 PM, Laszlo Ersek wrote: >> GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console) >> determines the preferred video resolution from the dynamic PCDs >> - gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolut

Re: [edk2] Locating a file in the file system

John, There are several resources for finding useful functions in EDK II. 1) The UEFI Specification from www.uefi.org. The functions listed in this document will be present on all UEFI compliant systems, thus affording a degree of portability to your applications. 2)

Re: [edk2] Locating a file in the file system

On Feb 26, 2014, at 11:30 AM, John Davis wrote: > Hello Andrew, > > The link there has a second link which says: > Looking for the latest version? Download > UDK2010.SR1.UP1.P1.Complete.MyWorkSpace.zip (88.1 MB) > > When I downloaded that zip file it has a lot of .chm files in the zip file.

Re: [edk2] Locating a file in the file system

I wonder if you have them in a specific folder and that is why they open correctly for you. On Wed, Feb 26, 2014 at 11:55 AM, Andrew Fish wrote: > > On Feb 26, 2014, at 11:30 AM, John Davis wrote: > > Hello Andrew, > > The link there has a second link which says: > Looking for the latest versi

Re: [edk2] Locating a file in the file system

Ahh, I see the problem. All the zip files in the directories need to be unzipped first. once I did that, I could open the .chm files. On Wed, Feb 26, 2014 at 12:03 PM, John Davis wrote: > I wonder if you have them in a specific folder and that is why they open > correctly for you. > > > On We

Re: [edk2] Locating a file in the file system

Of all the gin joints in all the towns in all the world, John Davis had to walk into mine at 10:30:59 on Wednesday 26 February 2014 and say: > Hello > > Is there an example someplace for accessing a file in the filesystem? I > would like to be able to read a file into a buffer as a simple exerc

Re: [edk2] [PATCH v2 01/19] OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxe

On Wed, Feb 26, 2014 at 11:35 AM, Laszlo Ersek wrote: > On 02/26/14 20:25, Jordan Justen wrote: >> On Fri, Feb 21, 2014 at 3:58 PM, Laszlo Ersek wrote: >>> GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console) >>> determines the preferred video resolution from the dynamic PCDs >

Re: [edk2] Locating a file in the file system

If you are writing something that is only used from the shell, the EfiShellProtocol also provides functions to decode the file system string identifiers ("fs0") and block string identifiers ("blk0"). This makes it easier for users to interact with your application if that is required. -Jaben

Re: [edk2] [PATCH v2 03/19] OvmfPkg: introduce PlatformConfigLib

On Fri, Feb 21, 2014 at 3:58 PM, Laszlo Ersek wrote: > This small library allows the saving and loading of platform configuration > to/from the non-volatile variable store. > > It provides a backend for EFI_HII_CONFIG_ACCESS_PROTOCOL (ie. setup forms) > and for various DXE and UEFI drivers that de

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

In summary: These 2 have r-b: 40ec150 OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxe bcfafb6 OvmfPkg: introduce gOvmfPlatformConfigGuid Add an empty PlatformDxe driver here. PlatformConfigLib functionality moves into PlatformDxe. a67623f OvmfPkg: introduce PlatformConfigLib Move into

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

On 02/26/14 20:16, Jordan Justen wrote: > Commonly a platform will have a PlatformDxe driver. It has kind of > surprised me how long OVMF has lived without one. One of the main > things that lived in the PlatformDxe driver is the setup form data. > > So, rather than PlatformConfigDxe, could you ad

[edk2] ARM use of EBC?

Has there been any thought to use EBC on ARM platforms, not just Intel ones? Would ARM opcodes fit into EBC or would that be unfeasible? An EBC owned by UEFI Forum that targeted all HW not just one vendors would be more useful, right? Below ARM VM has other goals, but for non-EFI use that BSD-l

Re: [edk2] [PATCH v2 00/19] OvmfPkg: improve video mode selection

On Wed, Feb 26, 2014 at 1:59 PM, Laszlo Ersek wrote: > On 02/26/14 20:16, Jordan Justen wrote: >> Commonly a platform will have a PlatformDxe driver. It has kind of >> surprised me how long OVMF has lived without one. One of the main >> things that lived in the PlatformDxe driver is the setup form

Re: [edk2] ARM use of EBC?

On Feb 26, 2014, at 2:38 PM, Blibbet wrote: > Has there been any thought to use EBC on ARM platforms, not just Intel ones? > I think all that is missing is a volunteer to do the work in the edk2 open source project > Would ARM opcodes fit into EBC or would that be unfeasible? > EBC is a v

[edk2] any idea why LocateHandleBuffer would fail with NT32?

I'm trying to mimic some existing code. I have gEfiFirmwareVolumeProtocolGuid in my .efi [Protocols] section and previous gBS->HandleProtocol calls work. EFI_STATUSStatus; UINTN HandleCount; EFI_HANDLE *HandleBuffer; // MdePkg/Include/Uefi/UefiSpec.h has a struct for BootServices which is of

Re: [edk2] any idea why LocateHandleBuffer would fail with NT32?

On Feb 26, 2014, at 4:22 PM, John Davis wrote: > I'm trying to mimic some existing code. I have > gEfiFirmwareVolumeProtocolGuid in my .efi [Protocols] section and previous > gBS->HandleProtocol calls work. > > EFI_STATUS Status; > UINTN

Re: [edk2] any idea why LocateHandleBuffer would fail with NT32?

Yes indeed that fixed it. Many thanks. Includes for .c #include Api call Status = gBS->HandleProtocol (ImageHandle, &gEfiLoadedImageProtocolGuid, (VOID **)&LoadedImage); .inf entry [ Protocols ] gEfiFirmwareVolume2ProtocolGuid On Wed, Feb 26, 2014 at 4:36 PM, Andrew Fish wrote: > > On

Re: [edk2] SetupBrowser validation for Inconsistent/Warning If

Hi Samer, Thanks for you to report this issue, this is truly a potential issue, I will follow up with it. Thanks, Eric From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] Sent: Wednesday, February 26, 2014 9:31 PM To: edk2-devel@lists.sourceforge.net Subject: [edk2] SetupBrowser va

[edk2] the implemention of the NVRAM storage with EMMC device on ARM platform

all: i am porting the uefi to a arm soc with emmc stroage, i meet some questions when i am trying to implement the NVRAM variable read/write. since there is no nor flash on my platform, so i want to store the variable in the emmc device(RPMB partition). but i find in the edk2, there is no proper

Re: [edk2] the implemention of the NVRAM storage with EMMC device on ARM platform

You can implement a Firmware_Volume_Block_Protocol based on your emmc driver. then all variable read/write would be passed down to variable region in EMMC. From: zhengjiewen2005 [mailto:zhengjiewen2...@163.com] Sent: Thursday, February 27, 2014 14:17 To: edk2-devel Subject: [edk2] the implemention