[edk2] [Patch]Vlv2DeviceRefCodePkg:Set USB Ports as User Visible in the _PLD

[Lu, ShifeiX A]

Set USB Ports as User Visible in the _PLD.


Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Lu, ShifeiX A 
mailto:shifeix.a...@intel.com>>




Thanks,
Shifei



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Mixed (unix/windows) line endings in EDK2

[Scott Duplichan]

I noticed a line number discrepancy when using different combinations
of diff/patch tools. The problem is caused by inconsistent line endings
in some of the files. EDK2 does have a mix of Linux and Windows style
files. Apparently the tools handle this fairly well. But the trouble I
have is with single files that contain a mix of both styles. Here is a
bash command that detects some of the inconsistent files:

grep --null-data --include=*.{c,h,bat,cmd,vfr,vfi,txt,template,sh,s,inf,inc,h} 
-rlbUaP "\x0D\x0D\x0A"

output:
CorebootModulePkg/Library/CbParseLib/CbParseLib.inf
289 files from the Vlv2TbltDevicePkg directory.

How can we make these files use consistent line endings?
Would a patch work?

Thanks,
Scott

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ShellPkg: Add function comments and refine code format to follow EDKII coding style.

[Qiu Shumin]

Cc: Ronald Cron 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 
---
 ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 130 ++--
 1 file changed, 123 insertions(+), 7 deletions(-)

diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c 
b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
index b872afd..d837485 100644
--- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
+++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
@@ -36,18 +36,69 @@ STATIC CONST CHAR16 mTftpProgressFrame[] = L"[
 // (TFTP_PROGRESS_MESSAGE_SIZE-1) '\b'
 STATIC CONST CHAR16 mTftpProgressDelete[] = 
L"\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b";
 
-STATIC BOOLEAN StringToUint16 (
+/**
+  Check and convert the UINT16 option values of the 'tftp' command
+
+  @param[in]  ValueStr  Value as an Unicode encoded string
+  @param[out] Value UINT16 value
+
+  @return TRUE  The value was returned.
+  @return FALSE A parsing error occured.
+**/
+STATIC 
+BOOLEAN 
+StringToUint16 (
   IN   CONST CHAR16  *ValueStr,
   OUT  UINT16*Value
   );
 
-STATIC EFI_STATUS GetNicName (
+/**
+  Get the name of the NIC.
+
+  @param[in]   ControllerHandle  The network physical device handle.
+  @param[in]   NicNumber The network physical device number.
+  @param[out]  NicName   Address where to store the NIC name.
+ The memory area has to be at least
+ IP4_NIC_NAME_LENGTH bytes wide.
+
+  @return  EFI_SUCCESS  The name of the NIC was returned.
+  @return  Others   The creation of the child for the Managed
+Network Service failed or the opening of
+the Managed Network Protocol failed or
+the operational parameters for the
+Managed Network Protocol could not be
+read.
+**/
+STATIC 
+EFI_STATUS 
+GetNicName (
   IN   EFI_HANDLE  ControllerHandle,
   IN   UINTN   Index,
   OUT  CHAR16  *NicName
   );
 
-STATIC EFI_STATUS CreateServiceChildAndOpenProtocol (
+/**
+  Create a child for the service identified by its service binding protocol 
GUID
+  and get from the child the interface of the protocol identified by its GUID.
+
+  @param[in]   ControllerHandleController handle.
+  @param[in]   ServiceBindingProtocolGuid  Service binding protocol GUID of the
+   service to be created.
+  @param[in]   ProtocolGuidGUID of the protocol to be open.
+  @param[out]  ChildHandle Address where the handler of the
+   created child is returned. NULL is
+   returned in case of error.
+  @param[out]  Interface   Address where a pointer to the
+   protocol interface is returned in
+   case of success.
+
+  @return  EFI_SUCCESS  The child was created and the protocol opened.
+  @return  Others   Either the creation of the child or the opening
+of the protocol failed.
+**/
+STATIC 
+EFI_STATUS 
+CreateServiceChildAndOpenProtocol (
   IN   EFI_HANDLE  ControllerHandle,
   IN   EFI_GUID*ServiceBindingProtocolGuid,
   IN   EFI_GUID*ProtocolGuid,
@@ -55,20 +106,71 @@ STATIC EFI_STATUS CreateServiceChildAndOpenProtocol (
   OUT  VOID**Interface
   );
 
-STATIC VOID CloseProtocolAndDestroyServiceChild (
+/**
+  Close the protocol identified by its GUID on the child handle of the service
+  identified by its service binding protocol GUID, then destroy the child
+  handle.
+
+  @param[in]  ControllerHandleController handle.
+  @param[in]  ServiceBindingProtocolGuid  Service binding protocol GUID of the
+  service to be destroyed.
+  @param[in]  ProtocolGuidGUID of the protocol to be closed.
+  @param[in]  ChildHandle Handle of the child to be destroyed.
+
+**/
+STATIC 
+VOID 
+CloseProtocolAndDestroyServiceChild (
   IN  EFI_HANDLE  ControllerHandle,
   IN  EFI_GUID*ServiceBindingProtocolGuid,
   IN  EFI_GUID*ProtocolGuid,
   IN  EFI_HANDLE  ChildHandle
   );
 
-STATIC EFI_STATUS GetFileSize (
+/**
+  Worker function that gets the size in numbers of bytes of a file from a TFTP
+  server before to download the file.
+
+  @param[in]   Mtftp4MTFTP4 protocol interface
+  @param[in]   FilePath  Path of the file, ASCII encoded
+  @param[out]  FileSize  Address where to store the file size in number of
+ bytes.
+
+  @retval  EFI_SUCCESS  The size of the file was returned.
+  @retval  EFI_UNSUPPORTED  The server does not support the "tsize" option.
+  @retval  Others   Error when retrieving the information from the 

Re: [edk2] [PATCH] MdePkg UefiLib: Fix ASSERT in CatVSPrint

[Gao, Liming]

Reviewed-by: Liming Gao 

-Original Message-
From: Wu, Hao A 
Sent: Wednesday, July 29, 2015 9:21 AM
To: edk2-devel@lists.01.org; Gao, Liming; Qiu, Shumin
Cc: Wu, Hao A
Subject: [PATCH] MdePkg UefiLib: Fix ASSERT in CatVSPrint

The second parameter 'DestMax' of StrCpyS() should be the number of unicode 
characters, not the size in bytes.

Also, code is modified to keep align with the one in 
IntelFrameworkPkg\Library\FrameworkUefiLib\UefiLibPrint.c.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdePkg/Library/UefiLib/UefiLibPrint.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/MdePkg/Library/UefiLib/UefiLibPrint.c 
b/MdePkg/Library/UefiLib/UefiLibPrint.c
index 91ce492..9f52e7d 100644
--- a/MdePkg/Library/UefiLib/UefiLibPrint.c
+++ b/MdePkg/Library/UefiLib/UefiLibPrint.c
@@ -754,14 +754,16 @@ CatVSPrint (
 SizeRequired = sizeof(CHAR16) + (CharactersRequired * sizeof(CHAR16));
   }
 
-  BufferToReturn = AllocateZeroPool(SizeRequired);
+  BufferToReturn = AllocatePool(SizeRequired);
 
   if (BufferToReturn == NULL) {
 return NULL;
+  } else {
+BufferToReturn[0] = L'\0';
   }
-  
+
   if (String != NULL) {
-StrCpyS(BufferToReturn, SizeRequired, String);
+StrCpyS(BufferToReturn, SizeRequired / sizeof(CHAR16), String);
   }
 
   UnicodeVSPrint(BufferToReturn + StrLen(BufferToReturn), 
(CharactersRequired+1) * sizeof(CHAR16), FormatString, Marker);
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] IntelFrameworkPkg FrameworkUefiLib: Fix ASSERT in CatVSPrint

[Fan, Jeff]

It's good!

Reviewed-by: Jeff Fan 

-Original Message-
From: Wu, Hao A
Sent: Wednesday, July 29, 2015 9:27 AM
To: edk2-devel@lists.01.org; Fan, Jeff; Qiu, Shumin
Cc: Wu, Hao A
Subject: [PATCH] IntelFrameworkPkg FrameworkUefiLib: Fix ASSERT in CatVSPrint

The second parameter 'DestMax' of StrCpyS() should be the number of unicode 
characters, not the size in bytes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c 
b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
index 2570ff4..f0dcf9f 100644
--- a/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
+++ b/IntelFrameworkPkg/Library/FrameworkUefiLib/UefiLibPrint.c
@@ -763,7 +763,7 @@ CatVSPrint (
   }
 
   if (String != NULL) {
-StrCpyS(BufferToReturn, SizeRequired, String);
+StrCpyS(BufferToReturn, SizeRequired / sizeof(CHAR16), String);
   }
 
   UnicodeVSPrint(BufferToReturn + StrLen(BufferToReturn), 
(CharactersRequired+1) * sizeof(CHAR16), FormatString, Marker);
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] NetworkPkg: Fix assert caused by wrong parameter in AsciiStrCpyS()

[Wu, Jiaxin]

Reviewed-by: Jiaxin Wu 


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang 
Lubo
Sent: Wednesday, August 5, 2015 10:04 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin
Subject: [edk2] [patch] NetworkPkg: Fix assert caused by wrong parameter in 
AsciiStrCpyS()

The 2nd parameter in AsciiStrCpyS() should be the max available memory of the 
destination.

Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/Mtftp6Dxe/Mtftp6Support.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c 
b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
index 20888e8..c31fc9d 100644
--- a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
+++ b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
@@ -600,11 +600,11 @@ Mtftp6SendError (
   }
 
   TftpError->OpCode  = HTONS (EFI_MTFTP6_OPCODE_ERROR);
   TftpError->Error.ErrorCode = HTONS (ErrCode);
 
-  AsciiStrCpyS ((CHAR8 *) TftpError->Error.ErrorMessage, sizeof 
(TftpError->Error.ErrorMessage) / sizeof (TftpError->Error.ErrorMessage[0]), 
(CHAR8 *) ErrInfo);
+  AsciiStrCpyS ((CHAR8 *) TftpError->Error.ErrorMessage, AsciiStrLen 
+ ((CHAR8 *) ErrInfo) + 1 , (CHAR8 *) ErrInfo);
 
   //
   // Save the packet buf for retransmit
   //
   if (Instance->LastPacket != NULL) {
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [patch] NetworkPkg: Fix assert caused by wrong parameter in AsciiStrCpyS()

[Zhang Lubo]

The 2nd parameter in AsciiStrCpyS() should be the max available
memory of the destination.

Cc: Fu Siyuan
Cc: Ye Ting
CC: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
---
 NetworkPkg/Mtftp6Dxe/Mtftp6Support.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c 
b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
index 20888e8..c31fc9d 100644
--- a/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
+++ b/NetworkPkg/Mtftp6Dxe/Mtftp6Support.c
@@ -600,11 +600,11 @@ Mtftp6SendError (
   }
 
   TftpError->OpCode  = HTONS (EFI_MTFTP6_OPCODE_ERROR);
   TftpError->Error.ErrorCode = HTONS (ErrCode);
 
-  AsciiStrCpyS ((CHAR8 *) TftpError->Error.ErrorMessage, sizeof 
(TftpError->Error.ErrorMessage) / sizeof (TftpError->Error.ErrorMessage[0]), 
(CHAR8 *) ErrInfo);
+  AsciiStrCpyS ((CHAR8 *) TftpError->Error.ErrorMessage, AsciiStrLen ((CHAR8 
*) ErrInfo) + 1 , (CHAR8 *) ErrInfo);
 
   //
   // Save the packet buf for retransmit
   //
   if (Instance->LastPacket != NULL) {
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How to update an App Lib dependency ?

[Tian, Feng]

Why do you need to do the copy operation?

EDKII Build system could ensure this dependency. Please read EDKII module 
writer's guide at first 
(https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-User-Documentation)

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shubha 
Ramani
Sent: Wednesday, August 05, 2015 00:50
To: edk2-devel@lists.01.org
Subject: [edk2] How to update an App Lib dependency ?

Hello there. I have built a lib under C:\edk2\MyWorkspace\MdeModulePkg\Library 
and an Application which consumes that library under  
C:\edk2\MyWorkspace\MdeModulePkg\Application.
If I change code in the lib, how can I make sure that the rebuilt App gets the 
latest lib ? I usually manuallycopy the static lib file from 
C:\edk2\MyWorkspace\Build\DuetPkgX64\RELEASE_VS2012x86\X64\MdeModulePkg\Libraryinto
 the Application folder. I know there's got to be a better way.
Do we add a post-build rule to automatically copy the lib file from  
 to   ? If so, can you tell me how this is done ?
Thanks,
Shubha
Shubha D. Ramani
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 characters

[Qiu, Shumin]

Reviewed-by: Qiu Shumin 

From: Shah, Tapan [mailto:tapands...@hp.com]
Sent: Wednesday, August 05, 2015 3:54 AM
To: Carsey, Jaben; Qiu, Shumin; edk2-devel@lists.01.org
Cc: Phillips, Chris J (Plano, TX)
Subject: ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 
characters

Jaben / Shumin,
   Can you review this one-line fix?

Thanks,
Tapan


ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 characters

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off by: Tapan Shah mailto:tapands...@hp.com>>
Reviewed-by: Chris Phillips mailto:chr...@hp.com>>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HID descriptor parsing

[Tian, Feng]

UsbKbDxe driver in MdeModulePkg/Bus/Usb handles usb key board devices. Note we 
don’t parse its HID descriptor in this driver, we only use SET_REPORT request 
to enable Keyboard’s LED.

If you need to parse HID items, you can refer to the logic in usb mouse driver 
and write a new one.

PS: UefiUsbLib in MdePkg/Library provides some library APIs to provide HID 
services.

From: cruxpot [mailto:crux...@gmail.com]
Sent: Wednesday, August 05, 2015 05:10
To: Tian, Feng
Cc: Ulysses Mckibbens; edk2-de...@lists.sourceforge.net
Subject: Re: [edk2] HID descriptor parsing


Hi Tian,

Which driver handles the keyboard devices? we did see that in the mouse driver.
On Aug 3, 2015 6:08 PM, "Tian, Feng" 
mailto:feng.t...@intel.com>> wrote:
UsbBusDxe driver is a bus driver who is used to enumerate attached devices and 
start their corresponding device drivers.

So you couldn’t see HID parser in UsbBus driver. You have to see it in usb 
device drivers.

UsbMouseDxe/MouseHid.c is such sample for how parsing HID items.

From: Ulysses Mckibbens 
[mailto:zergrusher2...@gmail.com]
Sent: Tuesday, August 04, 2015 00:20
To: edk2-de...@lists.sourceforge.net
Subject: [edk2] HID descriptor parsing

Hi,

Where is the HID descriptor parsed in the UsbBusDxe driver? I am using a 
Minnowboard Max with 0.81 firmware and I am trying to debug the HID descriptor 
attributes for a device I'm writing a driver for. Any pointers?

--

___
edk2-devel mailing list
edk2-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 characters

[Shah, Tapan]

Jaben / Shumin,
   Can you review this one-line fix?

Thanks,
Tapan


ShellPkg: Fix 'drivers' assert issue for a driver name longer than 35 characters

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off by: Tapan Shah mailto:tapands...@hp.com>>
Reviewed-by: Chris Phillips mailto:chr...@hp.com>>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmVirtPkg/ArmVirtXen: add missing BdsLib instance

[Ard Biesheuvel]

Now that the ARM BDS has been removed, there is a remaining BdsLib
dependency in ArmVirtXen that has now become unresolved. So re-add
the BdsLib resolution that we removed from ArmVirt.dsc.inc to
ArmVirtXen.dsc

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---

Committing as a build fix after my SVN r18153 has broken the build

 ArmVirtPkg/ArmVirtXen.dsc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 06c0003ae893..5c19afca30b9 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -58,6 +58,8 @@ [LibraryClasses.common]
   
PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
 
+  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
+
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
 
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

[Ard Biesheuvel]

On 4 August 2015 at 17:21, Ard Biesheuvel  wrote:
> This series is a followup to the patches
>   'ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default'
> and
>   'ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build'
> that I sent out earlier today. (The former was itself a replacement for
> 'ArmVirtPkg: align ARM BDS build with LinuxLoader changes', part of which
> has been brought back in patch #3 of this series)
>
> The ARM BDS currently depends on the LinuxLoader UEFI application to be
> present in an FV, and it to be loadable and executable via the protocols
> installed by FvSimpleFileSystemDxe. The current ArmVirtQemu builds lack
> both the UEFI application and the filesystem driver, and so these builds
> have been broken ever since the LinuxLoader was split off into a separate
> application.
>
> The LinuxLoader for AARCH64 is buggy and violates the arm64 boot protocol,
> and the ARM BDS violates the UEFI spec. So instead of restoring the ARM BDS
> to working order, we drop it completely from the ArmVirtQemu platform.
> (patch #1)
>
> In patch #2, we remove a copy-pasted ARM BDS related PCD definition from the
> Xen build that has never been used, as the Xen build is Intel BDS only.
>
> Patch #3 adds support for the Linux loader to the ARM build of ArmVirtQemu
> when running the Intel BDS. The LinuxLoader for 32-bit ARM implements the
> boot protocol correctly (although some patches are pending to improve it in
> some areas), and is actually required to boot a Linux kernel at all since
> the ARM/Linux kernel has no UEFI stub support (yet).
>
> Ard Biesheuvel (3):
>   ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default
>   ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD
>   ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build
>

Committed as SVN r18153 .. r18155
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

[Laszlo Ersek]

On 08/04/15 18:47, Ard Biesheuvel wrote:
> On 4 August 2015 at 17:21, Ard Biesheuvel  wrote:
>> The ARM build still needs an intermediate loader to boot Linux,
>> since ARM/Linux has no builtin UEFI boot stub (yet).
>>
>> So add the LinuxLoader UEFI application to the FV, and enable
>> the FvSimpleFileSystemDxe driver so that we can invoke the
>> Linux loader from the shell, e.g.,
>>
>>   Shell> linuxloader fs2:zImage -c console=ttyAMA0
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> Reviewed-by: Laszlo Ersek 
>> ---
>>  ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
>>  ArmVirtPkg/ArmVirtQemu.dsc | 9 +
>>  ArmVirtPkg/ArmVirtQemu.fdf | 5 +
>>  3 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index ced45c8194bc..7bba6eba05a8 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>>
>> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
>>
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
>> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>>
>>  [LibraryClasses.common.UEFI_DRIVER]
>>
>> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
>> @@ -396,9 +399,6 @@ [Components.common]
>>
>> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>>
>> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>>
>> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
>> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>>
>> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index 5a644090be7c..61e95517259c 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -354,3 +354,12 @@ [Components.common]
>>MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>> +
>> +[Components.ARM]
>> +  #
>> +  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still 
>> need
>> +  # an intermediate OS loader. Add the LinuxLoader UEFI application so we 
>> can
>> +  # invoke it from the shell.
>> +  #
>> +  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
>> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> 
> This needs
> 
> +
> +  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
> 
> since I removed the common BdsLib resolution from ArmVirt.dsc.inc in patch #1.
> 
> I will just add that when committing, unless anyone feels I need to repost.
> 

OK with me
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] How to update an App Lib dependency ?

[Shubha Ramani]

Hello there. I have built a lib under C:\edk2\MyWorkspace\MdeModulePkg\Library 
and an Application which consumes that library under  
C:\edk2\MyWorkspace\MdeModulePkg\Application.
If I change code in the lib, how can I make sure that the rebuilt App gets the 
latest lib ? I usually manuallycopy the static lib file from 
C:\edk2\MyWorkspace\Build\DuetPkgX64\RELEASE_VS2012x86\X64\MdeModulePkg\Libraryinto
 the Application folder. I know there's got to be a better way.
Do we add a post-build rule to automatically copy the lib file from  
 to   ? If so, can you tell me how this is done ?
Thanks,
Shubha
Shubha D. Ramani
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/3] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

[Ard Biesheuvel]

On 4 August 2015 at 17:21, Ard Biesheuvel  wrote:
> The ARM build still needs an intermediate loader to boot Linux,
> since ARM/Linux has no builtin UEFI boot stub (yet).
>
> So add the LinuxLoader UEFI application to the FV, and enable
> the FvSimpleFileSystemDxe driver so that we can invoke the
> Linux loader from the shell, e.g.,
>
>   Shell> linuxloader fs2:zImage -c console=ttyAMA0
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> Reviewed-by: Laszlo Ersek 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
>  ArmVirtPkg/ArmVirtQemu.dsc | 9 +
>  ArmVirtPkg/ArmVirtQemu.fdf | 5 +
>  3 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index ced45c8194bc..7bba6eba05a8 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>
>  [LibraryClasses.common.UEFI_DRIVER]
>
> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
> @@ -396,9 +399,6 @@ [Components.common]
>
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 5a644090be7c..61e95517259c 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -354,3 +354,12 @@ [Components.common]
>MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
> +
> +[Components.ARM]
> +  #
> +  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still 
> need
> +  # an intermediate OS loader. Add the LinuxLoader UEFI application so we can
> +  # invoke it from the shell.
> +  #
> +  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf

This needs

+
+  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf

since I removed the common BdsLib resolution from ArmVirt.dsc.inc in patch #1.

I will just add that when committing, unless anyone feels I need to repost.

-- 
Ard.


> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
> index a9ad9ca6fe2d..6faf3bc12172 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -237,6 +237,11 @@ [FV.FvMain]
>  SECTION RAW = MdeModulePkg/Logo/Logo.bmp
>}
>
> +!if $(ARCH) == ARM
> +  INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> +  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> +!endif
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Check arguments for PrintLib format format string

[Scott Duplichan]

Laszlo Ersek [mailto:ler...@redhat.com] wrote:

]Sent: Tuesday, August 04, 2015 09:01 AM
]To: Scott Duplichan 
]Cc: 'edk2-devel@lists.01.org' ; 'Andrew Fish' 

]Subject: Re: [edk2] [PATCH] Check arguments for PrintLib format format string
]
]On 08/04/15 03:19, Scott Duplichan wrote:
]> Andrew Fish [mailto:af...@apple.com] wrote:
]> 
]> ]Sent: Monday, August 03, 2015 04:48 PM
]> ]To: Scott Duplichan 
]> ]Cc: edk2-devel@lists.01.org ; Laszlo Ersek 

]> ]Subject: Re: [edk2] [PATCH] Check arguments for PrintLib format format 
string
]> ]
]> ]
]> ]> On Aug 2, 2015, at 9:58 PM, Scott Duplichan  wrote:
]> ]> 
]> ]> Add support for checking the argument list of functions that use
]> ]> a PrintLib style format string. This feature requires a patched
]> ]> gcc tool chain that is identified by the presence of compiler
]> ]> predefined macro __GCC_EDK2_FORMATS__. To enable format string
]> ]> checking, use a patched gcc tool chain and define the macro
]> ]> EDK2_FORMAT_CHECKING. 
]> ]> 
]> ]
]> ]Scott, 
]> ]
]> ]> +//
]> ]> +#if defined(EDK2_FORMAT_CHECKING)
]> ]
]> ]Is this an external flag? Why not just use __GCC_EDK2_FORMATS__, if that is 
what the compiler adds?
]> ]This feature could get added to other compilers in the future...
]> 
]> Good points. Yes, I am setting EDK2_FORMAT_CHECKING externally. Here is how 
I run a
]> batch mode build test:
]> 
]> D:\edk2build> set GCC_EXTRA_CC_FLAGS=-DEDK2_FORMAT_CHECKING -Wno-error
]> D:\edk2build> buildall-gcc49.bat
]> 
]> The first command sets an environment variable who's contents are appended
]> to the GCC CC flags. This relies on a recently submitted (and rejected)
]> patch: "BaseTools: Add mechanism to override or add CC_FLAGS"
]> 
]> I actually modified that patch slightly because it assumed the presence
]> of the recently submitted but not approved GCC Link Time Optimization
]> patch. The revised patch is "gcc_extra_cc_flags_08-02-2015.patch" from:
]> 
http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Tool%20Chain%]20Support/gcc/
]> 
]> To answer your question "Why not just use __GCC_EDK2_FORMATS__".
]> With format checking enabled, a batch EDK2 build I use to check for 
]> breakage produces 1,049 unique cases of -Wformat warnings. So we need
]> a way to turn the new warnings off so that a build can complete without
]> suppressing the 'warning as error' policy. The patch is using the
]> compiler macro EDK2_FORMAT_CHECKING. But there is a way to
]> enable/disable format checking that does use a flag: Use two separate
]> GCC49 tool chains. One standard, and one with the EDK2 format checking
]> patch applied. These libraryless gcc tool chains are quite small and
]> keeping more of them is not unreasonable.
]> 
]> 
]> ]> +  #if !defined(__GCC_EDK2_FORMATS__)
]> ]> +#error "EDK2_FORMAT_CHECKING is not supported by this tool chain"
]> ]> +  #else
]> ]> +#define EFIFORMAT(FormatType, FormatPosition) \
]> ]> +__attribute__((format (FormatType, FormatPosition, 
FormatPosition+1)))
]> ]> +  #endif
]> ]> +#else
]> ]> +  #define EFIFORMAT(FormatType, FormatPosition)
]> ]> +#endif
]> ]
]> ]I don’t have an issue with adding the more generic EFIFORMAT() macro, but 
it would be more general ]to ]hide the 1st argument to __attribtue__ ((format, 
…)) as that is implementation specific. 
]> ]So maybe:
]> ]#define EFI_PRINT_FORMAT(FormatPossition) EFIFORMAT(edk2_printf, 
FormatPossition)
]> 
]> That is actually what I wanted to do. But then I encountered the %N, %H, %E,
]> %B, %V extensions of function ShellPrintEx. My first idea for accommodating
]> the Shell Extensions was to use an optional macro argument for this single 
case.
]> But that requires complex macro logic. The next solution I considered was a 
pair
]> of macros: one for EDK2 standard formats and one for EDK2 formats with Shell 
Print
]> Extensions. Though that is probably the best answer, I couldn't think of a 
good
]> pair of macro names. Maybe EFIFORMAT/EFIFORMAT_SHELL would be OK. If you can
]> suggest a pair of names, I could resubmit the patch using them.
]> 
]> ]So if this every gets added to clang, or VC++ (via SAL Annotations?) it 
does not blow up if the ]edk2_printf name is not used. 
]> 
]> Yes. So all we need is a way to handle the special case of function 
ShellPrintEx
]> and then the only macro argument needed is a single one that identifies which
]> function argument passes the format string.
]> 
]> The one remaining issue is how to temporarily suppress the 'warning as error'
]> policy. With 1,049 unique cases to fix, the need for suppressing 'warning as
]> error' is apparent. Without doing so, you can see only one error at a time 
and
]> that error must be fixed before the next can be seen. I fear that if there is
]> no simple way to make a format checking enabled build run to completion, then
]> no one will actually try or use this patch.
]
]I agree. Last time you posted the OvmfPkg format warnings, I relied on
]them having been provided in a "batch" format.
]
]> Th

Re: [edk2] [PATCH 1/3] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Laszlo Ersek]

On 08/04/15 17:21, Ard Biesheuvel wrote:
> ARM BDS support in ArmVirtQemu has been broken since SVN r17969
> ("ArmPkg/BdsLib: Remove Linux loader from BdsLib") dated July 14th.
> 
> Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
> altogether: they violate both the UEFI spec and the arm64 Linux boot
> protocol, and lack the level of integration with the QEMU command
> line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc |  5 +--
>  ArmVirtPkg/ArmVirtQemu.dsc | 32 ++--
>  ArmVirtPkg/ArmVirtQemu.fdf |  6 
>  3 files changed, 3 insertions(+), 40 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 8c54242b597b..ced45c8194bc 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -106,8 +106,7 @@ [LibraryClasses.common]
>DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
>
> DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
>  
> -  # BDS Libraries
> -  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
> +  # Flattened Device Tree (FDT) access library
>FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
>  
># PCI Libraries
> @@ -279,8 +278,6 @@ [PcdsFeatureFlag.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
>  
>  [PcdsFixedAtBuild.common]
> -  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
> -
>gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
>gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
>gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index c199cac72cfd..5a644090be7c 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -57,13 +57,11 @@ [LibraryClasses.common]
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>  
> -!if $(INTEL_BDS) == TRUE
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
>
> PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> -!endif
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> @@ -99,8 +97,6 @@ [PcdsFeatureFlag.common]
>gArmVirtTokenSpaceGuid.PcdKludgeMapPciMmioAsCached|TRUE
>  
>  [PcdsFixedAtBuild.common]
> -  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"QEMU"
> -
>gArmPlatformTokenSpaceGuid.PcdCoreCount|1
>  !if $(ARCH) == AARCH64
>gArmTokenSpaceGuid.PcdVFPEnabled|1
> @@ -127,29 +123,11 @@ [PcdsFixedAtBuild.common]
>## PL011 - Serial Terminal
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
>  
> -  #
> -  # ARM OS Loader
> -  #
> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
> virtio31:hd0:part0"
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
> console=ttyAMA0 earlycon uefi_debug"
> -
> -  #
> -  # Settings for ARM BDS -- use the serial console (ConIn & ConOut).
> -  #
> -!if $(TTY_TERMINAL) == TRUE
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
> -  ## Terminal Type - TTYTERM, consistent with ConOut/ConIn Device Path.
> +  ## Default Terminal Type
>## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
> +!if $(TTY_TERMINAL) == TRUE
>gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
>  !else
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
> -  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
> -  ## When Intel BDS is enabled, the above ConOut/ConIn device path is 
> useless,
> -  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
> -  ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
>gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
>  !endif
>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
> @@ -175,10 +153,8 @@

Re: [edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD

[Laszlo Ersek]

On 08/04/15 17:21, Ard Biesheuvel wrote:
> The PcdFirmwareVendor PCD was never used on this platform, since
> it has never supported the ARM BDS. So remove it.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtXen.dsc | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index b4007ff3c6a4..06c0003ae893 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -79,7 +79,6 @@ [BuildOptions]
>  
> 
>  
>  [PcdsFixedAtBuild.common]
> -  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"XEN-UEFI"
>gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)"
>  
>gArmPlatformTokenSpaceGuid.PcdCoreCount|1
> 

Reviewed-by: Laszlo Ersek 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/9] ArmVirtPkg: revert "ArmVirtPkg: add QemuFwCfgToPcdDxe"

[Ard Biesheuvel]

On 31 July 2015 at 20:40, Laszlo Ersek  wrote:
> This reverts git commit d2733aa9 (SVN r18042), because it is empty now.
> The original problem:
>
>   Many universal DXE drivers in edk2 can be controlled by setting dynamic
>   PCDs. Such a PCD must be set before the consumer DXE driver is
>   dispatched.
>
> should be hereafter solved similarly to how
> OvmfPkg/Library/SmbiosVersionLib is plugged into
> MdeModulePkg/Universal/SmbiosDxe now (originally suggested by Jordan
> Justen ).
>
> Cc: Ard Biesheuvel 
> Cc: Wei Huang 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf | 42 
>  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c   | 33 ---
>  ArmVirtPkg/ArmVirtQemu.dsc  |  1 -
>  ArmVirtPkg/ArmVirtQemu.fdf  |  2 -
>  4 files changed, 78 deletions(-)
>
> diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf 
> b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
> deleted file mode 100644
> index a9983be..000
> --- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -## @file
> -#  An "early" DXE driver that parses well-known fw-cfg files into dynamic 
> PCDs
> -#  that control other (universal) DXE drivers.
> -#
> -#  Copyright (C) 2015, Red Hat, Inc.
> -#  Copyright (c) 2014, Linaro Ltd. 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  = QemuFwCfgToPcdDxe
> -  FILE_GUID  = 5bb7cc92-1a36-4833-84cf-db7f8258e48d
> -  MODULE_TYPE= DXE_DRIVER
> -  VERSION_STRING = 1.0
> -  ENTRY_POINT= ParseQemuFwCfgToPcd
> -
> -[Sources]
> -  QemuFwCfgToPcd.c
> -
> -[Packages]
> -  MdePkg/MdePkg.dec
> -  OvmfPkg/OvmfPkg.dec
> -
> -[LibraryClasses]
> -  PcdLib
> -  QemuFwCfgLib
> -  UefiDriverEntryPoint
> -
> -[Pcd]
> -
> -[Depex]
> -  TRUE
> diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c 
> b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
> deleted file mode 100644
> index 8f60e21..000
> --- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/** @file
> -*  An "early" DXE driver that parses well-known fw-cfg files into dynamic 
> PCDs
> -*  that control other (universal) DXE drivers.
> -*
> -*  Copyright (C) 2015, Red Hat, Inc.
> -*  Copyright (c) 2014, Linaro Ltd. 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.
> -*
> -**/
> -
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -
> -EFI_STATUS
> -EFIAPI
> -ParseQemuFwCfgToPcd (
> -  IN EFI_HANDLE   ImageHandle,
> -  IN EFI_SYSTEM_TABLE *SystemTable
> -  )
> -{
> -  return EFI_SUCCESS;
> -}
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 00571d4..618a158 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -316,7 +316,6 @@ [Components.common]
># Platform Driver
>#
>ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf
> -  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
>OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>OvmfPkg/VirtioNetDxe/VirtioNet.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
> index 3c0487c..f378da5 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -104,12 +104,10 @@ [FV.FvMain]
>APRIORI DXE {
>  INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>  INF ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf
> -INF ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
>}
>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>INF ArmVirtPkg/VirtFdtDxe/VirtFdtDxe.inf
> -  INF ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
>
>#
># PI DXE Drivers producing Architectural Protocols (EFI Services)
> --
> 1.8.3.1
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2

Re: [edk2] [PATCH 8/9] ArmVirtPkg: set default for PcdSmbiosDocRev

[Ard Biesheuvel]

On 31 July 2015 at 20:41, Laszlo Ersek  wrote:
> When MdeModulePkg/Universal/SmbiosDxe is instructed to compose & install
> an SMBIOS 3.0 entry point, it keys the Docrev (specification document
> revision) field of that structure off of PcdSmbiosDocRev. An upcoming
> OvmfPkg patch will have OvmfPkg/Library/SmbiosVersionLib set this PCD
> dynamically. Because we use that driver in the ArmVirtQemu.dsc platform,
> we must provide a default for the dynamic PCD.
>
> Cc: Ard Biesheuvel 
> Cc: Wei Huang 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/ArmVirtQemu.dsc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 8c842c7..ab94cbc 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -237,6 +237,7 @@ [PcdsDynamicDefault.common]
># SMBIOS entry point version
>#
>gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
>gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
>
>  
> 
> --
> 1.8.3.1
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 6/9] ArmVirtPkg/ArmVirtQemu.dsc: set default for PcdQemuSmbiosValidated

[Ard Biesheuvel]

On 31 July 2015 at 20:40, Laszlo Ersek  wrote:
> The upcoming OvmfPkg patches will implicitly affect the ArmVirtQemu.dsc
> build, necessitating a default value for the new dynamic
> PcdQemuSmbiosValidated. Add it.
>
> Cc: Ard Biesheuvel 
> Cc: Wei Huang 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 


> ---
>  ArmVirtPkg/ArmVirtQemu.dsc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 618a158..8c842c7 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -237,6 +237,7 @@ [PcdsDynamicDefault.common]
># SMBIOS entry point version
>#
>gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0300
> +  gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
>
>  
> 
>  #
> --
> 1.8.3.1
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/9] ArmVirtPkg: set SMBIOS version in DetectSmbiosVersionLib instead of QemuFwCfgToPcdDxe

[Ard Biesheuvel]

On 31 July 2015 at 20:40, Laszlo Ersek  wrote:
> This patch de-duplicates the logic added in commit
>
>   ArmVirtPkg: QemuFwCfgToPcdDxe: set SMBIOS entry point version
>   dynamically
>
> (git c98da334, SVN r18043) by hooking DetectSmbiosVersionLib into
> SmbiosDxe.
>
> Although said commit was supposed to work with SMBIOS 3.0 payloads from
> QEMU, in practice that never worked, because the size / signature checks
> in SmbiosVersionInitialization() would always fail, due to the SMBIOS 3.0
> entry point being structurally different. Therefore this patch doesn't
> regress ArmVirtPkg.
>
> Cc: Ard Biesheuvel 
> Cc: Wei Huang 
> Suggested-by: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 

Reviewed-by: Ard Biesheuvel 

> ---
>  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf |  4 --
>  ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c   | 40 
>  ArmVirtPkg/ArmVirtQemu.dsc  |  5 ++-
>  3 files changed, 4 insertions(+), 45 deletions(-)
>
> diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf 
> b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
> index 649cfdc..a9983be 100644
> --- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
> +++ b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.inf
> @@ -29,18 +29,14 @@ [Sources]
>
>  [Packages]
>MdePkg/MdePkg.dec
> -  MdeModulePkg/MdeModulePkg.dec
>OvmfPkg/OvmfPkg.dec
>
>  [LibraryClasses]
> -  BaseMemoryLib
> -  DebugLib
>PcdLib
>QemuFwCfgLib
>UefiDriverEntryPoint
>
>  [Pcd]
> -  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion
>
>  [Depex]
>TRUE
> diff --git a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c 
> b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
> index 814bb5c..8f60e21 100644
> --- a/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
> +++ b/ArmVirtPkg/QemuFwCfgToPcdDxe/QemuFwCfgToPcd.c
> @@ -19,48 +19,9 @@
>  #include 
>  #include 
>
> -#include 
> -
> -#include 
> -#include 
>  #include 
>  #include 
>
> -
> -/**
> -  Set the SMBIOS entry point version for the generic SmbiosDxe driver.
> -**/
> -STATIC
> -VOID
> -SmbiosVersionInitialization (
> -  VOID
> -  )
> -{
> -  FIRMWARE_CONFIG_ITEM Anchor;
> -  UINTNAnchorSize;
> -  SMBIOS_TABLE_ENTRY_POINT QemuAnchor;
> -  UINT16   SmbiosVersion;
> -
> -  if (RETURN_ERROR (QemuFwCfgFindFile ("etc/smbios/smbios-anchor", &Anchor,
> -  &AnchorSize)) ||
> -  AnchorSize != sizeof QemuAnchor) {
> -return;
> -  }
> -
> -  QemuFwCfgSelectItem (Anchor);
> -  QemuFwCfgReadBytes (AnchorSize, &QemuAnchor);
> -  if (CompareMem (QemuAnchor.AnchorString, "_SM_", 4) != 0 ||
> -  CompareMem (QemuAnchor.IntermediateAnchorString, "_DMI_", 5) != 0) {
> -return;
> -  }
> -
> -  SmbiosVersion = (UINT16)(QemuAnchor.MajorVersion << 8 |
> -   QemuAnchor.MinorVersion);
> -  DEBUG ((EFI_D_INFO, "%a: SMBIOS version from QEMU: 0x%04x\n", __FUNCTION__,
> -SmbiosVersion));
> -  PcdSet16 (PcdSmbiosVersion, SmbiosVersion);
> -}
> -
>  EFI_STATUS
>  EFIAPI
>  ParseQemuFwCfgToPcd (
> @@ -68,6 +29,5 @@ ParseQemuFwCfgToPcd (
>IN EFI_SYSTEM_TABLE *SystemTable
>)
>  {
> -  SmbiosVersionInitialization ();
>return EFI_SUCCESS;
>  }
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 0b69134..00571d4 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -349,7 +349,10 @@ [Components.common]
>#
># SMBIOS Support
>#
> -  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> +  MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
> +
> +  NULL|OvmfPkg/Library/SmbiosVersionLib/DetectSmbiosVersionLib.inf
> +  }
>OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>
>#
> --
> 1.8.3.1
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 3/3] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

[Ard Biesheuvel]

The ARM build still needs an intermediate loader to boot Linux,
since ARM/Linux has no builtin UEFI boot stub (yet).

So add the LinuxLoader UEFI application to the FV, and enable
the FvSimpleFileSystemDxe driver so that we can invoke the
Linux loader from the shell, e.g.,

  Shell> linuxloader fs2:zImage -c console=ttyAMA0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
 ArmVirtPkg/ArmVirtQemu.dsc | 9 +
 ArmVirtPkg/ArmVirtQemu.fdf | 5 +
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index ced45c8194bc..7bba6eba05a8 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
@@ -396,9 +399,6 @@ [Components.common]
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 5a644090be7c..61e95517259c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -354,3 +354,12 @@ [Components.common]
   MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
   MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+
+[Components.ARM]
+  #
+  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still need
+  # an intermediate OS loader. Add the LinuxLoader UEFI application so we can
+  # invoke it from the shell.
+  #
+  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index a9ad9ca6fe2d..6faf3bc12172 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -237,6 +237,11 @@ [FV.FvMain]
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
 
+!if $(ARCH) == ARM
+  INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+!endif
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/3] ArmVirtPkg: drop support for the ARM BDS

[Ard Biesheuvel]

This series is a followup to the patches
  'ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default'
and
  'ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build'
that I sent out earlier today. (The former was itself a replacement for
'ArmVirtPkg: align ARM BDS build with LinuxLoader changes', part of which
has been brought back in patch #3 of this series)

The ARM BDS currently depends on the LinuxLoader UEFI application to be
present in an FV, and it to be loadable and executable via the protocols
installed by FvSimpleFileSystemDxe. The current ArmVirtQemu builds lack
both the UEFI application and the filesystem driver, and so these builds
have been broken ever since the LinuxLoader was split off into a separate
application.

The LinuxLoader for AARCH64 is buggy and violates the arm64 boot protocol,
and the ARM BDS violates the UEFI spec. So instead of restoring the ARM BDS
to working order, we drop it completely from the ArmVirtQemu platform.
(patch #1)

In patch #2, we remove a copy-pasted ARM BDS related PCD definition from the
Xen build that has never been used, as the Xen build is Intel BDS only.

Patch #3 adds support for the Linux loader to the ARM build of ArmVirtQemu
when running the Intel BDS. The LinuxLoader for 32-bit ARM implements the
boot protocol correctly (although some patches are pending to improve it in
some areas), and is actually required to boot a Linux kernel at all since
the ARM/Linux kernel has no UEFI stub support (yet).

Ard Biesheuvel (3):
  ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default
  ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD
  ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

 ArmVirtPkg/ArmVirt.dsc.inc | 11 ++
 ArmVirtPkg/ArmVirtQemu.dsc | 41 ++--
 ArmVirtPkg/ArmVirtQemu.fdf |  9 ++---
 ArmVirtPkg/ArmVirtXen.dsc  |  1 -
 4 files changed, 19 insertions(+), 43 deletions(-)

-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/3] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Ard Biesheuvel]

ARM BDS support in ArmVirtQemu has been broken since SVN r17969
("ArmPkg/BdsLib: Remove Linux loader from BdsLib") dated July 14th.

Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
altogether: they violate both the UEFI spec and the arm64 Linux boot
protocol, and lack the level of integration with the QEMU command
line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirt.dsc.inc |  5 +--
 ArmVirtPkg/ArmVirtQemu.dsc | 32 ++--
 ArmVirtPkg/ArmVirtQemu.fdf |  6 
 3 files changed, 3 insertions(+), 40 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 8c54242b597b..ced45c8194bc 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -106,8 +106,7 @@ [LibraryClasses.common]
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
 
-  # BDS Libraries
-  BdsLib|ArmPkg/Library/BdsLib/BdsLib.inf
+  # Flattened Device Tree (FDT) access library
   FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
 
   # PCI Libraries
@@ -279,8 +278,6 @@ [PcdsFeatureFlag.common]
   gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
 
 [PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
-
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index c199cac72cfd..5a644090be7c 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,13 +57,11 @@ [LibraryClasses.common]
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 
-!if $(INTEL_BDS) == TRUE
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
   PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
-!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
@@ -99,8 +97,6 @@ [PcdsFeatureFlag.common]
   gArmVirtTokenSpaceGuid.PcdKludgeMapPciMmioAsCached|TRUE
 
 [PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"QEMU"
-
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
 !if $(ARCH) == AARCH64
   gArmTokenSpaceGuid.PcdVFPEnabled|1
@@ -127,29 +123,11 @@ [PcdsFixedAtBuild.common]
   ## PL011 - Serial Terminal
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
 
-  #
-  # ARM OS Loader
-  #
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
virtio31:hd0:part0"
-  
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
console=ttyAMA0 earlycon uefi_debug"
-
-  #
-  # Settings for ARM BDS -- use the serial console (ConIn & ConOut).
-  #
-!if $(TTY_TERMINAL) == TRUE
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
-  ## Terminal Type - TTYTERM, consistent with ConOut/ConIn Device Path.
+  ## Default Terminal Type
   ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
+!if $(TTY_TERMINAL) == TRUE
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
 !else
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
-  
gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenVt100()"
-  ## Terminal Type - VT100, consistent with ConOut/ConIn Device Path.
-  ## When Intel BDS is enabled, the above ConOut/ConIn device path is useless,
-  ## but we still use VT100 terminal type when TTY_TERMINAL is not TRUE.
-  ## 0-PCANSI, 1-VT100, 2-VT00+, 3-UTF8, 4-TTYTERM
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
 !endif
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|3
@@ -175,10 +153,8 @@ [PcdsFixedAtBuild.common]
   # initial location of the device tree blob passed by QEMU -- base of DRAM
   gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
 
-!if $(INTEL_BDS) == TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformation

[edk2] [PATCH 2/3] ArmVirtPkg/ArmVirtXen: remove unused PcdFirmwareVendor PCD

[Ard Biesheuvel]

The PcdFirmwareVendor PCD was never used on this platform, since
it has never supported the ARM BDS. So remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirtXen.dsc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index b4007ff3c6a4..06c0003ae893 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -79,7 +79,6 @@ [BuildOptions]
 

 
 [PcdsFixedAtBuild.common]
-  gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"XEN-UEFI"
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"$(FIRMWARE_VER)"
 
   gArmPlatformTokenSpaceGuid.PcdCoreCount|1
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Ard Biesheuvel]

On 4 August 2015 at 16:50, Laszlo Ersek  wrote:
> On 08/04/15 16:34, Ard Biesheuvel wrote:
>> On 4 August 2015 at 15:35, Laszlo Ersek  wrote:
[...]
>>> I propose the following:
>>> - The Xen hit should be removed as a separate patch, as it has never
>>>   been useful. (The Xen build uses Intel BDS exclusively.)
>>
>> OK
>>
>>> - The rest of the PCDs (in ArmVirtQemu.dsc and in ArmVirt.dsc.inc)
>>>   should be removed as part of this patch. In practice, those are:
>>>   - PcdFirmwareVendor (both files)
>>>   - PcdDefaultConOutPaths (two instances)
>>>   - PcdDefaultConInPaths (two instance)
>>>
>>> After you remove these, only
>>> gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType remains in this context,
>>> so please refresh both the leading comment, and the
>>> TTY_TERMINAL-dependent comments just below it. (They make references to
>>> ConOut/ConIn, and Intel BDS being optional.)
>>>
>>
>> I will remove the comment, since it suggests that ConIn/ConOut is
>> unused under the Intel BDS, but that is clearly not the case.
>
> You refer to
> - gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths
> - gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths
> as being used by
>
>   ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>
> That is correct. However, ArmVirtQemu.dsc does not resolve
> PlatformBdsLib to that instance; it uses
>
>   ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>
> instead.
>
> Since your patch modifies ArmVirtQemu (where the ArmPlatformPkg library
> instance is unused), the PCDs should be removed.
>
> (The report files can be trusted about PCD usage.)
>
> The ArmPlatformPkg library instance is indeed used by ArmVirtXen, but
> the patch doesn't touch that file.
>

OK, good. I got confused by the fact that nothing under
ArmPlatformPkg/ actually uses this instance, but indeed, ArmVirtQemu
has its own.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Laszlo Ersek]

On 08/04/15 16:34, Ard Biesheuvel wrote:
> On 4 August 2015 at 15:35, Laszlo Ersek  wrote:
>> On 08/04/15 14:40, Ard Biesheuvel wrote:
>>> ARM BDS support in ArmVirtQemu has been broken since SVN r17969
>>> ("ArmPkg/BdsLib: Remove Linux loader from BdsLib") dated July 14th.
>>>
>>> Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
>>> altogether: they violate both the UEFI spec and the arm64 Linux boot
>>> protocol, and lack the level of integration with the QEMU command
>>> line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>> Note that this supersedes 'ArmVirtPkg: align ARM BDS build with LinuxLoader
>>> changes' that I sent out earlier today. After having discussed the matter on
>>> IRC (#linaro-enterprise) with leiflindholm and lersek, it turns out we all
>>> agree that the best course of action is to drop the ARM BDS entirely.
>>>
>>>  ArmVirtPkg/ArmVirtQemu.dsc | 17 +
>>>  ArmVirtPkg/ArmVirtQemu.fdf |  6 --
>>>  2 files changed, 1 insertion(+), 22 deletions(-)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> index c199cac72cfd..528d13e6aece 100644
>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> @@ -57,13 +57,11 @@ [LibraryClasses.common]
>>>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>>>
>>> NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>>
>>> -!if $(INTEL_BDS) == TRUE
>>>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>>>
>>> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
>>>
>>> PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>>>
>>> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>>>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>>> -!endif
>>>
>>>  [LibraryClasses.common.UEFI_DRIVER]
>>>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>>> @@ -128,14 +126,7 @@ [PcdsFixedAtBuild.common]
>>>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
>>>
>>>#
>>> -  # ARM OS Loader
>>> -  #
>>> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) 
>>> on virtio31:hd0:part0"
>>> -  
>>> gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
>>> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
>>> console=ttyAMA0 earlycon uefi_debug"
>>> -
>>> -  #
>>> -  # Settings for ARM BDS -- use the serial console (ConIn & ConOut).
>>> +  # Settings for BDS -- use the serial console (ConIn & ConOut).
>>>#
>>>  !if $(TTY_TERMINAL) == TRUE
>>>
>>> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
>>
>> The patch is good, but incomplete. You should remove more PCDs.
>>
>> I built ArmVirtQemu.dsc with and without INTEL_BDS. I instructed the
>> build utility to write a report file for both builds, and then diffed
>> the report files (the section entitled "Platform Configuration Database
>> Report"). Clearly the token space that we care about now is
>> gArmPlatformTokenSpaceGuid and gArmTokenSpaceGuid.
>>
>> The build report classifies the PCD settings that are not just plainly
>> inherited from whichever .dec file:
>>
>> *P - Platform scoped PCD override in DSC file
>> *F - Platform scoped PCD override in FDF file
>> *M - Module scoped PCD override
>>
>> So we are looking for differences where a *P, *F, or *M disappears, from
>> under the above two token spaces. (Disappearances of PCDs that we just
>> used to inherit need no action.)
>>
>> ... Except when the explicit setting we have under ArmVirtPkg matches
>> the default value from the .dec, because then *P is not added. So we do
>> have to look at *all* differences in these two token spaces, and
>> cross-ref them individually against our files.
>>
>> For gArmPlatformTokenSpaceGuid, this means:
>> - PcdBdsLinuxSupport
>> - PcdFirmwareVendor
>> - PcdDefaultBootDescription
>> - PcdDefaultBootDevicePath
>> - PcdDefaultBootArgument
> 
> Agreed.
> 
>> - PcdDefaultConInPaths
>> - PcdDefaultConOutPaths
>>
> 
> These are referred to by
> ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c
> 
>> For gArmTokenSpaceGuid:
>> - PcdMaxTftpFileSize
>>
> 
> Agreed.
> 
>> Matches:
>>
>> ArmVirtPkg/ArmVirt.dsc.inc:282: 
>> gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
>> ArmVirtPkg/ArmVirtQemu.dsc:102: 
>> gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"QEMU"
>> ArmVirtPkg/ArmVirtQemu.dsc:133: 
>> gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
>> virtio31:hd0:part0"
>> ArmVirtPkg/ArmVirtQemu.dsc:134: 
>> gArm

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Ard Biesheuvel]

On 4 August 2015 at 15:35, Laszlo Ersek  wrote:
> On 08/04/15 14:40, Ard Biesheuvel wrote:
>> ARM BDS support in ArmVirtQemu has been broken since SVN r17969
>> ("ArmPkg/BdsLib: Remove Linux loader from BdsLib") dated July 14th.
>>
>> Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
>> altogether: they violate both the UEFI spec and the arm64 Linux boot
>> protocol, and lack the level of integration with the QEMU command
>> line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>> Note that this supersedes 'ArmVirtPkg: align ARM BDS build with LinuxLoader
>> changes' that I sent out earlier today. After having discussed the matter on
>> IRC (#linaro-enterprise) with leiflindholm and lersek, it turns out we all
>> agree that the best course of action is to drop the ARM BDS entirely.
>>
>>  ArmVirtPkg/ArmVirtQemu.dsc | 17 +
>>  ArmVirtPkg/ArmVirtQemu.fdf |  6 --
>>  2 files changed, 1 insertion(+), 22 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index c199cac72cfd..528d13e6aece 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -57,13 +57,11 @@ [LibraryClasses.common]
>>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>>
>> -!if $(INTEL_BDS) == TRUE
>>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>>
>> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
>>
>> PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>>
>> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>> -!endif
>>
>>  [LibraryClasses.common.UEFI_DRIVER]
>>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
>> @@ -128,14 +126,7 @@ [PcdsFixedAtBuild.common]
>>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
>>
>>#
>> -  # ARM OS Loader
>> -  #
>> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) 
>> on virtio31:hd0:part0"
>> -  
>> gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
>> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
>> console=ttyAMA0 earlycon uefi_debug"
>> -
>> -  #
>> -  # Settings for ARM BDS -- use the serial console (ConIn & ConOut).
>> +  # Settings for BDS -- use the serial console (ConIn & ConOut).
>>#
>>  !if $(TTY_TERMINAL) == TRUE
>>
>> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
>
> The patch is good, but incomplete. You should remove more PCDs.
>
> I built ArmVirtQemu.dsc with and without INTEL_BDS. I instructed the
> build utility to write a report file for both builds, and then diffed
> the report files (the section entitled "Platform Configuration Database
> Report"). Clearly the token space that we care about now is
> gArmPlatformTokenSpaceGuid and gArmTokenSpaceGuid.
>
> The build report classifies the PCD settings that are not just plainly
> inherited from whichever .dec file:
>
> *P - Platform scoped PCD override in DSC file
> *F - Platform scoped PCD override in FDF file
> *M - Module scoped PCD override
>
> So we are looking for differences where a *P, *F, or *M disappears, from
> under the above two token spaces. (Disappearances of PCDs that we just
> used to inherit need no action.)
>
> ... Except when the explicit setting we have under ArmVirtPkg matches
> the default value from the .dec, because then *P is not added. So we do
> have to look at *all* differences in these two token spaces, and
> cross-ref them individually against our files.
>
> For gArmPlatformTokenSpaceGuid, this means:
> - PcdBdsLinuxSupport
> - PcdFirmwareVendor
> - PcdDefaultBootDescription
> - PcdDefaultBootDevicePath
> - PcdDefaultBootArgument

Agreed.

> - PcdDefaultConInPaths
> - PcdDefaultConOutPaths
>

These are referred to by
ArmPlatformPkg/Library/PlatformIntelBdsLib/IntelBdsPlatform.c

> For gArmTokenSpaceGuid:
> - PcdMaxTftpFileSize
>

Agreed.

> Matches:
>
> ArmVirtPkg/ArmVirt.dsc.inc:282: 
> gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
> ArmVirtPkg/ArmVirtQemu.dsc:102: 
> gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"QEMU"
> ArmVirtPkg/ArmVirtQemu.dsc:133: 
> gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
> virtio31:hd0:part0"
> ArmVirtPkg/ArmVirtQemu.dsc:134: 
> gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
> ArmVirtPkg/ArmVirtQemu.d

Re: [edk2] [PATCH] Check arguments for PrintLib format format string

[Laszlo Ersek]

On 08/04/15 03:19, Scott Duplichan wrote:
> Andrew Fish [mailto:af...@apple.com] wrote:
> 
> ]Sent: Monday, August 03, 2015 04:48 PM
> ]To: Scott Duplichan 
> ]Cc: edk2-devel@lists.01.org ; Laszlo Ersek 
> 
> ]Subject: Re: [edk2] [PATCH] Check arguments for PrintLib format format string
> ]
> ]
> ]> On Aug 2, 2015, at 9:58 PM, Scott Duplichan  wrote:
> ]> 
> ]> Add support for checking the argument list of functions that use
> ]> a PrintLib style format string. This feature requires a patched
> ]> gcc tool chain that is identified by the presence of compiler
> ]> predefined macro __GCC_EDK2_FORMATS__. To enable format string
> ]> checking, use a patched gcc tool chain and define the macro
> ]> EDK2_FORMAT_CHECKING. 
> ]> 
> ]
> ]Scott, 
> ]
> ]> +//
> ]> +#if defined(EDK2_FORMAT_CHECKING)
> ]
> ]Is this an external flag? Why not just use __GCC_EDK2_FORMATS__, if that is 
> what the compiler adds?
> ]This feature could get added to other compilers in the future...
> 
> Good points. Yes, I am setting EDK2_FORMAT_CHECKING externally. Here is how I 
> run a
> batch mode build test:
> 
> D:\edk2build> set GCC_EXTRA_CC_FLAGS=-DEDK2_FORMAT_CHECKING -Wno-error
> D:\edk2build> buildall-gcc49.bat
> 
> The first command sets an environment variable who's contents are appended
> to the GCC CC flags. This relies on a recently submitted (and rejected)
> patch: "BaseTools: Add mechanism to override or add CC_FLAGS"
> 
> I actually modified that patch slightly because it assumed the presence
> of the recently submitted but not approved GCC Link Time Optimization
> patch. The revised patch is "gcc_extra_cc_flags_08-02-2015.patch" from:
> http://sourceforge.net/projects/edk2developertoolsforwindows/files/Patches/Tool%20Chain%20Support/gcc/
> 
> To answer your question "Why not just use __GCC_EDK2_FORMATS__".
> With format checking enabled, a batch EDK2 build I use to check for 
> breakage produces 1,049 unique cases of -Wformat warnings. So we need
> a way to turn the new warnings off so that a build can complete without
> suppressing the 'warning as error' policy. The patch is using the
> compiler macro EDK2_FORMAT_CHECKING. But there is a way to
> enable/disable format checking that does use a flag: Use two separate
> GCC49 tool chains. One standard, and one with the EDK2 format checking
> patch applied. These libraryless gcc tool chains are quite small and
> keeping more of them is not unreasonable.
> 
> 
> ]> +  #if !defined(__GCC_EDK2_FORMATS__)
> ]> +#error "EDK2_FORMAT_CHECKING is not supported by this tool chain"
> ]> +  #else
> ]> +#define EFIFORMAT(FormatType, FormatPosition) \
> ]> +__attribute__((format (FormatType, FormatPosition, FormatPosition+1)))
> ]> +  #endif
> ]> +#else
> ]> +  #define EFIFORMAT(FormatType, FormatPosition)
> ]> +#endif
> ]
> ]I don’t have an issue with adding the more generic EFIFORMAT() macro, but it 
> would be more general to ]hide the 1st argument to __attribtue__ ((format, 
> …)) as that is implementation specific. 
> ]So maybe:
> ]#define EFI_PRINT_FORMAT(FormatPossition) EFIFORMAT(edk2_printf, 
> FormatPossition)
> 
> That is actually what I wanted to do. But then I encountered the %N, %H, %E,
> %B, %V extensions of function ShellPrintEx. My first idea for accommodating
> the Shell Extensions was to use an optional macro argument for this single 
> case.
> But that requires complex macro logic. The next solution I considered was a 
> pair
> of macros: one for EDK2 standard formats and one for EDK2 formats with Shell 
> Print
> Extensions. Though that is probably the best answer, I couldn't think of a 
> good
> pair of macro names. Maybe EFIFORMAT/EFIFORMAT_SHELL would be OK. If you can
> suggest a pair of names, I could resubmit the patch using them.
> 
> ]So if this every gets added to clang, or VC++ (via SAL Annotations?) it does 
> not blow up if the ]edk2_printf name is not used. 
> 
> Yes. So all we need is a way to handle the special case of function 
> ShellPrintEx
> and then the only macro argument needed is a single one that identifies which
> function argument passes the format string.
> 
> The one remaining issue is how to temporarily suppress the 'warning as error'
> policy. With 1,049 unique cases to fix, the need for suppressing 'warning as
> error' is apparent. Without doing so, you can see only one error at a time and
> that error must be fixed before the next can be seen. I fear that if there is
> no simple way to make a format checking enabled build run to completion, then
> no one will actually try or use this patch.

I agree. Last time you posted the OvmfPkg format warnings, I relied on
them having been provided in a "batch" format.

> The single line change of patch
> "gcc_extra_cc_flags_08-02-2015.patch" is the only reasonable solution I 
> know of. But this patch was rejected.

(For context, that patch hooks $(GCC_EXTRA_CC_FLAGS) into the gcc
command line.)

Regarding the 1049 new warnings: I'm surprised it contains an OvmfPkg
entry -- last time 

Re: [edk2] [PATCH] Check arguments for PrintLib format format string

[Laszlo Ersek]

On 08/03/15 06:58, Scott Duplichan wrote:

>  OvmfPkg/Include/Protocol/XenBus.h  |  2 +-
>  OvmfPkg/XenBusDxe/XenStore.h   |  2 ++

> diff --git a/OvmfPkg/Include/Protocol/XenBus.h 
> b/OvmfPkg/Include/Protocol/XenBus.h
> index 3509691..c86b812 100644
> --- a/OvmfPkg/Include/Protocol/XenBus.h
> +++ b/OvmfPkg/Include/Protocol/XenBus.h
> @@ -132,7 +132,7 @@ XENSTORE_STATUS
>  **/
>  typedef
>  XENSTORE_STATUS
> -(EFIAPI *XENBUS_XS_PRINTF) (
> +(EFIAPI EFIFORMAT (edk2_printf, 5) *XENBUS_XS_PRINTF) (
>IN XENBUS_PROTOCOL*This,
>IN CONST XENSTORE_TRANSACTION *Transaction,
>IN CONST CHAR8*Directory,
> diff --git a/OvmfPkg/XenBusDxe/XenStore.h b/OvmfPkg/XenBusDxe/XenStore.h
> index de56901..1fc0202 100644
> --- a/OvmfPkg/XenBusDxe/XenStore.h
> +++ b/OvmfPkg/XenBusDxe/XenStore.h
> @@ -188,6 +188,7 @@ XenStoreTransactionEnd (
>  **/
>  XENSTORE_STATUS
>  EFIAPI
> +EFIFORMAT (edk2_printf, 4)
>  XenStoreSPrint (
>IN CONST XENSTORE_TRANSACTION *Transaction,
>IN CONST CHAR8*DirectoryPath,
> @@ -344,6 +345,7 @@ XenBusXenStoreTransactionEnd (
>  
>  XENSTORE_STATUS
>  EFIAPI
> +EFIFORMAT (edk2_printf, 5)
>  XenBusXenStoreSPrint (
>IN XENBUS_PROTOCOL*This,
>IN CONST XENSTORE_TRANSACTION *Transaction,

These hunks (the OvmfPkg hunks) look good to me. I understand that your
patch is (apparently) work in progress. When you post the next version,
please try to separate out these OvmfPkg changes, and please add

Reviewed-by: Laszlo Ersek 

so that I'll know that I had already looked at them.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

[Laszlo Ersek]

On 08/04/15 15:41, Laszlo Ersek wrote:

> Looks good. But, since you are going to submit a new version of the
> other patch, can you post a two-part series instead, with that patch and
> this patch?

Sorry, that's three patches (the Xen change is separate).

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

[Laszlo Ersek]

On 08/04/15 15:22, Ard Biesheuvel wrote:
> The ARM build still needs an intermediate loader to boot Linux,
> since ARM/Linux has no builtin UEFI boot stub (yet).
> 
> So add the LinuxLoader UEFI application to the FV, and enable
> the FvSimpleFileSystemDxe driver so that we can invoke the
> Linux loader from the shell, e.g.,
> 
>   Shell> linuxloader fs2:zImage -c console=ttyAMA0
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
>  ArmVirtPkg/ArmVirtQemu.dsc | 9 +
>  ArmVirtPkg/ArmVirtQemu.fdf | 5 +
>  3 files changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 8c54242b597b..b1b0d049bc71 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -207,6 +207,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>
> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
> @@ -399,9 +402,6 @@ [Components.common]
>
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>  
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 528d13e6aece..c020253587d0 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -367,3 +367,12 @@ [Components.common]
>MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
> +
> +[Components.ARM]
> +  #
> +  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still 
> need
> +  # an intermediate OS loader. Add the LinuxLoader UEFI application so we can
> +  # invoke it from the shell.
> +  #
> +  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
> index a9ad9ca6fe2d..6faf3bc12172 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -237,6 +237,11 @@ [FV.FvMain]
>  SECTION RAW = MdeModulePkg/Logo/Logo.bmp
>}
>  
> +!if $(ARCH) == ARM
> +  INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> +  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> +!endif
> +
>  [FV.FVMAIN_COMPACT]
>  FvAlignment= 16
>  ERASE_POLARITY = 1
> 

Looks good. But, since you are going to submit a new version of the
other patch, can you post a two-part series instead, with that patch and
this patch?

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Laszlo Ersek]

On 08/04/15 14:40, Ard Biesheuvel wrote:
> ARM BDS support in ArmVirtQemu has been broken since SVN r17969
> ("ArmPkg/BdsLib: Remove Linux loader from BdsLib") dated July 14th.
>
> Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
> altogether: they violate both the UEFI spec and the arm64 Linux boot
> protocol, and lack the level of integration with the QEMU command
> line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
> Note that this supersedes 'ArmVirtPkg: align ARM BDS build with LinuxLoader
> changes' that I sent out earlier today. After having discussed the matter on
> IRC (#linaro-enterprise) with leiflindholm and lersek, it turns out we all
> agree that the best course of action is to drop the ARM BDS entirely.
>
>  ArmVirtPkg/ArmVirtQemu.dsc | 17 +
>  ArmVirtPkg/ArmVirtQemu.fdf |  6 --
>  2 files changed, 1 insertion(+), 22 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index c199cac72cfd..528d13e6aece 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -57,13 +57,11 @@ [LibraryClasses.common]
>TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
>
> -!if $(INTEL_BDS) == TRUE
>CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
>
> GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
>
> PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> -!endif
>
>  [LibraryClasses.common.UEFI_DRIVER]
>UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> @@ -128,14 +126,7 @@ [PcdsFixedAtBuild.common]
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
>
>#
> -  # ARM OS Loader
> -  #
> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
> virtio31:hd0:part0"
> -  
> gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
> -  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
> console=ttyAMA0 earlycon uefi_debug"
> -
> -  #
> -  # Settings for ARM BDS -- use the serial console (ConIn & ConOut).
> +  # Settings for BDS -- use the serial console (ConIn & ConOut).
>#
>  !if $(TTY_TERMINAL) == TRUE
>
> gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"

The patch is good, but incomplete. You should remove more PCDs.

I built ArmVirtQemu.dsc with and without INTEL_BDS. I instructed the
build utility to write a report file for both builds, and then diffed
the report files (the section entitled "Platform Configuration Database
Report"). Clearly the token space that we care about now is
gArmPlatformTokenSpaceGuid and gArmTokenSpaceGuid.

The build report classifies the PCD settings that are not just plainly
inherited from whichever .dec file:

*P - Platform scoped PCD override in DSC file
*F - Platform scoped PCD override in FDF file
*M - Module scoped PCD override

So we are looking for differences where a *P, *F, or *M disappears, from
under the above two token spaces. (Disappearances of PCDs that we just
used to inherit need no action.)

... Except when the explicit setting we have under ArmVirtPkg matches
the default value from the .dec, because then *P is not added. So we do
have to look at *all* differences in these two token spaces, and
cross-ref them individually against our files.

For gArmPlatformTokenSpaceGuid, this means:
- PcdBdsLinuxSupport
- PcdFirmwareVendor
- PcdDefaultBootDescription
- PcdDefaultBootDevicePath
- PcdDefaultBootArgument
- PcdDefaultConInPaths
- PcdDefaultConOutPaths

For gArmTokenSpaceGuid:
- PcdMaxTftpFileSize

Matches:

ArmVirtPkg/ArmVirt.dsc.inc:282: 
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
ArmVirtPkg/ArmVirtQemu.dsc:102: 
gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"QEMU"
ArmVirtPkg/ArmVirtQemu.dsc:133: 
gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
virtio31:hd0:part0"
ArmVirtPkg/ArmVirtQemu.dsc:134: 
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
ArmVirtPkg/ArmVirtQemu.dsc:135: 
gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
console=ttyAMA0 earlycon uefi_debug"
ArmVirtPkg/ArmVirtQemu.dsc:141: 
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
Arm

[edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: add LinuxLoader UEFI app to ARM build

[Ard Biesheuvel]

The ARM build still needs an intermediate loader to boot Linux,
since ARM/Linux has no builtin UEFI boot stub (yet).

So add the LinuxLoader UEFI application to the FV, and enable
the FvSimpleFileSystemDxe driver so that we can invoke the
Linux loader from the shell, e.g.,

  Shell> linuxloader fs2:zImage -c console=ttyAMA0

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
 ArmVirtPkg/ArmVirtQemu.dsc | 9 +
 ArmVirtPkg/ArmVirtQemu.fdf | 5 +
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 8c54242b597b..b1b0d049bc71 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -207,6 +207,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
@@ -399,9 +402,6 @@ [Components.common]
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 528d13e6aece..c020253587d0 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -367,3 +367,12 @@ [Components.common]
   MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
   MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+
+[Components.ARM]
+  #
+  # The ARM/Linux kernel has no built in EFI boot stub (yet), so we still need
+  # an intermediate OS loader. Add the LinuxLoader UEFI application so we can
+  # invoke it from the shell.
+  #
+  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index a9ad9ca6fe2d..6faf3bc12172 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -237,6 +237,11 @@ [FV.FvMain]
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
 
+!if $(ARCH) == ARM
+  INF MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
+  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+!endif
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmVirtPkg/ArmVirtQemu: drop ARM BDS and make Intel BDS the default

[Ard Biesheuvel]

ARM BDS support in ArmVirtQemu has been broken since SVN r17969
("ArmPkg/BdsLib: Remove Linux loader from BdsLib") dated July 14th.

Instead of fixing this, let's get rid of the ARM BDS and LinuxLoader
altogether: they violate both the UEFI spec and the arm64 Linux boot
protocol, and lack the level of integration with the QEMU command
line that the Intel BDS has when running under ArmVirtPkg or OvmfPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
Note that this supersedes 'ArmVirtPkg: align ARM BDS build with LinuxLoader
changes' that I sent out earlier today. After having discussed the matter on
IRC (#linaro-enterprise) with leiflindholm and lersek, it turns out we all
agree that the best course of action is to drop the ARM BDS entirely.

 ArmVirtPkg/ArmVirtQemu.dsc | 17 +
 ArmVirtPkg/ArmVirtQemu.fdf |  6 --
 2 files changed, 1 insertion(+), 22 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index c199cac72cfd..528d13e6aece 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -57,13 +57,11 @@ [LibraryClasses.common]
   TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
   NorFlashPlatformLib|ArmVirtPkg/Library/NorFlashQemuLib/NorFlashQemuLib.inf
 
-!if $(INTEL_BDS) == TRUE
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
   PlatformBdsLib|ArmVirtPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
-!endif
 
 [LibraryClasses.common.UEFI_DRIVER]
   UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
@@ -128,14 +126,7 @@ [PcdsFixedAtBuild.common]
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|38400
 
   #
-  # ARM OS Loader
-  #
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootDescription|L"Linux (EFI stub) on 
virtio31:hd0:part0"
-  
gArmPlatformTokenSpaceGuid.PcdDefaultBootDevicePath|L"VenHw(837DCA9E-E874-4D82-B29A-23FE0E23D1E2,003E000A)/HD(1,MBR,0x,0x3F,0x19FC0)/Image"
-  gArmPlatformTokenSpaceGuid.PcdDefaultBootArgument|"root=/dev/vda2 
console=ttyAMA0 earlycon uefi_debug"
-
-  #
-  # Settings for ARM BDS -- use the serial console (ConIn & ConOut).
+  # Settings for BDS -- use the serial console (ConIn & ConOut).
   #
 !if $(TTY_TERMINAL) == TRUE
   
gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(38400,8,N,1)/VenMsg(7D916D80-5BB1-458C-A48F-E25FDD51EF94)"
@@ -175,10 +166,8 @@ [PcdsFixedAtBuild.common]
   # initial location of the device tree blob passed by QEMU -- base of DRAM
   gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress|0x4000
 
-!if $(INTEL_BDS) == TRUE
   gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-!endif
 
   #
   # The maximum physical I/O addressability of the processor, set with
@@ -332,13 +321,9 @@ [Components.common]
   # Bds
   #
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-!if $(INTEL_BDS) == TRUE
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
-!else
-  ArmPlatformPkg/Bds/Bds.inf
-!endif
 
   #
   # SCSI Bus and Disk Driver
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 3c0487cd95b6..a9ad9ca6fe2d 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -171,13 +171,9 @@ [FV.FvMain]
   # Bds
   #
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
-!if $(INTEL_BDS) == TRUE
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
   INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
-!else
-  INF ArmPlatformPkg/Bds/Bds.inf
-!endif
 
   #
   # Networking stack
@@ -234,14 +230,12 @@ [FV.FvMain]
   INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
 
-!if $(INTEL_BDS) == TRUE
   #
   # TianoCore logo (splash screen)
   #
   FILE FREEFORM = PCD(gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
 SECTION RAW = MdeModulePkg/Logo/Logo.bmp
   }
-!endif
 
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] BaseTools features: multiple workspaces

[Laszlo Ersek]

On 08/03/15 19:35, Jordan Justen wrote:
> On 2015-08-03 02:08:14, Gao, Liming wrote:
>> Paolo:
>>   I think that keep the exiting syntax for WORKSPACE to be a single
>>   path can minimize the impacts to exiting tools that assume a
>>   single workspace.
> 
> I know you originally suggested to use WORKSPACE, but got some
> feedback that it might be better to create a new variable to not break
> some unspecified tools.
> 
> Was anyone able to name an actual tool that would be impacted? Why not
> work to update these tools at the same time? An easy 'fix' will be for
> any such tool to give an error message if it sees ':' or ';' in the
> WORKSPACE environment variable. Although this is really not a fix, it
> will be just as much support as if they ignore the new
> WORKSPACE_MULTIPLE environment variable.
> 
> I think that using the single separated WORKSPACE environment variable
> is more intuitive/expected. From using env vars such as PATH, we all
> know what it means.
> 
> For WORKSPACE+WORKSPACE_MULTIPLE, I don't know which has priority. I
> assume WORKSPACE is checked first, and then WORKSPACE_MULTIPLE?

This was described in Liming's email, in point 4b.

> 
> Will this work for the integrated CryptoPkg + open-ssl? It seems like
> we need a priority above EDK II for this. I guess WORKSPACE will not
> be set to EDK II in this case?
> 
> Anyway, it just seems a little odd.

For me a colon-separated (well, separator-separated :)) single WORKSPACE
variable would be more intuitive, but WORKSPACE_MULTIPLE can be defined
well enough too. For example:
- WORKSPACE must not contain separators
- if WORKSPACE_MULTIPLE is set, then the effect is as if
  ${WORKSPACE}:${WORKSPACE_MULTIPLE} were specified under the
  well-known PATH semantics.

No clue about the CryptoPkg impact. Can you remind me please why
CryptoPkg / OpensslLib are special wrt. WORKSPACE?

Thanks
Laszlo

> 
> -Jordan
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo 
>> Bonzini
>> Sent: Monday, August 03, 2015 4:31 PM
>> To: Gao, Liming; edk2-devel@lists.01.org
>> Subject: Re: [edk2] BaseTools features: multiple workspaces
>>
>>
>> On 03/08/2015 05:56, Gao, Liming wrote:
>>> Hi, all
>>>   We will update BaseTools feature to allow more than one workspaces. The 
>>> detail design in the below. Please help review it. If you have any 
>>> comments, please let me know.
>>>
>>> 1.   Keep $(WORKSPACE) environment as is
>>>
>>> a.   $(WORKSPACE) determines location of Build and Conf directory.
>>>
>>> 2.   New optional $(WORKSPACE_MULTIPLE) environment is added to include 
>>> more directories with the separator ';', like $(PATH)
>>
>> Why is $(WORKSPACE_MULTIPLE) necessary?  On Linux it is okay to break 
>> preexisting paths that contain a ":"; on Windows semicolons are allowed in 
>> theory but in practice break in several ways.
>>
>> Paolo
>>
>>> a.   Produce the same behavior if $(WORKSPACE_MULTIPLE) is not set.
>>>
>>> 3.   Update edksetup.bat/edksetup.sh to find BaseTools directory from 
>>> $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
>>>
>>> 4.   Update BaseTools to support multiple workspaces
>>>
>>> a.   For the relative file path (INF, DSC and FDF), BaseTools will 
>>> search them from $(WORKSPACE) and $(WORKSPACE_MULTIPLE) directories.
>>>
>>> b.  Search priority from high to low: $(WORKSPACE), 
>>> $(WORKSPACE_MULTIPLE).
>>>
>>> This is a compatible feature. It has no impact on current EDKII project.
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

[David Woodhouse]

On Tue, 2015-08-04 at 13:07 +0200, Laszlo Ersek wrote:
> On 08/04/15 12:42, David Woodhouse wrote:
> > Then (if the BDS gets it right) you should be able to boot legacy
> > targets as well as native UEFI targets.
> 
> Okay, if you don't have your guests any longer, I guess I can add 
> this to the end of my queue too.

I do still have an OS zoo which I can use for CSM testing. That was
more useful for the actual CSM functionality though — catching ACPI
compatibility issues and timer breakage and other things.

It's less useful for the simple case of BDS testing, where if it
*starts* trying to boot the correct OS you probably haven't broken it
(and hell, if it offers you the *option* of a Legacy boot from a given
target you're most of the way there).

I certainly can do some more testing though.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

[Laszlo Ersek]

On 08/04/15 12:53, Laszlo Ersek wrote:

> No matter how carefully
> we review and test the new code, something will inevitably break,

This wasn't meant as lack of trust in your code; it's just that there
are many cases and corner cases in the related OVMF code, and it's quite
hard to test them all.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

[Laszlo Ersek]

On 08/04/15 12:42, David Woodhouse wrote:
> On Tue, 2015-08-04 at 03:16 +, Ni, Ruiyu wrote:
>> I forgot to emphasize that I only tested the QEMU boot timeout 
>> feature after changing the QemuBootOrderLib. I don't know how to test 
>> the boot order feature.
>> For the SeaBIOS CSM, can you tell me how to test or test it for me if 
>> it's very quick?
> 
> It's been a quite since I've done it; Laszlo probably has more up-to
> -date instructions and a prepackaged SeaBIOS .config file (perhaps in
> the RPM packages).
> 
> But basically you first build the SeaBIOS CSM image as described at
> http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29
> and then drop it into OvmfPkg/Csm/Csm16/Csm16.bin and build with -DCSM_ENABLE.
> 
> Then (if the BDS gets it right) you should be able to boot legacy
> targets as well as native UEFI targets.

Okay, if you don't have your guests any longer, I guess I can add this
to the end of my queue too.

Thanks
Laszlo

> 
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

[Laszlo Ersek]

On 08/04/15 05:16, Ni, Ruiyu wrote:
> No.
> 
> I forgot to emphasize that I only tested the QEMU boot timeout feature after 
> changing the QemuBootOrderLib. I don't know how to test the boot order 
> feature.

This series, on the surface, seems intrusive and to have potential to
cause many regressions. So, as the first step, please push the series to
a public repo, so I can fetch it -- I tried to apply it manually and it
failed -- and review it locally. In particular I'd like to review the
series with rename and copy detection enabled in git. (So that the pure
code movement is filtered out of the patches.)

The boot order stuff is very hairy and also very important to us, so
I'll have to review that carefully.

A different question -- can you please tell me more about the new BDS
and UiApp? What the motivation for it was, what it does?

Do the GenericBdsLib functions continue to work? What we have in OvmfPkg
at the moment is pretty fine-tuned to GenericBdsLib, so if the new
library is just a rough match, it might not be feasible to quickly
rebase OvmfPkg.

Also, given that ArmVirtPkg is not being modified, it appears that
GenericBdsLib is not planned (in the short/mid term at least) to be
phased out. Is that correct?

Because if it is, then I wonder if it would be more prudent to implement
these changes in OVMF with a new build time flag. Namely, I don't want
to block the testing / development of the new BDS infrastructure -- OVMF
is a nice testbed for firmware development, so it should support such
use cases. (Also, in the long term we should probably move to the new
BDS permanently, as there must have been good reasons for implementing
the new BDS in the first place.)

However, this should not regress current users. No matter how carefully
we review and test the new code, something will inevitably break, and
users should not be exposed to that at once (and we shouldn't have to
scramble for fixes retroactively, in a mortal hurry).

Optimally, edk2 should support stable and development branches &
releases (not just for UDK but for everything else, OvmfPkg included).
Since we don't have that, I think it's prudent to implement intrusive
changes in two phases, with a new build time flag. And at some point we
can flip the default, if we want to. (For example, in ArmVirtPkg we
still have -D INTEL_BDS separately.)

> For the SeaBIOS CSM, can you tell me how to test or test it for me if it's 
> very quick?

It's pretty messy. I think David used to have the best set of legacy
guests for testing CSM, so I'd ask him to help with testing it this time
too (sorry David! :)) However, that will also require this series to be
available in a public branch somewhere.

Thanks!
Laszlo

> 
> Thanks,
> Ray
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of David 
> Woodhouse
> Sent: Monday, August 3, 2015 6:31 PM
> To: Ni, Ruiyu ; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg
> 
> On Mon, 2015-08-03 at 13:41 +0800, Ruiyu Ni wrote:
>> A new BDS and UiApp was created in MdeModulePkg and are already
>> used in Nt32Pkg.
>> The patch changes the OvmfPkg to use the new BDS and UiApp as well.
> 
> Hi Ruiyu, were these changes tested with the SeaBIOS CSM?
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/3] Use new BDS and UiApp for OvmfPkg

[David Woodhouse]

On Tue, 2015-08-04 at 03:16 +, Ni, Ruiyu wrote:
> I forgot to emphasize that I only tested the QEMU boot timeout 
> feature after changing the QemuBootOrderLib. I don't know how to test 
> the boot order feature.
> For the SeaBIOS CSM, can you tell me how to test or test it for me if 
> it's very quick?

It's been a quite since I've done it; Laszlo probably has more up-to
-date instructions and a prepackaged SeaBIOS .config file (perhaps in
the RPM packages).

But basically you first build the SeaBIOS CSM image as described at
http://www.seabios.org/Build_overview#Build_as_a_UEFI_Compatibility_Support_Module_.28CSM.29
and then drop it into OvmfPkg/Csm/Csm16/Csm16.bin and build with -DCSM_ENABLE.

Then (if the BDS gets it right) you should be able to boot legacy
targets as well as native UEFI targets.

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation


smime.p7s
Description: S/MIME cryptographic signature
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] error when build ovmf

[Laszlo Ersek]

On 08/04/15 08:50, 闪耀 wrote:
> when build -a X64 -p OvmfPkg\OvmfPkgX64.dsc ,
> 
> 
> 
> 
> build...
>  : error C0DE: Unknown fatal error when processing 
> [c:\edk2-master\OvmfPkg\Platf
> ormDxe\Platform.inf]
> 
> 
> (Please send email to edk2-de...@lists.sourceforge.net for help, attaching 
> follo
> wing call stack trace!)
> 
> 
> (Python 2.7.3 on win32) Traceback (most recent call last):
>   File "build.py", line 2036, in Main
>   File "build.py", line 1792, in Launch
>   File "build.py", line 1622, in _MultiThreadBuildPlatform
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\AutoGen.py", line 3446, in CreateCodeFile
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\AutoGen.py", line 2854, in _GetAutoGenFileList
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\GenC.py", line 1552, in CreateCode
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\GenC.py", line 1456, in CreateUnicodeStringCode
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\StrGather.py", line 600, in GetStringFiles
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\UniClassObject.py", line 203, in __init__
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\UniClassObject.py", line 463, in LoadUniFiles
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\UniClassObject.py", line 377, in LoadUniFile
>   File 
> "c:\Users\Public\Documents\BuildPool\BaseTools\build\Source\Python\AutoGe
> n\UniClassObject.py", line 318, in PreProcess
>   File "C:\Python\32-bit\2.7\lib\codecs.py", line 684, in next
>   File "C:\Python\32-bit\2.7\lib\codecs.py", line 615, in next
>   File "C:\Python\32-bit\2.7\lib\codecs.py", line 530, in readline
>   File "C:\Python\32-bit\2.7\lib\codecs.py", line 477, in read
>   File "C:\Python\32-bit\2.7\lib\encodings\utf_16.py", line 112, in decode
> UnicodeError: UTF-16 stream does not start with BOM

You are probably using ancient BaseTools. The
"OvmfPkg/PlatformDxe/Platform.uni" was converted to UTF-8 in:

commit 8ad8a1fa52a8fdb0a00075f5f870235ef6e48b1b
Author: Jordan Justen 
Date:   Tue Jun 23 23:34:47 2015 +

OvmfPkg/PlatformDxe: Convert Platform.uni to UTF-8

However, that commit is the final patch in the series that adds UTF-8
support to BaseTools. So please just clean your workspace, refresh
everything (BaseTools, Conf/, etc) and rebuild.

Thanks
Laszlo


> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support

[Laszlo Ersek]

On 08/04/15 11:44, Zeng, Star wrote:
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, August 4, 2015 5:25 PM
>> To: Zeng, Star; Justen, Jordan L
>> Cc: Paolo Bonzini; edk2-de...@ml01.01.org; Yao, Jiewen
>> Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
>>
>> On 08/04/15 10:59, Zeng, Star wrote:
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Tuesday, August 4, 2015 4:34 PM
 To: Zeng, Star
 Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini
 Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX
>> support

 Star,

 On 07/31/15 14:22, Star Zeng wrote:
> This feature is added for UEFI spec that says "Stack may be marked
> as non-executable in identity mapped page tables".
> A PCD PcdSetNxForStack is added to turn on/off this feature, and it
> is FALSE by default.

> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>## The number of bytes between registers in serial device.  The
> default is
 1 byte.
># @Prompt Serial Port Register Stride in Bytes
>
>

>> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00
 01
> 006d
> -
> +
> +  ## Indicates if to set NX for stack.  #  For the DxeIpl
> + and the DxeCore are both X64, set NX for stack feature also
> + require PcdDxeIplBuildPageTables be TRUE.  #  For the DxeIpl
> + and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is
> + FALSE), set NX
 for stack feature also require  #  IA32 PAE is supported and Execute
 Disable Bit is available.
> +  #   TRUE  - to set NX for stack.
> +  #   FALSE - Not to set NX for stack.
> +  # @Prompt Set NX for stack.
> +
> +

>> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x
 0001
> + 006f
> +

 Are there any restrictions for setting this PCD statically in a platform 
 DSC
>> file?
 Could it regress anything?
>>>
>>> No. This feature require to build page table. More detailed explanation
>> below.
>>>

 In OVMF we have three DSC files:

 - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is
   FALSE. If we set PcdSetNxForStack in this DSC file, will the code
   dynamically determine if the hardware has the necessary features, and
   fall back gracefully if it doesn't?
>>>
>>> Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used
>>> to determine if the hardware has the necessary features.
>>> By default, 32BIT PEI+32BIT DXE do not need page table and
>>> PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both
>>> X64 as the comments in MdeModulePkg.dec.
>>> But this feature require page table, so (PcdGetBool (PcdSetNxForStack)
>>> && IsIa32PaeSupport () && IsExecuteDisableBitAvailable ()) is used to
>> determine if building page table or not.
>>
>> Ah, I can see that in the patch. It gates the new
>> Create4GPageTablesIa32Pae() function.
>>
>>>

 - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE,
>> PcdDxeIplSwitchToLongMode
   is TRUE. This use case doesn't seem to be described in the .dec file
   above. Is this configuration compatible with PcdSetNxForStack=TRUE?
>>>
>>> Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special
>>> comments for it in MdeModulepkg.dec and just PcdGetBool
>>> (PcdSetNxForStack) is used to enable this feature or not in page table (Nx
>> bit).
>>
>> Great.
>>
>>>

 - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is
   FALSE. We don't change PcdDxeIplBuildPageTables from the default, but
   the default in "MdeModulePkg/MdeModulePkg.dec" is TRUE, and we
   inherit that. Can we set PcdSetNxForStack to TRUE, statically?
>>>
>>> Of course YES.
>>
>> Thanks.
>>
>> The question emerges then: why doesn't PcdSetNxForStack default to true?
>>
>> I can see two possible reasons:
>>
>> - It is a new feature and causes changes in behavior. At worst, some
>> firmware could even rely on executing code from the stack. That shouldn't
>> be broken.
>>
>> - The code adds a new ASSERT(), and it could be triggered if the platform 
>> left
>> PcdDxeIplBuildPageTables at FALSE. It's not nice to introduce code with
>> potential to trigger an ASSERT() immediately, so this makes sense too.
>>
>> In OvmfPkg none of these should be an issue. I think (well, actually, Paolo
>> suggested it) that we should therefore enable the feature in OVMF.
> 
> Yes, you are right about the reasons.
> 
> BTW, in fact I made some test(write test code to load and start some
> module(for example, helloworld) to stack, 

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support

[Zeng, Star]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, August 4, 2015 5:25 PM
> To: Zeng, Star; Justen, Jordan L
> Cc: Paolo Bonzini; edk2-de...@ml01.01.org; Yao, Jiewen
> Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
> 
> On 08/04/15 10:59, Zeng, Star wrote:
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Tuesday, August 4, 2015 4:34 PM
> >> To: Zeng, Star
> >> Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini
> >> Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX
> support
> >>
> >> Star,
> >>
> >> On 07/31/15 14:22, Star Zeng wrote:
> >>> This feature is added for UEFI spec that says "Stack may be marked
> >>> as non-executable in identity mapped page tables".
> >>> A PCD PcdSetNxForStack is added to turn on/off this feature, and it
> >>> is FALSE by default.
> >>
> >>> diff --git a/MdeModulePkg/MdeModulePkg.dec
> >>> b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644
> >>> --- a/MdeModulePkg/MdeModulePkg.dec
> >>> +++ b/MdeModulePkg/MdeModulePkg.dec
> >>> @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
> >>>## The number of bytes between registers in serial device.  The
> >>> default is
> >> 1 byte.
> >>># @Prompt Serial Port Register Stride in Bytes
> >>>
> >>>
> >>
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00
> >> 01
> >>> 006d
> >>> -
> >>> +
> >>> +  ## Indicates if to set NX for stack.  #  For the DxeIpl
> >>> + and the DxeCore are both X64, set NX for stack feature also
> >>> + require PcdDxeIplBuildPageTables be TRUE.  #  For the DxeIpl
> >>> + and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is
> >>> + FALSE), set NX
> >> for stack feature also require  #  IA32 PAE is supported and Execute
> >> Disable Bit is available.
> >>> +  #   TRUE  - to set NX for stack.
> >>> +  #   FALSE - Not to set NX for stack.
> >>> +  # @Prompt Set NX for stack.
> >>> +
> >>> +
> >>
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x
> >> 0001
> >>> + 006f
> >>> +
> >>
> >> Are there any restrictions for setting this PCD statically in a platform 
> >> DSC
> file?
> >> Could it regress anything?
> >
> > No. This feature require to build page table. More detailed explanation
> below.
> >
> >>
> >> In OVMF we have three DSC files:
> >>
> >> - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is
> >>   FALSE. If we set PcdSetNxForStack in this DSC file, will the code
> >>   dynamically determine if the hardware has the necessary features, and
> >>   fall back gracefully if it doesn't?
> >
> > Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used
> > to determine if the hardware has the necessary features.
> > By default, 32BIT PEI+32BIT DXE do not need page table and
> > PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both
> > X64 as the comments in MdeModulePkg.dec.
> > But this feature require page table, so (PcdGetBool (PcdSetNxForStack)
> > && IsIa32PaeSupport () && IsExecuteDisableBitAvailable ()) is used to
> determine if building page table or not.
> 
> Ah, I can see that in the patch. It gates the new
> Create4GPageTablesIa32Pae() function.
> 
> >
> >>
> >> - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE,
> PcdDxeIplSwitchToLongMode
> >>   is TRUE. This use case doesn't seem to be described in the .dec file
> >>   above. Is this configuration compatible with PcdSetNxForStack=TRUE?
> >
> > Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special
> > comments for it in MdeModulepkg.dec and just PcdGetBool
> > (PcdSetNxForStack) is used to enable this feature or not in page table (Nx
> bit).
> 
> Great.
> 
> >
> >>
> >> - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is
> >>   FALSE. We don't change PcdDxeIplBuildPageTables from the default, but
> >>   the default in "MdeModulePkg/MdeModulePkg.dec" is TRUE, and we
> >>   inherit that. Can we set PcdSetNxForStack to TRUE, statically?
> >
> > Of course YES.
> 
> Thanks.
> 
> The question emerges then: why doesn't PcdSetNxForStack default to true?
> 
> I can see two possible reasons:
> 
> - It is a new feature and causes changes in behavior. At worst, some
> firmware could even rely on executing code from the stack. That shouldn't
> be broken.
> 
> - The code adds a new ASSERT(), and it could be triggered if the platform left
> PcdDxeIplBuildPageTables at FALSE. It's not nice to introduce code with
> potential to trigger an ASSERT() immediately, so this makes sense too.
> 
> In OvmfPkg none of these should be an issue. I think (well, actually, Paolo
> suggested it) that we should therefore enable the feature in OVMF.

Yes, you are right about the reasons.

BTW, in fact I made some test(write test code to load and start some module(for 
example, helloworld) to stack, then page fault came out with this feature 
enabled) based on qemu by Ovmf(IA32+

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Laszlo Ersek]

On 08/04/15 11:21, Sharma Bhupesh wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, August 04, 2015 2:36 PM
>> On 08/04/15 10:38, Sharma Bhupesh wrote:
 -Original Message-
 From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
 Sent: Tuesday, August 04, 2015 2:01 PM

 On 4 August 2015 at 10:07, Sharma Bhupesh
 
 wrote:
>>
> With the EFI_STUB becoming more or less mandatory and the leagacy
> ARM Bds Linux Loader being deprecated, are there any plans to
> provide means
 to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
>

 No. FIT images are a U-Boot construct. The recommended way under UEFI
 is to install the device tree as a FDT configuration table in the
>> firmware.
 Look at FdtPlatformDxe for more info. The initrd can be loaded by the
 EFI stub, by passing the initrd= option.

 The recommended way of doing authentication of bootable images is to
 use UEFI Secure Boot. DTB authentication is implicit if it is part of
 the UEFI image itself. How to do initrd authentication is undefined.
>>
>> (I'd say "unspecified" rather than "undefined", but that's a side point.)
>>
>>> initrd (Rootfs) is probably the easiest place to introduce a malicious
>>> application in, which can easily overwrite the text area, thus causing
>> the core to run a Trojan.
>>
>> How is this different from overwriting applications on a normal file
>> system? As far as I understand, applications are not part of the chain
>> being verified.
> 
> Cryptographically verifying the entire Root filesystem being provided with
> a software development kit, allows a OEM/customer to ensure that
> the platform only boots a application-set which is authenticated using
> their Public-Private key pairs.
> 
> So, if the system tries to launch a rootfs which is not authenticated 
> via the OEM/customer's public key, the boot process stalls and a preventive
> tamper-proofing action like zero'ing the DDR contents and reseting the SoC 
> can be taken.

I agree that this could be a useful configuration. But, if I understand
correctly, this appears to belong with stuff that comes "after" the
platform firmware. In the chain, each link tends to verify the next link.

So, if blob-like authentication is necessary for the initial ramdisk,
then I wonder if it should be the boot loader's (grub's, the EFI stub's,
etc) responsibility to perform that check at load time. Maybe even the
kernel (already verified) could itself authenticate the ramdisk image
before mounting it.

[Tue Aug  4 11:35:10 2015] Secure boot enabled
...
[Tue Aug  4 11:35:11 2015] Unpacking initramfs...

Thanks
Laszlo



> 
> Regards,
> Bhupesh
> 
>>
>> Kernel modules are (and they do reside in the initrd), but they should
>> already be covered by module signing.
>>
>> http://mjg59.dreamwidth.org/12368.html
>>
>> https://access.redhat.com/documentation/en-
>> US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-
>> signing-kernel-modules-for-secure-boot.html
>> https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se
>> cboot.html
>>
>> https://www.suse.com/documentation/sles-
>> 12/book_sle_admin/data/sec_uefi_secboot.html
>>
>> Thanks
>> Laszlo
>>
>>>
>>> The normal secure chain of boot, requires that each component verifies
>>> the next component it launches. FIT format seems to plug this gap.
>>>
>>> Can you point me to some documentation on UEFI secure boot and how it
>>> works on the
>>> ARM64 platforms - does it internally use and program the ARM TrustZone
>>> components like the TZASC and TZPC to partition the System RAM, etc
>>> into appropriate secure and non-secure partitions and the images
>> cryptographically verify the next stage image.
>>> A typical flow most OEMs use is:
>>>
>>> BootROM -> Arm Trusted Firmware -> UEFI -> Linux -> Initrd
>>>
>>> The current SEC stage code for ARM64 platforms supported in EDK2 seem
>>> to be programming the TZASC and TZPC entities, but I cannot see any
>>> secure chain-of-trust being established for the next stage images
>> there.
>>>
>>> Regards,
>>> Bhupesh
>>>

 Regards,
 Ard.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>> Of Ard Biesheuvel
>> Sent: Tuesday, August 04, 2015 1:27 PM
>> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
>> ler...@redhat.com
>> Cc: ryan.har...@linaro.org; Ard Biesheuvel
>> Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with
>> LinuxLoader changes
>>
>> LinuxLoader has been split off from the ARM BDS into a separate EFI
>> application. Because we never included this application into the
>> ArmVirtPkg platforms, its ARM BDS builds have effectively been
>> broken ever since that change was merged.
>>
>> Let's fix the situation by:
>> - Disabling LinuxLoader support for AARCH64 

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Ard Biesheuvel]

On 4 August 2015 at 11:21, Sharma Bhupesh  wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, August 04, 2015 2:36 PM
>> On 08/04/15 10:38, Sharma Bhupesh wrote:
>> >> -Original Message-
>> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> >> Sent: Tuesday, August 04, 2015 2:01 PM
>> >>
>> >> On 4 August 2015 at 10:07, Sharma Bhupesh
>> >> 
>> >> wrote:
>>
>> >>> With the EFI_STUB becoming more or less mandatory and the leagacy
>> >>> ARM Bds Linux Loader being deprecated, are there any plans to
>> >>> provide means
>> >> to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
>> >>>
>> >>
>> >> No. FIT images are a U-Boot construct. The recommended way under UEFI
>> >> is to install the device tree as a FDT configuration table in the
>> firmware.
>> >> Look at FdtPlatformDxe for more info. The initrd can be loaded by the
>> >> EFI stub, by passing the initrd= option.
>> >>
>> >> The recommended way of doing authentication of bootable images is to
>> >> use UEFI Secure Boot. DTB authentication is implicit if it is part of
>> >> the UEFI image itself. How to do initrd authentication is undefined.
>>
>> (I'd say "unspecified" rather than "undefined", but that's a side point.)
>>
>> > initrd (Rootfs) is probably the easiest place to introduce a malicious
>> > application in, which can easily overwrite the text area, thus causing
>> the core to run a Trojan.
>>
>> How is this different from overwriting applications on a normal file
>> system? As far as I understand, applications are not part of the chain
>> being verified.
>
> Cryptographically verifying the entire Root filesystem being provided with
> a software development kit, allows a OEM/customer to ensure that
> the platform only boots a application-set which is authenticated using
> their Public-Private key pairs.
>

Putting DTB, kernel and initrd in the same signed archive is a design
driven by convenience, not by security.

It is the firmware's responsibility to authenticate and boot the
kernel image, and provide it with a description of the hardware. The
kernel's trust of the firmware is implicit, that is why, under UEFI
Secure Boot, the only way of obtaining a DTB is from the configuration
table (the dtb= kernel command line parameter is disabled in this
case)

It is the kernel's responsibility to authenticate the file system,
regardless of whether it is a initrd or a filesystem hosted on block
storage. To the firmware, the initrd is just an opaque blob, whereas,
from the kernel pov, the initrd is a readable archive with kernel
modules and executables, each of which may have their own
authentication requirements.

> So, if the system tries to launch a rootfs which is not authenticated
> via the OEM/customer's public key, the boot process stalls and a preventive
> tamper-proofing action like zero'ing the DDR contents and reseting the SoC 
> can be taken.
>

A chain of trust implies discrete links. Signing everything with the
OEM/customer's public key and verifying all at the same time may be
appropriate in some cases, but you should not present it as the common
design. In general, it is much more convenient to allow the kernel to
be in charge of the public keys that authenticate subsequent boot
stages rather than mandating that DTB, kernel *and* initrd are all
signed with a public key known to the firmware.

-- 
Ard.



>>
>> Kernel modules are (and they do reside in the initrd), but they should
>> already be covered by module signing.
>>
>> http://mjg59.dreamwidth.org/12368.html
>>
>> https://access.redhat.com/documentation/en-
>> US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-
>> signing-kernel-modules-for-secure-boot.html
>> https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se
>> cboot.html
>>
>> https://www.suse.com/documentation/sles-
>> 12/book_sle_admin/data/sec_uefi_secboot.html
>>
>> Thanks
>> Laszlo
>>
>> >
>> > The normal secure chain of boot, requires that each component verifies
>> > the next component it launches. FIT format seems to plug this gap.
>> >
>> > Can you point me to some documentation on UEFI secure boot and how it
>> > works on the
>> > ARM64 platforms - does it internally use and program the ARM TrustZone
>> > components like the TZASC and TZPC to partition the System RAM, etc
>> > into appropriate secure and non-secure partitions and the images
>> cryptographically verify the next stage image.
>> > A typical flow most OEMs use is:
>> >
>> > BootROM -> Arm Trusted Firmware -> UEFI -> Linux -> Initrd
>> >
>> > The current SEC stage code for ARM64 platforms supported in EDK2 seem
>> > to be programming the TZASC and TZPC entities, but I cannot see any
>> > secure chain-of-trust being established for the next stage images
>> there.
>> >
>> > Regards,
>> > Bhupesh
>> >
>> >>
>> >> Regards,
>> >> Ard.
>> >>
>>  -Original Message-
>>  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Ard Biesheuvel]

On 4 August 2015 at 10:54, Laszlo Ersek  wrote:
> On 08/04/15 09:57, Ard Biesheuvel wrote:
>> LinuxLoader has been split off from the ARM BDS into a separate
>> EFI application. Because we never included this application into
>> the ArmVirtPkg platforms, its ARM BDS builds have effectively been
>> broken ever since that change was merged.
>>
>> Let's fix the situation by:
>> - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
>>   have UEFI stub support enabled by default, and the LinuxLoader code for
>>   booting arm64 Linux kernels is buggy. Note that this does not disable
>>   the ARM BDS text menu, it just removes the ability to boot bare Linux
>>   kernels.
>> - Adding the LinuxLoader EFI application to the ARM builds.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---
>>  ArmVirtPkg/ArmVirtQemu.dsc | 5 +
>>  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
>>  3 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index 2e2708d1c281..735f9edc58d6 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>>
>> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
>>
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
>> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>>
>>  [LibraryClasses.common.UEFI_DRIVER]
>>
>> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
>> @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]
>>
>>gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
>>
>> +[PcdsFeatureFlag.AARCH64]
>> +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
>> +
>>  [PcdsFixedAtBuild.common]
>>gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
>>
>> @@ -398,9 +404,6 @@ [Components.common]
>>
>> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>>
>> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>>
>> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
>> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>>
>> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>>
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index a2a82a4dba8c..92d55c770f55 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -381,3 +381,8 @@ [Components.common]
>>MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>> +
>> +[Components.ARM]
>> +!if $(INTEL_BDS) == FALSE
>> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
>> +!endif
>> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
>> index 3c0487cd95b6..47f9b095b3af 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.fdf
>> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
>> @@ -177,6 +177,9 @@ [FV.FvMain]
>>INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
>>  !else
>>INF ArmPlatformPkg/Bds/Bds.inf
>> +!if $(ARCH) == ARM
>> +  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
>> +!endif
>>  !endif
>
> One question -- do we have any trick in place in ArmVirtPkg that allows
> us to find UEFI_APPLICATION modules in firmware volumes? I vaguely
> recall patches from the list that expose FVs as filesystems, or some such.
>
> If we use that in ArmVirtPkg, then it makes sense to build a
> UEFI_APPLICATION into the firmware binary; otherwise it doesn't. (The
> UEFI shell is located differently by the Intel BDS; the FILE_GUID of the
> shell binary is specified in PcdShellFile, and GenericBdsLib looks for
> it specifically.)
>
> Hm... yes, I think I have "MdeModulePkg/Universal/FvSimpleFileSystemDxe"
> in mind. We don't use it in ArmVirtPkg (nor OvmfPkg, FWIW). So, please
> either drop the FDF hunk, or include FvSimpleFileSystemDxe too in the
> build. (Or explain why I'm wrong :))
>

I think you're right. I fixed the ARM BDS menu, but booting an image
using the LinuxLoader does not actually work after applying the patch.
(Should have tested this more thoroughly, obviously). I will respin
and add the FvSimpleFileSystemDxe to the ARM+ARM_BDS build
___
edk2-devel mailing list
ed

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support

[Laszlo Ersek]

On 08/04/15 10:59, Zeng, Star wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, August 4, 2015 4:34 PM
>> To: Zeng, Star
>> Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini
>> Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
>>
>> Star,
>>
>> On 07/31/15 14:22, Star Zeng wrote:
>>> This feature is added for UEFI spec that says "Stack may be marked as
>>> non-executable in identity mapped page tables".
>>> A PCD PcdSetNxForStack is added to turn on/off this feature, and it is
>>> FALSE by default.
>>
>>> diff --git a/MdeModulePkg/MdeModulePkg.dec
>>> b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644
>>> --- a/MdeModulePkg/MdeModulePkg.dec
>>> +++ b/MdeModulePkg/MdeModulePkg.dec
>>> @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>>>## The number of bytes between registers in serial device.  The default 
>>> is
>> 1 byte.
>>># @Prompt Serial Port Register Stride in Bytes
>>>
>>>
>> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00
>> 01
>>> 006d
>>> -
>>> +
>>> +  ## Indicates if to set NX for stack.  #  For the DxeIpl and
>>> + the DxeCore are both X64, set NX for stack feature also require
>>> + PcdDxeIplBuildPageTables be TRUE.  #  For the DxeIpl and the
>>> + DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is FALSE), set NX
>> for stack feature also require  #  IA32 PAE is supported and Execute Disable
>> Bit is available.
>>> +  #   TRUE  - to set NX for stack.
>>> +  #   FALSE - Not to set NX for stack.
>>> +  # @Prompt Set NX for stack.
>>> +
>>> +
>> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x
>> 0001
>>> + 006f
>>> +
>>
>> Are there any restrictions for setting this PCD statically in a platform DSC 
>> file?
>> Could it regress anything?
> 
> No. This feature require to build page table. More detailed explanation below.
> 
>>
>> In OVMF we have three DSC files:
>>
>> - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is
>>   FALSE. If we set PcdSetNxForStack in this DSC file, will the code
>>   dynamically determine if the hardware has the necessary features, and
>>   fall back gracefully if it doesn't?
> 
> Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used to
> determine if the hardware has the necessary features.
> By default, 32BIT PEI+32BIT DXE do not need page table and
> PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both X64
> as the comments in MdeModulePkg.dec.
> But this feature require page table, so (PcdGetBool (PcdSetNxForStack) && 
> IsIa32PaeSupport () && IsExecuteDisableBitAvailable ())
> is used to determine if building page table or not.

Ah, I can see that in the patch. It gates the new
Create4GPageTablesIa32Pae() function.

> 
>>
>> - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode
>>   is TRUE. This use case doesn't seem to be described in the .dec file
>>   above. Is this configuration compatible with PcdSetNxForStack=TRUE?
> 
> Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special
> comments for it in MdeModulepkg.dec and just PcdGetBool (PcdSetNxForStack)
> is used to enable this feature or not in page table (Nx bit).

Great.

> 
>>
>> - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is
>>   FALSE. We don't change PcdDxeIplBuildPageTables from the default, but
>>   the default in "MdeModulePkg/MdeModulePkg.dec" is TRUE, and we
>>   inherit that. Can we set PcdSetNxForStack to TRUE, statically?
> 
> Of course YES.

Thanks.

The question emerges then: why doesn't PcdSetNxForStack default to true?

I can see two possible reasons:

- It is a new feature and causes changes in behavior. At worst, some
firmware could even rely on executing code from the stack. That
shouldn't be broken.

- The code adds a new ASSERT(), and it could be triggered if the
platform left PcdDxeIplBuildPageTables at FALSE. It's not nice to
introduce code with potential to trigger an ASSERT() immediately, so
this makes sense too.

In OvmfPkg none of these should be an issue. I think (well, actually,
Paolo suggested it) that we should therefore enable the feature in OVMF.

I'll mark this discussion thread for later, so I can remember it, and
maybe submit a patch for it. Jordan (or anyone else), please feel free
to take a stab at it, if you'd like to :)

Thanks
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Sharma Bhupesh]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, August 04, 2015 2:36 PM
> On 08/04/15 10:38, Sharma Bhupesh wrote:
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: Tuesday, August 04, 2015 2:01 PM
> >>
> >> On 4 August 2015 at 10:07, Sharma Bhupesh
> >> 
> >> wrote:
> 
> >>> With the EFI_STUB becoming more or less mandatory and the leagacy
> >>> ARM Bds Linux Loader being deprecated, are there any plans to
> >>> provide means
> >> to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
> >>>
> >>
> >> No. FIT images are a U-Boot construct. The recommended way under UEFI
> >> is to install the device tree as a FDT configuration table in the
> firmware.
> >> Look at FdtPlatformDxe for more info. The initrd can be loaded by the
> >> EFI stub, by passing the initrd= option.
> >>
> >> The recommended way of doing authentication of bootable images is to
> >> use UEFI Secure Boot. DTB authentication is implicit if it is part of
> >> the UEFI image itself. How to do initrd authentication is undefined.
> 
> (I'd say "unspecified" rather than "undefined", but that's a side point.)
> 
> > initrd (Rootfs) is probably the easiest place to introduce a malicious
> > application in, which can easily overwrite the text area, thus causing
> the core to run a Trojan.
> 
> How is this different from overwriting applications on a normal file
> system? As far as I understand, applications are not part of the chain
> being verified.

Cryptographically verifying the entire Root filesystem being provided with
a software development kit, allows a OEM/customer to ensure that
the platform only boots a application-set which is authenticated using
their Public-Private key pairs.

So, if the system tries to launch a rootfs which is not authenticated 
via the OEM/customer's public key, the boot process stalls and a preventive
tamper-proofing action like zero'ing the DDR contents and reseting the SoC can 
be taken.

Regards,
Bhupesh

> 
> Kernel modules are (and they do reside in the initrd), but they should
> already be covered by module signing.
> 
> http://mjg59.dreamwidth.org/12368.html
> 
> https://access.redhat.com/documentation/en-
> US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-
> signing-kernel-modules-for-secure-boot.html
> https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_se
> cboot.html
> 
> https://www.suse.com/documentation/sles-
> 12/book_sle_admin/data/sec_uefi_secboot.html
> 
> Thanks
> Laszlo
> 
> >
> > The normal secure chain of boot, requires that each component verifies
> > the next component it launches. FIT format seems to plug this gap.
> >
> > Can you point me to some documentation on UEFI secure boot and how it
> > works on the
> > ARM64 platforms - does it internally use and program the ARM TrustZone
> > components like the TZASC and TZPC to partition the System RAM, etc
> > into appropriate secure and non-secure partitions and the images
> cryptographically verify the next stage image.
> > A typical flow most OEMs use is:
> >
> > BootROM -> Arm Trusted Firmware -> UEFI -> Linux -> Initrd
> >
> > The current SEC stage code for ARM64 platforms supported in EDK2 seem
> > to be programming the TZASC and TZPC entities, but I cannot see any
> > secure chain-of-trust being established for the next stage images
> there.
> >
> > Regards,
> > Bhupesh
> >
> >>
> >> Regards,
> >> Ard.
> >>
>  -Original Message-
>  From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
>  Of Ard Biesheuvel
>  Sent: Tuesday, August 04, 2015 1:27 PM
>  To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
>  ler...@redhat.com
>  Cc: ryan.har...@linaro.org; Ard Biesheuvel
>  Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with
>  LinuxLoader changes
> 
>  LinuxLoader has been split off from the ARM BDS into a separate EFI
>  application. Because we never included this application into the
>  ArmVirtPkg platforms, its ARM BDS builds have effectively been
>  broken ever since that change was merged.
> 
>  Let's fix the situation by:
>  - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux
> >> kernels
>    have UEFI stub support enabled by default, and the LinuxLoader
>  code
> >> for
>    booting arm64 Linux kernels is buggy. Note that this does not
> >> disable
>    the ARM BDS text menu, it just removes the ability to boot bare
> >> Linux
>    kernels.
>  - Adding the LinuxLoader EFI application to the ARM builds.
> 
>  Contributed-under: TianoCore Contribution Agreement 1.0
>  Signed-off-by: Ard Biesheuvel 
>  ---
>   ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---
>  ArmVirtPkg/ArmVirtQemu.dsc
>  | 5
>  +  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
>   3 files changed, 14 insertions(+), 3 deletions(-)
> 
>  diff --git a/ArmVirt

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Laszlo Ersek]

On 08/04/15 10:38, Sharma Bhupesh wrote:
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Tuesday, August 04, 2015 2:01 PM
>>
>> On 4 August 2015 at 10:07, Sharma Bhupesh 
>> wrote:

>>> With the EFI_STUB becoming more or less mandatory and the leagacy ARM
>>> Bds Linux Loader being deprecated, are there any plans to provide means
>> to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
>>>
>>
>> No. FIT images are a U-Boot construct. The recommended way under UEFI is
>> to install the device tree as a FDT configuration table in the firmware.
>> Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI
>> stub, by passing the initrd= option.
>>
>> The recommended way of doing authentication of bootable images is to use
>> UEFI Secure Boot. DTB authentication is implicit if it is part of the
>> UEFI image itself. How to do initrd authentication is undefined.

(I'd say "unspecified" rather than "undefined", but that's a side point.)

> initrd (Rootfs) is probably the easiest place to introduce a malicious 
> application
> in, which can easily overwrite the text area, thus causing the core to run a 
> Trojan.

How is this different from overwriting applications on a normal file
system? As far as I understand, applications are not part of the chain
being verified.

Kernel modules are (and they do reside in the initrd), but they should
already be covered by module signing.

http://mjg59.dreamwidth.org/12368.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html
https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_uefi_secboot.html

https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_uefi_secboot.html

Thanks
Laszlo

> 
> The normal secure chain of boot, requires that each component verifies the 
> next component
> it launches. FIT format seems to plug this gap.
> 
> Can you point me to some documentation on UEFI secure boot and how it works 
> on the
> ARM64 platforms - does it internally use and program the ARM TrustZone 
> components
> like the TZASC and TZPC to partition the System RAM, etc into appropriate 
> secure
> and non-secure partitions and the images cryptographically verify the next 
> stage image.
> A typical flow most OEMs use is:
> 
> BootROM -> Arm Trusted Firmware -> UEFI -> Linux -> Initrd
> 
> The current SEC stage code for ARM64 platforms supported in EDK2 seem to be
> programming the TZASC and TZPC entities, but I cannot see any secure 
> chain-of-trust being
> established for the next stage images there.
> 
> Regards,
> Bhupesh
> 
>>
>> Regards,
>> Ard.
>>
 -Original Message-
 From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
 Of Ard Biesheuvel
 Sent: Tuesday, August 04, 2015 1:27 PM
 To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
 ler...@redhat.com
 Cc: ryan.har...@linaro.org; Ard Biesheuvel
 Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with
 LinuxLoader changes

 LinuxLoader has been split off from the ARM BDS into a separate EFI
 application. Because we never included this application into the
 ArmVirtPkg platforms, its ARM BDS builds have effectively been broken
 ever since that change was merged.

 Let's fix the situation by:
 - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux
>> kernels
   have UEFI stub support enabled by default, and the LinuxLoader code
>> for
   booting arm64 Linux kernels is buggy. Note that this does not
>> disable
   the ARM BDS text menu, it just removes the ability to boot bare
>> Linux
   kernels.
 - Adding the LinuxLoader EFI application to the ARM builds.

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Ard Biesheuvel 
 ---
  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---  ArmVirtPkg/ArmVirtQemu.dsc
 | 5
 +  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
  3 files changed, 14 insertions(+), 3 deletions(-)

 diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
 index
 2e2708d1c281..735f9edc58d6 100644
 --- a/ArmVirtPkg/ArmVirt.dsc.inc
 +++ b/ArmVirtPkg/ArmVirt.dsc.inc
 @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]

 PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceL
 PerformanceLib|ib.in
 f

 MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemory
 MemoryAllocationLib|Alloc
 ationLib.inf
HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
 +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
 +
 + FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.in
 + f  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf

  [LibraryClasses.common.UEFI_DRIVER]

 ReportStatusCodeLib|IntelFra

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support

[Zeng, Star]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, August 4, 2015 4:34 PM
> To: Zeng, Star
> Cc: edk2-de...@ml01.01.org; Yao, Jiewen; Paolo Bonzini
> Subject: Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support
> 
> Star,
> 
> On 07/31/15 14:22, Star Zeng wrote:
> > This feature is added for UEFI spec that says "Stack may be marked as
> > non-executable in identity mapped page tables".
> > A PCD PcdSetNxForStack is added to turn on/off this feature, and it is
> > FALSE by default.
> 
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> > b/MdeModulePkg/MdeModulePkg.dec index 4a1acac..3b5617a 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
> >## The number of bytes between registers in serial device.  The default 
> > is
> 1 byte.
> ># @Prompt Serial Port Register Stride in Bytes
> >
> >
> gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x00
> 01
> > 006d
> > -
> > +
> > +  ## Indicates if to set NX for stack.  #  For the DxeIpl and
> > + the DxeCore are both X64, set NX for stack feature also require
> > + PcdDxeIplBuildPageTables be TRUE.  #  For the DxeIpl and the
> > + DxeCore are both IA32 (PcdDxeIplSwitchToLongMode is FALSE), set NX
> for stack feature also require  #  IA32 PAE is supported and Execute Disable
> Bit is available.
> > +  #   TRUE  - to set NX for stack.
> > +  #   FALSE - Not to set NX for stack.
> > +  # @Prompt Set NX for stack.
> > +
> > +
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x
> 0001
> > + 006f
> > +
> 
> Are there any restrictions for setting this PCD statically in a platform DSC 
> file?
> Could it regress anything?

No. This feature require to build page table. More detailed explanation below.

> 
> In OVMF we have three DSC files:
> 
> - OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is
>   FALSE. If we set PcdSetNxForStack in this DSC file, will the code
>   dynamically determine if the hardware has the necessary features, and
>   fall back gracefully if it doesn't?

Yes, IsIa32PaeSupport () and IsExecuteDisableBitAvailable () are used to
determine if the hardware has the necessary features.
By default, 32BIT PEI+32BIT DXE do not need page table and
PcdDxeIplBuildPageTables is only for DxeIpl and the DxeCore are both X64
as the comments in MdeModulePkg.dec.
But this feature require page table, so (PcdGetBool (PcdSetNxForStack) && 
IsIa32PaeSupport () && IsExecuteDisableBitAvailable ())
is used to determine if building page table or not.

> 
> - OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode
>   is TRUE. This use case doesn't seem to be described in the .dec file
>   above. Is this configuration compatible with PcdSetNxForStack=TRUE?

Yes, 32BIT PEI+64BIT DXE builds page table by default, so no special
comments for it in MdeModulepkg.dec and just PcdGetBool (PcdSetNxForStack)
is used to enable this feature or not in page table (Nx bit).

> 
> - OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is
>   FALSE. We don't change PcdDxeIplBuildPageTables from the default, but
>   the default in "MdeModulePkg/MdeModulePkg.dec" is TRUE, and we
>   inherit that. Can we set PcdSetNxForStack to TRUE, statically?

Of course YES.

> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Laszlo Ersek]

On 08/04/15 09:57, Ard Biesheuvel wrote:
> LinuxLoader has been split off from the ARM BDS into a separate
> EFI application. Because we never included this application into
> the ArmVirtPkg platforms, its ARM BDS builds have effectively been
> broken ever since that change was merged.
> 
> Let's fix the situation by:
> - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
>   have UEFI stub support enabled by default, and the LinuxLoader code for
>   booting arm64 Linux kernels is buggy. Note that this does not disable
>   the ARM BDS text menu, it just removes the ability to boot bare Linux
>   kernels.
> - Adding the LinuxLoader EFI application to the ARM builds.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---
>  ArmVirtPkg/ArmVirtQemu.dsc | 5 +
>  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
>  3 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index 2e2708d1c281..735f9edc58d6 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>  
>  [LibraryClasses.common.UEFI_DRIVER]
>
> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
> @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]
>  
>gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
>  
> +[PcdsFeatureFlag.AARCH64]
> +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
> +
>  [PcdsFixedAtBuild.common]
>gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
>  
> @@ -398,9 +404,6 @@ [Components.common]
>
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
>
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
>
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>  
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index a2a82a4dba8c..92d55c770f55 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -381,3 +381,8 @@ [Components.common]
>MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
> +
> +[Components.ARM]
> +!if $(INTEL_BDS) == FALSE
> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
> index 3c0487cd95b6..47f9b095b3af 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -177,6 +177,9 @@ [FV.FvMain]
>INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
>  !else
>INF ArmPlatformPkg/Bds/Bds.inf
> +!if $(ARCH) == ARM
> +  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> +!endif
>  !endif

One question -- do we have any trick in place in ArmVirtPkg that allows
us to find UEFI_APPLICATION modules in firmware volumes? I vaguely
recall patches from the list that expose FVs as filesystems, or some such.

If we use that in ArmVirtPkg, then it makes sense to build a
UEFI_APPLICATION into the firmware binary; otherwise it doesn't. (The
UEFI shell is located differently by the Intel BDS; the FILE_GUID of the
shell binary is specified in PcdShellFile, and GenericBdsLib looks for
it specifically.)

Hm... yes, I think I have "MdeModulePkg/Universal/FvSimpleFileSystemDxe"
in mind. We don't use it in ArmVirtPkg (nor OvmfPkg, FWIW). So, please
either drop the FDF hunk, or include FvSimpleFileSystemDxe too in the
build. (Or explain why I'm wrong :))

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Sharma Bhupesh]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, August 04, 2015 2:01 PM
> 
> On 4 August 2015 at 10:07, Sharma Bhupesh 
> wrote:
> > I have a related question. The EFI stub documentation (see [1]), seems
> > to suggest that we have the support to boot the kernel Image, DTB and
> > Rootfs when supplied as separate images to the EFI stub.
> >
> > However, other Bootloaders like u-boot are supporting newer FIT image
> > format (see [2]), where these 3 images can be bundled into one and
> > passed to the bootloader for verification (both crc as well as
> cryptographic checks) and loading. This is supported on both x86 and ARM
> platforms.
> >
> > At Freescale, we have a internal re-worked version of the ARM Bds
> > Linux Loader, where we can parse a FIT format Linux image and load
> Linux using the same on ARM64 platforms.
> >
> 
> OK, first of all, I should point out that the ARM BDS does not adhere to
> the UEFI spec regarding booting removable media. This means that, as long
> as you use the ARM BDS, you will not be able to run OS installers that
> have their GRUB or kernel image in /EFI/BOOT/BOOTAA64.EFI, which is a
> default path defined by the spec.

Agreed.
 
> > With the EFI_STUB becoming more or less mandatory and the leagacy ARM
> > Bds Linux Loader being deprecated, are there any plans to provide means
> to pass FIT format images via EFI_STUB to the ARM64 Linux kernel?
> >
> 
> No. FIT images are a U-Boot construct. The recommended way under UEFI is
> to install the device tree as a FDT configuration table in the firmware.
> Look at FdtPlatformDxe for more info. The initrd can be loaded by the EFI
> stub, by passing the initrd= option.
> 
> The recommended way of doing authentication of bootable images is to use
> UEFI Secure Boot. DTB authentication is implicit if it is part of the
> UEFI image itself. How to do initrd authentication is undefined.

initrd (Rootfs) is probably the easiest place to introduce a malicious 
application
in, which can easily overwrite the text area, thus causing the core to run a 
Trojan.

The normal secure chain of boot, requires that each component verifies the next 
component
it launches. FIT format seems to plug this gap.

Can you point me to some documentation on UEFI secure boot and how it works on 
the
ARM64 platforms - does it internally use and program the ARM TrustZone 
components
like the TZASC and TZPC to partition the System RAM, etc into appropriate secure
and non-secure partitions and the images cryptographically verify the next 
stage image.
A typical flow most OEMs use is:

BootROM -> Arm Trusted Firmware -> UEFI -> Linux -> Initrd

The current SEC stage code for ARM64 platforms supported in EDK2 seem to be
programming the TZASC and TZPC entities, but I cannot see any secure 
chain-of-trust being
established for the next stage images there.

Regards,
Bhupesh

> 
> Regards,
> Ard.
> 
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Ard Biesheuvel
> >> Sent: Tuesday, August 04, 2015 1:27 PM
> >> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org;
> >> ler...@redhat.com
> >> Cc: ryan.har...@linaro.org; Ard Biesheuvel
> >> Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with
> >> LinuxLoader changes
> >>
> >> LinuxLoader has been split off from the ARM BDS into a separate EFI
> >> application. Because we never included this application into the
> >> ArmVirtPkg platforms, its ARM BDS builds have effectively been broken
> >> ever since that change was merged.
> >>
> >> Let's fix the situation by:
> >> - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux
> kernels
> >>   have UEFI stub support enabled by default, and the LinuxLoader code
> for
> >>   booting arm64 Linux kernels is buggy. Note that this does not
> disable
> >>   the ARM BDS text menu, it just removes the ability to boot bare
> Linux
> >>   kernels.
> >> - Adding the LinuxLoader EFI application to the ARM builds.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---  ArmVirtPkg/ArmVirtQemu.dsc
> >> | 5
> >> +  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
> >>  3 files changed, 14 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> >> index
> >> 2e2708d1c281..735f9edc58d6 100644
> >> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> >> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> >> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
> >>
> >> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceL
> >> PerformanceLib|ib.in
> >> f
> >>
> >> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemory
> >> MemoryAllocationLib|Alloc
> >> ationLib.inf
> >>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> >> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> >> +
> >> + FileHandleLi

Re: [edk2] [PATCH] MdeModulePkg DxeIpl: Add stack NX support

[Laszlo Ersek]

Star,

On 07/31/15 14:22, Star Zeng wrote:
> This feature is added for UEFI spec that says
> "Stack may be marked as non-executable in identity mapped page tables".
> A PCD PcdSetNxForStack is added to turn on/off this feature, and it is
> FALSE by default.

> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 4a1acac..3b5617a 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -948,7 +948,16 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>## The number of bytes between registers in serial device.  The default is 
> 1 byte.
># @Prompt Serial Port Register Stride in Bytes
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterStride|1|UINT32|0x0001006d
> -  
> +
> +  ## Indicates if to set NX for stack.
> +  #  For the DxeIpl and the DxeCore are both X64, set NX for stack feature 
> also require PcdDxeIplBuildPageTables be TRUE.
> +  #  For the DxeIpl and the DxeCore are both IA32 (PcdDxeIplSwitchToLongMode 
> is FALSE), set NX for stack feature also require
> +  #  IA32 PAE is supported and Execute Disable Bit is available.
> +  #   TRUE  - to set NX for stack.
> +  #   FALSE - Not to set NX for stack.
> +  # @Prompt Set NX for stack.
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack|FALSE|BOOLEAN|0x0001006f
> +

Are there any restrictions for setting this PCD statically in a platform
DSC file? Could it regress anything?

In OVMF we have three DSC files:

- OvmfPkgIa32.dsc: 32-bit PEI, 32-bit DXE, PcdDxeIplSwitchToLongMode is
  FALSE. If we set PcdSetNxForStack in this DSC file, will the code
  dynamically determine if the hardware has the necessary features, and
  fall back gracefully if it doesn't?

- OvmfPkgIa32X64.dsc: 32-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode
  is TRUE. This use case doesn't seem to be described in the .dec file
  above. Is this configuration compatible with PcdSetNxForStack=TRUE?

- OvmfPkgX64.dsc: 64-bit PEI, 64-bit DXE, PcdDxeIplSwitchToLongMode is
  FALSE. We don't change PcdDxeIplBuildPageTables from the default, but
  the default in "MdeModulePkg/MdeModulePkg.dec" is TRUE, and we
  inherit that. Can we set PcdSetNxForStack to TRUE, statically?

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Ard Biesheuvel]

On 4 August 2015 at 10:07, Sharma Bhupesh  wrote:
> I have a related question. The EFI stub documentation (see [1]), seems to 
> suggest that
> we have the support to boot the kernel Image, DTB and Rootfs when supplied as
> separate images to the EFI stub.
>
> However, other Bootloaders like u-boot are supporting newer FIT image format 
> (see [2]), where
> these 3 images can be bundled into one and passed to the bootloader for 
> verification (both
> crc as well as cryptographic checks) and loading. This is supported on both 
> x86 and ARM platforms.
>
> At Freescale, we have a internal re-worked version of the ARM Bds Linux 
> Loader, where we can parse a FIT format
> Linux image and load Linux using the same on ARM64 platforms.
>

OK, first of all, I should point out that the ARM BDS does not adhere
to the UEFI spec regarding booting removable media. This means that,
as long as you use the ARM BDS, you will not be able to run OS
installers that have their GRUB or kernel image in
/EFI/BOOT/BOOTAA64.EFI, which is a default path defined by the spec.

> With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds 
> Linux Loader being deprecated,
> are there any plans to provide means to pass FIT format images via EFI_STUB 
> to the ARM64 Linux kernel?
>

No. FIT images are a U-Boot construct. The recommended way under UEFI
is to install the device tree as a FDT configuration table in the
firmware. Look at FdtPlatformDxe for more info. The initrd can be
loaded by the EFI stub, by passing the initrd= option.

The recommended way of doing authentication of bootable images is to
use UEFI Secure Boot. DTB authentication is implicit if it is part of
the UEFI image itself. How to do initrd authentication is undefined.

Regards,
Ard.

>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
>> Biesheuvel
>> Sent: Tuesday, August 04, 2015 1:27 PM
>> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com
>> Cc: ryan.har...@linaro.org; Ard Biesheuvel
>> Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader
>> changes
>>
>> LinuxLoader has been split off from the ARM BDS into a separate EFI
>> application. Because we never included this application into the
>> ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever
>> since that change was merged.
>>
>> Let's fix the situation by:
>> - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
>>   have UEFI stub support enabled by default, and the LinuxLoader code for
>>   booting arm64 Linux kernels is buggy. Note that this does not disable
>>   the ARM BDS text menu, it just removes the ability to boot bare Linux
>>   kernels.
>> - Adding the LinuxLoader EFI application to the ARM builds.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---  ArmVirtPkg/ArmVirtQemu.dsc | 5
>> +  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
>>  3 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index
>> 2e2708d1c281..735f9edc58d6 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
>>
>> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.in
>> f
>>
>> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAlloc
>> ationLib.inf
>>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
>> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>>
>>  [LibraryClasses.common.UEFI_DRIVER]
>>
>> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLib
>> Framework/DxeReportStatusCodeLib.inf
>> @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]
>>
>>gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
>>
>> +[PcdsFeatureFlag.AARCH64]
>> +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
>> +
>>  [PcdsFixedAtBuild.common]
>>gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization
>> Platform"
>>
>> @@ -398,9 +404,6 @@ [Components.common]
>>
>> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comman
>> dsLib.inf
>>
>> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comman
>> dsLib.inf
>>
>> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLi
>> b.inf
>> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
>> -
>> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>>
>> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgComma
>> ndLib.inf
>>
>> diff --git a/ArmVirtPk

Re: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Sharma Bhupesh]

I have a related question. The EFI stub documentation (see [1]), seems to 
suggest that
we have the support to boot the kernel Image, DTB and Rootfs when supplied as 
separate images to the EFI stub.

However, other Bootloaders like u-boot are supporting newer FIT image format 
(see [2]), where
these 3 images can be bundled into one and passed to the bootloader for 
verification (both
crc as well as cryptographic checks) and loading. This is supported on both x86 
and ARM platforms.

At Freescale, we have a internal re-worked version of the ARM Bds Linux Loader, 
where we can parse a FIT format
Linux image and load Linux using the same on ARM64 platforms.

With the EFI_STUB becoming more or less mandatory and the leagacy ARM Bds Linux 
Loader being deprecated,
are there any plans to provide means to pass FIT format images via EFI_STUB to 
the ARM64 Linux kernel?

[1] https://www.kernel.org/doc/Documentation/efi-stub.txt

[2] 
http://git.denx.de/?p=u-boot.git;a=blob_plain;f=doc/uImage.FIT/kernel.its;hb=HEAD

Regards,
Bhupesh


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> Biesheuvel
> Sent: Tuesday, August 04, 2015 1:27 PM
> To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com
> Cc: ryan.har...@linaro.org; Ard Biesheuvel
> Subject: [edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader
> changes
> 
> LinuxLoader has been split off from the ARM BDS into a separate EFI
> application. Because we never included this application into the
> ArmVirtPkg platforms, its ARM BDS builds have effectively been broken ever
> since that change was merged.
> 
> Let's fix the situation by:
> - Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
>   have UEFI stub support enabled by default, and the LinuxLoader code for
>   booting arm64 Linux kernels is buggy. Note that this does not disable
>   the ARM BDS text menu, it just removes the ability to boot bare Linux
>   kernels.
> - Adding the LinuxLoader EFI application to the ARM builds.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---  ArmVirtPkg/ArmVirtQemu.dsc | 5
> +  ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
>  3 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index
> 2e2708d1c281..735f9edc58d6 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
> 
> PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.in
> f
> 
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAlloc
> ationLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> 
>  [LibraryClasses.common.UEFI_DRIVER]
> 
> ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLib
> Framework/DxeReportStatusCodeLib.inf
> @@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]
> 
>gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
> 
> +[PcdsFeatureFlag.AARCH64]
> +  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
> +
>  [PcdsFixedAtBuild.common]
>gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization
> Platform"
> 
> @@ -398,9 +404,6 @@ [Components.common]
> 
> NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1Comman
> dsLib.inf
> 
> NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1Comman
> dsLib.inf
> 
> HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLi
> b.inf
> -  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> -
> FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> -  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
>PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> 
> BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgComma
> ndLib.inf
> 
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc index
> a2a82a4dba8c..92d55c770f55 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -381,3 +381,8 @@ [Components.common]
>MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
> +
> +[Components.ARM]
> +!if $(INTEL_BDS) == FALSE
> +  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
> +!endif
> diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf index
> 3c0487cd95b6..47f9b095b3af 100644
> --- a/ArmVirtPkg/ArmVirtQemu.fdf
> +++ b/ArmVirtPkg/ArmVirtQemu.fdf
> @@ -177,6 +177,9 @@ [FV.FvMain]
>INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
>  !else
>INF ArmPlatformPkg/Bds/Bds.inf
> +!if $(

Re: [edk2] [Patch 0/2] UiApp/LegacyBootMaintUi: Update Copyright info for

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric Dong
Sent: Monday, August 3, 2015 2:29 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 0/2] UiApp/LegacyBootMaintUi: Update Copyright info for

Although these two modules are new added, but this code is come from  
IntelFrameworkModulePkg/Universal/BdsDxe driver, so update copyright 
info to cover these old code history.

Eric Dong (2):
  UiApp: Update copyright info, cover old code existed in old BdsDxe
driver.
  LegacyBootMaintUi: Update copyright info, cover old code existed in
old BdsDxe driver.

 .../LegacyBootMaintUiLib/LegacyBootMaintUi.c|   2 +-
 .../LegacyBootMaintUiLib/LegacyBootMaintUi.h|   2 +-
 .../LegacyBootMaintUiStrings.uni| Bin 6362 -> 6376 bytes
 .../LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h |   2 +-
 MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr |   2 +-
 MdeModulePkg/Application/UiApp/BootMaint/BmLib.c|   2 +-
 .../Application/UiApp/BootMaint/Bmstring.uni| Bin 41508 -> 41522 bytes
 .../Application/UiApp/BootMaint/BootMaint.c |   2 +-
 .../Application/UiApp/BootMaint/BootMaint.h |   2 +-
 .../Application/UiApp/BootMaint/BootOption.c|   2 +-
 .../Application/UiApp/BootMaint/ConsoleOption.c |   2 +-
 MdeModulePkg/Application/UiApp/BootMaint/Data.c |   2 +-
 MdeModulePkg/Application/UiApp/BootMaint/FE.vfr |   2 +-
 .../Application/UiApp/BootMaint/FileExplorer.c  |   2 +-
 MdeModulePkg/Application/UiApp/BootMaint/FormGuid.h |   2 +-
 .../Application/UiApp/BootMaint/UpdatePage.c|   2 +-
 MdeModulePkg/Application/UiApp/BootMaint/Variable.c |   2 +-
 .../Application/UiApp/BootMngr/BootManager.c|   2 +-
 .../Application/UiApp/BootMngr/BootManager.h|   2 +-
 .../UiApp/BootMngr/BootManagerStrings.uni   | Bin 3518 -> 3532 bytes
 .../Application/UiApp/BootMngr/BootManagerVfr.Vfr   |   2 +-
 .../Application/UiApp/DeviceMngr/DeviceManager.c|   2 +-
 .../Application/UiApp/DeviceMngr/DeviceManager.h|   2 +-
 .../UiApp/DeviceMngr/DeviceManagerStrings.uni   | Bin 7086 -> 7100 bytes
 .../UiApp/DeviceMngr/DeviceManagerVfr.Vfr   |   2 +-
 .../UiApp/DeviceMngr/DriverHealthVfr.Vfr|   2 +-
 MdeModulePkg/Application/UiApp/FormsetGuid.h|   2 +-
 MdeModulePkg/Application/UiApp/FrontPage.c  |   2 +-
 MdeModulePkg/Application/UiApp/FrontPage.h  |   2 +-
 MdeModulePkg/Application/UiApp/FrontPageStrings.uni | Bin 11190 -> 11190 bytes
 MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr |   2 +-
 MdeModulePkg/Application/UiApp/Language.c   |   2 +-
 MdeModulePkg/Application/UiApp/Language.h   |   2 +-
 MdeModulePkg/Application/UiApp/String.c |   2 +-
 MdeModulePkg/Application/UiApp/String.h |   2 +-
 MdeModulePkg/Application/UiApp/Strings.uni  | Bin 4702 -> 4716 bytes
 MdeModulePkg/Application/UiApp/Ui.h |   2 +-
 MdeModulePkg/Application/UiApp/UiApp.inf|   2 +-
 38 files changed, 32 insertions(+), 32 deletions(-)

-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] ArmVirtPkg: align ARM BDS build with LinuxLoader changes

[Ard Biesheuvel]

LinuxLoader has been split off from the ARM BDS into a separate
EFI application. Because we never included this application into
the ArmVirtPkg platforms, its ARM BDS builds have effectively been
broken ever since that change was merged.

Let's fix the situation by:
- Disabling LinuxLoader support for AARCH64 builds: arm64 Linux kernels
  have UEFI stub support enabled by default, and the LinuxLoader code for
  booting arm64 Linux kernels is buggy. Note that this does not disable
  the ARM BDS text menu, it just removes the ability to boot bare Linux
  kernels.
- Adding the LinuxLoader EFI application to the ARM builds.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
---
 ArmVirtPkg/ArmVirt.dsc.inc | 9 ++---
 ArmVirtPkg/ArmVirtQemu.dsc | 5 +
 ArmVirtPkg/ArmVirtQemu.fdf | 3 +++
 3 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index 2e2708d1c281..735f9edc58d6 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -206,6 +206,9 @@ [LibraryClasses.common.UEFI_APPLICATION]
   PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
+  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
 
 [LibraryClasses.common.UEFI_DRIVER]
   
ReportStatusCodeLib|IntelFrameworkModulePkg/Library/DxeReportStatusCodeLibFramework/DxeReportStatusCodeLib.inf
@@ -277,6 +280,9 @@ [PcdsFeatureFlag.common]
 
   gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
 
+[PcdsFeatureFlag.AARCH64]
+  gArmPlatformTokenSpaceGuid.PcdBdsLinuxSupport|FALSE
+
 [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdFirmwareVendor|"ARM Virtualization Platform"
 
@@ -398,9 +404,6 @@ [Components.common]
   
NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
   
NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
   
HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
-  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
-  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
-  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
 
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index a2a82a4dba8c..92d55c770f55 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -381,3 +381,8 @@ [Components.common]
   MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
   MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
   MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
+
+[Components.ARM]
+!if $(INTEL_BDS) == FALSE
+  ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+!endif
diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index 3c0487cd95b6..47f9b095b3af 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -177,6 +177,9 @@ [FV.FvMain]
   INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
 !else
   INF ArmPlatformPkg/Bds/Bds.inf
+!if $(ARCH) == ARM
+  INF ArmPkg/Application/LinuxLoader/LinuxLoader.inf
+!endif
 !endif
 
   #
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel