Re: [edk2] [PATCH] BaseTools/tools_def: suppress GCC predefined macros in DTB compilation

2017-10-30 Thread Gao, Liming
Ard:
  I have no other comments. 

Reviewed-by: Liming Gao 

Thanks
Liming
>-Original Message-
>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>Sent: Thursday, October 26, 2017 6:12 PM
>To: edk2-devel@lists.01.org
>Cc: leif.lindh...@linaro.org; Gao, Liming ; Zhu,
>Yonghong ; Ard Biesheuvel
>
>Subject: [PATCH] BaseTools/tools_def: suppress GCC predefined macros in
>DTB compilation
>
>The standard GCC preprocessor we use to preprocess device tree sources
>files has a whole bunch of macros predefined, among which
>
>This causes a property like 'linux,code' to be converted into '1,code'
>which is obviously wrong. So let's get rid of all the predefined macros
>by passing -undef to the preprocessor command line.
>
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Ard Biesheuvel 
>---
> BaseTools/Conf/tools_def.template | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/BaseTools/Conf/tools_def.template
>b/BaseTools/Conf/tools_def.template
>index df7c109438fd..98df0ffc9294 100755
>--- a/BaseTools/Conf/tools_def.template
>+++ b/BaseTools/Conf/tools_def.template
>@@ -4369,7 +4369,7 @@ DEFINE GCC_VFRPP_FLAGS = -x c -E -P -
>DVFRCOMPILE --include $(DEST_DI
> DEFINE GCC_ASLPP_FLAGS = -x c -E -include AutoGen.h
> DEFINE GCC_ASLCC_FLAGS = -x c
> DEFINE GCC_WINDRES_FLAGS   = -J rc -O coff
>-DEFINE GCC_DTCPP_FLAGS = -E -x assembler-with-cpp -imacros
>$(DEST_DIR_DEBUG)/AutoGen.h -nostdinc
>+DEFINE GCC_DTCPP_FLAGS = -E -x assembler-with-cpp -imacros
>$(DEST_DIR_DEBUG)/AutoGen.h -nostdinc -undef
> DEFINE GCC_IA32_RC_FLAGS   = -I binary -O elf32-i386  -B i386 
>--
>rename-section .data=.hii
> DEFINE GCC_X64_RC_FLAGS= -I binary -O elf64-x86-64-B i386 
>--
>rename-section .data=.hii
> DEFINE GCC_IPF_RC_FLAGS= -I binary -O elf64-ia64-little   -B ia64 
>--
>rename-section .data=.hii
>--
>2.11.0

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


Re: [edk2] Storing Non volatile variables on SD/NAND

2017-10-30 Thread Udit Kumar
Thanks Jeremy 

> Hi,
> 
> On 10/27/2017 10:09 PM, Udit Kumar wrote:
> >> (along those lines)
> >>
> >> 6 - Build an emulated disk controller as well as NV region in el3 (or
> >> el2) and export them to UEFI & the OS as real devices. Then
> >> trap/forward requests to the actual storage device, which is
> >> "hidden". This AFAIK was the basic idea behind the PS/2 emulation in
> >> x86/SMM. Again, probably not a high performance option.
> >
> > You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to 
> > get
> things done.
> > On this line,  some sort of permission manager could reside in el3 or el2.
> > Either UEFI or OS driver needs to make a call, if they are allowed to
> > access this specific controller or other driver is accessing it.
> > With this  performance issue could be ironed out .
> 
> That isn't really what I meant, what I was thinking about was creating an
> emulated (AHCI for example) controller where accesses to the "register" space
> would trap to synchronous data/external aborts. That way the firmware and OS
> could use existing drivers without knowledge that the device was in any way
> special. If you create a driver and do SMC/whatever calls, then your basically
> doing #5..

This may work if both OS and UEFI are residing is same EL level.  
Do you mean, to get access to controller use this trap or entire AHCI space in
unmapped area, which will leads to synchronous aborts.

> 
> >
> > Regards
> > Udit
> >
> >> -Original Message-
> >> From: Jeremy Linton [mailto:jeremy.lin...@arm.com]
> >> Sent: Friday, October 27, 2017 11:16 PM
> >> To: Ard Biesheuvel ; Udit Kumar
> >> 
> >> Cc: edk2-devel@lists.01.org; Andrew Fish ;
> >> olivier.mar...@arm.com; Vladimir Olovyannikov
> >> 
> >> Subject: Re: [edk2] Storing Non volatile variables on SD/NAND
> >>
> >> On 09/20/2017 12:39 PM, Ard Biesheuvel wrote:
> >>> On 20 September 2017 at 10:34, Udit Kumar  wrote:
> 
>  When we want to have UEFI and OS accessing same media ,
>  Possibilities I see
> 
>  1- Patch OS For status check of media (diversion from generic OS),
>  Good case
> >> will be modify low level driver.
>  But we may end up some surprises on synchronization.
> 
>  2- no runtime service for OS . I guess this will not be possible
> 
>  3- Way the  Vladimir implemented for eMMC, This has risk of losing
>  data in
> >> case of AC power off.
> 
>  4- update hardware with dual view (Ard suggestion)
> 
> >>>
> >>> 5 - abstract direct block device access into a firmware service that
> >>> is exposed via a DXE_RUNTIME_DRIVER.
> >>
> >> (along those lines)
> >>
> >> 6 - Build an emulated disk controller as well as NV region in el3 (or
> >> el2) and export them to UEFI & the OS as real devices. Then
> >> trap/forward requests to the actual storage device, which is
> >> "hidden". This AFAIK was the basic idea behind the PS/2 emulation in
> >> x86/SMM. Again, probably not a high performance option.
> >>
> >>
> >>>
> >>> The UEFI spec allows you to expose entry points into a
> >>> DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
> >>> can use a driver that uses the abstracted device rather than the
> >>> real device. Performance is going to be terrible, probably, and lots
> >>> of things that are specific to SD/MMC will no longer work, but it is
> >>> a possibility nonetheless.
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>>
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> >> sts.01
> >> .org%2Fmailman%2Flistinfo%2Fedk2-
> >>
> devel=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08
> >>
> d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723
> >>
> 1755528994=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA
> >> %3D=0
> >>>
> >

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


[edk2] [PATCH 1/2] MdeModulePkg/EmmcBlockIoPei: Support IoMmu

2017-10-30 Thread Hao Wu
Update the EmmcBlockIoPei driver to consume IOMMU_PPI to allocate DMA
buffer.

If no IOMMU_PPI exists, this driver still calls PEI service
to allocate DMA buffer, with assumption that DRAM==DMA.

This is a compatible change.

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/DmaMem.c   | 249 

 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcBlockIoPei.c   |  44 +++-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcBlockIoPei.h   | 141 ++-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcBlockIoPei.inf |   5 +-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHcMem.c|  23 +-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHcMem.h|   4 +-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHci.c  |  36 ++-
 7 files changed, 483 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/EmmcBlockIoPei/DmaMem.c 
b/MdeModulePkg/Bus/Sd/EmmcBlockIoPei/DmaMem.c
new file mode 100644
index 00..29fb37c225
--- /dev/null
+++ b/MdeModulePkg/Bus/Sd/EmmcBlockIoPei/DmaMem.c
@@ -0,0 +1,249 @@
+/** @file
+  The DMA memory help function.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions
+  of the BSD License which accompanies this distribution.  The
+  full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "EmmcBlockIoPei.h"
+
+EDKII_IOMMU_PPI  *mIoMmu;
+
+/**
+  Provides the controller-specific addresses required to access system memory 
from a
+  DMA bus master.
+
+  @param  Operation Indicates if the bus master is going to read 
or write to system memory.
+  @param  HostAddress   The system memory address to map to the PCI 
controller.
+  @param  NumberOfBytes On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param  DeviceAddress The resulting map address for the bus master 
PCI controller to use to
+access the hosts HostAddress.
+  @param  Mapping   A resulting value to pass to Unmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+IoMmuMap (
+  IN  EDKII_IOMMU_OPERATION Operation,
+  IN VOID   *HostAddress,
+  IN  OUT UINTN *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Attribute;
+
+  if (mIoMmu != NULL) {
+Status = mIoMmu->Map (
+   mIoMmu,
+   Operation,
+   HostAddress,
+   NumberOfBytes,
+   DeviceAddress,
+   Mapping
+   );
+if (EFI_ERROR (Status)) {
+  return EFI_OUT_OF_RESOURCES;
+}
+switch (Operation) {
+case EdkiiIoMmuOperationBusMasterRead:
+case EdkiiIoMmuOperationBusMasterRead64:
+  Attribute = EDKII_IOMMU_ACCESS_READ;
+  break;
+case EdkiiIoMmuOperationBusMasterWrite:
+case EdkiiIoMmuOperationBusMasterWrite64:
+  Attribute = EDKII_IOMMU_ACCESS_WRITE;
+  break;
+case EdkiiIoMmuOperationBusMasterCommonBuffer:
+case EdkiiIoMmuOperationBusMasterCommonBuffer64:
+  Attribute = EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE;
+  break;
+default:
+  ASSERT(FALSE);
+  return EFI_INVALID_PARAMETER;
+}
+Status = mIoMmu->SetAttribute (
+   mIoMmu,
+   *Mapping,
+   Attribute
+   );
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+  } else {
+*DeviceAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)HostAddress;
+*Mapping = NULL;
+Status = EFI_SUCCESS;
+  }
+  return Status;
+}
+
+/**
+  Completes the Map() operation and releases any corresponding resources.
+
+  @param  Mapping   The mapping value returned from Map().
+
+  @retval EFI_SUCCESS   The range was unmapped.
+  @retval EFI_INVALID_PARAMETER Mapping is not a value that was returned by 
Map().
+  @retval EFI_DEVICE_ERROR  The data was not committed to the target 
system memory.
+**/
+EFI_STATUS
+IoMmuUnmap (
+  IN VOID

[edk2] [PATCH 2/2] MdeModulePkg/SdBlockIoPei: Support IoMmu

2017-10-30 Thread Hao Wu
Update the SdBlockIoPei driver to consume IOMMU_PPI to allocate DMA
buffer.

If no IOMMU_PPI exists, this driver still calls PEI service
to allocate DMA buffer, with assumption that DRAM==DMA.

This is a compatible change.

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Sd/SdBlockIoPei/DmaMem.c | 249 
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdBlockIoPei.c   |  44 +++-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdBlockIoPei.h   | 141 ++-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdBlockIoPei.inf |   5 +-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHcMem.c|  23 +-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHcMem.h|   4 +-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHci.c  |  36 ++-
 7 files changed, 483 insertions(+), 19 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/SdBlockIoPei/DmaMem.c 
b/MdeModulePkg/Bus/Sd/SdBlockIoPei/DmaMem.c
new file mode 100644
index 00..0dc2711ed1
--- /dev/null
+++ b/MdeModulePkg/Bus/Sd/SdBlockIoPei/DmaMem.c
@@ -0,0 +1,249 @@
+/** @file
+  The DMA memory help function.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions
+  of the BSD License which accompanies this distribution.  The
+  full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "SdBlockIoPei.h"
+
+EDKII_IOMMU_PPI  *mIoMmu;
+
+/**
+  Provides the controller-specific addresses required to access system memory 
from a
+  DMA bus master.
+
+  @param  Operation Indicates if the bus master is going to read 
or write to system memory.
+  @param  HostAddress   The system memory address to map to the PCI 
controller.
+  @param  NumberOfBytes On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param  DeviceAddress The resulting map address for the bus master 
PCI controller to use to
+access the hosts HostAddress.
+  @param  Mapping   A resulting value to pass to Unmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+IoMmuMap (
+  IN  EDKII_IOMMU_OPERATION Operation,
+  IN VOID   *HostAddress,
+  IN  OUT UINTN *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Attribute;
+
+  if (mIoMmu != NULL) {
+Status = mIoMmu->Map (
+   mIoMmu,
+   Operation,
+   HostAddress,
+   NumberOfBytes,
+   DeviceAddress,
+   Mapping
+   );
+if (EFI_ERROR (Status)) {
+  return EFI_OUT_OF_RESOURCES;
+}
+switch (Operation) {
+case EdkiiIoMmuOperationBusMasterRead:
+case EdkiiIoMmuOperationBusMasterRead64:
+  Attribute = EDKII_IOMMU_ACCESS_READ;
+  break;
+case EdkiiIoMmuOperationBusMasterWrite:
+case EdkiiIoMmuOperationBusMasterWrite64:
+  Attribute = EDKII_IOMMU_ACCESS_WRITE;
+  break;
+case EdkiiIoMmuOperationBusMasterCommonBuffer:
+case EdkiiIoMmuOperationBusMasterCommonBuffer64:
+  Attribute = EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE;
+  break;
+default:
+  ASSERT(FALSE);
+  return EFI_INVALID_PARAMETER;
+}
+Status = mIoMmu->SetAttribute (
+   mIoMmu,
+   *Mapping,
+   Attribute
+   );
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+  } else {
+*DeviceAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)HostAddress;
+*Mapping = NULL;
+Status = EFI_SUCCESS;
+  }
+  return Status;
+}
+
+/**
+  Completes the Map() operation and releases any corresponding resources.
+
+  @param  Mapping   The mapping value returned from Map().
+
+  @retval EFI_SUCCESS   The range was unmapped.
+  @retval EFI_INVALID_PARAMETER Mapping is not a value that was returned by 
Map().
+  @retval EFI_DEVICE_ERROR  The data was not committed to the target 
system memory.
+**/
+EFI_STATUS
+IoMmuUnmap (
+  IN VOID  *Mapping
+  )
+{
+  EFI_STATUS  

[edk2] [PATCH 0/2] IoMMu support for SD/eMMC PEI stack

2017-10-30 Thread Hao Wu
The series adds the IoMMu support for the SD/eMMC PEI stack.

Cc: Star Zeng 
Cc: Jiewen Yao 

Hao Wu (2):
  MdeModulePkg/EmmcBlockIoPei: Support IoMmu
  MdeModulePkg/SdBlockIoPei: Support IoMmu

 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/DmaMem.c   | 249 

 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcBlockIoPei.c   |  44 +++-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcBlockIoPei.h   | 141 ++-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcBlockIoPei.inf |   5 +-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHcMem.c|  23 +-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHcMem.h|   4 +-
 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/EmmcHci.c  |  36 ++-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/DmaMem.c | 249 

 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdBlockIoPei.c   |  44 +++-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdBlockIoPei.h   | 141 ++-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdBlockIoPei.inf |   5 +-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHcMem.c|  23 +-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHcMem.h|   4 +-
 MdeModulePkg/Bus/Sd/SdBlockIoPei/SdHci.c  |  36 ++-
 14 files changed, 966 insertions(+), 38 deletions(-)
 create mode 100644 MdeModulePkg/Bus/Sd/EmmcBlockIoPei/DmaMem.c
 create mode 100644 MdeModulePkg/Bus/Sd/SdBlockIoPei/DmaMem.c

-- 
2.12.0.windows.1

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


[edk2] [platforms: PATCH 4/6] Marvell/Applications: SpiTool: Do not override existing slave device

2017-10-30 Thread Marcin Wojtas
Current usage of sf command requires running 'sf probe' prior to
executing any other option. Because it is done in two separate steps,
it turned out that SpiMasterProtocol->SetupDevice could easily
overwrite valid Slave pointer when performing second operation.

Fix the issue by allocating Slave device only once and keep it
as global variable in the SpiTool application. This patch
also updates FirmwareUpdate command to follow the modified
SetupDevice operation.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c |  4 ++--
 Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c|  8 
 Platform/Marvell/Drivers/Spi/MvSpiDxe.c| 17 +
 Platform/Marvell/Drivers/Spi/MvSpiDxe.h|  1 +
 Platform/Marvell/Include/Protocol/Spi.h|  1 +
 5 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c 
b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c
index 750e52a..9ccb1c7 100644
--- a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c
+++ b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c
@@ -240,7 +240,7 @@ ShellCommandRunFUpdate (
   )
 {
   IN SHELL_FILE_HANDLEFileHandle;
-  SPI_DEVICE  *Slave;
+  SPI_DEVICE  *Slave = NULL;
   UINT64  FileSize;
   UINTN   *FileBuffer = NULL;
   CHAR16  *ProblemParam;
@@ -302,7 +302,7 @@ ShellCommandRunFUpdate (
   }
 
   // Setup and probe SPI flash
-  Slave = SpiMasterProtocol->SetupDevice (SpiMasterProtocol, 0, 0);
+  Slave = SpiMasterProtocol->SetupDevice (SpiMasterProtocol, Slave, 0, 0);
   if (Slave == NULL) {
 Print(L"%s: Cannot allocate SPI device!\n", CMD_NAME_STRING);
 goto HeaderError;
diff --git a/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c 
b/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c
index 68a6cf7..1084f68 100644
--- a/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c
+++ b/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c
@@ -191,7 +191,7 @@ ShellCommandRunSpiFlash (
   )
 {
 EFI_STATUS  Status;
-  SPI_DEVICE*Slave;
+  STATIC SPI_DEVICE *Slave;
   LIST_ENTRY*CheckPackage;
   EFI_PHYSICAL_ADDRESS  Address = 0, Offset = 0;
   SHELL_FILE_HANDLE FileHandle = NULL;
@@ -273,7 +273,7 @@ EFI_STATUS  Status;
   Cs = PcdGet32 (PcdSpiFlashCs);
 
   // Setup new spi device
-  Slave = SpiMasterProtocol->SetupDevice (SpiMasterProtocol, Cs, Mode);
+  Slave = SpiMasterProtocol->SetupDevice (SpiMasterProtocol, Slave, Cs, Mode);
 if (Slave == NULL) {
   Print(L"sf: Cannot allocate SPI device!\n");
   return SHELL_ABORTED;
@@ -285,6 +285,8 @@ EFI_STATUS  Status;
 Status = FlashProbe (Slave);
 if (EFI_ERROR(Status)) {
   // No supported spi flash detected
+  SpiMasterProtocol->FreeDevice(Slave);
+  Slave = NULL;
   return SHELL_ABORTED;
 } else {
   return Status;
@@ -426,8 +428,6 @@ EFI_STATUS  Status;
 break;
   }
 
-  SpiMasterProtocol->FreeDevice(Slave);
-
   if (EFI_ERROR (Status)) {
 Print (L"sf: Error while performing spi transfer\n");
 return SHELL_ABORTED;
diff --git a/Platform/Marvell/Drivers/Spi/MvSpiDxe.c 
b/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
index 3b49147..a7db5f2 100755
--- a/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
+++ b/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
@@ -296,21 +296,22 @@ SPI_DEVICE *
 EFIAPI
 MvSpiSetupSlave (
   IN MARVELL_SPI_MASTER_PROTOCOL *This,
+  IN SPI_DEVICE *Slave,
   IN UINTN Cs,
   IN SPI_MODE Mode
   )
 {
-  SPI_DEVICE  *Slave;
+  if (!Slave) {
+Slave = AllocateZeroPool (sizeof(SPI_DEVICE));
+if (Slave == NULL) {
+  DEBUG((DEBUG_ERROR, "Cannot allocate memory\n"));
+  return NULL;
+}
 
-  Slave = AllocateZeroPool (sizeof(SPI_DEVICE));
-  if (Slave == NULL) {
-DEBUG((DEBUG_ERROR, "Cannot allocate memory\n"));
-return NULL;
+Slave->Cs   = Cs;
+Slave->Mode = Mode;
   }
 
-  Slave->Cs   = Cs;
-  Slave->Mode = Mode;
-
   SpiSetupTransfer (This, Slave);
 
   return Slave;
diff --git a/Platform/Marvell/Drivers/Spi/MvSpiDxe.h 
b/Platform/Marvell/Drivers/Spi/MvSpiDxe.h
index 1401f62..e7e280a 100644
--- a/Platform/Marvell/Drivers/Spi/MvSpiDxe.h
+++ b/Platform/Marvell/Drivers/Spi/MvSpiDxe.h
@@ -125,6 +125,7 @@ SPI_DEVICE *
 EFIAPI
 MvSpiSetupSlave (
   IN MARVELL_SPI_MASTER_PROTOCOL * This,
+  IN SPI_DEVICE *Slave,
   IN UINTN Cs,
   IN SPI_MODE Mode
   );
diff --git a/Platform/Marvell/Include/Protocol/Spi.h 
b/Platform/Marvell/Include/Protocol/Spi.h
index 93a8ec0..0cf7914 100644
--- a/Platform/Marvell/Include/Protocol/Spi.h
+++ b/Platform/Marvell/Include/Protocol/Spi.h
@@ -87,6 +87,7 @@ typedef
 SPI_DEVICE *
 (EFIAPI *MV_SPI_SETUP_DEVICE) (
   IN MARVELL_SPI_MASTER_PROTOCOL *This,
+  IN SPI_DEVICE *Slave,
   IN UINTNCs,
   

[edk2] [platforms: PATCH 5/6] Marvell/Drivers: MvSpiFlash: Fix bank selection for Spansion

2017-10-30 Thread Marcin Wojtas
Spansion SPI flash devices use different command for bank
selection. Update it, basing on the first byte of flash ID.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c | 5 +
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h | 4 
 2 files changed, 9 insertions(+)

diff --git a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c 
b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
index 703994c..a00fc305 100755
--- a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
+++ b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
@@ -150,6 +150,11 @@ SpiFlashCmdBankaddrWrite (
 {
   UINT8 Cmd = CMD_BANK_WRITE;
 
+  /* Update bank selection command for Spansion */
+  if (Slave->Info->Id[0] == SPI_FLASH_MFR_SPANSION) {
+Cmd = CMD_BANKADDR_BRWR;
+  }
+
   MvSpiFlashWriteCommon (Slave, , 1, , 1);
 }
 
diff --git a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h 
b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
index 2583484..00af188 100755
--- a/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
+++ b/Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
@@ -57,6 +57,7 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #define CMD_READ_ARRAY_FAST 0x0b
 #define CMD_PAGE_PROGRAM0x02
 #define CMD_BANK_WRITE  0xc5
+#define CMD_BANKADDR_BRWR   0x17
 #define CMD_ERASE_4K0x20
 #define CMD_ERASE_32K   0x52
 #define CMD_ERASE_64K   0xd8
@@ -72,6 +73,9 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 #define SPI_FLASH_16MB_BOUN 0x100
 
+/* Manufacturer ID's */
+#define SPI_FLASH_MFR_SPANSION  0x01
+
 typedef enum {
   SPI_FLASH_READ_ID,
   SPI_FLASH_READ, // Read from SPI flash with address
-- 
2.7.4

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


[edk2] [platforms: PATCH 6/6] Marvell/Drivers: MvSpiDxe: Keep data in SPI_DEVICE structure

2017-10-30 Thread Marcin Wojtas
In the MvSpiDxe driver obtaining host register base address,
controller clock and device maximum frequency directly from PCDs
was done all over the code. This patch cleans up the parameters'
handling and enables accessing them from SPI_DEVICE structure fields.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Drivers/Spi/MvSpiDxe.c | 48 
 Platform/Marvell/Include/Protocol/Spi.h |  2 +
 2 files changed, 31 insertions(+), 19 deletions(-)

diff --git a/Platform/Marvell/Drivers/Spi/MvSpiDxe.c 
b/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
index a7db5f2..c60a520 100755
--- a/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
+++ b/Platform/Marvell/Drivers/Spi/MvSpiDxe.c
@@ -38,12 +38,13 @@ SPI_MASTER *mSpiMasterInstance;
 STATIC
 EFI_STATUS
 SpiSetBaudRate (
+  IN SPI_DEVICE *Slave,
   IN UINT32 CpuClock,
   IN UINT32 MaxFreq
   )
 {
   UINT32 Spr, BestSpr, Sppr, BestSppr, ClockDivider, Match, Reg, MinBaudDiff;
-  UINTN SpiRegBase = PcdGet32 (PcdSpiRegBase);
+  UINTN SpiRegBase = Slave->HostRegisterBaseAddress;
 
   MinBaudDiff = 0x;
   BestSppr = 0;
@@ -93,26 +94,28 @@ SpiSetBaudRate (
 STATIC
 VOID
 SpiSetCs (
-  UINT8 CsId
+  IN SPI_DEVICE *Slave
   )
 {
-  UINT32 Reg, SpiRegBase = PcdGet32 (PcdSpiRegBase);
+  UINT32 Reg;
+  UINTN  SpiRegBase = Slave->HostRegisterBaseAddress;
 
   Reg = MmioRead32 (SpiRegBase + SPI_CTRL_REG);
   Reg &= ~SPI_CS_NUM_MASK;
-  Reg |= (CsId << SPI_CS_NUM_OFFSET);
+  Reg |= (Slave->Cs << SPI_CS_NUM_OFFSET);
   MmioWrite32 (SpiRegBase + SPI_CTRL_REG, Reg);
 }
 
 STATIC
 VOID
 SpiActivateCs (
-  UINT8 IN CsId
+  IN SPI_DEVICE *Slave
   )
 {
-  UINT32  Reg, SpiRegBase = PcdGet32 (PcdSpiRegBase);
+  UINT32 Reg;
+  UINTN  SpiRegBase = Slave->HostRegisterBaseAddress;
 
-  SpiSetCs(CsId);
+  SpiSetCs(Slave);
   Reg = MmioRead32 (SpiRegBase + SPI_CTRL_REG);
   Reg |= SPI_CS_EN_MASK;
   MmioWrite32(SpiRegBase + SPI_CTRL_REG, Reg);
@@ -121,10 +124,11 @@ SpiActivateCs (
 STATIC
 VOID
 SpiDeactivateCs (
-  VOID
+  IN SPI_DEVICE *Slave
   )
 {
-  UINT32  Reg, SpiRegBase = PcdGet32 (PcdSpiRegBase);
+  UINT32 Reg;
+  UINTN  SpiRegBase = Slave->HostRegisterBaseAddress;
 
   Reg = MmioRead32 (SpiRegBase + SPI_CTRL_REG);
   Reg &= ~SPI_CS_EN_MASK;
@@ -139,14 +143,15 @@ SpiSetupTransfer (
   )
 {
   SPI_MASTER *SpiMaster;
-  UINT32 Reg, SpiRegBase, CoreClock, SpiMaxFreq;
+  UINT32 Reg, CoreClock, SpiMaxFreq;
+  UINTN SpiRegBase;
 
   SpiMaster = SPI_MASTER_FROM_SPI_MASTER_PROTOCOL (This);
 
   // Initialize values from PCDs
-  SpiRegBase  = PcdGet32 (PcdSpiRegBase);
-  CoreClock   = PcdGet32 (PcdSpiClockFrequency);
-  SpiMaxFreq  = PcdGet32 (PcdSpiMaxFrequency);
+  SpiRegBase  = Slave->HostRegisterBaseAddress;
+  CoreClock   = Slave->CoreClock;
+  SpiMaxFreq  = Slave->MaxFreq;
 
   EfiAcquireLock (>Lock);
 
@@ -154,9 +159,9 @@ SpiSetupTransfer (
   Reg |= SPI_BYTE_LENGTH;
   MmioWrite32 (SpiRegBase + SPI_CONF_REG, Reg);
 
-  SpiSetCs(Slave->Cs);
+  SpiSetCs(Slave);
 
-  SpiSetBaudRate (CoreClock, SpiMaxFreq);
+  SpiSetBaudRate (Slave, CoreClock, SpiMaxFreq);
 
   Reg = MmioRead32 (SpiRegBase + SPI_CONF_REG);
   Reg &= ~(SPI_CPOL_MASK | SPI_CPHA_MASK | SPI_TXLSBF_MASK | SPI_RXLSBF_MASK);
@@ -194,21 +199,22 @@ MvSpiTransfer (
 {
   SPI_MASTER *SpiMaster;
   UINT64  Length;
-  UINT32  Iterator, Reg, SpiRegBase;
+  UINT32  Iterator, Reg;
   UINT8   *DataOutPtr = (UINT8 *)DataOut;
   UINT8   *DataInPtr  = (UINT8 *)DataIn;
   UINT8   DataToSend  = 0;
+  UINTN   SpiRegBase;
 
   SpiMaster = SPI_MASTER_FROM_SPI_MASTER_PROTOCOL (This);
 
-  SpiRegBase = PcdGet32 (PcdSpiRegBase);
+  SpiRegBase = Slave->HostRegisterBaseAddress;
 
   Length = 8 * DataByteCount;
 
   EfiAcquireLock (>Lock);
 
   if (Flag & SPI_TRANSFER_BEGIN) {
-SpiActivateCs (Slave->Cs);
+SpiActivateCs (Slave);
   }
 
   // Set 8-bit mode
@@ -245,7 +251,7 @@ MvSpiTransfer (
   }
 
   if (Flag & SPI_TRANSFER_END) {
-SpiDeactivateCs ();
+SpiDeactivateCs (Slave);
   }
 
   EfiReleaseLock (>Lock);
@@ -312,6 +318,10 @@ MvSpiSetupSlave (
 Slave->Mode = Mode;
   }
 
+  Slave->HostRegisterBaseAddress = PcdGet32 (PcdSpiRegBase);
+  Slave->CoreClock = PcdGet32 (PcdSpiClockFrequency);
+  Slave->MaxFreq = PcdGet32 (PcdSpiMaxFrequency);
+
   SpiSetupTransfer (This, Slave);
 
   return Slave;
diff --git a/Platform/Marvell/Include/Protocol/Spi.h 
b/Platform/Marvell/Include/Protocol/Spi.h
index 0cf7914..b8981f3 100644
--- a/Platform/Marvell/Include/Protocol/Spi.h
+++ b/Platform/Marvell/Include/Protocol/Spi.h
@@ -52,6 +52,8 @@ typedef struct {
   INTN MaxFreq;
   SPI_MODE Mode;
   NOR_FLASH_INFO *Info;
+  UINTN HostRegisterBaseAddress;
+  UINTN CoreClock;
 } SPI_DEVICE;
 
 typedef
-- 
2.7.4

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


[edk2] [platforms: PATCH 2/6] Marvell/Drivers: MvSpiFlash: Enable dynamic SPI Flash detection

2017-10-30 Thread Marcin Wojtas
Hitherto mechanism of fixing SPI flash model in the PCDs,
occured to be very inefficient and problematic. Enable
dynamic detection by reworking MvSpiFlashReadId() command,
which now uses newly added NorFlashInfoLib, that helps to
obtain description of the JEDEC compliant devices.

This patch updates the MvSpiFlashProtocol ReadId() protocol
callback on both producer's (MvFlashDxe) and consumers' sides
(FirmwareUpdate and SpiTool applications). Because all
information about detected SPI NOR flash is now stored in
the obtained NorFlashInfo structure fields, use them instead
of the PCDs.

Enable compilation of the NorFlashInfoLib and update
PortingGuide documentation accordingly.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c   |  5 +-
 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.inf |  4 +-
 Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c  |  5 +-
 Platform/Marvell/Applications/SpiTool/SpiFlashCmd.inf|  2 +-
 Platform/Marvell/Armada/Armada.dsc.inc   |  1 +
 Platform/Marvell/Armada/Armada70x0.dsc   |  5 --
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c| 68 
+++-
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf  |  9 +--
 Platform/Marvell/Drivers/Spi/MvSpiDxe.inf|  2 +
 Platform/Marvell/Include/Protocol/Spi.h  |  3 +
 Platform/Marvell/Include/Protocol/SpiFlash.h |  6 +-
 Platform/Marvell/Marvell.dec |  6 --
 Silicon/Marvell/Documentation/PortingGuide.txt   | 18 --
 13 files changed, 51 insertions(+), 83 deletions(-)

diff --git a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c 
b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c
index d70645d..750e52a 100644
--- a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c
+++ b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c
@@ -94,12 +94,9 @@ SpiFlashProbe (
   )
 {
   EFI_STATUS   Status;
-  UINT8   *FlashId;
-
-  FlashId = (UINT8 *)PcdGetPtr (PcdSpiFlashId);
 
   // Read SPI flash ID
-  Status = SpiFlashProtocol->ReadId (Slave, NOR_FLASH_ID_DEFAULT_LEN, FlashId);
+  Status = SpiFlashProtocol->ReadId (Slave, FALSE);
   if (EFI_ERROR (Status)) {
 return SHELL_ABORTED;
   }
diff --git a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.inf 
b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.inf
index 92c..53ea491 100644
--- a/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.inf
+++ b/Platform/Marvell/Applications/FirmwareUpdate/FUpdate.inf
@@ -44,6 +44,7 @@
   FUpdate.uni
 
 [Packages]
+  EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   Platform/Marvell/Marvell.dec
@@ -64,9 +65,6 @@
   UefiLib
   UefiRuntimeServicesTableLib
 
-[Pcd]
- gMarvellTokenSpaceGuid.PcdSpiFlashId
-
 [Protocols]
  gMarvellSpiFlashProtocolGuid
  gMarvellSpiMasterProtocolGuid
diff --git a/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c 
b/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c
index a12f2ec..68a6cf7 100644
--- a/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c
+++ b/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c
@@ -166,11 +166,8 @@ FlashProbe (
   )
 {
   EFI_STATUS Status;
-  UINT8  *FlashId;
 
-  FlashId = (UINT8 *)PcdGetPtr (PcdSpiFlashId);
-
-  Status = SpiFlashProtocol->ReadId (Slave, NOR_FLASH_ID_DEFAULT_LEN, FlashId);
+  Status = SpiFlashProtocol->ReadId (Slave, FALSE);
   if (EFI_ERROR (Status)) {
 return SHELL_ABORTED;
   }
diff --git a/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.inf 
b/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.inf
index 887b9a5..a52906b 100644
--- a/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.inf
+++ b/Platform/Marvell/Applications/SpiTool/SpiFlashCmd.inf
@@ -44,6 +44,7 @@
  SpiFlashCmd.uni
 
 [Packages]
+ EmbeddedPkg/EmbeddedPkg.dec
  MdePkg/MdePkg.dec
  ShellPkg/ShellPkg.dec
  MdeModulePkg/MdeModulePkg.dec
@@ -66,7 +67,6 @@
 
 [Pcd]
  gMarvellTokenSpaceGuid.PcdSpiFlashCs
- gMarvellTokenSpaceGuid.PcdSpiFlashId
  gMarvellTokenSpaceGuid.PcdSpiFlashMode
 
 [Protocols]
diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index b9fc384..2cd96e6 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -33,6 +33,7 @@
   
ArmPlatformLib|Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
   ComPhyLib|Platform/Marvell/Library/ComPhyLib/ComPhyLib.inf
   MppLib|Platform/Marvell/Library/MppLib/MppLib.inf
+  NorFlashInfoLib|EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.inf
   UtmiPhyLib|Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf
 
   DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
diff --git a/Platform/Marvell/Armada/Armada70x0.dsc 
b/Platform/Marvell/Armada/Armada70x0.dsc
index 4d5f55f..8e4cdb2 100644
--- 

[edk2] [platforms: PATCH 3/6] Marvell/Drivers: MvSpiFlash: Remove duplicated macros

2017-10-30 Thread Marcin Wojtas
Flash commands macros are already defined locally, so
remove them from the protocol header.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Include/Protocol/SpiFlash.h | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/Platform/Marvell/Include/Protocol/SpiFlash.h 
b/Platform/Marvell/Include/Protocol/SpiFlash.h
index 4a3053e..4ba29ba 100644
--- a/Platform/Marvell/Include/Protocol/SpiFlash.h
+++ b/Platform/Marvell/Include/Protocol/SpiFlash.h
@@ -36,17 +36,6 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 #include 
 
-#define CMD_READ_ID 0x9f
-#define READ_STATUS_REG_CMD 0x0b
-#define CMD_WRITE_ENABLE0x06
-#define CMD_FLAG_STATUS 0x70
-#define CMD_WRITE_STATUS_REG0x01
-#define CMD_READ_ARRAY_FAST 0x0b
-#define CMD_PAGE_PROGRAM0x02
-#define CMD_BANK_WRITE  0xc5
-#define CMD_ERASE_64K   0xd8
-#define CMD_4B_ADDR_ENABLE  0xb7
-
 extern EFI_GUID gMarvellSpiFlashProtocolGuid;
 
 typedef struct _MARVELL_SPI_FLASH_PROTOCOL MARVELL_SPI_FLASH_PROTOCOL;
-- 
2.7.4

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


[edk2] [platforms: PATCH 0/6] Armada 7k/8k SPI improvements pt 2.

2017-10-30 Thread Marcin Wojtas
Hi,

I submit a series, which comprises a major rework allowing
to make use of dynamic SPI NOR flash detection with recently
implemented NorFlashInfoLib. Comparing to initial version
of the patches, apart from the flash info table extraction,
also the functional changes around ReadId are taken into
a separate commit. This, I hope, results in readable patchset.

Patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/spi-upstream-r20171031
NorFlashInfoLib:
https://github.com/MarvellEmbeddedProcessors/edk2/commits/norlib-upstream-r20171030

I'm looking forward to the comments or remarks.

Best regards,
Marcin

Marcin Wojtas (6):
  Marvell/Drivers: MvSpiFlash: Improve ReadId
  Marvell/Drivers: MvSpiFlash: Enable dynamic SPI Flash detection
  Marvell/Drivers: MvSpiFlash: Remove duplicated macros
  Marvell/Applications: SpiTool: Do not override existing slave device
  Marvell/Drivers: MvSpiFlash: Fix bank selection for Spansion
  Marvell/Drivers: MvSpiDxe: Keep data in SPI_DEVICE structure

 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.c   |  25 +
 Platform/Marvell/Applications/FirmwareUpdate/FUpdate.inf |   4 +-
 Platform/Marvell/Applications/SpiTool/SpiFlashCmd.c  |  44 +++-
 Platform/Marvell/Applications/SpiTool/SpiFlashCmd.inf|   2 +-
 Platform/Marvell/Armada/Armada.dsc.inc   |   1 +
 Platform/Marvell/Armada/Armada70x0.dsc   |   5 -
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.c| 108 

 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.h|   6 ++
 Platform/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf  |   9 +-
 Platform/Marvell/Drivers/Spi/MvSpiDxe.c  |  63 +++-
 Platform/Marvell/Drivers/Spi/MvSpiDxe.h  |   1 +
 Platform/Marvell/Drivers/Spi/MvSpiDxe.inf|   2 +
 Platform/Marvell/Include/Protocol/Spi.h  |   6 ++
 Platform/Marvell/Include/Protocol/SpiFlash.h |  14 +--
 Platform/Marvell/Marvell.dec |   6 --
 Silicon/Marvell/Documentation/PortingGuide.txt   |  18 
 16 files changed, 141 insertions(+), 173 deletions(-)

-- 
2.7.4

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


[edk2] [PATCH v2] MdeModulePkg/UfsBlockIoPei: Support IoMmu

2017-10-30 Thread Hao Wu
V2 changes:
Resource cleanup logic update in UfsEndOfPei().

V1 history:
Update the UfsBlockIoPei driver to consume IOMMU_PPI to allocate DMA
buffer.

If no IOMMU_PPI exists, this driver still calls PEI service
to allocate DMA buffer, with assumption that DRAM==DMA.

This is a compatible change.

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c  | 249 
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c   |  60 -
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.h   | 141 ++-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.inf |   5 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.c|  23 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHcMem.h|   4 +-
 MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsHci.c  |  91 +--
 7 files changed, 535 insertions(+), 38 deletions(-)

diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c 
b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
new file mode 100644
index 00..0a939a3879
--- /dev/null
+++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/DmaMem.c
@@ -0,0 +1,249 @@
+/** @file
+  The DMA memory help function.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions
+  of the BSD License which accompanies this distribution.  The
+  full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "UfsBlockIoPei.h"
+
+EDKII_IOMMU_PPI  *mIoMmu;
+
+/**
+  Provides the controller-specific addresses required to access system memory 
from a
+  DMA bus master.
+
+  @param  Operation Indicates if the bus master is going to read 
or write to system memory.
+  @param  HostAddress   The system memory address to map to the PCI 
controller.
+  @param  NumberOfBytes On input the number of bytes to map. On output 
the number of bytes
+that were mapped.
+  @param  DeviceAddress The resulting map address for the bus master 
PCI controller to use to
+access the hosts HostAddress.
+  @param  Mapping   A resulting value to pass to Unmap().
+
+  @retval EFI_SUCCESS   The range was mapped for the returned 
NumberOfBytes.
+  @retval EFI_UNSUPPORTED   The HostAddress cannot be mapped as a common 
buffer.
+  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+  @retval EFI_DEVICE_ERROR  The system hardware could not map the 
requested address.
+
+**/
+EFI_STATUS
+IoMmuMap (
+  IN  EDKII_IOMMU_OPERATION Operation,
+  IN VOID   *HostAddress,
+  IN  OUT UINTN *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  )
+{
+  EFI_STATUS  Status;
+  UINT64  Attribute;
+
+  if (mIoMmu != NULL) {
+Status = mIoMmu->Map (
+   mIoMmu,
+   Operation,
+   HostAddress,
+   NumberOfBytes,
+   DeviceAddress,
+   Mapping
+   );
+if (EFI_ERROR (Status)) {
+  return EFI_OUT_OF_RESOURCES;
+}
+switch (Operation) {
+case EdkiiIoMmuOperationBusMasterRead:
+case EdkiiIoMmuOperationBusMasterRead64:
+  Attribute = EDKII_IOMMU_ACCESS_READ;
+  break;
+case EdkiiIoMmuOperationBusMasterWrite:
+case EdkiiIoMmuOperationBusMasterWrite64:
+  Attribute = EDKII_IOMMU_ACCESS_WRITE;
+  break;
+case EdkiiIoMmuOperationBusMasterCommonBuffer:
+case EdkiiIoMmuOperationBusMasterCommonBuffer64:
+  Attribute = EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE;
+  break;
+default:
+  ASSERT(FALSE);
+  return EFI_INVALID_PARAMETER;
+}
+Status = mIoMmu->SetAttribute (
+   mIoMmu,
+   *Mapping,
+   Attribute
+   );
+if (EFI_ERROR (Status)) {
+  return Status;
+}
+  } else {
+*DeviceAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)HostAddress;
+*Mapping = NULL;
+Status = EFI_SUCCESS;
+  }
+  return Status;
+}
+
+/**
+  Completes the Map() operation and releases any corresponding resources.
+
+  @param  Mapping   The mapping value returned from Map().
+
+  @retval EFI_SUCCESS   The range was unmapped.
+  @retval EFI_INVALID_PARAMETER Mapping is not a value that was returned by 
Map().
+  @retval EFI_DEVICE_ERROR  The data was not committed to the target 

[edk2] [PATCH v2] MdePkg: Add definitions for the SPI protocols introduced in PI 1.6.

2017-10-30 Thread Marvin Häuser
This commit adds header files for the SPI protocols introduced in the
UEFI PI 1.6 specification, as well as their GUIDs to MdePkg.dec.

EFI_SPI_TRANSACTION_TYPE assumes an enum with its members ordered the
way they are listed in the specification, as there are no values given
explicitely.
EFI_LEGACY_SPI_CONTROLLER_GUID assumes the character 'l' used in the
specification was meant to be '1'.

V2:
- Fixed LegacySpiFlash.h's header guard.
- Fixed LegacySpiSmmController's GUID name.
- Removed EFI_SPI_NOR_FLASH_PROTOCOL_LF_READ_DATA as it's unused.
- Added the missing SpiSmmNorFlash header.
- Fixed all file endings to be CRLF.
- Removed trailing whitespaces.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/LegacySpiController.h| 265 ++
 MdePkg/Include/Protocol/LegacySpiFlash.h | 201 ++
 MdePkg/Include/Protocol/LegacySpiSmmController.h |  36 +++
 MdePkg/Include/Protocol/LegacySpiSmmFlash.h  |  36 +++
 MdePkg/Include/Protocol/SpiConfiguration.h   | 293 
 MdePkg/Include/Protocol/SpiHc.h  | 194 +
 MdePkg/Include/Protocol/SpiIo.h  | 292 +++
 MdePkg/Include/Protocol/SpiNorFlash.h| 262 +
 MdePkg/Include/Protocol/SpiSmmConfiguration.h|  36 +++
 MdePkg/Include/Protocol/SpiSmmHc.h   |  36 +++
 MdePkg/Include/Protocol/SpiSmmNorFlash.h |  36 +++
 MdePkg/MdePkg.dec|  34 +++
 12 files changed, 1721 insertions(+)

diff --git a/MdePkg/Include/Protocol/LegacySpiController.h 
b/MdePkg/Include/Protocol/LegacySpiController.h
new file mode 100644
index ..7f6b07ec42e9
--- /dev/null
+++ b/MdePkg/Include/Protocol/LegacySpiController.h
@@ -0,0 +1,265 @@
+/** @file
+  This file defines the Legacy SPI Controller Protocol.
+
+  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD
+  License which accompanies this distribution. The full text of the license may
+  be found at http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+  @par Revision Reference:
+This Protocol was introduced in UEFI PI Specification 1.6.
+
+**/
+
+#ifndef __LEGACY_SPI_CONTROLLER_PROTOCOL_H__
+#define __LEGACY_SPI_CONTROLLER_PROTOCOL_H__
+
+///
+/// Note: The UEFI PI 1.6 specification uses the character 'l' in the GUID
+///   definition. This definition assumes it was supposed to be '1'.
+///
+/// Global ID for the Legacy SPI Controller Protocol
+///
+#define EFI_LEGACY_SPI_CONTROLLER_GUID  \
+  { 0x39136fc7, 0x1a11, 0x49de, \
+{ 0xbf, 0x35, 0x0e, 0x78, 0xdd, 0xb5, 0x24, 0xfc }}
+
+typedef
+struct _EFI_LEGACY_SPI_CONTROLLER_PROTOCOL
+EFI_LEGACY_SPI_CONTROLLER_PROTOCOL;
+
+/**
+  Set the erase block opcode.
+
+  This routine must be called at or below TPL_NOTIFY.
+  The menu table contains SPI transaction opcodes which are accessible after
+  the legacy SPI flash controller's configuration is locked. The board layer
+  specifies the erase block size for the SPI NOR flash part. The SPI NOR flash
+  peripheral driver selects the erase block opcode which matches the erase
+  block size and uses this API to load the opcode into the opcode menu table.
+
+  @param[in] This  Pointer to an EFI_LEGACY_SPI_CONTROLLER_PROTOCOL
+   structure.
+  @param[in] EraseBlockOpcode  Erase block opcode to be placed into the opcode
+   menu table.
+
+  @retval EFI_SUCCESS   The opcode menu table was updated
+  @retval EFI_ACCESS_ERROR  The SPI controller is locked
+
+**/
+typedef EFI_STATUS
+(EFIAPI *EFI_LEGACY_SPI_CONTROLLER_PROTOCOL_ERASE_BLOCK_OPCODE) (
+  IN CONST EFI_LEGACY_SPI_CONTROLLER_PROTOCOL  *This,
+  IN UINT8 EraseBlockOpcode
+  );
+
+/**
+  Set the write status prefix opcode.
+
+  This routine must be called at or below TPL_NOTIFY.
+  The prefix table contains SPI transaction write prefix opcodes which are
+  accessible after the legacy SPI flash controller's configuration is locked.
+  The board layer specifies the write status prefix opcode for the SPI NOR
+  flash part. The SPI NOR flash peripheral driver uses this API to load the
+  opcode into the prefix table.
+
+  @param[in] This   Pointer to an
+EFI_LEGACY_SPI_CONTROLLER_PROTOCOL structure.
+  @param[in] WriteStatusPrefix  Prefix opcode for the write status command.
+
+  @retval EFI_SUCCESS   The prefix table was updated
+  @retval EFI_ACCESS_ERROR  The SPI controller is locked
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI 

Re: [edk2] Storing Non volatile variables on SD/NAND

2017-10-30 Thread Jeremy Linton

Hi,

On 10/27/2017 10:09 PM, Udit Kumar wrote:

(along those lines)

6 - Build an emulated disk controller as well as NV region in el3 (or
el2) and export them to UEFI & the OS as real devices. Then trap/forward
requests to the actual storage device, which is "hidden". This AFAIK was the
basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high
performance option.


You mean, have a driver in el3 or el2 and UEFI or OS is doing smc call to get 
things done.
On this line,  some sort of permission manager could reside in el3 or el2.
Either UEFI or OS driver needs to make a call, if they are allowed to access 
this
specific controller or other driver is accessing it.
With this  performance issue could be ironed out .


That isn't really what I meant, what I was thinking about was creating 
an emulated (AHCI for example) controller where accesses to the 
"register" space would trap to synchronous data/external aborts. That 
way the firmware and OS could use existing drivers without knowledge 
that the device was in any way special. If you create a driver and do 
SMC/whatever calls, then your basically doing #5..







Regards
Udit


-Original Message-
From: Jeremy Linton [mailto:jeremy.lin...@arm.com]
Sent: Friday, October 27, 2017 11:16 PM
To: Ard Biesheuvel ; Udit Kumar

Cc: edk2-devel@lists.01.org; Andrew Fish ;
olivier.mar...@arm.com; Vladimir Olovyannikov

Subject: Re: [edk2] Storing Non volatile variables on SD/NAND

On 09/20/2017 12:39 PM, Ard Biesheuvel wrote:

On 20 September 2017 at 10:34, Udit Kumar  wrote:


When we want to have UEFI and OS accessing same media , Possibilities
I see

1- Patch OS For status check of media (diversion from generic OS), Good case

will be modify low level driver.

But we may end up some surprises on synchronization.

2- no runtime service for OS . I guess this will not be possible

3- Way the  Vladimir implemented for eMMC, This has risk of losing data in

case of AC power off.


4- update hardware with dual view (Ard suggestion)



5 - abstract direct block device access into a firmware service that
is exposed via a DXE_RUNTIME_DRIVER.


(along those lines)

6 - Build an emulated disk controller as well as NV region in el3 (or
el2) and export them to UEFI & the OS as real devices. Then trap/forward
requests to the actual storage device, which is "hidden". This AFAIK was the
basic idea behind the PS/2 emulation in x86/SMM. Again, probably not a high
performance option.




The UEFI spec allows you to expose entry points into a
DXE_RUNTIME_DRIVER module via a UEFI configuration table, and the OS
can use a driver that uses the abstracted device rather than the real
device. Performance is going to be terrible, probably, and lots of
things that are specific to SD/MMC will no longer work, but it is a
possibility nonetheless.
___
edk2-devel mailing list
edk2-devel@lists.01.org


https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01
.org%2Fmailman%2Flistinfo%2Fedk2-
devel=02%7C01%7Cudit.kumar%40nxp.com%7Cfe11f07ea67a4efa7d1b08
d51d629deb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63644723
1755528994=FYnH3ItGhXmqxNr%2BnaJBFMcKKduf%2FcS06JEA6dT6ZQA
%3D=0






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


[edk2] [PATCH 1/1] EmbeddedPkg: Implement NorFlashLib

2017-10-30 Thread Marcin Wojtas
The SPI NOR flash drivers which base on ArmPlatformPkg's
NorFlashDxe usually make use of static declarations of the
flash instances with their type and parameters. As a result
it implies hardcoding the exact way flash handling, not to
mention the code does not look very nice. Much better solution
would be obtaining the flash ID and hence its description
in runtime.

Because JEDEC compliant SPI NOR devices allow to obtain their ID
with READ_ID command (0x9f), implement a NorFlashLib that gives
access to the NOR flash data, such as name, page size, sector
(block) size and others, of more than 50 different models.
The new library user should pass an output array issuing
READ_ID command to the GetNorFlashInfo () routine - if the
match is found, an allocated (optionally for RT) pool with
the flash description will be returned.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 EmbeddedPkg/EmbeddedPkg.dec |   1 +
 EmbeddedPkg/Include/Library/NorFlashInfoLib.h   |  84 
 EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c   | 225 

 EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.inf |  34 +++
 4 files changed, 344 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 52482af..aa551ab 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -45,6 +45,7 @@
   EblNetworkLib|Include/Library/EblNetworkLib.h
   GdbSerialLib|Include/Library/GdbSerialLib.h
   DebugAgentTimerLib|Include/Library/DebugAgentTimerLib.h
+  NorFlashInfoLib|Include/Library/NorFlashInfoLib.h
 
   DtPlatformDtbLoaderLib|Include/Library/DtPlatformDtbLoaderLib.h
 
diff --git a/EmbeddedPkg/Include/Library/NorFlashInfoLib.h 
b/EmbeddedPkg/Include/Library/NorFlashInfoLib.h
new file mode 100644
index 000..ae0e45f
--- /dev/null
+++ b/EmbeddedPkg/Include/Library/NorFlashInfoLib.h
@@ -0,0 +1,84 @@
+/** @file
+*
+*  Copyright (c) 2017 Marvell International Ltd.
+*
+*  This program and the accompanying materials
+*  are licensed and made available under the terms and conditions of the BSD 
License
+*  which accompanies this distribution.  The full text of the license may be 
found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#ifndef __NOR_FLASH_ID_LIB_H__
+#define __NOR_FLASH_ID_LIB_H__
+
+#include 
+
+#define NOR_FLASH_MAX_ID_LEN6
+
+typedef struct {
+  /* Device name */
+  UINT16 *Name;
+
+  /*
+   * JEDEC ID
+   */
+  UINT8  Id[NOR_FLASH_MAX_ID_LEN];
+  UINT8  IdLen;
+
+  UINT16 PageSize;
+
+  /*
+   * Below parameters can be referred as BlockSize
+   * and BlockCount, when treating the NorFlash as
+   * block device.
+   */
+  UINT32 SectorSize;
+  UINT32 SectorCount;
+
+  UINT16 Flags;
+#define NF_ERASE_4K  1 << 0  /* Use 4096B erase blocks and CMD_ERASE_4K */
+#define NF_WRITE_FSR 1 << 1  /* Use flag status register for write */
+#define NF_4B_ADDR   1 << 2  /* Use 4B addressing */
+} NOR_FLASH_INFO;
+
+/**
+  Return a pool allocated copy of the NOR flash .
+
+  @param[in]   Id Pointer to an array with JEDEC ID 
obtained
+  from the NOR flash with READ_ID command
+  (0x9f)
+  @param[in out]   FlashInfo  Pointer to NOR flash information 
structure
+  @param[in]   AllocateForRuntime A flag specifying a type of a copy pool
+  allocation (TRUE for runtime, FALSE for
+  normal)
+
+  @retval   EFI_SUCCESS   Operation completed successfully
+  @retval   EFI_NOT_FOUND No matching entry in NOR ID table found
+  @retval   EFI_OUT_OF_RESOURCES  No pool memory available
+
+**/
+EFI_STATUS
+EFIAPI
+GetNorFlashInfo (
+  IN UINT8*Id,
+  IN OUT NOR_FLASH_INFO  **FlashInfo,
+  IN BOOLEAN   AllocateForRuntime
+  );
+
+/**
+  Print NOR flash information basing on data stored in
+  the NOR_FLASH_INFO structure.
+
+  @param[in]   FlashInfo  Pointer to NOR flash information 
structure
+
+**/
+VOID
+EFIAPI
+PrintNorFlashInfo (
+  IN NOR_FLASH_INFO  *Info
+  );
+#endif
diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c 
b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
new file mode 100644
index 000..2185163
--- /dev/null
+++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
@@ -0,0 +1,225 @@
+/** @file
+*
+*  Copyright (c) 2017 Marvell International Ltd.
+*
+*  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
+*  

Re: [edk2] [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64

2017-10-30 Thread Ard Biesheuvel
On 30 October 2017 at 15:13, Heyi Guo  wrote:
> Hi Ard,
>
>
> On 10/30/2017 04:21 PM, Ard Biesheuvel wrote:
>>
>> On 30 October 2017 at 03:52, Heyi Guo  wrote:
>>>
>>> Hi folks,
>>>
>>> In NonDiscoverablePciDeviceDxe driver, NonCoherentPciIoAllocateBuffer may
>>> allocate EFI_MEMORY_UC buffer depending on input Attributes and GCD
>>> capabilities. If it does, it actually allocates memory of "device" type
>>> in
>>> AArch64, but not "normal uncacheable" memory. For "device" memory type,
>>> it
>>> requires restrict access alignment and it may trigger alignment fault
>>> exception with BaseMemoryLibOptDxe in which read/write alignment is not
>>> guaranteed.
>>>
>>> Is EFI_MOMORY_WC enough for AArch64 platforms? How about other platforms,
>>> like X86?
>>>
>> Hello Heyi,
>>
>> Do you mean EFI_MEMORY_UC in the last sentence? If not, I don't
>> understand the question.
>
> I actually meant EFI_MOMORY_WC for I supposed EFI_MOMORY_WC should be enough
> for AArch64 non cacheable DMA access.
>
>>
>> Anyway, in reality, this code will only allocate EFI_MEMORY_UC memory
>> if any memory already exists in the memory map with that capability,
>> otherwise it will fall back to EFI_MEMORY_WC. On most arm64 platforms,
>> we no longer add this capability to system memoryEFI_MOMORY_WC by default,
>> so you
>> should be getting EFI_MEMORY_WC in most cases.
>
>
> Oh, I supposed we always have UC capability for system memory and we
> actually still do that on D0x platforms. Does it mean we'd better remove
> this capability to get the issue fixed?

Yes.

> Is there any architectural reason
> for not setting UC capability on system memory?
>

Yes, exactly the reasons you mention: memory no longer behaves as
memory if you map it with EFI_MEMORY_UC attributes, i.e., unaligned
accesses or DC ZVA instructions can no longer be used.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64

2017-10-30 Thread Heyi Guo

Hi Ard,


On 10/30/2017 04:21 PM, Ard Biesheuvel wrote:

On 30 October 2017 at 03:52, Heyi Guo  wrote:

Hi folks,

In NonDiscoverablePciDeviceDxe driver, NonCoherentPciIoAllocateBuffer may
allocate EFI_MEMORY_UC buffer depending on input Attributes and GCD
capabilities. If it does, it actually allocates memory of "device" type in
AArch64, but not "normal uncacheable" memory. For "device" memory type, it
requires restrict access alignment and it may trigger alignment fault
exception with BaseMemoryLibOptDxe in which read/write alignment is not
guaranteed.

Is EFI_MOMORY_WC enough for AArch64 platforms? How about other platforms,
like X86?


Hello Heyi,

Do you mean EFI_MEMORY_UC in the last sentence? If not, I don't
understand the question.
I actually meant EFI_MOMORY_WC for I supposed EFI_MOMORY_WC should be 
enough for AArch64 non cacheable DMA access.




Anyway, in reality, this code will only allocate EFI_MEMORY_UC memory
if any memory already exists in the memory map with that capability,
otherwise it will fall back to EFI_MEMORY_WC. On most arm64 platforms,
we no longer add this capability to system memoryEFI_MOMORY_WC by default, so 
you
should be getting EFI_MEMORY_WC in most cases.


Oh, I supposed we always have UC capability for system memory and we 
actually still do that on D0x platforms. Does it mean we'd better remove 
this capability to get the issue fixed? Is there any architectural 
reason for not setting UC capability on system memory?


Thanks,

Heyi



So the question is actually the opposite: does this interfere with
correct operation in cases where the shared mapping between the CPU
and the device should be strongly ordered, and EFI_MEMORY_WC doesn't
give sufficient guarantees.



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


Re: [edk2] [PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

2017-10-30 Thread Heyi Guo

Hi Ray,

It seems Ard already provided his R-B :)

Thanks.

Heyi


On 10/30/2017 06:23 PM, Ni, Ruiyu wrote:

I will wait for Ard's feedback. It's an ARM specific module.

Thanks/Ray


-Original Message-
From: Zeng, Star
Sent: Monday, October 30, 2017 6:07 PM
To: Ni, Ruiyu ; Heyi Guo ; linaro-
u...@lists.linaro.org; edk2-devel@lists.01.org
Cc: Dong, Eric ; Ard Biesheuvel
; Zeng, Star 
Subject: RE: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory
override bug

Ray,
Please help take a review to this patch.


Thanks,
Star
-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org]
Sent: Monday, October 30, 2017 1:48 PM
To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
Cc: Heyi Guo ; Zeng, Star ;
Dong, Eric ; Ard Biesheuvel
; Ni, Ruiyu 
Subject: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory
override bug

For PciIoPciRead interface, memory prior to Buffer would be written with
zeros if Offset was larger than sizeof (Dev->ConfigSpace), which would cause
serious system exception.

So we add a pre-check branch to avoid memory override.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ard Biesheuvel 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
---
  .../Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c | 5
+
  1 file changed, 5 insertions(+)

diff --git
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
PciDeviceIo.c
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
PciDeviceIo.c
index c836ad6..0e42ae4 100644
---
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
PciDeviceIo.c
+++
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
Pc
+++ iDeviceIo.c
@@ -465,6 +465,11 @@ PciIoPciRead (
Address = (UINT8 *)>ConfigSpace + Offset;
Length = Count << ((UINTN)Width & 0x3);

+  if (Offset >= sizeof (Dev->ConfigSpace)) {
+ZeroMem (Buffer, Length);
+return EFI_SUCCESS;
+  }
+
if (Offset + Length > sizeof (Dev->ConfigSpace)) {
  //
  // Read all zeroes for config space accesses beyond the first
--
1.9.1


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


Re: [edk2] [PATCH] ShellPkg: Fix type mismatch with GCC

2017-10-30 Thread Alcantara, Paulo
Ruiyu,

Thanks for letting me know. I agree with below changes and they look good to 
me. Please go ahead and fix them. Hopefully I'll  get a chance to review/test 
it.

Paulo

-Original Message-
From: Gao, Liming [mailto:liming@intel.com] 
Sent: Monday, October 30, 2017 3:27 AM
To: Ni, Ruiyu ; Alcantara, Paulo ; Carsey, 
Jaben ; edk2-devel@lists.01.org
Subject: RE: [PATCH] ShellPkg: Fix type mismatch with GCC

That's good. 

>-Original Message-
>From: Ni, Ruiyu
>Sent: Monday, October 30, 2017 1:25 PM
>To: Gao, Liming ; Alcantara, Paulo 
>; Carsey, Jaben ; 
>edk2-devel@lists.01.org
>Subject: RE: [PATCH] ShellPkg: Fix type mismatch with GCC
>
>I have a pending task to remove the dependency of InternalCharToUpper().
>Below two bugs require the same fix.
>664   [Shell] UnicodeCollation->StriColl() should be used to replace StrinCmp 
>in
>UefiShellLevel2CommandsLib
>294   Strnicmp() should use UNICODE_COLLATION.StrUpr() instead of
>converting char to upper case inself
>
>I think fixing them two is the right solution to go.
>
>
>Thanks/Ray
>
>> -Original Message-
>> From: Gao, Liming
>> Sent: Monday, October 30, 2017 1:18 PM
>> To: Alcantara, Paulo ; Carsey, Jaben 
>> ; edk2-devel@lists.01.org
>> Cc: Ni, Ruiyu 
>> Subject: RE: [PATCH] ShellPkg: Fix type mismatch with GCC
>>
>> I suggest to rename it and add its implementation in ShellPkg. We 
>> don't expect to use the internal function from another library or driver.
>>
>> Another way is to propose adding StrniCmp() API into BaseLib.
>>
>> Thanks
>> Liming
>> >-Original Message-
>> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> >Of Alcantara, Paulo
>> >Sent: Saturday, October 28, 2017 2:51 AM
>> >To: Carsey, Jaben ; edk2-devel@lists.01.org
>> >Cc: Ni, Ruiyu 
>> >Subject: Re: [edk2] [PATCH] ShellPkg: Fix type mismatch with GCC
>> >
>> >Hi Jaben,
>> >
>> >No, we can't. InternalCharToUpper() is declared internally in 
>> >BaseLib and unexported.
>> >
>> >The comment above the declaration in UefiShellLevel2CommandsLib.c 
>> >explains it:
>> >
>> >/**
>> >  Be lazy and borrow from baselib.
>> >
>> >  @param[in] Char   The character to convert to upper case.
>> >
>> >  @return Char as an upper case character.
>> >**/
>> >
>> >Thanks,
>> >Paulo
>> >
>> >
>> >From: Carsey, Jaben 
>> >Sent: Friday, October 27, 2017 4:33 PM
>> >To: Alcantara, Paulo; edk2-devel@lists.01.org
>> >Cc: Ni, Ruiyu
>> >Subject: RE: [PATCH] ShellPkg: Fix type mismatch with GCC
>> >
>> >Are we redefining a function from BaseLib?  Why not remove the 
>> >redundant definition instead of making it match?
>> >
>> >-Jaben
>> >
>> >> -Original Message-
>> >> From: Paulo Alcantara [mailto:pa...@hp.com]
>> >> Sent: Friday, October 27, 2017 9:24 AM
>> >> To: edk2-devel@lists.01.org
>> >> Cc: Paulo Alcantara ; Carsey, Jaben 
>> >> ; Ni, Ruiyu 
>> >> Subject: [PATCH] ShellPkg: Fix type mismatch with GCC
>> >> Importance: High
>> >>
>> >> This patch fixes the following warning reported by GCC 6.3:
>> >>
>> >>
>> >/home/pcacjr/src/edk2.git/ShellPkg/Library/UefiShellLevel2CommandsLi
>> >b
>/
>> U
>> >> efiShellLevel2CommandsLib.c:271:1:
>> >> warning: type of 'InternalCharToUpper' does not match original 
>> >> decl aration [-Wlto-type-mismatch]  InternalCharToUpper (  ^
>> >> /home/pcacjr/src/edk2.git/MdePkg/Library/BaseLib/String.c:555:1: note:
>> >> 'InternalCharToUpper' was previously declared here 
>> >> InternalCharToUpper (  ^
>> >>
>> >> Cc: Jaben Carsey 
>> >> Cc: Ruiyu Ni 
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Paulo Alcantara 
>> >> ---
>> >>
>> >>
>> >ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Commands
>Li
>> b
>> >> .c | 1 +
>> >>  1 file changed, 1 insertion(+)
>> >>
>> >> diff --git
>> >>
>> >a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
>d
>> s
>> >> Lib.c
>> >>
>> >b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
>d
>> s
>> >> Lib.c
>> >> index 7948e53cfc..bab6631e15 100644
>> >> ---
>> >>
>> >a/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
>d
>> s
>> >> Lib.c
>> >> +++
>> >>
>> >b/ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2Comman
>d
>> s
>> >> Lib.c
>> >> @@ -268,6 +268,7 @@ VerifyIntermediateDirectories (
>> >>@return Char as an upper case character.
>> >>  **/
>> >>  CHAR16
>> >> +EFIAPI
>> >>  InternalCharToUpper (
>> >>IN CONST CHAR16Char
>> >>);
>> >> --
>> >> 2.11.0
>> >
>> >___
>> >edk2-devel mailing list
>> 

Re: [edk2] [PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

2017-10-30 Thread Ni, Ruiyu
I will wait for Ard's feedback. It's an ARM specific module.

Thanks/Ray

> -Original Message-
> From: Zeng, Star
> Sent: Monday, October 30, 2017 6:07 PM
> To: Ni, Ruiyu ; Heyi Guo ; linaro-
> u...@lists.linaro.org; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Ard Biesheuvel
> ; Zeng, Star 
> Subject: RE: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory
> override bug
> 
> Ray,
> Please help take a review to this patch.
> 
> 
> Thanks,
> Star
> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Monday, October 30, 2017 1:48 PM
> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
> Cc: Heyi Guo ; Zeng, Star ;
> Dong, Eric ; Ard Biesheuvel
> ; Ni, Ruiyu 
> Subject: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory
> override bug
> 
> For PciIoPciRead interface, memory prior to Buffer would be written with
> zeros if Offset was larger than sizeof (Dev->ConfigSpace), which would cause
> serious system exception.
> 
> So we add a pre-check branch to avoid memory override.
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Ard Biesheuvel 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo 
> ---
>  .../Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c | 5
> +
>  1 file changed, 5 insertions(+)
> 
> diff --git
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> index c836ad6..0e42ae4 100644
> ---
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> +++
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> Pc
> +++ iDeviceIo.c
> @@ -465,6 +465,11 @@ PciIoPciRead (
>Address = (UINT8 *)>ConfigSpace + Offset;
>Length = Count << ((UINTN)Width & 0x3);
> 
> +  if (Offset >= sizeof (Dev->ConfigSpace)) {
> +ZeroMem (Buffer, Length);
> +return EFI_SUCCESS;
> +  }
> +
>if (Offset + Length > sizeof (Dev->ConfigSpace)) {
>  //
>  // Read all zeroes for config space accesses beyond the first
> --
> 1.9.1

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


Re: [edk2] [PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

2017-10-30 Thread Zeng, Star
Ray,
Please help take a review to this patch.


Thanks,
Star
-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org] 
Sent: Monday, October 30, 2017 1:48 PM
To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
Cc: Heyi Guo ; Zeng, Star ; Dong, 
Eric ; Ard Biesheuvel ; Ni, 
Ruiyu 
Subject: [edk2][PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

For PciIoPciRead interface, memory prior to Buffer would be written with zeros 
if Offset was larger than sizeof (Dev->ConfigSpace), which would cause serious 
system exception.

So we add a pre-check branch to avoid memory override.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ard Biesheuvel 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
---
 .../Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c 
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
index c836ad6..0e42ae4 100644
--- 
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
+++ b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePc
+++ iDeviceIo.c
@@ -465,6 +465,11 @@ PciIoPciRead (
   Address = (UINT8 *)>ConfigSpace + Offset;
   Length = Count << ((UINTN)Width & 0x3);
 
+  if (Offset >= sizeof (Dev->ConfigSpace)) {
+ZeroMem (Buffer, Length);
+return EFI_SUCCESS;
+  }
+
   if (Offset + Length > sizeof (Dev->ConfigSpace)) {
 //
 // Read all zeroes for config space accesses beyond the first
--
1.9.1

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


Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Add I2C table.

2017-10-30 Thread Wei, David
Reviewed-by: zwei4 

Thanks,
David  Wei

Intel SSG/STO/UEFI BIOS 

> -Original Message-
> From: Lu, ShifeiX A
> Sent: Monday, October 30, 2017 5:06 PM
> To: edk2-devel@lists.01.org
> Cc: Wei, David 
> Subject: [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Add I2C
> table.
> 
> Add I2C table for on-board WM8731 I2S audio.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: lushifex 
> ---
>  .../PlatformSsdt/Audio/AudioCodec_INT343A.asl   | 17 
> +
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git
> a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSs
> dt/Audio/AudioCodec_INT343A.asl
> b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSs
> dt/Audio/AudioCodec_INT343A.asl
> index a1756ec..b11793b 100644
> ---
> a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSs
> dt/Audio/AudioCodec_INT343A.asl
> +++
> b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSs
> dt/Audio/AudioCodec_INT343A.asl
> @@ -1,5 +1,5 @@
>  /** @file
> -  Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -14,13 +14,10 @@
>  External(\IOBF, IntObj) // ScHdAudioIoBufferOwnership
>  External(\IS3A, IntObj)
> 
> -Scope(\_SB.PCI0.I2C0) {
> +  Scope(\_SB.PCI0.I2C7) {
>//---
>//  HD Audio I2S Codec device
> -  //  ALC 298
> -  //  I2C1
> -  //  GPIO_192:SOC_CODEC_PD_NNorth West Community number 5
> -  //  GPIO_116:SOC_CODEC_IRQ North West Community, direct IRQ, IRQ
> number 0x5B.
> +  //  I2C7
>//---
>Device (HDAC)
>{
> @@ -35,14 +32,10 @@ Scope(\_SB.PCI0.I2C0) {
> 
>  Method (_CRS, 0, Serialized) {
>Name (SBFB, ResourceTemplate () {
> -I2cSerialBus (0x1C, ControllerInitiated, 40, AddressingMode7Bit,
> "\\_SB.PCI0.I2C0",,,)
> +I2cSerialBus (0x1A, ControllerInitiated, 40, AddressingMode7Bit,
> "\\_SB.PCI0.I2C7",0x00, ResourceConsumer,,)
>})
> 
> -  Name (SBFI, ResourceTemplate () {
> -Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake,,,)
> {0x5B}
> -  })
> -
> -  Return (ConcatenateResTemplate(SBFB, SBFI))
> +  Return (SBFB)
>  }
> 
>  Method (_STA, 0, NotSerialized)
> --
> 2.7.0.windows.1
> 

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


[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Add I2C table.

2017-10-30 Thread lushifex
Add I2C table for on-board WM8731 I2S audio.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 .../PlatformSsdt/Audio/AudioCodec_INT343A.asl   | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
index a1756ec..b11793b 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
+++ 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
@@ -1,5 +1,5 @@
 /** @file
-  Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -14,13 +14,10 @@
 External(\IOBF, IntObj) // ScHdAudioIoBufferOwnership
 External(\IS3A, IntObj)
 
-Scope(\_SB.PCI0.I2C0) {
+  Scope(\_SB.PCI0.I2C7) {
   //---
   //  HD Audio I2S Codec device
-  //  ALC 298
-  //  I2C1
-  //  GPIO_192:SOC_CODEC_PD_NNorth West Community number 5
-  //  GPIO_116:SOC_CODEC_IRQ North West Community, direct IRQ, IRQ number 
0x5B.
+  //  I2C7
   //---
   Device (HDAC)
   {
@@ -35,14 +32,10 @@ Scope(\_SB.PCI0.I2C0) {
 
 Method (_CRS, 0, Serialized) {
   Name (SBFB, ResourceTemplate () {
-I2cSerialBus (0x1C, ControllerInitiated, 40, AddressingMode7Bit, 
"\\_SB.PCI0.I2C0",,,)
+I2cSerialBus (0x1A, ControllerInitiated, 40, AddressingMode7Bit, 
"\\_SB.PCI0.I2C7",0x00, ResourceConsumer,,)
   })
 
-  Name (SBFI, ResourceTemplate () {
-Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake,,,) 
{0x5B}
-  })
-
-  Return (ConcatenateResTemplate(SBFB, SBFI))
+  Return (SBFB)
 }
 
 Method (_STA, 0, NotSerialized)
-- 
2.7.0.windows.1


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


[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Enable audio.

2017-10-30 Thread lushifex
Enable on-board audio.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
---
 .../PlatformSsdt/Audio/AudioCodec_INT343A.asl   | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
index a1756ec..b11793b 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
+++ 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/Audio/AudioCodec_INT343A.asl
@@ -1,5 +1,5 @@
 /** @file
-  Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -14,13 +14,10 @@
 External(\IOBF, IntObj) // ScHdAudioIoBufferOwnership
 External(\IS3A, IntObj)
 
-Scope(\_SB.PCI0.I2C0) {
+  Scope(\_SB.PCI0.I2C7) {
   //---
   //  HD Audio I2S Codec device
-  //  ALC 298
-  //  I2C1
-  //  GPIO_192:SOC_CODEC_PD_NNorth West Community number 5
-  //  GPIO_116:SOC_CODEC_IRQ North West Community, direct IRQ, IRQ number 
0x5B.
+  //  I2C7
   //---
   Device (HDAC)
   {
@@ -35,14 +32,10 @@ Scope(\_SB.PCI0.I2C0) {
 
 Method (_CRS, 0, Serialized) {
   Name (SBFB, ResourceTemplate () {
-I2cSerialBus (0x1C, ControllerInitiated, 40, AddressingMode7Bit, 
"\\_SB.PCI0.I2C0",,,)
+I2cSerialBus (0x1A, ControllerInitiated, 40, AddressingMode7Bit, 
"\\_SB.PCI0.I2C7",0x00, ResourceConsumer,,)
   })
 
-  Name (SBFI, ResourceTemplate () {
-Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake,,,) 
{0x5B}
-  })
-
-  Return (ConcatenateResTemplate(SBFB, SBFI))
+  Return (SBFB)
 }
 
 Method (_STA, 0, NotSerialized)
-- 
2.7.0.windows.1


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


Re: [edk2] [RFC] MdeModulePkg/NonDiscoverablePciDeviceDxe: NonCoherentPciIoAllocateBuffer issue with AArch64

2017-10-30 Thread Ard Biesheuvel
On 30 October 2017 at 03:52, Heyi Guo  wrote:
> Hi folks,
>
> In NonDiscoverablePciDeviceDxe driver, NonCoherentPciIoAllocateBuffer may
> allocate EFI_MEMORY_UC buffer depending on input Attributes and GCD
> capabilities. If it does, it actually allocates memory of "device" type in
> AArch64, but not "normal uncacheable" memory. For "device" memory type, it
> requires restrict access alignment and it may trigger alignment fault
> exception with BaseMemoryLibOptDxe in which read/write alignment is not
> guaranteed.
>
> Is EFI_MOMORY_WC enough for AArch64 platforms? How about other platforms,
> like X86?
>

Hello Heyi,

Do you mean EFI_MEMORY_UC in the last sentence? If not, I don't
understand the question.

Anyway, in reality, this code will only allocate EFI_MEMORY_UC memory
if any memory already exists in the memory map with that capability,
otherwise it will fall back to EFI_MEMORY_WC. On most arm64 platforms,
we no longer add this capability to system memory by default, so you
should be getting EFI_MEMORY_WC in most cases.

So the question is actually the opposite: does this interfere with
correct operation in cases where the shared mapping between the CPU
and the device should be strongly ordered, and EFI_MEMORY_WC doesn't
give sufficient guarantees.

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


Re: [edk2] [PATCH] MdeModulePkg/NonDiscoverable: fix memory override bug

2017-10-30 Thread Ard Biesheuvel
On 30 October 2017 at 05:47, Heyi Guo  wrote:
> For PciIoPciRead interface, memory prior to Buffer would be written
> with zeros if Offset was larger than sizeof (Dev->ConfigSpace), which
> would cause serious system exception.
>
> So we add a pre-check branch to avoid memory override.
>
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Ard Biesheuvel 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo 

Reviewed-by: Ard Biesheuvel 

> ---
>  .../Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c | 5 
> +
>  1 file changed, 5 insertions(+)
>
> diff --git 
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
>  
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
> index c836ad6..0e42ae4 100644
> --- 
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
> +++ 
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
> @@ -465,6 +465,11 @@ PciIoPciRead (
>Address = (UINT8 *)>ConfigSpace + Offset;
>Length = Count << ((UINTN)Width & 0x3);
>
> +  if (Offset >= sizeof (Dev->ConfigSpace)) {
> +ZeroMem (Buffer, Length);
> +return EFI_SUCCESS;
> +  }
> +
>if (Offset + Length > sizeof (Dev->ConfigSpace)) {
>  //
>  // Read all zeroes for config space accesses beyond the first
> --
> 1.9.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel