Re: [edk2] BdsDxe: about always regenerating a bunch of boot options

[Bill Paul]

Of all the gin joints in all the towns in all the world, Laszlo Ersek had to 
walk into mine at 17:05:52 on Friday 21 February 2014 and say:

> On 02/20/14 06:53, Sergey Isakov wrote:
> > Hi Laszlo,
> > I think there may be a bug: Variable.c
> > Look
> > ---
> > NewLoadContext->ForceReconnect = (BOOLEAN) (NewLoadContext->Attributes &
> > LOAD_OPTION_FORCE_RECONNECT);
> > ---
> > But LOAD_OPTION_FORCE_RECONNECT == 2 and BOOLEAN == UINT8
> > so ForceReconnect will be 2. Then
> > --
> > *((UINT32 *) Ptr) = LOAD_OPTION_ACTIVE | (ForceReconnect << 1);
> > --
> > I am not sure it is a bug but I think it should be corrected as
> > -
> > NewLoadContext->ForceReconnect = (BOOLEAN) ((NewLoadContext->Attributes
> > & LOAD_OPTION_FORCE_RECONNECT)?1:0);
> > -
> > Wishes,
> > Sergey
> 
> Thanks for the tip!
> 
> I'll look into this as soon as I can, because the bug is for real,
> wherever it is -- while working on my OVMF vidmode series, I rebooted
> one of my VMs so many times that it had *completely* run out flash
> storage, hit an ASSERT() *before* reaching the setup screens, and that
> was it.
> 
> Of course I could find out about this only because my nvvarstore is
> split off into a separate file, and when I test a new OVMF build, the
> varstore remains intact (as it should do)... but with ever less room :)
> There were warning signs: after some point, the nvvar reclaim code ran
> at each boot, but in vain: the free workspace continued to decrease.
> 
> The ASSERT() wasn't very hard to deal with, using a virtual machine
> (restore pristine nvvarstore file from fresh build), but I suspect the
> bug (wherever it is) might have bricked a real HW box :(

You think? :)

On that note, don't you think maybe, just maybe, there should a way to force 
entry to the setup screen in general so that this becomes less of an issue?

It's especially frustrating when the machine taunts you by telling you it's 
"Entering Setup..." and then never actually gets there, even though that's 
exactly what you need to it to do so you can cure problem that's gotten it 
stuck in the first place. (OVMF doesn't do this exactly, but I have had it 
happen on real hardware. Luckily I had JTAG to unjam it.)

I expect the reason it behaves the way it does now is that somebody said "But, 
we need to gather up all this information before we enter the setup screen so 
that we can display what we found." If so, I would have to disagree: given 
what could happen if you don't let me into the setup screen, when I ask you to 
do it, you should drop everything and let me do just that. Maybe you can defer 
scanning the boot options and just jump straight to the menu and then ask me 
if I want to scan them, giving me the chance to say "no."

There has to be a better way.

-Bill

> So we need to exterminate this insect.
> 
> Laszlo
> 
> 
> ---
> --- Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktr
> k ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/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
=

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[John Davis]

I appreciate the help folks. Rick, Laurie, Andrew, Jabin, Tim and Bill.

I've got something at least compiling now.

Here is the relevant includes for the .c source.

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 


This requires the following entries in the .inf file.


[Packages]

  MdePkg/MdePkg.dec

  MdeModulePkg/MdeModulePkg.dec

  IntelFrameworkPkg/IntelFrameworkPkg.dec


[LibraryClasses]

  UefiApplicationEntryPoint

  UefiLib

  PcdLib



This allows the following types to compile.


EFI_STATUS EFIAPI getData(UINTN count, EFI_HANDLE handles[]) {


UINTN rc;

UINTN include;

UINTN Index;

VOID  *RomImage;

UINTN RomSize;

UINT32AuthenticationStatus;

EFI_STATUSStatus;

EFI_GUID  FirmwareVolumeProtocolGuid =
EFI_FIRMWARE_VOLUME_PROTOCOL_GUID;

EFI_FIRMWARE_VOLUME_PROTOCOL  *FirmwareVolume;

EFI_FV_FILE_ATTRIBUTESAttributes;

EFI_FV_FILETYPE   Type;
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] BdsDxe: about always regenerating a bunch of boot options

[Laszlo Ersek]

On 02/20/14 06:53, Sergey Isakov wrote:
> Hi Laszlo,
> I think there may be a bug: Variable.c
> Look
> ---
> NewLoadContext->ForceReconnect = (BOOLEAN) (NewLoadContext->Attributes &
> LOAD_OPTION_FORCE_RECONNECT);
> ---
> But LOAD_OPTION_FORCE_RECONNECT == 2 and BOOLEAN == UINT8 
> so ForceReconnect will be 2. Then
> --
> *((UINT32 *) Ptr) = LOAD_OPTION_ACTIVE | (ForceReconnect << 1);
> --
> I am not sure it is a bug but I think it should be corrected as
> -
> NewLoadContext->ForceReconnect = (BOOLEAN) ((NewLoadContext->Attributes
> & LOAD_OPTION_FORCE_RECONNECT)?1:0);
> -
> Wishes,
> Sergey

Thanks for the tip!

I'll look into this as soon as I can, because the bug is for real,
wherever it is -- while working on my OVMF vidmode series, I rebooted
one of my VMs so many times that it had *completely* run out flash
storage, hit an ASSERT() *before* reaching the setup screens, and that
was it.

Of course I could find out about this only because my nvvarstore is
split off into a separate file, and when I test a new OVMF build, the
varstore remains intact (as it should do)... but with ever less room :)
There were warning signs: after some point, the nvvar reclaim code ran
at each boot, but in vain: the free workspace continued to decrease.

The ASSERT() wasn't very hard to deal with, using a virtual machine
(restore pristine nvvarstore file from fresh build), but I suspect the
bug (wherever it is) might have bricked a real HW box :(

So we need to exterminate this insect.

Laszlo


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 11/19] OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer size

[Laszlo Ersek]

In the next patch we'll add many new BOCHS modes, some of which require
large frame buffers.

The size of the QXL VGA compatibility framebuffer can be changed with the

  -global qxl-vga.vgamem_mb=$NUM_MB

QEMU option.

If $NUM_MB would exceed 32, then the following two QEMU options are
necessary instead:

  -global qxl-vga.vgamem_mb=$NUM_MB \
  -global qxl-vga.ram_size_mb=$((NUM_MB*2))

because the compatibility framebuffer can't cover more than half of PCI
BAR #0. The latter defaults to 64MB in size, and is controlled by
"ram_size_mb".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- calculate size of available framebuffer with a paravirt call [Gerd]
- update commit message to reflect QEMU command line options that change
  the size of the vga compat framebuffer [Gerd]

 OvmfPkg/QemuVideoDxe/Initialize.c | 46 ++-
 1 file changed, 31 insertions(+), 15 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Initialize.c 
b/OvmfPkg/QemuVideoDxe/Initialize.c
index d3d2e2e..80e9b3a 100644
--- a/OvmfPkg/QemuVideoDxe/Initialize.c
+++ b/OvmfPkg/QemuVideoDxe/Initialize.c
@@ -222,11 +222,20 @@ QemuVideoBochsModeSetup (
   QEMU_VIDEO_PRIVATE_DATA  *Private
   )
 {
+  UINT32 AvailableFbSize;
   UINT32 Index;
   QEMU_VIDEO_MODE_DATA   *ModeData;
   QEMU_VIDEO_BOCHS_MODES *VideoMode;
 
   //
+  // fetch available framebuffer size
+  //
+  AvailableFbSize  = BochsRead (Private, VBE_DISPI_INDEX_VIDEO_MEMORY_64K);
+  AvailableFbSize *= SIZE_64KB;
+  DEBUG ((EFI_D_VERBOSE, "%a: AvailableFbSize=0x%x\n", __FUNCTION__,
+AvailableFbSize));
+
+  //
   // Setup Video Modes
   //
   Private->ModeData = AllocatePool (
@@ -238,22 +247,29 @@ QemuVideoBochsModeSetup (
   ModeData = Private->ModeData;
   VideoMode = &QemuVideoBochsModes[0];
   for (Index = 0; Index < QEMU_VIDEO_BOCHS_MODE_COUNT; Index ++) {
-ModeData->InternalModeIndex = Index;
-ModeData->HorizontalResolution  = VideoMode->Width;
-ModeData->VerticalResolution= VideoMode->Height;
-ModeData->ColorDepth= VideoMode->ColorDepth;
-ModeData->RefreshRate   = 60;
-DEBUG ((EFI_D_INFO,
-  "Adding Mode %d as Bochs Internal Mode %d: %dx%d, %d-bit, %d Hz\n",
-  (INT32) (ModeData - Private->ModeData),
-  ModeData->InternalModeIndex,
-  ModeData->HorizontalResolution,
-  ModeData->VerticalResolution,
-  ModeData->ColorDepth,
-  ModeData->RefreshRate
-  ));
+UINTN RequiredFbSize;
 
-ModeData ++ ;
+ASSERT (VideoMode->ColorDepth % 8 == 0);
+RequiredFbSize = (UINTN) VideoMode->Width * VideoMode->Height *
+ (VideoMode->ColorDepth / 8);
+if (RequiredFbSize <= AvailableFbSize) {
+  ModeData->InternalModeIndex= Index;
+  ModeData->HorizontalResolution = VideoMode->Width;
+  ModeData->VerticalResolution   = VideoMode->Height;
+  ModeData->ColorDepth   = VideoMode->ColorDepth;
+  ModeData->RefreshRate  = 60;
+  DEBUG ((EFI_D_INFO,
+"Adding Mode %d as Bochs Internal Mode %d: %dx%d, %d-bit, %d Hz\n",
+(INT32) (ModeData - Private->ModeData),
+ModeData->InternalModeIndex,
+ModeData->HorizontalResolution,
+ModeData->VerticalResolution,
+ModeData->ColorDepth,
+ModeData->RefreshRate
+));
+
+  ModeData ++ ;
+}
 VideoMode ++;
   }
   Private->MaxMode = ModeData - Private->ModeData;
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Laszlo Ersek]

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 all references, rename the field to "InternalModeIndex".

Also, when filling in the card type independent QEMU_VIDEO_MODE_DATA array
from the card type specific mode array, distinguish the GOP mode number
from the internal mode index in the debug message.

This patch effects no functional changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuVideoDxe/Qemu.h   | 11 +--
 OvmfPkg/QemuVideoDxe/Gop.c|  4 ++--
 OvmfPkg/QemuVideoDxe/Initialize.c | 18 ++
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index 78e182e..098ee77 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -50,7 +50,7 @@
 // QEMU Vide Graphical Mode Data
 //
 typedef struct {
-  UINT32  ModeNumber;
+  UINT32  InternalModeIndex; // points into card-specific mode table
   UINT32  HorizontalResolution;
   UINT32  VerticalResolution;
   UINT32  ColorDepth;
@@ -107,15 +107,22 @@ typedef struct {
   UINT64OriginalPciAttributes;
   EFI_GRAPHICS_OUTPUT_PROTOCOL  GraphicsOutput;
   EFI_DEVICE_PATH_PROTOCOL  *GopDevicePath;
+
+  //
+  // The next three fields match the client-visible
+  // EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE.Mode and
+  // EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE.MaxMode fields.
+  //
   UINTN CurrentMode;
   UINTN MaxMode;
   QEMU_VIDEO_MODE_DATA  *ModeData;
+
   UINT8 *LineBuffer;
   QEMU_VIDEO_VARIANTVariant;
 } QEMU_VIDEO_PRIVATE_DATA;
 
 ///
-/// Video Mode structure
+/// Card-specific Video Mode structures
 ///
 typedef struct {
   UINT32  Width;
diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index 912947c..2ff4bcf 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -180,11 +180,11 @@ Routine Description:
   switch (Private->Variant) {
   case QEMU_VIDEO_CIRRUS_5430:
   case QEMU_VIDEO_CIRRUS_5446:
-InitializeCirrusGraphicsMode (Private, 
&QemuVideoCirrusModes[ModeData->ModeNumber]);
+InitializeCirrusGraphicsMode (Private, 
&QemuVideoCirrusModes[ModeData->InternalModeIndex]);
 break;
   case QEMU_VIDEO_BOCHS_MMIO:
   case QEMU_VIDEO_BOCHS:
-InitializeBochsGraphicsMode (Private, 
&QemuVideoBochsModes[ModeData->ModeNumber]);
+InitializeBochsGraphicsMode (Private, 
&QemuVideoBochsModes[ModeData->InternalModeIndex]);
 break;
   default:
 ASSERT (FALSE);
diff --git a/OvmfPkg/QemuVideoDxe/Initialize.c 
b/OvmfPkg/QemuVideoDxe/Initialize.c
index 3774478..d3d2e2e 100644
--- a/OvmfPkg/QemuVideoDxe/Initialize.c
+++ b/OvmfPkg/QemuVideoDxe/Initialize.c
@@ -182,14 +182,15 @@ QemuVideoCirrusModeSetup (
   ModeData = Private->ModeData;
   VideoMode = &QemuVideoCirrusModes[0];
   for (Index = 0; Index < QEMU_VIDEO_CIRRUS_MODE_COUNT; Index ++) {
-ModeData->ModeNumber = Index;
+ModeData->InternalModeIndex = Index;
 ModeData->HorizontalResolution  = VideoMode->Width;
 ModeData->VerticalResolution= VideoMode->Height;
 ModeData->ColorDepth= VideoMode->ColorDepth;
 ModeData->RefreshRate   = VideoMode->RefreshRate;
 DEBUG ((EFI_D_INFO,
-  "Adding Cirrus Video Mode %d: %dx%d, %d-bit, %d Hz\n",
-  ModeData->ModeNumber,
+  "Adding Mode %d as Cirrus Internal Mode %d: %dx%d, %d-bit, %d Hz\n",
+  (INT32) (ModeData - Private->ModeData),
+  ModeData->InternalModeIndex,
   ModeData->HorizontalResolution,
   ModeData->VerticalResolution,
   ModeData->ColorDepth,
@@ -199,7 +200,7 @@ QemuVideoCirrusModeSetup (
 ModeData ++ ;
 VideoMode ++;
   }
-  Private->MaxMode = QEMU_VIDEO_CIRRUS_MODE_COUNT;
+  Private->MaxMode = ModeData - Private->ModeData;
 
   return EFI_SUCCESS;
 }
@@ -237,14 +238,15 @@ QemuVideoBochsModeSetup (
   ModeData = Private->ModeData;
   VideoMode = &QemuVideoBochsModes[0];
   for (Index = 0; Index < QEMU_VIDEO_BOCHS_MODE_COUNT; Index ++) {
-ModeData->ModeNumber = Index;
+ModeData->InternalModeIndex = Index;
 ModeData->HorizontalResolution  = VideoMode->Width;
 ModeData->VerticalResolution= VideoMode->Height;
 ModeData->ColorDepth= VideoMode->ColorDepth;
 ModeData->RefreshRate   = 60;
 DEBUG ((EFI_D_INFO,
-  "Adding Bochs Video Mode %d: %dx%d, %d-bit, %d Hz\n",
-  ModeData->ModeNumber,
+  "Adding Mode %d as Bochs Internal Mode %d: %dx%d, %d-bit, %d Hz\n",
+  (INT32) (ModeData - Private->ModeData),
+  ModeData->InternalModeIndex,
   ModeData->HorizontalRe

[edk2] [PATCH v2 18/19] OvmfPkg: PlatformConfigDxe: connect ExtractConfig() to platform data

[Laszlo Ersek]

Establish the full stack of conversions in retrieving the platform
configuration:

MultiConfigAltResp   -- form engine / HII communication
^
|
 [BlockToConfig]
|
 MAIN_FORM_STATE -- binary representation of form/widget state
^
|
[PlatformConfigToFormState]
|
 PLATFORM_CONFIG -- accessible to DXE and UEFI drivers
^
|
   [PlatformConfigLoad]
|
  UEFI non-volatile variable -- accessible to external utilities

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf |  2 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c   | 85 ++--
 2 files changed, 83 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
index 8d04ae0..c7e43d0 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
@@ -35,10 +35,12 @@
 
 [LibraryClasses]
   BaseLib
+  BaseMemoryLib
   DebugLib
   DevicePathLib
   HiiLib
   MemoryAllocationLib
+  PlatformConfigLib
   PrintLib
   UefiBootServicesTableLib
   UefiHiiServicesLib
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
index b915406..efd5033 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
@@ -14,10 +14,12 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,6 +114,73 @@ STATIC GOP_MODE *mGopModes;
 
 
 /**
+  Load the persistent platform configuration and translate it to binary form
+  state.
+
+  If the platform configuration is missing, then the function fills in a
+  default state.
+
+  @param[out] MainFormState  Binary form/widget state after translation.
+
+  @retval EFI_SUCCESS  Form/widget state ready.
+  @return  Error codes from underlying functions.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+PlatformConfigToFormState (
+  OUT MAIN_FORM_STATE *MainFormState
+  )
+{
+  EFI_STATUS  Status;
+  PLATFORM_CONFIG PlatformConfig;
+  UINT64  OptionalElements;
+  UINTN   ModeNumber;
+
+  ZeroMem (MainFormState, sizeof *MainFormState);
+
+  Status = PlatformConfigLoad (&PlatformConfig, &OptionalElements);
+  switch (Status) {
+  case EFI_SUCCESS:
+//
+// Format the preferred resolution as text.
+//
+UnicodeSPrintAsciiFormat (
+  (CHAR16 *) MainFormState->CurrentPreferredResolution,
+  sizeof MainFormState->CurrentPreferredResolution,
+  "%Ldx%Ld",
+  (INT64) PlatformConfig.HorizontalResolution,
+  (INT64) PlatformConfig.VerticalResolution);
+
+//
+// Try to locate it in the drop-down list too. This may not succeed, but
+// that's fine.
+//
+for (ModeNumber = 0; ModeNumber < mNumGopModes; ++ModeNumber) {
+  if (mGopModes[ModeNumber].X == PlatformConfig.HorizontalResolution &&
+  mGopModes[ModeNumber].Y == PlatformConfig.VerticalResolution) {
+MainFormState->NextPreferredResolution = (UINT32) ModeNumber;
+break;
+  }
+}
+break;
+
+  case EFI_NOT_FOUND:
+UnicodeSPrintAsciiFormat (
+  (CHAR16 *) MainFormState->CurrentPreferredResolution,
+  sizeof MainFormState->CurrentPreferredResolution,
+  "Unset");
+break;
+
+  default:
+return Status;
+  }
+
+  return EFI_SUCCESS;
+}
+
+
+/**
   This function is called by the HII machinery when it fetches the form state.
 
   See the precise documentation in the UEFI spec.
@@ -128,7 +197,9 @@ STATIC GOP_MODE *mGopModes;
 all values filled in for the names in the Request
 string.
 
-  @return  Status codes from gHiiConfigRouting->BlockToConfig().
+  @retval EFI_SUCCESS  Extraction of form state in 
+   encoding successful.
+  @return  Status codes from underlying functions.
 
 **/
 STATIC
@@ -146,9 +217,15 @@ ExtractConfig (
 
   DEBUG ((EFI_D_VERBOSE, "%a: Request=\"%s\"\n", __FUNCTION__, Request));
 
-  StrnCpy ((CHAR16 *) MainFormState.CurrentPreferredResolution,
-   L"Unset", MAXSIZE_RES_CUR);
-  MainFormState.NextPreferredResolution = 0;
+  Status = PlatformConfigToFormState (&MainFormState);
+  if (EFI_ERROR (Status)) {
+*Progress = Request;
+return Status;
+  }
+
+  //
+  // Answer the textual request keying off the binary form state.
+  //
   Status = gHiiConfigRouting->BlockToConfig (gHiiConfigRouting, Request,
 (VOID *) &MainFormState, sizeof MainFormState,
 Results, Progress);
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read th

[edk2] [PATCH v2 19/19] OvmfPkg: PlatformConfigDxe: connect RouteConfig() to platform data

[Laszlo Ersek]

Establish the full stack of conversions when modifying the platform
configuration:

   ConfigResp-- form engine / HII communication
|
 [ConfigToBlock]
|
v
 MAIN_FORM_STATE -- binary representation of form/widget state
|
[FormStateToPlatformConfig]
|
v
 PLATFORM_CONFIG -- accessible to DXE and UEFI drivers
|
   [PlatformConfigSave]
|
v
  UEFI non-volatile variable -- accessible to external utilities

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c | 95 +-
 1 file changed, 94 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
index efd5033..b69bb65 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
@@ -239,6 +239,62 @@ ExtractConfig (
 }
 
 
+/**
+  Interpret the binary form state and save it as persistent platform
+  configuration.
+
+  @param[in] MainFormState  Binary form/widget state to verify and save.
+
+  @retval EFI_SUCCESS  Platform configuration saved.
+  @return  Error codes from underlying functions.
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+FormStateToPlatformConfig (
+  IN CONST MAIN_FORM_STATE *MainFormState
+  )
+{
+  EFI_STATUS  Status;
+  PLATFORM_CONFIG PlatformConfig;
+  CONST GOP_MODE  *GopMode;
+
+  //
+  // There's nothing to do with the textual CurrentPreferredResolution field.
+  // We verify and translate the selection in the drop-down list.
+  //
+  if (MainFormState->NextPreferredResolution >= mNumGopModes) {
+return EFI_INVALID_PARAMETER;
+  }
+  GopMode = mGopModes + MainFormState->NextPreferredResolution;
+
+  ZeroMem (&PlatformConfig, sizeof PlatformConfig);
+  PlatformConfig.HorizontalResolution = GopMode->X;
+  PlatformConfig.VerticalResolution   = GopMode->Y;
+
+  Status = PlatformConfigSave (&PlatformConfig);
+  return Status;
+}
+
+
+/**
+  This function is called by the HII machinery when it wants the driver to
+  interpret and persist the form state.
+
+  See the precise documentation in the UEFI spec.
+
+  @param[in]  This   The Config Access Protocol instance.
+
+  @param[in]  Configuration  A  format UCS-2 string describing the
+ form state.
+
+  @param[out] Progress   A pointer into Configuration on output,
+ identifying the element where processing failed.
+
+  @retval EFI_SUCCESS  Configuration verified, state permanent.
+
+  @return  Status codes from underlying functions.
+**/
 STATIC
 EFI_STATUS
 EFIAPI
@@ -248,9 +304,46 @@ RouteConfig (
   OUT   EFI_STRING  *Progress
 )
 {
+  MAIN_FORM_STATE MainFormState;
+  UINTN   BlockSize;
+  EFI_STATUS  Status;
+
   DEBUG ((EFI_D_VERBOSE, "%a: Configuration=\"%s\"\n", __FUNCTION__,
 Configuration));
-  return EFI_SUCCESS;
+
+  //
+  // the "read" step in RMW
+  //
+  Status = PlatformConfigToFormState (&MainFormState);
+  if (EFI_ERROR (Status)) {
+*Progress = Configuration;
+return Status;
+  }
+
+  //
+  // the "modify" step in RMW
+  //
+  // (Update the binary form state. This update may be partial, which is why in
+  // general we must pre-load the form state from the platform config.)
+  //
+  BlockSize = sizeof MainFormState;
+  Status = gHiiConfigRouting->ConfigToBlock (gHiiConfigRouting, Configuration,
+(VOID *) &MainFormState, &BlockSize, Progress);
+  if (EFI_ERROR (Status)) {
+DEBUG ((EFI_D_ERROR, "%a: ConfigToBlock(): %r, Progress=\"%s\"\n",
+  __FUNCTION__, Status,
+  (Status == EFI_BUFFER_TOO_SMALL) ? NULL : *Progress));
+return Status;
+  }
+
+  //
+  // the "write" step in RMW
+  //
+  Status = FormStateToPlatformConfig (&MainFormState);
+  if (EFI_ERROR (Status)) {
+*Progress = Configuration;
+  }
+  return Status;
 }
 
 
-- 
1.8.3.1


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 17/19] OvmfPkg: PlatformConfigDxe: add save and discard buttons to the form

[Laszlo Ersek]

The RouteConfig() function is also called now as expected.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.h|   3 +++
 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr |  13 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c|  22 ++
 OvmfPkg/PlatformConfigDxe/PlatformConfig.uni  | Bin 3016 -> 3322 bytes
 4 files changed, 38 insertions(+)

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
index 77c4ecb..abd3df9 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
@@ -27,6 +27,9 @@
 #define LABEL_RES_NEXT 1
 #define QUESTION_RES_NEXT  2
 
+#define QUESTION_SAVE_EXIT 3
+#define QUESTION_DISCARD_EXIT  4
+
 //
 // This structure describes the form state. Its fields relate strictly to the
 // visual widgets on the form.
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr 
b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
index efd4589..e69591a 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
@@ -56,6 +56,19 @@ formset
 // We'll dynamically generate a one-of-many selection at this label.
 //
 label LABEL_RES_NEXT;
+
+text
+  help  = STRING_TOKEN(STR_SAVE_EXIT),
+  text  = STRING_TOKEN(STR_SAVE_EXIT),
+  flags = INTERACTIVE,
+  key   = QUESTION_SAVE_EXIT;
+
+text
+  help  = STRING_TOKEN(STR_DISCARD_EXIT),
+  text  = STRING_TOKEN(STR_DISCARD_EXIT),
+  flags = INTERACTIVE,
+  key   = QUESTION_DISCARD_EXIT;
+
   endform;
 
 endformset;
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
index 1ab4232..b915406 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
@@ -171,6 +171,8 @@ RouteConfig (
   OUT   EFI_STRING  *Progress
 )
 {
+  DEBUG ((EFI_D_VERBOSE, "%a: Configuration=\"%s\"\n", __FUNCTION__,
+Configuration));
   return EFI_SUCCESS;
 }
 
@@ -187,6 +189,26 @@ Callback (
   OUTEFI_BROWSER_ACTION_REQUEST *ActionRequest
   )
 {
+  DEBUG ((EFI_D_VERBOSE, "%a: Action=0x%Lx QuestionId=%d Type=%d\n",
+__FUNCTION__, (UINT64) Action, QuestionId, Type));
+
+  if (Action != EFI_BROWSER_ACTION_CHANGED) {
+return EFI_UNSUPPORTED;
+  }
+
+  switch (QuestionId) {
+  case QUESTION_SAVE_EXIT:
+*ActionRequest = EFI_BROWSER_ACTION_REQUEST_FORM_SUBMIT_EXIT;
+break;
+
+  case QUESTION_DISCARD_EXIT:
+*ActionRequest = EFI_BROWSER_ACTION_REQUEST_FORM_DISCARD_EXIT;
+break;
+
+  default:
+break;
+  }
+
   return EFI_SUCCESS;
 }
 
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.uni 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.uni
index 
7fc3fa0c7528b6beadeb882820ac80919ac5a97a..0dbbdbbd91a2d9f2a153492e22719ef411d330dc
 100644
GIT binary patch
delta 176
zcmX>h{!4Ph5$?(RI3)yw85|kH7+e|RfjEM}lObgCL3Yu}7uZ=Qaj9tLGvoqcCPN8>
z0)sO{216o49z!}qDnl`l4`QbPX;+2{hRn%@T#Di@K<&Xmb&d={3@#`J3QyuvvT^|$
YRLqbJ)K~=8h}S@%l}Ze}3|wFg0OMODO8@`>

delta 12
Tcmew*c|v@{5pEV<1}+8wAn*f?

-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 16/19] OvmfPkg: PlatformConfigDxe: get available resolutions from GOP

[Laszlo Ersek]

Generate the options for the drop-down list from the GOP resolutions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf |   5 +-
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c   | 148 +++
 2 files changed, 132 insertions(+), 21 deletions(-)

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
index c3834c9..8d04ae0 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
@@ -38,12 +38,15 @@
   DebugLib
   DevicePathLib
   HiiLib
+  MemoryAllocationLib
+  PrintLib
   UefiBootServicesTableLib
   UefiHiiServicesLib
   UefiDriverEntryPoint
 
 [Protocols]
   gEfiDevicePathProtocolGuid  ## PRODUCES
+  gEfiGraphicsOutputProtocolGuid  ## CONSUMES
   gEfiHiiConfigAccessProtocolGuid ## PRODUCES
 
 [Guids]
@@ -51,4 +54,4 @@
   gOvmfPlatformConfigGuid
 
 [Depex]
-  TRUE
+  gEfiGraphicsOutputProtocolGuid
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
index 49fefaf..1ab4232 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
@@ -17,9 +17,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -96,6 +99,17 @@ STATIC EFI_HII_HANDLE mInstalledPackages;
 extern UINT8 PlatformConfigDxeStrings[];
 extern UINT8 PlatformConfigFormsBin[];
 
+//
+// Cache the resolutions we get from the GOP.
+//
+typedef struct {
+  UINT32 X;
+  UINT32 Y;
+} GOP_MODE;
+
+STATIC UINTNmNumGopModes;
+STATIC GOP_MODE *mGopModes;
+
 
 /**
   This function is called by the HII machinery when it fetches the form state.
@@ -178,6 +192,72 @@ Callback (
 
 
 /**
+  Query and save all resolutions supported by the GOP.
+
+  @param[out] NumGopModes  The number of modes supported by the GOP. On output,
+   this parameter will be positive.
+
+  @param[out] GopModes On output, a dynamically allocated array containing
+   the resolutions returned by the GOP. The caller is
+   responsible for freeing the array after use.
+
+  @retval EFI_UNSUPPORTED   No modes found.
+  @retval EFI_OUT_OF_RESOURCES  Failed to allocate GopModes.
+  @return   Error codes from LocateProtocol() and
+QueryMode().
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+QueryGopModes (
+  OUT UINTN*NumGopModes,
+  OUT GOP_MODE **GopModes
+  )
+{
+  EFI_STATUS   Status;
+  EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop;
+  UINT32   ModeNumber;
+
+  Status = gBS->LocateProtocol (&gEfiGraphicsOutputProtocolGuid, NULL,
+  (VOID **) &Gop);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+  if (Gop->Mode->MaxMode == 0) {
+return EFI_UNSUPPORTED;
+  }
+  *NumGopModes = Gop->Mode->MaxMode;
+
+  *GopModes = AllocatePool (Gop->Mode->MaxMode * sizeof **GopModes);
+  if (*GopModes == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  for (ModeNumber = 0; ModeNumber < Gop->Mode->MaxMode; ++ModeNumber) {
+EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *Info;
+UINTNSizeOfInfo;
+
+Status = Gop->QueryMode (Gop, ModeNumber, &SizeOfInfo, &Info);
+if (EFI_ERROR (Status)) {
+  goto FreeGopModes;
+}
+
+(*GopModes)[ModeNumber].X = Info->HorizontalResolution;
+(*GopModes)[ModeNumber].Y = Info->VerticalResolution;
+FreePool (Info);
+  }
+
+  return EFI_SUCCESS;
+
+FreeGopModes:
+  FreePool (*GopModes);
+
+  return Status;
+}
+
+
+/**
   Create a set of "one-of-many" (ie. "drop down list") option IFR opcodes,
   based on available GOP resolutions, to be placed under a "one-of-many" (ie.
   "drop down list") opcode.
@@ -191,6 +271,10 @@ Callback (
 resolutions. The caller is responsible for freeing
 OpCodeBuffer with HiiFreeOpCodeHandle() after use.
 
+  @param[in]  NumGopModes   Number of entries in GopModes.
+
+  @param[in]  GopModes  Array of resolutions retrieved from the GOP.
+
   @retval EFI_SUCESS  Opcodes have been successfully produced.
 
   @return Status codes from underlying functions. PackageList may
@@ -202,30 +286,39 @@ EFI_STATUS
 EFIAPI
 CreateResolutionOptions (
   IN  EFI_HII_HANDLE  *PackageList,
-  OUT VOID**OpCodeBuffer
+  OUT VOID**OpCodeBuffer,
+  IN  UINTN   NumGopModes,
+  IN  GOP_MODE*GopModes
   )
 {
-  EFI_STATUS   Status;
-  VOID *OutputBuffer;
-  EFI_STRING_IDNewString;
-  VOID *OpCode;
+  EFI_STATUS Status;
+  VOID   *OutputBuffer;
+  UINTN  ModeNumber;
 
   OutputBuffer = HiiAllocateOpCodeHandle ();
   if (OutputBuffer == NULL) {
 return EFI_OUT_OF_RESOURC

[edk2] [PATCH v2 15/19] OvmfPkg: PlatformConfigDxe: add form widgets for video modes

[Laszlo Ersek]

In this patch we populate the form with the two widgets related to video
resolution:
- A read-only string field displaying the preference for the next boot.
- A drop-down list offering choices for changing the setting. This list is
  implemented with dynamically generated IFR opcodes.

(In general, the current preference may be missing, or it may be invalid
for the available video RAM size. The list of possible new settings is
filtered with the video RAM size.)

Because the form now becomes able to receive input, we must also implement
ExtractConfig(). This function tells the HII engine about the state of the
widgets.

For now we set up both widgets with static data only:
- The current preference always says "Unset". The driver code is still
  isolated from the backend (the UEFI variable store).
- The list of possible resolutions offers 800x600 only. We don't
  interrogate the GOP yet.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf  |   6 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.h|   4 +
 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr |  18 ++
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c| 216 +-
 OvmfPkg/PlatformConfigDxe/PlatformConfig.uni  | Bin 1944 -> 3016 bytes
 5 files changed, 243 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
index 7f04c23..c3834c9 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
@@ -34,15 +34,21 @@
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
+  BaseLib
   DebugLib
   DevicePathLib
   HiiLib
   UefiBootServicesTableLib
+  UefiHiiServicesLib
   UefiDriverEntryPoint
 
 [Protocols]
   gEfiDevicePathProtocolGuid  ## PRODUCES
   gEfiHiiConfigAccessProtocolGuid ## PRODUCES
 
+[Guids]
+  gEfiIfrTianoGuid
+  gOvmfPlatformConfigGuid
+
 [Depex]
   TRUE
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
index 5d9874f..77c4ecb 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
@@ -21,8 +21,12 @@
 #define FORMSTATEID_MAIN_FORM  1
 #define FORMID_MAIN_FORM   1
 
+#define QUESTION_RES_CUR   1
 #define MAXSIZE_RES_CUR   16
 
+#define LABEL_RES_NEXT 1
+#define QUESTION_RES_NEXT  2
+
 //
 // This structure describes the form state. Its fields relate strictly to the
 // visual widgets on the form.
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr 
b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
index 5dc4843..efd4589 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
@@ -38,6 +38,24 @@ formset
   form
 formid = FORMID_MAIN_FORM,
 title  = STRING_TOKEN(STR_MAIN_FORM_TITLE);
+
+//
+// Display the current preference in a read-only string field.
+//
+string
+  varid  = MainFormState.CurrentPreferredResolution,
+  questionid = QUESTION_RES_CUR,
+  prompt = STRING_TOKEN(STR_RES_CUR),
+  help   = STRING_TOKEN(STR_RES_CUR_HELP),
+  flags  = READ_ONLY,
+  minsize= 0,
+  maxsize= MAXSIZE_RES_CUR,
+endstring;
+
+//
+// We'll dynamically generate a one-of-many selection at this label.
+//
+label LABEL_RES_NEXT;
   endform;
 
 endformset;
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
index eb03dd8..49fefaf 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.c
@@ -13,12 +13,18 @@
   WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 **/
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
+
+#include "PlatformConfig.h"
 
 //
 // The HiiAddPackages() library function requires that any controller (or
@@ -91,6 +97,26 @@ extern UINT8 PlatformConfigDxeStrings[];
 extern UINT8 PlatformConfigFormsBin[];
 
 
+/**
+  This function is called by the HII machinery when it fetches the form state.
+
+  See the precise documentation in the UEFI spec.
+
+  @param[in]  This  The Config Access Protocol instance.
+
+  @param[in]  Request   A  format UCS-2 string describing the
+query.
+
+  @param[out] Progress  A pointer into Request on output, identifying the query
+element where processing failed.
+
+  @param[out] Results   A  format UCS-2 string that has
+all values filled in for the names in the Request
+string.
+
+  @return  Status codes from gHiiConfigRouting->BlockToConfig().
+
+**/
 STATIC
 EFI_STATUS
 EFIAPI
@@ -101,7 +127,24 @@ ExtractConfig (
   OUT   EFI_STRING  *Results
 )
 {
-  return EFI_SUCCESS;
+  MAIN_FORM_STATE MainFormSt

[edk2] [PATCH v2 12/19] OvmfPkg: QemuVideoDxe: add further BOCHS modes

[Laszlo Ersek]

This brings the list of BOCHS video modes to par with the QEMU QXL
implementation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuVideoDxe/Initialize.c | 40 ---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Initialize.c 
b/OvmfPkg/QemuVideoDxe/Initialize.c
index 80e9b3a..a536d47 100644
--- a/OvmfPkg/QemuVideoDxe/Initialize.c
+++ b/OvmfPkg/QemuVideoDxe/Initialize.c
@@ -209,9 +209,43 @@ QemuVideoCirrusModeSetup (
 /// Table of supported video modes
 ///
 QEMU_VIDEO_BOCHS_MODES  QemuVideoBochsModes[] = {
-  {  640, 480, 32 },
-  {  800, 600, 32 },
-  { 1024, 768, 24 },
+  {  640,  480, 32 },
+  {  800,  480, 32 },
+  {  800,  600, 32 },
+  {  832,  624, 32 },
+  {  960,  640, 32 },
+  { 1024,  600, 32 },
+  { 1024,  768, 32 },
+  { 1152,  864, 32 },
+  { 1152,  870, 32 },
+  { 1280,  720, 32 },
+  { 1280,  760, 32 },
+  { 1280,  768, 32 },
+  { 1280,  800, 32 },
+  { 1280,  960, 32 },
+  { 1280, 1024, 32 },
+  { 1360,  768, 32 },
+  { 1366,  768, 32 },
+  { 1400, 1050, 32 },
+  { 1440,  900, 32 },
+  { 1600,  900, 32 },
+  { 1600, 1200, 32 },
+  { 1680, 1050, 32 },
+  { 1920, 1080, 32 },
+  { 1920, 1200, 32 },
+  { 1920, 1440, 32 },
+  { 2000, 2000, 32 },
+  { 2048, 1536, 32 },
+  { 2048, 2048, 32 },
+  { 2560, 1440, 32 },
+  { 2560, 1600, 32 },
+  { 2560, 2048, 32 },
+  { 2800, 2100, 32 },
+  { 3200, 2400, 32 },
+  { 3840, 2160, 32 },
+  { 4096, 2160, 32 },
+  { 7680, 4320, 32 },
+  { 8192, 4320, 32 }
 };
 
 #define QEMU_VIDEO_BOCHS_MODE_COUNT \
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 09/19] OvmfPkg: QemuVideoDxe: eliminate useless Private->HardwareNeedsStarting

[Laszlo Ersek]

Currently, QemuVideoGraphicsOutputQueryMode() reports EFI_NOT_STARTED when
this boolean field is set.

However, QemuVideoGraphicsOutputQueryMode() is only available to callers
after the GOP interface has been installed. That in turn implies that the
following partial call tree has succeeded without errors:

  QemuVideoControllerDriverStart()
QemuVideoGraphicsOutputConstructor()
  QemuVideoGraphicsOutputSetMode(... 0 ...)
HardwareNeedsStarting = FALSE
InstallMultipleProtocolInterfaces(... GOP ...)

That is, when QemuVideoGraphicsOutputQueryMode() is reached,
HardwareNeedsStarting is always FALSE.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuVideoDxe/Qemu.h | 1 -
 OvmfPkg/QemuVideoDxe/Gop.c  | 7 ---
 2 files changed, 8 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index 38d6872..78e182e 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -111,7 +111,6 @@ typedef struct {
   UINTN MaxMode;
   QEMU_VIDEO_MODE_DATA  *ModeData;
   UINT8 *LineBuffer;
-  BOOLEAN   HardwareNeedsStarting;
   QEMU_VIDEO_VARIANTVariant;
 } QEMU_VIDEO_PRIVATE_DATA;
 
diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index 1b7db32..912947c 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -114,10 +114,6 @@ Routine Description:
 
   Private = QEMU_VIDEO_PRIVATE_DATA_FROM_GRAPHICS_OUTPUT_THIS (This);
 
-  if (Private->HardwareNeedsStarting) {
-return EFI_NOT_STARTED;
-  }
-
   if (Info == NULL || SizeOfInfo == NULL || ModeNumber >= This->Mode->MaxMode) 
{
 return EFI_INVALID_PARAMETER;
   }
@@ -209,8 +205,6 @@ Routine Description:
 This->Mode->Info
 );
 
-  Private->HardwareNeedsStarting  = FALSE;
-
   return EFI_SUCCESS;
 }
 
@@ -331,7 +325,6 @@ QemuVideoGraphicsOutputConstructor (
   }
   Private->GraphicsOutput.Mode->MaxMode = (UINT32) Private->MaxMode;
   Private->GraphicsOutput.Mode->Mode= GRAPHICS_OUTPUT_INVALIDE_MODE_NUMBER;
-  Private->HardwareNeedsStarting= TRUE;
   Private->LineBuffer   = NULL;
 
   //
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 14/19] OvmfPkg: PlatformConfigDxe: introduce state for the main form

[Laszlo Ersek]

We'll need a C language (ie. structure) representation for the state of
the visual elements on the form. We choose the Buffer Storage kind (see
29.2.5.6 "Storage" in UEFI 2.4A), because it's easy to work with.

Note that the structure added in this patch has nothing to do with UEFI
non-volatile variables.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.h| 12 
 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr |  5 +
 2 files changed, 17 insertions(+)

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
index 8efe789..5d9874f 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
@@ -18,6 +18,18 @@
 //
 // Macro and type definitions that connect the form with the HII driver code.
 //
+#define FORMSTATEID_MAIN_FORM  1
 #define FORMID_MAIN_FORM   1
 
+#define MAXSIZE_RES_CUR   16
+
+//
+// This structure describes the form state. Its fields relate strictly to the
+// visual widgets on the form.
+//
+typedef struct {
+  UINT16 CurrentPreferredResolution[MAXSIZE_RES_CUR];
+  UINT32 NextPreferredResolution;
+} MAIN_FORM_STATE;
+
 #endif // _PLATFORM_CONFIG_H_
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr 
b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
index 1576199..5dc4843 100644
--- a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
@@ -30,6 +30,11 @@ formset
   title = STRING_TOKEN(STR_FORMSET_TITLE),
   help  = STRING_TOKEN(STR_FORMSET_HELP),
 
+  varstore MAIN_FORM_STATE,
+varid = FORMSTATEID_MAIN_FORM,
+name  = MainFormState,
+guid  = OVMF_PLATFORM_CONFIG_GUID;
+
   form
 formid = FORMID_MAIN_FORM,
 title  = STRING_TOKEN(STR_MAIN_FORM_TITLE);
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 13/19] OvmfPkg: introduce PlatformConfigDxe

[Laszlo Ersek]

This DXE driver will collect OVMF config knobs into an HII form. Right now
it only adds a new menu entry in the Device Manager window that opens an
empty form.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf  |  48 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.h|  23 +++
 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr |  38 
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c| 216 ++
 OvmfPkg/OvmfPkgIa32.dsc   |   2 +
 OvmfPkg/OvmfPkgIa32.fdf   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   2 +
 OvmfPkg/OvmfPkgIa32X64.fdf|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   2 +
 OvmfPkg/OvmfPkgX64.fdf|   1 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.uni  | Bin 0 -> 1944 bytes
 11 files changed, 334 insertions(+)
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.h
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.c
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.uni

diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
new file mode 100644
index 000..7f04c23
--- /dev/null
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
@@ -0,0 +1,48 @@
+## @file
+#  This driver exposes OVMF's platform configuration settings via HII.
+#
+#  Copyright (C) 2014, Red Hat, Inc.
+#  Copyright (c) 2009 - 2010, 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
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+#  IMPLIED.
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = PlatformConfigDxe
+  FILE_GUID  = D9DCC5DF-4007-435E-9098-8970935504B2
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= PlatformConfigInit
+  UNLOAD_IMAGE   = PlatformConfigUnload
+
+[Sources]
+  PlatformConfig.c
+  PlatformConfig.uni
+  PlatformConfigForms.vfr
+
+[Packages]
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  DebugLib
+  DevicePathLib
+  HiiLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Protocols]
+  gEfiDevicePathProtocolGuid  ## PRODUCES
+  gEfiHiiConfigAccessProtocolGuid ## PRODUCES
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfig.h 
b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
new file mode 100644
index 000..8efe789
--- /dev/null
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfig.h
@@ -0,0 +1,23 @@
+/** @file
+  This driver exposes OVMF's platform configuration settings via HII.
+
+  Copyright (C) 2014, Red Hat, Inc.
+
+  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
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#ifndef _PLATFORM_CONFIG_H_
+#define _PLATFORM_CONFIG_H_
+
+//
+// Macro and type definitions that connect the form with the HII driver code.
+//
+#define FORMID_MAIN_FORM   1
+
+#endif // _PLATFORM_CONFIG_H_
diff --git a/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr 
b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
new file mode 100644
index 000..1576199
--- /dev/null
+++ b/OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
@@ -0,0 +1,38 @@
+// *++
+//
+// Copyright (C) 2014, Red Hat, Inc.
+// Copyright (c) 2009 - 2011, 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
+// http://opensource.org/licenses/bsd-license.php
+//
+// THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+// WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
+// IMPLIED.
+//
+// Module Name:
+//
+//   PlatformConfigForms.vfr
+//
+// Abstract:
+//
+//   Form definitions for exposing some of OVMF's platform knobs via HII.
+//
+// --*/
+
+#include 
+#include "PlatformConfig.h"
+
+formset
+  guid 

[edk2] [PATCH v2 07/19] OvmfPkg: QemuVideoDxe: disentangle UEFI driver model use in Stop()

[Laszlo Ersek]

A bus driver needs to pay attention whether its Stop() function is being
called on the "main" controller handle (NumberOfChildren == 0) or on the
child handles (NumberOfChildren > 0).

In QemuVideoDxe, all our resources are associated with the one child
handle (and the Private data structure) *except* the top-level PciIo
protocol reference. Be conscious of which mode Stop() is being called for.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuVideoDxe/Driver.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index ab3afae..6a2cac1 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -464,8 +464,26 @@ QemuVideoControllerDriverStop (
   EFI_STATUS  Status;
   QEMU_VIDEO_PRIVATE_DATA  *Private;
 
+  if (NumberOfChildren == 0) {
+//
+// Close the PCI I/O Protocol
+//
+gBS->CloseProtocol (
+  Controller,
+  &gEfiPciIoProtocolGuid,
+  This->DriverBindingHandle,
+  Controller
+  );
+return EFI_SUCCESS;
+  }
+
+  //
+  // free all resources for whose access we need the child handle, because the
+  // child handle is going away
+  //
+  ASSERT (NumberOfChildren == 1);
   Status = gBS->OpenProtocol (
-  Controller,
+  ChildHandleBuffer[0],
   &gEfiGraphicsOutputProtocolGuid,
   (VOID **) &GraphicsOutput,
   This->DriverBindingHandle,
@@ -480,6 +498,7 @@ QemuVideoControllerDriverStop (
   // Get our private context information
   //
   Private = QEMU_VIDEO_PRIVATE_DATA_FROM_GRAPHICS_OUTPUT_THIS (GraphicsOutput);
+  ASSERT (Private->Handle == ChildHandleBuffer[0]);
 
   QemuVideoGraphicsOutputDestructor (Private);
   //
@@ -506,16 +525,6 @@ QemuVideoControllerDriverStop (
   NULL
   );
 
-  //
-  // Close the PCI I/O Protocol
-  //
-  gBS->CloseProtocol (
-Controller,
-&gEfiPciIoProtocolGuid,
-This->DriverBindingHandle,
-Controller
-);
-
   gBS->CloseProtocol (
 Controller,
 &gEfiPciIoProtocolGuid,
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 08/19] OvmfPkg: QemuVideoDxe: plug remaining leaks in Stop()

[Laszlo Ersek]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
At this point in the series I tested repeated connect/disconnect on the
video driver, in the UEFI shell, using the serial console. The graphics
console went down and came up as requested.

 OvmfPkg/QemuVideoDxe/Driver.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 6a2cac1..b446952 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -532,6 +532,11 @@ QemuVideoControllerDriverStop (
 Private->Handle
 );
 
+  FreePool (Private->ModeData);
+  gBS->UninstallProtocolInterface (Private->Handle,
+ &gEfiDevicePathProtocolGuid, Private->GopDevicePath);
+  FreePool (Private->GopDevicePath);
+
   //
   // Free our instance data
   //
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 06/19] OvmfPkg: QemuVideoDxe: simplify UEFI driver model use in Supported() / Start()

[Laszlo Ersek]

A bus driver is allowed to ignore the actual value of RemainingDevicePath
in Supported() and Start(), and to produce all child handles at once.

This in effect means the following invariants for QemuVideoDxe:
- (RemainingDevicePath == NULL), and
- (Private->GopDevicePath != NULL)

Simplify Supported() and Start() by substituting constant TRUE and FALSE
(as appropriate) in expressions that check RemainingDevicePath and/or
Private->GopDevicePath.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuVideoDxe/Driver.c | 108 +-
 1 file changed, 23 insertions(+), 85 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index b1105f4..ab3afae 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -97,7 +97,6 @@ QemuVideoControllerDriverSupported (
   EFI_STATUS  Status;
   EFI_PCI_IO_PROTOCOL *PciIo;
   PCI_TYPE00  Pci;
-  EFI_DEV_PATH*Node;
   QEMU_VIDEO_CARD *Card;
 
   //
@@ -130,40 +129,10 @@ QemuVideoControllerDriverSupported (
   }
 
   Status = EFI_UNSUPPORTED;
-  //
-  // See if the I/O enable is on.  Most systems only allow one VGA device to 
be turned on
-  // at a time, so see if this is one that is turned on.
-  //
-  //  if (((Pci.Hdr.Command & 0x01) == 0x01)) {
-  //
-  // See if this is a Cirrus Logic PCI controller
-  //
   Card = QemuVideoDetect(Pci.Hdr.VendorId, Pci.Hdr.DeviceId);
   if (Card != NULL) {
 DEBUG ((EFI_D_INFO, "QemuVideo: %s detected\n", Card->Name));
 Status = EFI_SUCCESS;
-//
-// If this is an Intel 945 graphics controller,
-// go further check RemainingDevicePath validation
-//
-if (RemainingDevicePath != NULL) {
-  Node = (EFI_DEV_PATH *) RemainingDevicePath;
-  //
-  // Check if RemainingDevicePath is the End of Device Path Node, 
-  // if yes, return EFI_SUCCESS
-  //
-  if (!IsDevicePathEnd (Node)) {
-//
-// If RemainingDevicePath isn't the End of Device Path Node,
-// check its validation
-//
-if (Node->DevPath.Type != ACPI_DEVICE_PATH ||
-Node->DevPath.SubType != ACPI_ADR_DP ||
-DevicePathNodeLength(&Node->DevPath) != 
sizeof(ACPI_ADR_DEVICE_PATH)) {
-  Status = EFI_UNSUPPORTED;
-}
-  }
-}
   }
 
 Done:
@@ -204,6 +173,7 @@ QemuVideoControllerDriverStart (
   EFI_STATUSStatus;
   QEMU_VIDEO_PRIVATE_DATA   *Private;
   EFI_DEVICE_PATH_PROTOCOL  *ParentDevicePath;
+  ACPI_ADR_DEVICE_PATH  AcpiDeviceNode;
   PCI_TYPE00Pci;
   QEMU_VIDEO_CARD   *Card;
   EFI_PCI_IO_PROTOCOL   *ChildPciIo;
@@ -342,50 +312,32 @@ QemuVideoControllerDriverStart (
   //
   // Set Gop Device Path
   //
-  if (RemainingDevicePath == NULL) {
-ACPI_ADR_DEVICE_PATH AcpiDeviceNode;
+  ZeroMem (&AcpiDeviceNode, sizeof (ACPI_ADR_DEVICE_PATH));
+  AcpiDeviceNode.Header.Type = ACPI_DEVICE_PATH;
+  AcpiDeviceNode.Header.SubType = ACPI_ADR_DP;
+  AcpiDeviceNode.ADR = ACPI_DISPLAY_ADR (1, 0, 0, 1, 0, 
ACPI_ADR_DISPLAY_TYPE_VGA, 0, 0);
+  SetDevicePathNodeLength (&AcpiDeviceNode.Header, sizeof 
(ACPI_ADR_DEVICE_PATH));
 
-ZeroMem (&AcpiDeviceNode, sizeof (ACPI_ADR_DEVICE_PATH));
-AcpiDeviceNode.Header.Type = ACPI_DEVICE_PATH;
-AcpiDeviceNode.Header.SubType = ACPI_ADR_DP;
-AcpiDeviceNode.ADR = ACPI_DISPLAY_ADR (1, 0, 0, 1, 0, 
ACPI_ADR_DISPLAY_TYPE_VGA, 0, 0);
-SetDevicePathNodeLength (&AcpiDeviceNode.Header, sizeof 
(ACPI_ADR_DEVICE_PATH));
-
-Private->GopDevicePath = AppendDevicePathNode (
-ParentDevicePath,
-(EFI_DEVICE_PATH_PROTOCOL *) 
&AcpiDeviceNode
-);
-if (Private->GopDevicePath == NULL) {
-  Status = EFI_OUT_OF_RESOURCES;
-  goto RestoreAttributes;
-}
-  } else if (!IsDevicePathEnd (RemainingDevicePath)) {
-//
-// If RemainingDevicePath isn't the End of Device Path Node, 
-// only scan the specified device by RemainingDevicePath
-//
-Private->GopDevicePath = AppendDevicePathNode (ParentDevicePath, 
RemainingDevicePath);
-if (Private->GopDevicePath == NULL) {
-  Status = EFI_OUT_OF_RESOURCES;
-  goto RestoreAttributes;
-}
+  Private->GopDevicePath = AppendDevicePathNode (
+  ParentDevicePath,
+  (EFI_DEVICE_PATH_PROTOCOL *) 
&AcpiDeviceNode
+  );
+  if (Private->GopDevicePath == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+goto RestoreAttributes;
   }
 
   //
-  // Create new child handle and install the device path protocol on it only if
-  // RemainingDevicePath equals NULL, or doesn't point to the End of Device
-  // Path Node.
+  // Create new child handle and install the device 

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

[Laszlo Ersek]

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 depend on the platform
configuration.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 .../PlatformConfigLib/PlatformConfigLib.inf|  36 +++
 OvmfPkg/Include/Library/PlatformConfigLib.h|  54 +++
 .../Library/PlatformConfigLib/PlatformConfigLib.c  | 106 +
 OvmfPkg/OvmfPkgIa32.dsc|   2 +
 OvmfPkg/OvmfPkgIa32X64.dsc |   2 +
 OvmfPkg/OvmfPkgX64.dsc |   2 +
 6 files changed, 202 insertions(+)
 create mode 100644 OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.inf
 create mode 100644 OvmfPkg/Include/Library/PlatformConfigLib.h
 create mode 100644 OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.c

diff --git a/OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.inf 
b/OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.inf
new file mode 100644
index 000..cffb60c
--- /dev/null
+++ b/OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.inf
@@ -0,0 +1,36 @@
+## @file
+# Library for serializing (persistently storing) and deserializing OVMF's
+# platform configuration.
+#
+# Copyright (C) 2014, Red Hat, Inc.
+#
+# 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
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = PlatformConfigLib
+  FILE_GUID  = 30F126DF-CD18-4DDC-BE0A-1159540BCADF
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = PlatformConfigLib|DXE_DRIVER UEFI_DRIVER
+
+[Sources]
+  PlatformConfigLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  UefiRuntimeServicesTableLib
+
+[Guids]
+  gOvmfPlatformConfigGuid
diff --git a/OvmfPkg/Include/Library/PlatformConfigLib.h 
b/OvmfPkg/Include/Library/PlatformConfigLib.h
new file mode 100644
index 000..d2c11a5
--- /dev/null
+++ b/OvmfPkg/Include/Library/PlatformConfigLib.h
@@ -0,0 +1,54 @@
+/** @file
+
+  Library for serializing (persistently storing) and deserializing OVMF's
+  platform configuration.
+
+  Copyright (C) 2014, Red Hat, Inc.
+
+  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
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _PLATFORM_CONFIG_LIB_H_
+#define _PLATFORM_CONFIG_LIB_H_
+
+#include 
+
+//
+// This structure participates in driver configuration and in communication
+// with HII. It does not (necessarily) reflect the wire format in the
+// persistent store.
+//
+#pragma pack(1)
+typedef struct {
+  //
+  // preferred graphics console resolution when booting
+  //
+  UINT32 HorizontalResolution;
+  UINT32 VerticalResolution;
+} PLATFORM_CONFIG;
+#pragma pack()
+
+//
+// Please see the API documentation near the function definitions.
+//
+EFI_STATUS
+EFIAPI
+PlatformConfigSave (
+  IN PLATFORM_CONFIG *PlatformConfig
+  );
+
+EFI_STATUS
+EFIAPI
+PlatformConfigLoad (
+  OUT PLATFORM_CONFIG *PlatformConfig,
+  OUT UINT64  *OptionalElements
+  );
+
+#endif // _PLATFORM_CONFIG_LIB_H_
diff --git a/OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.c 
b/OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.c
new file mode 100644
index 000..73c4bfc
--- /dev/null
+++ b/OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.c
@@ -0,0 +1,106 @@
+/** @file
+
+  Library for serializing (persistently storing) and deserializing OVMF's
+  platform configuration.
+
+  Copyright (C) 2014, Red Hat, Inc.
+
+  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
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include 
+#include 
+#include 
+
+
+//
+// Name of the UEFI variable that we use for persistent storage.
+//
+STATIC CHAR16 mVariableName[] = L"P

[edk2] [PATCH v2 02/19] OvmfPkg: introduce gOvmfPlatformConfigGuid

[Laszlo Ersek]

This GUID should become a new "namespace" for UEFI variables that are
specific to OVMF configuration (as opposed to standard UEFI global
variables). We'll also use it as the GUID of the related HII form-set (ie.
the interactive user interface).

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- s/SystemConfig/PlatformConfig/g [Jordan]
- the new GUID will also participate in HII formset identification

 OvmfPkg/Include/Guid/OvmfPlatformConfig.h | 24 
 OvmfPkg/OvmfPkg.dec   |  1 +
 2 files changed, 25 insertions(+)
 create mode 100644 OvmfPkg/Include/Guid/OvmfPlatformConfig.h

diff --git a/OvmfPkg/Include/Guid/OvmfPlatformConfig.h 
b/OvmfPkg/Include/Guid/OvmfPlatformConfig.h
new file mode 100644
index 000..ea3c26c
--- /dev/null
+++ b/OvmfPkg/Include/Guid/OvmfPlatformConfig.h
@@ -0,0 +1,24 @@
+/** @file
+  GUID for UEFI variables that are specific to OVMF configuration.
+
+  Copyright (C) 2014, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made available
+  under the terms and conditions of the BSD License that accompanies this
+  distribution. The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __OVMF_PLATFORM_CONFIG_H__
+#define __OVMF_PLATFORM_CONFIG_H__
+
+#define OVMF_PLATFORM_CONFIG_GUID \
+{0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac, 0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
+
+extern EFI_GUID gOvmfPlatformConfigGuid;
+
+#endif
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 034ccd8..3f8b6ae 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -42,6 +42,7 @@
 [Guids]
   gUefiOvmfPkgTokenSpaceGuid  = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 0x62, 
0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 0x12, 
0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
+  gOvmfPlatformConfigGuid = {0x7235c51c, 0x0c80, 0x4cab, {0x87, 0xac, 
0x3b, 0x08, 0x4a, 0x63, 0x04, 0xb1}}
 
 [Protocols]
   gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 0xec, 
0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

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

[Laszlo Ersek]

This is v2 of the vidmode selection series (codenamed "be careful what
you ask for" :)), with v1 comments addressed, a whole lot of
QemuVideoDxe cleanups, and -- in the "bells and whistles" category -- an
HII form.

Recap from the v1 blurb:

> The series is mainly motivated by the Windows 2012 R2 / Windows 8
> guest: the QXL WDDM driver (0.3) depends on VGABIOS services and
> doesn't work with OVMF. The series allows the guest admin to configure
> the GOP through the PreferredResolution global variable, and Windows
> 2012 R2 simply inherits the GOP resolution and framebuffer.

Anatomy of the patchset -- Laszlo Ersek (19):

#01 enables the PCD-level configuration of the graphics console in OVMF:

  OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxe

#02-#03 introduce a simple library that abstracts out Platform
Configuration knobs on top of one binary NvVar (the wire format can be
changed later if needed):

  OvmfPkg: introduce gOvmfPlatformConfigGuid
  OvmfPkg: introduce PlatformConfigLib

#04 makes OVMF's BDS shovel the resolution preference from the Platform
Config to the graphics console:

  OvmfPkg: BDS: set preferred video resolution from platform
configuration

#05-#10 constitute a fearless cleanup of QemuVideoDxe:

  OvmfPkg: QemuVideoDxe: tidy up error checking/handling in & under
Start()
  OvmfPkg: QemuVideoDxe: simplify UEFI driver model use in Supported() /
Start()
  OvmfPkg: QemuVideoDxe: disentangle UEFI driver model use in Stop()
  OvmfPkg: QemuVideoDxe: plug remaining leaks in Stop()
  OvmfPkg: QemuVideoDxe: eliminate useless
Private->HardwareNeedsStarting
  OvmfPkg: QemuVideoDxe: clarify QEMU_VIDEO_MODE_DATA.ModeNumber

#11-#12 add a bunch of video modes for QXL:

  OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer
size
  OvmfPkg: QemuVideoDxe: add further BOCHS modes

#13-19 develop an HII driver for interactively massaging Platform Config
knobs -- at the end of the series, the preferred resolution can be
specified (to be effective from next boot) under Device Manager.

  OvmfPkg: introduce PlatformConfigDxe
  OvmfPkg: PlatformConfigDxe: introduce state for the main form
  OvmfPkg: PlatformConfigDxe: add form widgets for video modes
  OvmfPkg: PlatformConfigDxe: get available resolutions from GOP
  OvmfPkg: PlatformConfigDxe: add save and discard buttons to the form
  OvmfPkg: PlatformConfigDxe: connect ExtractConfig() to platform data
  OvmfPkg: PlatformConfigDxe: connect RouteConfig() to platform data

The patchset can be fetched from

  https://github.com/lersek/edk2/commits/mode_select_v2

Please test and review.

(
  For reviewing and generally working with .uni (UCS-2) files in the
  tree, see this thread:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/6351

  The "Notes:" sections have been prepared with git-notes(1).
)

Thanks!
Laszlo

 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf  |   3 +
 .../PlatformConfigLib/PlatformConfigLib.inf|  36 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf   |  59 ++
 OvmfPkg/Include/Guid/OvmfPlatformConfig.h  |  24 +
 OvmfPkg/Include/Library/PlatformConfigLib.h|  54 ++
 OvmfPkg/PlatformConfigDxe/PlatformConfig.h |  42 ++
 OvmfPkg/QemuVideoDxe/Qemu.h|  12 +-
 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr  |  74 +++
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c   |  32 +
 .../Library/PlatformConfigLib/PlatformConfigLib.c  | 106 +++
 OvmfPkg/PlatformConfigDxe/PlatformConfig.c | 730 +
 OvmfPkg/QemuVideoDxe/Driver.c  | 291 
 OvmfPkg/QemuVideoDxe/Gop.c |  34 +-
 OvmfPkg/QemuVideoDxe/Initialize.c  | 102 ++-
 OvmfPkg/OvmfPkg.dec|   1 +
 OvmfPkg/OvmfPkgIa32.dsc|  11 +-
 OvmfPkg/OvmfPkgIa32.fdf|   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc |  11 +-
 OvmfPkg/OvmfPkgIa32X64.fdf |   1 +
 OvmfPkg/OvmfPkgX64.dsc |  11 +-
 OvmfPkg/OvmfPkgX64.fdf |   1 +
 OvmfPkg/PlatformConfigDxe/PlatformConfig.uni   | Bin 0 -> 3322 bytes
 22 files changed, 1437 insertions(+), 199 deletions(-)
 create mode 100644 OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.inf
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.inf
 create mode 100644 OvmfPkg/Include/Guid/OvmfPlatformConfig.h
 create mode 100644 OvmfPkg/Include/Library/PlatformConfigLib.h
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.h
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfigForms.vfr
 create mode 100644 OvmfPkg/Library/PlatformConfigLib/PlatformConfigLib.c
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.c
 create mode 100644 OvmfPkg/PlatformConfigDxe/PlatformConfig.uni

-- 
1.8.3.1


--
Ma

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

[Laszlo Ersek]

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

- tigthen scope of temporaries:
  - MmioDesc
  - AcpiDeviceNode

- supplement missing error checks:
  - AppendDevicePathNode() can fail with out-of-memory (2 locations)
  - when installing GopDevicePath
  - retval of QemuVideoGraphicsOutputConstructor() (can justifiedly fail
with out-of-resources)

- plug leaks on error:
  - free GopDevicePath (AppendDevicePathNode() allocates dynamically)
  - uninstall GopDevicePath
  - free Private->ModeData
  - call QemuVideoGraphicsOutputDestructor()
  - uninstall GOP

In QemuVideoGraphicsOutputConstructor(), called by Start():
- supplement missing error checks:
  - QemuVideoGraphicsOutputSetMode() retval (it can fail with
out-of-resources)

- plug leaks on error:
  - free Mode->Info
  - free Mode

In QemuVideoCirrusModeSetup() and QemuVideoBochsModeSetup(), both called
by Start():
- supplement missing error checks:
  - AllocatePool() can fail in both

In QemuVideoGraphicsOutputDestructor(), called by Start() on the error
path:
- plug leaks:
  - free Private->LineBuffer, which is allocated in
Start() -> Constructor() -> SetMode()

In QemuVideoGraphicsOutputSetMode(), called by Start() indirectly:
- remove redundant zero-assignment to:
  - Private->LineBuffer

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/QemuVideoDxe/Driver.c | 207 +-
 OvmfPkg/QemuVideoDxe/Gop.c|  23 -
 OvmfPkg/QemuVideoDxe/Initialize.c |   6 ++
 3 files changed, 140 insertions(+), 96 deletions(-)

diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index b253ec7..b1105f4 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -203,29 +203,23 @@ QemuVideoControllerDriverStart (
 {
   EFI_STATUSStatus;
   QEMU_VIDEO_PRIVATE_DATA   *Private;
-  BOOLEAN   PciAttributesSaved;
   EFI_DEVICE_PATH_PROTOCOL  *ParentDevicePath;
-  ACPI_ADR_DEVICE_PATH  AcpiDeviceNode;
   PCI_TYPE00Pci;
   QEMU_VIDEO_CARD   *Card;
-  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *MmioDesc;
   EFI_PCI_IO_PROTOCOL   *ChildPciIo;
 
-  PciAttributesSaved = FALSE;
   //
   // Allocate Private context data for GOP inteface.
   //
   Private = AllocateZeroPool (sizeof (QEMU_VIDEO_PRIVATE_DATA));
   if (Private == NULL) {
-Status = EFI_OUT_OF_RESOURCES;
-goto Error;
+return EFI_OUT_OF_RESOURCES;
   }
 
   //
   // Set up context record
   //
   Private->Signature  = QEMU_VIDEO_PRIVATE_DATA_SIGNATURE;
-  Private->Handle = NULL;
 
   //
   // Open PCI I/O Protocol
@@ -239,7 +233,7 @@ QemuVideoControllerDriverStart (
   EFI_OPEN_PROTOCOL_BY_DRIVER
   );
   if (EFI_ERROR (Status)) {
-goto Error;
+goto FreePrivate;
   }
 
   //
@@ -253,13 +247,16 @@ QemuVideoControllerDriverStart (
 &Pci
 );
   if (EFI_ERROR (Status)) {
-goto Error;
+goto ClosePciIo;
   }
 
+  //
+  // Determine card variant.
+  //
   Card = QemuVideoDetect(Pci.Hdr.VendorId, Pci.Hdr.DeviceId);
   if (Card == NULL) {
 Status = EFI_DEVICE_ERROR;
-goto Error;
+goto ClosePciIo;
   }
   Private->Variant = Card->Variant;
 
@@ -274,10 +271,12 @@ QemuVideoControllerDriverStart (
 );
 
   if (EFI_ERROR (Status)) {
-goto Error;
+goto ClosePciIo;
   }
-  PciAttributesSaved = TRUE;
 
+  //
+  // Set new PCI attributes
+  //
   Status = Private->PciIo->Attributes (
 Private->PciIo,
 EfiPciIoAttributeOperationEnable,
@@ -285,13 +284,15 @@ QemuVideoControllerDriverStart (
 NULL
 );
   if (EFI_ERROR (Status)) {
-goto Error;
+goto ClosePciIo;
   }
 
   //
   // Check whenever the qemu stdvga mmio bar is present (qemu 1.3+).
   //
   if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO) {
+EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *MmioDesc;
+
 Status = Private->PciIo->GetBarAttributes (
 Private->PciIo,
 PCI_BAR_IDX2,
@@ -322,7 +323,7 @@ QemuVideoControllerDriverStart (
 if ((BochsId & 0xFFF0) != VBE_DISPI_ID0) {
   DEBUG ((EFI_D_INFO, "QemuVideo: BochsID mismatch (got 0x%x)\n", 
BochsId));
   Status = EFI_DEVICE_ERROR;
-  goto Error;
+  goto RestoreAttributes;
 }
   }
 
@@ -335,13 +336,15 @@ QemuVideoControllerDriverStart (
   (VOID **) &ParentDevicePath
   );
   if (EFI_ERROR (Status)) {
-goto Error;
+goto RestoreAttributes;
   }
 
   //
   // Set Gop Device Path
   //
   if (RemainingDevicePath == NULL) {
+ACP

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

[Laszlo Ersek]

GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console)
determines the preferred video resolution from the dynamic PCDs
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution

In one of the next patches, we'd like to change these PCDs. In order for
GraphicsConsoleDxe to retrieve the new values dynamically,
- it must be linked with the non-null instance of PcdLib,
- OvmfPkg must provide dynamic defaults.

We keep MdeModulePkg's 800x600 default resolution. (The UEFI specification
requires video drivers to support 800x600.)

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc| 7 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc | 7 ++-
 OvmfPkg/OvmfPkgX64.dsc | 7 ++-
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 88d479d..78ab4e8 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -320,6 +320,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
 
 
 

@@ -423,7 +425,10 @@
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
-  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf {
+
+  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+  }
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf {
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f19b658..9fbdf56 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -326,6 +326,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
 
 
 

@@ -430,7 +432,10 @@
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
-  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf {
+
+  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+  }
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf {
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index a927564..5776c0e 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -347,6 +347,8 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration|FALSE
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|800
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|600
 
 
 

@@ -450,7 +452,10 @@
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
   MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
   MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
-  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
+  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf {
+
+  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
+  }
   MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf {
 
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH v2 04/19] OvmfPkg: BDS: set preferred video resolution from platform configuration

[Laszlo Ersek]

The GraphicsConsoleDxe driver (in MdeModulePkg/Universal/Console)
determines the preferred video resolution from the dynamic PCDs
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution

Before BDS connects the console(s), let's retrieve the preferred
resolution from the OVMF platform configuration, and set the above PCDs
accordingly.

Setting the GOP resolution during boot is useful when the guest OS (for
lack of a dedicated display driver) continues to work with the original
GOP resolution and framebuffer.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---

Notes:
v2:
- retrieve preferred resolution with PlatformConfigLib rather than direct
  variable access [Jordan]
- setting the preferred resolution with user tools (UEFI shell, guest OS
  tools) is no longer recommended

 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf |  3 +++
 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c  | 32 +++
 2 files changed, 35 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf 
b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
index a2b72ba..d4aba98 100644
--- a/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
+++ b/OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
@@ -52,12 +52,15 @@
   NvVarsFileLib
   QemuFwCfgLib
   LoadLinuxLib
+  PlatformConfigLib
 
 [Pcd]
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
+  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
 
 [Pcd.IA32, Pcd.X64]
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock
diff --git a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
index ab9c93e..38f8625 100644
--- a/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
@@ -14,6 +14,7 @@
 
 #include "BdsPlatform.h"
 #include "QemuBootOrder.h"
+#include 
 
 
 //
@@ -1027,6 +1028,36 @@ Returns:
 }
 
 
+/**
+  Read the preferred resolution from the platform configuration, and pass it to
+  GraphicsConsoleDxe via dynamic PCDs.
+
+  @retval EFI_SUCCESSPCDs have been set.
+  @returnStatus codes from PlatformConfigLoad().
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+SetPreferredResolution (
+  VOID
+  )
+{
+  EFI_STATUS  Status;
+  PLATFORM_CONFIG PlatformConfig;
+  UINT64  OptionalElements;
+
+  Status = PlatformConfigLoad (&PlatformConfig, &OptionalElements);
+  if (EFI_ERROR (Status)) {
+DEBUG (((Status == EFI_NOT_FOUND) ? EFI_D_VERBOSE : EFI_D_ERROR,
+  "%a: failed to load platform config: %r\n", __FUNCTION__, Status));
+return Status;
+  }
+  PcdSet32 (PcdVideoHorizontalResolution, PlatformConfig.HorizontalResolution);
+  PcdSet32 (PcdVideoVerticalResolution, PlatformConfig.VerticalResolution);
+  return EFI_SUCCESS;
+}
+
+
 VOID
 EFIAPI
 PlatformBdsPolicyBehavior (
@@ -1108,6 +1139,7 @@ Returns:
   //
   // Connect platform console
   //
+  SetPreferredResolution ();
   Status = PlatformBdsConnectConsole (gPlatformConsole);
   if (EFI_ERROR (Status)) {
 //
-- 
1.8.3.1



--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

[Laszlo Ersek]

On 02/21/14 19:44, Andrew Fish wrote:
> 
> On Feb 21, 2014, at 10:17 AM, Laszlo Ersek  > wrote:
> 
>> On 02/21/14 16:12, Ryan Harkin wrote:
>>> Hi Olivier,
>>>
>>> I've just noticed that the upstream EDK2 repository for the FVP AEMv8
>>> model is broken when built with Linaro GCC 13.12 onwards.
>>>
>>> The error I see is:
>>>
>>> UEFI firmware (version  built at 14:54:24 on Feb 21 2014)
>>> add-symbol-file
>>> /linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
>>> 0x88000780
>>> Decompress Failed - Not Found
>>>
>>> ASSERT_EFI_ERROR (Status = Not Found)
>>> ASSERT
>>> /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194):
>>> !EFI_ERROR (Status)
>>>
>>> I've tracked the bug as far as function "FfsProcessSection" [1] where
>>> at line 373, it calls into function "ExtractGuidedSectionDecode" [2]
>>> which then calls into "SavedData->ExtractDecodeHandlerTable [Index]".
>>> At that point, I can't work out where it goes.
>>>
>>> I can "fix" the problem if I re-org the variables at the top of
>>> FfsProcessSection so that DstBuffer is at the start of the
>>> declarations.  That is obviously not a fix.  But it will probably hint
>>> at why the subsequent code is broken.
>>>
>>> Cheers,
>>> Ryan
>>>
>>> [1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285
>>> [2]
>>> EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166
>>
>> Here's a random shot (could be completely unrelated):
>>
>>
>> EFI_STATUS
>> FfsProcessSection (
>>  IN EFI_SECTION_TYPE   SectionType,
>>  IN EFI_COMMON_SECTION_HEADER  *Section,
>>  IN UINTN  SectionSize,
>>  OUT VOID  **OutputBuffer
>>  )
>> {
>>  /* ... */
>>  UINTN   DstBufferSize;
>>  /* ... */
>>
>> You're on AArch64, so UINTN means UINT64.
>>
>> Note that this "auto" variable is not initialized, hence its contents
>> are indeterminate. Fast forward to the next use:
>>
>>Status = UefiDecompressGetInfo (
>>   (UINT8 *) ((EFI_COMPRESSION_SECTION *) Section + 1),
>>   (UINT32) SectionLength - sizeof
>> (EFI_COMPRESSION_SECTION),
>>   (UINT32 *) &DstBufferSize,
>>   &ScratchBufferSize
>>   );
>>  } else if (Section->Type == EFI_SECTION_GUID_DEFINED) {
>>Status = ExtractGuidedSectionGetInfo (
>>   Section,
>>   (UINT32 *) &DstBufferSize,
>>   &ScratchBufferSize,
>>   &SectionAttribute
>>   );
>>
>> Whichever of these functions is invoked, it fills in only four bytes
>> (UINT32). Then,
>>
>>  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
>> (DstBufferSize) + 1);
>>
>> etc etc etc.
>>
>> By reordering the local variables, you could be limiting the nonzero
>> garbage in "DstBufferSize" to those four bytes that *are* ultimately
>> overwritten.
>>
>> I guess initing DstBufferSize to zero is easy enough to try... :)
>>
> 
> Why not just make it UINT32 and remove the casts. A real fix!

I considered that, but didn't propose it, because it could have made a
difference somewhere down the line.

For example, if DstBufferSize were multiplied by an UINT32, then the
product's type (== range) would be affected (on 64-bit):

  UINTN  * UINT32 --> UINTN
  UINT32 * UINT32 --> UINT32

and I didn't check if something depended on the type (== range) of the
product.

Admittedly, multiplying a buffer size with anything doesn't make much
sense in this instance, but I'm generally paranoid about type changes
without auditing all uses.

Thanks!
Laszlo

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

[Ryan Harkin]

On 21 February 2014 18:44, Andrew Fish  wrote:

>
> On Feb 21, 2014, at 10:17 AM, Laszlo Ersek  wrote:
>
> On 02/21/14 16:12, Ryan Harkin wrote:
>
> Hi Olivier,
>
> I've just noticed that the upstream EDK2 repository for the FVP AEMv8
> model is broken when built with Linaro GCC 13.12 onwards.
>
> The error I see is:
>
> UEFI firmware (version  built at 14:54:24 on Feb 21 2014)
> add-symbol-file
>
> /linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
> 0x88000780
> Decompress Failed - Not Found
>
> ASSERT_EFI_ERROR (Status = Not Found)
> ASSERT
> /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194):
> !EFI_ERROR (Status)
>
> I've tracked the bug as far as function "FfsProcessSection" [1] where
> at line 373, it calls into function "ExtractGuidedSectionDecode" [2]
> which then calls into "SavedData->ExtractDecodeHandlerTable [Index]".
> At that point, I can't work out where it goes.
>
> I can "fix" the problem if I re-org the variables at the top of
> FfsProcessSection so that DstBuffer is at the start of the
> declarations.  That is obviously not a fix.  But it will probably hint
> at why the subsequent code is broken.
>
> Cheers,
> Ryan
>
> [1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285
> [2]
> EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166
>
>
> Here's a random shot (could be completely unrelated):
>
>
> EFI_STATUS
> FfsProcessSection (
>  IN EFI_SECTION_TYPE   SectionType,
>  IN EFI_COMMON_SECTION_HEADER  *Section,
>  IN UINTN  SectionSize,
>  OUT VOID  **OutputBuffer
>  )
> {
>  /* ... */
>  UINTN   DstBufferSize;
>  /* ... */
>
> You're on AArch64, so UINTN means UINT64.
>
> Note that this "auto" variable is not initialized, hence its contents are
> indeterminate. Fast forward to the next use:
>
>Status = UefiDecompressGetInfo (
>   (UINT8 *) ((EFI_COMPRESSION_SECTION *) Section + 1),
>   (UINT32) SectionLength - sizeof
> (EFI_COMPRESSION_SECTION),
>   (UINT32 *) &DstBufferSize,
>   &ScratchBufferSize
>   );
>  } else if (Section->Type == EFI_SECTION_GUID_DEFINED) {
>Status = ExtractGuidedSectionGetInfo (
>   Section,
>   (UINT32 *) &DstBufferSize,
>   &ScratchBufferSize,
>   &SectionAttribute
>   );
>
> Whichever of these functions is invoked, it fills in only four bytes
> (UINT32). Then,
>
>  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES
> (DstBufferSize) + 1);
>
> etc etc etc.
>
> By reordering the local variables, you could be limiting the nonzero
> garbage in "DstBufferSize" to those four bytes that *are* ultimately
> overwritten.
>
> I guess initing DstBufferSize to zero is easy enough to try... :)
>
>
As you guessed, it was easy to try and it does indeed fix the problem.
However

>
>
> Why not just make it UINT32 and remove the casts. A real fix!
>

That looks like the correct solution to me.  And yes, it works also.

Andrew, would you like to submit a patch as it's your change?  I'm very
happy to do it, so whichever you'd prefer.

Thanks for your help, both!

Cheers,
Ryan.



>
> Thanks,
>
> Andrew Fish
>
> Thanks
> Laszlo
>
>
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[Bill Paul]

Of all the gin joints in all the towns in all the world, John Davis had to 
walk into mine at 10:02:01 on Friday 21 February 2014 and say:

> Hello
> 
> I got a few emails.  Perhaps I should repose the question.
> 
> I was reading the EDKII Coding Guidelines document on tianocore.  In it, it
> says do not use int or char native types.  Consquently, I was trying to use
> UINT32 and UNIT8 types.
> When I try to extend the HelloWorld sample application from the
> MdeModulePkg with simple type definitions as UINT32 it fails to compile.  I
> am confused by the other sample main since it seems to be doing precisely
> what the coding guidelines say not to do.
> 
> So, how do you setup your includes in your .c file and the .inf file to
> build code which uses UINT types?
> 
> John

I created a small application sample for you which you can download from:

http://people.freebsd.org/~wpaul/w00t/MooPkg.zip

Unzip this in your edk2 directory and it will create a MooPkg directory. You 
can build it by doing:

build  -a IA32 -b RELEASE -t [yourtool] -p MooPkg/MooPkg.dsc
build  -a X64 -b RELEASE -t [yourtool] -p MooPkg/MooPkg.dsc

I only set it up for the IA32 and X64 arches because that's all I can readily 
test right now, but you can change this by editing MooPkg.dsc and editing the 
SUPPORTED_ARCHITECTURES line. Note that all the GUIDs in the .dsc, .dec and 
.inf files are zeros. I leave it to you to fill in the blanks.

This builds you a simple application, Moo.efi, which just prints a hello world 
message on the console with a variable declared as UINT32. This does not use 
StdLib, ShellLib or any of the EDK I compatibility stuff. Here's a sample run 
using OVMF under QEMU:

UEFI Interactive Shell v2.0
EDK II
UEFI v2.40 (EDK II, 0x0001)
Mapping table
  FS0: Alias(s):HD7a1:;BLK3:
  PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)
 BLK0: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
 BLK1: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x1)
 BLK2: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
 BLK4: Alias(s):
  PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
Press ESC in 5 seconds to skip startup.nsh or any other key to continue.
Shell> Moo
HELLO WORLD: 123
Shell> 

It seems that include paths are specified by an [Includes] section in the .dec 
file. The MooPkg.dec just specifies that MooPkg/Include should be added as a 
path, but other paths are inherited from other .dec files. For example, 
Moo.inf says:

[Packages]
  MdePkg/MdePkg.dec

This causes the Moo package to inherit the include paths specified my 
MdePkg.dec.

-Bill

-- 
=
-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
=

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

[Andrew Fish]

On Feb 21, 2014, at 10:17 AM, Laszlo Ersek  wrote:

> On 02/21/14 16:12, Ryan Harkin wrote:
>> Hi Olivier,
>> 
>> I've just noticed that the upstream EDK2 repository for the FVP AEMv8
>> model is broken when built with Linaro GCC 13.12 onwards.
>> 
>> The error I see is:
>> 
>> UEFI firmware (version  built at 14:54:24 on Feb 21 2014)
>> add-symbol-file
>> /linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
>> 0x88000780
>> Decompress Failed - Not Found
>> 
>> ASSERT_EFI_ERROR (Status = Not Found)
>> ASSERT 
>> /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194):
>> !EFI_ERROR (Status)
>> 
>> I've tracked the bug as far as function "FfsProcessSection" [1] where
>> at line 373, it calls into function "ExtractGuidedSectionDecode" [2]
>> which then calls into "SavedData->ExtractDecodeHandlerTable [Index]".
>> At that point, I can't work out where it goes.
>> 
>> I can "fix" the problem if I re-org the variables at the top of
>> FfsProcessSection so that DstBuffer is at the start of the
>> declarations.  That is obviously not a fix.  But it will probably hint
>> at why the subsequent code is broken.
>> 
>> Cheers,
>> Ryan
>> 
>> [1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285
>> [2] 
>> EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166
> 
> Here's a random shot (could be completely unrelated):
> 
> 
> EFI_STATUS
> FfsProcessSection (
>  IN EFI_SECTION_TYPE   SectionType,
>  IN EFI_COMMON_SECTION_HEADER  *Section,
>  IN UINTN  SectionSize,
>  OUT VOID  **OutputBuffer
>  )
> {
>  /* ... */
>  UINTN   DstBufferSize;
>  /* ... */
> 
> You're on AArch64, so UINTN means UINT64.
> 
> Note that this "auto" variable is not initialized, hence its contents are 
> indeterminate. Fast forward to the next use:
> 
>Status = UefiDecompressGetInfo (
>   (UINT8 *) ((EFI_COMPRESSION_SECTION *) Section + 1),
>   (UINT32) SectionLength - sizeof (EFI_COMPRESSION_SECTION),
>   (UINT32 *) &DstBufferSize,
>   &ScratchBufferSize
>   );
>  } else if (Section->Type == EFI_SECTION_GUID_DEFINED) {
>Status = ExtractGuidedSectionGetInfo (
>   Section,
>   (UINT32 *) &DstBufferSize,
>   &ScratchBufferSize,
>   &SectionAttribute
>   );
> 
> Whichever of these functions is invoked, it fills in only four bytes 
> (UINT32). Then,
> 
>  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
> (DstBufferSize) + 1);
> 
> etc etc etc.
> 
> By reordering the local variables, you could be limiting the nonzero garbage 
> in "DstBufferSize" to those four bytes that *are* ultimately overwritten.
> 
> I guess initing DstBufferSize to zero is easy enough to try... :)
> 

Why not just make it UINT32 and remove the casts. A real fix!

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

[Laszlo Ersek]

On 02/21/14 16:12, Ryan Harkin wrote:
> Hi Olivier,
> 
> I've just noticed that the upstream EDK2 repository for the FVP AEMv8
> model is broken when built with Linaro GCC 13.12 onwards.
> 
> The error I see is:
> 
> UEFI firmware (version  built at 14:54:24 on Feb 21 2014)
> add-symbol-file
> /linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
> 0x88000780
> Decompress Failed - Not Found
> 
> ASSERT_EFI_ERROR (Status = Not Found)
> ASSERT 
> /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194):
> !EFI_ERROR (Status)
> 
> I've tracked the bug as far as function "FfsProcessSection" [1] where
> at line 373, it calls into function "ExtractGuidedSectionDecode" [2]
> which then calls into "SavedData->ExtractDecodeHandlerTable [Index]".
> At that point, I can't work out where it goes.
> 
> I can "fix" the problem if I re-org the variables at the top of
> FfsProcessSection so that DstBuffer is at the start of the
> declarations.  That is obviously not a fix.  But it will probably hint
> at why the subsequent code is broken.
> 
> Cheers,
> Ryan
> 
> [1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285
> [2] 
> EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166

Here's a random shot (could be completely unrelated):


EFI_STATUS
FfsProcessSection (
  IN EFI_SECTION_TYPE   SectionType,
  IN EFI_COMMON_SECTION_HEADER  *Section,
  IN UINTN  SectionSize,
  OUT VOID  **OutputBuffer
  )
{
  /* ... */
  UINTN   DstBufferSize;
  /* ... */

You're on AArch64, so UINTN means UINT64.

Note that this "auto" variable is not initialized, hence its contents are 
indeterminate. Fast forward to the next use:

Status = UefiDecompressGetInfo (
   (UINT8 *) ((EFI_COMPRESSION_SECTION *) Section + 1),
   (UINT32) SectionLength - sizeof (EFI_COMPRESSION_SECTION),
   (UINT32 *) &DstBufferSize,
   &ScratchBufferSize
   );
  } else if (Section->Type == EFI_SECTION_GUID_DEFINED) {
Status = ExtractGuidedSectionGetInfo (
   Section,
   (UINT32 *) &DstBufferSize,
   &ScratchBufferSize,
   &SectionAttribute
   );

Whichever of these functions is invoked, it fills in only four bytes (UINT32). 
Then,

  DstBuffer = (VOID *)(UINTN)AllocatePages (EFI_SIZE_TO_PAGES 
(DstBufferSize) + 1);

etc etc etc.

By reordering the local variables, you could be limiting the nonzero garbage in 
"DstBufferSize" to those four bytes that *are* ultimately overwritten.

I guess initing DstBufferSize to zero is easy enough to try... :)

Thanks
Laszlo

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[John Davis]

Hello

I got a few emails.  Perhaps I should repose the question.

I was reading the EDKII Coding Guidelines document on tianocore.  In it, it
says do not use int or char native types.  Consquently, I was trying to use
UINT32 and UNIT8 types.
When I try to extend the HelloWorld sample application from the
MdeModulePkg with simple type definitions as UINT32 it fails to compile.  I
am confused by the other sample main since it seems to be doing precisely
what the coding guidelines say not to do.

So, how do you setup your includes in your .c file and the .inf file to
build code which uses UINT types?

John
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] UEFI writing protection variable

[Tim Lewis]

Good points, Brian. 

The typical solution to this sort of problem requires hardware support, where a 
key is hidden in a piece of hardware that is readable after reset but then can 
be locked. In this way, once your driver reads the key from the lockable 
storage, it then locks it, uses it and then scrubs all references from memory. 
This does not protect you against agents that run before you, or hardware 
snooping devices, but it does protect you from anyone running after you. 

Tim

-Original Message-
From: Brian J. Johnson [mailto:bjohn...@sgi.com] 
Sent: Friday, February 21, 2014 9:40 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] UEFI writing protection variable

On 02/21/2014 04:41 AM, miguelro...@ua.pt wrote:
> Hello all,
>
>
> I'm a master's student and for my final thesis I am writing a UEFI
> Application/Driver.
>
>
> In my UEFI Application/Driver I need to have access to a non volatile
> variable that must be visible (write permission) only to my UEFI
> Application/Driver and invisible (no read permission) for other drivers,
> applications or operating systems.
>
>
> Does UEFI provide any mechanism to create a non volatile variable (or
> some kind of data storage) that is only accessible to my driver? Can I
> have some hints on how to do this?
>
>
> I have been reading about the Secure Boot secure variables and Key
> Managment Service but, the first does not seem to provide reading
> protection and the second does not specify read/write protections for
> the saved keys.
>

You could encrypt the variable's contents with a key known only to your 
driver.  That's the scheme used for updating the secure Machine Owner 
Key (MOK) database from a running OS:  encrypt the data into a 
non-secure transit variable, then reboot, decrypt, and validate it from 
a signed driver in a secure environment.  As Tim Lewis pointed out, this 
wouldn't protect you from all threats, but at least it could ensure that 
only signed/trusted software is running at the point you decrypt your data.

See the IDF presentations and other info linked from 
http://uefidk.intel.com/blog/using-mok-and-uefi-secure-boot-suse-linux

(I'm not a security researcher, so take all the above with a grain of 
salt.  I just thought the scheme presented at IDF was interesting, and 
it seemed applicable.)
-- 

 Brian J. Johnson



   "I use not only the brains I have, but all I can borrow."
-- Woodrow Wilson


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] UEFI writing protection variable

[Brian J. Johnson]

On 02/21/2014 04:41 AM, miguelro...@ua.pt wrote:
> Hello all,
>
>
> I'm a master's student and for my final thesis I am writing a UEFI
> Application/Driver.
>
>
> In my UEFI Application/Driver I need to have access to a non volatile
> variable that must be visible (write permission) only to my UEFI
> Application/Driver and invisible (no read permission) for other drivers,
> applications or operating systems.
>
>
> Does UEFI provide any mechanism to create a non volatile variable (or
> some kind of data storage) that is only accessible to my driver? Can I
> have some hints on how to do this?
>
>
> I have been reading about the Secure Boot secure variables and Key
> Managment Service but, the first does not seem to provide reading
> protection and the second does not specify read/write protections for
> the saved keys.
>

You could encrypt the variable's contents with a key known only to your 
driver.  That's the scheme used for updating the secure Machine Owner 
Key (MOK) database from a running OS:  encrypt the data into a 
non-secure transit variable, then reboot, decrypt, and validate it from 
a signed driver in a secure environment.  As Tim Lewis pointed out, this 
wouldn't protect you from all threats, but at least it could ensure that 
only signed/trusted software is running at the point you decrypt your data.

See the IDF presentations and other info linked from 
http://uefidk.intel.com/blog/using-mok-and-uefi-secure-boot-suse-linux

(I'm not a security researcher, so take all the above with a grain of 
salt.  I just thought the scheme presented at IDF was interesting, and 
it seemed applicable.)
-- 

 Brian J. Johnson



   "I use not only the brains I have, but all I can borrow."
-- Woodrow Wilson


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [RFC] ArmPlatformPkg: PcdCPUCoreSecStackBase and PcdCPUCoresStackBase: UINT64 (patch)

[Steven Kinney]

Hi Olivier,

 I modified the Stacks so that the typedef is UINT64;
for pointing to System Memory outside of the addressable region accessable
via UINT32.  This is very similar to the System Memory changes you made
regarding System Memory base address earlier.  I can across this issue when
migrating to our silicon memory map, which has the stacks in DRAM outside
of the addressable range afforded by a UINT32 typedef.  Please suggest
changes or considerations I might have overlooked.  I tested this on
AARCH64 across multiple memory regions; including the RTSM SRAM locations.

Thanks,

Steve
From fe3fe86ec70945cc8612b5c63b62764652a7a415 Mon Sep 17 00:00:00 2001
From: Steven Kinney 
Date: Fri, 21 Feb 2014 08:26:21 -0600
Subject: [PATCH] ArmPlatformPkg: PcdCPUCoreSecStackBase and
 PcdCPUCoresStackBase: UINT64

Modify the type defintion for PcdCPUCoreSecStackBase and PcdCPUCoresStackBase
to allow for stacks that reside in upper System Memory.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Kinney 
---
 ArmPlatformPkg/ArmPlatformPkg.dec  |4 ++--
 .../Pei/PeiArmPlatformGlobalVariableLib.c  |6 +++---
 ArmPlatformPkg/PrePeiCore/MainMPCore.c |2 +-
 ArmPlatformPkg/PrePeiCore/PrePeiCore.c |4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec b/ArmPlatformPkg/ArmPlatformPkg.dec
index 114c591..71301f4 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -63,12 +63,12 @@
   gArmPlatformTokenSpaceGuid.PcdClusterCount|1|UINT32|0x0038
 
   # Stack for CPU Cores in Secure Mode
-  gArmPlatformTokenSpaceGuid.PcdCPUCoresSecStackBase|0|UINT32|0x0005
+  gArmPlatformTokenSpaceGuid.PcdCPUCoresSecStackBase|0|UINT64|0x0005
   gArmPlatformTokenSpaceGuid.PcdCPUCoreSecPrimaryStackSize|0x1|UINT32|0x0036
   gArmPlatformTokenSpaceGuid.PcdCPUCoreSecSecondaryStackSize|0x1000|UINT32|0x0006
 
   # Stack for CPU Cores in Non Secure Mode
-  gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0|UINT32|0x0009
+  gArmPlatformTokenSpaceGuid.PcdCPUCoresStackBase|0|UINT64|0x0009
   gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0x1|UINT32|0x0037
   gArmPlatformTokenSpaceGuid.PcdCPUCoreSecondaryStackSize|0x1000|UINT32|0x000A
 
diff --git a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/Pei/PeiArmPlatformGlobalVariableLib.c b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/Pei/PeiArmPlatformGlobalVariableLib.c
index df3e129..2ffbdbe 100644
--- a/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/Pei/PeiArmPlatformGlobalVariableLib.c
+++ b/ArmPlatformPkg/Library/ArmPlatformGlobalVariableLib/Pei/PeiArmPlatformGlobalVariableLib.c
@@ -34,7 +34,7 @@ ArmPlatformGetGlobalVariable (
   // Ensure the Global Variable Size have been initialized
   ASSERT (VariableOffset < PcdGet32 (PcdPeiGlobalVariableSize));
 
-  GlobalVariableBase = PcdGet32 (PcdCPUCoresStackBase) + PcdGet32 (PcdCPUCorePrimaryStackSize) - PcdGet32 (PcdPeiGlobalVariableSize);
+  GlobalVariableBase = PcdGet64 (PcdCPUCoresStackBase) + PcdGet32 (PcdCPUCorePrimaryStackSize) - PcdGet32 (PcdPeiGlobalVariableSize);
 
   if (VariableSize == 4) {
 *(UINT32*)Variable = ReadUnaligned32 ((CONST UINT32*)(GlobalVariableBase + VariableOffset));
@@ -57,7 +57,7 @@ ArmPlatformSetGlobalVariable (
   // Ensure the Global Variable Size have been initialized
   ASSERT (VariableOffset < PcdGet32 (PcdPeiGlobalVariableSize));
 
-  GlobalVariableBase = PcdGet32 (PcdCPUCoresStackBase) + PcdGet32 (PcdCPUCorePrimaryStackSize) - PcdGet32 (PcdPeiGlobalVariableSize);
+  GlobalVariableBase = PcdGet64 (PcdCPUCoresStackBase) + PcdGet32 (PcdCPUCorePrimaryStackSize) - PcdGet32 (PcdPeiGlobalVariableSize);
 
   if (VariableSize == 4) {
 WriteUnaligned32 ((UINT32*)(GlobalVariableBase + VariableOffset), *(UINT32*)Variable);
@@ -78,7 +78,7 @@ ArmPlatformGetGlobalVariableAddress (
   // Ensure the Global Variable Size have been initialized
   ASSERT (VariableOffset < PcdGet32 (PcdPeiGlobalVariableSize));
 
-  GlobalVariableBase = PcdGet32 (PcdCPUCoresStackBase) + PcdGet32 (PcdCPUCorePrimaryStackSize) - PcdGet32 (PcdPeiGlobalVariableSize);
+  GlobalVariableBase = PcdGet64 (PcdCPUCoresStackBase) + PcdGet32 (PcdCPUCorePrimaryStackSize) - PcdGet32 (PcdPeiGlobalVariableSize);
 
   return (VOID*)(GlobalVariableBase + VariableOffset);
 }
diff --git a/ArmPlatformPkg/PrePeiCore/MainMPCore.c b/ArmPlatformPkg/PrePeiCore/MainMPCore.c
index 9bfc990..f849d85 100644
--- a/ArmPlatformPkg/PrePeiCore/MainMPCore.c
+++ b/ArmPlatformPkg/PrePeiCore/MainMPCore.c
@@ -124,7 +124,7 @@ PrimaryMain (
   // Adjust the Temporary Ram as the new Ppi List (Common + Platform Ppi Lists) is created at
   // the base of the primary core stack
   PpiListSize = ALIGN_VALUE(PpiListSize, 0x4);
-  TemporaryRamBase = (UINTN)PcdGet32 (PcdCPUCoresStackBase) + PpiListSize;
+  TemporaryRamBase = (UINTN)PcdGet64 (Pc

Re: [edk2] UEFI writing protection variable

[Tim Lewis]

Miguel -

There is no provision for such protection in UEFI. UEFI does not provide the 
type of secure environment that would enforce such protections. For example, 
another driver executing could look in your driver, since they share a single 
memory space.

All keys used by the UEFI firmware are public keys, as you noted.

Tim

From: miguelro...@ua.pt [mailto:miguelro...@ua.pt]
Sent: Friday, February 21, 2014 2:42 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] UEFI writing protection variable


Hello all,



I'm a master's student and for my final thesis I am writing a UEFI 
Application/Driver.



In my UEFI Application/Driver I need to have access to a non volatile variable 
that must be visible (write permission) only to my UEFI Application/Driver and 
invisible (no read permission) for other drivers, applications or operating 
systems.



Does UEFI provide any mechanism to create a non volatile variable (or some kind 
of data storage) that is only accessible to my driver? Can I have some hints on 
how to do this?



I have been reading about the Secure Boot secure variables and Key Managment 
Service but, the first does not seem to provide reading protection and the 
second does not specify read/write protections for the saved keys.



Regards

Miguel Rocha
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[Tim Lewis]

John –

You should use Uefi.h in MdePkg/Include

Tim

From: John Davis [mailto:davi...@gmail.com]
Sent: Friday, February 21, 2014 9:09 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] hello world application sample and beyond

Hello Jaben,

Thanks for the response.  To be honest, I did not think it was wise to use the 
compatibility stuff either since I am just starting out.

I simply want to move from the HelloWorld app to something more significant.  
Its hard when I can't get simple types to compile, eg. UINT32.  I see that this 
type is defined in the compatibiilty/foundation include files and that is why I 
was trying to pull it in.

John

On Fri, Feb 21, 2014 at 8:44 AM, Carsey, Jaben 
mailto:jaben.car...@intel.com>> wrote:
Not sure what specifically you are looking to do.  The 
ShellPkg\Application\Shell is a pretty significant application in terms of what 
it does..

I would stay away from the compatibility stuff unless you are actually 
compiling old code from previous generation environment.

-Jaben

From: John Davis [mailto:davi...@gmail.com]
Sent: Friday, February 21, 2014 8:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] hello world application sample and beyond

Hello

Is there an official source for something a little more complex than the 
helloworld application?  I'm trying to use it as a model for something more 
complex and I can not get simple types to even build.  I see that UINT32 is in 
the edkcompatibilitypkg dir and I have added it to my [packages] section in my 
.inf file but I still can't get the include files in the foundation subdir 
beneath there to satisfy my build requirements.

Here is my setup:

The .inf file:
[Sources]
  MyFindRom.c

[Packages]
  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
  EdkCompatibilityPkg/EdkCompatibilityPkg.dec

[LibraryClasses]
  UefiApplicationEntryPoint
  UefiLib
  PcdLib

The .c includes
/** @file
**/

#include 

#include 
#include 

// EdkCompatibilityPkg\Foundation\Efi\Include\EfiTypes.h:typedef uint32_t 
UINT32;
#include 
#include 
#include 


# the error in build

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\OUTPUT\.\
Dpc.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 /GL /FIAutoGen.h 
/EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe 
 /Ic:\fw\edk2\Build\NT32
IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\DEBUG  
/Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\MdePkg\Include  
/Ic:\fw\edk2\MdePkg\Include\Ia32  /Ic:\fw\edk2\MdeMo
dulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
c:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe\Dpc.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(7) : fatal error 
C1083: Cannot open include file: 'EfiTypes.h': No such file or directory
Dpc.c
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
10.0\Vc\bin\cl.exe"' : return code '0x2'
Stop.

# if I remove the EfiTypes.h in the .c source, this is my error:
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2275: 
'UINT32' : illegal use of this type as an expression
c:\fw\edk2\MdePkg\Include\Ia32\ProcessorBind.h(116) : see declaration 
of 'UINT32'
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Un
UTPUT\.\HiiDatabaseEntry.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 
/GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\Md
c:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseDxe\DEBUG
  /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\
lude\Ia32  /Ic:\fw\edk2\MdeModulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
c:\fw\edk2\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseEntry.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2146: 
syntax error : missing ';' before identifier 'include'
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2065: 
'include' : undeclared identifier

fwiw, I have UINT32 include; in my .c source.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel



--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

--
Managing the Performance of Cloud-Bas

Re: [edk2] working with .uni files in git

[Brian J. Johnson]

On 02/21/2014 07:34 AM, Laszlo Ersek wrote:
> On 02/21/14 12:43, Laszlo Ersek wrote:
>> This is a small hint for people who want to see the changes in .uni
>> files (== UCS-2 encoded strings for HII forms) while using git. I've
>> distilled it from  and I'm
>> posting it to save others time.
>>
>> (1) Add the following lines to your .git/info/attributes (the .uni one
>> is imporant, the others are here just for completeness):
>>
>> *.efi -diff
>> *.EFI -diff
>> *.uni diff=uni
>> *.UNI diff=uni
>> *.bin -diff
>> *.BIN -diff
>> *.raw -diff
>> *.RAW -diff
>> *.bmp -diff
>> *.BMP -diff
>>
>> (2) Then edit .git/config:
>>
>> [diff "uni"]
>>  textconv = iconv -f UCS-2 -t UTF-8
>>  binary = true
>>
>> (3) Profit! :)
>>
>> Note that this only helps with *viewing* changes as patches. Git still
>> won't help you resolve conflicts during rebases, it won't try to merge
>> changes, and importantly it won't generate textual patches in
>> git-format-patch. You'll also still need a UCS-2 compatible text editor
>> that preserves the BOM (like "gedit") to edit .uni files.
>
> Sorry for the self-followup, but I figured out how it can be made work
> for merges too (cherry-pick, conflicts in rebase / merge etc.).
>
> So, in addition to the above:
>
> (4) modify .git/info/attributes like this (ie. add the "merge" attribute
> for *.uni files):
>
> *.uni diff=uni merge=uni
> *.UNI diff=uni merge=uni
>
> (5) append to .git/config:
>
> [merge "uni"]
>   name = merge driver for UCS-2 encoded text files
>   driver = uni-merge %O %A %B
>
> (6) Place the attached "uni-merge" script on your PATH (and make it
> executable).
>
> (7) Profit more! :)

Thanks, great hints!

BTW, if you like a graphical tool, the program "diffuse" does a pretty 
good job of graphically diffing and merging .uni files.  Install it from 
http://diffuse.sourceforge.net/ (it's just a python script), set it as 
your difftool and/or mergetool, and you're golden.  In your .git/config 
or ~/.gitconfig:

[diff]
 tool = diffuse
[difftool]
 prompt = false
[merge]
 tool = diffuse
[mergetool]
 prompt = false

Then "git difftool " or "git mergetool" will invoke it automatically.

You can also use "diffuse -m" to show diffs against HEAD in your 
workarea (one file per tab, very handy) or "diffuse -c " to show 
the changes introduced by a particular commit (again, one file per tab.) 
  Highly recommended.

The program "meld" works too, and displays changes a bit more prettily. 
  But it requires a newer version of python than I have on my old build 
server, so I haven't used it much.
-- 

 Brian



   "Great works are performed not by power, but by perseverance."
-- Samuel Johnson

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[John Davis]

Hello Jaben,

Thanks for the response.  To be honest, I did not think it was wise to use
the compatibility stuff either since I am just starting out.

I simply want to move from the HelloWorld app to something more
significant.  Its hard when I can't get simple types to compile, eg.
UINT32.  I see that this type is defined in the compatibiilty/foundation
include files and that is why I was trying to pull it in.

John


On Fri, Feb 21, 2014 at 8:44 AM, Carsey, Jaben wrote:

>  Not sure what specifically you are looking to do.  The
> ShellPkg\Application\Shell is a pretty significant application in terms of
> what it does..
>
>
>
> I would stay away from the compatibility stuff unless you are actually
> compiling old code from previous generation environment.
>
>
>
> -Jaben
>
>
>
> *From:* John Davis [mailto:davi...@gmail.com]
> *Sent:* Friday, February 21, 2014 8:22 AM
> *To:* edk2-devel@lists.sourceforge.net
> *Subject:* [edk2] hello world application sample and beyond
>
>
>
> Hello
>
>
>
> Is there an official source for something a little more complex than the
> helloworld application?  I'm trying to use it as a model for something more
> complex and I can not get simple types to even build.  I see that UINT32 is
> in the edkcompatibilitypkg dir and I have added it to my [packages] section
> in my .inf file but I still can't get the include files in the foundation
> subdir beneath there to satisfy my build requirements.
>
>
>
> Here is my setup:
>
>
>
> The .inf file:
>
> [Sources]
>
>   MyFindRom.c
>
>
>
> [Packages]
>
>   MdePkg/MdePkg.dec
>
>   MdeModulePkg/MdeModulePkg.dec
>
>   EdkCompatibilityPkg/EdkCompatibilityPkg.dec
>
>
>
> [LibraryClasses]
>
>   UefiApplicationEntryPoint
>
>   UefiLib
>
>   PcdLib
>
>
>
> The .c includes
>
> /** @file
>
> **/
>
>
>
> #include 
>
>
>
> #include 
>
> #include 
>
>
>
> // EdkCompatibilityPkg\Foundation\Efi\Include\EfiTypes.h:typedef uint32_t
> UINT32;
>
> #include 
>
> #include 
>
> #include 
>
>
>
>
>
> # the error in build
>
>
>
> "C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\Vc\bin\cl.exe"
> /Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\OUTPUT\.\
>
> Dpc.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 /GL
> /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm
> /Ic:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe  /Ic:\fw\edk2\Build\NT32
>
> IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\DEBUG
>  /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\MdePkg\Include
>  /Ic:\fw\edk2\MdePkg\Include\Ia32  /Ic:\fw\edk2\MdeMo
>
> dulePkg  /Ic:\fw\edk2\MdeModulePkg\Include
> c:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe\Dpc.c
>
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(7) : fatal error
> C1083: Cannot open include file: 'EfiTypes.h': No such file or directory
>
> Dpc.c
>
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 10.0\Vc\bin\cl.exe"' : return code '0x2'
>
> Stop.
>
>
>
> # if I remove the EfiTypes.h in the .c source, this is my error:
>
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error
> C2275: 'UINT32' : illegal use of this type as an expression
>
> c:\fw\edk2\MdePkg\Include\Ia32\ProcessorBind.h(116) : see
> declaration of 'UINT32'
>
> "C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\Vc\bin\cl.exe"
> /Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Un
>
> UTPUT\.\HiiDatabaseEntry.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE
> /O1ib2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\Md
>
> c:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseDxe\DEBUG
>  /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\
>
> lude\Ia32  /Ic:\fw\edk2\MdeModulePkg  /Ic:\fw\edk2\MdeModulePkg\Include
> c:\fw\edk2\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseEntry.c
>
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error
> C2146: syntax error : missing ';' before identifier 'include'
>
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error
> C2065: 'include' : undeclared identifier
>
>
>
> fwiw, I have UINT32 include; in my .c source.
>
>
>
>
>
> --
>
> John F. Davis
>
> 6 Kandes Court
>
> Durham, NC 27713
>
> 919-888-8358
>
>
> 独树一帜
>
>
>
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>


-- 
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜
--
Managing the Performance of Cloud-Based Applications
Take advantage of what

Re: [edk2] hello world application sample and beyond

[Jarlstrom, Laurie]

The EdkCompatiblityPkg is for combining EDK 1 style modules with the EDK II 
build environment.If are starting in EDK II you should NOT use the 
EdkCompatiblityPkg.

More examples in the MdeModulePkg\Universa and  AppPkg\Applications and the 
ShellPkg

thanks,
Laurie

laurie.jarlst...@intel.com
EFI / Framework Technical
Marketing Engineering Team
(503) 712-9395
From: John Davis [mailto:davi...@gmail.com]
Sent: Friday, February 21, 2014 8:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] hello world application sample and beyond

Hello

Is there an official source for something a little more complex than the 
helloworld application?  I'm trying to use it as a model for something more 
complex and I can not get simple types to even build.  I see that UINT32 is in 
the edkcompatibilitypkg dir and I have added it to my [packages] section in my 
.inf file but I still can't get the include files in the foundation subdir 
beneath there to satisfy my build requirements.

Here is my setup:

The .inf file:
[Sources]
  MyFindRom.c

[Packages]
  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
  EdkCompatibilityPkg/EdkCompatibilityPkg.dec

[LibraryClasses]
  UefiApplicationEntryPoint
  UefiLib
  PcdLib

The .c includes
/** @file
**/

#include 

#include 
#include 

// EdkCompatibilityPkg\Foundation\Efi\Include\EfiTypes.h:typedef uint32_t 
UINT32;
#include 
#include 
#include 


# the error in build

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\OUTPUT\.\
Dpc.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 /GL /FIAutoGen.h 
/EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe 
 /Ic:\fw\edk2\Build\NT32
IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\DEBUG  
/Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\MdePkg\Include  
/Ic:\fw\edk2\MdePkg\Include\Ia32  /Ic:\fw\edk2\MdeMo
dulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
c:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe\Dpc.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(7) : fatal error 
C1083: Cannot open include file: 'EfiTypes.h': No such file or directory
Dpc.c
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
10.0\Vc\bin\cl.exe"' : return code '0x2'
Stop.

# if I remove the EfiTypes.h in the .c source, this is my error:
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2275: 
'UINT32' : illegal use of this type as an expression
c:\fw\edk2\MdePkg\Include\Ia32\ProcessorBind.h(116) : see declaration 
of 'UINT32'
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Un
UTPUT\.\HiiDatabaseEntry.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 
/GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\Md
c:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseDxe\DEBUG
  /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\
lude\Ia32  /Ic:\fw\edk2\MdeModulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
c:\fw\edk2\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseEntry.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2146: 
syntax error : missing ';' before identifier 'include'
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2065: 
'include' : undeclared identifier

fwiw, I have UINT32 include; in my .c source.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[Andrew Fish]

On Feb 21, 2014, at 8:22 AM, John Davis  wrote:

> Hello
> 
> Is there an official source for something a little more complex than the 
> helloworld application?  I'm trying to use it as a model for something more 
> complex and I can not get simple types to even build.  I see that UINT32 is 
> in the edkcompatibilitypkg dir and I have added it to my [packages] section 
> in my .inf file but I still can't get the include files in the foundation 
> subdir beneath there to satisfy my build requirements.
> 

The EdkCompatabilityPkg is for EDK style applications, not edk2 style 
applications. So that is just making things worse. 

There is no stdlib.h for EFI Applications. Like: 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/Application/HelloWorld/HelloWorld.inf

If you need things StdLib then you need to use that package and follow the 
example: 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/AppPkg/Applications/Main/Main.inf

Thanks,

Andrew Fish

> Here is my setup:
> 
> The .inf file:
> [Sources]
>   MyFindRom.c
> 
> [Packages]
>   MdePkg/MdePkg.dec
>   MdeModulePkg/MdeModulePkg.dec
>   EdkCompatibilityPkg/EdkCompatibilityPkg.dec
> 
> [LibraryClasses]
>   UefiApplicationEntryPoint
>   UefiLib
>   PcdLib
> 
> The .c includes
> /** @file
> **/
> 
> #include 
> 
> #include 
> #include 
> 
> // EdkCompatibilityPkg\Foundation\Efi\Include\EfiTypes.h:typedef uint32_t 
> UINT32;
> #include 
> #include 
> #include 
> 
> 
> # the error in build
> 
> "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
> /Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\OUTPUT\.\
> Dpc.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 /GL /FIAutoGen.h 
> /EHs-c- /GR- /GF /Gy /Zi /Gm 
> /Ic:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe  /Ic:\fw\edk2\Build\NT32
> IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\DEBUG  
> /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\MdePkg\Include  
> /Ic:\fw\edk2\MdePkg\Include\Ia32  /Ic:\fw\edk2\MdeMo
> dulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
> c:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe\Dpc.c
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(7) : fatal error 
> C1083: Cannot open include file: 'EfiTypes.h': No such file or directory
> Dpc.c
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\Vc\bin\cl.exe"' : return code '0x2'
> Stop.
> 
> # if I remove the EfiTypes.h in the .c source, this is my error:
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2275: 
> 'UINT32' : illegal use of this type as an expression
> c:\fw\edk2\MdePkg\Include\Ia32\ProcessorBind.h(116) : see declaration 
> of 'UINT32'
> "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
> /Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Un
> UTPUT\.\HiiDatabaseEntry.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
> /O1ib2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\Md
> c:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseDxe\DEBUG
>   /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\
> lude\Ia32  /Ic:\fw\edk2\MdeModulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
> c:\fw\edk2\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseEntry.c
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2146: 
> syntax error : missing ';' before identifier 'include'
> c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2065: 
> 'include' : undeclared identifier
> 
> fwiw, I have UINT32 include; in my .c source.
> 
> 
> -- 
> John F. Davis
> 6 Kandes Court
> Durham, NC 27713
> 919-888-8358
> 
> 独树一帜
> 
> 
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] hello world application sample and beyond

[Carsey, Jaben]

Not sure what specifically you are looking to do.  The 
ShellPkg\Application\Shell is a pretty significant application in terms of what 
it does..

I would stay away from the compatibility stuff unless you are actually 
compiling old code from previous generation environment.

-Jaben

From: John Davis [mailto:davi...@gmail.com]
Sent: Friday, February 21, 2014 8:22 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] hello world application sample and beyond

Hello

Is there an official source for something a little more complex than the 
helloworld application?  I'm trying to use it as a model for something more 
complex and I can not get simple types to even build.  I see that UINT32 is in 
the edkcompatibilitypkg dir and I have added it to my [packages] section in my 
.inf file but I still can't get the include files in the foundation subdir 
beneath there to satisfy my build requirements.

Here is my setup:

The .inf file:
[Sources]
  MyFindRom.c

[Packages]
  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
  EdkCompatibilityPkg/EdkCompatibilityPkg.dec

[LibraryClasses]
  UefiApplicationEntryPoint
  UefiLib
  PcdLib

The .c includes
/** @file
**/

#include 

#include 
#include 

// EdkCompatibilityPkg\Foundation\Efi\Include\EfiTypes.h:typedef uint32_t 
UINT32;
#include 
#include 
#include 


# the error in build

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\OUTPUT\.\
Dpc.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 /GL /FIAutoGen.h 
/EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe 
 /Ic:\fw\edk2\Build\NT32
IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\DEBUG  
/Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\MdePkg\Include  
/Ic:\fw\edk2\MdePkg\Include\Ia32  /Ic:\fw\edk2\MdeMo
dulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
c:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe\Dpc.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(7) : fatal error 
C1083: Cannot open include file: 'EfiTypes.h': No such file or directory
Dpc.c
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
10.0\Vc\bin\cl.exe"' : return code '0x2'
Stop.

# if I remove the EfiTypes.h in the .c source, this is my error:
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2275: 
'UINT32' : illegal use of this type as an expression
c:\fw\edk2\MdePkg\Include\Ia32\ProcessorBind.h(116) : see declaration 
of 'UINT32'
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe" 
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Un
UTPUT\.\HiiDatabaseEntry.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 
/GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\Md
c:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseDxe\DEBUG
  /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\
lude\Ia32  /Ic:\fw\edk2\MdeModulePkg  /Ic:\fw\edk2\MdeModulePkg\Include 
c:\fw\edk2\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseEntry.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2146: 
syntax error : missing ';' before identifier 'include'
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error C2065: 
'include' : undeclared identifier

fwiw, I have UINT32 include; in my .c source.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] hello world application sample and beyond

[John Davis]

Hello

Is there an official source for something a little more complex than the
helloworld application?  I'm trying to use it as a model for something more
complex and I can not get simple types to even build.  I see that UINT32 is
in the edkcompatibilitypkg dir and I have added it to my [packages] section
in my .inf file but I still can't get the include files in the foundation
subdir beneath there to satisfy my build requirements.

Here is my setup:

The .inf file:
[Sources]
  MyFindRom.c

[Packages]
  MdePkg/MdePkg.dec
  MdeModulePkg/MdeModulePkg.dec
  EdkCompatibilityPkg/EdkCompatibilityPkg.dec

[LibraryClasses]
  UefiApplicationEntryPoint
  UefiLib
  PcdLib

The .c includes
/** @file
**/

#include 

#include 
#include 

// EdkCompatibilityPkg\Foundation\Efi\Include\EfiTypes.h:typedef uint32_t
UINT32;
#include 
#include 
#include 


# the error in build

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe"
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\OUTPUT\.\
Dpc.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE /O1ib2 /GL /FIAutoGen.h
/EHs-c- /GR- /GF /Gy /Zi /Gm
/Ic:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe  /Ic:\fw\edk2\Build\NT32
IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\Network\DpcDxe\DpcDxe\DEBUG
 /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\MdePkg\Include
 /Ic:\fw\edk2\MdePkg\Include\Ia32  /Ic:\fw\edk2\MdeMo
dulePkg  /Ic:\fw\edk2\MdeModulePkg\Include
c:\fw\edk2\MdeModulePkg\Universal\Network\DpcDxe\Dpc.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(7) : fatal error
C1083: Cannot open include file: 'EfiTypes.h': No such file or directory
Dpc.c
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
10.0\Vc\bin\cl.exe"' : return code '0x2'
Stop.

# if I remove the EfiTypes.h in the .c source, this is my error:
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error
C2275: 'UINT32' : illegal use of this type as an expression
c:\fw\edk2\MdePkg\Include\Ia32\ProcessorBind.h(116) : see
declaration of 'UINT32'
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Vc\bin\cl.exe"
/Foc:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Un
UTPUT\.\HiiDatabaseEntry.obj /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE
/O1ib2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Ic:\fw\edk2\Md
c:\fw\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseDxe\DEBUG
 /Ic:\fw\edk2\MdePkg  /Ic:\fw\edk2\
lude\Ia32  /Ic:\fw\edk2\MdeModulePkg  /Ic:\fw\edk2\MdeModulePkg\Include
c:\fw\edk2\MdeModulePkg\Universal\HiiDatabaseDxe\HiiDatabaseEntry.c
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error
C2146: syntax error : missing ';' before identifier 'include'
c:\fw\edk2\MdeModulePkg\Application\MyFindRom\MyFindRom.c(81) : error
C2065: 'include' : undeclared identifier

fwiw, I have UINT32 include; in my .c source.


-- 
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358

独树一帜
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Upstream EDK2 broken with latest Linaro toolchain (13.12 onwards)

[Ryan Harkin]

Hi Olivier,

I've just noticed that the upstream EDK2 repository for the FVP AEMv8
model is broken when built with Linaro GCC 13.12 onwards.

The error I see is:

UEFI firmware (version  built at 14:54:24 on Feb 21 2014)
add-symbol-file
/linaro/uefi/master/upstream/edk2.git/Build/ArmVExpress-FVP-AArch64/DEBUG_ARMGCC/AARCH64/ArmPlatformPkg/PrePi/PeiMPCore/DEBUG/ArmPlatformPrePiMPCore.dll
0x88000780
Decompress Failed - Not Found

ASSERT_EFI_ERROR (Status = Not Found)
ASSERT /linaro/uefi/master/upstream/edk2.git/ArmPlatformPkg/PrePi/PrePi.c(194):
!EFI_ERROR (Status)

I've tracked the bug as far as function "FfsProcessSection" [1] where
at line 373, it calls into function "ExtractGuidedSectionDecode" [2]
which then calls into "SavedData->ExtractDecodeHandlerTable [Index]".
At that point, I can't work out where it goes.

I can "fix" the problem if I re-org the variables at the top of
FfsProcessSection so that DstBuffer is at the start of the
declarations.  That is obviously not a fix.  But it will probably hint
at why the subsequent code is broken.

Cheers,
Ryan

[1] EmbeddedPkg/Library/PrePiLib/FwVol.c, line 285
[2] 
EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.c:166

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] working with .uni files in git

[Laszlo Ersek]

On 02/21/14 12:43, Laszlo Ersek wrote:
> This is a small hint for people who want to see the changes in .uni
> files (== UCS-2 encoded strings for HII forms) while using git. I've
> distilled it from  and I'm
> posting it to save others time.
> 
> (1) Add the following lines to your .git/info/attributes (the .uni one
> is imporant, the others are here just for completeness):
> 
> *.efi -diff
> *.EFI -diff
> *.uni diff=uni
> *.UNI diff=uni
> *.bin -diff
> *.BIN -diff
> *.raw -diff
> *.RAW -diff
> *.bmp -diff
> *.BMP -diff
> 
> (2) Then edit .git/config:
> 
> [diff "uni"]
>   textconv = iconv -f UCS-2 -t UTF-8
>   binary = true
> 
> (3) Profit! :)
> 
> Note that this only helps with *viewing* changes as patches. Git still
> won't help you resolve conflicts during rebases, it won't try to merge
> changes, and importantly it won't generate textual patches in
> git-format-patch. You'll also still need a UCS-2 compatible text editor
> that preserves the BOM (like "gedit") to edit .uni files.

Sorry for the self-followup, but I figured out how it can be made work
for merges too (cherry-pick, conflicts in rebase / merge etc.).

So, in addition to the above:

(4) modify .git/info/attributes like this (ie. add the "merge" attribute
for *.uni files):

*.uni diff=uni merge=uni
*.UNI diff=uni merge=uni

(5) append to .git/config:

[merge "uni"]
name = merge driver for UCS-2 encoded text files
driver = uni-merge %O %A %B

(6) Place the attached "uni-merge" script on your PATH (and make it
executable).

(7) Profit more! :)

Thanks
Laszlo
#!/bin/bash

# Merge UCS-2 encoded text files.
# This is a git-merge driver. It will overwrite "$MINE".
#
# Exit status:
# 0 -- no conflicts
# 1 -- conflicts
# 2 -- trouble

OLD="$1"
MINE="$2"
YOURS="$3"

# Set safe defaults for the trap handler.
OLD_UTF8=
MY_UTF8=
YOUR_UTF8=
NEW_UTF8=
EX=2

trap 'rm -f -- "$OLD_UTF8" "$MY_UTF8" "$YOUR_UTF8" "$NEW_UTF8"; exit $EX' EXIT
set -e -u -C

OLD_UTF8=$(mktemp)
iconv --from UCS-2 --to UTF-8 <"$OLD" >>"$OLD_UTF8"

MY_UTF8=$(mktemp)
iconv --from UCS-2 --to UTF-8 <"$MINE" >>"$MY_UTF8"

YOUR_UTF8=$(mktemp)
iconv --from UCS-2 --to UTF-8 <"$YOURS" >>"$YOUR_UTF8"

NEW_UTF8=$(mktemp)
set +e
diff3 --merge --label=mine --label=old --label=yours -- \
"$MY_UTF8" "$OLD_UTF8" "$YOUR_UTF8" >>"$NEW_UTF8"
DIFFRET=$?
set -e

if [ 0 -ne "$DIFFRET" ] && [ 1 -ne "$DIFFRET" ]; then
  exit
fi

iconv --from UTF-8 --to UCS-2 <"$NEW_UTF8" >|"$MINE"
EX=$DIFFRET
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] working with .uni files in git

[Laszlo Ersek]

This is a small hint for people who want to see the changes in .uni
files (== UCS-2 encoded strings for HII forms) while using git. I've
distilled it from  and I'm
posting it to save others time.

(1) Add the following lines to your .git/info/attributes (the .uni one
is imporant, the others are here just for completeness):

*.efi -diff
*.EFI -diff
*.uni diff=uni
*.UNI diff=uni
*.bin -diff
*.BIN -diff
*.raw -diff
*.RAW -diff
*.bmp -diff
*.BMP -diff

(2) Then edit .git/config:

[diff "uni"]
textconv = iconv -f UCS-2 -t UTF-8
binary = true

(3) Profit! :)

Note that this only helps with *viewing* changes as patches. Git still
won't help you resolve conflicts during rebases, it won't try to merge
changes, and importantly it won't generate textual patches in
git-format-patch. You'll also still need a UCS-2 compatible text editor
that preserves the BOM (like "gedit") to edit .uni files.

HTH!
Laszlo

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] UEFI writing protection variable

[miguelro...@ua.pt]

Hello all,


I'm a master's student and for my final thesis I am writing a UEFI 
Application/Driver.


In my UEFI Application/Driver I need to have access to a non volatile variable 
that must be visible (write permission) only to my UEFI Application/Driver and 
invisible (no read permission) for other drivers, applications or operating 
systems.


Does UEFI provide any mechanism to create a non volatile variable (or some kind 
of data storage) that is only accessible to my driver? Can I have some hints on 
how to do this?


I have been reading about the Secure Boot secure variables and Key Managment 
Service but, the first does not seem to provide reading protection and the 
second does not specify read/write protections for the saved keys.


Regards

Miguel Rocha
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel