Re: [edk2] [PATCH 1/1] ArmPkg/OpteeLib: Add APIs to communicate with OP-TEE

[Bhupesh Sharma]

Hi Sumit,

On Tue, Aug 28, 2018 at 10:04 PM, Sumit Garg  wrote:
> Hi Achin,
>
> On Tue, 28 Aug 2018 at 18:38, Achin Gupta  wrote:
>>
>> Hi Sumit,
>>
>> Apologies for not replying sooner. Some questions and thoughts inline.
>>
>> On Mon, Aug 27, 2018 at 03:28:52PM +0530, Sumit Garg wrote:
>> > On Fri, 24 Aug 2018 at 23:33, Matteo Carlini  
>> > wrote:
>> > >
>> > > +Achin
>> > >
>> > > SPD (for OP-TEE and other Trusted-OSes payloads running at S-EL1) and 
>> > > SPM (for Secure Partitions at S-EL0) are currently mutually exclusive 
>> > > into Trusted Firmware-A codebase.
>> > >
>> > > In other words, you cannot turn them on in parallel and execute both a 
>> > > S-EL1 Trusted OS AND (one or many) S-EL0 Secure Partitions in the Secure 
>> > > World with the current Software Architecture.
>> > >
>> >
>> > IIUC, currently BL32 image is common in Trusted Firmware-A code-base.
>> > If we turn on SPD then BL32= else if we turn on SPM
>> > then BL32=, correct?
>>
>> Yes! BL32 is a TOS image if SPD is enabled. It is a S-EL0 Standalone MM 
>> Secure
>> partition image if SPM is enabled.
>>
>> >
>> > But I think SMC calling conventions (SMC Calling Convention [1] and
>> > Management Mode Interface Specification [2]) doesn't put any such
>> > restrictions as SMC function IDs are totally separate.
>>
>> Yes, this was an implementation choice to ensure that either a S-EL1 payload
>> (Trusted OS) or a S-EL0 payload (MM SP) could be included in an Arm TF build 
>> but
>> not both.
>>
>> >
>> > > Achin and other Arm architects are trying to figure out a way for 
>> > > solving this problem without the need for a v8.4 Secure-EL2 Hypervisor, 
>> > > obviously without leveraging the isolation benefits of it (see also [1]).
>> > >
>> >
>> > Agree we won't be having isolation benefits which provides added level
>> > of Security.
>> >
>> > > But Ard is right: there could be use-cases to ship UEFI systems with 
>> > > OP-TEE and TAs on top...and this should still be currently possible 
>> > > using the SPD dispatcher into TF-A. I've not looked deeply into this 
>> > > patch, but it doesn’t seem to contradict the above Sw architecture.
>> > >
>> > > The question would be: would you foresee the need for running one (or 
>> > > many) other (UEFI/EDK2-based) Secure Services in the Secure World into a 
>> > > Secure Partition (using the StandaloneMmPkg) *together* with OP-TEE?
>> > >
>> >
>> > As per following quote from Management Mode Interface Specification [2]:
>> >
>> > "Management Mode (MM) provides an environment for implementing OS
>> > agnostic services (MM services) like RAS error handling, secure
>> > variable storage, and firmware updates in system firmware. The
>> > services can be invoked synchronously and asynchronously."
>> >
>> > It seems that MM mode is designed for more robust and platform
>> > specific services whereas OP-TEE (or any trusted OS) use-cases seem to
>> > be more complex like Entropy pool (RNG as in our case), DRM (could be
>> > valid use-case for Android TV or Chromebook), keymaster or keystore
>> > (for Edge devices) etc.
>>
>> It really depends upon the secure sw stack, use case and the requirements. MM
>> interface specification specifies a blocking SMC (MM_COMMUNICATE) to access a
>> secure service implemented in S-EL0.
>>
>> In the UEFI/PI/EDK2 context, MM drivers are used to satisfy a variety of use
>> cases during boot through the EFI_MM_COMMUNICATION_PROTOCOL (the bad press of
>> SMM aside!). MM_COMMUNICATE SMC provides a channel into the secure world to 
>> the
>> backend of this protocol on Arm systems. So any service accessible through 
>> this
>> protocol could be implemented on Arm systems in a MM SP.
>>
>> IIUC, in your case there is OP-TEE and firmware in the secure world. OP-TEE 
>> has
>> a static TA that provides the random data service and you want to leverage 
>> it at
>> boot time? Ditto for other services?
>
> Correct, actually we tried to create OP-TEE static (pseudo) TA that
> provides RNG service using thermal sensor noise and secure timer
> interrupts (FIQs) to fill entropy pool. Using this service via OP-TEE
> library in UEFI (subset in terms of functionality as compared to
> OP-TEE kernel driver) for features like KASLR etc.

Commenting on this from a distribution p-o-v, we have arn64 boards
available which have good entropy sources available but do not support
EFI_RNG_PROTOCOL as they would not like the EFI firmware running in
EL2 mode to use the secure entropy sources (which should be touched
only by secure EL3 or EL1 softwares).

In such cases, we are not able to support KASLR linux boot on such
boards as there is basically no EFI_RNG_PROTOCOL support (see [1]).
Ofcourse we can ask them to plug-in usb keys (Ard has a driver
available for the Chaos Usb Key, see [2]) to help generate the random
entropy for us, but it is not always possible in a production
environment. Using on-board entropy sources (if available), is the
best possible alternative there.

We rely on using 

Re: [edk2] [RFC PATCH] MdePkg/BaseIoLibIntrinsic ARM AARCH64: avoid C code for MMIO access

[Bhupesh Sharma]

On Tue, Jun 5, 2018 at 1:00 PM, Ard Biesheuvel
 wrote:
> Even though MMIO shares the address space with ordinary memory, the
> accesses involved are *not* ordinary memory accesses, and so it is
> a bad idea to let the compiler generate them using pointer dereferences.
>
> Instead, introduce a set of internal accessors implemented in assembler,
> and call those from the various Mmio[Read|Write]XX () implementations.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> Open coding the MMIO accesses is a good idea in general, but it also works
> around an issue that affects EDK2 running under KVM on ARM or AARCH64, where
> LTO code generation results in MMIO accesses involving instructions that 
> cannot
> be emulated by the hypervisor.
>
>  MdePkg/Library/BaseIoLibIntrinsic/AArch64/IoLibMmio.S| 164 
> ++
>  MdePkg/Library/BaseIoLibIntrinsic/Arm/IoLibMmio.S| 164 
> ++
>  MdePkg/Library/BaseIoLibIntrinsic/Arm/IoLibMmio.asm  | 165 
> ++
>  MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf |   9 +-
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c |  36 ++--
>  MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.h | 179 
> 
>  6 files changed, 692 insertions(+), 25 deletions(-)
>
> diff --git a/MdePkg/Library/BaseIoLibIntrinsic/AArch64/IoLibMmio.S 
> b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/IoLibMmio.S
> new file mode 100644
> index ..ac96df602f7a
> --- /dev/null
> +++ b/MdePkg/Library/BaseIoLibIntrinsic/AArch64/IoLibMmio.S
> @@ -0,0 +1,164 @@
> +#
> +#  Copyright (c) 2014-2018, Linaro Limited. 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.
> +#
> +#
> +
> +.text
> +.align 3
> +
> +GCC_ASM_EXPORT(MmioRead8Internal)
> +GCC_ASM_EXPORT(MmioWrite8Internal)
> +GCC_ASM_EXPORT(MmioRead16Internal)
> +GCC_ASM_EXPORT(MmioWrite16Internal)
> +GCC_ASM_EXPORT(MmioRead32Internal)
> +GCC_ASM_EXPORT(MmioWrite32Internal)
> +GCC_ASM_EXPORT(MmioRead64Internal)
> +GCC_ASM_EXPORT(MmioWrite64Internal)
> +
> +//
> +//  Reads an 8-bit MMIO register.
> +//
> +//  Reads the 8-bit MMIO register specified by Address. The 8-bit read value 
> is
> +//  returned. This function must guarantee that all MMIO read and write
> +//  operations are serialized.
> +//
> +//  If 8-bit MMIO register operations are not supported, then ASSERT().
> +//
> +//  @param  Address The MMIO register to read.
> +//
> +//  @return The value read.
> +//
> +ASM_PFX(MmioRead8Internal):
> +  ldrbw0, [x0]
> +  dsb ld

I am generally worried about sprinkling of the 'dsb' that the patch
here (and below) does, without adding comments.

Please note that with current (and possible future) ARM core erratas
and SoC specific erratas (from Si vendors) assumptions about the
serialization sequence can be tricky at times in terms of MMIO
accesses and dsb usages.

I would suggest that we document the 'dsb' usage here and _warn_ users
to add to/fix the sequence in case they are working on a 'broken' Si
with known erratas (which they normally get around with by fixing and
using inhouse versions of gcc which fix the sequencing issue for them
while generating the relevant code).

Regards,
Bhupesh


> +  ret
> +
> +//
> +//  Writes an 8-bit MMIO register.
> +//
> +//  Writes the 8-bit MMIO register specified by Address with the value 
> specified
> +//  by Value and returns Value. This function must guarantee that all MMIO 
> read
> +//  and write operations are serialized.
> +//
> +//  If 8-bit MMIO register operations are not supported, then ASSERT().
> +//
> +//  @param  Address The MMIO register to write.
> +//  @param  Value   The value to write to the MMIO register.
> +//
> +ASM_PFX(MmioWrite8Internal):
> +  dsb st
> +  strbw1, [x0]
> +  ret
> +
> +//
> +//  Reads a 16-bit MMIO register.
> +//
> +//  Reads the 16-bit MMIO register specified by Address. The 16-bit read 
> value is
> +//  returned. This function must guarantee that all MMIO read and write
> +//  operations are serialized.
> +//
> +//  If 16-bit MMIO register operations are not supported, then ASSERT().
> +//
> +//  @param  Address The MMIO register to read.
> +//
> +//  @return The value read.
> +//
> +ASM_PFX(MmioRead16Internal):
> +  ldrhw0, [x0]
> +  dsb ld
> +  ret
> +
> +//
> +//  Writes a 16-bit MMIO register.
> +//
> +//  Writes the 16-bit MMIO register specified by Address with the value 
> specified
> +//  by Value and returns Value. This function must guarantee that all MMIO 
> read
> +//  and 

Re: [edk2] [PATCH V3 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled

[Bhupesh SHARMA]

On Thu, Jan 26, 2017 at 8:06 PM, Leif Lindholm <leif.lindh...@linaro.org> wrote:
> On Fri, Jan 20, 2017 at 05:10:45PM +0530, Bhupesh Sharma wrote:
>> ARM TZASC-380 IP provides a mechanism to split memory regions being
>> protected via it into eight equal-sized sub-regions. A bit-setting
>> allows the corresponding subregion to be disabled.
>>
>> Several NXP/FSL SoCs support the TZASC-380 IP block and allow
>> the DDR connected via the TZASC to be partitioned into regions
>> having different security settings and also allow subregions
>> to be disabled.
>>
>> This patch enables this support and can be used for SoCs which
>> support such a partition of DDR regions.
>>
>> Details of the 'subregion_disable' register can be viewed here:
>> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0431c/CHDIGDCI.html
>>
>> Cc: Leif Lindholm <leif.lindh...@linaro.org>
>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
>> [bhupesh.li...@gmail.com : Added my gmail ID as the NXP one is no longer 
>> valid]
>> Signed-off-by: Bhupesh Sharma <bhupesh.li...@gmail.com>
>
> Thanks for the cleanup.
> I may actually delete that CTA9x4 lib once your platform gets in...
>
> Reviewed-by: Leif Lindholm <leif.lindh...@linaro.org>
>
> Pushed as 465663e.

Many thanks Leif.

Regards,
Bhupesh

>> ---
>> Changes from v2:
>>  - Added more descriptive arrays as suggested by Leif
>>
>>  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c   | 14 +++---
>>  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c| 13 ++---
>>  ArmPlatformPkg/Include/Drivers/ArmTrustzone.h | 19 
>> ++-
>>  3 files changed, 35 insertions(+), 11 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> index 6fa0774f59f8..42d731ea98c9 100644
>> --- 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> +++ 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> @@ -72,18 +72,18 @@ ArmPlatformSecTrustzoneInit (
>>// NOR Flash 0 non secure (BootMon)
>>TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_NOR0_BASE,0,
>> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>
>>// NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
>> secure firmware (sec_uefi.bin)
>>if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
>>  //Note: Your OS Kernel must be aware of the secure regions before to 
>> enable this region
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
>> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
>>} else {
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_NOR1_BASE,0,
>> -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>}
>>
>>// Base of SRAM. Only half of SRAM in Non Secure world
>> @@ -92,22 +92,22 @@ ArmPlatformSecTrustzoneInit (
>>  //Note: Your OS Kernel must be aware of the secure regions before to 
>> enable this region
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_SRAM_BASE,0,
>> -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW, 0);
>>} else {
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_SRAM_BASE,0,
>> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
>>}
>>
>>// Memory Mapped Peripherals. All in non secure world
>>TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_PERIPH_BASE,0,
>> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>
>>// MotherBoard Peripherals and On-chip peripherals.
>>TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
>>ARM_VE_

[edk2] [PATCH V3 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled

[Bhupesh Sharma]

ARM TZASC-380 IP provides a mechanism to split memory regions being
protected via it into eight equal-sized sub-regions. A bit-setting
allows the corresponding subregion to be disabled.

Several NXP/FSL SoCs support the TZASC-380 IP block and allow
the DDR connected via the TZASC to be partitioned into regions
having different security settings and also allow subregions
to be disabled.

This patch enables this support and can be used for SoCs which
support such a partition of DDR regions.

Details of the 'subregion_disable' register can be viewed here:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0431c/CHDIGDCI.html

Cc: Leif Lindholm <leif.lindh...@linaro.org>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
[bhupesh.li...@gmail.com : Added my gmail ID as the NXP one is no longer valid]
Signed-off-by: Bhupesh Sharma <bhupesh.li...@gmail.com>
---
Changes from v2:
 - Added more descriptive arrays as suggested by Leif

 .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c   | 14 +++---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c| 13 ++---
 ArmPlatformPkg/Include/Drivers/ArmTrustzone.h | 19 ++-
 3 files changed, 35 insertions(+), 11 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
index 6fa0774f59f8..42d731ea98c9 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
@@ -72,18 +72,18 @@ ArmPlatformSecTrustzoneInit (
   // NOR Flash 0 non secure (BootMon)
   TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
   ARM_VE_SMB_NOR0_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
 
   // NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
secure firmware (sec_uefi.bin)
   if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE,0,
-TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
   }
 
   // Base of SRAM. Only half of SRAM in Non Secure world
@@ -92,22 +92,22 @@ ArmPlatformSecTrustzoneInit (
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW, 0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
   }
 
   // Memory Mapped Peripherals. All in non secure world
   TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
   ARM_VE_SMB_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
 
   // MotherBoard Peripherals and On-chip peripherals.
   TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
   ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW, 0);
 }
 
 /**
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
index 070c0dcb5d4d..1f002198e552 100644
--- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
+++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
@@ -87,20 +87,27 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN SubregionDisableMask
   )
 {
   UINT32* Region;
+  UINT32  RegionAttributes;
 
   if (RegionId > TZASCGetNumRegions(TzascBase)) {
 return EFI_INVALID_PARAMETER;
   }
 
+  RegionAttributes = TZASC_REGION_ATTR_SECURITY(Security) |
+ TZASC_REGION_ATTR_SUBREG_DISABLE(SubregionDisableMask) |
+ TZASC_REGION_ATTR_SIZE(Size) |
+ TZASC_REGION_ATTR_ENABLE(Enabled);
+
   Region = (UINT32*)((UINTN)TzascBase + TZASC_REGIONS_REG + (RegionId * 0x10));
 
-  MmioWrite32((UINTN)(Region), LowAddress&0x8000)

Re: [edk2] [PATCH V2 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled

[Bhupesh SHARMA]

Hi Leif,

Thanks for the review.

On Mon, Jan 16, 2017 at 10:50 PM, Leif Lindholm
<leif.lindh...@linaro.org> wrote:
> On Tue, Dec 27, 2016 at 02:45:42AM +0530, Bhupesh Sharma wrote:
>> ARM TZASC-380 IP provides a mechanism to split memory regions being
>> protected via it into eight equal-sized sub-regions. A bit-setting
>> allows the corresponding subregion to be disabled.
>>
>> Several NXP/FSL SoCs support the TZASC-380 IP block and allow
>> the DDR connected via the TZASC to be partitioned into regions
>> having different security settings and also allow subregions
>> to be disabled.
>>
>> This patch enables this support and can be used for SoCs which
>> support such a partition of DDR regions.
>
> So, I am tempted to take this patch, but I should warn you that you
> are possibly now the only consumer of this driver. (Other platforms
> use ARM Trusted Firmware.)

Gulp. Understood :)

>> Details of the 'subregion_disable' register can be viewed here:
>> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0431c/CHDIGDCI.html
>>
>> Cc: Leif Lindholm <leif.lindh...@linaro.org>
>> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> Signed-off-by: Bhupesh Sharma <bhupesh.li...@gmail.com>
>
> Please add Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> as was in the v1 submission, then add your gmail.com submission below.

Sure.

>> Contributed-under: TianoCore Contribution Agreement 1.0
>
> Contributed-under: goes before Signed-off-by:.
>
>> ---
>>  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c| 14 
>> +++---
>>  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c | 10 --
>>  ArmPlatformPkg/Include/Drivers/ArmTrustzone.h  |  3 ++-
>>  3 files changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> index 6fa0774f59f8..42d731ea98c9 100644
>> --- 
>> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> +++ 
>> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
>> @@ -72,18 +72,18 @@ ArmPlatformSecTrustzoneInit (
>>// NOR Flash 0 non secure (BootMon)
>>TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_NOR0_BASE,0,
>> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>
>>// NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
>> secure firmware (sec_uefi.bin)
>>if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
>>  //Note: Your OS Kernel must be aware of the secure regions before to 
>> enable this region
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
>> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
>>} else {
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_NOR1_BASE,0,
>> -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>}
>>
>>// Base of SRAM. Only half of SRAM in Non Secure world
>> @@ -92,22 +92,22 @@ ArmPlatformSecTrustzoneInit (
>>  //Note: Your OS Kernel must be aware of the secure regions before to 
>> enable this region
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_SRAM_BASE,0,
>> -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW, 0);
>>} else {
>>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>>  ARM_VE_SMB_SRAM_BASE,0,
>> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
>> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
>>}
>>
>>// Memory Mapped Peripherals. All in non secure world
>>TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_PERIPH_BASE,0,
>> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
>> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
>>
>>// MotherBoard Peripherals and On-chip peripherals.
>>TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
>>ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
>> -  TZASC_REGI

Re: [edk2] [PATCH 1/1] AcpiTool: Fix minor casing and file path issues

[Bhupesh Sharma]

Hi Andrew,

On Sat, Jan 14, 2017 at 7:33 AM, Andrew Fish <af...@apple.com> wrote:
>
>> On Jan 12, 2017, at 11:56 PM, Bhupesh Sharma <bhsha...@redhat.com> wrote:
>>
>> This patch fixes some minor casing and file path issues
>
> Should we add a Linux builder with a case sensitive file system?
>
> macOS defaults to case insensitive but our build machines always use a case 
> sensitive filesystem so I've seen my share of case bugs
>
> One of the tricks we use on macOS is to create a DMG (disk image file) that 
> is case sensitive and then you mount it as /Volumes/Case and you don't have 
> to repartition your disk. I'm guessing you can do something similar in Linux.

I think that is doable but normal grep searches on linux (for
identifiers) without the -i parameter (search irrespective of the
case) do not return function names being used if the casing is not
handled properly.

In the case of AcpiTool the file names and paths are not too messed up
and the minor issues can be fixed by this patch.

But ofcourse if I am running a BoardPkg created using Windows tool on
Linux, I would be tempted to use a Mac like approach to get the stuff
to properly compile.

Regards,
Bhupesh

>
> Thanks,
>
> Andrew Fish
>
>> with the AcpiToolPkg from Yao Jiewen
>> (https://github.com/jyao1/EdkiiShellTool).
>>
>> This patch also adds AARCH64 as one of the supported architectures
>> on which AcpiTool can run.
>>
>> Compiled and tested this patch under the following environment:
>>
>> - Compiled for AARCH64 architecture using GCC4.9 toolchain from Linaro.
>> - Exercised the 'DumpACPI.efi' thus generated on Qemu for AARCH64 as an
>>  application.
>> - Able to dump all relevant ACPI tables.
>>
>> This patch is also available here for easy access:
>> https://github.com/bhupesh-sharma/EdkiiShellTool
>>
>> Cc: Ni Ruiyu <ruiyu...@intel.com>
>> Cc: Evan Lloyd <evan.ll...@arm.com>
>> Cc: Sami Mujawar <sami.muja...@arm.com>
>> Cc: Yao Jiewen <jiewen@intel.com>
>> Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> ---
>> AcpiToolPkg/AcpiToolPkg.dsc | 2 +-
>> AcpiToolPkg/DumpAcpi/DumpACPI.c | 2 +-
>> AcpiToolPkg/DumpAcpi/DumpACPI.h | 2 +-
>> AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c | 2 +-
>> AcpiToolPkg/DumpAcpi/DumpAcpiPSDT.c | 2 +-
>> AcpiToolPkg/DumpAcpi/DumpAcpiSSDT.c | 2 +-
>> AcpiToolPkg/Library/DumpAcpi/DumpAcpiDMARLib/DumpAcpiDMARLib.c  | 2 +-
>> .../Library/DumpAcpi/DumpAcpiTableFuncLib/DumpAcpiTableFuncLib.c| 6 
>> +++---
>> 8 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/AcpiToolPkg/AcpiToolPkg.dsc b/AcpiToolPkg/AcpiToolPkg.dsc
>> index 9943f7610315..c0fcec5b2518 100644
>> --- a/AcpiToolPkg/AcpiToolPkg.dsc
>> +++ b/AcpiToolPkg/AcpiToolPkg.dsc
>> @@ -17,7 +17,7 @@
>>   PLATFORM_VERSION   = 0.1
>>   DSC_SPECIFICATION  = 0x00010005
>>   OUTPUT_DIRECTORY   = Build/AcpiToolPkg
>> -  SUPPORTED_ARCHITECTURES= IA32|X64
>> +  SUPPORTED_ARCHITECTURES= IA32|X64|AARCH64
>>   BUILD_TARGETS  = DEBUG|RELEASE
>>   SKUID_IDENTIFIER   = DEFAULT
>>
>> diff --git a/AcpiToolPkg/DumpAcpi/DumpACPI.c 
>> b/AcpiToolPkg/DumpAcpi/DumpACPI.c
>> index 38cc804a72e9..5ea51e67a260 100644
>> --- a/AcpiToolPkg/DumpAcpi/DumpACPI.c
>> +++ b/AcpiToolPkg/DumpAcpi/DumpACPI.c
>> @@ -23,7 +23,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
>> EXPRESS OR IMPLIED.
>>
>> #include 
>>
>> -#include "DumpAcpi.h"
>> +#include "DumpACPI.h"
>>
>> #define RSDP_SIGN_DEFINITION SIGNATURE_32 ('R', 'S', 'D', 'P')
>>
>> diff --git a/AcpiToolPkg/DumpAcpi/DumpACPI.h 
>> b/AcpiToolPkg/DumpAcpi/DumpACPI.h
>> index 40c11e70f443..8307f50ec805 100644
>> --- a/AcpiToolPkg/DumpAcpi/DumpACPI.h
>> +++ b/AcpiToolPkg/DumpAcpi/DumpACPI.h
>> @@ -16,7 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
>> EXPRESS OR IMPLIED.
>>
>> #include 
>> #include 
>> -#include <IndustryStandard\Acpi.h>
>> +#include 
>>
>> #ifndef MAX_FILE_NAME_LEN
>> #define MAX_FILE_NAME_LEN  0x1000
>> diff --git a/AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c 
>> b/AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c
>> index 42541be92081..7

[edk2] [PATCH 1/1] ArmVirtPkg/ArmVirtQemu: Install BGRT ACPI table

[Bhupesh Sharma]

While debugging OS for ACPI BGRT support (especially on VMs),
it is very useful to have the EFI firmware to export the
ACPI BGRT table.

This patch tries to add this support in ArmVirtPkg.

Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Cc: Laszlo Ersek <ler...@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
---
 ArmVirtPkg/ArmVirtQemu.dsc   | 1 +
 ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
 ArmVirtPkg/ArmVirtQemuKernel.dsc | 1 +
 3 files changed, 3 insertions(+)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 0cae9968f4ea..8fe3c3816961 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -390,6 +390,7 @@
   #
   # ACPI Support
   #
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
 
   NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index a2e82b3179e8..cc5d12aaefea 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -145,6 +145,7 @@ READ_LOCK_STATUS   = TRUE
   # ACPI Support
   #
   INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+  INF 
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
 
   #
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index fe76c2263faa..aa40374745af 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -379,6 +379,7 @@
   #
   # ACPI Support
   #
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
   OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
 
   NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
-- 
2.7.4

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

Re: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

[Bhupesh SHARMA]

Hi All,

On Fri, Dec 23, 2016 at 7:01 AM, Yao, Jiewen  wrote:
> HI Even
> Thank you for the response.
>
> *Mike Kinney* is managing staging tree – he may help answer the question on 
> staging. ☺
>
> I am glad to co-work with you on that.
>
> Merry Christmas!
>
>
> Thank you
> Yao Jiewen
>
> From: Evan Lloyd [mailto:evan.ll...@arm.com]
> Sent: Friday, December 23, 2016 2:26 AM
> To: Yao, Jiewen ; Ni, Ruiyu ; 
> Carsey, Jaben ; Sami Mujawar 
> Cc: Carsey, Jaben ; edk2-de...@ml01.01.org; Leif 
> Lindholm ; ard.biesheu...@linaro.org
> Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables
>
>
> Hi Jiewen.
> I hope I have our forename there, not your surname - it can be difficult to 
> tell :-)
> I've trimmed a lot out  of the history below, for clarity.
>
>>
>>From: Yao, Jiewen [mailto:jiewen@intel.com]
>>Sent: 20 December 2016 16:35
>>To: Evan Lloyd; Ni, Ruiyu; Carsey, Jaben; Sami Mujawar
>>Cc: Carsey, Jaben; edk2-de...@ml01.01.org; 
>>Leif Lindholm; ard.biesheu...@linaro.org
>>Subject: RE: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables
>>
>>Thank you, Lloyd.
>>
>>Comment inline.
>>
> ...
>>[Jiewen] Got it.
>>As you mention, I hope it can be in SHELL spec, too.
>>
>>So that we can have a standard way to dump all table information.
>>
>>For X86 system, I have written similar tool to dump X86 related info.
>>I just check in to 
>>https://github.com/jyao1/EdkiiShellTool/tree/master/AcpiToolPkg.
>>It is also BSD license code. I tried by best to dump info for *all* the ACPI 
>>table.
>>But I do not validate ARM system. We complement to each other. ?
>
> Yes, we obviously need to get together over this.
>
>>...
>>[Jiewen] Let me summarize current status:
>>1)   We know there is strong requirement to dump ACPI table in UEFI shell 
>>environment, for debug purposes.
>>2)   UEFI shell specification does not contain any ACPI dump command. 
>>(Although it has SmbiosDump)
>>3)   ACPICA.ORG has sample code to dump ACPI.
>>> > >Binary can be downloaded from: https://acpica.org/downloads/uefi-support
>>> > >Source can be downloaded from: https://github.com/acpica/acpica
>>4)   This patch provides dump ACPI information with consistency check. 
>>But limitation is: it only supports the limited table on ARM platform. NO 
>>support for X86 platform.
>>5)   I have similar code to dump ACPI. But the limitation is: it only 
>>validated on X86 platform. It is not validated on ARM platform.
>>
>>
>>So I would like to propose:
>>1)   DOCUMENTATION: Can we co-work to submit an ECR for SHELL, to add 
>>AcpiDump command? So that people may get standard dump log in the future.
>
> This sounds fine, but I'd suggest getting it into the Shell spec is much lower
> priority than making the tool available.  We believe the checking aspect will
> help people detect errors at an early stage, so want to "get it out there".
>
>>2)   CODE: It seems both of our code is POC quality and has partial 
>>validation only. It might not be suitable to check in EDKII immediately
>>I would like to propose we co-work in EDKII staging tree - 
>>https://github.com/tianocore/edk2-staging/ (We have 4 features there.)
>
> That sounds excellent.  It will be a great thing to have ARM/Intel (or 
> Intel/ARM if you prefer) cooperation on this.
>
>>We can align our design, then I can help validate X86 and you can help 
>>validate ARM.
>>Then we can submit a complete patch to EDKII ShellPkg.
>>
>>What about your idea?
>
> I think this potentially helps everyone in UEFI.
> Sadly, we are about to shut down for Christmas, and will not be back until 
> 2017-01-03.  (I'm not really sad about it.)
> From looking at your code, I think we will be able to learn a lot about EDK2 
> programming from you.
> I suggest we can discuss the design and code merge aspects off list. (And 
> make details of the results public in condensed form.)
>
> Do I need to ask anyone to give me commit rights to 
> https://github.com/tianocore/edk2-staging?
> Or is it pull request based?
>
> Regards, and Merry Christmas,
> Evan
>
>>
>  Thank you
>>> Yao Jiewen
>>

I needed a ACPI table dump tool for fixing a issue with BGRT table
being passed to a x86_64 and AARCH64 Linux kernel. I just happened to
evaluate and use both the excellent tools:

[1]. https://github.com/jyao1/EdkiiShellTool from Yao Jiewen
[2]. https://github.com/EvanLloyd/tianocore/tree/651_acpiview_v1 from Evan

Since my use case was primarily to dump the BGRT ACPI table being
passed to the kernel although I tried both the tool flavours, I found
[1] more powerful in dumping the ACPI tables.

Since I needed this tool to work on Qemu on AARCH64 as well. so I
compiled [1] using AARCH64, GCC4.9 toolchain and after some changes -
which I have submitted to 

[edk2] [PATCH 1/1] AcpiTool: Fix minor casing and file path issues

[Bhupesh Sharma]

This patch fixes some minor casing and file path issues
with the AcpiToolPkg from Yao Jiewen
(https://github.com/jyao1/EdkiiShellTool).

This patch also adds AARCH64 as one of the supported architectures
on which AcpiTool can run.

Compiled and tested this patch under the following environment:

- Compiled for AARCH64 architecture using GCC4.9 toolchain from Linaro.
- Exercised the 'DumpACPI.efi' thus generated on Qemu for AARCH64 as an
  application.
- Able to dump all relevant ACPI tables.

This patch is also available here for easy access:
https://github.com/bhupesh-sharma/EdkiiShellTool

Cc: Ni Ruiyu <ruiyu...@intel.com>
Cc: Evan Lloyd <evan.ll...@arm.com>
Cc: Sami Mujawar <sami.muja...@arm.com>
Cc: Yao Jiewen <jiewen@intel.com>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
---
 AcpiToolPkg/AcpiToolPkg.dsc | 2 +-
 AcpiToolPkg/DumpAcpi/DumpACPI.c | 2 +-
 AcpiToolPkg/DumpAcpi/DumpACPI.h | 2 +-
 AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c | 2 +-
 AcpiToolPkg/DumpAcpi/DumpAcpiPSDT.c | 2 +-
 AcpiToolPkg/DumpAcpi/DumpAcpiSSDT.c | 2 +-
 AcpiToolPkg/Library/DumpAcpi/DumpAcpiDMARLib/DumpAcpiDMARLib.c  | 2 +-
 .../Library/DumpAcpi/DumpAcpiTableFuncLib/DumpAcpiTableFuncLib.c| 6 +++---
 8 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/AcpiToolPkg/AcpiToolPkg.dsc b/AcpiToolPkg/AcpiToolPkg.dsc
index 9943f7610315..c0fcec5b2518 100644
--- a/AcpiToolPkg/AcpiToolPkg.dsc
+++ b/AcpiToolPkg/AcpiToolPkg.dsc
@@ -17,7 +17,7 @@
   PLATFORM_VERSION   = 0.1
   DSC_SPECIFICATION  = 0x00010005
   OUTPUT_DIRECTORY   = Build/AcpiToolPkg
-  SUPPORTED_ARCHITECTURES= IA32|X64
+  SUPPORTED_ARCHITECTURES= IA32|X64|AARCH64
   BUILD_TARGETS  = DEBUG|RELEASE
   SKUID_IDENTIFIER   = DEFAULT
 
diff --git a/AcpiToolPkg/DumpAcpi/DumpACPI.c b/AcpiToolPkg/DumpAcpi/DumpACPI.c
index 38cc804a72e9..5ea51e67a260 100644
--- a/AcpiToolPkg/DumpAcpi/DumpACPI.c
+++ b/AcpiToolPkg/DumpAcpi/DumpACPI.c
@@ -23,7 +23,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 
-#include "DumpAcpi.h"
+#include "DumpACPI.h"
 
 #define RSDP_SIGN_DEFINITION SIGNATURE_32 ('R', 'S', 'D', 'P')
  
diff --git a/AcpiToolPkg/DumpAcpi/DumpACPI.h b/AcpiToolPkg/DumpAcpi/DumpACPI.h
index 40c11e70f443..8307f50ec805 100644
--- a/AcpiToolPkg/DumpAcpi/DumpACPI.h
+++ b/AcpiToolPkg/DumpAcpi/DumpACPI.h
@@ -16,7 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include 
 #include 
-#include <IndustryStandard\Acpi.h>
+#include 
 
 #ifndef MAX_FILE_NAME_LEN
 #define MAX_FILE_NAME_LEN  0x1000
diff --git a/AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c 
b/AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c
index 42541be92081..764f4b6470ba 100644
--- a/AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c
+++ b/AcpiToolPkg/DumpAcpi/DumpAcpiDSDT.c
@@ -24,7 +24,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 
-#include "DumpAcpi.h"
+#include "DumpACPI.h"
 
 VOID
 EFIAPI
diff --git a/AcpiToolPkg/DumpAcpi/DumpAcpiPSDT.c 
b/AcpiToolPkg/DumpAcpi/DumpAcpiPSDT.c
index 8878d3f6b594..b28e90f18172 100644
--- a/AcpiToolPkg/DumpAcpi/DumpAcpiPSDT.c
+++ b/AcpiToolPkg/DumpAcpi/DumpAcpiPSDT.c
@@ -24,7 +24,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 
-#include "DumpAcpi.h"
+#include "DumpACPI.h"
 
 VOID
 EFIAPI
diff --git a/AcpiToolPkg/DumpAcpi/DumpAcpiSSDT.c 
b/AcpiToolPkg/DumpAcpi/DumpAcpiSSDT.c
index 0a268eb136ab..c49b84c18ee0 100644
--- a/AcpiToolPkg/DumpAcpi/DumpAcpiSSDT.c
+++ b/AcpiToolPkg/DumpAcpi/DumpAcpiSSDT.c
@@ -24,7 +24,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 
-#include "DumpAcpi.h"
+#include "DumpACPI.h"
 
 VOID
 EFIAPI
diff --git a/AcpiToolPkg/Library/DumpAcpi/DumpAcpiDMARLib/DumpAcpiDMARLib.c 
b/AcpiToolPkg/Library/DumpAcpi/DumpAcpiDMARLib/DumpAcpiDMARLib.c
index 865a213fa706..7d6d8e0b0194 100644
--- a/AcpiToolPkg/Library/DumpAcpi/DumpAcpiDMARLib/DumpAcpiDMARLib.c
+++ b/AcpiToolPkg/Library/DumpAcpi/DumpAcpiDMARLib/DumpAcpiDMARLib.c
@@ -18,7 +18,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
-#include 
+#include 
 
 VOID
 DumpDmarDeviceScopeEntry (
diff --git 
a/AcpiToolPkg/Library/DumpAcpi/DumpAcpiTableFuncLib/DumpAcpiTableFuncLib.c 
b/AcpiToolPkg/Library/DumpAcpi/DumpAcpiTableFuncLib/DumpAcpiTableFuncLib.c
index a52a718bfa40..9036926065cb 100644
--- a/AcpiToolPkg/Library/DumpAcpi/DumpAcpiTableFuncLib/DumpAcpiTableFuncLib.c

[edk2] [PATCH V2 1/1] OvmfPkg: Install BGRT ACPI table

[Bhupesh Sharma]

While debugging OS for ACPI BGRT support (especially on VMs),
it is very useful to have the EFI firmware (OVMF in most cases
which use Tianocore) to export the ACPI BGRT table.

This patch tries to add this support in OvmfPkg.

Tested this patch in the following environments:

1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host:
   - Ensured that the BGRT logo is properly prepared and
 can be viewed with user-space tools (like 'Gwenview' on KDE,
 for example):

 $ file /sys/firmware/acpi/bgrt/image
 /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x
 58 x 24

2. On a Windows-10 VM Guest running on a Fedora-24 Host:
   - Ensured that the BGRT ACPI table is properly prepared and can be
 read with freeware tool like FirmwareTablesView:

 ==
 Signature : BGRT
 Firmware Provider : ACPI
 Length: 56
 Revision  : 1
 Checksum  : 129
 OEM ID: INTEL
 OEM Table ID  : EDK2
 OEM Revision  : 0x0002
 Creator ID: 0x20202020
 Creator Revision  : 0x0113
 Description   :
 ==

Cc: Jordan Justen <jordan.l.jus...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
---
Changes since v1:
 - Improved the commit log and cc list as per Laszlo's suggestions.
 - Also tested the patch on a Windows 10 VM guest to make sure that
   the BGRT table is properly created.

 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 81f752121f2f..e97f7f0262d9 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -679,6 +679,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 2a5b211a3666..34d57a6079cc 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f7855b6e5ea4..8e3e04c135cc 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -688,6 +688,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 1c7df210ddd5..df55c2b21021 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e933a41ab98e..6ec3fe050dc7 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -686,6 +686,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 3bb11cbf7377..5e2e1dfaf5a9 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF  
MdeM

Re: [edk2] [PATCH 1/1] Add BGRT ACPI table inclusion support in OVMF

[Bhupesh SHARMA]

Hi Laszlo,

Many thanks for taking out the time to review this.

On Tue, Jan 3, 2017 at 8:16 PM, Laszlo Ersek <ler...@redhat.com> wrote:
> On 12/26/16 06:25, Bhupesh Sharma wrote:
>> During debugging Linux kernel for ACPI BGRT support
>> (especially on VMs), it is sometimes very useful to have
>> the EFI firmware (OVMF in most cases which use Tianocore)
>> to export the ACPI BGRT table.
>>
>> This patch tries to add this support.
>>
>> I have tested this patch on a RHEL7.3 and Fedora-25 KVM
>> and ensured that the BGRT logo is properly prepared and
>> can be viewed with user-space tools (like 'Gwenview' on KDE,
>> for example):
>>
>> $ file /sys/firmware/acpi/bgrt/image
>> /sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x
>> 24
>>
>> Cc: Laszlo Ersek <ler...@redhat.com>
>> Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> ---
>>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>>  OvmfPkg/OvmfPkgIa32.fdf| 1 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>>  OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
>>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>>  OvmfPkg/OvmfPkgX64.fdf | 1 +
>>  6 files changed, 6 insertions(+)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 81f7521..e97f7f0 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -679,6 +679,7 @@
>>OvmfPkg/AcpiTables/AcpiTables.inf
>>MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
>>
>> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
>> +  
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>>
>>#
>># Network Support
>> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
>> index 2a5b211..34d57a6 100644
>> --- a/OvmfPkg/OvmfPkgIa32.fdf
>> +++ b/OvmfPkg/OvmfPkgIa32.fdf
>> @@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>  INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
>>  INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
>>  INF  
>> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
>> +INF  
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>>
>>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index f7855b6..8e3e04c 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -688,6 +688,7 @@
>>OvmfPkg/AcpiTables/AcpiTables.inf
>>MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
>>
>> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
>> +  
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>>
>>#
>># Network Support
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
>> index 1c7df21..df55c2b 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
>> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
>> @@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>  INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
>>  INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
>>  INF  
>> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
>> +INF  
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>>
>>  INF  FatPkg/EnhancedFatDxe/Fat.inf
>>
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index e933a41..6ec3fe0 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -686,6 +686,7 @@
>>OvmfPkg/AcpiTables/AcpiTables.inf
>>MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
>>
>> MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
>> +  
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>>
>>#
>># Network Support
>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
>> index 3bb11cb..5e2e1df 100644
>> --- a/OvmfPkg/OvmfPkgX64.fdf
>> +++ b/OvmfPkg/OvmfPkgX64.fdf
>> @@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
>>  INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
>>  INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe

[edk2] [PATCH V2 1/1] ArmPlatformPkg/TZASC: Allow specifying subregions to be disabled

[Bhupesh Sharma]

ARM TZASC-380 IP provides a mechanism to split memory regions being
protected via it into eight equal-sized sub-regions. A bit-setting
allows the corresponding subregion to be disabled.

Several NXP/FSL SoCs support the TZASC-380 IP block and allow
the DDR connected via the TZASC to be partitioned into regions
having different security settings and also allow subregions
to be disabled.

This patch enables this support and can be used for SoCs which
support such a partition of DDR regions.

Details of the 'subregion_disable' register can be viewed here:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0431c/CHDIGDCI.html

Cc: Leif Lindholm <leif.lindh...@linaro.org>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
Signed-off-by: Bhupesh Sharma <bhupesh.li...@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
---
 .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c| 14 +++---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c | 10 --
 ArmPlatformPkg/Include/Drivers/ArmTrustzone.h  |  3 ++-
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
index 6fa0774f59f8..42d731ea98c9 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
@@ -72,18 +72,18 @@ ArmPlatformSecTrustzoneInit (
   // NOR Flash 0 non secure (BootMon)
   TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
   ARM_VE_SMB_NOR0_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
 
   // NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
secure firmware (sec_uefi.bin)
   if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE,0,
-TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
   }
 
   // Base of SRAM. Only half of SRAM in Non Secure world
@@ -92,22 +92,22 @@ ArmPlatformSecTrustzoneInit (
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW, 0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW, 0);
   }
 
   // Memory Mapped Peripherals. All in non secure world
   TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
   ARM_VE_SMB_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW, 0);
 
   // MotherBoard Peripherals and On-chip peripherals.
   TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
   ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW, 0);
 }
 
 /**
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
index 070c0dcb5d4d..c99c16d4c442 100644
--- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
+++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
@@ -87,20 +87,26 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN SubregionDisableMask
   )
 {
   UINT32* Region;
+  UINT32  RegionAttributes;
 
   if (RegionId > TZASCGetNumRegions(TzascBase)) {
 return EFI_INVALID_PARAMETER;
   }
 
+  RegionAttributes = ((Security & 0xF) << 28) |
+ ((SubregionDisableMask & 0xFF) << 8) |
+ ((Size & 0x3F) << 1) | (Enabled & 0x1);
+
   Region = (UINT32*)((UINTN)TzascBase + TZASC_REGIONS_REG + (RegionId * 0x10));
 
   MmioWrite32((UINTN)(Region), LowAddress&0x8000);
   MmioWrite32((UINTN)(Region+1), HighAddress);
-  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | ((Size & 0x3F) << 
1) | (Enabled & 0x1));
+  MmioWrite32((UINTN)(Region+2), RegionAttributes);
 
   return EFI_SUCCESS;
 }
d

[edk2] [PATCH 1/1] Add BGRT ACPI table inclusion support in OVMF

[Bhupesh Sharma]

During debugging Linux kernel for ACPI BGRT support
(especially on VMs), it is sometimes very useful to have
the EFI firmware (OVMF in most cases which use Tianocore)
to export the ACPI BGRT table.

This patch tries to add this support.

I have tested this patch on a RHEL7.3 and Fedora-25 KVM
and ensured that the BGRT logo is properly prepared and
can be viewed with user-space tools (like 'Gwenview' on KDE,
for example):

$ file /sys/firmware/acpi/bgrt/image
/sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x 58 x
24

Cc: Laszlo Ersek <ler...@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsha...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
---
 OvmfPkg/OvmfPkgIa32.dsc| 1 +
 OvmfPkg/OvmfPkgIa32.fdf| 1 +
 OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
 OvmfPkg/OvmfPkgIa32X64.fdf | 1 +
 OvmfPkg/OvmfPkgX64.dsc | 1 +
 OvmfPkg/OvmfPkgX64.fdf | 1 +
 6 files changed, 6 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 81f7521..e97f7f0 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -679,6 +679,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index 2a5b211..34d57a6 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f7855b6..8e3e04c 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -688,6 +688,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 1c7df21..df55c2b 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e933a41..6ec3fe0 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -686,6 +686,7 @@
   OvmfPkg/AcpiTables/AcpiTables.inf
   MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
   MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
   #
   # Network Support
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 3bb11cb..5e2e1df 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -278,6 +278,7 @@ INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
 INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
+INF  
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
 
 INF  FatPkg/EnhancedFatDxe/Fat.inf
 
-- 
2.7.4

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

Re: [edk2] EDK2 master build failure

[Bhupesh Sharma]

Thanks Liming.

I will try building this on a native Linux Host rather than VirtualBox.

Regards,
Bhupesh

> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Friday, November 18, 2016 10:45 AM
> 
> In Misc.py, it import string class. But, in the same directory, there
> is source file String.py. Seemly, python interpreter wrongly imports
> String.py and cause this issue. This issue may happen on the case
> insensitive file system.
> 
> We meet with such issue before. We set up virtual machine on windows OS
> to run Linux build, edk2 source code is downloaded in windows OS and
> shared to virtual linux machine, then do linux build will cause such
> issue. To avoid it, we download edk2 source code in Linux machine and
> build them pass.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of
> > Bhupesh Sharma
> > Sent: Friday, November 18, 2016 4:12 AM
> > To: edk2-devel@lists.01.org
> > Subject: [edk2] EDK2 master build failure
> >
> > Hi EDK2 experts,
> >
> > I have just rebased my code on the latest EDK2 master branch and now
> > when I am trying to compile the same I am getting the following
> errors
> > (for my ARMv8 build):
> >
> > # ./build.sh RELEASE clean; ./build.sh RELEASE
> > ..
> > Welcome to LS1043A UEFI Build environment
> > ..
> > Cleaning up the build directory '../../../../Build/LS1043aRdb/'..
> > ..
> > Welcome to LS1043A UEFI Build environment
> > ..
> > Initializing workspace
> > Loading previous configuration from /media/sf_VBox-
> > Share/LS1043A/edk2/Conf/BuildEnv.sh
> > WORKSPACE: /media/sf_VBox-Share/LS1043A/edk2
> > EDK_TOOLS_PATH: /media/sf_VBox-Share/LS1043A/edk2/BaseTools
> > CONF_PATH: /media/sf_VBox-Share/LS1043A/edk2/Conf
> > Copying $EDK_TOOLS_PATH/Conf/tools_def.template
> >  to /media/sf_VBox-Share/LS1043A/edk2/Conf/tools_def.txt
> > Build environment:
> > Linux-4.2.0-27-generic-x86_64-with-Ubuntu-14.04-trusty
> > Build start time: 01:19:30, Nov.18 2016
> >
> > WORKSPACE= /media/sf_VBox-Share/LS1043A/edk2
> > ECP_SOURCE   = /media/sf_VBox-
> > Share/LS1043A/edk2/EdkCompatibilityPkg
> > EDK_SOURCE   = /media/sf_VBox-
> > Share/LS1043A/edk2/EdkCompatibilityPkg
> > EFI_SOURCE   = /media/sf_VBox-
> > Share/LS1043A/edk2/EdkCompatibilityPkg
> > EDK_TOOLS_PATH   = /media/sf_VBox-Share/LS1043A/edk2/BaseTools
> > CONF_PATH= /media/sf_VBox-Share/LS1043A/edk2/Conf
> >
> >
> > Architecture(s)  = AARCH64
> > Build target = RELEASE
> > Toolchain= GCC49
> >
> > Active Platform  = /media/sf_VBox-
> > Share/LS1043A/edk2/OpenPlatformPkg/Platforms/Nxp/LS1043aRdb/LS1043a
> > RdbPkg.dsc
> > Flash Image Definition   = /media/sf_VBox-
> > Share/LS1043A/edk2/OpenPlatformPkg/Platforms/Nxp/LS1043aRdb/LS1043a
> > RdbPkg.fdf
> >
> > Processing meta-data ...
> >
> >
> > build.py...
> >  : error C0DE: Unknown fatal error when processing [/media/sf_VBox-
> > Share/LS1043A/edk2/MdePkg/MdePkg.dec]
> >
> > (Please send email to edk2-devel@lists.01.org for help, attaching
> > following call stack trace!)
> >
> > (Python 2.7.6 on linux2) Traceback (most recent call last):
> >   File "/media/sf_VBox-
> >
> Share/LS1043A/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python
> > /build/build.py", line 2276, in Main
> > MyBuild.Launch()
> >   File "/media/sf_VBox-
> >
> Share/LS1043A/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python
> > /build/build.py", line 2028, in Launch
> > self._MultiThreadBuildPlatform()
> >   File "/media/sf_VBox-
> >
> Share/LS1043A/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python
> > /build/build.py", line 1823, in _MultiThreadBuildPlatform
> > self.Progress
> >   File "/media/sf_VBox-
> > Share/LS1043A/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line
> > 176, in __new__
> > if not AutoGenObject._Init(Workspace, MetaFile, Target,
> Toolchain,
> > Arch, *args, **kwargs):
> >   File "/media/sf_VBox-
> > Share/LS1043A/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line
> > 464, in _Init
> > for key in BuildData.Pcds:
> >   File "/media/sf_VBox-
> > Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/Workspac

[edk2] EDK2 master build failure

[Bhupesh Sharma]

Hi EDK2 experts,

I have just rebased my code on the latest EDK2 master branch and now when I am 
trying to compile the same
I am getting the following errors (for my ARMv8 build):

# ./build.sh RELEASE clean; ./build.sh RELEASE
..
Welcome to LS1043A UEFI Build environment
..
Cleaning up the build directory '../../../../Build/LS1043aRdb/'..
..
Welcome to LS1043A UEFI Build environment
..
Initializing workspace
Loading previous configuration from 
/media/sf_VBox-Share/LS1043A/edk2/Conf/BuildEnv.sh
WORKSPACE: /media/sf_VBox-Share/LS1043A/edk2
EDK_TOOLS_PATH: /media/sf_VBox-Share/LS1043A/edk2/BaseTools
CONF_PATH: /media/sf_VBox-Share/LS1043A/edk2/Conf
Copying $EDK_TOOLS_PATH/Conf/tools_def.template
 to /media/sf_VBox-Share/LS1043A/edk2/Conf/tools_def.txt
Build environment: Linux-4.2.0-27-generic-x86_64-with-Ubuntu-14.04-trusty
Build start time: 01:19:30, Nov.18 2016

WORKSPACE= /media/sf_VBox-Share/LS1043A/edk2
ECP_SOURCE   = /media/sf_VBox-Share/LS1043A/edk2/EdkCompatibilityPkg
EDK_SOURCE   = /media/sf_VBox-Share/LS1043A/edk2/EdkCompatibilityPkg
EFI_SOURCE   = /media/sf_VBox-Share/LS1043A/edk2/EdkCompatibilityPkg
EDK_TOOLS_PATH   = /media/sf_VBox-Share/LS1043A/edk2/BaseTools
CONF_PATH= /media/sf_VBox-Share/LS1043A/edk2/Conf


Architecture(s)  = AARCH64
Build target = RELEASE
Toolchain= GCC49

Active Platform  = 
/media/sf_VBox-Share/LS1043A/edk2/OpenPlatformPkg/Platforms/Nxp/LS1043aRdb/LS1043aRdbPkg.dsc
Flash Image Definition   = 
/media/sf_VBox-Share/LS1043A/edk2/OpenPlatformPkg/Platforms/Nxp/LS1043aRdb/LS1043aRdbPkg.fdf

Processing meta-data ... 


build.py...
 : error C0DE: Unknown fatal error when processing 
[/media/sf_VBox-Share/LS1043A/edk2/MdePkg/MdePkg.dec]

(Please send email to edk2-devel@lists.01.org for help, attaching following 
call stack trace!)

(Python 2.7.6 on linux2) Traceback (most recent call last):
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 2276, in Main
MyBuild.Launch()
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 2028, in Launch
self._MultiThreadBuildPlatform()
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
 line 1823, in _MultiThreadBuildPlatform
self.Progress
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 176, in __new__
if not AutoGenObject._Init(Workspace, MetaFile, Target, Toolchain, Arch, 
*args, **kwargs):
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", 
line 464, in _Init
for key in BuildData.Pcds:
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
 line 2469, in _GetPcds
self._Pcds.update(self._GetPcd(MODEL_PCD_FEATURE_FLAG))
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
 line 2583, in _GetPcd
if TokenSpaceGuid not in self.Guids:
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
 line 2368, in _GetGuids
Value = GuidValue(CName, self.Packages, self.MetaFile.Path)
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Common/Misc.py", 
line 804, in GuidValue
GuidKeys = P.Guids.keys()
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py",
 line 1482, in _GetGuid
RecordList = self._RawData[MODEL_EFI_GUID, self._Arch]
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 239, in __getitem__
self.Start()
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 1671, in Start
self._SectionParser[self._SectionType[0]](self)
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 43, in MacroParser
Parser(self)
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Workspace/MetaFileParser.py",
 line 1896, in _PcdParser
IsValid, Cause = CheckPcdDatum(ValueList[1], ValueList[0])
  File 
"/media/sf_VBox-Share/LS1043A/edk2/BaseTools/Source/Python/Common/Misc.py", 
line 1639, in CheckPcdDatum
Printset = set(string.printable)
AttributeError: 'module' object has no attribute 'printable'


- Failed -
Build end time: 01:19:43,

Is this a known issue?

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

Re: [edk2] [RESEND PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

[Bhupesh Sharma]

Hi Ard,

> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, October 17, 2016 7:46 PM
> 
> On 17 October 2016 at 14:25, Leif Lindholm <leif.lindh...@linaro.org>
> wrote:
> > On Mon, Oct 17, 2016 at 10:18:01AM +, Bhupesh Sharma wrote:
> >> Hi Ard, Leif,
> >>
> >> Any comments on this patch ?
> >
> > You didn't cc me before :)
> >
> > But more importantly, I don't really have any platform to test this
> > on, so I could use a Tested-by: from someone who does. Evan, do you?
> >
> >> > From: Bhupesh Sharma [mailto:bhupesh.sha...@nxp.com]
> >> > Sent: Friday, October 14, 2016 4:40 PM
> >> >
> >> > ARM TZASC-380 IP provides a mechanism to split memory regions
> being
> >> > protected via it into eight equal-sized sub-regions, with a bit
> >> > setting allowing the corresponding subregion to be disabled.
> >> >
> >> > Several NXP/FSL SoCs support the TZASC-380 IP block and allow the
> >> > DDR connected via the TZASC to be partitioned into regions having
> >> > different security settings.
> >> >
> >> > This patch enables this support and can be used for SoCs which
> >> > support such partition of DDR regions.
> >> >
> >> > Details of the 'subregion_disable'
> >
> > This is not actually what the register is called in the link you're
> > providing.
> >
> >> > register can be viewed here:
> >> >
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431
> >> > c/CJ
> >> > ABCFHB.html
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.0
> >> > Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> >> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> >> > ---
> >> >  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21
> >> > ++---
> >> >  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
> >> >  ArmPlatformPkg/Include/Drivers/ArmTrustzone.h   |  3 ++-
> >> >  3 files changed, 19 insertions(+), 10 deletions(-)
> >> >
> >> > diff --git
> >> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA
> >> > 9x4S
> >> > ec.c
> >> >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA
> >> > 9x4S
> >> > ec.c
> >> > index 6fa0774..d358d65 100644
> >> > ---
> >> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA
> >> > 9x4S
> >> > ec.c
> >> > +++
> >> >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA
> >> > 9
> >> > +++ x4Sec.c
> >> > @@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
> >> >// NOR Flash 0 non secure (BootMon)
> >> >TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
> >> >ARM_VE_SMB_NOR0_BASE,0,
> >> > -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> >> > +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> >> > +  0);
> >> >
> >> >// NOR Flash 1. The first half of the NOR Flash1 must be secure
> >> > for the secure firmware (sec_uefi.bin)
> >> >if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
> >> >  //Note: Your OS Kernel must be aware of the secure regions
> >> > before to enable this region
> >> >  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
> >> >  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
> >> > -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> >> > +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> >> > +   0);
> >
> > TAB used (convert to spaces).
> >
> >> >} else {
> >> >  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
> >> >  ARM_VE_SMB_NOR1_BASE,0,
> >> > -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> >> > +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> >> > +   0);
> >
> > TAB used (convert to spaces).
> >
> >> >}
> >> >
> >> >// Base of SRAM. Only half of SRAM in Non Secure world @@ -
> 92,22
> >> > +95,26 @@ ArmPlatformSecTrustzoneInit (
> >> >  //Note: Your OS Ke

Re: [edk2] [RESEND PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

[Bhupesh Sharma]

Hi Leif,

Thanks for the review.

Please see my replies in-line.

> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Monday, October 17, 2016 6:55 PM
> 
> On Mon, Oct 17, 2016 at 10:18:01AM +0000, Bhupesh Sharma wrote:
> > Hi Ard, Leif,
> >
> > Any comments on this patch ?
> 
> You didn't cc me before :)
> 
> But more importantly, I don't really have any platform to test this on,
> so I could use a Tested-by: from someone who does. Evan, do you?
> 
> > > From: Bhupesh Sharma [mailto:bhupesh.sha...@nxp.com]
> > > Sent: Friday, October 14, 2016 4:40 PM
> > >
> > > ARM TZASC-380 IP provides a mechanism to split memory regions being
> > > protected via it into eight equal-sized sub-regions, with a bit
> > > setting allowing the corresponding subregion to be disabled.
> > >
> > > Several NXP/FSL SoCs support the TZASC-380 IP block and allow the
> > > DDR connected via the TZASC to be partitioned into regions having
> > > different security settings.
> > >
> > > This patch enables this support and can be used for SoCs which
> > > support such partition of DDR regions.
> > >
> > > Details of the 'subregion_disable'
> 
> This is not actually what the register is called in the link you're
> providing.
> 
> > > register can be viewed here:
> > >
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c
> > > /CJ
> > > ABCFHB.html
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> > > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> > > ---
> > >  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21
> > > ++---
> > >  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
> > >  ArmPlatformPkg/Include/Drivers/ArmTrustzone.h   |  3 ++-
> > >  3 files changed, 19 insertions(+), 10 deletions(-)
> > >
> > > diff --git
> > >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> > > x4S
> > > ec.c
> > >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> > > x4S
> > > ec.c
> > > index 6fa0774..d358d65 100644
> > > ---
> > >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> > > x4S
> > > ec.c
> > > +++
> > >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> > > +++ x4Sec.c
> > > @@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
> > >// NOR Flash 0 non secure (BootMon)
> > >TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
> > >ARM_VE_SMB_NOR0_BASE,0,
> > > -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> > > +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> > > +  0);
> > >
> > >// NOR Flash 1. The first half of the NOR Flash1 must be secure
> > > for the secure firmware (sec_uefi.bin)
> > >if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
> > >  //Note: Your OS Kernel must be aware of the secure regions
> > > before to enable this region
> > >  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
> > >  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
> > > -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> > > +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> > > + 0);
> 
> TAB used (convert to spaces).

Ok.
 
> > >} else {
> > >  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
> > >  ARM_VE_SMB_NOR1_BASE,0,
> > > -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> > > +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> > > + 0);
> 
> TAB used (convert to spaces).

Ok.
 
> > >}
> > >
> > >// Base of SRAM. Only half of SRAM in Non Secure world @@ -92,22
> > > +95,26 @@ ArmPlatformSecTrustzoneInit (
> > >  //Note: Your OS Kernel must be aware of the secure regions
> > > before to enable this region
> > >  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
> > >  ARM_VE_SMB_SRAM_BASE,0,
> > > -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
> > > +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
> > > + 0);
> 
> TAB used (convert to spaces).

Ok.
 
> > >} else {
> > >  TZASCSetReg

Re: [edk2] [RESEND PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

[Bhupesh Sharma]

Hi Ard, Leif,

Any comments on this patch ?

> From: Bhupesh Sharma [mailto:bhupesh.sha...@nxp.com]
> Sent: Friday, October 14, 2016 4:40 PM
> 
> ARM TZASC-380 IP provides a mechanism to split memory regions being
> protected via it into eight equal-sized sub-regions, with a bit setting
> allowing the corresponding subregion to be disabled.
> 
> Several NXP/FSL SoCs support the TZASC-380 IP block and allow the DDR
> connected via the TZASC to be partitioned into regions having different
> security settings.
> 
> This patch enables this support and can be used for SoCs which support
> such partition of DDR regions.
> 
> Details of the 'subregion_disable' register can be viewed here:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJ
> ABCFHB.html
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21
> ++---
>  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
>  ArmPlatformPkg/Include/Drivers/ArmTrustzone.h   |  3 ++-
>  3 files changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> index 6fa0774..d358d65 100644
> ---
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> +++
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> +++ x4Sec.c
> @@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
>// NOR Flash 0 non secure (BootMon)
>TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
>ARM_VE_SMB_NOR0_BASE,0,
> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
> 
>// NOR Flash 1. The first half of the NOR Flash1 must be secure for
> the secure firmware (sec_uefi.bin)
>if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
>  //Note: Your OS Kernel must be aware of the secure regions before
> to enable this region
>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>} else {
>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_NOR1_BASE,0,
> -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>}
> 
>// Base of SRAM. Only half of SRAM in Non Secure world @@ -92,22
> +95,26 @@ ArmPlatformSecTrustzoneInit (
>  //Note: Your OS Kernel must be aware of the secure regions before
> to enable this region
>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_SRAM_BASE,0,
> -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>} else {
>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_SRAM_BASE,0,
> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>}
> 
>// Memory Mapped Peripherals. All in non secure world
>TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
>ARM_VE_SMB_PERIPH_BASE,0,
> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
> 
>// MotherBoard Peripherals and On-chip peripherals.
>TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
>ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
> -  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
>  }
> 
>  /**
> diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> index 070c0dc..5cd41ef 100644
> --- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> +++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> @@ -87,7 +87,8 @@ TZASCSetRegion (
>IN  UINTN LowAddress,
>IN  UINTN HighAddress,
>IN  UINTN Size,
> -  IN  UINTN Security
> +  IN  UINTN Security,
> +  IN  UINTN SubregionDisableMask
>)
>  {
>UINT32* Region;
> @@ -100,7 +101,7 @@ TZASCSetRegion (
> 
>MmioWrite32((UINTN)(Region), LowAddress&am

Re: [edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

[Bhupesh Sharma]

Hi Laszlo,

> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Friday, October 14, 2016 5:37 PM
> 
> On 10/14/16 11:33, Bhupesh Sharma wrote:
> > Various IPs on NXP/FSL SoCs having ARM64 cores have big-endian MMIO
> > interfaces.
> >
> > This implies that a byte-swap operation is needed to read/write such
> > BE MMIO registers from the LE ARM64 cores.
> >
> > This patch adds the support for the same.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
> > Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> > ---
> >  MdePkg/Include/Library/IoLib.h   | 364
> 
> >  MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c | 479
> > +++
> >  2 files changed, 843 insertions(+)
> 
> I think this is both overkill and incomplete, at the same time :)
> 
> - Incomplete because only one IoLib instance gets the implementation.

Agree, but do we have an example of similar BE MMIO IPs on other
Architectures/soc? I was only aware of NXP/FSL having such MMIO
interfaces as the IPs have been reused from PPC SoC, which used
to have a BE core and hence did not require a SwapByte.
 
> - Overkill because you can easily use the SwapBytes16, SwapBytes32,
> SwapBytes64 functions -- also from BaseLib --, for transforming
> MmioWrite arguments and MmioRead results.
> 

Yes, but that means at every IP driver needs to especially carry such
arguments and transform the results. That might be an overkill.

We already have similar implementations MMIO implementations in Linux for e.g.
http://lxr.free-electrons.com/source/include/asm-generic/io.h#L642

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

[edk2] [RESEND PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

[Bhupesh Sharma]

ARM TZASC-380 IP provides a mechanism to split memory regions being
protected via it into eight equal-sized sub-regions,
with a bit setting allowing the corresponding subregion to be disabled.

Several NXP/FSL SoCs support the TZASC-380 IP block and allow
the DDR connected via the TZASC to be partitioned into regions
having different security settings.

This patch enables this support and can be used for SoCs which
support such partition of DDR regions.

Details of the 'subregion_disable' register can be viewed here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJABCFHB.html

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21 ++---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
 ArmPlatformPkg/Include/Drivers/ArmTrustzone.h   |  3 ++-
 3 files changed, 19 insertions(+), 10 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
index 6fa0774..d358d65 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
@@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
   // NOR Flash 0 non secure (BootMon)
   TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
   ARM_VE_SMB_NOR0_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
secure firmware (sec_uefi.bin)
   if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE,0,
-TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Base of SRAM. Only half of SRAM in Non Secure world
@@ -92,22 +95,26 @@ ArmPlatformSecTrustzoneInit (
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Memory Mapped Peripherals. All in non secure world
   TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
   ARM_VE_SMB_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // MotherBoard Peripherals and On-chip peripherals.
   TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
   ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 }
 
 /**
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
index 070c0dc..5cd41ef 100644
--- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
+++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
@@ -87,7 +87,8 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN SubregionDisableMask
   )
 {
   UINT32* Region;
@@ -100,7 +101,7 @@ TZASCSetRegion (
 
   MmioWrite32((UINTN)(Region), LowAddress&0x8000);
   MmioWrite32((UINTN)(Region+1), HighAddress);
-  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | ((Size & 0x3F) << 
1) | (Enabled & 0x1));
+  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | 
((SubregionDisableMask & 0xFF) << 8) | ((Size & 0x3F) << 1) | (Enabled & 0x1));
 
   return EFI_SUCCESS;
 }
diff --git a/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h 
b/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
index 78e98aa..1ba963d 100644
--- a/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
+++ b/ArmPlatformPkg/Include/Drivers/ArmTrustzone.h
@@ -82,7 +82,8 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
  

Re: [edk2] [PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

[Bhupesh Sharma]

This patch is missing a .h file. Please discard.
I will RESEND the patch with the fix.

Apologies for the inconvenience. 

Regards,
Bhupesh

> -Original Message-
> From: Bhupesh Sharma [mailto:bhupesh.sha...@nxp.com]
> Sent: Friday, October 14, 2016 4:22 PM
> To: edk2-de...@ml01.01.org
> Cc: linaro-u...@lists.linaro.org; Bhupesh Sharma
> <bhupesh.sha...@nxp.com>; Ard Biesheuvel <ard.biesheu...@linaro.org>
> Subject: [PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for
> specifying Subregions to be disabled
> 
> ARM TZASC-380 IP provides a mechanism to split memory regions being
> protected via it into eight equal-sized sub-regions, with a bit setting
> allowing the corresponding subregion to be disabled.
> 
> Several NXP/FSL SoCs support the TZASC-380 IP block and allow the DDR
> connected via the TZASC to be partitioned into regions having different
> security settings.
> 
> This patch enables this support and can be used for SoCs which support
> such partition of DDR regions.
> 
> Details of the 'subregion_disable' register can be viewed here:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJ
> ABCFHB.html
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21
> ++---
>  ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
>  2 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> index 6fa0774..d358d65 100644
> ---
> a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4S
> ec.c
> +++
> b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9
> +++ x4Sec.c
> @@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
>// NOR Flash 0 non secure (BootMon)
>TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
>ARM_VE_SMB_NOR0_BASE,0,
> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
> 
>// NOR Flash 1. The first half of the NOR Flash1 must be secure for
> the secure firmware (sec_uefi.bin)
>if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
>  //Note: Your OS Kernel must be aware of the secure regions before
> to enable this region
>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>} else {
>  TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_NOR1_BASE,0,
> -TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>}
> 
>// Base of SRAM. Only half of SRAM in Non Secure world @@ -92,22
> +95,26 @@ ArmPlatformSecTrustzoneInit (
>  //Note: Your OS Kernel must be aware of the secure regions before
> to enable this region
>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_SRAM_BASE,0,
> -TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>} else {
>  TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
>  ARM_VE_SMB_SRAM_BASE,0,
> -TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
> +TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
> + 0);
>}
> 
>// Memory Mapped Peripherals. All in non secure world
>TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
>ARM_VE_SMB_PERIPH_BASE,0,
> -  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
> 
>// MotherBoard Peripherals and On-chip peripherals.
>TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
>ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
> -  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
> +  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
> +  0);
>  }
> 
>  /**
> diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> index 070c0dc..5cd41ef 100644
> --- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> +++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
> @@ -87,7 +87

[edk2] [PATCH 1/1] ArmPlatformPkg/ArmTrustZone: Add support for specifying Subregions to be disabled

[Bhupesh Sharma]

ARM TZASC-380 IP provides a mechanism to split memory regions being
protected via it into eight equal-sized sub-regions,
with a bit setting allowing the corresponding subregion to be disabled.

Several NXP/FSL SoCs support the TZASC-380 IP block and allow
the DDR connected via the TZASC to be partitioned into regions
having different security settings.

This patch enables this support and can be used for SoCs which
support such partition of DDR regions.

Details of the 'subregion_disable' register can be viewed here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0431c/CJABCFHB.html

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
Cc: Ard Biesheuvel <ard.biesheu...@linaro.org>
---
 .../Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c | 21 ++---
 ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c  |  5 +++--
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git 
a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c 
b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
index 6fa0774..d358d65 100644
--- a/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
+++ b/ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressSecLibCTA9x4/CTA9x4Sec.c
@@ -72,18 +72,21 @@ ArmPlatformSecTrustzoneInit (
   // NOR Flash 0 non secure (BootMon)
   TZASCSetRegion(ARM_VE_TZASC_BASE,1,TZASC_REGION_ENABLED,
   ARM_VE_SMB_NOR0_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // NOR Flash 1. The first half of the NOR Flash1 must be secure for the 
secure firmware (sec_uefi.bin)
   if (PcdGetBool (PcdTrustzoneSupport) == TRUE) {
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE + SIZE_32MB,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,2,TZASC_REGION_ENABLED,
 ARM_VE_SMB_NOR1_BASE,0,
-TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Base of SRAM. Only half of SRAM in Non Secure world
@@ -92,22 +95,26 @@ ArmPlatformSecTrustzoneInit (
 //Note: Your OS Kernel must be aware of the secure regions before to 
enable this region
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_16MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   } else {
 TZASCSetRegion(ARM_VE_TZASC_BASE,3,TZASC_REGION_ENABLED,
 ARM_VE_SMB_SRAM_BASE,0,
-TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW);
+TZASC_REGION_SIZE_32MB, TZASC_REGION_SECURITY_NSRW,
+   0);
   }
 
   // Memory Mapped Peripherals. All in non secure world
   TZASCSetRegion(ARM_VE_TZASC_BASE,4,TZASC_REGION_ENABLED,
   ARM_VE_SMB_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_64MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 
   // MotherBoard Peripherals and On-chip peripherals.
   TZASCSetRegion(ARM_VE_TZASC_BASE,5,TZASC_REGION_ENABLED,
   ARM_VE_SMB_MB_ON_CHIP_PERIPH_BASE,0,
-  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW);
+  TZASC_REGION_SIZE_256MB, TZASC_REGION_SECURITY_NSRW,
+  0);
 }
 
 /**
diff --git a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c 
b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
index 070c0dc..5cd41ef 100644
--- a/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
+++ b/ArmPlatformPkg/Drivers/ArmTrustZone/ArmTrustZone.c
@@ -87,7 +87,8 @@ TZASCSetRegion (
   IN  UINTN LowAddress,
   IN  UINTN HighAddress,
   IN  UINTN Size,
-  IN  UINTN Security
+  IN  UINTN Security,
+  IN  UINTN SubregionDisableMask
   )
 {
   UINT32* Region;
@@ -100,7 +101,7 @@ TZASCSetRegion (
 
   MmioWrite32((UINTN)(Region), LowAddress&0x8000);
   MmioWrite32((UINTN)(Region+1), HighAddress);
-  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | ((Size & 0x3F) << 
1) | (Enabled & 0x1));
+  MmioWrite32((UINTN)(Region+2), ((Security & 0xF) <<28) | 
((SubregionDisableMask & 0xFF) << 8) | ((Size & 0x3F) << 1) | (Enabled & 0x1));
 
   return EFI_SUCCESS;
 }
-- 
1.9.1


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

[edk2] [PATCH 1/1] MdePkg/IoLib: Add support for big-endian MMIO

[Bhupesh Sharma]

Various IPs on NXP/FSL SoCs having ARM64 cores have big-endian
MMIO interfaces.

This implies that a byte-swap operation is needed to read/write
such BE MMIO registers from the LE ARM64 cores.

This patch adds the support for the same.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Meenakshi Aggarwal <meenakshi.aggar...@nxp.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sha...@nxp.com>
---
 MdePkg/Include/Library/IoLib.h   | 364 
 MdePkg/Library/BaseIoLibIntrinsic/IoLibArm.c | 479 +++
 2 files changed, 843 insertions(+)

diff --git a/MdePkg/Include/Library/IoLib.h b/MdePkg/Include/Library/IoLib.h
index a0dd16b..f5842e6 100644
--- a/MdePkg/Include/Library/IoLib.h
+++ b/MdePkg/Include/Library/IoLib.h
@@ -2658,6 +2658,370 @@ MmioWriteBuffer64 (
   IN  CONST UINT64 *Buffer
   );
 
+/**
+  Reads a 16-bit MMIO register in Big Endian format.
+
+  Reads the 16-bit MMIO register specified by Address. The 16-bit read value is
+  returned. This function must guarantee that all MMIO read and write
+  operations are serialized.
+
+  If 16-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT16
+EFIAPI
+MmioReadBe16 (
+  IN  UINTN Address
+  );
+
+/**
+  Writes a 16-bit MMIO register in Big Endian format.
+
+  Writes the 16-bit MMIO register specified by Address with the value specified
+  by Value and returns Value. This function must guarantee that all MMIO read
+  and write operations are serialized.
+
+  If 16-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT16
+EFIAPI
+MmioWriteBe16 (
+  IN  UINTN Address,
+  IN  UINT16Value
+  );
+
+/**
+  Reads a 32-bit MMIO register in Big Endian format.
+
+  Reads the 32-bit MMIO register specified by Address. The 32-bit read value is
+  returned. This function must guarantee that all MMIO read and write
+  operations are serialized.
+
+  If 32-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT32
+EFIAPI
+MmioReadBe32 (
+  IN  UINTN Address
+  );
+
+/**
+  Writes a 32-bit MMIO register in Big Endian format.
+
+  Writes the 32-bit MMIO register specified by Address with the value specified
+  by Value and returns Value. This function must guarantee that all MMIO read
+  and write operations are serialized.
+
+  If 32-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT32
+EFIAPI
+MmioWriteBe32 (
+  IN  UINTN Address,
+  IN  UINT32Value
+  );
+
+
+/**
+  Reads a 64-bit MMIO register in Big Endian format.
+
+  Reads the 64-bit MMIO register specified by Address. The 64-bit read value is
+  returned. This function must guarantee that all MMIO read and write
+  operations are serialized.
+
+  If 64-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to read.
+
+  @return The value read.
+
+**/
+UINT64
+EFIAPI
+MmioReadBe64 (
+  IN  UINTN Address
+  );
+
+
+/**
+  Writes a 64-bit MMIO register in Big Endian format.
+
+  Writes the 64-bit MMIO register specified by Address with the value specified
+  by Value and returns Value. This function must guarantee that all MMIO read
+  and write operations are serialized.
+
+  If 64-bit MMIO register operations are not supported, then ASSERT().
+
+  @param  Address The MMIO register to write.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT64
+EFIAPI
+MmioWriteBe64 (
+  IN  UINTN Address,
+  IN  UINT64Value
+  );
+
+/**
+  Clear and set a 8-bit MMIO register.
+
+  Mask the 8-bit MMIO register specified by Address with the mask specified
+  by Mask and then Writes the 8-bit MMIO register specified by Address with
+  the value specified by Value and returns current value on register. This
+  function must guarantee that all MMIO read and write operations are 
serialized.
+
+  @param  Address The MMIO register to write.
+  @param  MaskThe Mask to clear the MMIO register.
+  @param  Value   The value to write to the MMIO register.
+
+**/
+UINT8
+EFIAPI
+MmioClearSet8 (
+  IN  UINTNAddress,
+  IN  UINT8Mask,
+  IN  UINT8Value
+  );
+
+/**
+  Clear and set a 16-bit MMIO register in Big Endian format.
+
+  Mask the 16-bit MMIO register specified by Address with the mask specified
+  by Mask and then Writes the 16-bit MMIO register specifie

Re: [edk2] [RFC V2] EDK2 Platform Proposal

[Bhupesh Sharma]

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Friday, September 23, 2016 2:25 AM

> Hello,
> 
> 
> 
> Here is the V2 version of the proposal for the edk2-platforms repo.
> 
> 
> 
> Changes from V1:
> 
> 
> 
> * edk2-platform is not a fork of edk2.
> 
> * edk2-platforms branches contain CPU, Chipset, SoC, and platform
> specific
> 
>   packages
> 
> * edk2-plaforms/master contains all open platforms that are synced with
> 
>   edk2/master.
> 
> * Each edk2-platforms branch may support many platforms (not just one)
> 
> * Use PACKAGES_PATH to do builds using packages from multiple
> repositories
> 
> * Update edk2-platforms branch naming to clearly identify platforms
> that
> 
>   are considered stable and platforms that are under active
> development.
> 
> * edk2 developers may be required to verify platforms in edk2-platforms
> 
>   builds as part of test criteria.  Especially platforms that are
> intended
> 
>   to be used with edk2/master in edk2-platforms/stable-* branches.
> 
> 
> 
> =
> 
> 
> 
> Similar to edk2-staging, we also have a need to manage platforms
> 
> that have been ported to edk2.  Jordan has created a repository
> 
> called edk2-platforms and has created a branch for the
> 
> minnowboard-max that uses a validated release of the UDK 2015 for
> 
> the dependent packages:
> 
> 
> 
> https://github.com/tianocore/edk2-platforms
> 
> 
> 
> https://github.com/tianocore/edk2-platforms/tree/minnowboard-max-
> udk2015

[Bhupesh] This link seems broken. I get a 404 error while trying to acess
this branch. Does it require some special privileges.

Regards,
Bhupesh

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

Re: [edk2] Exporting discontiguous System Memory to EFI STUB

[Bhupesh Sharma]

Hi Ard,

> From: Ard Biesheuvel
> Sent: Wednesday, September 21, 2016 4:50 PM
> 
> On 21 September 2016 at 12:17, Laszlo Ersek <ler...@redhat.com> wrote:
> > On 09/21/16 11:10, Bhupesh Sharma wrote:
> >> Thanks Ard, Laszlo.
> >>
> >> See replies in-line:
> >>
> >>> From: Ard Biesheuvel
> >>> Sent: Thursday, September 15, 2016 5:01 PM
> >>>
> >>> On 15 September 2016 at 10:01, Laszlo Ersek <ler...@redhat.com>
> wrote:
> >>>> On 09/15/16 10:45, Sakar Arora wrote:
> >>>>> Hi
> >>>>>
> >>>>> This is in aarch64 UEFI context.
> >>>>>
> >>>>> The efi stub code ignores any memory nodes in the device tree. It
> >>>>> only relies on the UEFI memory map for memory info.
> >>>>>
> >>>>> In such a scenario, how can one export discontiguous regions of
> >>>>> system memory to the efi stub? There seems to be only one way to
> >>>>> inform UEFI about system memory, via PcdSystemMemoryBase.
> >>>>>
> >>>>> Looking at the latest Arm Juno code, it seems like building a
> >>>>> memory resource descriptor hob, for the extra memory region, does
> >>>>> the
> >>> trick.
> >>>>> Would that be the best way to go?
> >>>>>
> >>>>> Suggestions please.
> >>>>
> >>>> There are two ways.
> >>>>
> >>>> First, in the PEI phase, you can produce memory resource
> descriptor
> >>>> HOBs that will describe system memory areas. When the DXE core
> >>> starts,
> >>>> it will convert the suitable HOBs to EfiGcdMemoryTypeSystemMemory
> >>>> memory space. During DXE and BDS, boot/runtime code/data
> >>>> allocations will be satisfied from these. Then the UEFI memmap
> will
> >>>> reflect those allocations, and the system memory left unused, to
> the EFI stub.
> >>>>
> >>>> Second, you can add EfiGcdMemoryTypeSystemMemory memory space
> >>>> during and after the DXE phase, explicitly, using the DXE
> services.
> >>>> (IIRC, the PI spec says that memory space added this way may be
> >>>> picked by
> >>> the
> >>>> UEFI memory allocation system immediately; IOW, it may immediately
> >>>> become available to the pool and page allocation boot serivces, to
> >>>> allocate from. IIRC, in edk2 this actually happens.) The rest is
> >>>> the same as above, wrt. the UEFI memmap.
> >>>>
> >>>> You can see an example for the second method under
> >>>> "ArmVirtPkg/HighMemDxe". I think it might be particularly close to
> >>>> your use case, as it practically translates the memory nodes found
> >>>> in QEMU's
> >>>> (copied) DTB to EfiGcdMemoryTypeSystemMemory memory space.
> >>>>
> >>>> (Ard, when do you plan to port this driver to FDT_CLIENT_PROTOCOL?
> >>> :))
> >>>>
> >>>
> >>> Any day now :-)
> >>>
> >>> But seriously, I think this is orthogonal to the question, since I
> >>> don't expect that this platform uses DTB to describe the platform
> >>> *to UEFI*, and it would not run any of the runtime DT probing code.
> >>>
> >>> So in this particular case, it is simply a matter of adding the
> >>> additional memory at any point during the execution of UEFI that is
> >>> convenient, by using one of the two methods you describe.
> >>>
> >>
> >> Yes, this platform, which has been extensively discussion on Linux
> >> mailing-lists as well for discontiguous memory regions and their
> >> support in Linux (see [1]), doesn't use DTB to describe the platform
> *to UEFI*.
> >>
> >> However I have one generic question. At the moment we seem to use
> the
> >> PcdSystemMemoryBase and PcdSystemMemorySize PCDs to convey to the
> PEI
> >> and DXE phases about the UEFI system memory limits.
> >
> > No, that's incorrect. These PCDs don't capture the full picture about
> > the "UEFI system memory limits". They just describe one initial
> memory
> > range; the one that will serve as the permanent PEI RAM. (In the PEI
> > phase, one of the PEIMs discovers and installs the "permanent PEI
> > RAM", which is one contiguo

[edk2] Persistent Variable Storage and PlatformBootTimeOut

[Bhupesh Sharma]

Hi EDK2 experts,

We have recently added the support for storing UEFI run-time variables on 
underlying NOR
Flash slave on our ARMV8 NXP board.

We are successfully able to change the values of variables like boot-order 
using the latest
MdeModulePkg BDS:

MdeModulePkg/Universal/BdsDxe/BdsDxe.inf

and retrieve them on next board boot.

While this works almost on all the places, we see that the Auto Boot Time we 
have set using the
following PCD:
gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|20

Doesn't work when one enters the BIOS screen and enters the Boot Maintenance 
Manager to change this
value from say 20 to 10.

On the next board boot, the PlatformBootTimeOut value is still 20.

The same issue is replicable on latest EDK2 (master branch) on qemu for aarch64.

Is this a known issue or are we missing something here?

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

Re: [edk2] Shell version 2.2

[Bhupesh Sharma]

Unfortunately the 'ver' command on the shell also shows up a 2.1 shell version 
with the latest edk2/master.

So, we think it is rather a bug.

Regards,
Bhupesh


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Tim Lewis
> Sent: Saturday, August 06, 2016 12:47 AM
> To: Carsey, Jaben ; Meenakshi Aggarwal
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Subject: Re: [edk2] Shell version 2.2
> 
> Yes,  but they are the same numbers. So I think this is probably a
> 
> The specification says (in the Shell protocol section's Related
> Defintiions):
> 
> #define EFI_SHELL_MAJOR_VERSION 2
> #define EFI_SHELL_MINOR_VERSION 2
> 
> And, from ver.c:
> 
> ShellPrintHiiEx (
>   0,
>   gST->ConOut->Mode->CursorRow,
>   NULL,
>   STRING_TOKEN (STR_VER_OUTPUT_SIMPLE),
>   gShellLevel3HiiHandle,
>   gEfiShellProtocol->MajorVersion,
>   gEfiShellProtocol->MinorVersion
>  );
> 
> And the shell protocol instance comes from ShellProtocol.c (see below):
> 
> EFI_SHELL_PROTOCOL mShellProtocol = {
>   EfiShellExecute,
>   EfiShellGetEnv,
>   EfiShellSetEnv,
>   EfiShellGetAlias,
>   EfiShellSetAlias,
>   EfiShellGetHelpText,
>   EfiShellGetDevicePathFromMap,
>   EfiShellGetMapFromDevicePath,
>   EfiShellGetDevicePathFromFilePath,
>   EfiShellGetFilePathFromDevicePath,
>   EfiShellSetMap,
>   EfiShellGetCurDir,
>   EfiShellSetCurDir,
>   EfiShellOpenFileList,
>   EfiShellFreeFileList,
>   EfiShellRemoveDupInFileList,
>   EfiShellBatchIsActive,
>   EfiShellIsRootShell,
>   EfiShellEnablePageBreak,
>   EfiShellDisablePageBreak,
>   EfiShellGetPageBreak,
>   EfiShellGetDeviceName,
>   (EFI_SHELL_GET_FILE_INFO)FileHandleGetInfo, //*
>   (EFI_SHELL_SET_FILE_INFO)FileHandleSetInfo, //*
>   EfiShellOpenFileByName,
>   EfiShellClose,
>   EfiShellCreateFile,
>   (EFI_SHELL_READ_FILE)FileHandleRead,//*
>   (EFI_SHELL_WRITE_FILE)FileHandleWrite,  //*
>   (EFI_SHELL_DELETE_FILE)FileHandleDelete,//*
>   EfiShellDeleteFileByName,
>   (EFI_SHELL_GET_FILE_POSITION)FileHandleGetPosition, //*
>   (EFI_SHELL_SET_FILE_POSITION)FileHandleSetPosition, //*
>   (EFI_SHELL_FLUSH_FILE)FileHandleFlush,  //*
>   EfiShellFindFiles,
>   EfiShellFindFilesInDir,
>   (EFI_SHELL_GET_FILE_SIZE)FileHandleGetSize, //*
>   EfiShellOpenRoot,
>   EfiShellOpenRootByHandle,
>   NULL,
>   SHELL_MAJOR_VERSION,
>   SHELL_MINOR_VERSION,
> 
>   // New for UEFI Shell 2.1
>   EfiShellRegisterGuidName,
>   EfiShellGetGuidName,
>   EfiShellGetGuidFromName,
>   EfiShellGetEnvEx
> };
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Carsey, Jaben
> Sent: Friday, August 05, 2016 12:10 PM
> To: Tim Lewis ; Meenakshi Aggarwal
> ; edk2-devel@lists.01.org  de...@ml01.01.org>
> Cc: Carsey, Jaben 
> Subject: Re: [edk2] Shell version 2.2
> 
> Tim,
> 
> Yes, ver command would output that the version of the shell is
> different.
> 
> The #define below is specifically the version of the Protocol, not the
> version of the spec.
> 
> It could have been a miss on the part of the committee, but that was
> hoe I interpreted the non-change to the protocol version.
> 
> -Jaben
> 
> > -Original Message-
> > From: Tim Lewis [mailto:tim.le...@insyde.com]
> > Sent: Friday, August 5, 2016 11:36 AM
> > To: Carsey, Jaben ; Meenakshi Aggarwal
> > ; edk2-devel@lists.01.org  > de...@ml01.01.org>
> > Subject: RE: Shell version 2.2
> > Importance: High
> >
> > Jaben --
> >
> > Are there no shell commands where the standard command-line
> parameters
> > have changed?
> >
> > Tim
> >
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> Of
> > Carsey, Jaben
> > Sent: Friday, August 05, 2016 10:26 AM
> > To: Meenakshi Aggarwal ; edk2-
> > de...@lists.01.org 
> > Cc: Carsey, Jaben 
> > Subject: Re: [edk2] Shell version 2.2
> >
> > I think that that version (2.1) is correct for the version of the
> > protocol.  The protocol API was not changed for the UEFI Shell 2.2.
> >
> > That is the current version and should support the 2.2 spec.
> >
> > -Jaben
> >
> > > -Original Message-
> > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > > Of Meenakshi Aggarwal
> > > Sent: Friday, August 5, 2016 2:20 AM
> > > To: edk2-devel@lists.01.org 
> > > Subject: [edk2] Shell version 2.2
> > > Importance: High
> > >
> > > Hi,
> > >
> > >
> > > I can see UEFI shell specification 2.2
> > >
> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pd
> > > f) is available, But on edk2 master branch 

Re: [edk2] [Patch] ShellPkg: Enhance ping to select the interface automatically

[Bhupesh Sharma]

Hello Jiaxin,

Sorry for the delay in reply - I was on holidays.

I will check this patch at my end and will soon get back with the results.

Regards,
Bhupesh

> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Thursday, April 21, 2016 7:35 AM
> To: Bhupesh Sharma <bhupesh.sha...@nxp.com>; Carsey, Jaben
> <jaben.car...@intel.com>; edk2-devel@lists.01.org
> Cc: David Van Arnem <dvanar...@cmlab.biz>; Ye, Ting
> <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>
> Subject: RE: [Patch] ShellPkg: Enhance ping to select the interface
> automatically
> 
> Hello Bhupesh,
> 
> Any test result or feedback for this patch?
> 
> Thanks.
> Jiaxin
> 
> > -Original Message-
> > From: Carsey, Jaben
> > Sent: Wednesday, April 20, 2016 1:10 AM
> > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> > Cc: David Van Arnem <dvanar...@cmlab.biz>; Bhupesh Sharma
> > <bhupesh.sha...@nxp.com>; Ye, Ting <ting...@intel.com>; Fu, Siyuan
> > <siyuan...@intel.com>; Carsey, Jaben <jaben.car...@intel.com>
> > Subject: RE: [Patch] ShellPkg: Enhance ping to select the interface
> > automatically
> >
> > Reviewed-by: Jaben Carsey <jaben.car...@intel.com>
> >
> >
> >
> > > -Original Message-
> > > From: Wu, Jiaxin
> > > Sent: Monday, April 18, 2016 6:52 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: David Van Arnem <dvanar...@cmlab.biz>; Bhupesh Sharma
> > > <bhupesh.sha...@nxp.com>; Carsey, Jaben <jaben.car...@intel.com>;
> > Ye,
> > > Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>
> > > Subject: [Patch] ShellPkg: Enhance ping to select the interface
> > > automatically
> > > Importance: High
> > >
> > > This patch is used to support no source IP specified case while
> > > multiple NICs existed in the platform. The command will select the
> > > first both connected and configured interface automatically.
> > >
> > > Cc: David Van Arnem <dvanar...@cmlab.biz>
> > > Cc: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> > > Cc: Jaben Carsey <jaben.car...@intel.com>
> > > Cc: Ye Ting <ting...@intel.com>
> > > Cc: Fu Siyuan <siyuan...@intel.com>
> > > Contributed-under: TianoCore Contribution Agreement 1.0
> > > Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
> > > ---
> > >  .../Library/UefiShellNetwork1CommandsLib/Ping.c| 224
> -
> > ---
> > > -
> > >  1 file changed, 127 insertions(+), 97 deletions(-)
> > >
> > > diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> > > b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> > > index 13bcdde..6b05884 100644
> > > --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> > > +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> > > @@ -874,20 +874,24 @@ PingCreateIpInstance (  {
> > >EFI_STATUS   Status;
> > >UINTNHandleIndex;
> > >UINTNHandleNum;
> > >EFI_HANDLE   *HandleBuffer;
> > > +  BOOLEAN  UnspecifiedSrc;
> > > +  BOOLEAN  MediaPresent;
> > >EFI_SERVICE_BINDING_PROTOCOL *EfiSb;
> > >VOID *IpXCfg;
> > >EFI_IP6_CONFIG_DATA  Ip6Config;
> > >EFI_IP4_CONFIG_DATA  Ip4Config;
> > >VOID *IpXInterfaceInfo;
> > >UINTNIfInfoSize;
> > >EFI_IPv6_ADDRESS *Addr;
> > >UINTNAddrIndex;
> > >
> > >HandleBuffer  = NULL;
> > > +  UnspecifiedSrc= FALSE;
> > > +  MediaPresent  = TRUE;
> > >EfiSb = NULL;
> > >IpXInterfaceInfo  = NULL;
> > >IfInfoSize= 0;
> > >
> > >//
> > > @@ -923,139 +927,165 @@ PingCreateIpInstance (
> > >ShellPrintHiiEx (-1, -1, NULL, STRING_TOKEN
> > > (STR_GEN_PARAM_INV), gShellNetwork1HiiHandle, L"ping", mSrcString);
> > >Status = EFI_INVALID_PARAMETER;
> > >goto ON_ERROR;
> > >  }
> > >}
> > > +
> > > +  if (Private->IpChoice == PING_IP_CHOICE_IP6 ?
> > 

Re: [edk2] [PATCH] ArmPlatformPkg: fixups for 64-bit mailbox pointers

[Bhupesh Sharma]

We also should consider ARM SOCs which have Internal ROM code running even 
before the ATF starts running in EL3. Such a internal ROM code might be 
configured to make sure that only the primary core runs the ATF and UEFI code 
and the secondaries enter the ATF code first time only when Linux does a 
secondary CPU_ON call.

Regards,
Bhupesh


From: edk2-devel  on behalf of Ard Biesheuvel 

Sent: Monday, April 18, 2016 4:12:15 PM
To: Leif Lindholm
Cc: edk2-devel@lists.01.org; Leo Duran
Subject: Re: [edk2] [PATCH] ArmPlatformPkg: fixups for 64-bit mailbox   pointers

On 18 April 2016 at 12:39, Leif Lindholm  wrote:
> On Thu, Mar 24, 2016 at 11:33:22PM +0100, Ard Biesheuvel wrote:
>> On 24 March 2016 at 21:30, Leo Duran  wrote:
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Leo Duran 
>> > ---
>> >  ArmPlatformPkg/PrePeiCore/MainMPCore.c | 10 --
>> >  ArmPlatformPkg/PrePi/MainMPCore.c  | 10 --
>> >  2 files changed, 16 insertions(+), 4 deletions(-)
>> >
>>
>>
>> ArmPlatformPkg/ArmVExpressPkg/Include/VExpressMotherBoard.h has the
>> following defines
>>
>> #define ARM_VE_SYS_FLAGS_SET_REG
>> (ARM_VE_BOARD_PERIPH_BASE + 0x00030)
>> #define ARM_VE_SYS_FLAGS_CLR_REG
>> (ARM_VE_BOARD_PERIPH_BASE + 0x00034)
>> #define ARM_VE_SYS_FLAGS_NV_REG
>> (ARM_VE_BOARD_PERIPH_BASE + 0x00038)
>>
>> and is used on Juno as well as the older 32-bit archs. I don't know if
>> this is dead code now that PSCI is implemented by ARM trusted
>> firmware, and so we never bring up the secondaries in UEFI. But I
>> would like Leif's take on this when he gets back, since writing 64-bit
>> values is clearly not correct either in this particular case.
>
> Yeah, these remain 32-bit also on Juno.
>
> Moreover, only user I see of this module in public code is FVP
> (OpenPlatformPkg), which should probably be investigated.
>
> Leo: do you actually need PrePeiCoreMPCore in the current version of
> your platform code?
>

I suppose the question here is whether all cores enter UEFI or only
the boot CPU. If the EL3 firmware is doing PSCI, then only the boot
core enters UEFI, and this code could be dropped or simplified. Note
that there are some checks in the code still that prevent you from
running the unicore version on a SMP system, so that should still be
addressed afair
___
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] Using multiple SNP drivers on Shell

[Bhupesh Sharma]

> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Wednesday, April 06, 2016 8:41 AM


> 
> More Info:
> '-s SourceIp' operation is not defined in shell Spec 2.1 or any old
> version, but for ping usage convenience(like Bhupesh's case), the code
> implementation added the additional option '-_s'. That is a non-standard
> option in shell Spec 2.1 but it's allowed by the Shell Spec. Because the
> Spec declaims that command-line options that begin with the '_' character
> are implementation specific.
> 
> But in latest shell Spec version 2.2, '-s SourceIp' option has been
> standardized. So, we will create one patch to update the implementation
> to make it consistent with latest shell Spec. After that, I think
> Bhupesh's issue will be resolved. If there are multiple NICs existed in
> the platform, '-s SourceIp' can be used to specify any interface you
> want(Current implementation is '-_s SourceIp'), this similar like '-S
> SourceIp' in windows or '-I interface' in linux functionality.
> 
> Considering the backward compatible issue, the patch will keep '-_s'
> command option unchanged, only add the new option '-s' and make the old
> option '-_s' function same as new one.

Thanks Jiaxin, that seems fine for me :)

Regards,
Bhupesh

> 
> Thanks.
> Jiaxin
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > David Van Arnem
> > Sent: Wednesday, April 6, 2016 1:34 AM
> > To: Andrew Fish <af...@apple.com>; Bhupesh Sharma
> > <bhupesh.sha...@nxp.com>
> > Cc: Carsey, Jaben <jaben.car...@intel.com>; edk2-devel@lists.01.org
> > <edk2-de...@ml01.01.org>; Laszlo Ersek <ler...@redhat.com>
> > Subject: Re: [edk2] Using multiple SNP drivers on Shell
> >
> > On 04/04/2016 10:30 PM, Andrew Fish wrote:
> > >
> > >> On Apr 4, 2016, at 9:17 PM, Bhupesh Sharma <bhupesh.sha...@nxp.com>
> > wrote:
> > >>
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> > >>> Sent: Monday, April 04, 2016 11:28 PM
> > >>> To: Laszlo Ersek; Bhupesh Sharma
> > >>> Cc: edk2-devel@lists.01.org; David Van Arnem; Carsey, Jaben
> > >>> Subject: RE: [edk2] Using multiple SNP drivers on Shell
> > >>>
> > >>>
> > >>>
> > >>>> -Original Message-
> > >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> > >>>> Behalf Of Laszlo Ersek
> > >>>> Sent: Monday, April 04, 2016 10:47 AM
> > >>>> To: Bhupesh Sharma <bhupesh.sha...@nxp.com>
> > >>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; David Van
> > >>>> Arnem <dvanar...@cmlab.biz>
> > >>>> Subject: Re: [edk2] Using multiple SNP drivers on Shell
> > >>>> Importance: High
> > >>>>
> > >>>> On 04/04/16 19:38, Bhupesh Sharma wrote:
> > >>>>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
> > >>>>>> Sent: Monday, April 04, 2016 11:06 PM
> > >>>>>>
> > >>>>>> On 04/04/16 19:24, David Van Arnem wrote:
> > >>>>>>> On 04/04/2016 03:17 AM, Laszlo Ersek wrote:
> > >>>>>>
> > >>>>>>>> The most recent version (that I have) of the Shell Spec is
> 2.2.
> > >>>>>>>> That version lists both "ping" and "ping6", and the synopsis
> > >>>>>>>> for
> > >>> "ping" is:
> > >>>>>>>>
> > >>>>>>>>Ping [-n count] [-l size] [-s SourceIp] TargetIp
> > >>>>>>>
> > >>>>>>> Interesting, it looks like we each have a different "ping"
> command:
> > >>>>>>> Bhupesh's requires "-_s [SourceIP]", Laszlo's uses "-s
> > >>>>>>> [SourceIP]", and mine (not sure which commit it was build
> > >>>>>>> from, I built it a while
> > >>>>>>> ago) says to use "-s [interface name]" (this may work with the
> > >>>>>>> Source IP also, but the "help" gave eth0 as an example).
> > >>>>>>
> > >>>>>> Note: I didn't test "my" ping command, only proved it right
> > >>>>>&

Re: [edk2] Using multiple SNP drivers on Shell

[Bhupesh Sharma]

> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, April 04, 2016 11:06 PM
> 
> On 04/04/16 19:24, David Van Arnem wrote:
> > On 04/04/2016 03:17 AM, Laszlo Ersek wrote:
> 
> >> The most recent version (that I have) of the Shell Spec is 2.2. That
> >> version lists both "ping" and "ping6", and the synopsis for "ping" is:
> >>
> >>Ping [-n count] [-l size] [-s SourceIp] TargetIp
> >
> > Interesting, it looks like we each have a different "ping" command:
> > Bhupesh's requires "-_s [SourceIP]", Laszlo's uses "-s [SourceIP]",
> > and mine (not sure which commit it was build from, I built it a while
> > ago) says to use "-s [interface name]" (this may work with the Source
> > IP also, but the "help" gave eth0 as an example).
> 
> Note: I didn't test "my" ping command, only proved it right ^W^W^W quoted
> the shell spec. :)
> 
> > But, I suppose that is a moot point, since I should be using an
> > up-to-date Shell as Laszlo recommended.
> 
> The shell source code still uses L"-_s" for the ping (v4) command; only
> the ping6 command uses L"-s". Compare:
> 
> - ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c
> - ShellPkg/Library/UefiShellNetwork2CommandsLib/Ping6.c
> 
> And L"-_s" in the former dates back to this commit:
> 
> commit 68fb05272b45b473fe030ac11dcb79d3f3c0aecd
> Author: jcarsey 
> Date:   Fri Mar 25 20:47:02 2011 +
> 
> Add Network1 profile.
> 
> git-svn-id:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11423
> 6f19259b-4bc3-4df7-8a09-765794883524
> 
> The following command:
> 
>   git grep 'L"-_' -- ShellPkg
> 
> returns a few more hits. I'm thinking the "-_option" pattern is for non-
> standard options, and the underscore is supposed to prevent conflicts
> with any future standardization.
> 
> Maybe in the case of the Ping command, L"-_s" could now be simply
> replaced with L"-s".

IMHO, -_s makes no sense. -s is definitely concise and more readable.

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

Re: [edk2] Using multiple SNP drivers on Shell

[Bhupesh Sharma]

> From: David Van Arnem
> Sent: Friday, April 01, 2016 11:53 PM


> On 04/01/2016 06:48 AM, Bhupesh Sharma wrote:
> > Hello,
> >
> > Any suggestions for this issue? Is this a known issue?
> >
> 
> Hi Bhupesh,
> 
> The ping command allows you to specify the interface you would like to
> use with the -s flag, e.g.
> 
> ping -s eth0 192.168.1.1
> 
> or
> 
> ping -s eth1 192.168.1.1
> 
> The options for ping can be displayed in the Shell with "help ping".

Hi David,

Many thanks. It looks like ping -s is not a valid syntax. It may be that I am 
using a older ShellPkg:

FS0:\> ping -s eth1 192.168.1.1
ping: Invalid argument - '-s'

Looking at the help, I figured out that I need to use -_s option instead:

FS0:\> help ping
Pings the target host with an IPv4 or IPv6 stack.

PING [-_ip6] [-_s SourceIp] [-n count] [-l size] TargetIp ...
EXAMPLES:
...
  * To ping the target host by specifying the source adapter as IPv4 address:
fs0:\> ping -_s 202.120.100.12 202.120.100.1
---
This is a successful test:

FS0:\> ping -_s 192.168.1.8 192.168.1.1
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 836E623BE0 Ping 
192.168.1.1 16 data bytes.
16 bytes from 192.168.1.1 : icmp_seq=1 ttl=0 time=1ms
16 bytes from 192.168.1.1 : icmp_seq=2 ttl=0 time=2ms
16 bytes from 192.168.1.1 : icmp_seq=3 ttl=0 time=2ms
16 bytes from 192.168.1.1 : icmp_seq=4 ttl=0 time=2ms
16 bytes from 192.168.1.1 : icmp_seq=5 ttl=0 time=2ms
16 bytes from 192.168.1.1 : icmp_seq=6 ttl=0 time=2ms
16 bytes from 192.168.1.1 : icmp_seq=7 ttl=0 time=1ms

Now, this leaves me wondering why the Shell Specifications 2.1 contain an old 
syntax for the PING command?
Ping [-n count] [-l size] TargetIp

Will someone care to update it to reflect the correct options, in an upcoming 
Shell specification version?

Regards,
Bhupesh

> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Bhupesh Sharma
> >> Sent: Thursday, March 31, 2016 5:18 PM
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] Using multiple SNP drivers on Shell
> >>
> >> Hi EDK2 experts,
> >>
> >> We are facing an issue when we enable two SNP (Simple Network)
> >> drivers in our EDK2 setup over a ARMv8 based SoC - NXP LS2080A.
> >>
> >> Here, I have two Ethernet interfaces - one is a MAC on SoC + Phy chip
> >> interface, while the other is a E1000 NIC card connected over a PCIe
> >> slot.
> >>
> >> A) When I run the 'ifconfig -l' command, I am able to see that both
> >> the Ethernet interfaces can be probed and they get listed as eth0 and
> >> eth1
> >> interfaces:
> >>
> >> Shell> ifconfig -l
> >>
> >> -
> >>
> >> name : eth0
> >> Media State  : Media present
> >> policy   : dhcp
> >> mac addr : 68:05:CA:16:8C:5E
> >>
> >> ipv4 address : 0.0.0.0
> >>
> >> subnet mask  : 0.0.0.0
> >>
> >> default gateway: 0.0.0.0
> >>
> >>Routes (0 entries):
> >>
> >> DNS server   :
> >>
> >> -
> >>
> >> name : eth1
> >> Media State  : Media present
> >> policy   : static
> >> mac addr : 6E:70:FE:EC:00:06
> >>
> >> ipv4 address : 192.168.1.200
> >>
> >> subnet mask  : 255.255.255.0
> >>
> >> default gateway: 192.168.1.1
> >>
> >>Routes (2 entries):
> >>  Entry[0]
> >>   Subnet : 192.168.1.0
> >>   Netmask: 255.255.255.0
> >>   Gateway: 0.0.0.0
> >>  Entry[1]
> >>   Subnet : 0.0.0.0
> >>   Netmask: 0.0.0.0
> >>   Gateway: 192.168.1.1
> >>
> >> DNS server   :
> >>
> >> -
> >>
> >> B) Now, I try to assign a static IP address to the eth1 interface,
> >> which also works fine:
> >>
> >> Shell> ifconfig -s eth1 static 192.168.1.200 255.255.255.0
> >> Shell> 192.168.1.1
> >> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C
> >> 8370DFBAB0
> >>
> >> C) Now, when I try to ping a server over a LAN cable, I get the
> >> following error message:
> >>
> >> Shell> ping 192.168.1.1
> >> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334A

Re: [edk2] Using multiple SNP drivers on Shell

[Bhupesh Sharma]

Hello,

Any suggestions for this issue? Is this a known issue?

Regards,
Bhupesh

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Bhupesh Sharma
> Sent: Thursday, March 31, 2016 5:18 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Using multiple SNP drivers on Shell
> 
> Hi EDK2 experts,
> 
> We are facing an issue when we enable two SNP (Simple Network) drivers in
> our EDK2 setup over a ARMv8 based SoC - NXP LS2080A.
> 
> Here, I have two Ethernet interfaces - one is a MAC on SoC + Phy chip
> interface, while the other is a E1000 NIC card connected over a PCIe
> slot.
> 
> A) When I run the 'ifconfig -l' command, I am able to see that both the
> Ethernet interfaces can be probed and they get listed as eth0 and eth1
> interfaces:
> 
> Shell> ifconfig -l
> 
> -
> 
> name : eth0
> Media State  : Media present
> policy   : dhcp
> mac addr : 68:05:CA:16:8C:5E
> 
> ipv4 address : 0.0.0.0
> 
> subnet mask  : 0.0.0.0
> 
> default gateway: 0.0.0.0
> 
>   Routes (0 entries):
> 
> DNS server   :
> 
> -
> 
> name : eth1
> Media State  : Media present
> policy   : static
> mac addr : 6E:70:FE:EC:00:06
> 
> ipv4 address : 192.168.1.200
> 
> subnet mask  : 255.255.255.0
> 
> default gateway: 192.168.1.1
> 
>   Routes (2 entries):
> Entry[0]
>  Subnet : 192.168.1.0
>  Netmask: 255.255.255.0
>  Gateway: 0.0.0.0
> Entry[1]
>  Subnet : 0.0.0.0
>  Netmask: 0.0.0.0
>  Gateway: 192.168.1.1
> 
> DNS server   :
> 
> -
> 
> B) Now, I try to assign a static IP address to the eth1 interface, which
> also works fine:
> 
> Shell> ifconfig -s eth1 static 192.168.1.200 255.255.255.0 192.168.1.1
> InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 8370DFBAB0
> 
> C) Now, when I try to ping a server over a LAN cable, I get the following
> error message:
> 
> Shell> ping 192.168.1.1
> InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 8370DFD9E0
> InstallProtocolInterface: 8A219718-4EF5-4761-91C8-C0F04BDA9E56 8370DFF8A0
> 
> Snp->undi.transmit()  8000h:Ah
> Config No mapping
> 
> D) When I disable the PCIe-E1000 driver explicitly in my .fdf file, I get
> only one 'eth0'
> interface and then I am able to assign an IP address statically and PING
> a server on LAN successfully.
> 
> So, my query is whether two SNP drivers can be supported simultaneously
> over the Shell?
> 
> I also went through the Shell Specifications
> (http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf),
> but I cannot find a command that can be used to "select" one of the
> Ethernet interface to be used for PING/TFTP like commands when both the
> Ethernet interfaces are enabled.
> 
> Any pointers?
> 
> Regards,
> Bhupesh
> ___
> 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] Using multiple SNP drivers on Shell

[Bhupesh Sharma]

Hi EDK2 experts,

We are facing an issue when we enable two SNP (Simple Network) drivers in our 
EDK2 setup over a ARMv8 based
SoC - NXP LS2080A.

Here, I have two Ethernet interfaces - one is a MAC on SoC + Phy chip 
interface, while the
other is a E1000 NIC card connected over a PCIe slot.

A) When I run the 'ifconfig -l' command, I am able to see that both the 
Ethernet interfaces
can be probed and they get listed as eth0 and eth1 interfaces:

Shell> ifconfig -l

-

name : eth0
Media State  : Media present
policy   : dhcp
mac addr : 68:05:CA:16:8C:5E

ipv4 address : 0.0.0.0

subnet mask  : 0.0.0.0

default gateway: 0.0.0.0

  Routes (0 entries):

DNS server   :

-

name : eth1
Media State  : Media present
policy   : static
mac addr : 6E:70:FE:EC:00:06

ipv4 address : 192.168.1.200

subnet mask  : 255.255.255.0

default gateway: 192.168.1.1

  Routes (2 entries):
Entry[0]
 Subnet : 192.168.1.0
 Netmask: 255.255.255.0
 Gateway: 0.0.0.0
Entry[1]
 Subnet : 0.0.0.0
 Netmask: 0.0.0.0
 Gateway: 192.168.1.1

DNS server   :

-

B) Now, I try to assign a static IP address to the eth1 interface, which also 
works fine:

Shell> ifconfig -s eth1 static 192.168.1.200 255.255.255.0 192.168.1.1
InstallProtocolInterface: F4B427BB-BA21-4F16-BC4E-43E416AB619C 8370DFBAB0

C) Now, when I try to ping a server over a LAN cable, I get the following error 
message:

Shell> ping 192.168.1.1
InstallProtocolInterface: 41D94CD2-35B6-455A-8258-D4E51334AADD 8370DFD9E0
InstallProtocolInterface: 8A219718-4EF5-4761-91C8-C0F04BDA9E56 8370DFF8A0

Snp->undi.transmit()  8000h:Ah
Config No mapping

D) When I disable the PCIe-E1000 driver explicitly in my .fdf file, I get only 
one 'eth0'
interface and then I am able to assign an IP address statically and PING a 
server on LAN
successfully.

So, my query is whether two SNP drivers can be supported simultaneously over 
the Shell?

I also went through the Shell Specifications 
(http://www.uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf),
but I cannot find a command that can be used to "select" one of the Ethernet
interface to be used for PING/TFTP like commands when both the Ethernet 
interfaces are enabled.

Any pointers?

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

Re: [edk2] Allocating Aligned Pages

[Bhupesh Sharma]

> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, February 17, 2016 1:34 PM

> > On Feb 16, 2016, at 11:52 PM, Bhupesh Sharma <bhupesh.sha...@nxp.com>
> wrote:
> >
> > Hi Experts,
> >
> > We are using the 'AllocateAlignedPages' function (inside
> > 'MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c')
> > to allocate 512MB aligned memory chunk in a DXE driver.
> >
> > However the memory chunk which gets allocated by this API is around
> 1GB.
> >
> > I understand that this might be  because of the memory fragmentation,
> > as a result of which allocating the 512MB aligned buffer might result
> in memory chunk being allocated be greater in size than 512MB.
> >
> > Are we using the right API for the purpose - is there another API
> > available which allows alignment to specified more granularly?
> >
> 
> What do you mean by more granularity? Something other than a power of 2?
> How much memory does your system have? Have you looked at the memory map
> in the shell to see how fragmented it is?
> 

Yes, I mean something that would support allocating a page size of say 64K 
rather
than 4K, which is well supported on platforms like ARM and allow lesser memory 
fragmentation
(though it has its own demerits).

We currently have 2GB DDR on the board. It can be stacked up further by adding 
more DDR DIMMs,
but currently it is only 2GB.

So, if the memory allocation hunk consumes 1GB from the available 2GB, it's 
quite restrictive
at the moment.

I haven't checked at the Shell for memory allocation and corresponding 
fragmentation.

I will try and do the same and post back the results.

Regards,
Bhupesh
 
> > Here is the 'AllocateAlignedPages' function which calls
> 'InternalAllocateAlignedPages' internally.
> >
> > /**
> >  Allocates one or more 4KB pages of type EfiBootServicesData at a
> specified alignment.
> >
> >  Allocates the number of 4KB pages specified by Pages of type
> > EfiBootServicesData with an  alignment specified by Alignment.  The
> > allocated buffer is returned.  If Pages is 0, then NULL is  returned.
> > If there is not enough memory at the specified alignment remaining to
> satisfy the  request, then NULL is returned.
> >
> >  If Alignment is not a power of two and Alignment is not zero, then
> ASSERT().
> >  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> >
> >  @param  Pages The number of 4 KB pages to allocate.
> >  @param  Alignment The requested alignment of the
> allocation.  Must be a power of two.
> >If Alignment is zero, then byte
> alignment is used.
> >
> >  @return A pointer to the allocated buffer or NULL if allocation fails.
> >
> > **/
> > VOID *
> > EFIAPI
> > AllocateAlignedPages (
> >  IN UINTN  Pages,
> >  IN UINTN  Alignment
> >  )
> > {
> >  return InternalAllocateAlignedPages (EfiBootServicesData, Pages,
> > Alignment); }
> >
> > ...
> >
> > /**
> >  Allocates one or more 4KB pages of a certain memory type at a
> specified alignment.
> >
> >  Allocates the number of 4KB pages specified by Pages of a certain
> > memory type with an alignment  specified by Alignment.  The allocated
> buffer is returned.  If Pages is 0, then NULL is returned.
> >  If there is not enough memory at the specified alignment remaining to
> > satisfy the request, then  NULL is returned.
> >  If Alignment is not a power of two and Alignment is not zero, then
> ASSERT().
> >  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().
> >
> >  @param  MemoryTypeThe type of memory to allocate.
> >  @param  Pages The number of 4 KB pages to allocate.
> >  @param  Alignment The requested alignment of the
> allocation.  Must be a power of two.
> >If Alignment is zero, then byte
> alignment is used.
> >
> >  @return A pointer to the allocated buffer or NULL if allocation fails.
> >
> > **/
> > VOID *
> > InternalAllocateAlignedPages (
> >  IN EFI_MEMORY_TYPE  MemoryType,
> >  IN UINTNPages,
> >  IN UINTNAlignment
> >  )
> >
> > ...
> >
> > Thanks for the help.
> >
> > Regards,
> > Bhupesh
> > ___
> > 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] Allocating Aligned Pages

[Bhupesh Sharma]

Hi Experts,

We are using the 'AllocateAlignedPages' function (inside 
'MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c')
to allocate 512MB aligned memory chunk in a DXE driver.

However the memory chunk which gets allocated by this API is around 1GB.

I understand that this might be  because of the memory fragmentation, as a 
result of which allocating
the 512MB aligned buffer might result in memory chunk being allocated be 
greater in size than 512MB.

Are we using the right API for the purpose - is there another API available 
which allows alignment to specified
more granularly? 

Here is the 'AllocateAlignedPages' function which calls 
'InternalAllocateAlignedPages' internally.

/**
  Allocates one or more 4KB pages of type EfiBootServicesData at a specified 
alignment.

  Allocates the number of 4KB pages specified by Pages of type 
EfiBootServicesData with an
  alignment specified by Alignment.  The allocated buffer is returned.  If 
Pages is 0, then NULL is
  returned.  If there is not enough memory at the specified alignment remaining 
to satisfy the
  request, then NULL is returned.
  
  If Alignment is not a power of two and Alignment is not zero, then ASSERT().
  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().

  @param  Pages The number of 4 KB pages to allocate.
  @param  Alignment The requested alignment of the allocation.  
Must be a power of two.
If Alignment is zero, then byte alignment is 
used.

  @return A pointer to the allocated buffer or NULL if allocation fails.

**/
VOID *
EFIAPI
AllocateAlignedPages (
  IN UINTN  Pages,
  IN UINTN  Alignment
  )
{
  return InternalAllocateAlignedPages (EfiBootServicesData, Pages, Alignment);
}

...

/**
  Allocates one or more 4KB pages of a certain memory type at a specified 
alignment.

  Allocates the number of 4KB pages specified by Pages of a certain memory type 
with an alignment
  specified by Alignment.  The allocated buffer is returned.  If Pages is 0, 
then NULL is returned.
  If there is not enough memory at the specified alignment remaining to satisfy 
the request, then
  NULL is returned.
  If Alignment is not a power of two and Alignment is not zero, then ASSERT().
  If Pages plus EFI_SIZE_TO_PAGES (Alignment) overflows, then ASSERT().

  @param  MemoryTypeThe type of memory to allocate.
  @param  Pages The number of 4 KB pages to allocate.
  @param  Alignment The requested alignment of the allocation.  
Must be a power of two.
If Alignment is zero, then byte alignment is 
used.

  @return A pointer to the allocated buffer or NULL if allocation fails.

**/
VOID *
InternalAllocateAlignedPages (
  IN EFI_MEMORY_TYPE  MemoryType,  
  IN UINTNPages,
  IN UINTNAlignment
  )

...

Thanks for the help.

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

[edk2] Memory sharing between PEI and DXE phases

[Bhupesh Sharma]

Hi Experts,

I have a doubt regarding memory sharing between PEI and DXE phases.

Let's say I have a PEI library 'NorLib.c' and a DXE driver 'NorDxeDriver.c', 
where
the DXE driver uses some APIs of the PEI Library to obtain information and 
provide
functionalities to the upper layers.

Now, if I allocate some memory chunk (let's say for a pointer) in the PEI phase,
how can I use the same in the DXE phase (as normally the PEI pointer contents 
become
INVALID in the DXE phase).

Are there standard HOB mechanisms available for the same?

Thanks for the help.

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

Re: [edk2] SATA 3.0 AHCI host controller codebase

[Bhupesh Sharma]

> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, February 08, 2016 1:20 PM
> 
> On 02/06/16 09:38, Bhupesh Sharma wrote:
> >> From: Laszlo Ersek
> >> Sent: Friday, February 05, 2016 2:27 AM
> >>
> >> On 02/03/16 22:39, Leif Lindholm wrote:
> >>> Hi Shaveta,
> >>>
> >>> On Tue, Feb 02, 2016 at 07:05:03AM +, Shaveta Leekha wrote:
> >>>> Is there some SATA 3.0 AHCI driver implementation in UEFI / EDK
> code?
> >>>> The one I need to write for our platform is not PCI based.
> >>>>
> >>>> I have seen few implementations in EDK2:
> >>>> DuetPkg/SataControllerDxe/SataController.c
> >>>> OvmfPkg/SataControllerDxe/SataController.c
> >>>> But in all of them SATA connectivity is via PCI Express switch.
> >>>>
> >>>> Kindly point me to some non-PCI based "SATA 3.0 AHCI driver code"
> >>>> for UEFI, if there is any such code.
> >>>
> >>> I have seen several such platforms implementing a "dummy" PCI
> >>> Express driver, simply translating PCI accesses to memory mapped
> >>> ones, and still making use of the MdeModulePkg/Bus/Ata/ libraries.
> >>>
> >>> You can see examples of PCI emulation in
> >>> Omap35xxPkg/PciEmulation/PciEmulation.c
> >>> and
> >>> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/PciEmulation.c
> >>>
> >>> As a side note, we really should have a common mmio-PCI emulation
> >>> library in core EDK2.
> >>
> >> Actually the driver stack rests upon the platform-specific PCI host
> >> bridge/root bridge driver (a DXE_DRIVER, i.e., one that doesn't bind
> >> other handles according to the UEFI Driver Model, but produces the
> >> Root Bridge IO protocols, and the Host Bridge Resource Allocation
> >> protocol(s), out of "thin air", in its entry point function).
> >>
> >> The PCI Bus driver (producing PciIo protocol instances) is platform-
> >> independent, and needs the previously mentioned driver. From PciIo
> >> upwards, it's all generic. (Well, I'll mention that there is no
> >> platform- independent SataControllerDxe in edk2. I don't recall the
> >> reason -- apologies --, but a reason *was* given for it.)
> >>
> >> Ray recently implemented a generic PCI host bridge / root bridge
> >> driver, in "MdeModulePkg/Bus/Pci/PciHostBridgeDxe". That driver
> delegates:
> >>
> >> - some of the platform specifics to the (also new) PciHostBridgeLib
> >>   class,
> >> - PCI config space access to the PciSegmentLib class (there are, or
> can
> >>   be made, library instances that provide 0xCF8/0xCFC, or
> MMCONFIG/ECAM
> >>   based config space access),
> >> - IO port access to the CPU driver that provides the
> >>   EFI_CPU_IO2_PROTOCOL.
> >>
> >> I believe that for a "single root bridge" system, this structure is
> >> generic enough.
> >>
> >> (Of course, nothing prevents a system from implementing PciIo
> >> independently, which "ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe"
> >> seems to do.)
> >
> > Thanks Laszlo and Leif.
> >
> > So, AFAIU there are two approaches available on implementing the SATA
> > (AHCI based) host controller on ARM based SoCs:
> >
> > 1. Either, we can use the PCIe emulation layers to emulation a SATA
> > controller sitting as a PciIO device on top of the PCIe emulation
> > layer. So, eventually we will be using the ATA Bus layer inside
> > MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
> > to get the AHCI-ATA bus services.
> >
> > 2. Or, we can implement the AHCI based SATA controller as a block
> > device (exposing the BLOCK IO protocol) and implemented on the lines
> > of a SD/MMC card like driver. The BLOCK IO protocol can then be used by
> a FatPkg like layer to provide a support for FAT32 filesystem over the
> SATA driver.
> >
> > Both the above approaches have their own merits and demerits. While
> > approach 1 might introduce extra memory allocation/housekeeping
> overheads for PCIe emulation layer, approach 2 might not be compatible to
> all UEFI shell applications that want to use a underlying SATA HDD
> support.
> >
> > So, this brings forward the question, as to which UEFI shell
> applications (e.g. GRUB2) can work with approach 2 and which cannot.
> > Are there any other obvious disadvantages to approach 2?
&

Re: [edk2] UEFI Shell: Backspace doesn't work

[Bhupesh Sharma]

> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> Sent: Tuesday, February 02, 2016 5:35 PM
> 
> On 2 February 2016 at 11:59, Laszlo Ersek <ler...@redhat.com> wrote:
> > On 02/02/16 12:53, Bhupesh Sharma wrote:
> >>> From: Ryan Harkin [mailto:ryan.har...@linaro.org]
> >>> Sent: Tuesday, February 02, 2016 4:57 PM
> >>>
> >>> On 2 February 2016 at 10:18, Laszlo Ersek <ler...@redhat.com> wrote:
> >>>> On 02/02/16 10:09, Bhupesh Sharma wrote:
> >>>>>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >>>>>> Sent: Tuesday, February 02, 2016 1:44 PM
> >>>>>
> >>>>>> On 2 February 2016 at 09:05, Bhupesh Sharma
> >>>>>> <bhupesh.sha...@nxp.com>
> >>>>>> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I think some of the edk2 shell users might have already noticed
> >>>>>>> this, that the Backspace input doesn't work on the UEFI shell (I
> >>>>>>> am using the
> >>>>>> latest edk2/master branch).
> >>>>>>>
> >>>>>>> On Qemu-AARCH64 2.5 build, I can get 'Ctrl + H' to work as the
> >>>>>>> Backspace key on the shell, but on my AARCH64 platform even that
> >>>>>> doesn't work.
> >>>>>>>
> >>>>>>> Are there any plans to fix the same?
> >>>>>>>
> >>>>>>
> >>>>>> You can build ArmVirtQemu.dsc with -D TTY_TERMINAL to get the
> >>>>>> behavior you are looking for.
> >>>>>
> >>>>> Thanks Ard. Is this TerminalType setting specific only to IntelBds
> >>>>> or does it work with ArmBds as well, I mean something like a Arm
> >>>>> Juno
> >>> board which currently uses ArmBds.
> >>>>>
> >>>
> >>> This is the change I'm currently using for Juno.  The path is
> >>> different from OpenPlatformPkg vs EDK2, but the change is the same:
> >>
> >> Thanks Ryan and Laszlo for the suggestions.
> >>
> >> But I have replaced the ConIn and ConOut default paths in my platform
> >> .dsc with VenMsg(), and I still cannot get either Backspace or "Ctrl
> >> + h" to work :(
> >>
> 
> Ah, assuming you corrected the missing trailing quotes to get it to
> compile, 

I made a mistake in copy-pasting it to the mail-message, I have the trailing
quotes and closing bracket in place in the .dsc file.

> see below, you will also need to erase your existing UEFI
> variable store.  I do this by "touch / board>/SOFTWARE/blank.img" and rebooting the board.

This is Juno specific, right? I was testing on my own Freescale ARM64 board,
but cannot get the backspace yet to work even with the VenMsg(..) change.

I also have a remote Juno board. Let me try the fix there as well, but I
would really like to get the same working on my platform as well.

Regards,
Bhupesh

> 
> >> -  gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();"
> >> -  gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
> >> +
> >> + gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-9
> >> + 71A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1
> >> + -458C-A48F-E25FDD51EF94)
> >> +
> >> + gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-97
> >> + 1A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenMsg(7D916D80-5BB1-
> >> + 458C-A48F-E25FDD51EF94)
> >>
> >> I might be missing something here. So any pointers are much
> appreciated.
> >
> > Not sure if you pasted the above verbatim, but trailing quotes are
> > certainly missing.
> >
> 
> Yes, that was a weird copy/paste error.  Here's what that section of diff
> should really look like:
> 
> -  gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"VenHw(D3987D4B-
> 971A-435F-8CAF-
> 4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi();VenHw(CE660500-824D-11E0-
> AC72-0002A5D5C51B)"
> -  gArmPlatformTokenSpaceGuid.PcdDefaultConInPaths|L"VenHw(D3987D4B-971A-
> 435F-8CAF-4967EB627241)/Uart(115200,8,N,1)/VenPcAnsi()"
> +  gArmPlatformTokenSpaceGuid.PcdDefaultConOutPaths|L"V

[edk2] UEFI Shell: Backspace doesn't work

[Bhupesh Sharma]

Hi,

I think some of the edk2 shell users might have already noticed this, that the
Backspace input doesn't work on the UEFI shell (I am using the latest 
edk2/master branch).

On Qemu-AARCH64 2.5 build, I can get 'Ctrl + H' to work as the Backspace key on 
the shell,
but on my AARCH64 platform even that doesn't work.

Are there any plans to fix the same?

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

Re: [edk2] UEFI Shell: Backspace doesn't work

[Bhupesh Sharma]

> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Tuesday, February 02, 2016 1:44 PM

> On 2 February 2016 at 09:05, Bhupesh Sharma <bhupesh.sha...@nxp.com>
> wrote:
> > Hi,
> >
> > I think some of the edk2 shell users might have already noticed this,
> > that the Backspace input doesn't work on the UEFI shell (I am using the
> latest edk2/master branch).
> >
> > On Qemu-AARCH64 2.5 build, I can get 'Ctrl + H' to work as the
> > Backspace key on the shell, but on my AARCH64 platform even that
> doesn't work.
> >
> > Are there any plans to fix the same?
> >
> 
> You can build ArmVirtQemu.dsc with -D TTY_TERMINAL to get the behavior
> you are looking for.

Thanks Ard. Is this TerminalType setting specific only to IntelBds or does it 
work
with ArmBds as well, I mean something like a Arm Juno board which currently 
uses ArmBds.

I know that the ArmBds is deprecated, but just wanted to be sure.

Regards,
Bhupesh

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