Re: [edk2-devel] [PATCH edk2-platforms 5/5] Platform/RaspberryPi: Drop platform specific EfiResetSystemLib

2024-07-25 Thread Jeremy Linton

Hi,

On 7/25/24 06:38, Leif Lindholm wrote:

On Thu, Jul 25, 2024 at 12:43:30 +0200, Ard Biesheuvel wrote:

From: Ard Biesheuvel 

Drop the now unused EfiResetSystemLib implementation, which has been
superseded by the generic one from EDK2.

Signed-off-by: Ard Biesheuvel 
---
  Platform/RaspberryPi/RaspberryPi.dec   |   1 -
  Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf |   1 -
  Platform/RaspberryPi/Library/ResetLib/ResetLib.inf |  45 
--
  Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c   |  11 
--
  Platform/RaspberryPi/Library/ResetLib/ResetLib.c   | 151 

  5 files changed, 209 deletions(-)

diff --git a/Platform/RaspberryPi/RaspberryPi.dec 
b/Platform/RaspberryPi/RaspberryPi.dec
index 6bd16a5ae9fd..a5fa1fb00c48 100644
--- a/Platform/RaspberryPi/RaspberryPi.dec
+++ b/Platform/RaspberryPi/RaspberryPi.dec
@@ -24,7 +24,6 @@ [Protocols]
  
  [Guids]

gRaspberryPiTokenSpaceGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 
0x63, 0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}
-  gRaspberryPiEventResetGuid = {0xCD7CC258, 0x31DB, 0x11E6, {0x9F, 0xD3, 0x63, 
0xB4, 0xB4, 0xE4, 0xD4, 0xB4}}
gConfigDxeFormSetGuid = {0xCD7CC258, 0x31DB, 0x22E6, {0x9F, 0x22, 0x63, 
0xB0, 0xB8, 0xEE, 0xD6, 0xB5}}


*loud sigh at looking those "GUIDs"*
But that's not this set's fault.


The first couple are DCE time/mac UUIDs with the MAC address fuzzed, no? 
Initially I assumed this coudn't be the case because I would have 
expected the timestamp (2016-06-13 21:57:59, which looks almost 
reasonable) to vary, but i'm guessing they were generated, and then 
someone didn't want their mac in the pubic so they fuzzed it a couple 
times rather than generating completely new IDs. Some of the others 
though, maybe a BE/LE UUID/GUID manual conversion (or not) problem...


Anyway, I will spin it up in a day or two on real hardware, but right 
now its all torn down in boxes because i've moved.






For the series:
Reviewed-by: Leif Lindholm 
Thanks!

/
 Leif


  [PcdsFixedAtBuild.common]
diff --git 
a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf
index 6456153fd3ab..53391466a77b 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.inf
@@ -52,7 +52,6 @@ [LibraryClasses]
  
  [Guids]

gEfiEventVirtualAddressChangeGuid
-  gRaspberryPiEventResetGuid
gEfiEventReadyToBootGuid
  
  [Protocols]

diff --git a/Platform/RaspberryPi/Library/ResetLib/ResetLib.inf 
b/Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
deleted file mode 100644
index 9bdb94a52ebf..
--- a/Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
+++ /dev/null
@@ -1,45 +0,0 @@
-#/** @file
-#
-#  Reset System lib using PSCI hypervisor or secure monitor calls.
-#  Signals the gRaspberryPiEventResetGuid event group on reset.
-#
-#  Copyright (c) 2018, Andrei Warkentin 
-#  Copyright (c) 2014, Linaro Ltd. All rights reserved.
-#  Copyright (c) 2014, ARM Ltd. All rights reserved.
-#  Copyright (c) 2008, Apple Inc. All rights reserved.
-#
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-#**/
-
-[Defines]
-  INF_VERSION= 0x0001001A
-  BASE_NAME  = ResetLib
-  FILE_GUID  = B9F59B69-A105-41C7-8F5A-2C60DD7FD7AB
-  MODULE_TYPE= BASE
-  VERSION_STRING = 1.0
-  LIBRARY_CLASS  = EfiResetSystemLib
-
-[Sources]
-  ResetLib.c
-
-[Packages]
-  ArmPkg/ArmPkg.dec
-  MdePkg/MdePkg.dec
-  EmbeddedPkg/EmbeddedPkg.dec
-  Platform/RaspberryPi/RaspberryPi.dec
-
-[LibraryClasses]
-  DebugLib
-  BaseLib
-  ArmSmcLib
-  PcdLib
-  TimerLib
-  UefiLib
-  UefiRuntimeLib
-
-[Guids]
-  gRaspberryPiEventResetGuid
-
-[Pcd]
-  gRaspberryPiTokenSpaceGuid.PcdPlatformResetDelay  ## CONSUMES
diff --git 
a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c
index 81dfb95e323c..04414b142c7e 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServiceDxe.c
@@ -262,20 +262,9 @@ InstallDumpVarEventHandlers (
)
  {
EFI_STATUS   Status;
-  EFI_EVENTResetEvent;
EFI_EVENTReadyToBootEvent;
EFI_RESET_NOTIFICATION_PROTOCOL  *ResetNotify;
  
-  Status = gBS->CreateEventEx (

-  EVT_NOTIFY_SIGNAL,
-  TPL_CALLBACK,
-  DumpVarsOnEvent,
-  NULL,
-  ,
-  
-);
-  ASSERT_EFI_ERROR (Status);
-
Status = gBS->CreateEventEx (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
diff 

Re: [edk2-devel] [PATCH v2 1/5] Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011

2024-03-12 Thread Jeremy Linton

Hi,


On 3/11/24 09:13, Ard Biesheuvel via groups.io wrote:

On Wed, 17 Jan 2024 at 22:36, Jeremy Linton  wrote:


The rpi's config.txt controls which uart (pl011, or miniuart) is
selected as the console. TFA and edk2 follow its lead, but if the
miniuart is selected as the primary and the machine is booted in ACPI
mode the baud/etc is never configured for the pl011. The linux kernel
won't reconfigure it either as its listed as a "SBSA" uart, so it
simply won't work.

This re-enables BT on the pl011 in ACPI mode, and it somewhat starts
to work again.

Signed-off-by: Jeremy Linton 
---
  .../DualSerialPortLib/DualSerialPortLib.c | 44 ---
  1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index d2f983bf0a..09d3e33c00 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -76,6 +76,8 @@ SerialPortInitialize (
EFI_PARITY_TYPE Parity;
UINT8   DataBits;
EFI_STOP_BITS_TYPE  StopBits;
+  RETURN_STATUS   Ret;
+  UINTN   Timeout;

//
// First thing we need to do is determine which of PL011 or miniUART is 
selected
@@ -85,23 +87,34 @@ SerialPortInitialize (
  UsePl011UartSet = TRUE;
}

-  if (UsePl011Uart) {
-BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
+  // always init the pl011 on the RPi4, linux expects a SBSA uart to be at 
115200
+  // this means we need to set the baud/etc even if we aren't using it as a 
console
+  if ((UsePl011Uart) || (RPI_MODEL == 4)) {
  ReceiveFifoDepth = 0; // Use default FIFO depth
+if (!UsePl011Uart)
+{
+  BaudRate = 115200;
+}
+else
+{
+  BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
+}
  Parity = (EFI_PARITY_TYPE)FixedPcdGet8 (PcdUartDefaultParity);
  DataBits = FixedPcdGet8 (PcdUartDefaultDataBits);
  StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);

-return PL011UartInitializePort (
- PL011_UART_REGISTER_BASE,
- PL011UartClockGetFreq(),
- ,
- ,
- ,
- ,
- 
- );
-  } else {
+Ret = PL011UartInitializePort (
+   PL011_UART_REGISTER_BASE,
+   PL011UartClockGetFreq(),
+   ,
+   ,
+   ,
+   ,
+   
+   );
+  }
+
+  if (!UsePl011Uart) {
  SerialRegisterBase = MINI_UART_REGISTER_BASE;
  Divisor = SerialPortGetDivisor (PcdGet32 (PcdSerialBaudRate));

@@ -127,7 +140,8 @@ SerialPortInitialize (
  // Wait for the serial port to be ready.
  // Verify that both the transmit FIFO and the shift register are empty.
  //
-while ((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY));
+Timeout = 1000;
+while (((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) && 
(Timeout--));



Why is this necessary, and what does it have to do with the rest of the patch?


I think last time I noted that it side steps a problem when both of the 
uarts are being unilaterally configured but the clock wasn't because the 
default selected in the config.txt was the pl011 (IIRC). But it 
shouldn't be hit by default unless the config.txt and edk2 configs is 
differing.


I will drop or move it, if that is whats holding up this set.




  //
  // Configure baud rate
@@ -158,9 +172,9 @@ SerialPortInitialize (
  // Put Modem Control Register(MCR) into its reset state of 0x00.
  //
  SerialPortWriteRegister (SerialRegisterBase, R_UART_MCR, 0x00);
-
-return RETURN_SUCCESS;
+Ret = RETURN_SUCCESS;
}
+  return Ret;
  }

  /**
--
2.43.0











-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116702): https://edk2.groups.io/g/devel/message/116702
Mute This Topic: https://groups.io/mt/103796307/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/RPI4: Grow FV size to accommodate DEBUG build

2024-03-12 Thread Jeremy Linton

Hi,

On 3/12/24 05:43, Ard Biesheuvel wrote:

On Tue, 12 Mar 2024 at 11:29, Ard Biesheuvel  wrote:


From: Ard Biesheuvel 

The DEBUG build no longer fits when all build options used by the
release script on github.com/pftf are used, presumably due to the
OpenSSL upgrade.

So bump the size for all builds.

Signed-off-by: Ard Biesheuvel 
---
  Platform/RaspberryPi/RPi4/RPi4.fdf | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf 
b/Platform/RaspberryPi/RPi4/RPi4.fdf
index 816927761513..951488260ed4 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -25,11 +25,11 @@

  [FD.RPI_EFI]
  BaseAddress   = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress
-Size  = 0x001f|gArmTokenSpaceGuid.PcdFdSize
+Size  = 0x0021|gArmTokenSpaceGuid.PcdFdSize
  ErasePolarity = 1



Ugh just realized that this breaks DT loading from TFA, which places
the DT at a fixed offset of 0x1f


Right, which can be changed within the config.txt file but its probably 
better not to. I hit this a few months back and have a version on my 
github which moves it too, along with the TFA fixes, but really we 
should be able to move one of the other regions around the DT, which 
IIRC may be pushed to one of my branches on github along with the CPPC 
patches for TFA/etc too.


That was set 4 or 5 that i've not posted because all the stuff in front 
of it is still up in the air.


I can probably pick off just this bit and post it next week if its still 
a problem, since i'm away from the rpi's at the moment.







  BlockSize = 0x1000|gRaspberryPiTokenSpaceGuid.PcdFirmwareBlockSize
-NumBlocks = 0x1f0
+NumBlocks = 0x210

  

  #
@@ -56,7 +56,7 @@ [FD.RPI_EFI]
  #
  # UEFI image
  #
-0x0002|0x001b
+0x0002|0x001d
  gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
  FV = FVMAIN_COMPACT

@@ -70,7 +70,7 @@ [FD.RPI_EFI]
  #

  # NV_VARIABLE_STORE
-0x001d|0xe000
+0x001f|0xe000
  
gRaspberryPiTokenSpaceGuid.PcdNvStorageVariableBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize

  DATA = {
@@ -113,11 +113,11 @@ [FD.RPI_EFI]
  }

  # NV_EVENT_LOG
-0x001de000|0x1000
+0x001fe000|0x1000
  
gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogBase|gRaspberryPiTokenSpaceGuid.PcdNvStorageEventLogSize

  # NV_FTW_WORKING header
-0x001df000|0x1000
+0x001ff000|0x1000
  
gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwWorkingBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize

  DATA = {
@@ -132,7 +132,7 @@ [FD.RPI_EFI]
  }

  # NV_FTW_WORKING data
-0x001e|0x0001
+0x0020|0x0001
  
gRaspberryPiTokenSpaceGuid.PcdNvStorageFtwSpareBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize

  #
--
2.44.0.278.ge034bb2e1d-goog





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116701): https://edk2.groups.io/g/devel/message/116701
Mute This Topic: https://groups.io/mt/104882052/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 4/5] Platform/RaspberryPi: Give the user control over the XHCI mailbox

2024-01-17 Thread Jeremy Linton
Its a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets
give users which want to try DT the option of flipping this on/off.

Users that don't want to have to deal with DT, can use ACPI.

Signed-off-by: Jeremy Linton 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 10 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   |  1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|  5 +
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr| 15 +++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c  |  4 
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf|  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc|  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc|  7 +++
 Platform/RaspberryPi/RaspberryPi.dec  |  1 +
 9 files changed, 50 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 3dcf2bac0d..2484787982 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -298,6 +298,16 @@ SetupVariables (
 Status = PcdSet32S (PcdXhciPci, 1);
 ASSERT_EFI_ERROR (Status);
   }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciReload",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdXhciReload, PcdGet32 (PcdXhciReload));
+ASSERT_EFI_ERROR (Status);
+  }
+
 }
   } else {
 /*
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 6f6e8f42ac..475e645537 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -96,6 +96,7 @@
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
   gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate
+  gRaspberryPiTokenSpaceGuid.PcdXhciReload
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 5ec17072c3..8130638876 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -62,6 +62,11 @@
 #string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
 #string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"
 
+#string STR_ADVANCED_XHCIRELOAD_PROMPT  #language en-US "DT Reload XHCI 
firmware"
+#string STR_ADVANCED_XHCIRELOAD_HELP#language en-US "OS should reload XHCI 
firmware on reset"
+#string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f668b7a553..f13b70711d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -61,6 +61,11 @@ formset
   name  = XhciPci,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_XHCIPCI_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = XhciReload,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -228,6 +233,16 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PCIE), value = 
1, flags = 0;
 endoneof;
   endif;
+
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+oneof varid = XhciReload.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_PROMPT),
+  help= STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_HELP),
+  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_DISABLE), 
value = 0, flags = DEFAULT;
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_RELOAD), 
value = 1, flags = 0;
+endoneof;
+  endif;
 endif;
 #endif
 string varid = AssetTag.AssetTag,
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index cbbc2ad30d..dd4fc0a05e 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+

[edk2-devel] [PATCH v2 5/5] Platform/RaspberryPi: Update PCIe MMIO window for DT

2024-01-17 Thread Jeremy Linton
Since we are updating the DT memory map and telling it how
we have configured the PCIe, there isn't a reason for moving the
MMIO window. In fact this appears to fix OpenBSD+DT as well as
it makes the linux XHCI reset sequence happier.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c  | 22 +++
 .../RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |  6 +
 2 files changed, 28 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index dd4fc0a05e..a247aa36ed 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
@@ -375,6 +375,28 @@ SyncPcie (
 return EFI_NOT_FOUND;
   }
 
+  // move the MMIO window too
+  DmaRanges[0] = cpu_to_fdt32 (0x0200); //non prefech 32-bit
+  DmaRanges[1] = cpu_to_fdt32 (FixedPcdGet64 (PcdBcm27xxPciBusMmioAdr) >> 32); 
//bus addr @ 0x0f800
+  DmaRanges[2] = cpu_to_fdt32 (FixedPcdGet64 (PcdBcm27xxPciBusMmioAdr) & 
MAX_UINT32);
+  DmaRanges[3] = cpu_to_fdt32 (FixedPcdGet64 (PcdBcm27xxPciCpuMmioAdr) >> 32); 
//cpu addr @ 0x6
+  DmaRanges[4] = cpu_to_fdt32 (FixedPcdGet64 (PcdBcm27xxPciCpuMmioAdr) & 
MAX_UINT32);
+  DmaRanges[5] = cpu_to_fdt32 (0x);
+  DmaRanges[6] = cpu_to_fdt32 (FixedPcdGet32 (PcdBcm27xxPciBusMmioLen) + 1); 
// len = 0x4000 
+
+  DEBUG ((DEBUG_INFO, "%a: Updating PCIe ranges\n",  __func__));
+
+  /*
+   * Match ranges (BAR/MMIO) with the EDK2+ACPI setup we are using.
+   */
+  Retval = fdt_setprop (mFdtImage, Node, "ranges",
+DmaRanges,  sizeof DmaRanges);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to locate PCIe MMIO 'ranges' property 
(%d)\n",
+  __func__, Retval));
+return EFI_NOT_FOUND;
+  }
+
   if (PcdGet32 (PcdXhciReload) != 1) {
 return EFI_SUCCESS;
   }
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf
index d9fb6ee480..90e138af7c 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf
@@ -23,6 +23,7 @@
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   Platform/RaspberryPi/RaspberryPi.dec
+  Silicon/Broadcom/Bcm27xx/Bcm27xx.dec
 
 [LibraryClasses]
   BaseLib
@@ -44,6 +45,11 @@
 
 [FixedPcd]
   gRaspberryPiTokenSpaceGuid.PcdFdtBaseAddress
+  gBcm27xxTokenSpaceGuid.PcdBcm27xxPciRegBase
+  gBcm27xxTokenSpaceGuid.PcdBcm27xxPciBusMmioAdr
+  gBcm27xxTokenSpaceGuid.PcdBcm27xxPciBusMmioLen
+  gBcm27xxTokenSpaceGuid.PcdBcm27xxPciCpuMmioAdr
+
 
 [Pcd]
   gRaspberryPiTokenSpaceGuid.PcdSystemTableMode
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113965): https://edk2.groups.io/g/devel/message/113965
Mute This Topic: https://groups.io/mt/103796311/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 2/5] Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings

2024-01-17 Thread Jeremy Linton
Some recent GCC revisions will throw warnings about values being used
before being initialized. But in the case where the lack of initialization
is the result of the called function returning error status the EFI_ERROR()
macro/error seems to confuse the compiler about the fact that the value
is then never used.

So, while the code appears to be fine, lets just zero the variables
anyway to make the compiler happy.

Signed-off-by: Jeremy Linton 
---
 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c| 2 ++
 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c
index 9e5d30fafd..2d5f70170e 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c
@@ -381,6 +381,8 @@ GenericPhyUpdateConfig (
   BOOLEAN LinkUp;
 
   Status = GenericPhyGetLinkStatus (Phy);
+  Speed = 0;
+  Duplex = 0;
   LinkUp = EFI_ERROR (Status) ? FALSE : TRUE;
 
   if (Phy->LinkUp != LinkUp) {
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
index 3b51a86d65..7a7c398b1f 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
@@ -731,6 +731,9 @@ GenetSimpleNetworkReceive (
   UINT8   *Frame;
   UINTN   FrameLength;
 
+  DescIndex = 0;
+  FrameLength = 0;
+
   if (This == NULL || Buffer == NULL) {
 DEBUG ((DEBUG_ERROR, "%a: Invalid parameter (missing handle or buffer)\n",
   __FUNCTION__));
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113962): https://edk2.groups.io/g/devel/message/113962
Mute This Topic: https://groups.io/mt/103796308/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 1/5] Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011

2024-01-17 Thread Jeremy Linton
The rpi's config.txt controls which uart (pl011, or miniuart) is
selected as the console. TFA and edk2 follow its lead, but if the
miniuart is selected as the primary and the machine is booted in ACPI
mode the baud/etc is never configured for the pl011. The linux kernel
won't reconfigure it either as its listed as a "SBSA" uart, so it
simply won't work.

This re-enables BT on the pl011 in ACPI mode, and it somewhat starts
to work again.

Signed-off-by: Jeremy Linton 
---
 .../DualSerialPortLib/DualSerialPortLib.c | 44 ---
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index d2f983bf0a..09d3e33c00 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -76,6 +76,8 @@ SerialPortInitialize (
   EFI_PARITY_TYPE Parity;
   UINT8   DataBits;
   EFI_STOP_BITS_TYPE  StopBits;
+  RETURN_STATUS   Ret;
+  UINTN   Timeout;
 
   //
   // First thing we need to do is determine which of PL011 or miniUART is 
selected
@@ -85,23 +87,34 @@ SerialPortInitialize (
 UsePl011UartSet = TRUE;
   }
 
-  if (UsePl011Uart) {
-BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
+  // always init the pl011 on the RPi4, linux expects a SBSA uart to be at 
115200
+  // this means we need to set the baud/etc even if we aren't using it as a 
console
+  if ((UsePl011Uart) || (RPI_MODEL == 4)) {
 ReceiveFifoDepth = 0; // Use default FIFO depth
+if (!UsePl011Uart)
+{
+  BaudRate = 115200;
+}
+else
+{
+  BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
+}
 Parity = (EFI_PARITY_TYPE)FixedPcdGet8 (PcdUartDefaultParity);
 DataBits = FixedPcdGet8 (PcdUartDefaultDataBits);
 StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);
 
-return PL011UartInitializePort (
- PL011_UART_REGISTER_BASE,
- PL011UartClockGetFreq(),
- ,
- ,
- ,
- ,
- 
- );
-  } else {
+Ret = PL011UartInitializePort (
+   PL011_UART_REGISTER_BASE,
+   PL011UartClockGetFreq(),
+   ,
+   ,
+   ,
+   ,
+   
+   );
+  }
+
+  if (!UsePl011Uart) {
 SerialRegisterBase = MINI_UART_REGISTER_BASE;
 Divisor = SerialPortGetDivisor (PcdGet32 (PcdSerialBaudRate));
 
@@ -127,7 +140,8 @@ SerialPortInitialize (
 // Wait for the serial port to be ready.
 // Verify that both the transmit FIFO and the shift register are empty.
 //
-while ((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY));
+Timeout = 1000;
+while (((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) 
&& (Timeout--));
 
 //
 // Configure baud rate
@@ -158,9 +172,9 @@ SerialPortInitialize (
 // Put Modem Control Register(MCR) into its reset state of 0x00.
 //
 SerialPortWriteRegister (SerialRegisterBase, R_UART_MCR, 0x00);
-
-return RETURN_SUCCESS;
+Ret = RETURN_SUCCESS;
   }
+  return Ret;
 }
 
 /**
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113961): https://edk2.groups.io/g/devel/message/113961
Mute This Topic: https://groups.io/mt/103796307/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 3/5] Platform/RaspberryPi: Cleanup menu visibility

2024-01-17 Thread Jeremy Linton
Lets allow some of these options to change when the
system is in ACPI+DT mode. Plus the fan temp should
be disabled when ACPI isn't enabled.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index e8bf16312d..f668b7a553 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -196,7 +196,7 @@ formset
 endoneof;
 
 #if (RPI_MODEL == 4)
-grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   oneof varid = FanOnGpio.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANONGPIO_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANONGPIO_HELP),
@@ -207,7 +207,7 @@ formset
   endoneof;
 endif;
 
-grayoutif ideqval FanOnGpio.Enabled == 0;
+grayoutif ideqval FanOnGpio.Enabled == 0 OR ideqval 
SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   numeric varid = FanTemp.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANTEMP_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANTEMP_HELP),
@@ -219,7 +219,7 @@ formset
 endif;
 
 suppressif ideqval XhciPci.Value == 2;
-  grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
 oneof varid = XhciPci.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_XHCIPCI_HELP),
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113963): https://edk2.groups.io/g/devel/message/113963
Mute This Topic: https://groups.io/mt/103796309/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 0/5] Platform/RaspberryPi: Various minor fixes

2024-01-17 Thread Jeremy Linton
This includes a change to always initialize the PL011 to the
configured baud (which should be 115200 for the SBSA UART), which
fixes linux's assumption that SBSA UARTs are pre-programmed for
115200. This in turn (re)enables the PL011 when the console is on the
miniuart per the config.txt file.

Also included is another spin with the DT/XHCI reset patch which puts
removal of the DT node that causes linux to reset the XHCI controller,
as well as an additional patch that updates the DT to match the PCIe
MMIO window we have programmed. This cures much of the problem with
the PCIe/XHCI configuration when booted in DT mode on linux.

There is also a few menu visibility/section tweaks to assure ACPI/DT
specific settings show up at the appropriate time.

As well as a minor fix to work around a bogus compiler warning.

v1->v2: Ard's review comments.
Convert PCIe MMIO address to use the fixedPCDs defined elsewhere
Hardcode 115200 for the SBSA UART
    
Jeremy Linton (5):
  Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011
  Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings
  Platform/RaspberryPi: Cleanup menu visibility
  Platform/RaspberryPi: Give the user control over the XHCI mailbox
  Platform/RaspberryPi: Update PCIe MMIO window for DT

 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 10 +
 .../Drivers/ConfigDxe/ConfigDxe.inf   |  1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|  5 +++
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr| 21 +++--
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c  | 26 +++
 .../RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |  7 +++
 .../DualSerialPortLib/DualSerialPortLib.c | 44 ---
 Platform/RaspberryPi/RPi3/RPi3.dsc|  6 +++
 Platform/RaspberryPi/RPi4/RPi4.dsc|  7 +++
 Platform/RaspberryPi/RaspberryPi.dec  |  1 +
 .../Drivers/Net/BcmGenetDxe/GenericPhy.c  |  2 +
 .../Drivers/Net/BcmGenetDxe/SimpleNetwork.c   |  3 ++
 12 files changed, 115 insertions(+), 18 deletions(-)

-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113960): https://edk2.groups.io/g/devel/message/113960
Mute This Topic: https://groups.io/mt/103796306/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH 1/5] Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011

2024-01-11 Thread Jeremy Linton

Hi,

On 1/11/24 01:46, Ard Biesheuvel wrote:

Hi Jeremy,

Thanks for the patches.


Thanks for looking at them!




On Thu, 11 Jan 2024 at 00:52, Jeremy Linton  wrote:


The rpi's config.txt controls which uart (pl011, or miniuart) is
selected as the console. TFA and edk2 follow its lead, but if the
miniuart is selected as the primary and the machine is booted in ACPI
mode the baud/etc is never configured for the pl011. The linux kernel
won't reconfigure it either as its listed as a "SBSA" uart, so it
simply won't work.

This re-enables BT on the pl011 in ACPI mode, and it somewhat starts
to work again.

Signed-off-by: Jeremy Linton 
---
  .../DualSerialPortLib/DualSerialPortLib.c | 37 +++
  1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index d2f983bf0a..79545d93d6 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -76,6 +76,8 @@ SerialPortInitialize (
EFI_PARITY_TYPE Parity;
UINT8   DataBits;
EFI_STOP_BITS_TYPE  StopBits;
+  RETURN_STATUS   Ret;
+  UINTN   Timeout;


What is this for?


IIRC, its as you see, being used below to avoid an infinite loop when 
the miniuart doesn't become ready. That shouldn't be possible with this 
set, so its a safety change.


But IIRC, the infinite loop can be triggered by trying to enable the 
miniuart early, when its not the console, before the config dxe is run 
to turn the clock/regulator on. Which is what I was originally trying to 
do in this patch by configuring both uarts unconditionally.







//
// First thing we need to do is determine which of PL011 or miniUART is 
selected
@@ -85,23 +87,27 @@ SerialPortInitialize (
  UsePl011UartSet = TRUE;
}

-  if (UsePl011Uart) {
-BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
+  // always init the pl011 on the pi4, linux expects a SBSA uart to be at 
115200
+  // this means we need to set the baud/etc even if we arn't using it as a 
console


^ I should probably fix the spelling issues there too.


+  if ((UsePl011Uart) || (RPI_MODEL == 4)) {
  ReceiveFifoDepth = 0; // Use default FIFO depth
+BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);


Shouldn't we hardcode 115200 here if !UsePl011Uart?


Probably? For spec compliance for sure.

Although the BT as I mentioned is flaky, it will scan and connect to 
things like keyboards/mice and sorta work, although it may drop the 
connections/etc. A2dp devices are a no-go. But, running the port faster 
than 115200 seems to at least extend how long it works. So, presumably 
part of the problem is that the BT wants to bump the baud rate and reset 
the device, neither of which it can do in ACPI mode at the moment. And 
for clarity it does some of this in DT mode too, so its not entirely 
just baud rate and reset problems. I spent a fair bit of time a year+ 
back trying to get the BT to work reliably in just DT mode with mainline 
on the miniuart as well as on the pl011 where it sorta works and moved 
on to other things before solving the problem.


So, I guess I can hard-code it here, at least then we are spec compliant.





  Parity = (EFI_PARITY_TYPE)FixedPcdGet8 (PcdUartDefaultParity);
  DataBits = FixedPcdGet8 (PcdUartDefaultDataBits);
  StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);

-return PL011UartInitializePort (
- PL011_UART_REGISTER_BASE,
- PL011UartClockGetFreq(),
- ,
- ,
- ,
- ,
- 
- );
-  } else {
+Ret = PL011UartInitializePort (
+   PL011_UART_REGISTER_BASE,
+   PL011UartClockGetFreq(),
+   ,
+   ,
+   ,
+   ,
+   
+   );
+  }
+
+  if (!UsePl011Uart) {
  SerialRegisterBase = MINI_UART_REGISTER_BASE;
  Divisor = SerialPortGetDivisor (PcdGet32 (PcdSerialBaudRate));

@@ -127,7 +133,8 @@ SerialPortInitialize (
  // Wait for the serial port to be ready.
  // Verify that both the transmit FIFO and the shift register are empty.
  //
-while ((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY));
+Timeout = 1000;
+while (((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) && 
(Timeout--));

  //
  // Configure baud rate
@@ -158,9 +165,9 @@ SerialPortInitialize (
  // Put Modem Control Register(MCR) into its reset state of 0x00.
  //
  SerialPortWriteRegister (SerialRegisterBase, R_UART_MCR, 0x00);
-
-return RETURN_SUCCESS;
+Ret = RETURN_SUCCESS;
}
+  return

[edk2-devel] [PATCH] Platform/RaspberryPi: Enable FPDT data on RPi4

2024-01-10 Thread Jeremy Linton
FPDT data gives an approximation of how long each stage
of the firmware boot takes. Since the RPi has a generic
timer this is a fairly accurate timestamp from the point
where edk2 takes over, which is a few ms from actual
power on. While its not perfect its sufficiently granular
that a command like `systemd-analyze` shows the debug boot
to be quite slow.

Ex:
[root@rpi4 ~]# systemd-analyze
Startup finished in 24.313s (firmware) + 7.771s (loader) + 2.442s (kernel) + 
5.810s (initrd) + 20.371s (userspace) = 1min 708ms
multi-user.target reached after 17.343s in userspace.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/RPi4/RPi4.dsc | 28 ++--
 Platform/RaspberryPi/RPi4/RPi4.fdf |  7 +++
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 170e45ae7e..e9ca9463ce 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -69,7 +69,8 @@
   BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
   
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
-  
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
+  
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
+
   PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
@@ -279,13 +280,25 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
   gEfiMdePkgTokenSpaceGuid.PcdUgaConsumeSupport|FALSE
 
+  ## Indicates if S3 performance data will be supported in ACPI FPDT table.
+  #   TRUE  - S3 performance data will be supported in ACPI FPDT table.
+  #   FALSE - S3 performance data will not be supported in ACPI FPDT table.
+  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwarePerformanceDataTableS3Support|FALSE
+
 [PcdsFixedAtBuild.common]
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
   gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|1000
   gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF
-  gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|1
+  #define PERFORMANCE_LIBRARY_PROPERTY_MEASUREMENT_ENABLED  0x0001
+  #define PERF_CORE_START_IMAGE  0x0002
+  #define PERF_CORE_LOAD_IMAGE   0x0004
+  #define PERF_CORE_DB_SUPPORT   0x0008
+  #define PERF_CORE_DB_START 0x0010
+  #define PERF_CORE_DB_STOP  0x0020
+  #define PERF_GENERAL_TYPE  0x0040
+  gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0x1
   gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320
 
@@ -324,6 +337,7 @@
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|$(DEBUG_PRINT_ERROR_LEVEL)
 
   gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
+  gEfiMdeModulePkgTokenSpaceGuid.PcdExtFpdtBootRecordPadSize|0x2000
 
   #
   # Optional feature to help prevent EFI memory map fragments
@@ -812,6 +826,16 @@
   Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.inf
 
 
+  #
+  # Firmware Performance Data Table (FPDT)
+  #
+  
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+  
MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.inf
 {
+
+  LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
+  }
+
+  #
   # UEFI application (Shell Embedded Boot Loader)
   #
   ShellPkg/Application/Shell/Shell.inf {
diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf 
b/Platform/RaspberryPi/RPi4/RPi4.fdf
index 989d99a49f..321639fc64 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.fdf
+++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
@@ -326,6 +326,13 @@ READ_LOCK_STATUS   = TRUE
   #
   INF Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf
 
+  #
+  # Firmware Performance Data Table (FPDT)
+  #
+  INF 
MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe/ReportStatusCodeRouterRuntimeDxe.inf
+  INF 
MdeModulePkg/Universal/Acpi/FirmwarePerformanceDataTableDxe/FirmwarePerformanceDxe.inf
+
+
 [FV.FVMAIN_COMPACT]
 FvAlignment= 16
 ERASE_POLARITY = 1
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113564): https://edk2.groups.io/g/devel/message/113564
Mute This Topic: https://groups.io/mt/103653104/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [RFC 3/6] Platform/RasberryPi: Create I2C driver bound to RTC

2024-01-10 Thread Jeremy Linton
Now that we have a generic Bcm I2C driver lets instantiate one
against a possible RTC hat on the pi4.

Signed-off-by: Jeremy Linton 
---
 .../Drivers/BcmI2CPlatform/BcmI2CPlatform.c   | 127 ++
 .../Drivers/BcmI2CPlatform/BcmI2CPlatform.inf |  54 
 2 files changed, 181 insertions(+)
 create mode 100644 Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.c
 create mode 100644 
Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.inf

diff --git a/Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.c 
b/Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.c
new file mode 100644
index 00..11f927b848
--- /dev/null
+++ b/Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.c
@@ -0,0 +1,127 @@
+/** @file
+  Brcm/Rpi I2C DXE platform driver.
+
+  Copyright 2018-2020 NXP
+  Sourced and reworked from edk2/NXP I2C stack
+  Copyright 2022 Arm, Jeremy Linton
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  This thing binds a I2C driver to a RTC..
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+typedef struct {
+  EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR StartDesc;
+  UINT8 EndDesc;
+} ADDRESS_SPACE_DESCRIPTOR;
+
+#define BCM_I2C_NUM_CONTROLLERS 1 //actually 6 on the bcm2711, hack for now
+
+STATIC ADDRESS_SPACE_DESCRIPTOR mI2cDesc[BCM_I2C_NUM_CONTROLLERS];
+
+STATIC
+EFI_STATUS
+RegisterDevice (
+  IN  EFI_GUID*TypeGuid,
+  IN  ADDRESS_SPACE_DESCRIPTOR*Desc,
+  OUT EFI_HANDLE  *Handle
+  )
+{
+  NON_DISCOVERABLE_DEVICE *Device;
+  EFI_STATUS  Status;
+
+  Device = (NON_DISCOVERABLE_DEVICE *)AllocateZeroPool (sizeof (*Device));
+  if (Device == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  Device->Type = TypeGuid;
+  Device->DmaType = NonDiscoverableDeviceDmaTypeNonCoherent;
+  Device->Resources = (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *)Desc;
+
+  Status = gBS->InstallMultipleProtocolInterfaces (Handle,
+  , Device,
+  NULL);
+  if (EFI_ERROR (Status)) {
+goto FreeDevice;
+  }
+  return EFI_SUCCESS;
+
+FreeDevice:
+  FreePool (Device);
+
+  return Status;
+}
+
+VOID
+PopulateI2cInformation (
+  IN VOID
+  )
+{
+  UINT32 Index;
+
+  for (Index = 0; Index < ARRAY_SIZE (mI2cDesc); Index++) {
+mI2cDesc[Index].StartDesc.Desc = ACPI_ADDRESS_SPACE_DESCRIPTOR;
+mI2cDesc[Index].StartDesc.Len = sizeof (EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR) 
- 3;
+mI2cDesc[Index].StartDesc.ResType = ACPI_ADDRESS_SPACE_TYPE_MEM;
+mI2cDesc[Index].StartDesc.GenFlag = 0;
+mI2cDesc[Index].StartDesc.SpecificFlag = 0;
+mI2cDesc[Index].StartDesc.AddrSpaceGranularity = 32;
+mI2cDesc[Index].StartDesc.AddrRangeMin = BCM2836_I2C1_BASE_ADDRESS;
+mI2cDesc[Index].StartDesc.AddrRangeMax = 
mI2cDesc[Index].StartDesc.AddrRangeMin + BCM2836_I2C1_LENGTH;
+mI2cDesc[Index].StartDesc.AddrTranslationOffset = 0;
+mI2cDesc[Index].StartDesc.AddrLen = BCM2836_I2C1_LENGTH;
+
+mI2cDesc[Index].EndDesc = ACPI_END_TAG_DESCRIPTOR;
+  }
+}
+
+EFI_STATUS
+EFIAPI
+BcmI2CPlatformDxeEntryPoint (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_SYSTEM_TABLE   *SystemTable
+  )
+{
+  EFI_STATUS  Status;
+  EFI_HANDLE  Handle;
+
+  Handle = NULL;
+
+  PopulateI2cInformation ();
+
+  if (PcdGet32 (PcdHwRtc))
+  {
+DEBUG ((DEBUG_ERROR, "RTC I2C enable\n"));
+// If we don't register this, the second rtc won't get enabled
+// leaving the emulator in place.
+Status = RegisterDevice (,
+   [0], );
+ASSERT_EFI_ERROR (Status);
+
+//
+// Install the DS1307 I2C Master protocol on this handle so the RTC driver
+// can identify it as the I2C master it can invoke directly.
+//
+Status = gBS->InstallProtocolInterface (,
+,
+EFI_NATIVE_INTERFACE, NULL);
+ASSERT_EFI_ERROR (Status);
+  }  else  {
+DEBUG ((DEBUG_ERROR, "RTC I2C disabled\n"));
+  }
+
+  return EFI_SUCCESS;
+}
diff --git a/Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.inf 
b/Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.inf
new file mode 100644
index 00..aa5c1b51b2
--- /dev/null
+++ b/Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.inf
@@ -0,0 +1,54 @@
+## @file
+#
+#  Component description file for Bcm/Rpi I2C driver.
+#
+#  Copyright 2018-2020 NXP
+#  Sourced and reworked from edk2/NXP I2C stack
+#  Copyright 2022 Arm, Jeremy Linton
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = BcmI2CPlatformDxe
+  FILE_GUID  = 1a23fe23-39bc-4bee-859d-ecb5bbb60484
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= BcmI2CPlatformDxeEntryPoint
+
+[Sou

[edk2-devel] [RFC 4/6] Silicon/Maxim: Fix runtime issues

2024-01-10 Thread Jeremy Linton
The Ds1307 is ideally a runtime RTC but its use of the I2C
protocol might make it better if it updated the I2C_MASTER_PROTOCOL
callbacks it uses, although... hmmm maybe think about this
a bit more.

Signed-off-by: Jeremy Linton 
---
 .../Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c | 36 +--
 .../Library/Ds1307RtcLib/Ds1307RtcLib.inf |  7 +++-
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c 
b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c
index 444e011248..ede890448f 100644
--- a/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c
+++ b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c
@@ -18,14 +18,40 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "Ds1307Rtc.h"
 
 STATIC VOID   *mDriverEventRegistration;
 STATIC EFI_HANDLE mI2cMasterHandle;
+STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
 STATIC EFI_I2C_MASTER_PROTOCOL*mI2cMaster;
 
+
+/**
+  Fixup internal data so that EFI can be call in virtual mode.
+  Call the passed in Child Notify event and convert any pointers in
+  lib to virtual mode.
+
+  @param[in]Event   The Event that is being processed
+  @param[in]Context Event Context
+**/
+VOID
+EFIAPI
+LibRtcVirtualNotifyEvent (
+  IN EFI_EVENTEvent,
+  IN VOID *Context
+  )
+{
+  EfiConvertPointer (0x0, (VOID **)>SetBusFrequency);
+  EfiConvertPointer (0x0, (VOID **)>Reset);
+  EfiConvertPointer (0x0, (VOID **)>StartRequest);
+  EfiConvertPointer (0x0, (VOID **)>I2cControllerCapabilities);
+  EfiConvertPointer (0x0, (VOID **));
+}
+
+
 /**
   Read RTC register.
   Data Read-Slave Transmitter Mode
@@ -54,7 +80,7 @@ RtcRead (
 
   Req.OperationCount = 2;
 
-  Req.SetAddressOp.Flags = 0;
+  Req.SetAddressOp.Flags = 0; //I2C_FLAG_WRITE
   Req.SetAddressOp.LengthInBytes = sizeof (RtcRegAddr);
   Req.SetAddressOp.Buffer = 
 
@@ -98,7 +124,7 @@ RtcWrite (
   Buffer[0] = RtcRegAddr;
   Buffer[1] = Val;
 
-  Req.SetAddressOp.Flags = 0;
+  Req.SetAddressOp.Flags = 0; //I2C_FLAG_WRITE
   Req.SetAddressOp.LengthInBytes = sizeof (Buffer);
   Req.SetAddressOp.Buffer = Buffer;
 
@@ -375,5 +401,11 @@ LibRtcInitialize (
 NULL,
 );
 
+  Status = gBS->CreateEventEx (EVT_NOTIFY_SIGNAL, TPL_NOTIFY,
+  LibRtcVirtualNotifyEvent, NULL,
+  ,
+  );
+  ASSERT_EFI_ERROR (Status);
+
   return EFI_SUCCESS;
 }
diff --git a/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf 
b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
index b92f658bfc..9d8cf16d28 100644
--- a/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
+++ b/Silicon/Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.inf
@@ -28,6 +28,9 @@
   UefiBootServicesTableLib
   UefiLib
 
+[Guids]
+  gEfiEventVirtualAddressChangeGuid
+
 [Protocols]
   gEfiI2cMasterProtocolGuid  ## CONSUMES
   gDs1307RealTimeClockLibI2cMasterProtocolGuid   ## CONSUMES
@@ -36,5 +39,7 @@
   gDs1307RtcLibTokenSpaceGuid.PcdI2cSlaveAddress
   gDs1307RtcLibTokenSpaceGuid.PcdI2cBusFrequency
 
+# 2.15 EDK II INF, .. the generic (i.e depex).. are not permitted
+# yet it ANDs this into the parent's depex
 [Depex]
-  gDs1307RealTimeClockLibI2cMasterProtocolGuid
+  gDs1307RealTimeClockLibI2cMasterProtocolGuid AND gEfiI2cMasterProtocolGuid
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113561): https://edk2.groups.io/g/devel/message/113561
Mute This Topic: https://groups.io/mt/103653100/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [RFC 2/6] Silicon/Bcm283x: Add core I2C drivers

2024-01-10 Thread Jeremy Linton
There are a number of I2C interfaces on the rpi, some of which are
available on the GPIO connector and are utilized by various HATs. In
particular we are interested in the RTCs (usually based on DS1037)
which are attached to GPIO2/3 which can be pin muxed to I2C #1.

This commit adds a basic runtime utilizable I2C Dxe in preparation
for a platform driver which can bind it to the ds1307 RTC driver.

Signed-off-by: Jeremy Linton 
---
 .../Broadcom/Drivers/I2cDxe/ComponentName.c   | 181 ++
 .../Broadcom/Drivers/I2cDxe/DriverBinding.c   | 237 ++
 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.c  | 309 ++
 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.h  |  55 
 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.inf|  56 
 5 files changed, 838 insertions(+)
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/ComponentName.c
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/DriverBinding.c
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.c
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.h
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.inf

diff --git a/Silicon/Broadcom/Drivers/I2cDxe/ComponentName.c 
b/Silicon/Broadcom/Drivers/I2cDxe/ComponentName.c
new file mode 100644
index 00..75b4fdb3fe
--- /dev/null
+++ b/Silicon/Broadcom/Drivers/I2cDxe/ComponentName.c
@@ -0,0 +1,181 @@
+/** @file
+
+  Copyright 2018-2019 NXP
+  Sourced and reworked from edk2/NXP I2C stack
+  Copyright 2022 Arm, Jeremy Linton
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include "I2cDxe.h"
+
+STATIC EFI_UNICODE_STRING_TABLE mBcmI2cDriverNameTable[] = {
+  {
+"en",
+(CHAR16 *)L"Bcm I2C Driver"
+  },
+  { }
+};
+
+STATIC EFI_UNICODE_STRING_TABLE mBcmI2cControllerNameTable[] = {
+  {
+"en",
+(CHAR16 *)L"Bcm I2C Controller"
+  },
+  { }
+};
+
+/**
+  Retrieves a Unicode string that is the user readable name of the driver.
+
+  This function retrieves the user readable name of a driver in the form of a
+  Unicode string. If the driver specified by This has a user readable name in
+  the language specified by Language, then a pointer to the driver name is
+  returned in DriverName, and EFI_SUCCESS is returned. If the driver specified
+  by This does not support the language specified by Language,
+  then EFI_UNSUPPORTED is returned.
+
+  @param  This[in]  A pointer to the EFI_COMPONENT_NAME2_PROTOCOL 
or
+EFI_COMPONENT_NAME_PROTOCOL instance.
+
+  @param  Language[in]  A pointer to a Null-terminated ASCII string
+array indicating the language. This is the
+language of the driver name that the caller is
+requesting, and it must match one of the
+languages specified in SupportedLanguages. The
+number of languages supported by a driver is up
+to the driver writer. Language is specified
+in RFC 4646 or ISO 639-2 language code format.
+
+  @param  DriverName[out]   A pointer to the Unicode string to return.
+This Unicode string is the name of the
+driver specified by This in the language
+specified by Language.
+
+  @retval EFI_SUCCESS   The Unicode string for the Driver specified by
+This and the language specified by Language was
+returned in DriverName.
+
+  @retval EFI_INVALID_PARAMETER Language is NULL.
+
+  @retval EFI_INVALID_PARAMETER DriverName is NULL.
+
+  @retval EFI_UNSUPPORTED   The driver specified by This does not support
+the language specified by Language.
+
+**/
+STATIC
+EFI_STATUS
+EFIAPI
+BcmI2cGetDriverName (
+  IN  EFI_COMPONENT_NAME2_PROTOCOL  *This,
+  IN  CHAR8 *Language,
+  OUT CHAR16**DriverName
+  )
+{
+  return LookupUnicodeString2 (Language,
+   This->SupportedLanguages,
+   mBcmI2cDriverNameTable,
+   DriverName,
+   FALSE);
+}
+
+/**
+  Retrieves a Unicode string that is the user readable name of the controller
+  that is being managed by a driver.
+
+  This function retrieves the user readable name of the controller specified by
+  ControllerHandle and ChildHandle in the form of a Unicode string. If the
+  driver specified by This has a user readable name in the language specified 
by
+  Language, then a pointer to the controller name is returned in 
ControllerName,
+  and EFI_SUCCESS is returned.  If the driver specified by This is not 
currently
+  managing the controller specified by ControllerHandle and ChildHandle,
+  then 

[edk2-devel] [RFC 5/6] Platform/RasberryPi: Add I2C1 to uefi runtime memory map

2024-01-10 Thread Jeremy Linton
We intend to allow the OS to update the RTC after exit boot services.
THis means we need to assure that the I2C IO map is marked correctly.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 377ef438ff..fec8f63ea8 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -505,6 +505,7 @@ ApplyVariables (
   }
 
   if (mModelFamily == 4) {
+// add memoryspaces for the runtime flash/variable store
 Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
BCM2836_SPI0_BASE_ADDRESS,
   SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
 ASSERT_EFI_ERROR (Status);
@@ -517,6 +518,13 @@ ApplyVariables (
 Status = gDS->SetMemorySpaceAttributes (GPIO_BASE_ADDRESS,
 SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
 
+// add memoryspace for the runtime rtc/i2c
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
BCM2836_I2C1_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (BCM2836_I2C1_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
 ASSERT_EFI_ERROR (Status);
   }
 
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113562): https://edk2.groups.io/g/devel/message/113562
Mute This Topic: https://groups.io/mt/103653101/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [RFC 6/6] Platform/RaspberryPi: Add menu and build options for HW RTC

2024-01-10 Thread Jeremy Linton
Now that the i2c drivers, config setup, and DS1307 driver are
in place, lets add the drivers to the build. We also add a menu
item to enable/disable it since the device I have:

https://www.amazon.com/Makerfire%C2%AE-Raspberry-Module-DS1307-Battery/dp/B00ZOXWHK4

Doesn't utilize the HAT protocol so it cannot be detected.

Signed-off-by: Jeremy Linton 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 22 ++
 .../Drivers/ConfigDxe/ConfigDxe.inf   |  1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|  6 
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr| 16 ++
 Platform/RaspberryPi/Include/ConfigVars.h |  4 +++
 Platform/RaspberryPi/RPi3/RPi3.dsc|  7 +
 Platform/RaspberryPi/RPi4/RPi4.dsc| 30 +++
 Platform/RaspberryPi/RPi4/RPi4.fdf| 19 
 Platform/RaspberryPi/RaspberryPi.dec  |  2 ++
 9 files changed, 107 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index fec8f63ea8..0397941a06 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -319,6 +319,16 @@ SetupVariables (
   ASSERT_EFI_ERROR (Status);
 }
 
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"HwRtc",
+   ,
+   NULL, , );
+if (EFI_ERROR (Status)) {
+  Status = PcdSet32S (PcdHwRtc, PcdGet32 (PcdHwRtc));
+  ASSERT_EFI_ERROR (Status);
+}
+
+
   } else {
 /*
  * Disable PCIe and XHCI
@@ -716,6 +726,18 @@ ApplyVariables (
 GpioPinFuncSet (33, GPIO_FSEL_ALT3);
   }
 
+  // Assure I2C1 is selected on header
+  if (PcdGet32 (PcdHwRtc)) {
+UINT32 ClockRate;
+DEBUG ((DEBUG_INFO, "Enable SDA1\n"));
+GpioPinFuncSet (2, GPIO_FSEL_ALT0);
+GpioPinFuncSet (3, GPIO_FSEL_ALT0);
+
+mFwProtocol->GetClockRate (RPI_MBOX_CLOCK_RATE_CORE, );
+ClockRate/=5; //50Khz slow it down a bit initially
+
+MmioWrite32 (BCM2836_I2C1_OFFSET + BCM2836_SOC_REGISTERS + 
BCM2835_I2C_DIV, ClockRate ); //was 5dc which assumes a 150Mhz clock, when we 
are usually at 500Mhz?
+  }
 }
 
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e422e5ba5c..4c213174ce 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -98,6 +98,7 @@
   gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate
   gRaspberryPiTokenSpaceGuid.PcdXhciReload
   gRaspberryPiTokenSpaceGuid.PcdEnableGpio
+  gRaspberryPiTokenSpaceGuid.PcdHwRtc
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index fb06d46a61..8da143d519 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -72,6 +72,12 @@
 #string STR_ADVANCED_ENABLEGPIO_DISABLE #language en-US "Disabled"
 #string STR_ADVANCED_ENABLEGPIO_ENABLE  #language en-US "Enable"
 
+#string STR_ADVANCED_ENABLEHWRTC_PROMPT  #language en-US "Enable Hardware RTC"
+#string STR_ADVANCED_ENABLEHWRTC_HELP#language en-US "A DS1307 hardware 
real time clock is attached on I2C1."
+#string STR_ADVANCED_ENABLEHWRTC_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_ENABLEHWRTC_ENABLE  #language en-US "Enable"
+
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 04eb0a15a2..b7146b7e8c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -71,6 +71,11 @@ formset
   name  = EnableGpio,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_ENABLEHWRTC_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = HwRtc,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -259,6 +264,17 @@ formset
 option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_ENABLE), value 
= 1, flags = 0;
   endoneof;
 endif;
+
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
+  oneof varid = HwRtc.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_ENABLEHWRTC_PROMPT),
+  help  

[edk2-devel] [RFC 0/6] RasberryPi: RTC HAT support

2024-01-10 Thread Jeremy Linton
There are a number of Dallas 1307 based RTC HATs available for the RPi
that don't follow the HAT ID protocol but are simple, inexpensive and
widely available. Lets add an I2C driver and then allow the user to
enable them in the advanced menu. Once enabled and detected we then
dynamically swap them in to provide UEFI runtime RTC.

Its this latter bit of logic which seems to be unique to this platform
and probably should be closely reviewed.

Jeremy Linton (6):
  Silicon/Bcm283x: Document the I2C registers
  Silicon/Bcm283x: Add core I2C drivers
  Platform/RasberryPi: Create I2C driver bound to RTC
  Silicon/Maxim: Fix runtime issues
  Platform/RasberryPi: Add I2C1 to uefi runtime memory map
  Platform/RaspberryPi: Add menu and build options for HW RTC

 .../Drivers/BcmI2CPlatform/BcmI2CPlatform.c   | 127 +++
 .../Drivers/BcmI2CPlatform/BcmI2CPlatform.inf |  54 +++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  30 ++
 .../Drivers/ConfigDxe/ConfigDxe.inf   |   1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|   6 +
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr|  16 +
 Platform/RaspberryPi/Include/ConfigVars.h |   4 +
 Platform/RaspberryPi/RPi3/RPi3.dsc|   7 +
 Platform/RaspberryPi/RPi4/RPi4.dsc|  30 ++
 Platform/RaspberryPi/RPi4/RPi4.fdf|  19 ++
 Platform/RaspberryPi/RaspberryPi.dec  |   2 +
 .../Include/IndustryStandard/Bcm2836.h|  34 ++
 .../Broadcom/Drivers/I2cDxe/ComponentName.c   | 181 ++
 .../Broadcom/Drivers/I2cDxe/DriverBinding.c   | 237 ++
 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.c  | 309 ++
 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.h  |  55 
 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.inf|  56 
 .../Maxim/Library/Ds1307RtcLib/Ds1307RtcLib.c |  36 +-
 .../Library/Ds1307RtcLib/Ds1307RtcLib.inf |   7 +-
 19 files changed, 1208 insertions(+), 3 deletions(-)
 create mode 100644 Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.c
 create mode 100644 
Platform/RaspberryPi/Drivers/BcmI2CPlatform/BcmI2CPlatform.inf
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/ComponentName.c
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/DriverBinding.c
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.c
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.h
 create mode 100644 Silicon/Broadcom/Drivers/I2cDxe/I2cDxe.inf

-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113557): https://edk2.groups.io/g/devel/message/113557
Mute This Topic: https://groups.io/mt/103653096/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [RFC 1/6] Silicon/Bcm283x: Document the I2C registers

2024-01-10 Thread Jeremy Linton
Since we are now using I2C in edk2, its helpful if we document
the register names.

Signed-off-by: Jeremy Linton 
---
 .../Include/IndustryStandard/Bcm2836.h| 34 +++
 1 file changed, 34 insertions(+)

diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
index 55a446a86c..6dc8921346 100644
--- a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
@@ -97,6 +97,40 @@
 #define BCM2836_I2C2_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_I2C2_OFFSET)
 #define BCM2836_I2C2_LENGTH 0x0020
 
+#define BCM2836_I2C3_OFFSET 0x00205600
+#define BCM2836_I2C3_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_I2C3_OFFSET)
+#define BCM2836_I2C3_LENGTH 0x0020
+
+#define BCM2836_I2C4_OFFSET 0x00205800
+#define BCM2836_I2C4_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_I2C4_OFFSET)
+#define BCM2836_I2C4_LENGTH 0x0020
+
+#define BCM2836_I2C5_OFFSET 0x00205a00 //2711 
doc says 205a80?!
+#define BCM2836_I2C5_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_I2C5_OFFSET)
+#define BCM2836_I2C5_LENGTH 0x0020
+
+#define BCM2836_I2C6_OFFSET 0x00205c00
+#define BCM2836_I2C6_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_I2C6_OFFSET)
+#define BCM2836_I2C6_LENGTH 0x0020
+
+#define BCM2836_I2C20_OFFSET0x00f04500 //2711 
DCC0
+#define BCM2836_I2C20_BASE_ADDRESS  
(BCM2836_SOC_REGISTERS + BCM2836_I2C20_OFFSET)
+#define BCM2836_I2C20_LENGTH0x0020
+
+#define BCM2836_I2C21_OFFSET0x00f09500 //2711 
DCC1
+#define BCM2836_I2C21_BASE_ADDRESS  
(BCM2836_SOC_REGISTERS + BCM2836_I2C21_OFFSET)
+#define BCM2836_I2C21_LENGTH0x0020
+
+/* I2C register offsets */
+#define BCM2835_I2C_C  0x00
+#define BCM2835_I2C_S  0x04
+#define BCM2835_I2C_DLEN   0x08
+#define BCM2835_I2C_A  0x0c
+#define BCM2835_I2C_FIFO   0x10
+#define BCM2835_I2C_DIV0x14
+#define BCM2835_I2C_DEL0x18
+#define BCM2835_I2C_CLKT   0x1c
+
 #define BCM2836_SPI0_OFFSET 0x00204000
 #define BCM2836_SPI0_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_SPI0_OFFSET)
 #define BCM2836_SPI0_LENGTH 0x0020
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113558): https://edk2.groups.io/g/devel/message/113558
Mute This Topic: https://groups.io/mt/103653097/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 3/7] Platform/RaspberryPi: Add constants for controlling SPI

2024-01-10 Thread Jeremy Linton
Add the #defines needed to access the SPI interface
documented in the BCM2711 Peripheral guide chapter 8.

Signed-off-by: Jeremy Linton 
---
 .../Include/IndustryStandard/Bcm2836.h| 34 +++
 1 file changed, 34 insertions(+)

diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
index a930c64af3..55a446a86c 100644
--- a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
@@ -109,6 +109,40 @@
 #define BCM2836_SPI2_LENGTH 0x0040
 #define BCM2836_SPI2_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_SPI2_OFFSET)
 
+/* SPI register offsets */
+#define BCM2835_SPI_CS  0x00
+#define BCM2835_SPI_FIFO0x04
+#define BCM2835_SPI_CLK 0x08
+#define BCM2835_SPI_DLEN0x0c
+#define BCM2835_SPI_LTOH0x10
+#define BCM2835_SPI_DC  0x14
+
+/* Bitfields in CS */
+#define BCM2835_SPI_CS_LEN_LONG 0x0200
+#define BCM2835_SPI_CS_DMA_LEN  0x0100
+#define BCM2835_SPI_CS_CSPOL2   0x0080
+#define BCM2835_SPI_CS_CSPOL1   0x0040
+#define BCM2835_SPI_CS_CSPOL0   0x0020
+#define BCM2835_SPI_CS_RXF  0x0010
+#define BCM2835_SPI_CS_RXR  0x0008
+#define BCM2835_SPI_CS_TXD  0x0004
+#define BCM2835_SPI_CS_RXD  0x0002
+#define BCM2835_SPI_CS_DONE 0x0001
+#define BCM2835_SPI_CS_LEN  0x2000
+#define BCM2835_SPI_CS_REN  0x1000
+#define BCM2835_SPI_CS_ADCS 0x0800
+#define BCM2835_SPI_CS_INTR 0x0400
+#define BCM2835_SPI_CS_INTD 0x0200
+#define BCM2835_SPI_CS_DMAEN0x0100
+#define BCM2835_SPI_CS_TA   0x0080
+#define BCM2835_SPI_CS_CSPOL0x0040
+#define BCM2835_SPI_CS_CLEAR_RX 0x0020
+#define BCM2835_SPI_CS_CLEAR_TX 0x0010
+#define BCM2835_SPI_CS_CPOL 0x0008
+#define BCM2835_SPI_CS_CPHA 0x0004
+#define BCM2835_SPI_CS_CS_100x0002
+#define BCM2835_SPI_CS_CS_010x0001
+
 /* dma constants */
 #define BCM2836_DMA0_OFFSET 0x7000
 #define BCM2836_DMA0_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_DMA0_OFFSET)
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113552): https://edk2.groups.io/g/devel/message/113552
Mute This Topic: https://groups.io/mt/103653088/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 5/7] Platform/RaspberryPi: Add SPI/GPIO to memory map

2024-01-10 Thread Jeremy Linton
A large reason for using the SPI flash on this platform is that
it can be updated without OS interference at rutime. In order for
that to happen we need both the SPI, as well as the GPIO
which is used to change the pinmux from the PWM device to SPI added
to the UEFI memory map as being used by the runtime service.

Signed-off-by: Jeremy Linton 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 16 
 1 file changed, 16 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 151f3cd801..377ef438ff 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -504,6 +504,22 @@ ApplyVariables (
 DEBUG ((DEBUG_INFO, "Current CPU speed is %u MHz\n", Rate / FREQ_1_MHZ));
   }
 
+  if (mModelFamily == 4) {
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
BCM2836_SPI0_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (BCM2836_SPI0_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
GPIO_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (GPIO_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
+ASSERT_EFI_ERROR (Status);
+  }
+
   if (mModelFamily >= 4 && PcdGet32 (PcdRamMoreThan3GB) != 0 &&
   PcdGet32 (PcdRamLimitTo3GB) == 0) {
 UINT64 SystemMemorySize;
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113554): https://edk2.groups.io/g/devel/message/113554
Mute This Topic: https://groups.io/mt/103653091/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 6/7] Platform/RaspberryPi: Allow pin function selection at runtime

2024-01-10 Thread Jeremy Linton
Update GpioLib slightly so that we can change the GPIO pin
muxing at runtime. For the moment only the GpioPinFuncGet/Set()
routines are used at runtime, and only by the Variable service.

Signed-off-by: Jeremy Linton 
---
 .../Broadcom/Bcm283x/Include/Library/GpioLib.h   |  6 ++
 .../Broadcom/Bcm283x/Library/GpioLib/GpioLib.c   | 16 ++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
index 1f7d2204e0..79765be4fb 100644
--- a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -45,4 +45,10 @@ GpioSetPull (
   IN  UINTN   Pud
 );
 
+VOID
+GpioSetupRuntime (
+  VOID
+);
+
+
 #endif /* __GPIO_LIB__ */
diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
index eaf53e5369..fc1f928e6b 100644
--- a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -15,10 +15,22 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+
+STATIC EFI_PHYSICAL_ADDRESS GpioGfpSel0 = GPIO_GPFSEL0;
+
+VOID
+GpioSetupRuntime (
+  VOID
+  )
+{
+  EfiConvertPointer (0x0, (VOID**));
+}
+
 STATIC
 VOID
 GpioFSELModify (
@@ -30,7 +42,7 @@ GpioFSELModify (
   UINT32 Val;
   EFI_PHYSICAL_ADDRESS Reg;
 
-  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+  Reg = RegIndex * sizeof (UINT32) + GpioGfpSel0;
 
   ASSERT (Reg <= GPIO_GPFSEL5);
   ASSERT ((~ModifyMask & FunctionMask) == 0);
@@ -77,7 +89,7 @@ GpioPinFuncGet (
 
   RegIndex = Pin / 10;
   SelIndex = Pin % 10;
-  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+  Reg = RegIndex * sizeof (UINT32) + GpioGfpSel0;
 
   Val = MmioRead32 (Reg);
   Val >>= SelIndex * GPIO_FSEL_BITS_PER_PIN;
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113555): https://edk2.groups.io/g/devel/message/113555
Mute This Topic: https://groups.io/mt/103653092/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 7/7] Platform/RaspberryPi: Add SPI flash variable store.

2024-01-10 Thread Jeremy Linton
The RPi4 has a 512KB SPI flash, which depending on RPi
and firmware revision has 300-180K free. We can use this
storage to persist variables when the OS is running or
over firmware upgrades. The problem is that the SPI is pin
mux'ed with the PWM audio, so we want to leave the PWM
configured for OS use. And of course there is the problem
of sharing the GPIO block with OS's that are aware of it.
Hence a previous patch set which moves the GPIO and some of
the low level i2c/etc devices into its own SSDT, and
disables them by default.

This patch, adds a few SPI access functions directly to
the variable store rather than creating another runtime
service since the early boot ordering is critical. These
functions are of the form ReadSpi(), WriteSpi(),
DisableSpiWp(), etc all with Spi in the name. On top of that
a few "Flash" routines are created which provide high level
functions for reading/writing and walking the portion of the
SPI flash we use to clone the variable store region.
Importantly WalkFlashVolume() walks the entire SPI flash
region, which has a simple header structure containing
filename+len for each region of the flash, to return how
much of the capacity is being utilized by the existing
bootloader/etc firmware.

So, if this is a RPi4, and there is sufficient space, and
that space doesn't have a valid varstore header we erase
it and flush the RPI's varstore region to the SPI. Then
we note its starting offset in mFvInstance->FlashOffset.
>From then on, writes to the EFI_FW_VOL_BLOCK_DEVICE are
written to both the RAM copy as well as the SPI flash. If
the empty region has a valid header we read the entire
region overtop of the one being passed as part of the RPi's
BL33, and continue as above.

At ready to boot we re-enable the LDO, and then during the
dump vars check, we check for DT or the GPIO being enabled
and disable the runtime SPI updates because we can't be sure
of what the OS might be doing with the GPIO. The dual ACPI
and DT mode, leaves it enabled (if GPIO is disabled) so
care should be taken.

Now, one of the problems here is that with the LDO enabled
any SPI accesses can be heard over the speakers as pops,
buzzes, or scratchy tones. This is happening even without
this patch because TFA and/or the rpi low level firmware
doesn't itself assure the LDO is disabled during resets, so
the early SoC startup is quite noisy. We add to this, but
alongside that a couple fairly trivial TFA patchs, to mute
it before reset, and again assure its off before releasing
to us solve a large part of this problem. That said, this
can now happen during runtime as well. Generally the OS's
aren't doing a lot of variable updates, but when they do
its generally barely noticable clicks since we aren't going
through the long process of muting/unmuting the LDO which
itself causes a pop.

So, this patch fixes a whole bunch of bugs on github that
exist because the variable store isn't persisted. It also
fixes a rather large bug in the existing variable store
code caused by the FaultTolerantWriteDxe erasing the entire
variable store region when it garbage collects during startup.
That latter bug is the result of FvbGetLbaAddress reading
recently erased data from the VolumeHeader before its been
recreated, and results in random UEFI crashes.

Signed-off-by: Jeremy Linton 
---
 .../Drivers/VarBlockServiceDxe/FvbInfo.c  |   8 +-
 .../VarBlockServiceDxe/VarBlockService.c  | 669 +-
 .../VarBlockServiceDxe/VarBlockService.h  |  10 +
 .../VarBlockServiceDxe/VarBlockServiceDxe.c   |  69 +-
 .../VarBlockServiceDxe/VarBlockServiceDxe.inf |   7 +
 Platform/RaspberryPi/RPi4/RPi4.dsc|   5 +-
 6 files changed, 743 insertions(+), 25 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
index 0e0c108dba..ee18f327e6 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
@@ -11,12 +11,7 @@
 #include 
 #include 
 #include 
-
-typedef struct {
-  UINT64  FvLength;
-  EFI_FIRMWARE_VOLUME_HEADER  FvbInfo;
-  EFI_FV_BLOCK_MAP_ENTRY  End[1];
-} EFI_FVB_MEDIA_INFO;
+#include "VarBlockService.h"
 
 EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   //
@@ -38,6 +33,7 @@ EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   FixedPcdGet32 (PcdNvStorageEventLogSize),
   EFI_FVH_SIGNATURE,
   EFI_FVB2_MEMORY_MAPPED |
+EFI_FVB2_STICKY_WRITE |
 EFI_FVB2_READ_ENABLED_CAP |
 EFI_FVB2_READ_STATUS |
 EFI_FVB2_WRITE_ENABLED_CAP |
diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
index 572309439a..3b83d7ead8 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlo

[edk2-devel] [PATCH 1/7] Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT

2024-01-10 Thread Jeremy Linton
The UEFI firmware uses the GPIO port for the fan and
real soon now the runtime SPI variable store. As such
we need to be able to either isolate those devices from
the OS or we risk clashing with OS's that reconfigure
the GPIO pins. Ideally we would just rip this out
and use _DSM() or just individual device power
on/off methods to adjust the GPIO pins when needed.

For now, lets leave it since windows at least knows
about it. In the future we will decide whether the
firmware is controlling something (SPI!) based on
whether the user has enabled the GPIO block.

Signed-off-by: Jeremy Linton 
---
 .../RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl  |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl   | 126 --
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl  | 159 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   6 +
 5 files changed, 166 insertions(+), 133 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index da2a6db85f..3894d00565 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -40,6 +40,7 @@
   SsdtThermal.asl
   Xhci.asl
   Pci.asl
+  SsdtGpio.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index b594d50bdf..08acc81d57 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -21,13 +21,6 @@
 
 #include "AcpiTables.h"
 
-#define BCM_ALT0 0x4
-#define BCM_ALT1 0x5
-#define BCM_ALT2 0x6
-#define BCM_ALT3 0x7
-#define BCM_ALT4 0x3
-#define BCM_ALT5 0x2
-
 //
 // The ASL compiler does not support argument arithmetic in functions
 // like QWordMemory (). So we need to instantiate dummy qword regions
diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl 
b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
index 9750dc25c0..3399f0fc9a 100644
--- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
+++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
@@ -203,56 +203,6 @@ Device (VCSM)
   }
 }
 
-// Description: GPIO
-Device (GPI0)
-{
-  Name (_HID, "BCM2845")
-  Name (_CID, "BCM2845")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, GPIO_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared)
-{
-  BCM2386_GPIO_INTERRUPT0, BCM2386_GPIO_INTERRUPT1,
-  BCM2386_GPIO_INTERRUPT2, BCM2386_GPIO_INTERRUPT3
-}
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, GPIO_OFFSET)
-Return (^RBUF)
-  }
-}
-
-// Description: I2C
-Device (I2C1)
-{
-  Name (_HID, "BCM2841")
-  Name (_CID, "BCM2841")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_I2C1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_I2C1_INTERRUPT }
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 2, 3 }
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_I2C1_OFFSET)
-Return (^RBUF)
-  }
-}
 
 // I2C2 is the HDMI DDC connection
 Device (I2C2)
@@ -278,81 +228,6 @@ Device (I2C2)
   }
 }
 
-// SPI
-Device (SPI0)
-{
-  Name (_HID, "BCM2838")
-  Name (_CID, "BCM2838")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI0_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_SPI0_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 9, 10, 11 } // MISO, MOSI, SCLK
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 8 } // CE0
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 7 } // CE1
-  })
-
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_SPI0_OFFSET)
-Return (^RBUF)
-  }
-}
-
-Device (SPI1)
-{
-  Name (_HID, "BCM2839")
-  Name (_CID, "BCM2839")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Name (_DEP, Package() { \_SB.GDV0.RPIQ })
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared,) { 
BCM2836_SPI1_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT4, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 19, 20, 21 } // MISO, MOSI, S

[edk2-devel] [PATCH 2/7] Platform/RaspberryPi: Add menu item to enable/disable GPIO

2024-01-10 Thread Jeremy Linton
Now that the GPIO devices are in their own SSDT lets add
a menu item for the rpi4 to enable/disable it. For the
rpi3 the SSDT is always exported.

Signed-off-by: Jeremy Linton 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c   | 17 -
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf |  1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni  |  5 +
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr  | 15 +++
 Platform/RaspberryPi/Include/ConfigVars.h   |  4 
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 8 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index dd01e9a8dc..151f3cd801 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -309,12 +309,27 @@ SetupVariables (
   }
 
 }
+
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"EnableGpio",
+   ,
+   NULL, , );
+if (EFI_ERROR (Status)) {
+  Status = PcdSet32S (PcdEnableGpio, PcdGet32 (PcdEnableGpio));
+  ASSERT_EFI_ERROR (Status);
+}
+
   } else {
 /*
  * Disable PCIe and XHCI
  */
 Status = PcdSet32S (PcdXhciPci, 0);
 ASSERT_EFI_ERROR (Status);
+/*
+ * Enable GPIO
+ */
+Status = PcdSet32S (PcdEnableGpio, 1);
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (AssetTagVar);
@@ -842,7 +857,7 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
 #endif
   {
 SIGNATURE_64 ('R', 'P', 'I', '3', 'G', 'P', 'I', 'O'),
-0,
+PcdToken (PcdEnableGpio),
 0,
 NULL
   },
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 475e645537..e422e5ba5c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -97,6 +97,7 @@
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
   gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate
   gRaspberryPiTokenSpaceGuid.PcdXhciReload
+  gRaspberryPiTokenSpaceGuid.PcdEnableGpio
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 8130638876..fb06d46a61 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -67,6 +67,11 @@
 #string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
 #string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
 
+#string STR_ADVANCED_ENABLEGPIO_PROMPT  #language en-US "Export GPIO devices 
to OS"
+#string STR_ADVANCED_ENABLEGPIO_HELP#language en-US "OS can see the GPIO 
device and some low level SPI and I2C interfaces. Enabling this option will 
disable runtime variable support."
+#string STR_ADVANCED_ENABLEGPIO_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_ENABLEGPIO_ENABLE  #language en-US "Enable"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f13b70711d..04eb0a15a2 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -66,6 +66,11 @@ formset
   name  = XhciReload,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_ENABLEGPIO_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = EnableGpio,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -244,6 +249,16 @@ formset
 endoneof;
   endif;
 endif;
+
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
+  oneof varid = EnableGpio.Value,
+prompt  = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_PROMPT),
+help= STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_HELP),
+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_DISABLE), value 
= 0, flags = DEFAULT;
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_ENABLE), value 
= 1, flags = 0;
+  endoneof;
+endif;
 #endif
 string varid = AssetTag.AssetT

[edk2-devel] [PATCH 4/7] Platform/RaspberryPi: Add mailbox cmd to control audio amp

2024-01-10 Thread Jeremy Linton
The lower level firmware can enable/disable a LDO audio
amp, which allows us to mute/unmute audio output while
the firmware is running.

Signed-off-by: Jeremy Linton 
---
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   | 60 ++-
 .../Include/IndustryStandard/RpiMbox.h|  1 +
 .../Include/Protocol/RpiFirmware.h|  7 +++
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index 4edec0ad04..ea0ac1eefe 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -1532,6 +1532,63 @@ RpiFirmwareNotifyGpioSetCfg (
   return Status;
 }
 
+#pragma pack()
+typedef struct {
+  UINT32   State;
+} RPI_FW_SET_LDO_REG_TAG;
+
+typedef struct {
+  RPI_FW_BUFFER_HEAD   BufferHead;
+  RPI_FW_TAG_HEAD  TagHead;
+  RPI_FW_SET_LDO_REG_TAG   TagBody;
+  UINT32   EndTag;
+} RPI_FW_SET_LDO_REG_CMD;
+#pragma pack()
+
+
+STATIC
+EFI_STATUS
+EFIAPI
+RpiFirmwareSetLdoRegState (
+  IN UINTN State
+  )
+{
+  RPI_FW_SET_LDO_REG_CMD   *Cmd;
+  EFI_STATUS   Status;
+  UINT32   Result;
+
+  if (!AcquireSpinLockOrFail ()) {
+DEBUG ((DEBUG_ERROR, "%a: failed to acquire spinlock\n", __func__));
+return EFI_DEVICE_ERROR;
+  }
+
+  Cmd = mDmaBuffer;
+  ZeroMem (Cmd, sizeof (*Cmd));
+
+  Cmd->BufferHead.BufferSize  = sizeof (*Cmd);
+  Cmd->BufferHead.Response= 0;
+  Cmd->TagHead.TagId  = RPI_MBOX_SET_LDO_REGULATOR;
+  Cmd->TagHead.TagSize= sizeof (Cmd->TagBody);
+  Cmd->TagBody.State  = State;
+
+  Cmd->TagHead.TagValueSize   = 0;
+  Cmd->EndTag = 0;
+
+  Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
+
+  if (EFI_ERROR (Status) ||
+  Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
+DEBUG ((DEBUG_ERROR,
+  "%a: mailbox  transaction error: Status == %r, Response == 0x%x\n",
+  __func__, Status, Cmd->BufferHead.Response));
+  }
+
+  ReleaseSpinLock ();
+
+  return Status;
+}
+
+
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL mRpiFirmwareProtocol = {
   RpiFirmwareSetPowerState,
   RpiFirmwareGetMacAddress,
@@ -1557,7 +1614,8 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL 
mRpiFirmwareProtocol = {
   RpiFirmwareNotifyXhciReset,
   RpiFirmwareGetCurrentClockState,
   RpiFirmwareSetClockState,
-  RpiFirmwareNotifyGpioSetCfg
+  RpiFirmwareNotifyGpioSetCfg,
+  RpiFirmwareSetLdoRegState
 };
 
 /**
diff --git a/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h 
b/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
index 551c2b82e5..f36aaafaf8 100644
--- a/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
+++ b/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
@@ -92,6 +92,7 @@
 #define RPI_MBOX_NOTIFY_REBOOT0x00030048
 #define RPI_MBOX_GET_POE_HAT_VAL  0x00030049
 #define RPI_MBOX_SET_POE_HAT_VAL  0x00030050
+#define RPI_MBOX_SET_LDO_REGULATOR0x00030056
 #define RPI_MBOX_NOTIFY_XHCI_RESET0x00030058
 
 #define RPI_MBOX_SET_CLOCK_STATE  0x00038001
diff --git a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h 
b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
index c48bb6e434..175894e37a 100644
--- a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
+++ b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
@@ -171,6 +171,12 @@ EFI_STATUS
   UINTN State
   );
 
+typedef
+EFI_STATUS
+(EFIAPI *SET_LDO_REGULATOR) (
+  UINTN State
+  );
+
 typedef struct {
   SET_POWER_STATESetPowerState;
   GET_MAC_ADDRESSGetMacAddress;
@@ -197,6 +203,7 @@ typedef struct {
   GET_CLOCK_STATEGetClockState;
   SET_CLOCK_STATESetClockState;
   GPIO_SET_CFG   SetGpioConfig;
+  SET_LDO_REGULATOR  SetLdoRegState;
 } RASPBERRY_PI_FIRMWARE_PROTOCOL;
 
 extern EFI_GUID gRaspberryPiFirmwareProtocolGuid;
-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113553): https://edk2.groups.io/g/devel/message/113553
Mute This Topic: https://groups.io/mt/103653089/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 0/7] RaspberryPi: SPI Variables, again

2024-01-10 Thread Jeremy Linton
There is a 512KB SPI flash EEPROM on the RPi4, which is used to hold
the early boot firmware. Versions of this this firmware which predate
the network recovery have 160-300+KB unused, which is a perfect place
to drop a UEFI variable store.

This code scans the region and makes the decision at runtime if there
is sufficient space available and falls back to updating the SD/USB
firmware image if not. This behavior is now enabled/disabled at
compile time with -DSPI_VARIABLES=1/0

This is a rehash of a previous set I posted from a few years back, and
I'm largely re-posting it because its still useful for people who are
willing to back that firmware down to gain the functionality, as well
as fixing a crash caused by the variable store code garbage collecting
the storage region when it starts to get full

Beyond providing some example SPI programming on the platform, it also
moves I2C/SPI/GPIO devices which are debatably usable on Linux in
ACPI mode into its own SSDT.

Jeremy Linton (7):
  Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
  Platform/RaspberryPi: Add menu item to enable/disable GPIO
  Platform/RaspberryPi: Add constants for controlling SPI
  Platform/RaspberryPi: Add mailbox cmd to control audio amp
  Platform/RaspberryPi: Add SPI/GPIO to memory map
  Platform/RaspberryPi: Allow pin function selection at runtime
  Platform/RaspberryPi: Add SPI flash variable store.

 .../RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl  |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl   | 126 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl  | 159 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  37 +
 .../Drivers/ConfigDxe/ConfigDxe.inf   |   1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|   5 +
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr|  15 +
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c   |  60 +-
 .../Drivers/VarBlockServiceDxe/FvbInfo.c  |   8 +-
 .../VarBlockServiceDxe/VarBlockService.c  | 669 +-
 .../VarBlockServiceDxe/VarBlockService.h  |  10 +
 .../VarBlockServiceDxe/VarBlockServiceDxe.c   |  69 +-
 .../VarBlockServiceDxe/VarBlockServiceDxe.inf |   7 +
 Platform/RaspberryPi/Include/ConfigVars.h |   4 +
 .../Include/IndustryStandard/RpiMbox.h|   1 +
 .../Include/Protocol/RpiFirmware.h|   7 +
 Platform/RaspberryPi/RPi3/RPi3.dsc|   6 +
 Platform/RaspberryPi/RPi4/RPi4.dsc|  12 +-
 Platform/RaspberryPi/RaspberryPi.dec  |   1 +
 .../Include/IndustryStandard/Bcm2836.h|  34 +
 .../Bcm283x/Include/Library/GpioLib.h |   6 +
 .../Bcm283x/Library/GpioLib/GpioLib.c |  16 +-
 23 files changed, 1100 insertions(+), 161 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

-- 
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113549): https://edk2.groups.io/g/devel/message/113549
Mute This Topic: https://groups.io/mt/103653085/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 1/5] Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011

2024-01-10 Thread Jeremy Linton
The rpi's config.txt controls which uart (pl011, or miniuart) is
selected as the console. TFA and edk2 follow its lead, but if the
miniuart is selected as the primary and the machine is booted in ACPI
mode the baud/etc is never configured for the pl011. The linux kernel
won't reconfigure it either as its listed as a "SBSA" uart, so it
simply won't work.

This re-enables BT on the pl011 in ACPI mode, and it somewhat starts
to work again.

Signed-off-by: Jeremy Linton 
---
 .../DualSerialPortLib/DualSerialPortLib.c | 37 +++
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c 
b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
index d2f983bf0a..79545d93d6 100644
--- a/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
+++ b/Platform/RaspberryPi/Library/DualSerialPortLib/DualSerialPortLib.c
@@ -76,6 +76,8 @@ SerialPortInitialize (
   EFI_PARITY_TYPE Parity;
   UINT8   DataBits;
   EFI_STOP_BITS_TYPE  StopBits;
+  RETURN_STATUS   Ret;
+  UINTN   Timeout;

   //
   // First thing we need to do is determine which of PL011 or miniUART is 
selected
@@ -85,23 +87,27 @@ SerialPortInitialize (
 UsePl011UartSet = TRUE;
   }

-  if (UsePl011Uart) {
-BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
+  // always init the pl011 on the pi4, linux expects a SBSA uart to be at 
115200
+  // this means we need to set the baud/etc even if we arn't using it as a 
console
+  if ((UsePl011Uart) || (RPI_MODEL == 4)) {
 ReceiveFifoDepth = 0; // Use default FIFO depth
+BaudRate = FixedPcdGet64 (PcdUartDefaultBaudRate);
 Parity = (EFI_PARITY_TYPE)FixedPcdGet8 (PcdUartDefaultParity);
 DataBits = FixedPcdGet8 (PcdUartDefaultDataBits);
 StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);

-return PL011UartInitializePort (
- PL011_UART_REGISTER_BASE,
- PL011UartClockGetFreq(),
- ,
- ,
- ,
- ,
- 
- );
-  } else {
+Ret = PL011UartInitializePort (
+   PL011_UART_REGISTER_BASE,
+   PL011UartClockGetFreq(),
+   ,
+   ,
+   ,
+   ,
+   
+   );
+  }
+
+  if (!UsePl011Uart) {
 SerialRegisterBase = MINI_UART_REGISTER_BASE;
 Divisor = SerialPortGetDivisor (PcdGet32 (PcdSerialBaudRate));

@@ -127,7 +133,8 @@ SerialPortInitialize (
 // Wait for the serial port to be ready.
 // Verify that both the transmit FIFO and the shift register are empty.
 //
-while ((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY));
+Timeout = 1000;
+while (((SerialPortReadRegister (SerialRegisterBase, R_UART_LSR) & 
(B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) != (B_UART_LSR_TEMT | B_UART_LSR_TXRDY)) 
&& (Timeout--));

 //
 // Configure baud rate
@@ -158,9 +165,9 @@ SerialPortInitialize (
 // Put Modem Control Register(MCR) into its reset state of 0x00.
 //
 SerialPortWriteRegister (SerialRegisterBase, R_UART_MCR, 0x00);
-
-return RETURN_SUCCESS;
+Ret = RETURN_SUCCESS;
   }
+  return Ret;
 }

 /**
--
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113544): https://edk2.groups.io/g/devel/message/113544
Mute This Topic: https://groups.io/mt/103652853/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 5/5] Platform/RaspberryPi: Update PCIe MMIO window for DT

2024-01-10 Thread Jeremy Linton
Since we are updating the DT memory map and telling it how
we have configured the PCIe, there isn't a reason for moving the
MMIO window. In fact this appears to fix OpenBSD+DT as well as
it makes the linux XHCI reset sequence happier.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index dd4fc0a05e..e6942df6a3 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
@@ -375,6 +375,30 @@ SyncPcie (
 return EFI_NOT_FOUND;
   }

+  // move the MMIO window too
+  DmaRanges[0] = cpu_to_fdt32 (0x0200); //non prefech 32-bit
+  DmaRanges[1] = cpu_to_fdt32 (0x); //bus addr @ 0x0f800
+  DmaRanges[2] = cpu_to_fdt32 (0xf800);
+  DmaRanges[3] = cpu_to_fdt32 (0x0006); //cpu addr @ 0x6
+  DmaRanges[4] = cpu_to_fdt32 (0x);
+  DmaRanges[5] = cpu_to_fdt32 (0x);
+  DmaRanges[6] = cpu_to_fdt32 (0x0400); // len = 0x4000 
+
+  DEBUG ((DEBUG_INFO, "%a: Updating PCIe ranges\n",  __func__));
+
+  /*
+   * Match dma-ranges with the EDK2+ACPI setup we are using.  This works
+   * around a failure in Linux and OpenBSD to reset the PCIe/XHCI correctly
+   * when in DT mode.
+   */
+  Retval = fdt_setprop (mFdtImage, Node, "ranges",
+DmaRanges,  sizeof DmaRanges);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to locate PCIe MMIO 'ranges' property 
(%d)\n",
+  __func__, Retval));
+return EFI_NOT_FOUND;
+  }
+
   if (PcdGet32 (PcdXhciReload) != 1) {
 return EFI_SUCCESS;
   }
--
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113548): https://edk2.groups.io/g/devel/message/113548
Mute This Topic: https://groups.io/mt/103652857/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 4/5] Platform/RaspberryPi: Give the user control over the XHCI mailbox

2024-01-10 Thread Jeremy Linton
Its a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets
give users which want to try DT the option of flipping this on/off.

Users that don't want to have to deal with DT, can use ACPI.

Signed-off-by: Jeremy Linton 
---
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 10 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   |  1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|  5 +
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr| 15 +++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c  |  4 
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf|  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc|  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc|  7 +++
 Platform/RaspberryPi/RaspberryPi.dec  |  1 +
 9 files changed, 50 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 3dcf2bac0d..2484787982 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -298,6 +298,16 @@ SetupVariables (
 Status = PcdSet32S (PcdXhciPci, 1);
 ASSERT_EFI_ERROR (Status);
   }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciReload",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdXhciReload, PcdGet32 (PcdXhciReload));
+ASSERT_EFI_ERROR (Status);
+  }
+
 }
   } else {
 /*
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 6f6e8f42ac..475e645537 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -96,6 +96,7 @@
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
   gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate
+  gRaspberryPiTokenSpaceGuid.PcdXhciReload

 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 5ec17072c3..8130638876 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -62,6 +62,11 @@
 #string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
 #string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"

+#string STR_ADVANCED_XHCIRELOAD_PROMPT  #language en-US "DT Reload XHCI 
firmware"
+#string STR_ADVANCED_XHCIRELOAD_HELP#language en-US "OS should reload XHCI 
firmware on reset"
+#string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f668b7a553..f13b70711d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -61,6 +61,11 @@ formset
   name  = XhciPci,
   guid  = CONFIGDXE_FORM_SET_GUID;

+efivarstore ADVANCED_XHCIPCI_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = XhciReload,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -228,6 +233,16 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PCIE), value = 
1, flags = 0;
 endoneof;
   endif;
+
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+oneof varid = XhciReload.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_PROMPT),
+  help= STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_HELP),
+  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_DISABLE), 
value = 0, flags = DEFAULT;
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_RELOAD), 
value = 1, flags = 0;
+endoneof;
+  endif;
 endif;
 #endif
 string varid = AssetTag.AssetTag,
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index cbbc2ad30d..dd4fc0a05e 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+

[edk2-devel] [PATCH 0/5] Platform/RaspberryPi: Various minor fixes

2024-01-10 Thread Jeremy Linton
This includes a change to always initialize the PL011 to the
configured baud (which should be 115200 for the SBSA UART), which
fixes linux's assumption that SBSA UARTs are pre-programmed for
115200. This in turn (re)enables the PL011 when the console is on the
miniuart per the config.txt file.

Also included is another spin with the DT/XHCI reset patch which puts
removal of the DT node that causes linux to reset the XHCI controller,
as well as an additional patch that updates the DT to match the PCIe
MMIO window we have programmed. This cures much of the problem with
the PCIe/XHCI configuration when booted in DT mode on linux.

There is also a few menu visibility/section tweaks to assure ACPI/DT
specific settings show up at the appropriate time.

As well as a minor fix to work around a bogus compiler warning.

Jeremy Linton (5):
  Platform/RaspberryPi/DualSerialPortLib: Always configure the pl011
  Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings
  Platform/RaspberryPi: Cleanup menu visibility
  Platform/RaspberryPi: Give the user control over the XHCI mailbox
  Platform/RaspberryPi: Update PCIe MMIO window for DT

 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 10 +
 .../Drivers/ConfigDxe/ConfigDxe.inf   |  1 +
 .../Drivers/ConfigDxe/ConfigDxeHii.uni|  5 +++
 .../Drivers/ConfigDxe/ConfigDxeHii.vfr| 21 +--
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c  | 28 ++
 .../RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |  1 +
 .../DualSerialPortLib/DualSerialPortLib.c | 37 +++
 Platform/RaspberryPi/RPi3/RPi3.dsc|  6 +++
 Platform/RaspberryPi/RPi4/RPi4.dsc|  7 
 Platform/RaspberryPi/RaspberryPi.dec  |  1 +
 .../Drivers/Net/BcmGenetDxe/GenericPhy.c  |  2 +
 .../Drivers/Net/BcmGenetDxe/SimpleNetwork.c   |  3 ++
 12 files changed, 104 insertions(+), 18 deletions(-)

--
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113543): https://edk2.groups.io/g/devel/message/113543
Mute This Topic: https://groups.io/mt/103652852/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 2/5] Silicon/Broadcom/BcmGenetDxe: Suppress some bogus compiler warnings

2024-01-10 Thread Jeremy Linton
Some recent GCC revisions will throw warnings about values being used
before being initialized. But in the case where the lack of initialization
is the result of the called function returning error status the EFI_ERROR()
macro/error seems to confuse the compiler about the fact that the value
is then never used.

So, while the code appears to be fine, lets just zero the variables
anyway to make the compiler happy.

Signed-off-by: Jeremy Linton 
---
 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c| 2 ++
 Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c
index 9e5d30fafd..2d5f70170e 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/GenericPhy.c
@@ -381,6 +381,8 @@ GenericPhyUpdateConfig (
   BOOLEAN LinkUp;

   Status = GenericPhyGetLinkStatus (Phy);
+  Speed = 0;
+  Duplex = 0;
   LinkUp = EFI_ERROR (Status) ? FALSE : TRUE;

   if (Phy->LinkUp != LinkUp) {
diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c 
b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
index 3b51a86d65..7a7c398b1f 100644
--- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
+++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
@@ -731,6 +731,9 @@ GenetSimpleNetworkReceive (
   UINT8   *Frame;
   UINTN   FrameLength;

+  DescIndex = 0;
+  FrameLength = 0;
+
   if (This == NULL || Buffer == NULL) {
 DEBUG ((DEBUG_ERROR, "%a: Invalid parameter (missing handle or buffer)\n",
   __FUNCTION__));
--
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113545): https://edk2.groups.io/g/devel/message/113545
Mute This Topic: https://groups.io/mt/103652854/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 3/5] Platform/RaspberryPi: Cleanup menu visibility

2024-01-10 Thread Jeremy Linton
Lets allow some of these options to change when the
system is in ACPI+DT mode. Plus the fan temp should
be disabled when ACPI isn't enabled.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index e8bf16312d..f668b7a553 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -196,7 +196,7 @@ formset
 endoneof;

 #if (RPI_MODEL == 4)
-grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   oneof varid = FanOnGpio.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANONGPIO_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANONGPIO_HELP),
@@ -207,7 +207,7 @@ formset
   endoneof;
 endif;

-grayoutif ideqval FanOnGpio.Enabled == 0;
+grayoutif ideqval FanOnGpio.Enabled == 0 OR ideqval 
SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   numeric varid = FanTemp.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANTEMP_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANTEMP_HELP),
@@ -219,7 +219,7 @@ formset
 endif;

 suppressif ideqval XhciPci.Value == 2;
-  grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
 oneof varid = XhciPci.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_XHCIPCI_HELP),
--
2.43.0



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113546): https://edk2.groups.io/g/devel/message/113546
Mute This Topic: https://groups.io/mt/103652855/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

2023-10-31 Thread Jeremy Linton

On 10/31/23 12:37, Neal Gompa via groups.io wrote:

From: Neal Gompa 

Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, the introduction of Platform Recovery in UEFI 2.5 makes it
necessary to signal ReadyToBoot when a Platform Recovery boot loader
runs because otherwise it may lead to the execution of a boot loader
that has similar requirements to a regular one that is not launched
as a Boot Manager option.

This is especially critical to ensuring that the graphical console
is actually usable during platform recovery, as some platforms do
rely on the ConsolePrefDxe driver, which only performs console
initialization after ReadyToBoot is triggered.

This patch fixes that behavior by calling EfiSignalEventReadyToBoot ()
in EfiBootManagerProcessLoadOption () when invoking platform recovery,
which is the function that sets up the platform recovery boot process.

The expected behavior has been clarified in the UEFI 2.10 specification
to explicitly indicate this behavior is required for correct operation.

This is a rebased version of the patch originally written by Pete Batard.


Took me a bit to swap in that whole conversation again, and recheck the 
spec's and code paths, but this all looks fine to me and should allow 
the PFTF build to drop the similar patch from Pete that has been carried 
downstream for the past couple years.


As for testing the previous patch has been in the field for a couple 
years now and i'm not aware of it causing any issues. The additional 
restriction of limiting it to platform recovery logically makes sense, 
and as far as I can see shouldn't cause any problems.


So,

Reviewed-by: Jeremy Linton 


As a PS: I also went to check the ready to boot behavior for OsRecovery 
and realized that apparently none of that support was ever merged? That 
seems a bit of an oversight since its been in the spec for a few years now.





Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2831

Cc: Pete Batard 
Cc: Daniel P. Berrangé 
Cc: Gerd Hoffmann 
Cc: Samer El-Haj-Mahmoud 
Cc: Laszlo Ersek 

Co-authored-by: Pete Batard 
Signed-off-by: Neal Gompa 
---
  .../Library/UefiBootManagerLib/BmLoadOption.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 2087f0b91d..83a2f893e4 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1416,6 +1416,17 @@ EfiBootManagerProcessLoadOption (
  return EFI_SUCCESS;
}
  
+  if (LoadOption->OptionType == LoadOptionTypePlatformRecovery) {

+//
+// Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and 
execute the boot option.
+//
+EfiSignalEventReadyToBoot ();
+//
+// Report Status Code to indicate ReadyToBoot was signaled
+//
+REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+  }
+
//
// Load and start the load option.
//




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110454): https://edk2.groups.io/g/devel/message/110454
Mute This Topic: https://groups.io/mt/102302654/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[STILL CRASHING] Re: [edk2-devel] [PATCH v3 1/1] MdeModulePkg/UsbBusDxe: Rebuild the description table after Reset Device

2022-11-18 Thread Jeremy Linton

Hi,

Dead thread poke, but, its been > 2 years since this problem was pointed 
out.


Multiple patches have been proposed, including one by me:
https://edk2.groups.io/g/devel/message/58193
and the USB/XHCI reset logic continues to be broken enough that a wide 
range of USB issues can result in boot crashes. Those crashes are the 
result of a null pointer in the TrsRing being dereferenced following 
reset. In fact it is 100% reproducible on seemingly any edk2 platform 
with a XHCI controller given the right USB device (like the really 
common JMICRON I pointed out in one of the threads).


I'm not sure this patch is right, because the USB descriptors shouldn't 
be cached over reset, but something has to be done to fix this problem.



Thanks,




On 12/9/20 06:38, Srikumar Subramanian via groups.io wrote:

Hi Jiang,

Is it the responsibility of the reset routine to know what is wrong with the 
device? And on this topic I would like to know your thoughts on another 
alternative which is saving the config in XhcPollPortStatusChange before 
disabling the slot and restoring it after initializing the device slot again. 
My rationale for doing this is that, the reset device state diagram according 
to the specs moves the device from the configured to the default state and does 
not completely remove device information.
In this regard is it safe to assume that meta-data such as descriptors should 
be restored. Since in this case a port reset is triggering a device reset but 
because we disable and later initialize a new slot for an existing device we 
lose its configuration which we assume does not change.

Let me know your thoughts and inputs on this. And if I needed an immediate 
solution I would like to know the better option between the one I am proposing 
right now and the existing suggested solution (which is making a request to the 
device again for the descriptors.)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
index 1754a97..d330f21 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c
@@ -1,5 +1,5 @@
/**

**/
/** @file

@@ -1587,6 +1587,65 @@ XhcMonitorAsyncRequests (
gBS->RestoreTPL (OldTpl);
}

+/**
+    Save the current configuration for the Slot in Host Controller
+
+    @param Xhc                            The XHCI instance
+    @param SlotId                         The Slot ID
+    @param ActiveAlternateSetting         The Alternate interface setting that 
is part of the device context
+    @param ConfDesc                       The Configuration Descriptors of the 
device present in the slot
+    @param DevDesc                        The Device Descriptor of the device 
present in the slot
+**/
+VOID
+XhcSaveConfig(
+  IN USB_XHCI_INSTANCE    *Xhc,
+  IN UINT8                 SlotId,
+  OUT UINT8               **ActiveAlternateSetting,
+  OUT EFI_USB_CONFIG_DESCRIPTOR ***ConfDesc,
+  OUT EFI_USB_DEVICE_DESCRIPTOR *DevDesc
+)
+{
+  UINT8 Index;
+  UINT8 IfIndex;
+  UINT8 NumInterfaces;
+  UINT64 ConfSize;
+  EFI_USB_INTERFACE_DESCRIPTOR *IfDesc;
+
+  *DevDesc = Xhc->UsbDevContext[SlotId].DevDesc;
+
+  if(DevDesc->NumConfigurations==0){
+    return;
+  }
+
+  *ConfDesc = AllocateZeroPool(DevDesc->NumConfigurations * 
sizeof(EFI_USB_CONFIG_DESCRIPTOR*));
+
+  for(Index = 0; Index < DevDesc->NumConfigurations; Index++){
+    NumInterfaces = Xhc->UsbDevContext[SlotId].ConfDesc[Index]->NumInterfaces;
+    IfDesc = (EFI_USB_INTERFACE_DESCRIPTOR 
*)(Xhc->UsbDevContext[SlotId].ConfDesc[Index] + 1);
+
+    // Calculating the size of the configuration descriptor.
+    // This is needed since the interface and enpoint descriptors are nested 
within this.
+    // See USB_CONFIG_DESCRIPTOR, USB_INTERFACE_DESCRIPTOR, 
USB_ENDPOINT_DESCRIPTOR in MdePkg/Include/IndustryStandard/Usb.h
+    // See USB_CONFIG_DESC, USB_INTERFACE_DESC, USB_ENDPOINT_DESC in 
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbDesc.h
+    ConfSize = sizeof(Xhc->UsbDevContext[SlotId].ConfDesc[Index]);
+    ConfSize += (sizeof(EFI_USB_INTERFACE_DESCRIPTOR) * (NumInterfaces));
+    for(IfIndex = 0; IfIndex < NumInterfaces; IfIndex++){
+      ConfSize += IfDesc->NumEndpoints * sizeof(EFI_USB_ENDPOINT_DESCRIPTOR);
+      IfDesc = (USB_INTERFACE_DESCRIPTOR *)((UINTN)IfDesc + IfDesc->Length);
+    }
+
+    *ConfDesc[Index] = AllocateZeroPool(ConfSize);
+    CopyMem (*ConfDesc[Index] ,Xhc->UsbDevContext[SlotId].ConfDesc[Index], 
ConfSize);
+  }
+
+  *ActiveAlternateSetting = 
AllocateZeroPool(Xhc->UsbDevContext[SlotId].ConfDesc[0]->NumInterfaces * 
sizeof(UINT8));
+
+  CopyMem(*ActiveAlternateSetting, 
Xhc->UsbDevContext[SlotId].ActiveAlternateSetting, 
Xhc->UsbDevContext[SlotId].ConfDesc[0]->NumInterfaces * sizeof(UINT8));
+
+}
+
/**
Monitor the port status change. Enable/Disable device slot if there is a device 
attached/detached.

@@ -1613,6 +1672,15 @@ XhcPollPortStatusChange (
UINT8             SlotId;
USB_DEV_ROUTE     RouteChart;

+  

Re: [edk2-devel] [edk2-platforms PATCH v2] Platform/RaspberryPi: fix pci DT node address in SyncPcie()

2022-10-07 Thread Jeremy Linton

Hi,

On 10/6/22 12:46, Adrien Thierry wrote:

To make sure the XHCI controller does not get reset by Linux in DT mode,
we remove its pci parent node from the device tree. However, the pci
node address has been updated in the Raspberry Pi 4 device tree [1] and
no longer matches the one we are trying to remove in SyncPcie(). This
results in the XHCI controller actually being reset by Linux, which
leads to errors during USB initialization:

[3.563963] xhci_hcd :01:00.0: xHCI Host Controller
[3.569538] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 1
[3.577452] xhci_hcd :01:00.0: hcc params 0x002841eb hci version 0x100 
quirks 0x04000890
[3.587725] xhci_hcd :01:00.0: xHCI Host Controller
[3.593115] xhci_hcd :01:00.0: new USB bus registered, assigned bus 
number 2
[3.600693] xhci_hcd :01:00.0: Host supports USB 3.0 SuperSpeed
[3.608106] hub 1-0:1.0: USB hub found
[3.612026] hub 1-0:1.0: 1 port detected
[3.616819] hub 2-0:1.0: USB hub found
[3.620726] hub 2-0:1.0: 4 ports detected
[3.875902] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[4.008123] usb 1-1: device descriptor read/64, error -71
[4.256088] usb 1-1: device descriptor read/64, error -71
[4.495882] usb 1-1: new high-speed USB device number 3 using xhci_hcd
[4.628111] usb 1-1: device descriptor read/64, error -71
[4.872083] usb 1-1: device descriptor read/64, error -71
[5.407888] usb 1-1: new high-speed USB device number 4 using xhci_hcd
[6.023964] xhci_hcd :01:00.0: Setup ERROR: setup address command for 
slot 1.
[6.239977] xhci_hcd :01:00.0: Setup ERROR: setup address command for 
slot 1.

This patch allows matching any address for the pci node, thus working
with both legacy and new device trees.



Thanks a lot for looking into this! This looks fine to me, the only 
thing that poped out was that the uefi checkpatch complained about the 
linux log in the commit message, but I think that should be ok.


so:

Reviewed-by: Jeremy Linton 

and I also did some basic testing on a rpi4's so:

Tested-by: Jeremy Linton 

too.

Thanks again!


[1] https://lore.kernel.org/all/20210831125843.1233488-1-nsaen...@redhat.com/

Fixes: efff29cdcdb7 ("Platform/RaspberryPi: Always use non translating DMA in DT 
mode")
Signed-off-by: Adrien Thierry 
---

v1->v2: Match both pci@1,0 and pci@0,0

I chose to remove the address altogether, since there is only one pci
node for the Raspberry Pi 4 and thus no ambiguity. Let me know if you
prefer explicitly matching pci@1,0 and pci@0,0.

  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index e72d132b18..cbbc2ad30d 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
@@ -388,14 +388,14 @@ SyncPcie (
 * triggering the mailbox by removing the node.
 */
  
-  Node = fdt_path_offset (mFdtImage, "/scb/pcie@7d50/pci@1,0");

+  Node = fdt_path_offset (mFdtImage, "/scb/pcie@7d50/pci");
if (Node < 0) {
  // This can happen on CM4/etc which doesn't have an onboard XHCI
-DEBUG ((DEBUG_INFO, "%a: failed to locate 
/scb/pcie@7d50/pci@1/usb@1\n", __FUNCTION__));
+DEBUG ((DEBUG_INFO, "%a: failed to locate /scb/pcie@7d50/pci\n", 
__FUNCTION__));
} else {
  Retval = fdt_del_node (mFdtImage, Node);
  if (Retval != 0) {
-  DEBUG ((DEBUG_ERROR, "Failed to remove 
/scb/pcie@7d50/pci@1/usb@1\n"));
+  DEBUG ((DEBUG_ERROR, "Failed to remove /scb/pcie@7d50/pci\n"));
return EFI_NOT_FOUND;
  }
}

base-commit: ae75c51f27e21036b6ee021a2d5b9f365f951413




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94813): https://edk2.groups.io/g/devel/message/94813
Mute This Topic: https://groups.io/mt/94163254/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes

2022-10-03 Thread Jeremy Linton

Hi,

On 9/30/22 13:47, Adrien Thierry wrote:

Hi Jeremy,


If you just add the range tweak, does that fix the XHCI config in your setup
too?


I tested applying the range tweak in your patch, unfortunately it doesn't
seem to work on my setup. I'm still getting "usb 1-1: device descriptor > read/64, 
error -71" errors.


That is unfortunate. Which revision/how much RAM? Can you paste the 
before/after kernel/pci output like:


] brcm-pcie fd50.pcie: host bridge /scb/pcie@7d50 ranges:
] brcm-pcie fd50.pcie:   No bus range found for /scb/pcie@7d50, 
using [bus 00-ff]
] brcm-pcie fd50.pcie:  MEM 0x06..0x0603ff -> 
0x00f800
] brcm-pcie fd50.pcie:   IB MEM 0x00..0x00bfff -> 
0x00

] brcm-pcie fd50.pcie: PCI host bridge to bus :00
] pci_bus :00: root bus resource [bus 00-ff]
] pci_bus :00: root bus resource [mem 0x6-0x603ff] (bus 
address [0xf800-0xfbff])


I tested it on a C0 with 8G and a B0 with 4G, and it seems to work on 
both, although the C0 might have been misbehaving a bit (likely 
unrelated). In both cases I swapped in the latest Pi foundation DT 
(https://github.com/raspberrypi/firmware/blob/master/boot/bcm2711-rpi-4-b.dtb) 
which uses the address you suggest, and it still seems to work either 
way (with or without the reset). If we reroll the PFTF firmware it is 
usually with the latest pi foundation DTs.


So the first patch makes sense, but I think it should probably be 
checking both DT property names (pci0,0 and pci1,0) since we probably 
want maximum compatibility with differing DT's the user might swap in, 
and the upstream linux change which changes the node from 1,0 to 0,0 is 
from august of last year, so not old at all..


The second one, I'm less sure about, since the primary thing your 
changing (AFAIK) is whether the XHCI BIOS handoff is being checked, and 
since EDK2 supports the hand-off and Linux doesn't throw the XHCI bios 
failure message I think we actually want to leave that in place. If you 
have debugging turned on, the XHCI/LegacyBios ownership control is the 
message you see during exit boot services that says 
"XhciClearBiosOwnership: called to clear BIOS ownership". I suspect the 
kernel patch is yet another case of "UBOOT and/or the pi foundation 
firmware is broken so we fixed the kernel"


Do you see a difference with/without the second patch?






Here's my SyncPcie function with the range tweak applied [1]

I'm running upstream linux 6.0-rc6 with the downstream device tree
provided in [2]

Thank you,
Adrien

[1] http://pastebin.test.redhat.com/1075875
[2] https://github.com/pftf/RPi4/releases/tag/v1.33





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94688): https://edk2.groups.io/g/devel/message/94688
Mute This Topic: https://groups.io/mt/94002759/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes

2022-09-30 Thread Jeremy Linton

On 9/29/22 14:53, Adrien Thierry wrote:

This patch series does a few fixes in the SyncPcie() function, more
specifically in the logic that deletes the pci node to prevent Linux from
resetting the XHCI controller.


Hmm, that code not being exactly right isn't surprising, I went through 
about a dozen revisions looking for the one that fixed it consistently 
and in the end this version worked with some older kernels (and likely 
dt) but doesn't work with any of the recent ones.


But... I think I found an actual fix a couple months ago while testing 
the DT->SMCCC pci config space code. Which is to update the ranges 
property as well. With that change the firmware can reset the XHCI 
controller in recent Linux's, so there isn't a need to remove the XHCI node.



There is a copy of the patch hiding on my github

https://github.com/jlinton/edk2-platforms/commit/50540bd24f93b633c3597b5dc58c1a1a3b49bf7f#diff-373e67aaa16dd9ac2428d5acc3d73ef218b2ed6d24f3350d5af558cba03cf5adR378

along with a change to update the compatible property to 
pci-host-smc-generic and remove the ranges property which should be 
ignored... :)


If you just add the range tweak, does that fix the XHCI config in your 
setup too?



I really need to start getting many of those old/stale patches cleaned 
up and merged, but its not been a high priority.





Adrien Thierry (2):
   Platform/RaspberryPi: fix pci DT node address in SyncPcie()
   Platform/RaspberryPi: delete usb node instead of pci in SyncPcie()

  Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


base-commit: e55f0527dde48a5f139c1b8f35acc4e6b59dd794




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94572): https://edk2.groups.io/g/devel/message/94572
Mute This Topic: https://groups.io/mt/94002759/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms][PATCH v1 1/7] RaspberryPi: Pipeline: Resolving newly introduced dependency

2022-07-14 Thread Jeremy Linton

Hi,

On 7/8/22 16:02, Kun Qin wrote:

The new changes in SecureBootVariableLib brought in a new dependency
of PlatformPKProtectionLib.

This change added the new library instance from SecurityPkg to resolve
RaspberryPi platforms build.


This applies cleanly, and fixes the build break when the rpis are built 
against the latest edk2 branch.


Thanks,

Reviewed-by: Jeremy Linton 




Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Jeremy Linton 

Signed-off-by: Kun Qin 
---
  Platform/RaspberryPi/RPi3/RPi3.dsc | 1 +
  Platform/RaspberryPi/RPi4/RPi4.dsc | 1 +
  2 files changed, 2 insertions(+)

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 0eed03c097f8..4e7377a00036 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -169,6 +169,7 @@ [LibraryClasses.common]
PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf

SecureBootVariableLib|SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.inf

SecureBootVariableProvisionLib|SecurityPkg/Library/SecureBootVariableProvisionLib/SecureBootVariableProvisionLib.inf
+  
PlatformPKProtectionLib|SecurityPkg/Library/PlatformPKProtectionLibVarPolicy/PlatformPKProtectionLibVarPolicy.inf
  !else

TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf

AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index eabddd7382cf..8ba0ca61851e 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -166,6 +166,7 @@ [LibraryClasses.common]
AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf

SecureBootVariableLib|SecurityPkg/Library/SecureBootVariableLib/SecureBootVariableLib.inf

SecureBootVariableProvisionLib|SecurityPkg/Library/SecureBootVariableProvisionLib/SecureBootVariableProvisionLib.inf
+  
PlatformPKProtectionLib|SecurityPkg/Library/PlatformPKProtectionLibVarPolicy/PlatformPKProtectionLibVarPolicy.inf
  
# re-use the UserPhysicalPresent() dummy implementation from the ovmf tree

PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.inf




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91353): https://edk2.groups.io/g/devel/message/91353
Mute This Topic: https://groups.io/mt/92260958/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH edk2-platforms v2 06/11] Platform/RaspberryPi: Update for IORT revision macro renaming

2022-07-07 Thread Jeremy Linton

Hi,

On 7/6/22 05:39, Sami Mujawar wrote:

The IORT Specification E.d updates the IORT table revision to 5. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.

Therefore, update the usage of EFI_ACPI_IO_REMAPPING_TABLE_REVISION
macro in the IORT table for RaspberryPi platform to
EFI_ACPI_IO_REMAPPING_TABLE_REV0.

Signed-off-by: Sami Mujawar 
---
  Platform/RaspberryPi/AcpiTables/Iort.aslc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc 
b/Platform/RaspberryPi/AcpiTables/Iort.aslc
index 
810307ae376f7d24790775f499daa09e3137fe6c..3ca5471081f2b43e624b35fc7b9bda856b15daa9
 100644
--- a/Platform/RaspberryPi/AcpiTables/Iort.aslc
+++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
@@ -28,7 +28,7 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
{
  ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,
   RPI4_IO_REMAPPING_STRUCTURE,
- EFI_ACPI_IO_REMAPPING_TABLE_REVISION),
+ EFI_ACPI_IO_REMAPPING_TABLE_REV0),
  3,  // NumNodes
  sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE),   // NodeOffset
  0   // Reserved



So, this looks fine to me.

Thanks,

Reviewed-by: Jeremy Linton 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91140): https://edk2.groups.io/g/devel/message/91140
Mute This Topic: https://groups.io/mt/92203687/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms][PATCH v1 06/10] RaspberryPi: Add VariableFlashInfoLib

2022-04-22 Thread Jeremy Linton

Hi,

On 4/20/22 15:44, mikub...@linux.microsoft.com wrote:

From: Michael Kubacki 

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479

Adds an instance for the library class VariableFlashInfoLib that
was recently introduced in MdeModulePkg. This change is made to
allow the new variable driver to build that has a dependency on
this library class and does not require any further platform
changes.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Jeremy Linton 
Signed-off-by: Michael Kubacki 
---
  Platform/RaspberryPi/RPi3/RPi3.dsc | 1 +
  Platform/RaspberryPi/RPi4/RPi4.dsc | 1 +
  2 files changed, 2 insertions(+)

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 6dc48dc23302..0eed03c097f8 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -174,6 +174,7 @@ [LibraryClasses.common]

AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
  !endif
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf

VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf

VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
GpioLib|Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.inf
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index a9c0c36bb12b..eabddd7382cf 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -174,6 +174,7 @@ [LibraryClasses.common]

AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
  !endif
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+  
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf

VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf

VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
GpioLib|Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.inf


I applied both this and the other required set, built and booted them, 
and the variable store appears to continue behaving as before (both 
with/without my SPI flash patches).


And this looks fairly trivial, I'm not sure why its not just picked up 
as part of one of the other variable store related .inf's but 


So for this patch:

Tested-by: Jeremy Linton 
Reviewed-by: Jeremy Linton 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89234): https://edk2.groups.io/g/devel/message/89234
Mute This Topic: https://groups.io/mt/90592924/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Add 'clock-frequency' property for miniuart

2022-01-31 Thread Jeremy Linton

On 1/31/22 11:36, Ard Biesheuvel wrote:

On Mon, 31 Jan 2022 at 17:13, Jeremy Linton  wrote:


Hi,

On 1/28/22 09:38, Adrien Thierry via groups.io wrote:

Describe the miniuart clock frequency in a _DSD property, so that it can
be read from the Linux driver.

The miniuart clock frequency is the core clock frequency on the
Raspberry Pi. It can be modified by the user using the 'core_freq'
property in the config.txt file. So, we fetch it from the underlying
Raspberry Pi firmware.


Sorry about the delay, I've been out a bit.

So, this all looks good to me, and it passes the patch checker, the
trick now will be landing the linux patch.


Thanks,

Reviewed-by: Jeremy Linton 



Thanks. Could this be resent without whitespace damage please?
Also, a link the to Linux patch would be helpful.


Hmm, I've had that problem a couple times too with these postings, 
although it usually appeared to be something groups.io was doing because 
direct cc's to myself were correct. I've got a little script to remove 
the double lines, which is what I ran this through before git am'ing it.











Signed-off-by: Adrien Thierry 
---
   Platform/RaspberryPi/AcpiTables/Uart.asl   | 14 ++
   Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  9 +
   .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
   Platform/RaspberryPi/RPi3/RPi3.dsc |  5 +
   Platform/RaspberryPi/RPi4/RPi4.dsc |  5 +
   Platform/RaspberryPi/RaspberryPi.dec   |  1 +
   6 files changed, 35 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/Uart.asl 
b/Platform/RaspberryPi/AcpiTables/Uart.asl
index 974f06d3bc..ef5165be98 100644
--- a/Platform/RaspberryPi/AcpiTables/Uart.asl
+++ b/Platform/RaspberryPi/AcpiTables/Uart.asl
@@ -77,6 +77,20 @@ Device (URTM)
   MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_MINI_UART_OFFSET)

   Return (^RBUF)

 }

+

+  //

+  // Mini Uart Clock Rate will be dynamically updated during boot

+  // 0x4D 0x55 0x43 0x52 0xC 0x100 (Value must be > 16777215)

+  //

+  Name (MUCR, 0x100)

+

+  Name (_DSD, Package ()

+  {

+ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package ()

+{

+  Package (2) { "clock-frequency", MUCR },

+}

+  })

   }



   //

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 415d99fadb..3dcf2bac0d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -44,6 +44,7 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
   STATIC UINT32 mModelFamily = 0;

   STATIC UINT32 mModelInstalledMB = 0;

   STATIC UINT32 mModelRevision = 0;

+STATIC UINT32 mCoreClockRate = 0;



   STATIC EFI_MAC_ADDRESS  mMacAddress;



@@ -798,6 +799,7 @@ STATIC CONST AML_NAME_OP_REPLACE SsdtEmmcNameOpReplace[] = {


   STATIC CONST AML_NAME_OP_REPLACE DsdtNameOpReplace[] = {

 { "URIU", PcdToken (PcdUartInUse) },

+  { "MUCR", PcdToken (PcdMiniUartClockRate) },

 { }

   };



@@ -944,6 +946,13 @@ ConfigInitialize (
   DEBUG ((DEBUG_INFO, "Current Raspberry Pi revision %x\n", 
mModelRevision));

 }



+  Status = mFwProtocol->GetClockRate (RPI_MBOX_CLOCK_RATE_CORE, 
);

+  if (Status != EFI_SUCCESS) {

+DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi core clock rate: 
%r\n", Status));

+  } else {

+PcdSet32S (PcdMiniUartClockRate, mCoreClockRate);

+  }

+

 Status = SetupVariables ();

 if (Status != EFI_SUCCESS) {

   DEBUG ((DEBUG_ERROR, "Couldn't not setup NV vars: %r\n", Status));

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e6e22ad82e..6f6e8f42ac 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -95,6 +95,7 @@
 gRaspberryPiTokenSpaceGuid.PcdFanTemp

 gRaspberryPiTokenSpaceGuid.PcdUartInUse

 gRaspberryPiTokenSpaceGuid.PcdXhciPci

+  gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate



   [Depex]

 gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 6ab5d1ae6d..6dc48dc233 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -561,6 +561,11 @@
 #

 gRaspberryPiTokenSpaceGuid.PcdUartInUse|1



+  #

+  # Mini-UART clock rate

+  #

+  gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate|25000

+

   


   #

   # Components Section - list of all EDK II Modules needed by this Platform

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 44ed60ab2f..a9c0c36bb1 100644
--- a/Platform/Raspberr

Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Add 'clock-frequency' property for miniuart

2022-01-31 Thread Jeremy Linton

Hi,

On 1/28/22 09:38, Adrien Thierry via groups.io wrote:

Describe the miniuart clock frequency in a _DSD property, so that it can
be read from the Linux driver.

The miniuart clock frequency is the core clock frequency on the
Raspberry Pi. It can be modified by the user using the 'core_freq'
property in the config.txt file. So, we fetch it from the underlying
Raspberry Pi firmware.


Sorry about the delay, I've been out a bit.

So, this all looks good to me, and it passes the patch checker, the 
trick now will be landing the linux patch.



Thanks,

Reviewed-by: Jeremy Linton 





Signed-off-by: Adrien Thierry 
---
  Platform/RaspberryPi/AcpiTables/Uart.asl   | 14 ++
  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  9 +
  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
  Platform/RaspberryPi/RPi3/RPi3.dsc |  5 +
  Platform/RaspberryPi/RPi4/RPi4.dsc |  5 +
  Platform/RaspberryPi/RaspberryPi.dec   |  1 +
  6 files changed, 35 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/Uart.asl 
b/Platform/RaspberryPi/AcpiTables/Uart.asl
index 974f06d3bc..ef5165be98 100644
--- a/Platform/RaspberryPi/AcpiTables/Uart.asl
+++ b/Platform/RaspberryPi/AcpiTables/Uart.asl
@@ -77,6 +77,20 @@ Device (URTM)
  MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_MINI_UART_OFFSET)

  Return (^RBUF)

}

+

+  //

+  // Mini Uart Clock Rate will be dynamically updated during boot

+  // 0x4D 0x55 0x43 0x52 0xC 0x100 (Value must be > 16777215)

+  //

+  Name (MUCR, 0x100)

+

+  Name (_DSD, Package ()

+  {

+ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package ()

+{

+  Package (2) { "clock-frequency", MUCR },

+}

+  })

  }

  


  //

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 415d99fadb..3dcf2bac0d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -44,6 +44,7 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
  STATIC UINT32 mModelFamily = 0;

  STATIC UINT32 mModelInstalledMB = 0;

  STATIC UINT32 mModelRevision = 0;

+STATIC UINT32 mCoreClockRate = 0;

  


  STATIC EFI_MAC_ADDRESS  mMacAddress;

  


@@ -798,6 +799,7 @@ STATIC CONST AML_NAME_OP_REPLACE SsdtEmmcNameOpReplace[] = {
  


  STATIC CONST AML_NAME_OP_REPLACE DsdtNameOpReplace[] = {

{ "URIU", PcdToken (PcdUartInUse) },

+  { "MUCR", PcdToken (PcdMiniUartClockRate) },

{ }

  };

  


@@ -944,6 +946,13 @@ ConfigInitialize (
  DEBUG ((DEBUG_INFO, "Current Raspberry Pi revision %x\n", 
mModelRevision));

}

  


+  Status = mFwProtocol->GetClockRate (RPI_MBOX_CLOCK_RATE_CORE, 
);

+  if (Status != EFI_SUCCESS) {

+DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi core clock rate: 
%r\n", Status));

+  } else {

+PcdSet32S (PcdMiniUartClockRate, mCoreClockRate);

+  }

+

Status = SetupVariables ();

if (Status != EFI_SUCCESS) {

  DEBUG ((DEBUG_ERROR, "Couldn't not setup NV vars: %r\n", Status));

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e6e22ad82e..6f6e8f42ac 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -95,6 +95,7 @@
gRaspberryPiTokenSpaceGuid.PcdFanTemp

gRaspberryPiTokenSpaceGuid.PcdUartInUse

gRaspberryPiTokenSpaceGuid.PcdXhciPci

+  gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate

  


  [Depex]

gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 6ab5d1ae6d..6dc48dc233 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -561,6 +561,11 @@
#

gRaspberryPiTokenSpaceGuid.PcdUartInUse|1

  


+  #

+  # Mini-UART clock rate

+  #

+  gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate|25000

+

  


  #

  # Components Section - list of all EDK II Modules needed by this Platform

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 44ed60ab2f..a9c0c36bb1 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -580,6 +580,11 @@
#

gRaspberryPiTokenSpaceGuid.PcdUartInUse|0

  


+  #

+  # Mini-UART clock rate

+  #

+  gRaspberryPiTokenSpaceGuid.PcdMiniUartClockRate|5

+

  


  #

  # Components Section - list of all EDK II Modules needed by this Platform

diff --git a/Platform/RaspberryPi/RaspberryPi.dec 
b/Platform/RaspberryPi/RaspberryPi.dec
index 797be59274..17b6061a05 

[edk2-devel] [PATCH V2 10/10] Platform/RaspberryPi: Update RPi4 Readme

2022-01-01 Thread Jeremy Linton
Replace the paragraph about NVRAM/UEFI variables, with
something that explains the situation a bit better.

Update the UEFI settings table.

Tweak the DT overlay list, and note support for
CM4 and RPi400.

Update the missing block to describe some higher level
goals and point users at the github issues page.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/RPi4/Readme.md | 63 +++--
 1 file changed, 53 insertions(+), 10 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/Readme.md 
b/Platform/RaspberryPi/RPi4/Readme.md
index 80899f4ca4..38ae0372fb 100644
--- a/Platform/RaspberryPi/RPi4/Readme.md
+++ b/Platform/RaspberryPi/RPi4/Readme.md
@@ -16,6 +16,8 @@ Raspberry Pi is a trademark of the [Raspberry Pi 
Foundation](https://www.raspber
 
 The RPi4 target supports Pi revisions based on the BCM2711 SoC:
 - Raspberry Pi 4B
+- Raspberry Compute Module 4
+- Raspberry Pi 400
 
 Please see the RPi3 target for the BCM2837-based variants, such as the 
Raspberry
 Pi 3B.
@@ -44,10 +46,11 @@ Build instructions from the top level edk2-platforms 
Readme.md apply.
 1. Format a uSD card as FAT16 or FAT32
 2. Copy the generated `RPI_EFI.fd` firmware onto the partition
 3. Download and copy the following files from 
https://github.com/raspberrypi/firmware/tree/master/boot
-  - `bcm2711-rpi-4-b.dtb`
+  - `bcm2711-rpi-4-b.dtb`, `bcm2711-rpi-cm4.dtb`, or `bcm2711-rpi-400.dtb`
   - `fixup4.dat`
   - `start4.elf`
   - `overlays/miniuart-bt.dbto` or `overlays/disable-bt.dtbo` (Optional)
+  - `overlays/upstream-pi4.dtbo` (Optional)
 4. Create a `config.txt` with the following content:
 ```
 arm_64bit=1
@@ -62,7 +65,12 @@ Build instructions from the top level edk2-platforms 
Readme.md apply.
 ```
 dtoverlay=miniuart-bt
 ```
-Note: doing so requires `miniuart-bt.dbto` to have been copied into an 
`overlays/`
+Additionally, if you want to use linux in DT mode
+```
+dtoverlay=upstream-pi4
+```
+
+Note: doing so requires `miniuart-bt.dbto` or `upstream-pi4.dtbo` to have 
been copied into an `overlays/`
 directory on the uSD card. Alternatively, you may use `disable-bt` instead 
of
 `miniuart-bt` if you don't require Bluetooth.
 5. Insert the uSD card and power up the Pi.
@@ -84,6 +92,8 @@ By default, UEFI will use the device tree loaded by the 
VideoCore firmware. This
 depends on the model/variant, and relies on the presence on specific files on 
your boot media.
 E.g.:
  - `bcm2711-rpi-4-b.dtb` (for Pi 4B)
+ - `bcm2711-rpi-cm4.dtb` (for CM4)
+ - `bcm2711-rpi-400.dtb` (for Pi 400)
 
 You can override the DTB and provide a custom one. Copy the relevant `.dtb` 
into the root of
 the SD or USB, and then edit your `config.txt` so that it looks like:
@@ -110,11 +120,36 @@ Note, that the ultimate contents of `/chosen/bootargs` 
are a combination of seve
 
 ## NVRAM
 
-The Raspberry Pi has no NVRAM.
-
-NVRAM is emulated, with the non-volatile store backed by the UEFI image 
itself. This
-means that any changes made in UEFI proper are persisted, but changes made 
from within
-an Operating System aren't.
+The Raspberry Pi doesn't have NVRAM dedicated for UEFI.
+
+While UEFI variables and associated functions will appear to work correctly,
+changes made while the OS is active won't persist over reboot except when
+three conditions are true. Those conditions are:
+- The OS must be running in ACPI mode.
+- The GPIO controller is not exported to the OS.
+- There must be sufficient free space on the SPI flash.
+
+In explanation, there are two different methods used to persist firmware
+configurations. The firmware first attempts to find 128K of free space on the
+SPI flash utilized by the SoC for early boot. If that fails, updates are
+written directly to the RPI_EFI.fd image, but only when two conditions are
+true. Those conditions are:
+- The OS is not yet booted.
+- The RPI_EFI.fd image is stored on media that the firmware can rewrite.
+
+The SPI is generally a better choice, but it only works if the firmware
+controls the GPIO pin muxing (since it shares pins with the PWM Audio) and the
+associated SPI controller while the OS is running. That is where the DT and
+GPIO restrictions come in.
+
+Finally, since the variables store utilizes free space on an SPI flash device
+reserved for early boot/low-level firmware functions, future versions of the
+RPi foundation firmware may consume more of the available free space. The SPI
+flash may be upgraded/downgraded using the official
+[RPi imager](https://github.com/raspberrypi/rpi-imager) update flash tool. That
+tool writes an SD disk image that, when placed in the RPi, will erase and
+reprogram the entire SPI flash, thereby wiping out the UEFI variable store in
+the process.
 
 ## RTC
 
@@ -141,9 +176,12 @@ all functionality may be available.
 
 ## Missing Functionality
 
-- Network booting via onboard NIC.
-- SPCR hardcodes type to PL011, and thus will not expose correct
-  (miniUART) UART if DT overlays

[edk2-devel] [PATCH V2 08/10] Platform/RaspberryPi: Allow pin function selection at runtime

2022-01-01 Thread Jeremy Linton
Update GpioLib slightly so that we can change the GPIO pin
muxing at runtime. For the moment only the GpioPinFuncGet/Set()
routines are used at runtime, and only by the Variable service.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h |  6 ++
 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c | 16 ++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
index 1f7d2204e0..79765be4fb 100644
--- a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -45,4 +45,10 @@ GpioSetPull (
   IN  UINTN   Pud
 );
 
+VOID
+GpioSetupRuntime (
+  VOID
+);
+
+
 #endif /* __GPIO_LIB__ */
diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
index eaf53e5369..fc1f928e6b 100644
--- a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -15,10 +15,22 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+
+STATIC EFI_PHYSICAL_ADDRESS GpioGfpSel0 = GPIO_GPFSEL0;
+
+VOID
+GpioSetupRuntime (
+  VOID
+  )
+{
+  EfiConvertPointer (0x0, (VOID**));
+}
+
 STATIC
 VOID
 GpioFSELModify (
@@ -30,7 +42,7 @@ GpioFSELModify (
   UINT32 Val;
   EFI_PHYSICAL_ADDRESS Reg;
 
-  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+  Reg = RegIndex * sizeof (UINT32) + GpioGfpSel0;
 
   ASSERT (Reg <= GPIO_GPFSEL5);
   ASSERT ((~ModifyMask & FunctionMask) == 0);
@@ -77,7 +89,7 @@ GpioPinFuncGet (
 
   RegIndex = Pin / 10;
   SelIndex = Pin % 10;
-  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+  Reg = RegIndex * sizeof (UINT32) + GpioGfpSel0;
 
   Val = MmioRead32 (Reg);
   Val >>= SelIndex * GPIO_FSEL_BITS_PER_PIN;
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85256): https://edk2.groups.io/g/devel/message/85256
Mute This Topic: https://groups.io/mt/88087670/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH V2 09/10] Platform/RaspberryPi: Add SPI flash variable store.

2022-01-01 Thread Jeremy Linton
The RPi4 has a 512KB SPI flash, which depending on RPi
and firmware revision has 300-180K free. We can use this
storage to persist variables when the OS is running or
over firmware upgrades. The problem is that the SPI is pin
mux'ed with the PWM audio, so we want to leave the PWM
configured for OS use. And of course there is the problem
of sharing the GPIO block with OS's that are aware of it.
Hence a previous patch set which moves the GPIO and some of
the low level i2c/etc devices into its own SSDT, and
disables them by default.

This patch, adds a few SPI access functions directly to
the variable store rather than creating another runtime
service since the early boot ordering is critical. These
functions are of the form ReadSpi(), WriteSpi(),
DisableSpiWp(), etc all with Spi in the name. On top of that
a few "Flash" routines are created which provide high level
functions for reading/writing and walking the portion of the
SPI flash we use to clone the variable store region.
Importantly WalkFlashVolume() walks the entire SPI flash
region, which has a simple header structure containing
filename+len for each region of the flash, to return how
much of the capacity is being utilized by the existing
bootloader/etc firmware.

So, if this is a RPi4, and there is sufficient space, and
that space doesn't have a valid varstore header we erase
it and flush the RPI's varstore region to the SPI. Then
we note its starting offset in mFvInstance->FlashOffset.
>From then on, writes to the EFI_FW_VOL_BLOCK_DEVICE are
written to both the RAM copy as well as the SPI flash. If
the empty region has a valid header we read the entire
region overtop of the one being passed as part of the RPi's
BL33, and continue as above.

At ready to boot we re-enable the LDO, and then during the
dump vars check, we check for DT or the GPIO being enabled
and disable the runtime SPI updates because we can't be sure
of what the OS might be doing with the GPIO. The dual ACPI
and DT mode, leaves it enabled (if GPIO is disabled) so
care should be taken.

Now, one of the problems here is that with the LDO enabled
any SPI accesses can be heard over the speakers as pops,
buzzes, or scratchy tones. This is happening even without
this patch because TFA and/or the rpi low level firmware
doesn't itself assure the LDO is disabled during resets, so
the early SoC startup is quite noisy. We add to this, but
alongside that a couple fairly trivial TFA patchs, to mute
it before reset, and again assure its off before releasing
to us solve a large part of this problem. That said, this
can now happen during runtime as well. Generally the OS's
aren't doing a lot of variable updates, but when they do
its generally barely noticable clicks since we aren't going
through the long process of muting/unmuting the LDO which
itself causes a pop.

So, this patch fixes a whole bunch of bugs on github that
exist because the variable store isn't persisted. It also
fixes a rather large bug in the existing variable store
code caused by the FaultTolerantWriteDxe erasing the entire
variable store region when it garbage collects during startup.
That latter bug is the result of FvbGetLbaAddress reading
recently erased data from the VolumeHeader before its been
recreated, and results in random UEFI crashes.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 .../Drivers/VarBlockServiceDxe/FvbInfo.c   |   8 +-
 .../Drivers/VarBlockServiceDxe/VarBlockService.c   | 650 -
 .../Drivers/VarBlockServiceDxe/VarBlockService.h   |  10 +
 .../VarBlockServiceDxe/VarBlockServiceDxe.c|  38 +-
 .../VarBlockServiceDxe/VarBlockServiceDxe.inf  |   6 +
 5 files changed, 690 insertions(+), 22 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
index 0e0c108dba..ee18f327e6 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
@@ -11,12 +11,7 @@
 #include 
 #include 
 #include 
-
-typedef struct {
-  UINT64  FvLength;
-  EFI_FIRMWARE_VOLUME_HEADER  FvbInfo;
-  EFI_FV_BLOCK_MAP_ENTRY  End[1];
-} EFI_FVB_MEDIA_INFO;
+#include "VarBlockService.h"
 
 EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   //
@@ -38,6 +33,7 @@ EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   FixedPcdGet32 (PcdNvStorageEventLogSize),
   EFI_FVH_SIGNATURE,
   EFI_FVB2_MEMORY_MAPPED |
+EFI_FVB2_STICKY_WRITE |
 EFI_FVB2_READ_ENABLED_CAP |
 EFI_FVB2_READ_STATUS |
 EFI_FVB2_WRITE_ENABLED_CAP |
diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
index 572309439a..0cf204738f 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlo

[edk2-devel] [PATCH V2 06/10] Platform/RaspberryPi: Add mailbox cmd to control audio amp

2022-01-01 Thread Jeremy Linton
The lower level firmware can enable/disable a LDO audio
amp, which allows us to mute/unmute audio output while
the firmware is running.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 60 +-
 .../RaspberryPi/Include/IndustryStandard/RpiMbox.h |  1 +
 .../RaspberryPi/Include/Protocol/RpiFirmware.h |  7 +++
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index 4edec0ad04..dca43d78a6 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -1532,6 +1532,63 @@ RpiFirmwareNotifyGpioSetCfg (
   return Status;
 }
 
+#pragma pack()
+typedef struct {
+  UINT32   State;
+} RPI_FW_SET_LDO_REG_TAG;
+
+typedef struct {
+  RPI_FW_BUFFER_HEAD   BufferHead;
+  RPI_FW_TAG_HEAD  TagHead;
+  RPI_FW_SET_LDO_REG_TAG   TagBody;
+  UINT32   EndTag;
+} RPI_FW_SET_LDO_REG_CMD;
+#pragma pack()
+
+
+STATIC
+EFI_STATUS
+EFIAPI
+RpiFirmwareSetLdoRegState (
+  IN UINTN State
+  )
+{
+  RPI_FW_SET_LDO_REG_CMD   *Cmd;
+  EFI_STATUS   Status;
+  UINT32   Result;
+
+  if (!AcquireSpinLockOrFail ()) {
+DEBUG ((DEBUG_ERROR, "%a: failed to acquire spinlock\n", __FUNCTION__));
+return EFI_DEVICE_ERROR;
+  }
+
+  Cmd = mDmaBuffer;
+  ZeroMem (Cmd, sizeof (*Cmd));
+
+  Cmd->BufferHead.BufferSize  = sizeof (*Cmd);
+  Cmd->BufferHead.Response= 0;
+  Cmd->TagHead.TagId  = RPI_MBOX_SET_LDO_REGULATOR;
+  Cmd->TagHead.TagSize= sizeof (Cmd->TagBody);
+  Cmd->TagBody.State  = State;
+
+  Cmd->TagHead.TagValueSize   = 0;
+  Cmd->EndTag = 0;
+
+  Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
+
+  if (EFI_ERROR (Status) ||
+  Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
+DEBUG ((DEBUG_ERROR,
+  "%a: mailbox  transaction error: Status == %r, Response == 0x%x\n",
+  __FUNCTION__, Status, Cmd->BufferHead.Response));
+  }
+
+  ReleaseSpinLock ();
+
+  return Status;
+}
+
+
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL mRpiFirmwareProtocol = {
   RpiFirmwareSetPowerState,
   RpiFirmwareGetMacAddress,
@@ -1557,7 +1614,8 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL 
mRpiFirmwareProtocol = {
   RpiFirmwareNotifyXhciReset,
   RpiFirmwareGetCurrentClockState,
   RpiFirmwareSetClockState,
-  RpiFirmwareNotifyGpioSetCfg
+  RpiFirmwareNotifyGpioSetCfg,
+  RpiFirmwareSetLdoRegState
 };
 
 /**
diff --git a/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h 
b/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
index 551c2b82e5..f36aaafaf8 100644
--- a/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
+++ b/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
@@ -92,6 +92,7 @@
 #define RPI_MBOX_NOTIFY_REBOOT0x00030048
 #define RPI_MBOX_GET_POE_HAT_VAL  0x00030049
 #define RPI_MBOX_SET_POE_HAT_VAL  0x00030050
+#define RPI_MBOX_SET_LDO_REGULATOR0x00030056
 #define RPI_MBOX_NOTIFY_XHCI_RESET0x00030058
 
 #define RPI_MBOX_SET_CLOCK_STATE  0x00038001
diff --git a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h 
b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
index c48bb6e434..175894e37a 100644
--- a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
+++ b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
@@ -171,6 +171,12 @@ EFI_STATUS
   UINTN State
   );
 
+typedef
+EFI_STATUS
+(EFIAPI *SET_LDO_REGULATOR) (
+  UINTN State
+  );
+
 typedef struct {
   SET_POWER_STATESetPowerState;
   GET_MAC_ADDRESSGetMacAddress;
@@ -197,6 +203,7 @@ typedef struct {
   GET_CLOCK_STATEGetClockState;
   SET_CLOCK_STATESetClockState;
   GPIO_SET_CFG   SetGpioConfig;
+  SET_LDO_REGULATOR  SetLdoRegState;
 } RASPBERRY_PI_FIRMWARE_PROTOCOL;
 
 extern EFI_GUID gRaspberryPiFirmwareProtocolGuid;
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85254): https://edk2.groups.io/g/devel/message/85254
Mute This Topic: https://groups.io/mt/88087668/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH V2 07/10] Platform/RaspberryPi: Add SPI/GPIO to memory map

2022-01-01 Thread Jeremy Linton
A large reason for using the SPI flash on this platform is that
it can be updated without OS interference at rutime. In order for
that to happen we need both the SPI, as well as the GPIO
which is used to change the pinmux from the PWM device to SPI added
to the UEFI memory map as being used by the runtime service.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index de7eb769ea..b0db3312c5 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -503,6 +503,22 @@ ApplyVariables (
 DEBUG ((DEBUG_INFO, "Current CPU speed is %u MHz\n", Rate / FREQ_1_MHZ));
   }
 
+  if (mModelFamily == 4) {
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
BCM2836_SPI0_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (BCM2836_SPI0_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
GPIO_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (GPIO_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
+ASSERT_EFI_ERROR (Status);
+  }
+
   if (mModelFamily >= 4 && PcdGet32 (PcdRamMoreThan3GB) != 0 &&
   PcdGet32 (PcdRamLimitTo3GB) == 0) {
 UINT64 SystemMemorySize;
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85255): https://edk2.groups.io/g/devel/message/85255
Mute This Topic: https://groups.io/mt/88087669/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH V2 03/10] Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT

2022-01-01 Thread Jeremy Linton
The UEFI firmware uses the GPIO port for the fan and
real soon now the runtime SPI variable store. As such
we need to be able to either isolate those devices from
the OS or we risk clashing with OS's that reconfigure
the GPIO pins. Ideally we would just rip this out
and use _DSM() or just individual device power
on/off methods to adjust the GPIO pins when needed.

For now, lets leave it since windows at least knows
about it. In the future we will decide whether the
firmware is controlling something (SPI!) based on
whether the user has enabled the GPIO block.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 126 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl   | 159 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   6 +
 5 files changed, 166 insertions(+), 133 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index da2a6db85f..3894d00565 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -40,6 +40,7 @@
   SsdtThermal.asl
   Xhci.asl
   Pci.asl
+  SsdtGpio.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index b594d50bdf..08acc81d57 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -21,13 +21,6 @@
 
 #include "AcpiTables.h"
 
-#define BCM_ALT0 0x4
-#define BCM_ALT1 0x5
-#define BCM_ALT2 0x6
-#define BCM_ALT3 0x7
-#define BCM_ALT4 0x3
-#define BCM_ALT5 0x2
-
 //
 // The ASL compiler does not support argument arithmetic in functions
 // like QWordMemory (). So we need to instantiate dummy qword regions
diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl 
b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
index 9750dc25c0..3399f0fc9a 100644
--- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
+++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
@@ -203,56 +203,6 @@ Device (VCSM)
   }
 }
 
-// Description: GPIO
-Device (GPI0)
-{
-  Name (_HID, "BCM2845")
-  Name (_CID, "BCM2845")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, GPIO_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared)
-{
-  BCM2386_GPIO_INTERRUPT0, BCM2386_GPIO_INTERRUPT1,
-  BCM2386_GPIO_INTERRUPT2, BCM2386_GPIO_INTERRUPT3
-}
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, GPIO_OFFSET)
-Return (^RBUF)
-  }
-}
-
-// Description: I2C
-Device (I2C1)
-{
-  Name (_HID, "BCM2841")
-  Name (_CID, "BCM2841")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_I2C1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_I2C1_INTERRUPT }
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 2, 3 }
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_I2C1_OFFSET)
-Return (^RBUF)
-  }
-}
 
 // I2C2 is the HDMI DDC connection
 Device (I2C2)
@@ -278,81 +228,6 @@ Device (I2C2)
   }
 }
 
-// SPI
-Device (SPI0)
-{
-  Name (_HID, "BCM2838")
-  Name (_CID, "BCM2838")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI0_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_SPI0_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 9, 10, 11 } // MISO, MOSI, SCLK
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 8 } // CE0
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 7 } // CE1
-  })
-
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_SPI0_OFFSET)
-Return (^RBUF)
-  }
-}
-
-Device (SPI1)
-{
-  Name (_HID, "BCM2839")
-  Name (_CID, "BCM2839")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Name (_DEP, Package() { \_SB.GDV0.RPIQ })
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared,) { 
BCM2836_SPI1_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT4, "\\_SB.GDV0.GP

[edk2-devel] [PATCH V2 05/10] Platform/RaspberryPi: Add constants for controlling SPI

2022-01-01 Thread Jeremy Linton
Add the #defines needed to access the SPI interface
documented in the BCM2711 Peripheral guide chapter 8.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 .../Bcm283x/Include/IndustryStandard/Bcm2836.h | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
index a930c64af3..55a446a86c 100644
--- a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
@@ -109,6 +109,40 @@
 #define BCM2836_SPI2_LENGTH 0x0040
 #define BCM2836_SPI2_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_SPI2_OFFSET)
 
+/* SPI register offsets */
+#define BCM2835_SPI_CS  0x00
+#define BCM2835_SPI_FIFO0x04
+#define BCM2835_SPI_CLK 0x08
+#define BCM2835_SPI_DLEN0x0c
+#define BCM2835_SPI_LTOH0x10
+#define BCM2835_SPI_DC  0x14
+
+/* Bitfields in CS */
+#define BCM2835_SPI_CS_LEN_LONG 0x0200
+#define BCM2835_SPI_CS_DMA_LEN  0x0100
+#define BCM2835_SPI_CS_CSPOL2   0x0080
+#define BCM2835_SPI_CS_CSPOL1   0x0040
+#define BCM2835_SPI_CS_CSPOL0   0x0020
+#define BCM2835_SPI_CS_RXF  0x0010
+#define BCM2835_SPI_CS_RXR  0x0008
+#define BCM2835_SPI_CS_TXD  0x0004
+#define BCM2835_SPI_CS_RXD  0x0002
+#define BCM2835_SPI_CS_DONE 0x0001
+#define BCM2835_SPI_CS_LEN  0x2000
+#define BCM2835_SPI_CS_REN  0x1000
+#define BCM2835_SPI_CS_ADCS 0x0800
+#define BCM2835_SPI_CS_INTR 0x0400
+#define BCM2835_SPI_CS_INTD 0x0200
+#define BCM2835_SPI_CS_DMAEN0x0100
+#define BCM2835_SPI_CS_TA   0x0080
+#define BCM2835_SPI_CS_CSPOL0x0040
+#define BCM2835_SPI_CS_CLEAR_RX 0x0020
+#define BCM2835_SPI_CS_CLEAR_TX 0x0010
+#define BCM2835_SPI_CS_CPOL 0x0008
+#define BCM2835_SPI_CS_CPHA 0x0004
+#define BCM2835_SPI_CS_CS_100x0002
+#define BCM2835_SPI_CS_CS_010x0001
+
 /* dma constants */
 #define BCM2836_DMA0_OFFSET 0x7000
 #define BCM2836_DMA0_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_DMA0_OFFSET)
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85253): https://edk2.groups.io/g/devel/message/85253
Mute This Topic: https://groups.io/mt/88087667/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH V2 02/10] Platform/RaspberryPi: Give the user control over the XHCI mailbox

2022-01-01 Thread Jeremy Linton
Its a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets
give users which want to try DT the option of flipping this on/off.

Users that don't want to have to deal with DT, can use ACPI.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 10 ++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c|  4 
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 9 files changed, 50 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 415d99fadb..bdabdec7a5 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -297,6 +297,16 @@ SetupVariables (
 Status = PcdSet32S (PcdXhciPci, 1);
 ASSERT_EFI_ERROR (Status);
   }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciReload",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdXhciReload, PcdGet32 (PcdXhciReload));
+ASSERT_EFI_ERROR (Status);
+  }
+
 }
   } else {
 /*
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e6e22ad82e..ff182e831d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -95,6 +95,7 @@
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
+  gRaspberryPiTokenSpaceGuid.PcdXhciReload
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 5ec17072c3..8130638876 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -62,6 +62,11 @@
 #string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
 #string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"
 
+#string STR_ADVANCED_XHCIRELOAD_PROMPT  #language en-US "DT Reload XHCI 
firmware"
+#string STR_ADVANCED_XHCIRELOAD_HELP#language en-US "OS should reload XHCI 
firmware on reset"
+#string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f668b7a553..f13b70711d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -61,6 +61,11 @@ formset
   name  = XhciPci,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_XHCIPCI_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = XhciReload,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -228,6 +233,16 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PCIE), value = 
1, flags = 0;
 endoneof;
   endif;
+
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+oneof varid = XhciReload.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_PROMPT),
+  help= STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_HELP),
+  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_DISABLE), 
value = 0, flags = DEFAULT;
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_RELOAD), 
value = 1, flags = 0;
+endoneof;
+  endif;
 endif;
 #endif
 string varid = AssetTag.AssetTag,
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index e7

[edk2-devel] [PATCH V2 00/10] Platform/RaspberryPi: Utilize SPI flash for EFI variables

2022-01-01 Thread Jeremy Linton
The RPi4 has a SPI flash with unused capacity. This set detects if
that capacity is sufficient for a UEFI variable store and utilizes
it as such. This fixes a long list of problems, and along the way likely
also fixes a random boot failure caused by the FaultTolerantWriteDxe
garbage collecting, and erasing the flash volume header which is being
used to return information about the underlying variable storage capacity.

This set was dependent on an earlier, mostly ignored set of changes to
move the GPIO/etc devices into their own SSDT and disable them. Because
of that, the two sets have been merged.

Why is that? Because the SPI flash is mux'ed with the PWM used to play
audio out the 3.5mm audio jack on this device. This causes a long list
of problems we must try and avoid, starting with the fact that the pins
need to be controlled by the uefi runtime service. The other problem is
obviously that any time a variable is updated, if the user is utilizing
the 3.5mm audio they will hear clicks and pops. Turns out that behavior
isn't unique to this patch set because the low level boot/etc exhibits this
when running in a TFA+uboot/edk2 environment. A fairly small tweak to TFA
fixes the majority of this, and the remaining runtime problems caused
by this patch actually are very slight and generally not noticeable unless
one goes looking for them. OTOH, we revert to the earlier non persisted
variable store if the firmware is running in a DT only mode, or the
user enables the ACPI GPIO block.

V1->V2:
  Move Rhpx.asl into GPIO SSDT, this fixes a windows problem if the
GPIO description is removed.
  Add longer explanation to Readme.md as well as update it to note
CM4/RPi400, newer menu item variables, etc.
  Various code cleanups caught by updated PatchCheck
  More agressive ifdef'ing out RPi4 only code for RPi3

Jeremy Linton (10):
  Platform/RaspberryPi: Cleanup menu visibility
  Platform/RaspberryPi: Give the user control over the XHCI mailbox
  Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
  Platform/RaspberryPi: Add menu item to enable/disable GPIO
  Platform/RaspberryPi: Add constants for controlling SPI
  Platform/RaspberryPi: Add mailbox cmd to control audio amp
  Platform/RaspberryPi: Add SPI/GPIO to memory map
  Platform/RaspberryPi: Allow pin function selection at runtime
  Platform/RaspberryPi: Add SPI flash variable store.
  Platform/RaspberryPi: Update RPi4 Readme

 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 126 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl   | 159 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  47 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|   2 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  10 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |  36 +-
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |   4 +
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |   1 +
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c|  60 +-
 .../Drivers/VarBlockServiceDxe/FvbInfo.c   |   8 +-
 .../Drivers/VarBlockServiceDxe/VarBlockService.c   | 657 -
 .../Drivers/VarBlockServiceDxe/VarBlockService.h   |  10 +
 .../VarBlockServiceDxe/VarBlockServiceDxe.c|  38 +-
 .../VarBlockServiceDxe/VarBlockServiceDxe.inf  |   6 +
 Platform/RaspberryPi/Include/ConfigVars.h  |   4 +
 .../RaspberryPi/Include/IndustryStandard/RpiMbox.h |   1 +
 .../RaspberryPi/Include/Protocol/RpiFirmware.h |   7 +
 Platform/RaspberryPi/RPi3/RPi3.dsc |  12 +
 Platform/RaspberryPi/RPi4/RPi4.dsc |  14 +
 Platform/RaspberryPi/RPi4/Readme.md|  63 +-
 Platform/RaspberryPi/RaspberryPi.dec   |   2 +
 .../Bcm283x/Include/IndustryStandard/Bcm2836.h |  34 ++
 Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h |   6 +
 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c |  16 +-
 26 files changed, 1160 insertions(+), 171 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85249): https://edk2.groups.io/g/devel/message/85249
Mute This Topic: https://groups.io/mt/88087663/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH V2 01/10] Platform/RaspberryPi: Cleanup menu visibility

2022-01-01 Thread Jeremy Linton
Lets allow some of these options to change when the
system is in ACPI+DT mode. Plus the fan temp should
be disabled when ACPI isn't enabled.

Tested-by: Ard Biesheuvel 
Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index e8bf16312d..f668b7a553 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -196,7 +196,7 @@ formset
 endoneof;
 
 #if (RPI_MODEL == 4)
-grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   oneof varid = FanOnGpio.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANONGPIO_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANONGPIO_HELP),
@@ -207,7 +207,7 @@ formset
   endoneof;
 endif;
 
-grayoutif ideqval FanOnGpio.Enabled == 0;
+grayoutif ideqval FanOnGpio.Enabled == 0 OR ideqval 
SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   numeric varid = FanTemp.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANTEMP_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANTEMP_HELP),
@@ -219,7 +219,7 @@ formset
 endif;
 
 suppressif ideqval XhciPci.Value == 2;
-  grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
 oneof varid = XhciPci.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_XHCIPCI_HELP),
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85248): https://edk2.groups.io/g/devel/message/85248
Mute This Topic: https://groups.io/mt/88087662/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH] Maintainers.txt: Replace Pete with Jeremy as RPi reviewer

2021-12-17 Thread Jeremy Linton
First a huge thank you to Pete Batard for all the hard work
landing the RPi code here, and keeping everyone in line.

But, he has lots of commitments, and its time to give him
a breather. As such, I will take over as a platform reviewer.

Cc: Pete Batard 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Andrei Warkentin 
Cc: Samer El-Haj-Mahmoud 
Signed-off-by: Jeremy Linton 
---
 Maintainers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 2cad0a597d..a6ce4eee0f 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -346,7 +346,7 @@ F: Platform/RaspberryPi/
 F: Silicon/Broadcom/
 M: Ard Biesheuvel 
 M: Leif Lindholm 
-R: Pete Batard 
+R: Jeremy Linton 

 RPMB driver for OP-TEE
 F: Drivers/OpTee/OpteeRpmbPkg/
--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#85079): https://edk2.groups.io/g/devel/message/85079
Mute This Topic: https://groups.io/mt/87792984/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length

2021-12-15 Thread Jeremy Linton

Hi,

On 12/14/21 16:49, Adrien Thierry wrote:

The Raspberry Pi support in edk2-platforms, including ACPI, is a direct 
ancestor of the original ms-iot tree (https://github.com/ms-iot/RPi-UEFI, by 
way of https://github.com/andreiw/RaspberryPiPkg).
The way the miniUART is described in ACPI came from Microsoft. Microsoft 
introduced DBG2/SPCR type 0x10 
(https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table)
 and the BCM2836 _HID to describe the miniUART, and the contract is that the 
base address includes all those crazy registers.

To the best of my knowledge, today there isn't any other way to correctly 
describe the miniUART in a DBG2, SPCR or DSDT. Moreover, because there's code 
out there in at least two operating systems coded against these specific 
definitions, you don't get to change how a _HID == BCM2836 device or SPCR/DBG2 
type 0x10 is described.


Thanks for your feedback!
I only had Linux in mind and didn't think about the other implementations
that would break. Thank you for stating the historical reasons why things
are set that way, I better understand now and see why this patch wouldn't
be such a great idea.


I guess I wasn't clear, I wasn't suggesting we change the existing
mechanism, so yes, I agree we either need another mechanism, or linux is
going to have to deal with it as is. The latter is IMHO the best option
(and as I mentioned I have patches to make it work), but sort of moves
us away from the standard uart/etc mechanisms we want for systemready.
So in that regard its not ideal.


I'm very interested to play with your patches if you could send them :)
I've been trying to add ACPI support to the miniuart Linux driver, and
stumbled across two issues:


I sent you a hatchet job that works with the current firmware.


- the miniuart base address "off by 0x40" in the DSDT (the subject of
this thread)
I think a reasonable choice is probably to add a structure to the linux 
acpi_device_id table, and put the offset in there, retrieve it during 
_probe with the macro that checks for a acpi device and picks off the 
acpi device match entry and then add the offset to the resource.




- how to properly get the clock rate with ACPI


Again if you look in the Uart.asl file you modified at the pl011, you 
will see that there is a clock-frequency DSD. Something similar appears 
to work on the pi4 since the miniuart clock doesn't appear to be 
changing over core frequency changes, and if that starts it looks like 
ACPI won't be the only victim.




Ideally, the end goal would be to have both the serial console and BT
working with the miniuart.

Adrien





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84941): https://edk2.groups.io/g/devel/message/84941
Mute This Topic: https://groups.io/mt/87501357/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length

2021-12-14 Thread Jeremy Linton

Hi,

On 12/14/21 00:21, Andrei Warkentin wrote:

The Raspberry Pi support in edk2-platforms, including ACPI, is a direct 
ancestor of the original ms-iot tree (https://github.com/ms-iot/RPi-UEFI, by 
way of https://github.com/andreiw/RaspberryPiPkg).
The way the miniUART is described in ACPI came from Microsoft. Microsoft 
introduced DBG2/SPCR type 0x10 
(https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table)
 and the BCM2836 _HID to describe the miniUART, and the contract is that the 
base address includes all those crazy registers.

To the best of my knowledge, today there isn't any other way to correctly 
describe the miniUART in a DBG2, SPCR or DSDT. Moreover, because there's code 
out there in at least two operating systems coded against these specific 
definitions, you don't get to change how a _HID == BCM2836 device or SPCR/DBG2 
type 0x10 is described.

If you wanted to introduce an alternate mechanism to describe the miniUART - great. 
You'd have to pick a new _HID. And re-use one of the generic DBG2/SPCR types or 
cajole for a new one (I'm guessing in the ASWG but I really don't know). But you 
surely can't haphazardly change an existing firmware<->OS contract. Moreover, 
you can't deprecate the existing contract overnight as well, so you'd have to add an 
option to expose the miniUART using a presumably more-Linux friendly option.


I guess I wasn't clear, I wasn't suggesting we change the existing 
mechanism, so yes, I agree we either need another mechanism, or linux is 
going to have to deal with it as is. The latter is IMHO the best option 
(and as I mentioned I have patches to make it work), but sort of moves 
us away from the standard uart/etc mechanisms we want for systemready. 
So in that regard its not ideal.




If you do introduce a new mechanism to describe the miniUART in ACPI, I'm happy 
to add support for it in ESXi, paving the way for eventual deprecation of the 
current mechanism (assuming you get all the other OSes to play ball too...)

Still a NAK. It's not a fix because it's not broken. And it's not considered 
broken just because you don't like the definitions. I don't like the 
definitions either, but that's all we got.


Yes, I tend to agree WRT to changing the base address for the existing 
HID. So I wasn't disagreeing with your intent, just trying to point out 
a way forward without changing the base addr. Although, I'm going to 
continue thinking its broken :)



Thanks,




A


From: Jeremy Linton 
Sent: Monday, December 13, 2021 11:39 PM
To: devel@edk2.groups.io ; Andrei Warkentin ; Ard 
Biesheuvel ; Adrien Thierry ; Pete Batard 

Cc: Ard Biesheuvel ; Leif Lindholm 

Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix 
miniuart base address and length

Hi,

On 12/13/21 13:17, Andrei Warkentin via groups.io wrote:

If I understand correctly, you want to describe the UART at 0x00215000 to be at 
0x00215040.

This will break SPCR and DBG2 - so that's a regression for Windows, ESXi and 
possibly the NetBSDs.

I guess that's a NAK unless I misunderstood something.


Presumably the end goal is to get BT working, or are we trying to get
the console working too?

Either way, the historical SPCR definition is less than ideal because it
covers those AUX_IRQ/AUX_ENABLE registers which include information for
the SPI which isn't included in the "uart" definition here. So, IMHO it
is wrong, but its stuck that way unless we define another uart. Which if
all we wanted it for was BT then we could just create another device
under BCM2836 which is only the 8250 like registers. That is sorta ugly,
but not having a standard uart is ugly too. The other ugly thing is to
just use the address as is, and offset it by 0x40 in linux as part of
the clock and ACPI bindings linux patch. (i've got a patch to make it
work someone wants to bite into it. Lol).

For linux the base clock-rate is going to have to be added as a _DSD
too. Which I assume is a large part of why it has a custom SPCR id? Put
another way, is anyone using the extra AUX_ registers, and what else are
people (windows/etc) "quirking" with the SPCR id?

For linux I've not particularly felt the need to fix this because I had
BT working (although unreliably) this time last year when I was working
on the SD/SDIO drivers, and my answer at the time was that one either
gets a serial console using the pl011 or one gets BT with the pl011. But
it looks like at a minimum the linux-firmware project and the brcmfmac
firmware loader have been tweaked over the past year and getting BT
working isn't as simple as just taking the miniuart-bt line out of
config.txt as I have in my not particularly good notes from that time
period.

So, while its behaving like it did when it had bad firmware, it could be
something in the lower level firmware since attempting to roll back to
an older firmware/kernel I had on another d

Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length

2021-12-13 Thread Jeremy Linton

Hi,

On 12/13/21 13:17, Andrei Warkentin via groups.io wrote:

If I understand correctly, you want to describe the UART at 0x00215000 to be at 
0x00215040.

This will break SPCR and DBG2 - so that's a regression for Windows, ESXi and 
possibly the NetBSDs.

I guess that's a NAK unless I misunderstood something.


Presumably the end goal is to get BT working, or are we trying to get 
the console working too?


Either way, the historical SPCR definition is less than ideal because it 
covers those AUX_IRQ/AUX_ENABLE registers which include information for 
the SPI which isn't included in the "uart" definition here. So, IMHO it 
is wrong, but its stuck that way unless we define another uart. Which if 
all we wanted it for was BT then we could just create another device 
under BCM2836 which is only the 8250 like registers. That is sorta ugly, 
but not having a standard uart is ugly too. The other ugly thing is to 
just use the address as is, and offset it by 0x40 in linux as part of 
the clock and ACPI bindings linux patch. (i've got a patch to make it 
work someone wants to bite into it. Lol).


For linux the base clock-rate is going to have to be added as a _DSD 
too. Which I assume is a large part of why it has a custom SPCR id? Put 
another way, is anyone using the extra AUX_ registers, and what else are 
people (windows/etc) "quirking" with the SPCR id?


For linux I've not particularly felt the need to fix this because I had 
BT working (although unreliably) this time last year when I was working 
on the SD/SDIO drivers, and my answer at the time was that one either 
gets a serial console using the pl011 or one gets BT with the pl011. But 
it looks like at a minimum the linux-firmware project and the brcmfmac 
firmware loader have been tweaked over the past year and getting BT 
working isn't as simple as just taking the miniuart-bt line out of 
config.txt as I have in my not particularly good notes from that time 
period.


So, while its behaving like it did when it had bad firmware, it could be 
something in the lower level firmware since attempting to roll back to 
an older firmware/kernel I had on another disk didn't immediately fix it.






From: Ard Biesheuvel 
Sent: Monday, December 13, 2021 9:14 AM
To: Adrien Thierry ; Andrei Warkentin ; 
Pete Batard 
Cc: edk2-devel-groups-io ; Ard Biesheuvel 
; Leif Lindholm 
Subject: Re: [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base 
address and length

On Mon, 13 Dec 2021 at 15:54, Adrien Thierry  wrote:


Hi Ard, Leif, Pete

Do you have any feedback on this patch ?



No objections from me but I'd like an ack from someone else as well.










-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84790): https://edk2.groups.io/g/devel/message/84790
Mute This Topic: https://groups.io/mt/87501357/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH 0/9] Platform/RaspberryPi: Utilize SPI flash for EFI variables

2021-12-03 Thread Jeremy Linton

Hi,

On 12/3/21 12:12, Ard Biesheuvel wrote:

On Thu, 2 Dec 2021 at 18:55, Jeremy Linton  wrote:


Hi,


On 12/2/21 11:09, Ard Biesheuvel wrote:

On Thu, 2 Dec 2021 at 18:03, Ard Biesheuvel  wrote:


On Thu, 2 Dec 2021 at 17:52, Jeremy Linton  wrote:


The RPi4 has a SPI flash with unused capacity. This set detects if
that capacity is sufficient for a UEFI variable store and utilizes
it as such. This fixes a long list of problems, and along the way likely
also fixes a random boot failure caused by the FaultTolerantWriteDxe
garbage collecting, and erasing the flash volume header which is being
used to return information about the underlying variable storage capacity.

This set was dependent on an earlier, mostly ignored set of changes to
move the GPIO/etc devices into their own SSDT and disable them. Because
of that, the two sets have been merged.

Why is that? Because the SPI flash is mux'ed with the PWM used to play
audio out the 3.5mm audio jack on this device. This causes a long list
of problems we must try and avoid, starting with the fact that the pins
need to be controlled by the uefi runtime service. The other problem is
obviously that any time a variable is updated, if the user is utilizing
the 3.5mm audio they will hear clicks and pops. Turns out that behavior
isn't unique to this patch set because the low level boot/etc exhibits this
when running in a TFA+uboot/edk2 environment. A fairly small tweak to TFA
fixes the majority of this, and the remaining runtime problems caused
by this patch actually are very slight and generally not noticeable unless
one goes looking for them. OTOH, we revert to the earlier non persisted
variable store if the firmware is running in a DT only mode, or the
user enables the ACPI GPIO block.


Jeremy Linton (9):
Platform/RaspberryPi: Cleanup menu visibility
Platform/RaspberryPi: Give the user control over the XHCI mailbox
Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
Platform/RaspberryPi: Add menu item to enable/disable GPIO
Platform/RaspberryPi: Add constants for controlling SPI
Platform/RaspberryPi: Add mailbox cmd to control audio amp
Platform/RaspberryPi: Add SPI/GPIO to memory map
Platform/RaspberryPi: Allow pin function selection at runtime
Platform/RaspberryPi: Add SPI flash variable store.



Very nice!

I am having trouble applying these patches, though. Could you please
resend without the random whitespace changes?


It appears only 2/9 is affected, the remaining ones apply cleanly,
with the exception of 9/9, which seems to be missing entirely. Could
you please resend that one as well?



Hi,

So, 2/2 was probably me too, I resent it as well with the same subject
but of course the email thread id isn't right.


Thanks

I gave this a spin, and Boot variables created by the Debian
installer persisted as expected, so

Tested-by: Ard Biesheuvel 

Before I merge this, though, could you elaborate on how playing with
the SPI flash like this is not going to brick my RPi4? Also, others,
please chime in as well.




First though, in the constant tweaking of patches, I noticed that 6/9 
"Add mailbox command to control audio amp" should probably have the LDO 
state DEBUG_ERROR's removed/reduced (I just removed them). NBD either 
way I guess.


So, back to how you won't permanently brick your rpi. Bricking it seems 
a lot harder than random SPI corruption, which I managed to achieve a 
few times while developing this set. More than once I corrupted it 
sufficiently to keep the low level bootloader from running. In those 
cases the rpi foundation's 
https://www.raspberrypi.com/news/raspberry-pi-imager-imaging-utility/ 
imaging tool has an option "Bootloader EEPOM configuration", which 
creates an SD image that the SoC will prefer to boot from over the SPI 
flash. That utility erases the entire flash and writes the latest 
bootloader image to it. The whole process takes a few seconds if one 
keeps the recovery disk handy.


So, I think we are good if someone decides to run that utility to 
upgrade their "EEPROM", or we have bugs that corrupt it. My larger worry 
is that we create upgrade problems with the EFI firmware itself, but I 
don't see any evidence of that happening yet, we just need to be careful 
about how we initialize new variables to avoid a situation where the 
user has to use that utility to reset the EFI variable portion of the flash.


The other issue is that the rpi foundation hasn't made any guarantees 
that this space will remain available in the future, which this code 
should deal with as is, by reverting to the previous behavior. If/when 
they do that we can trim some of their fat, or ask them politely to 
create a reduced feature version for us (say by removing nvme boot/etc), 
or simply keep using the older versions until we find legitimate 
problems with them.




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84335): 

Re: [edk2-devel] [PATCH 0/9] Platform/RaspberryPi: Utilize SPI flash for EFI variables

2021-12-02 Thread Jeremy Linton

Hi,


On 12/2/21 11:09, Ard Biesheuvel wrote:

On Thu, 2 Dec 2021 at 18:03, Ard Biesheuvel  wrote:


On Thu, 2 Dec 2021 at 17:52, Jeremy Linton  wrote:


The RPi4 has a SPI flash with unused capacity. This set detects if
that capacity is sufficient for a UEFI variable store and utilizes
it as such. This fixes a long list of problems, and along the way likely
also fixes a random boot failure caused by the FaultTolerantWriteDxe
garbage collecting, and erasing the flash volume header which is being
used to return information about the underlying variable storage capacity.

This set was dependent on an earlier, mostly ignored set of changes to
move the GPIO/etc devices into their own SSDT and disable them. Because
of that, the two sets have been merged.

Why is that? Because the SPI flash is mux'ed with the PWM used to play
audio out the 3.5mm audio jack on this device. This causes a long list
of problems we must try and avoid, starting with the fact that the pins
need to be controlled by the uefi runtime service. The other problem is
obviously that any time a variable is updated, if the user is utilizing
the 3.5mm audio they will hear clicks and pops. Turns out that behavior
isn't unique to this patch set because the low level boot/etc exhibits this
when running in a TFA+uboot/edk2 environment. A fairly small tweak to TFA
fixes the majority of this, and the remaining runtime problems caused
by this patch actually are very slight and generally not noticeable unless
one goes looking for them. OTOH, we revert to the earlier non persisted
variable store if the firmware is running in a DT only mode, or the
user enables the ACPI GPIO block.


Jeremy Linton (9):
   Platform/RaspberryPi: Cleanup menu visibility
   Platform/RaspberryPi: Give the user control over the XHCI mailbox
   Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
   Platform/RaspberryPi: Add menu item to enable/disable GPIO
   Platform/RaspberryPi: Add constants for controlling SPI
   Platform/RaspberryPi: Add mailbox cmd to control audio amp
   Platform/RaspberryPi: Add SPI/GPIO to memory map
   Platform/RaspberryPi: Allow pin function selection at runtime
   Platform/RaspberryPi: Add SPI flash variable store.



Very nice!

I am having trouble applying these patches, though. Could you please
resend without the random whitespace changes?


It appears only 2/9 is affected, the remaining ones apply cleanly,
with the exception of 9/9, which seems to be missing entirely. Could
you please resend that one as well?



Hi,

So, 2/2 was probably me too, I resent it as well with the same subject 
but of course the email thread id isn't right.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84270): https://edk2.groups.io/g/devel/message/84270
Mute This Topic: https://groups.io/mt/87456856/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 2/9] Platform/RaspberryPi: Give the user control over the XHCI mailbox

2021-12-02 Thread Jeremy Linton
Its a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets
give users which want to try DT the option of flipping this on/off.

Users that don't want to have to deal with DT, can use ACPI.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 10 ++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c|  4 
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 9 files changed, 50 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 6b69934ef3..8979b3da4c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -297,6 +297,16 @@ SetupVariables (
 Status = PcdSet32S (PcdXhciPci, 1);
 ASSERT_EFI_ERROR (Status);
   }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciReload",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdXhciReload, PcdGet32 (PcdXhciReload));
+ASSERT_EFI_ERROR (Status);
+  }
+
 }
   } else {
 /*
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e6e22ad82e..ff182e831d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -95,6 +95,7 @@
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
+  gRaspberryPiTokenSpaceGuid.PcdXhciReload

 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index e25bb83cd3..e40b0914f8 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -63,6 +63,11 @@
 #string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
 #string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"

+#string STR_ADVANCED_XHCIRELOAD_PROMPT  #language en-US "DT Reload XHCI 
firmware"
+#string STR_ADVANCED_XHCIRELOAD_HELP#language en-US "OS should reload XHCI 
firmware on reset"
+#string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 830c72eac6..61171cf658 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -61,6 +61,11 @@ formset
   name  = XhciPci,
   guid  = CONFIGDXE_FORM_SET_GUID;

+efivarstore ADVANCED_XHCIPCI_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = XhciReload,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -229,6 +234,16 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PCIE), value = 
1, flags = 0;
 endoneof;
   endif;
+
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+oneof varid = XhciReload.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_PROMPT),
+  help= STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_HELP),
+  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_DISABLE), 
value = 0, flags = DEFAULT;
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_RELOAD), 
value = 1, flags = 0;
+endoneof;
+  endif;
 endif;
 #endif
 string varid = AssetTag.AssetTag,
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index e72d132b18..a808b1bf8c 100644
--- a/Pl

[edk2-devel] [PATCH 9/9] Platform/RaspberryPi: Add SPI flash variable store.

2021-12-02 Thread Jeremy Linton
The RPi4 has a 512KB SPI flash, which depending on RPi
and firmware revision has 300-180K free. We can use this
storage to persist variables when the OS is running or
over firmware upgrades. The problem is that the SPI is pin
mux'ed with the PWM audio, so we want to leave the PWM
configured for OS use. And of course there is the problem
of sharing the GPIO block with OS's that are aware of it.
Hence a previous patch set which moves the GPIO and some of
the low level i2c/etc devices into its own SSDT, and
disables them by default.

This patch, adds a few SPI access functions directly to
the variable store rather than creating another runtime
service since the early boot ordering is critical. These
functions are of the form ReadSpi(), WriteSpi(),
DisableSpiWp(), etc all with Spi in the name. On top of that
a few "Flash" routines are created which provide high level
functions for reading/writing and walking the portion of the
SPI flash we use to clone the variable store region.
Importantly WalkFlashVolume() walks the entire SPI flash
region, which has a simple header structure containing
filename+len for each region of the flash, to return how
much of the capacity is being utilized by the existing
bootloader/etc firmware.

So, if this is a RPi4, and there is sufficient space, and
that space doesn't have a valid varstore header we erase
it and flush the RPI's varstore region to the SPI. Then
we note its starting offset in mFvInstance->FlashOffset.
>From then on, writes to the EFI_FW_VOL_BLOCK_DEVICE are
written to both the RAM copy as well as the SPI flash. If
the empty region has a valid header we read the entire
region overtop of the one being passed as part of the RPi's
BL33, and continue as above.

At ready to boot we re-enable the LDO, and then during the
dump vars check, we check for DT or the GPIO being enabled
and disable the runtime SPI updates because we can't be sure
of what the OS might be doing with the GPIO. The dual ACPI
and DT mode, leaves it enabled (if GPIO is disabled) so
care should be taken.

Now, one of the problems here is that with the LDO enabled
any SPI accesses can be heard over the speakers as pops,
buzzes, or scratchy tones. This is happening even without
this patch because TFA and/or the rpi low level firmware
doesn't itself assure the LDO is disabled during resets, so
the early SoC startup is quite noisy. We add to this, but
alongside that a couple fairly trivial TFA patchs, to mute
it before reset, and again assure its off before releasing
to us solve a large part of this problem. That said, this
can now happen during runtime as well. Generally the OS's
aren't doing a lot of variable updates, but when they do
its generally barely noticable clicks since we aren't going
through the long process of muting/unmuting the LDO which
itself causes a pop.

So, this patch fixes a whole bunch of bugs on github that
exist because the variable store isn't persisted. It also
fixes a rather large bug in the existing variable store
code caused by the FaultTolerantWriteDxe erasing the entire
variable store region when it garbage collects during startup.
That latter bug is the result of FvbGetLbaAddress reading
recently erased data from the VolumeHeader before its been
recreated, and results in random UEFI crashes.

Signed-off-by: Jeremy Linton 
---
 .../Drivers/VarBlockServiceDxe/FvbInfo.c   |   8 +-
 .../Drivers/VarBlockServiceDxe/VarBlockService.c   | 654 -
 .../Drivers/VarBlockServiceDxe/VarBlockService.h   |  10 +
 .../VarBlockServiceDxe/VarBlockServiceDxe.c|  38 +-
 .../VarBlockServiceDxe/VarBlockServiceDxe.inf  |   6 +
 5 files changed, 694 insertions(+), 22 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
index 0e0c108dba..ee18f327e6 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/FvbInfo.c
@@ -11,12 +11,7 @@
 #include 
 #include 
 #include 
-
-typedef struct {
-  UINT64  FvLength;
-  EFI_FIRMWARE_VOLUME_HEADER  FvbInfo;
-  EFI_FV_BLOCK_MAP_ENTRY  End[1];
-} EFI_FVB_MEDIA_INFO;
+#include "VarBlockService.h"
 
 EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   //
@@ -38,6 +33,7 @@ EFI_FVB_MEDIA_INFO  mPlatformFvbMediaInfo[] = {
   FixedPcdGet32 (PcdNvStorageEventLogSize),
   EFI_FVH_SIGNATURE,
   EFI_FVB2_MEMORY_MAPPED |
+EFI_FVB2_STICKY_WRITE |
 EFI_FVB2_READ_ENABLED_CAP |
 EFI_FVB2_READ_STATUS |
 EFI_FVB2_WRITE_ENABLED_CAP |
diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c 
b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
index 572309439a..03ccf799b6 100644
--- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
+++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c
@@ -7,17 +7,28 @@
  *
  **/
 
+#inclu

Re: [edk2-devel] [PATCH 0/9] Platform/RaspberryPi: Utilize SPI flash for EFI variables

2021-12-02 Thread Jeremy Linton

On 12/2/21 11:09, Ard Biesheuvel wrote:

On Thu, 2 Dec 2021 at 18:03, Ard Biesheuvel  wrote:


On Thu, 2 Dec 2021 at 17:52, Jeremy Linton  wrote:


The RPi4 has a SPI flash with unused capacity. This set detects if
that capacity is sufficient for a UEFI variable store and utilizes
it as such. This fixes a long list of problems, and along the way likely
also fixes a random boot failure caused by the FaultTolerantWriteDxe
garbage collecting, and erasing the flash volume header which is being
used to return information about the underlying variable storage capacity.

This set was dependent on an earlier, mostly ignored set of changes to
move the GPIO/etc devices into their own SSDT and disable them. Because
of that, the two sets have been merged.

Why is that? Because the SPI flash is mux'ed with the PWM used to play
audio out the 3.5mm audio jack on this device. This causes a long list
of problems we must try and avoid, starting with the fact that the pins
need to be controlled by the uefi runtime service. The other problem is
obviously that any time a variable is updated, if the user is utilizing
the 3.5mm audio they will hear clicks and pops. Turns out that behavior
isn't unique to this patch set because the low level boot/etc exhibits this
when running in a TFA+uboot/edk2 environment. A fairly small tweak to TFA
fixes the majority of this, and the remaining runtime problems caused
by this patch actually are very slight and generally not noticeable unless
one goes looking for them. OTOH, we revert to the earlier non persisted
variable store if the firmware is running in a DT only mode, or the
user enables the ACPI GPIO block.


Jeremy Linton (9):
   Platform/RaspberryPi: Cleanup menu visibility
   Platform/RaspberryPi: Give the user control over the XHCI mailbox
   Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
   Platform/RaspberryPi: Add menu item to enable/disable GPIO
   Platform/RaspberryPi: Add constants for controlling SPI
   Platform/RaspberryPi: Add mailbox cmd to control audio amp
   Platform/RaspberryPi: Add SPI/GPIO to memory map
   Platform/RaspberryPi: Allow pin function selection at runtime
   Platform/RaspberryPi: Add SPI flash variable store.



Very nice!

I am having trouble applying these patches, though. Could you please
resend without the random whitespace changes?


It appears only 2/9 is affected, the remaining ones apply cleanly,
with the exception of 9/9, which seems to be missing entirely. Could
you please resend that one as well?



Yah, so it looks like 2/9 picked up a couple tab/trailing whitespace 
cleanups when I ran it through the edk2 checkpatch right before sending 
it. I can kill those, although, that doesn't really explain why it 
doesn't apply. Both the copies I got look ok, although the groups.io 
version changed the content-type from text/plain/7bit to 
text/plain/quoted-printable, which is disturbing if it decided to quote 
parts of the patch.


9/9 though seems to be my side, because it got rejected due to UTF-8 
whitespace on the last line of the patch not being 7-bit.


My mail process on this ML seems to continue to be a pain, and i'm not 
entirely sure why its special (I post patches elseswhere with a lot less 
trouble).




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84266): https://edk2.groups.io/g/devel/message/84266
Mute This Topic: https://groups.io/mt/87456856/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 8/9] Platform/RaspberryPi: Allow pin function selection at runtime

2021-12-02 Thread Jeremy Linton
Update GpioLib slightly so that we can change the GPIO pin
muxing at runtime. For the moment only the GpioPinFuncGet/Set()
routines are used at runtime, and only by the Variable service.

Signed-off-by: Jeremy Linton 
---
 Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h |  6 ++
 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c | 16 ++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h 
b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
index 1f7d2204e0..79765be4fb 100644
--- a/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
+++ b/Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h
@@ -45,4 +45,10 @@ GpioSetPull (
   IN  UINTN   Pud
 );

+VOID
+GpioSetupRuntime (
+  VOID
+);
+
+
 #endif /* __GPIO_LIB__ */
diff --git a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c 
b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
index eaf53e5369..fc1f928e6b 100644
--- a/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
+++ b/Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c
@@ -15,10 +15,22 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

+
+STATIC EFI_PHYSICAL_ADDRESS GpioGfpSel0 = GPIO_GPFSEL0;
+
+VOID
+GpioSetupRuntime (
+  VOID
+  )
+{
+  EfiConvertPointer (0x0, (VOID**));
+}
+
 STATIC
 VOID
 GpioFSELModify (
@@ -30,7 +42,7 @@ GpioFSELModify (
   UINT32 Val;
   EFI_PHYSICAL_ADDRESS Reg;

-  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+  Reg = RegIndex * sizeof (UINT32) + GpioGfpSel0;

   ASSERT (Reg <= GPIO_GPFSEL5);
   ASSERT ((~ModifyMask & FunctionMask) == 0);
@@ -77,7 +89,7 @@ GpioPinFuncGet (

   RegIndex = Pin / 10;
   SelIndex = Pin % 10;
-  Reg = RegIndex * sizeof (UINT32) + GPIO_GPFSEL0;
+  Reg = RegIndex * sizeof (UINT32) + GpioGfpSel0;

   Val = MmioRead32 (Reg);
   Val >>= SelIndex * GPIO_FSEL_BITS_PER_PIN;
--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84261): https://edk2.groups.io/g/devel/message/84261
Mute This Topic: https://groups.io/mt/87456864/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 6/9] Platform/RaspberryPi: Add mailbox cmd to control audio amp

2021-12-02 Thread Jeremy Linton
The lower level firmware can enable/disable a LDO audio
amp, which allows us to mute/unmute audio output while
the firmware is running.

Signed-off-by: Jeremy Linton 
---
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 62 +-
 .../RaspberryPi/Include/IndustryStandard/RpiMbox.h |  1 +
 .../RaspberryPi/Include/Protocol/RpiFirmware.h |  7 +++
 3 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index d38ffbc7d3..03c1e1708f 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -1532,6 +1532,65 @@ RpiFirmwareNotifyGpioSetCfg (
   return Status;
 }

+#pragma pack()
+typedef struct {
+  UINT32   State;
+} RPI_FW_SET_LDO_REG_TAG;
+
+typedef struct {
+  RPI_FW_BUFFER_HEAD   BufferHead;
+  RPI_FW_TAG_HEAD  TagHead;
+  RPI_FW_SET_LDO_REG_TAG   TagBody;
+  UINT32   EndTag;
+} RPI_FW_SET_LDO_REG_CMD;
+#pragma pack()
+
+
+STATIC
+EFI_STATUS
+EFIAPI
+RpiFirmwareSetLdoRegState (
+  IN UINTN State
+  )
+{
+  RPI_FW_SET_LDO_REG_CMD   *Cmd;
+  EFI_STATUS   Status;
+  UINT32   Result;
+
+  if (!AcquireSpinLockOrFail ()) {
+DEBUG ((DEBUG_ERROR, "%a: failed to acquire spinlock\n", __FUNCTION__));
+return EFI_DEVICE_ERROR;
+  }
+
+  DEBUG ((DEBUG_ERROR, "%a: set LDO\n", __FUNCTION__));
+  Cmd = mDmaBuffer;
+  ZeroMem (Cmd, sizeof (*Cmd));
+
+  Cmd->BufferHead.BufferSize  = sizeof (*Cmd);
+  Cmd->BufferHead.Response= 0;
+  Cmd->TagHead.TagId  = RPI_MBOX_SET_LDO_REGULATOR;
+  Cmd->TagHead.TagSize= sizeof (Cmd->TagBody);
+  Cmd->TagBody.State  = State;
+
+  Cmd->TagHead.TagValueSize   = 0;
+  Cmd->EndTag = 0;
+
+  Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
+
+  DEBUG ((DEBUG_ERROR, "%a: set LDO Done\n", __FUNCTION__));
+  if (EFI_ERROR (Status) ||
+  Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
+DEBUG ((DEBUG_ERROR,
+  "%a: mailbox  transaction error: Status == %r, Response == 0x%x\n",
+  __FUNCTION__, Status, Cmd->BufferHead.Response));
+  }
+
+  ReleaseSpinLock ();
+
+  return Status;
+}
+
+
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL mRpiFirmwareProtocol = {
   RpiFirmwareSetPowerState,
   RpiFirmwareGetMacAddress,
@@ -1557,7 +1616,8 @@ STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL 
mRpiFirmwareProtocol = {
   RpiFirmwareNotifyXhciReset,
   RpiFirmwareGetCurrentClockState,
   RpiFirmwareSetClockState,
-  RpiFirmwareNotifyGpioSetCfg
+  RpiFirmwareNotifyGpioSetCfg,
+  RpiFirmwareSetLdoRegState
 };

 /**
diff --git a/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h 
b/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
index 551c2b82e5..f36aaafaf8 100644
--- a/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
+++ b/Platform/RaspberryPi/Include/IndustryStandard/RpiMbox.h
@@ -92,6 +92,7 @@
 #define RPI_MBOX_NOTIFY_REBOOT0x00030048
 #define RPI_MBOX_GET_POE_HAT_VAL  0x00030049
 #define RPI_MBOX_SET_POE_HAT_VAL  0x00030050
+#define RPI_MBOX_SET_LDO_REGULATOR0x00030056
 #define RPI_MBOX_NOTIFY_XHCI_RESET0x00030058

 #define RPI_MBOX_SET_CLOCK_STATE  0x00038001
diff --git a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h 
b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
index c48bb6e434..175894e37a 100644
--- a/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
+++ b/Platform/RaspberryPi/Include/Protocol/RpiFirmware.h
@@ -171,6 +171,12 @@ EFI_STATUS
   UINTN State
   );

+typedef
+EFI_STATUS
+(EFIAPI *SET_LDO_REGULATOR) (
+  UINTN State
+  );
+
 typedef struct {
   SET_POWER_STATESetPowerState;
   GET_MAC_ADDRESSGetMacAddress;
@@ -197,6 +203,7 @@ typedef struct {
   GET_CLOCK_STATEGetClockState;
   SET_CLOCK_STATESetClockState;
   GPIO_SET_CFG   SetGpioConfig;
+  SET_LDO_REGULATOR  SetLdoRegState;
 } RASPBERRY_PI_FIRMWARE_PROTOCOL;

 extern EFI_GUID gRaspberryPiFirmwareProtocolGuid;
--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84259): https://edk2.groups.io/g/devel/message/84259
Mute This Topic: https://groups.io/mt/87456862/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 5/9] Platform/RaspberryPi: Add constants for controlling SPI

2021-12-02 Thread Jeremy Linton
Add the #defines needed to access the SPI interface
documented in the BCM2711 Peripheral guide chapter 8.

Signed-off-by: Jeremy Linton 
---
 .../Bcm283x/Include/IndustryStandard/Bcm2836.h | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h 
b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
index a930c64af3..55a446a86c 100644
--- a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
+++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h
@@ -109,6 +109,40 @@
 #define BCM2836_SPI2_LENGTH 0x0040
 #define BCM2836_SPI2_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_SPI2_OFFSET)

+/* SPI register offsets */
+#define BCM2835_SPI_CS  0x00
+#define BCM2835_SPI_FIFO0x04
+#define BCM2835_SPI_CLK 0x08
+#define BCM2835_SPI_DLEN0x0c
+#define BCM2835_SPI_LTOH0x10
+#define BCM2835_SPI_DC  0x14
+
+/* Bitfields in CS */
+#define BCM2835_SPI_CS_LEN_LONG 0x0200
+#define BCM2835_SPI_CS_DMA_LEN  0x0100
+#define BCM2835_SPI_CS_CSPOL2   0x0080
+#define BCM2835_SPI_CS_CSPOL1   0x0040
+#define BCM2835_SPI_CS_CSPOL0   0x0020
+#define BCM2835_SPI_CS_RXF  0x0010
+#define BCM2835_SPI_CS_RXR  0x0008
+#define BCM2835_SPI_CS_TXD  0x0004
+#define BCM2835_SPI_CS_RXD  0x0002
+#define BCM2835_SPI_CS_DONE 0x0001
+#define BCM2835_SPI_CS_LEN  0x2000
+#define BCM2835_SPI_CS_REN  0x1000
+#define BCM2835_SPI_CS_ADCS 0x0800
+#define BCM2835_SPI_CS_INTR 0x0400
+#define BCM2835_SPI_CS_INTD 0x0200
+#define BCM2835_SPI_CS_DMAEN0x0100
+#define BCM2835_SPI_CS_TA   0x0080
+#define BCM2835_SPI_CS_CSPOL0x0040
+#define BCM2835_SPI_CS_CLEAR_RX 0x0020
+#define BCM2835_SPI_CS_CLEAR_TX 0x0010
+#define BCM2835_SPI_CS_CPOL 0x0008
+#define BCM2835_SPI_CS_CPHA 0x0004
+#define BCM2835_SPI_CS_CS_100x0002
+#define BCM2835_SPI_CS_CS_010x0001
+
 /* dma constants */
 #define BCM2836_DMA0_OFFSET 0x7000
 #define BCM2836_DMA0_BASE_ADDRESS   
(BCM2836_SOC_REGISTERS + BCM2836_DMA0_OFFSET)
--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84258): https://edk2.groups.io/g/devel/message/84258
Mute This Topic: https://groups.io/mt/87456861/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 7/9] Platform/RaspberryPi: Add SPI/GPIO to memory map

2021-12-02 Thread Jeremy Linton
A large reason for using the SPI flash on this platform is that
it can be updated without OS interference at rutime. In order for
that to happen we need both the SPI, as well as the GPIO
which is used to change the pinmux from the PWM device to SPI added
to the UEFI memory map as being used by the runtime service.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 3d058cb40d..ccdeddf3c0 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -503,6 +503,22 @@ ApplyVariables (
 DEBUG ((DEBUG_INFO, "Current CPU speed is %u MHz\n", Rate / FREQ_1_MHZ));
   }

+  if (mModelFamily == 4) {
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
BCM2836_SPI0_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (BCM2836_SPI0_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
+Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, 
GPIO_BASE_ADDRESS,
+  SIZE_4KB, EFI_MEMORY_UC | 
EFI_MEMORY_RUNTIME);
+ASSERT_EFI_ERROR (Status);
+Status = gDS->SetMemorySpaceAttributes (GPIO_BASE_ADDRESS,
+SIZE_4KB, 
EFI_MEMORY_UC|EFI_MEMORY_RUNTIME);
+
+ASSERT_EFI_ERROR (Status);
+  }
+
   if (mModelFamily >= 4 && PcdGet32 (PcdRamMoreThan3GB) != 0 &&
   PcdGet32 (PcdRamLimitTo3GB) == 0) {
 UINT64 SystemMemorySize;
--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84260): https://edk2.groups.io/g/devel/message/84260
Mute This Topic: https://groups.io/mt/87456863/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 4/9] Platform/RaspberryPi: Add menu item to enable/disable GPIO

2021-12-02 Thread Jeremy Linton
Now that the GPIO devices are in their own SSDT lets add
a menu item for the rpi4 to enable/disable it. For the
rpi3 the SSDT is always exported.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 17 -
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Include/ConfigVars.h   |  4 
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 8 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index f32d75ad34..3d058cb40d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -308,12 +308,27 @@ SetupVariables (
   }

 }
+
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"EnableGpio",
+   ,
+   NULL, , );
+if (EFI_ERROR (Status)) {
+  Status = PcdSet32S (PcdEnableGpio, PcdGet32 (PcdEnableGpio));
+  ASSERT_EFI_ERROR (Status);
+}
+
   } else {
 /*
  * Disable PCIe and XHCI
  */
 Status = PcdSet32S (PcdXhciPci, 0);
 ASSERT_EFI_ERROR (Status);
+/*
+ * Enable GPIO
+ */
+Status = PcdSet32S (PcdEnableGpio, 1);
+ASSERT_EFI_ERROR (Status);
   }

   Size = sizeof (AssetTagVar);
@@ -840,7 +855,7 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
 #endif
   {
 SIGNATURE_64 ('R', 'P', 'I', '3', 'G', 'P', 'I', 'O'),
-0,
+PcdToken(PcdEnableGpio),
 0,
 NULL
   },
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index ff182e831d..1cba4a2a22 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -96,6 +96,7 @@
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
   gRaspberryPiTokenSpaceGuid.PcdXhciReload
+  gRaspberryPiTokenSpaceGuid.PcdEnableGpio

 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index e40b0914f8..a036fe9edb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -68,6 +68,11 @@
 #string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
 #string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"

+#string STR_ADVANCED_ENABLEGPIO_PROMPT  #language en-US "Export GPIO devices 
to OS"
+#string STR_ADVANCED_ENABLEGPIO_HELP#language en-US "OS can see the GPIO 
device and some low level SPI and I2C interfaces"
+#string STR_ADVANCED_ENABLEGPIO_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_ENABLEGPIO_ENABLE  #language en-US "Enable"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 61171cf658..24324bb81c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -66,6 +66,11 @@ formset
   name  = XhciReload,
   guid  = CONFIGDXE_FORM_SET_GUID;

+efivarstore ADVANCED_ENABLEGPIO_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = EnableGpio,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -245,6 +250,16 @@ formset
 endoneof;
   endif;
 endif;
+
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
+  oneof varid = EnableGpio.Value,
+prompt  = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_PROMPT),
+help= STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_HELP),
+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_DISABLE), value 
= 0, flags = DEFAULT;
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_ENABLE), value 
= 1, flags = 0;
+  endoneof;
+endif;
 #endif
 string varid = AssetTag.AssetTag,

[edk2-devel] [PATCH 1/9] Platform/RaspberryPi: Cleanup menu visibility

2021-12-02 Thread Jeremy Linton
Lets allow some of these options to change when the
system is in ACPI+DT mode. Plus the fan temp should
be disabled when ACPI isn't enabled.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index df45d7b1fe..830c72eac6 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -196,7 +196,7 @@ formset
 endoneof;

 #if (RPI_MODEL == 4)
-grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   oneof varid = FanOnGpio.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANONGPIO_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANONGPIO_HELP),
@@ -208,7 +208,7 @@ formset
   endoneof;
 endif;

-grayoutif ideqval FanOnGpio.Enabled == 0;
+grayoutif ideqval FanOnGpio.Enabled == 0 OR ideqval 
SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   numeric varid = FanTemp.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANTEMP_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANTEMP_HELP),
@@ -220,7 +220,7 @@ formset
 endif;

 suppressif ideqval XhciPci.Value == 2;
-  grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
 oneof varid = XhciPci.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_XHCIPCI_HELP),
--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84256): https://edk2.groups.io/g/devel/message/84256
Mute This Topic: https://groups.io/mt/87456859/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 3/9] Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT

2021-12-02 Thread Jeremy Linton
The UEFI firmware uses the GPIO port for the fan and
real soon now the runtime SPI variable store. As such
we need to be able to either isolate those devices from
the OS or we risk clashing with OS's that reconfigure
the GPIO pins. Ideally we would just rip this out
and use _DSM() or just individual device power
on/off methods to adjust the GPIO pins when needed.

For now, lets leave it since windows at least knows
about it. In the future we will decide whether the
firmware is controlling something (SPI!) based on
whether the user has enabled the GPIO block.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 125 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl   | 157 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   6 +
 5 files changed, 164 insertions(+), 132 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index 1170d8b112..9c7041cda9 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -41,6 +41,7 @@
   SsdtThermal.asl
   Xhci.asl
   Pci.asl
+  SsdtGpio.asl

 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index 124372f880..358d2b3f54 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -21,13 +21,6 @@

 #include "AcpiTables.h"

-#define BCM_ALT0 0x4
-#define BCM_ALT1 0x5
-#define BCM_ALT2 0x6
-#define BCM_ALT3 0x7
-#define BCM_ALT4 0x3
-#define BCM_ALT5 0x2
-
 //
 // The ASL compiler does not support argument arithmetic in functions
 // like QWordMemory (). So we need to instantiate dummy qword regions
diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl 
b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
index c69e565795..f41f2670b3 100644
--- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
+++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
@@ -395,56 +395,6 @@ Device (VCSM)
   }
 }

-// Description: GPIO
-Device (GPI0)
-{
-  Name (_HID, "BCM2845")
-  Name (_CID, "BCM2845")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, GPIO_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared)
-{
-  BCM2386_GPIO_INTERRUPT0, BCM2386_GPIO_INTERRUPT1,
-  BCM2386_GPIO_INTERRUPT2, BCM2386_GPIO_INTERRUPT3
-}
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, GPIO_OFFSET)
-Return (^RBUF)
-  }
-}
-
-// Description: I2C
-Device (I2C1)
-{
-  Name (_HID, "BCM2841")
-  Name (_CID, "BCM2841")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_I2C1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_I2C1_INTERRUPT }
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 2, 3 }
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_I2C1_OFFSET)
-Return (^RBUF)
-  }
-}

 // I2C2 is the HDMI DDC connection
 Device (I2C2)
@@ -470,81 +420,6 @@ Device (I2C2)
   }
 }

-// SPI
-Device (SPI0)
-{
-  Name (_HID, "BCM2838")
-  Name (_CID, "BCM2838")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI0_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_SPI0_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 9, 10, 11 } // MISO, MOSI, SCLK
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 8 } // CE0
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 7 } // CE1
-  })
-
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_SPI0_OFFSET)
-Return (^RBUF)
-  }
-}
-
-Device (SPI1)
-{
-  Name (_HID, "BCM2839")
-  Name (_CID, "BCM2839")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Name (_DEP, Package() { \_SB.GDV0.RPIQ })
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared,) { 
BCM2836_SPI1_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT4, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 

[edk2-devel] [PATCH 2/9] Platform/RaspberryPi: Give the user control over the XHCI mailbox

2021-12-02 Thread Jeremy Linton
Its a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets
give users which want to try DT the option of flipping this on/off.

Users that don't want to have to deal with DT, can use ACPI.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 10 ++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c| 10 +++---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 9 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 6b69934ef3..8979b3da4c 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -297,6 +297,16 @@ SetupVariables (
 Status = PcdSet32S (PcdXhciPci, 1);
 ASSERT_EFI_ERROR (Status);
   }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciReload",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdXhciReload, PcdGet32 (PcdXhciReload));
+ASSERT_EFI_ERROR (Status);
+  }
+
 }
   } else {
 /*
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e6e22ad82e..ff182e831d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -95,6 +95,7 @@
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
+  gRaspberryPiTokenSpaceGuid.PcdXhciReload

 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index e25bb83cd3..e40b0914f8 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -63,6 +63,11 @@
 #string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
 #string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"

+#string STR_ADVANCED_XHCIRELOAD_PROMPT  #language en-US "DT Reload XHCI 
firmware"
+#string STR_ADVANCED_XHCIRELOAD_HELP#language en-US "OS should reload XHCI 
firmware on reset"
+#string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 830c72eac6..61171cf658 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -61,6 +61,11 @@ formset
   name  = XhciPci,
   guid  = CONFIGDXE_FORM_SET_GUID;

+efivarstore ADVANCED_XHCIPCI_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = XhciReload,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -229,6 +234,16 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PCIE), value = 
1, flags = 0;
 endoneof;
   endif;
+
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+oneof varid = XhciReload.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_PROMPT),
+  help= STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_HELP),
+  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_DISABLE), 
value = 0, flags = DEFAULT;
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_RELOAD), 
value = 1, flags = 0;
+endoneof;
+  endif;
 endif;
 #endif
 string varid = AssetTag.AssetTag,
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index a4816d4295..a8

[edk2-devel] [PATCH 0/9] Platform/RaspberryPi: Utilize SPI flash for EFI variables

2021-12-02 Thread Jeremy Linton
The RPi4 has a SPI flash with unused capacity. This set detects if
that capacity is sufficient for a UEFI variable store and utilizes
it as such. This fixes a long list of problems, and along the way likely
also fixes a random boot failure caused by the FaultTolerantWriteDxe
garbage collecting, and erasing the flash volume header which is being
used to return information about the underlying variable storage capacity.

This set was dependent on an earlier, mostly ignored set of changes to
move the GPIO/etc devices into their own SSDT and disable them. Because
of that, the two sets have been merged.

Why is that? Because the SPI flash is mux'ed with the PWM used to play
audio out the 3.5mm audio jack on this device. This causes a long list
of problems we must try and avoid, starting with the fact that the pins
need to be controlled by the uefi runtime service. The other problem is
obviously that any time a variable is updated, if the user is utilizing
the 3.5mm audio they will hear clicks and pops. Turns out that behavior
isn't unique to this patch set because the low level boot/etc exhibits this
when running in a TFA+uboot/edk2 environment. A fairly small tweak to TFA
fixes the majority of this, and the remaining runtime problems caused
by this patch actually are very slight and generally not noticeable unless
one goes looking for them. OTOH, we revert to the earlier non persisted
variable store if the firmware is running in a DT only mode, or the
user enables the ACPI GPIO block.


Jeremy Linton (9):
  Platform/RaspberryPi: Cleanup menu visibility
  Platform/RaspberryPi: Give the user control over the XHCI mailbox
  Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
  Platform/RaspberryPi: Add menu item to enable/disable GPIO
  Platform/RaspberryPi: Add constants for controlling SPI
  Platform/RaspberryPi: Add mailbox cmd to control audio amp
  Platform/RaspberryPi: Add SPI/GPIO to memory map
  Platform/RaspberryPi: Allow pin function selection at runtime
  Platform/RaspberryPi: Add SPI flash variable store.

 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 125 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl   | 157 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  47 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|   2 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  10 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |  36 +-
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |  10 +-
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |   1 +
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c|  62 +-
 .../Drivers/VarBlockServiceDxe/FvbInfo.c   |   8 +-
 .../Drivers/VarBlockServiceDxe/VarBlockService.c   | 654 -
 .../Drivers/VarBlockServiceDxe/VarBlockService.h   |  10 +
 .../VarBlockServiceDxe/VarBlockServiceDxe.c|  38 +-
 .../VarBlockServiceDxe/VarBlockServiceDxe.inf  |   6 +
 Platform/RaspberryPi/Include/ConfigVars.h  |   4 +
 .../RaspberryPi/Include/IndustryStandard/RpiMbox.h |   1 +
 .../RaspberryPi/Include/Protocol/RpiFirmware.h |   7 +
 Platform/RaspberryPi/RPi3/RPi3.dsc |  12 +
 Platform/RaspberryPi/RPi4/RPi4.dsc |  14 +
 Platform/RaspberryPi/RaspberryPi.dec   |   2 +
 .../Bcm283x/Include/IndustryStandard/Bcm2836.h |  34 ++
 Silicon/Broadcom/Bcm283x/Include/Library/GpioLib.h |   6 +
 Silicon/Broadcom/Bcm283x/Library/GpioLib/GpioLib.c |  16 +-
 25 files changed, 1107 insertions(+), 163 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

--
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84253): https://edk2.groups.io/g/devel/message/84253
Mute This Topic: https://groups.io/mt/87456856/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [edk2-platforms][PATCH v1 1/2] Platform/RaspberryPi: Add support for PWM1 in ACPI

2021-11-15 Thread Jeremy Linton

Hi,

First thanks for posting this!

I ended up tweaking this a bit to get it to apply, because something in 
my email chain mangled it more than usual. Hopefully others aren't 
seeing this.


Anyway see below..

On 11/5/21 15:34, Mario Bălănică via groups.io wrote:

Also fix PWM0 on the Raspberry Pi 4, but we can't expose both yet.
Why is that? The rpi4 needs both PWM devices to output stereo right? So 
with this patch is still mono?


Signed-off-by: Mario Bălănică 
---
  Platform/RaspberryPi/AcpiTables/AcpiTables.h   | 10 ++-
  Platform/RaspberryPi/AcpiTables/Dsdt.asl   | 34 ++---
  Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 78 

  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h| 13 
  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Pwm.h | 26 +++
  5 files changed, 122 insertions(+), 39 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.h 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.h
index 37e2a6bdf409..05da967803af 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.h
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.h
@@ -24,6 +24,11 @@
  CreateDwordField (^BufName, ^MemName._BAS, VarName)  \

  Add (BCM2836_SOC_REGISTERS, Offset, VarName)

  


+// Same as above, but without the base address.

+#define MEMORY32SET(BufName, MemName, VarName, Address)  \

+CreateDwordField (^BufName, ^MemName._BAS, VarName)  \

+Store(Address, VarName)

+

  #define EFI_ACPI_OEM_ID   {'R','P','I','F','D','N'}

  #if (RPI_MODEL == 3)

  #define EFI_ACPI_OEM_TABLE_ID SIGNATURE_64 ('R','P','I','3',' 
',' ',' ',' ')

@@ -113,7 +118,7 @@ typedef struct
  //

  #if (RPI_MODEL == 3)

  #define BCM2836_V3D_BUS_INTERRUPT   0x2A

-#define BCM2836_DMA_INTERRUPT   0x3B

+#define BCM2836_DMA5_INTERRUPT  0x35

  #define BCM2836_SPI1_INTERRUPT  0x3D

  #define BCM2836_SPI2_INTERRUPT  0x3D

  #define BCM2836_HVS_INTERRUPT   0x41

@@ -138,7 +143,8 @@ typedef struct
  #define BCM2836_PL011_UART_INTERRUPT0x59

  #elif (RPI_MODEL == 4)

  #define BCM2836_V3D_BUS_INTERRUPT   0x2A

-#define BCM2836_DMA_INTERRUPT   0x3B

+#define BCM2836_DMA0_INTERRUPT  0x70

+#define BCM2836_DMA5_INTERRUPT  0x75

  #define BCM2836_SPI1_INTERRUPT  0x7D

  #define BCM2836_SPI2_INTERRUPT  0x7D

  #define BCM2836_HVS_INTERRUPT   0x41

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index b594d50bdf8e..fbc0049e6beb 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -139,15 +139,22 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 2, "RPIFDN", "RPI", 
2)
QWORDMEMORYBUF(14)

QWORDMEMORYBUF(15)

// QWORDMEMORYBUF(16)

+#if (RPI_MODEL == 3)

QWORDMEMORYBUF(17)

QWORDMEMORYBUF(18)

QWORDMEMORYBUF(19)

QWORDMEMORYBUF(20)

+#elif (RPI_MODEL == 4)

QWORDMEMORYBUF(21)

QWORDMEMORYBUF(22)

QWORDMEMORYBUF(23)

QWORDMEMORYBUF(24)

+#endif


Assuming we are just aiming for mono on the rpi4, Do we need a separate 
set of buffers here for both the rpi3 and 4, can't the buffers be reused 
below?




QWORDMEMORYBUF(25)

+  QWORDMEMORYBUF(26)

+  QWORDMEMORYBUF(27)

+  QWORDMEMORYBUF(28)

+  QWORDMEMORYBUF(29)

  })

  


  // USB

@@ -181,19 +188,28 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 2, "RPIFDN", "RPI", 
2)
  // QWORDMEMORYSET(16, BCM2836_SPI2_OFFSET, BCM2836_SPI2_LENGTH)

  


  // PWM

-QWORDMEMORYSET(17, BCM2836_PWM_DMA_OFFSET, BCM2836_PWM_DMA_LENGTH)

-QWORDMEMORYSET(18, BCM2836_PWM_CTRL_OFFSET, BCM2836_PWM_CTRL_LENGTH)

-QWORDBUSMEMORYSET(19, BCM2836_PWM_BUS_BASE_ADDRESS, 
BCM2836_PWM_BUS_LENGTH)

-QWORDBUSMEMORYSET(20, BCM2836_PWM_CTRL_UNCACHED_BASE_ADDRESS, 
BCM2836_PWM_CTRL_UNCACHED_LENGTH)

-QWORDMEMORYSET(21, BCM2836_PWM_CLK_OFFSET, BCM2836_PWM_CLK_LENGTH)

+#if (RPI_MODEL == 3)

+QWORDMEMORYSET(17, BCM2836_DMA5_OFFSET, BCM2836_DMA_CHANNEL_LENGTH)

+QWORDMEMORYSET(18, BCM2836_PWM0_CTRL_OFFSET, BCM2836_PWM_CTRL_LENGTH)

+QWORDBUSMEMORYSET(19, BCM2836_PWM0_CTRL_BUS_BASE_ADDRESS, 
BCM2836_PWM_CTRL_LENGTH)

+QWORDBUSMEMORYSET(20, BCM2836_DMA_DEVICE_OFFSET, 1)

+#elif (RPI_MODEL == 4)

+QWORDMEMORYSET(21, BCM2836_DMA0_OFFSET, BCM2836_DMA_CHANNEL_LENGTH)

+QWORDMEMORYSET(22, BCM2836_PWM1_CTRL_OFFSET, BCM2836_PWM_CTRL_LENGTH)

+QWORDBUSMEMORYSET(23, BCM2836_PWM1_CTRL_BUS_BASE_ADDRESS, 

[edk2-devel] [PATCH 4/4] Platform/RaspberryPi: Add menu item to enable/disable GPIO

2021-11-11 Thread Jeremy Linton
Now that the GPIO devices are in their own SSDT lets add
a menu item for the rpi4 to enable/disable it. For the
rpi3 the SSDT is always exported.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 17 -
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Include/ConfigVars.h   |  4 
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 8 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index d22ecb3128..794d056dc6 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -308,12 +308,27 @@ SetupVariables (
   }
 
 }
+
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"EnableGpio",
+   ,
+   NULL, , );
+if (EFI_ERROR (Status)) {
+  Status = PcdSet32S (PcdEnableGpio, PcdGet32 (PcdEnableGpio));
+  ASSERT_EFI_ERROR (Status);
+}
+
   } else {
 /*
  * Disable PCIe and XHCI
  */
 Status = PcdSet32S (PcdXhciPci, 0);
 ASSERT_EFI_ERROR (Status);
+/*
+ * Enable GPIO
+ */
+Status = PcdSet32S (PcdEnableGpio, 1);
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (AssetTagVar);
@@ -840,7 +855,7 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
 #endif
   {
 SIGNATURE_64 ('R', 'P', 'I', '3', 'G', 'P', 'I', 'O'),
-0,
+PcdToken(PcdEnableGpio),
 0,
 NULL
   },
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index ff182e831d..1cba4a2a22 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -96,6 +96,7 @@
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
   gRaspberryPiTokenSpaceGuid.PcdXhciReload
+  gRaspberryPiTokenSpaceGuid.PcdEnableGpio
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 8130638876..8fcb6a3949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -67,6 +67,11 @@
 #string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
 #string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
 
+#string STR_ADVANCED_ENABLEGPIO_PROMPT  #language en-US "Export GPIO devices 
to OS"
+#string STR_ADVANCED_ENABLEGPIO_HELP#language en-US "OS can see the GPIO 
device and some low level SPI and I2C interfaces"
+#string STR_ADVANCED_ENABLEGPIO_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_ENABLEGPIO_ENABLE  #language en-US "Enable"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f13b70711d..04eb0a15a2 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -66,6 +66,11 @@ formset
   name  = XhciReload,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_ENABLEGPIO_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = EnableGpio,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -244,6 +249,16 @@ formset
 endoneof;
   endif;
 endif;
+
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
+  oneof varid = EnableGpio.Value,
+prompt  = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_PROMPT),
+help= STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_HELP),
+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_DISABLE), value 
= 0, flags = DEFAULT;
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_ENABLE), value 
= 1, flags = 0;
+  endoneof;
+endif;
 #endif
 string varid = AssetTag.AssetT

[edk2-devel] [PATCH 2/4] Platform/RaspberryPi: Give the user control over the XHCI mailbox

2021-11-11 Thread Jeremy Linton
Its a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets
give users which want to try DT the option of flipping this on/off.

Users that don't want to have to deal with DT, can use ACPI.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 10 ++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c|  4 
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf  |  1 +
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 9 files changed, 50 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 415d99fadb..bdabdec7a5 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -297,6 +297,16 @@ SetupVariables (
 Status = PcdSet32S (PcdXhciPci, 1);
 ASSERT_EFI_ERROR (Status);
   }
+
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciReload",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status)) {
+Status = PcdSet32S (PcdXhciReload, PcdGet32 (PcdXhciReload));
+ASSERT_EFI_ERROR (Status);
+  }
+
 }
   } else {
 /*
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index e6e22ad82e..ff182e831d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -95,6 +95,7 @@
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
+  gRaspberryPiTokenSpaceGuid.PcdXhciReload
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 5ec17072c3..8130638876 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -62,6 +62,11 @@
 #string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
 #string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"
 
+#string STR_ADVANCED_XHCIRELOAD_PROMPT  #language en-US "DT Reload XHCI 
firmware"
+#string STR_ADVANCED_XHCIRELOAD_HELP#language en-US "OS should reload XHCI 
firmware on reset"
+#string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f668b7a553..f13b70711d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -61,6 +61,11 @@ formset
   name  = XhciPci,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_XHCIPCI_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = XhciReload,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -228,6 +233,16 @@ formset
   option text = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PCIE), value = 
1, flags = 0;
 endoneof;
   endif;
+
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+oneof varid = XhciReload.Value,
+  prompt  = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_PROMPT),
+  help= STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_HELP),
+  flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_DISABLE), 
value = 0, flags = DEFAULT;
+  option text = STRING_TOKEN(STR_ADVANCED_XHCIRELOAD_RELOAD), 
value = 1, flags = 0;
+endoneof;
+  endif;
 endif;
 #endif
 string varid = AssetTag.AssetTag,
diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index e72d132b18..7eb1b26b68 100644
--- a/Pl

[edk2-devel] [PATCH 3/4] Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT

2021-11-11 Thread Jeremy Linton
The UEFI firmware uses the GPIO port for the fan and
real soon now the runtime SPI variable store. As such
we need to be able to either isolate those devices from
the OS or we risk clashing with OS's that reconfigure
the GPIO pins. Ideally we would just rip this out
and use _DSM() or just individual device power
on/off methods to adjust the GPIO pins when needed.

For now, lets leave it since windows at least knows
about it. In the future we will decide whether the
firmware is controlling something (SPI!) based on
whether the user has enabled the GPIO block.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 125 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl   | 157 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   6 +
 5 files changed, 164 insertions(+), 132 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index da2a6db85f..3894d00565 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -40,6 +40,7 @@
   SsdtThermal.asl
   Xhci.asl
   Pci.asl
+  SsdtGpio.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index b594d50bdf..08acc81d57 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -21,13 +21,6 @@
 
 #include "AcpiTables.h"
 
-#define BCM_ALT0 0x4
-#define BCM_ALT1 0x5
-#define BCM_ALT2 0x6
-#define BCM_ALT3 0x7
-#define BCM_ALT4 0x3
-#define BCM_ALT5 0x2
-
 //
 // The ASL compiler does not support argument arithmetic in functions
 // like QWordMemory (). So we need to instantiate dummy qword regions
diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl 
b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
index 9750dc25c0..b1fd5a1387 100644
--- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
+++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl
@@ -203,56 +203,6 @@ Device (VCSM)
   }
 }
 
-// Description: GPIO
-Device (GPI0)
-{
-  Name (_HID, "BCM2845")
-  Name (_CID, "BCM2845")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, GPIO_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared)
-{
-  BCM2386_GPIO_INTERRUPT0, BCM2386_GPIO_INTERRUPT1,
-  BCM2386_GPIO_INTERRUPT2, BCM2386_GPIO_INTERRUPT3
-}
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, GPIO_OFFSET)
-Return (^RBUF)
-  }
-}
-
-// Description: I2C
-Device (I2C1)
-{
-  Name (_HID, "BCM2841")
-  Name (_CID, "BCM2841")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return(0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_I2C1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_I2C1_INTERRUPT }
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 2, 3 }
-  })
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_I2C1_OFFSET)
-Return (^RBUF)
-  }
-}
 
 // I2C2 is the HDMI DDC connection
 Device (I2C2)
@@ -278,81 +228,6 @@ Device (I2C2)
   }
 }
 
-// SPI
-Device (SPI0)
-{
-  Name (_HID, "BCM2838")
-  Name (_CID, "BCM2838")
-  Name (_UID, 0x0)
-  Name (_CCA, 0x0)
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI0_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared) { 
BCM2836_SPI0_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 9, 10, 11 } // MISO, MOSI, SCLK
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 8 } // CE0
-PinFunction (Exclusive, PullUp, BCM_ALT0, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 7 } // CE1
-  })
-
-  Method (_CRS, 0x0, Serialized)
-  {
-MEMORY32SETBASE (RBUF, RMEM, RBAS, BCM2836_SPI0_OFFSET)
-Return (^RBUF)
-  }
-}
-
-Device (SPI1)
-{
-  Name (_HID, "BCM2839")
-  Name (_CID, "BCM2839")
-  Name (_UID, 0x1)
-  Name (_CCA, 0x0)
-  Name (_DEP, Package() { \_SB.GDV0.RPIQ })
-  Method (_STA)
-  {
-Return (0xf)
-  }
-  Name (RBUF, ResourceTemplate ()
-  {
-MEMORY32FIXED (ReadWrite, 0, BCM2836_SPI1_LENGTH, RMEM)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Shared,) { 
BCM2836_SPI1_INTERRUPT }
-PinFunction (Exclusive, PullDown, BCM_ALT4, "\\_SB.GDV0.GPI0", 0, 
ResourceConsumer, , ) { 

[edk2-devel] [PATCH 1/4] Platform/RaspberryPi: Cleanup menu visibility

2021-11-11 Thread Jeremy Linton
Lets allow some of these options to change when the
system is in ACPI+DT mode. Plus the fan temp should
be disabled when ACPI isn't enabled.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index e8bf16312d..f668b7a553 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -196,7 +196,7 @@ formset
 endoneof;
 
 #if (RPI_MODEL == 4)
-grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   oneof varid = FanOnGpio.Enabled,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANONGPIO_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANONGPIO_HELP),
@@ -207,7 +207,7 @@ formset
   endoneof;
 endif;
 
-grayoutif ideqval FanOnGpio.Enabled == 0;
+grayoutif ideqval FanOnGpio.Enabled == 0 OR ideqval 
SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
   numeric varid = FanTemp.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_FANTEMP_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_FANTEMP_HELP),
@@ -219,7 +219,7 @@ formset
 endif;
 
 suppressif ideqval XhciPci.Value == 2;
-  grayoutif NOT ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_ACPI;
+  grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
 oneof varid = XhciPci.Value,
   prompt  = STRING_TOKEN(STR_ADVANCED_XHCIPCI_PROMPT),
   help= STRING_TOKEN(STR_ADVANCED_XHCIPCI_HELP),
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83636): https://edk2.groups.io/g/devel/message/83636
Mute This Topic: https://groups.io/mt/86979573/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Add menu item to enable/disable GPIO

2021-11-11 Thread Jeremy Linton
Now that the GPIO devices are in their own SSDT lets add
a menu item for the rpi4 to enable/disable it. For the
rpi3 the SSDT is always exported.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c  | 17 -
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 15 +++
 Platform/RaspberryPi/Include/ConfigVars.h   |  4 
 Platform/RaspberryPi/RPi3/RPi3.dsc  |  6 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc  |  7 +++
 Platform/RaspberryPi/RaspberryPi.dec|  1 +
 8 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index d22ecb3128..794d056dc6 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -308,12 +308,27 @@ SetupVariables (
   }
 
 }
+
+Size = sizeof (UINT32);
+Status = gRT->GetVariable (L"EnableGpio",
+   ,
+   NULL, , );
+if (EFI_ERROR (Status)) {
+  Status = PcdSet32S (PcdEnableGpio, PcdGet32 (PcdEnableGpio));
+  ASSERT_EFI_ERROR (Status);
+}
+
   } else {
 /*
  * Disable PCIe and XHCI
  */
 Status = PcdSet32S (PcdXhciPci, 0);
 ASSERT_EFI_ERROR (Status);
+/*
+ * Enable GPIO
+ */
+Status = PcdSet32S (PcdEnableGpio, 1);
+ASSERT_EFI_ERROR (Status);
   }
 
   Size = sizeof (AssetTagVar);
@@ -840,7 +855,7 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
 #endif
   {
 SIGNATURE_64 ('R', 'P', 'I', '3', 'G', 'P', 'I', 'O'),
-0,
+PcdToken(PcdEnableGpio),
 0,
 NULL
   },
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index ff182e831d..1cba4a2a22 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -96,6 +96,7 @@
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
   gRaspberryPiTokenSpaceGuid.PcdXhciPci
   gRaspberryPiTokenSpaceGuid.PcdXhciReload
+  gRaspberryPiTokenSpaceGuid.PcdEnableGpio
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 8130638876..8fcb6a3949 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -67,6 +67,11 @@
 #string STR_ADVANCED_XHCIRELOAD_DISABLE #language en-US "Disabled"
 #string STR_ADVANCED_XHCIRELOAD_RELOAD  #language en-US "Reload"
 
+#string STR_ADVANCED_ENABLEGPIO_PROMPT  #language en-US "Export GPIO devices 
to OS"
+#string STR_ADVANCED_ENABLEGPIO_HELP#language en-US "OS can see the GPIO 
device and some low level SPI and I2C interfaces"
+#string STR_ADVANCED_ENABLEGPIO_DISABLE #language en-US "Disabled"
+#string STR_ADVANCED_ENABLEGPIO_ENABLE  #language en-US "Enable"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index f13b70711d..04eb0a15a2 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -66,6 +66,11 @@ formset
   name  = XhciReload,
   guid  = CONFIGDXE_FORM_SET_GUID;
 
+efivarstore ADVANCED_ENABLEGPIO_VARSTORE_DATA,
+  attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
+  name  = EnableGpio,
+  guid  = CONFIGDXE_FORM_SET_GUID;
+
 efivarstore SYSTEM_TABLE_MODE_VARSTORE_DATA,
   attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE,
   name  = SystemTableMode,
@@ -244,6 +249,16 @@ formset
 endoneof;
   endif;
 endif;
+
+grayoutif ideqval SystemTableMode.Mode == SYSTEM_TABLE_MODE_DT;
+  oneof varid = EnableGpio.Value,
+prompt  = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_PROMPT),
+help= STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_HELP),
+flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_DISABLE), value 
= 0, flags = DEFAULT;
+option text = STRING_TOKEN(STR_ADVANCED_ENABLEGPIO_ENABLE), value 
= 1, flags = 0;
+  endoneof;
+endif;
 #endif
 string varid = AssetTag.AssetT

[edk2-devel] [PATCH 0/4] Platform/RaspberryPi: new GPIO and DT menu items

2021-11-11 Thread Jeremy Linton
Its been reported that some kernel versions still need the XHCI reload
while others only work if the reload isn't present. Lets give the user
the ability to control that for DT systems.

Further, there is now an example persistent variable store implementation
that uses the on-board SPI flash rather than trying to rewrite the UEFI
firmware image on SD/etc late in the boot cycle. The problem is that
we now need to control the GPIO pin mux. This isn't a problem for
Linux as such, because it only messes with the pin mux under DT, but
windows has some drivers which export the GPIO devices using the
ACPI definition. Lets add a menu item to enable the GPIO and default
it to off on the RPi4 under the assumption that we can't fix a GPIO
pin mux war reliably and instead will simply revert to a mode that
fails to persist variables written while the OS is active if the
GPIO is enabled.

This set also cleans up the ACPI/DT visiblity of a couple
nearby menu items as well.

Jeremy Linton (4):
  Platform/RaspberryPi: Cleanup menu visibility
  Platform/RaspberryPi: Give the user control over the XHCI mailbox
  Platform/RaspberryPi: Move GPIO/SPI/I2C to SSDT
  Platform/RaspberryPi: Add menu item to enable/disable GPIO

 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   7 -
 Platform/RaspberryPi/AcpiTables/GpuDevs.asl| 125 
 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl   | 157 +
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  31 
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|   2 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  10 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |  36 -
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |   4 +
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.inf |   1 +
 Platform/RaspberryPi/Include/ConfigVars.h  |   4 +
 Platform/RaspberryPi/RPi3/RPi3.dsc |  12 ++
 Platform/RaspberryPi/RPi4/RPi4.dsc |  14 ++
 Platform/RaspberryPi/RaspberryPi.dec   |   2 +
 14 files changed, 271 insertions(+), 135 deletions(-)
 create mode 100644 Platform/RaspberryPi/AcpiTables/SsdtGpio.asl

-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#83634): https://edk2.groups.io/g/devel/message/83634
Mute This Topic: https://groups.io/mt/86979571/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 5/5] Platform/RaspberryPi: Disconnect/shutdown all drivers before reboot

2021-10-18 Thread Jeremy Linton
In theory we should be properly cleaning up all the device drivers before
hitting the big reset. The partition manager will issue flush commands to
attached disks as it goes down. This assures that devices running in WB mode,
which correctly handle flush/sync/etc commands, are persisted to physical
media before reset.

Without this, there are definitely cases where the relevant specifications
don't guarantee persistence of data in their buffers in the face of reset
conditions. We can't really do anything about the many devices that don't
honor persistence requests, but we can start here.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Library/ResetLib/ResetLib.c | 42 
 1 file changed, 42 insertions(+)

diff --git a/Platform/RaspberryPi/Library/ResetLib/ResetLib.c 
b/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
index a70eee485d..2bcef8d4db 100644
--- a/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
+++ b/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
@@ -19,11 +19,51 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include 
 
+
+/**
+  Disconnect everything.
+  Modified from the UEFI 2.3 spec (May 2009 version)
+
+**/
+STATIC
+VOID
+DisconnectAll (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  UINTN HandleCount;
+  EFI_HANDLE *HandleBuffer;
+  UINTN HandleIndex;
+
+  /*
+   * Retrieve the list of all handles from the handle database
+   */
+  Status = gBS->LocateHandleBuffer (
+AllHandles,
+NULL,
+NULL,
+,
+
+   );
+  if (EFI_ERROR (Status)) {
+  return;
+  }
+
+  for (HandleIndex = 0; HandleIndex < HandleCount; HandleIndex++) {
+gBS->DisconnectController (HandleBuffer[HandleIndex], NULL, NULL);
+  }
+
+  gBS->FreePool(HandleBuffer);
+}
+
+
 /**
   Resets the entire platform.
 
@@ -53,6 +93,8 @@ LibResetSystem (
  */
 EfiEventGroupSignal ();
 
+DisconnectAll ();
+
 Delay = PcdGet32 (PcdPlatformResetDelay);
 if (Delay != 0) {
   DEBUG ((DEBUG_INFO, "Platform will be reset in %d.%d seconds...\n",
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82254): https://edk2.groups.io/g/devel/message/82254
Mute This Topic: https://groups.io/mt/86424965/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 4/5] Platform/RaspberryPi: Normal memory should not be marked as uncached

2021-10-18 Thread Jeremy Linton
The efi spec seems to indicate that the efi uncacheable attribute
should be mapped to device memory rather than normal-nc. This means
that the uefi mem attribute for the >3G ram doesn't match the remainder
of the RAM in the machine.

So, lets remove the uncacheable attribute to make it more consistent.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 2ef7da67bd..415d99fadb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -499,7 +499,7 @@ ApplyVariables (
 
 Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, 3UL * BASE_1GB,
 SystemMemorySizeBelow4GB - (3UL * SIZE_1GB),
-EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
EFI_MEMORY_WB);
+EFI_MEMORY_WC | EFI_MEMORY_WT | EFI_MEMORY_WB);
 ASSERT_EFI_ERROR (Status);
 Status = gDS->SetMemorySpaceAttributes (3UL * BASE_1GB,
 SystemMemorySizeBelow4GB - (3UL * SIZE_1GB), 
EFI_MEMORY_WB);
@@ -511,7 +511,7 @@ ApplyVariables (
   //
   Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, 4UL * 
BASE_1GB,
   SystemMemorySize - (4UL * SIZE_1GB),
-  EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
EFI_MEMORY_WB);
+  EFI_MEMORY_WC | EFI_MEMORY_WT | EFI_MEMORY_WB);
   ASSERT_EFI_ERROR (Status);
   Status = gDS->SetMemorySpaceAttributes (4UL * BASE_1GB,
   SystemMemorySize - (4UL * SIZE_1GB), EFI_MEMORY_WB);
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82253): https://edk2.groups.io/g/devel/message/82253
Mute This Topic: https://groups.io/mt/86424964/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 2/5] Platform/RaspberryPi: Fix vfr warning caused by two defaults

2021-10-18 Thread Jeremy Linton
The build has been tossing a warning about having two defaults
for a while now, lets fix it.

Signed-off-by: Jeremy Linton 
Reviewed-by: Andrei Warkentin 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 18b3ec726e..e8bf16312d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -192,7 +192,7 @@ formset
 flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
 option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_ACPI), value = 
SYSTEM_TABLE_MODE_ACPI, flags = 0;
 option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_BOTH), value = 
SYSTEM_TABLE_MODE_BOTH, flags = DEFAULT;
-option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_DT), value = 
SYSTEM_TABLE_MODE_DT, flags = DEFAULT;
+option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_DT), value = 
SYSTEM_TABLE_MODE_DT, flags =0;
 endoneof;
 
 #if (RPI_MODEL == 4)
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82251): https://edk2.groups.io/g/devel/message/82251
Mute This Topic: https://groups.io/mt/86424960/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 3/5] Platform/RaspberryPi: Expand locking to cover return data

2021-10-18 Thread Jeremy Linton
It appears that the locking for many of the mailbox commands is
incorrect. All UEFI firmware calls to the RPi mailbox share a single
mDmaBuffer. That buffer is used to fill out the command passed to the
vc firmware, and record its response. The buffer is protected by
mMailboxLock, yet in many cases the mailbox response is copied from
the buffer after the lock has been released. This doesn't currently
appear to be causing any problems, but should be fixed anyway.

There are a couple other minor tweaks in this patch that are hard to
justify on their own, one is a bit of whitespace cleanup, and the
other is the addition of a debug message to print the returned clock
rate for the requested clock. This latter print would have immediatly
shown that the vc firmware was returning 0 as the emmc clock rate
rather than something reasonable.

Signed-off-by: Jeremy Linton 
Reviewed-by: Andrei Warkentin 
---
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 102 -
 1 file changed, 59 insertions(+), 43 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index bf74148bbb..d38ffbc7d3 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -203,7 +203,6 @@ RpiFirmwareSetPowerState (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
 
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
@@ -219,6 +218,7 @@ RpiFirmwareSetPowerState (
   __FUNCTION__, PowerState ? "en" : "dis", DeviceId));
 Status = EFI_DEVICE_ERROR;
   }
+  ReleaseSpinLock ();
 
   return Status;
 }
@@ -266,18 +266,20 @@ RpiFirmwareGetArmMemory (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
 
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Base = Cmd->TagBody.Base;
   *Size = Cmd->TagBody.Size;
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -323,17 +325,18 @@ RpiFirmwareGetMacAddress (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   CopyMem (MacAddress, Cmd->TagBody.MacAddress, sizeof 
(Cmd->TagBody.MacAddress));
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -378,17 +381,17 @@ RpiFirmwareGetSerial (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Serial = Cmd->TagBody.Serial;
+  ReleaseSpinLock ();
   // Some platforms return 0 or 0x1000 for serial.
   // For those, try to use the MAC address.
   if ((*Serial == 0) || ((*Serial & 0x0FFFULL) == 0)) {
@@ -441,17 +444,18 @@ RpiFirmwareGetModel (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Model = Cmd->TagBody.Model;
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -496,17 +500,18 @@ RpiFirmwareGetModelRevision (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Revision = Cmd->TagBody.Revision;
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -538,17 +543,18 @@ RpiFirmwareGetFirmwareRev

[edk2-devel] [PATCH v2 0/5] Platform/Rpi: Various cleanups + DT booting

2021-10-18 Thread Jeremy Linton
From: Jeremy Linton 

This set is a few patches I've been collecting to fix minor issues I've seen
while debugging other problems, or just various things I think should probably
be changed. It also includes the patch to adjust the PCIe/XHCI dma-attributes
which fixes DT booting on recent Linux kernels as well as OpenBSD.

I've been running all of them in some form or another for a while and
generally nothing has broken because of them AFAIK. So its probably time to
start getting a few of them out of my private tree.

The first patch syncs the DT/PCIe translation to the way its being used in
UEFI, and removes the XHCI reset node. The second is just a compiler
warning. The third is mostly expanding the mailbox lock to cover the return
data.  Number 4 is an odd one because it just looks wrong, and I'm worried its
causing random bugs. The final is a corrected shutdown sequence that was
discussed months ago. It looks right. but didn't actually fix the data
persistence problems that resulted in the couple second reboot delay that is
currently in place.

v1->v2:
Include the DT patch to sync the PCIe/XHCI values
Now that it also fixes a problem with OpenBSD.
Rework the error handling in the DisconnectAll code
borrowed from the UEFI spec.
Adjust some DEBUG_XXX values so they make more sense.
Some comment/changelog grammar. 

Jeremy Linton (5):
  Platform/RaspberryPi: Always use non translating DMA in DT mode
  Platform/RaspberryPi: Fix vfr warning caused by two defaults
  Platform/RaspberryPi: Expand locking to cover return data
  Platform/RaspberryPi: Normal memory should not be marked as uncached
  Platform/RaspberryPi: Disconnect/shutdown all drivers before reboot

 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   4 +-
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |   2 +-
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c   |  75 +++
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 102 -
 Platform/RaspberryPi/Library/ResetLib/ResetLib.c   |  42 +
 5 files changed, 179 insertions(+), 46 deletions(-)

-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82249): https://edk2.groups.io/g/devel/message/82249
Mute This Topic: https://groups.io/mt/86424956/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 1/5] Platform/RaspberryPi: Always use non translating DMA in DT mode

2021-10-18 Thread Jeremy Linton
One of the many issues with the PCIe on this platform is its inbound
DMA is either constrained to the lower 3G, or on later SOC's a
translation may be used. That translation is problematic with some of
the OS's expected to boot on this platform. So, across the board a 3G
DMA limit is enforced during boot when in ACPI mode. This itself
causes problems because the later boards removed the SPI EEPROM used
by the onboard XHCI controller, instead favoring using a block of RAM
to load its firmware. Hence it is the lower level firmware's
responsibility via a mailbox call, to read the bridge
translation/configuration before telling the XHCI controller where it
can find its firmware.

Everything is great in ACPI land. Now it appears that Linux after
reprogramming the bridge to match the DT (when using a translation)
can't actually get the XHCI/quirk/reset to function. Apparently,
because the firmware only reads the bridge configuration the first
time its called(?), or the kernel reset sequence isn't correct. Worse,
with just the DMA ranges corrected, the XHCI/QUIRK itself then causes
the controller to start having what appear to be DMA issues.

Lets simplify the situation and make all DT's provided by this
firmware have a 3G DMA limit on the PCIe bus. Then remove the ability
for Linux/etc to trigger the quirk by remove the DT node attaching the
reset controller to the XHCI. The latter seems somewhat questionable,
since the DT/PCIe host bridge driver is doing what appears to be a
PERST which might then require a firmware reload, but at the
moment seems to work without.

The first part of this patch also appears to fix a problem with
OpenBSD which interprets the DT as describing how the firmware
has configured the device, and makes no attempt to reconfigure it.
Hence the newer SOC's implementing a translation fail to boot
since the DT being passed to the OS doesn't match the translation
the firmware has setup.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 75 
 1 file changed, 75 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index 0472d8ecf6..a4816d4295 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
@@ -334,6 +334,76 @@ CleanSimpleFramebuffer (
   return EFI_SUCCESS;
 }
 
+STATIC
+EFI_STATUS
+SyncPcie (
+  VOID
+  )
+{
+#if (RPI_MODEL == 4)
+  INTN  Node;
+  INTN  Retval;
+  UINT32DmaRanges[7];
+
+  Node = fdt_path_offset (mFdtImage, "pcie0");
+  if (Node < 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to locate 'pcie0' alias\n", 
__FUNCTION__));
+return EFI_NOT_FOUND;
+  }
+
+  // non translated 32-bit DMA window with a limit of 0xc000
+  DmaRanges[0] = cpu_to_fdt32 (0x0200); 
+  DmaRanges[1] = cpu_to_fdt32 (0x); 
+  DmaRanges[2] = cpu_to_fdt32 (0x);
+  DmaRanges[3] = cpu_to_fdt32 (0x);
+  DmaRanges[4] = cpu_to_fdt32 (0x);
+  DmaRanges[5] = cpu_to_fdt32 (0x);
+  DmaRanges[6] = cpu_to_fdt32 (0xc000);
+
+  DEBUG ((DEBUG_INFO, "%a: Updating PCIe dma-ranges\n",  __FUNCTION__));
+
+  /* 
+   * Match dma-ranges with the EDK2+ACPI setup we are using.  This works
+   * around a failure in Linux and OpenBSD to reset the PCIe/XHCI correctly
+   * when in DT mode.
+   */
+  Retval = fdt_setprop (mFdtImage, Node, "dma-ranges",
+DmaRanges,  sizeof DmaRanges);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to locate PCIe 'dma-ranges' property 
(%d)\n",
+  __FUNCTION__, Retval));
+return EFI_NOT_FOUND;
+  }
+
+  /*
+   * Now that we are always running without DMA translation, and with a 3G
+   * limit, there shouldn't be a need to reset/reload the XHCI. The
+   * possible problem is that the PCIe root port is itself being reset (by
+   * Linux+DT). The RPi foundation claims this is needed as a pre-req to
+   * reloading the XHCI firmware, which also implies that a PCI fundamental
+   * reset should cause the XHCI itself to reset.  This isn't happening
+   * fully, otherwise reloading the firmware would be mandatory. As it is,
+   * recent kernels actually start to have problems following the XHCI
+   * reset notification mailbox!  Instead lets stop the kernel from
+   * triggering the mailbox by removing the node.
+   */
+
+  Node = fdt_path_offset (mFdtImage, "/scb/pcie@7d50/pci@1,0");
+  if (Node < 0) {
+// This can happen on CM4/etc which doesn't have an onboard XHCI
+DEBUG ((DEBUG_INFO, "%a: failed to locate 
/scb/pcie@7d50/pci@1/usb@1\n", __FUNCTION__));
+  } else {
+Retval = fdt_del_node (mFdtImage, Node);
+if (Retval != 0) {
+  DEBUG ((DEBUG_ERROR, "Failed to remove 
/scb/pcie@7d50/pci@1/usb@1\n"));
+  return EFI_NOT_FOUND;
+}
+  }
+
+#endif
+  return EFI_SUCCESS;
+}
+
 /**
   @pa

Re: [edk2-devel] [PATCH v1 3/7] ShellPkg: Update Acpiview PPTT parser to ACPI 6.4

2021-10-18 Thread Jeremy Linton

Hi,

On 10/18/21 10:10 AM, Chris Jones via groups.io wrote:

Bugzilla: 3697 (https://bugzilla.tianocore.org/show_bug.cgi?id=3697)

Update the Acpiview PPTT parser to use Acpi64.h. As part of the changes,
remove support for parsing PPTT type 2 ID structure.

Signed-off-by: Chris Jones 
---
  ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c | 
61 
  ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c |  
2 +-
  2 files changed, 12 insertions(+), 51 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
index 
acd2b81bb3258c7322aa10d2c0e0d842d89e358b..bce9edcedde50e53035059e6da57b9449209a674
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
@@ -1,11 +1,11 @@
  /** @file
PPTT table parser
  
-  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.

+  Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.
SPDX-License-Identifier: BSD-2-Clause-Patent
  
@par Reference(s):

-- ACPI 6.3 Specification - January 2019
+- ACPI 6.4 Specification - January 2021
  - ARM Architecture Reference Manual ARMv8 (D.a)
  **/
  
@@ -157,8 +157,8 @@ ValidateCacheAttributes (

)
  {
// Reference: Advanced Configuration and Power Interface (ACPI) 
Specification
-  //Version 6.2 Errata A, September 2017
-  // Table 5-153: Cache Type Structure
+  //Version 6.4, January 2021
+  // Table 5-140: Cache Type Structure
UINT8 Attributes;
Attributes = *(UINT8*)Ptr;
  
@@ -222,22 +222,6 @@ STATIC CONST ACPI_PARSER CacheTypeStructureParser[] = {

{L"Line size", 2, 22, L"%d", NULL, NULL, ValidateCacheLineSize, NULL}
  };
  
-/**

-  An ACPI_PARSER array describing the ID Type Structure - Type 2.
-**/
-STATIC CONST ACPI_PARSER IdStructureParser[] = {
-  {L"Type", 1, 0, L"0x%x", NULL, NULL, NULL, NULL},
-  {L"Length", 1, 1, L"%d", NULL, NULL, NULL, NULL},
-  {L"Reserved", 2, 2, L"0x%x", NULL, NULL, NULL, NULL},
-
-  {L"VENDOR_ID", 4, 4, NULL, Dump4Chars, NULL, NULL, NULL},
-  {L"LEVEL_1_ID", 8, 8, L"0x%x", NULL, NULL, NULL, NULL},
-  {L"LEVEL_2_ID", 8, 16, L"0x%x", NULL, NULL, NULL, NULL},
-  {L"MAJOR_REV", 2, 24, L"0x%x", NULL, NULL, NULL, NULL},
-  {L"MINOR_REV", 2, 26, L"0x%x", NULL, NULL, NULL, NULL},
-  {L"SPIN_REV", 2, 28, L"0x%x", NULL, NULL, NULL, NULL},
-};
-


Don't people compile shellpkg for out of tree machines? Are we 100% sure 
that there aren't any machines in the wild with older PPTT's using this 
structure?


Although, this is less of a problem than below..


  /**
This function parses the Processor Hierarchy Node Structure (Type 0).
  
@@ -335,29 +319,6 @@ DumpCacheTypeStructure (

  );
  }
  
-/**

-  This function parses the ID Structure (Type 2).
-
-  @param [in] Ptr Pointer to the start of the ID Structure data.
-  @param [in] Length  Length of the ID Structure.
-**/
-STATIC
-VOID
-DumpIDStructure (
-  IN UINT8* Ptr,
-  IN UINT8 Length
-  )
-{
-  ParseAcpi (
-TRUE,
-2,
-"ID Structure",
-Ptr,
-Length,
-PARSER_PARAMS (IdStructureParser)
-);
-}
-
  /**
This function parses the ACPI PPTT table.
When trace is enabled this function parses the PPTT table and
@@ -366,7 +327,6 @@ DumpIDStructure (
This function parses the following processor topology structures:
  - Processor hierarchy node structure (Type 0)
  - Cache Type Structure (Type 1)
-- ID structure (Type 2)
  
This function also performs validation of the ACPI table fields.
  
@@ -444,22 +404,23 @@ ParseAcpiPptt (

  Print (L"0x%x\n", Offset);
  
  switch (*ProcessorTopologyStructureType) {

-  case EFI_ACPI_6_2_PPTT_TYPE_PROCESSOR:
+  case EFI_ACPI_6_4_PPTT_TYPE_PROCESSOR:


I suspect this breaks every single other edk2-platforms machine in this 
tree not using the dynamic table generator. AKA all the hardcoded PPTTs 
used on synquacer/rpi/etc. I suspect this code path should be able to 
deal with multiple versions of the spec.



Thanks,


  DumpProcessorHierarchyNodeStructure (
ProcessorTopologyStructurePtr,
*ProcessorTopologyStructureLength
);
  break;
-  case EFI_ACPI_6_2_PPTT_TYPE_CACHE:
+  case EFI_ACPI_6_4_PPTT_TYPE_CACHE:
  DumpCacheTypeStructure (
ProcessorTopologyStructurePtr,
*ProcessorTopologyStructureLength
);
  break;
-  case EFI_ACPI_6_2_PPTT_TYPE_ID:
-DumpIDStructure (
-  ProcessorTopologyStructurePtr,
-  *ProcessorTopologyStructureLength
+  case EFI_ACPI_6_3_PPTT_TYPE_ID:
+IncrementErrorCount ();
+Print (
+  L"ERROR: PPTT Type 2 - Processor ID is deprecated and must not be"
+L"used.\n"
);
  break;
 

Re: [edk2-devel] [PATCH 3/5] Platform/RaspberryPi: Update Linux quirk name

2021-10-14 Thread Jeremy Linton

Hi,


On 10/1/21 7:52 PM, Jeremy Linton wrote:

During review/merge of the linux ecam quirk, some logic
was added to require the quirk name to be exactly 6
characters, matching the MADT field its overriding.

As such, the rpi quirk here needed to be shorted by
a character to avoid confusion.


I'm going to drop this from the v2 of this set because while the 
mainline patch has a bunch of Ack's, its stuck because we are still 
discussing whether a DSD here is the right choice.





Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Pci.asl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Pci.asl 
b/Platform/RaspberryPi/AcpiTables/Pci.asl
index ee37b7a21e..e5fe755923 100644
--- a/Platform/RaspberryPi/AcpiTables/Pci.asl
+++ b/Platform/RaspberryPi/AcpiTables/Pci.asl
@@ -65,7 +65,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4PCIE", 2)
Name (_DSD, Package () {
  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
-Package () { "linux-ecam-quirk-id", "bcm2711" },
+Package () { "linux-ecam-quirk-id", "bc2711" },
}
})
  





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82054): https://edk2.groups.io/g/devel/message/82054
Mute This Topic: https://groups.io/mt/86014863/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH] Platform/RaspberryPi: Remove TypeTranslation attribute

2021-10-14 Thread Jeremy Linton

Hi,

On 10/10/21 4:10 PM, Ard Biesheuvel wrote:

On Sun, 10 Oct 2021 at 21:48, Mark Kettenis  wrote:


The MMIO host bridge window isn't translated as both the primary
and secondary side are MMIO.  So remove the incorrect
TypeTranslation attribute.

Signed-off-by: Mark Kettenis 


Reviewed-by: Ard Biesheuvel 

Pushed as bbb431a0c658..ab6fcc28fd99

Thanks,


---
  Platform/RaspberryPi/AcpiTables/Pci.asl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Pci.asl 
b/Platform/RaspberryPi/AcpiTables/Pci.asl
index ee37b7a21e..f485c6b5d2 100644
--- a/Platform/RaspberryPi/AcpiTables/Pci.asl
+++ b/Platform/RaspberryPi/AcpiTables/Pci.asl
@@ -94,7 +94,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4PCIE", 2)
  1,  // SANITIZED_PCIE_MMIO_LEN + 
SANITIZED_PCIE_PCI_MMIO_BEGIN
  SANITIZED_PCIE_CPU_MMIO_WINDOW, // SANITIZED_PCIE_PCI_MMIO_BEGIN 
- SANITIZED_PCIE_CPU_MMIO_WINDOW
  2   // SANITIZED_PCIE_MMIO_LEN + 1
-,,,MMI1,,TypeTranslation
+,,,MMI1
)


Its a bit late, but this looks fine.

THanks!



// root port registers, not to be used if SMCCC is utilized
--
2.33.0




Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81734): https://edk2.groups.io/g/devel/message/81734
Mute This Topic: https://groups.io/mt/86221449/1131722
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [a...@kernel.org]







-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#82053): https://edk2.groups.io/g/devel/message/82053
Mute This Topic: https://groups.io/mt/86221449/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH 5/5] Platform/RaspberryPi: Disconnect/shutdown all drivers before reboot

2021-10-05 Thread Jeremy Linton

Hi,

On 10/5/21 5:11 AM, Ard Biesheuvel wrote:

On Sat, 2 Oct 2021 at 02:52, Jeremy Linton  wrote:


In theory we should be properly cleaning up all the device drivers before
pulling the big switch. Particularly the partition mgr will issue
flush commands to attached disks as it goes down. This assures that
devices running in WB mode (that correctly handle flush/sync/etc) commands
are persisted to physical media before we hit reset.

Without this, there are definitly cases where the relevant specifications
don't guarantee persistence of data in their buffers in the face of
reset conditions. We can't really do anything about the many
devices that don't honor persistance requests but we can start here.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/Library/ResetLib/ResetLib.c | 44 
  1 file changed, 44 insertions(+)

diff --git a/Platform/RaspberryPi/Library/ResetLib/ResetLib.c 
b/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
index a70eee485d..036f619cb5 100644
--- a/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
+++ b/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
@@ -19,11 +19,54 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

  #include 

+
+/**
+  Disconnect everything.
+  Modified from the UEFI 2.3 spec (May 2009 version)
+
+  @retval EFI_SUCCESS The operation was successful.
+
+**/


STATIC


+EFI_STATUS
+DisconnectAll(


Space before (


+  VOID
+  )
+{
+  EFI_STATUS Status;
+  UINTN HandleCount;
+  EFI_HANDLE *HandleBuffer;
+  UINTN HandleIndex;
+
+  //
+  // Retrieve the list of all handles from the handle database
+  //
+  Status = gBS->LocateHandleBuffer (
+AllHandles,
+NULL,
+NULL,
+,
+
+   );
+  if (!EFI_ERROR (Status)) {


I understand that this code is copy/pasted but I'd still prefer to
avoid the 'success handling' anti pattern here.


Sure.



if (EFI_ERROR (Status)) {
   return Status;
}


+for (HandleIndex = 0; HandleIndex < HandleCount; HandleIndex++) {
+  Status = gBS->DisconnectController (
+HandleBuffer[HandleIndex],
+NULL,
+NULL
+   );
+}
+gBS->FreePool(HandleBuffer);
+  }
+  return (EFI_SUCCESS);


No need for ()


Yup




+}
+
+
  /**
Resets the entire platform.

@@ -57,6 +100,7 @@ LibResetSystem (
  if (Delay != 0) {
DEBUG ((DEBUG_INFO, "Platform will be reset in %d.%d seconds...\n",
Delay / 100, (Delay % 100) / 10));
+  DisconnectAll ();


Capture Status here and ASSERT_EFI_ERROR() ??

Maybe it is overkill, and maybe DisconnectController() fails
spuriously, so I am not entirely sure, but adding a local function
that returns a value and then ignore it seems slightly sloppy to me.


Which makes the above bits about failure returns sorta redundant as I 
should probably just make DisconnectAll() void. There isn't really 
anything to do with a failed return other than print a message and 
ignore it.






MicroSecondDelay (Delay);
  }
}
--
2.13.7





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81522): https://edk2.groups.io/g/devel/message/81522
Mute This Topic: https://groups.io/mt/86014865/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




Re: [edk2-devel] [PATCH 2/5] Platform/RaspberryPi: Expand locking to cover return data

2021-10-05 Thread Jeremy Linton

Hi,

On 10/5/21 5:12 AM, Ard Biesheuvel wrote:

On Sat, 2 Oct 2021 at 02:52, Jeremy Linton  wrote:


While debugging problems with the GET/SET_CLOCK mailbox calls it appeared
that the locking in most of the mailbox commands isn't perfectly
correct. All UEFI firmware calls to the RPi mailbox share a single
mDmaBuffer which is used to fill out the command passed to the vc firmware,
and record its response. The buffer is protected by mMailboxLock, yet in
many cases the result of the request is copied from the buffer after the
lock has been released. This doesn't currently appear to be causing any
problems, but should probably be fixed anyway.

There are a couple other minor tweaks in this patch that are hard to
justify on their own, one is a bit of whitespace cleanup, and the other is
the addition of a debug message to print the returned clock rate for the
requested clock. This latter print would have immediatly shown that the vc
firmware was returning 0 as the emmc clock rate rather than something
reasonable.

Signed-off-by: Jeremy Linton 


This fails to apply for me - can you rebase onto the last
edk2-platform master please?


Sure. Is it whitespace, or general conflicts? I noticed that groups.io's 
web UI looked like I had MIME linebreaks sprinked through my patch 
despite specifying 8bit ASCII. I flirted with 7-bit ASCII with some of 
the previous patches, but its pretty clear that the arm foss server is 
mangling what it thinks are MIME emails and putting cr/lf's changes its 
behavior a bit.



Let me try and force the 7bit again, which git rejects if it finds utf 
in the files (and a few of them had it in the past ).






---
  .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 102 -
  1 file changed, 59 insertions(+), 43 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index bf74148bbb..29719aa5ec 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -203,7 +203,6 @@ RpiFirmwareSetPowerState (

Status = MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_VC_CHANNEL, 
);

-  ReleaseSpinLock ();

if (EFI_ERROR (Status) ||
Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
@@ -219,6 +218,7 @@ RpiFirmwareSetPowerState (
__FUNCTION__, PowerState ? "en" : "dis", DeviceId));
  Status = EFI_DEVICE_ERROR;
}
+  ReleaseSpinLock ();

return Status;
  }
@@ -266,18 +266,20 @@ RpiFirmwareGetArmMemory (

Status = MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_VC_CHANNEL, 
);

-  ReleaseSpinLock ();

if (EFI_ERROR (Status) ||
Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
  DEBUG ((DEBUG_ERROR,
"%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
__FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
  return EFI_DEVICE_ERROR;
}

*Base = Cmd->TagBody.Base;
*Size = Cmd->TagBody.Size;
+  ReleaseSpinLock ();
+
return EFI_SUCCESS;
  }

@@ -323,17 +325,18 @@ RpiFirmwareGetMacAddress (

Status = MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_VC_CHANNEL, 
);

-  ReleaseSpinLock ();
-
if (EFI_ERROR (Status) ||
Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
  DEBUG ((DEBUG_ERROR,
"%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
__FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
  return EFI_DEVICE_ERROR;
}

CopyMem (MacAddress, Cmd->TagBody.MacAddress, sizeof 
(Cmd->TagBody.MacAddress));
+  ReleaseSpinLock ();
+
return EFI_SUCCESS;
  }

@@ -378,17 +381,17 @@ RpiFirmwareGetSerial (

Status = MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_VC_CHANNEL, 
);

-  ReleaseSpinLock ();
-
if (EFI_ERROR (Status) ||
Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
  DEBUG ((DEBUG_ERROR,
"%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
__FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
  return EFI_DEVICE_ERROR;
}

*Serial = Cmd->TagBody.Serial;
+  ReleaseSpinLock ();
// Some platforms return 0 or 0x1000 for serial.
// For those, try to use the MAC address.
if ((*Serial == 0) || ((*Serial & 0x0FFFULL) == 0)) {
@@ -441,17 +444,18 @@ RpiFirmwareGetModel (

Status = MailboxTransaction (Cmd->BufferHead.BufferSize, RPI_MBOX_VC_CHANNEL, 
);

-  ReleaseSpinLock ();
-
if (EFI_ERROR (Status) ||
Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
  DEBUG ((DEBUG_ERROR,
"%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
__FUNCTION__, Status, Cmd->BufferHead.Respo

[edk2-devel] [PATCH 5/5] Platform/RaspberryPi: Disconnect/shutdown all drivers before reboot

2021-10-01 Thread Jeremy Linton
In theory we should be properly cleaning up all the device drivers before
pulling the big switch. Particularly the partition mgr will issue
flush commands to attached disks as it goes down. This assures that
devices running in WB mode (that correctly handle flush/sync/etc) commands
are persisted to physical media before we hit reset.

Without this, there are definitly cases where the relevant specifications
don't guarantee persistence of data in their buffers in the face of
reset conditions. We can't really do anything about the many
devices that don't honor persistance requests but we can start here.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Library/ResetLib/ResetLib.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/Platform/RaspberryPi/Library/ResetLib/ResetLib.c 
b/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
index a70eee485d..036f619cb5 100644
--- a/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
+++ b/Platform/RaspberryPi/Library/ResetLib/ResetLib.c
@@ -19,11 +19,54 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include 
 
+
+/**
+  Disconnect everything.
+  Modified from the UEFI 2.3 spec (May 2009 version)
+
+  @retval EFI_SUCCESS The operation was successful.
+
+**/
+EFI_STATUS
+DisconnectAll(
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  UINTN HandleCount;
+  EFI_HANDLE *HandleBuffer;
+  UINTN HandleIndex;
+
+  //
+  // Retrieve the list of all handles from the handle database
+  //
+  Status = gBS->LocateHandleBuffer (
+AllHandles,
+NULL,
+NULL,
+,
+
+   );
+  if (!EFI_ERROR (Status)) {
+for (HandleIndex = 0; HandleIndex < HandleCount; HandleIndex++) {
+  Status = gBS->DisconnectController (
+HandleBuffer[HandleIndex],
+NULL,
+NULL
+   );
+}
+gBS->FreePool(HandleBuffer);
+  }
+  return (EFI_SUCCESS);
+}
+
+
 /**
   Resets the entire platform.
 
@@ -57,6 +100,7 @@ LibResetSystem (
 if (Delay != 0) {
   DEBUG ((DEBUG_INFO, "Platform will be reset in %d.%d seconds...\n",
   Delay / 100, (Delay % 100) / 10));
+  DisconnectAll ();
   MicroSecondDelay (Delay);
 }
   }
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81381): https://edk2.groups.io/g/devel/message/81381
Mute This Topic: https://groups.io/mt/86014865/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 4/5] Platform/RaspberryPi: Normal memory should not be marked as uncached

2021-10-01 Thread Jeremy Linton
The efi spec seems to indicate that the efi uncacheable attribute
should be mapped to device memory rather than normal-nc. This means
that the uefi mem attribute for the >3G ram doesn't match the remainder
of the RAM in the machine.

So, lets remove the uncacheable attribute to make it more consistent.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 2ef7da67bd..415d99fadb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -499,7 +499,7 @@ ApplyVariables (
 
 Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, 3UL * BASE_1GB,
 SystemMemorySizeBelow4GB - (3UL * SIZE_1GB),
-EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
EFI_MEMORY_WB);
+EFI_MEMORY_WC | EFI_MEMORY_WT | EFI_MEMORY_WB);
 ASSERT_EFI_ERROR (Status);
 Status = gDS->SetMemorySpaceAttributes (3UL * BASE_1GB,
 SystemMemorySizeBelow4GB - (3UL * SIZE_1GB), 
EFI_MEMORY_WB);
@@ -511,7 +511,7 @@ ApplyVariables (
   //
   Status = gDS->AddMemorySpace (EfiGcdMemoryTypeSystemMemory, 4UL * 
BASE_1GB,
   SystemMemorySize - (4UL * SIZE_1GB),
-  EFI_MEMORY_UC | EFI_MEMORY_WC | EFI_MEMORY_WT | 
EFI_MEMORY_WB);
+  EFI_MEMORY_WC | EFI_MEMORY_WT | EFI_MEMORY_WB);
   ASSERT_EFI_ERROR (Status);
   Status = gDS->SetMemorySpaceAttributes (4UL * BASE_1GB,
   SystemMemorySize - (4UL * SIZE_1GB), EFI_MEMORY_WB);
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81380): https://edk2.groups.io/g/devel/message/81380
Mute This Topic: https://groups.io/mt/86014864/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 3/5] Platform/RaspberryPi: Update Linux quirk name

2021-10-01 Thread Jeremy Linton
During review/merge of the linux ecam quirk, some logic
was added to require the quirk name to be exactly 6
characters, matching the MADT field its overriding.

As such, the rpi quirk here needed to be shorted by
a character to avoid confusion.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/AcpiTables/Pci.asl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Pci.asl 
b/Platform/RaspberryPi/AcpiTables/Pci.asl
index ee37b7a21e..e5fe755923 100644
--- a/Platform/RaspberryPi/AcpiTables/Pci.asl
+++ b/Platform/RaspberryPi/AcpiTables/Pci.asl
@@ -65,7 +65,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4PCIE", 2)
   Name (_DSD, Package () {
 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
   Package () {
-Package () { "linux-ecam-quirk-id", "bcm2711" },
+Package () { "linux-ecam-quirk-id", "bc2711" },
   }
   })
 
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81379): https://edk2.groups.io/g/devel/message/81379
Mute This Topic: https://groups.io/mt/86014863/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 1/5] Platform/RaspberryPi: Fix vfr warning caused by two defaults

2021-10-01 Thread Jeremy Linton
The build has been tossing a warning about having two defaults
for a while now, lets fix it.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index 18b3ec726e..e8bf16312d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
@@ -192,7 +192,7 @@ formset
 flags   = NUMERIC_SIZE_4 | INTERACTIVE | RESET_REQUIRED,
 option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_ACPI), value = 
SYSTEM_TABLE_MODE_ACPI, flags = 0;
 option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_BOTH), value = 
SYSTEM_TABLE_MODE_BOTH, flags = DEFAULT;
-option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_DT), value = 
SYSTEM_TABLE_MODE_DT, flags = DEFAULT;
+option text = STRING_TOKEN(STR_ADVANCED_SYSTAB_DT), value = 
SYSTEM_TABLE_MODE_DT, flags =0;
 endoneof;
 
 #if (RPI_MODEL == 4)
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81377): https://edk2.groups.io/g/devel/message/81377
Mute This Topic: https://groups.io/mt/86014861/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH 2/5] Platform/RaspberryPi: Expand locking to cover return data

2021-10-01 Thread Jeremy Linton
While debugging problems with the GET/SET_CLOCK mailbox calls it appeared
that the locking in most of the mailbox commands isn't perfectly
correct. All UEFI firmware calls to the RPi mailbox share a single
mDmaBuffer which is used to fill out the command passed to the vc firmware,
and record its response. The buffer is protected by mMailboxLock, yet in
many cases the result of the request is copied from the buffer after the
lock has been released. This doesn't currently appear to be causing any
problems, but should probably be fixed anyway.

There are a couple other minor tweaks in this patch that are hard to
justify on their own, one is a bit of whitespace cleanup, and the other is
the addition of a debug message to print the returned clock rate for the
requested clock. This latter print would have immediatly shown that the vc
firmware was returning 0 as the emmc clock rate rather than something
reasonable.

Signed-off-by: Jeremy Linton 
---
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 102 -
 1 file changed, 59 insertions(+), 43 deletions(-)

diff --git a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c 
b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
index bf74148bbb..29719aa5ec 100644
--- a/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
+++ b/Platform/RaspberryPi/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c
@@ -203,7 +203,6 @@ RpiFirmwareSetPowerState (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
 
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
@@ -219,6 +218,7 @@ RpiFirmwareSetPowerState (
   __FUNCTION__, PowerState ? "en" : "dis", DeviceId));
 Status = EFI_DEVICE_ERROR;
   }
+  ReleaseSpinLock ();
 
   return Status;
 }
@@ -266,18 +266,20 @@ RpiFirmwareGetArmMemory (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
 
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Base = Cmd->TagBody.Base;
   *Size = Cmd->TagBody.Size;
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -323,17 +325,18 @@ RpiFirmwareGetMacAddress (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   CopyMem (MacAddress, Cmd->TagBody.MacAddress, sizeof 
(Cmd->TagBody.MacAddress));
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -378,17 +381,17 @@ RpiFirmwareGetSerial (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Serial = Cmd->TagBody.Serial;
+  ReleaseSpinLock ();
   // Some platforms return 0 or 0x1000 for serial.
   // For those, try to use the MAC address.
   if ((*Serial == 0) || ((*Serial & 0x0FFFULL) == 0)) {
@@ -441,17 +444,18 @@ RpiFirmwareGetModel (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Model = Cmd->TagBody.Model;
+  ReleaseSpinLock ();
+
   return EFI_SUCCESS;
 }
 
@@ -496,17 +500,18 @@ RpiFirmwareGetModelRevision (
 
   Status = MailboxTransaction (Cmd->BufferHead.BufferSize, 
RPI_MBOX_VC_CHANNEL, );
 
-  ReleaseSpinLock ();
-
   if (EFI_ERROR (Status) ||
   Cmd->BufferHead.Response != RPI_MBOX_RESP_SUCCESS) {
 DEBUG ((DEBUG_ERROR,
   "%a: mailbox transaction error: Status == %r, Response == 0x%x\n",
   __FUNCTION__, Status, Cmd->BufferHead.Response));
+ReleaseSpinLock ();
 return EFI_DEVICE_ERROR;
   }
 
   *Revision = Cmd->TagBody.Revision;
+  ReleaseSpinLock ();
+
   return EFI_SUCCE

[edk2-devel] [PATCH 0/5] Platform/Rpi: Various cleanups

2021-10-01 Thread Jeremy Linton
This set is a few patches I've been collecting to fix minor issues I've seen
while debugging other problems, or just various things I think should probably
be changed. Generally I don't think they fix anything that is currently user
visible, although its quite possible some mysterious failures go away.

I've been running all of them in some form or another for a few months and
generally nothing has broken because of them AFAIK. So its probably time to
start getting a few of them out of my private tree.

The first is just a compiler warning. The second is mostly expanding the
mailbox lock to cover the return data. The third is an update to make the
hopefully merged soon CM4 quirk actually work with the patches currently on
LKML. Number 4 is an odd one because it just looks wrong, and I'm worried its
causing random bugs. The final is a corrected shutdown sequence that was
discussed months ago. It looks right. but didn't actually fix the data
persistence problems that resulted in the couple second reboot delay
that is currently in place.

Jeremy Linton (5):
  Platform/RaspberryPi: Fix vfr warning caused by two defaults
  Platform/RaspberryPi: Expand locking to cover return data
  Platform/RaspberryPi: Update Linux quirk name
  Platform/RaspberryPi: Normal memory should not be marked as uncached
  Platform/RaspberryPi: Disconnect/shutdown all drivers before reboot

 Platform/RaspberryPi/AcpiTables/Pci.asl|   2 +-
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |   4 +-
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |   2 +-
 .../Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c| 102 -
 Platform/RaspberryPi/Library/ResetLib/ResetLib.c   |  44 +
 5 files changed, 107 insertions(+), 47 deletions(-)

-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81376): https://edk2.groups.io/g/devel/message/81376
Mute This Topic: https://groups.io/mt/86014860/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v2 1/1] Platform/RaspberryPi: Always use non translating DMA in DT mode

2021-10-01 Thread Jeremy Linton
One of the many issues with the PCIe on this platform is
its inbound DMA is either constrained to the lower 3G, or
on later SoC's a translation can be used. That translation
was problematic with some of the OS's expected to boot
on this platform. So, across the board a 3G DMA limit is
enforced during boot. This itself causes problems because
the later boards removed the SPI EEPROM used by the onboard
XHCI controller, instead favoring using a block of RAM to
load its firmware. Hence it is the lower level firmware's
responsibility via a mailbox call, to read the bridge
translation/configuration before telling the XHCI controller
where it can find its firmware.

Everything is great, except that it appears that Linux
after reprogramming the bridge to match the DT (when using
a translation) can't actually get the XHCI/quirk/reset to
function. Apparently, because the firmware only reads the
bridge configuration the first time its called(?). Worse
with just the DMA ranges corrected, the XHCI/QUIRK itself
then causes the controller to start having what appear
to be DMA issues.

So again, simplify the situation and make all DT's
provided by this firmware have a 3G DMA limit on the
PCIe bus. Then remove the ability for linux/etc to
trigger the quirk by remove the DT node attaching the
reset controller to the XHCI. The latter seems somewhat
questionable, since the DT/PCIe host bridge driver is
doing what appears to be a PERST which in theory
might then require a firmware reload, but at the
moment seems to work without.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 75 
 1 file changed, 75 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c 
b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
index 0472d8ecf6..1a8fc7a134 100644
--- a/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
+++ b/Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c
@@ -334,6 +334,76 @@ CleanSimpleFramebuffer (
   return EFI_SUCCESS;
 }
 
+STATIC
+EFI_STATUS
+SyncPcie (
+  VOID
+  )
+{
+#if (RPI_MODEL == 4)
+  INTN  Node;
+  INTN  Retval;
+  UINT32DmaRanges[7];
+
+  Node = fdt_path_offset (mFdtImage, "pcie0");
+  if (Node < 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to locate 'pcie0' alias\n", 
__FUNCTION__));
+return EFI_NOT_FOUND;
+  }
+
+  // non translated 32-bit DMA window with a limit of 0xc000
+  DmaRanges[0] = cpu_to_fdt32 (0x0200); 
+  DmaRanges[1] = cpu_to_fdt32 (0x); 
+  DmaRanges[2] = cpu_to_fdt32 (0x);
+  DmaRanges[3] = cpu_to_fdt32 (0x);
+  DmaRanges[4] = cpu_to_fdt32 (0x);
+  DmaRanges[5] = cpu_to_fdt32 (0x);
+  DmaRanges[6] = cpu_to_fdt32 (0xc000);
+
+  DEBUG ((DEBUG_INFO, "%a: Updating PCIe dma-ranges\n",  __FUNCTION__));
+
+  // Match dma-ranges with the edk2+ACPI setup we are using.
+  // This works around a failure in linux to reset the XHCI correctly
+  // when in DT mode following the linux kernel reprogramming the PCIe
+  // subsystem to match the DT supplied inbound PCIe/DMA translation.
+  // It appears the lower level firmware honors whatever it reads
+  // during the first PCI/XHCI quirk call and uses that value until
+  // rebooted rather than re-reading it on every mailbox command.
+  Retval = fdt_setprop (mFdtImage, Node, "dma-ranges",
+DmaRanges,  sizeof DmaRanges);
+  if (Retval != 0) {
+DEBUG ((DEBUG_ERROR, "%a: failed to update 'dma-ranges' property (%d)\n",
+  __FUNCTION__, Retval));
+return EFI_NOT_FOUND;
+  }
+
+  // Now that we are always running without DMA translation, and with
+  // a 3G DMA limit, there shouldn't be a need to reset/reload
+  // the XHCI for it to operate. The possible problem is that the PCIe root
+  // port is itself being reset (by linux+DT), The rpi foundation claims
+  // this is needed as a pre-req to reloading the XHCI firmware, which
+  // also implies that a PCI fundamental reset should cause the XHCI itself
+  // to reset. For sure isn't happening fully, otherwise reloading the
+  // firmware would be mandatory. As it is, recent kernels actually start to
+  // have problems following the XHCI reset notification mailbox!
+  // So lets just stop the kernel from triggering the mailbox by removing
+  // the node.
+  Node = fdt_path_offset (mFdtImage, "/scb/pcie@7d50/pci@1,0");
+  if (Node < 0) {
+// This can happen on CM4/etc which doesn't have an onboard XHCI
+DEBUG ((DEBUG_ERROR, "%a: failed to locate 
/scb/pcie@7d50/pci@1/usb@1\n", __FUNCTION__));
+  } else {
+Retval = fdt_del_node (mFdtImage, Node);
+if (Retval != 0) {
+  DEBUG ((DEBUG_ERROR, "Failed to remove 
/scb/pcie@7d50/pci@1/usb@1\n"));
+  return EFI_NOT_FOUND;
+}
+  }
+
+#endif
+  return EFI_SUCCESS;
+}
+
 /**
   @param  ImageHandle   of the loaded driver
   @param  SystemTable   Pointer to the System Table

[edk2-devel] [PATCH v2 0/1] Fix DT boot on rpi4

2021-10-01 Thread Jeremy Linton
Some rpi4's haven't booted cleanly using DT for a few months.  The primarly
problem is that the XHCI_NOTIFY_RESET mailbox call doesn't seem to be able
to correctly read the pcie translation state after we have set it up. So,
while linux appears to be able to adjust the PCIe subsystem to the demands
of it's DT, the XHCI won't function because its looking for an untranslated
DMA range to access(?) its firmware image in main RAM.

So, lets apply the same non-translated 3G limit to DT's we hand off, as
well as remove the XHCI reset controller info so that linux/etc doesn't try
to reload the firmware. This latter tweak is a bit non obvious, but seems
to cure the general problem.

V1->V2:
Also remove the pci/usb node to keep Linux from
trying to call the XHCI_NOTIFY_RESET mailbox.

Jeremy Linton (1):
  Platform/RaspberryPi: Always use non translating DMA in DT mode

 Platform/RaspberryPi/Drivers/FdtDxe/FdtDxe.c | 75 
 1 file changed, 75 insertions(+)

-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81374): https://edk2.groups.io/g/devel/message/81374
Mute This Topic: https://groups.io/mt/86014857/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 5/7] Silicon/Broadcom/Bcm27xx: Move linkup check into the cfg accessor

2021-08-19 Thread Jeremy Linton
The existing code fails to create/finish configuring the
pcie subsystem if it fails to get a linkup. This is reasonable
on the RPi4 because it generally won't happen, and the OS
could not see the root port. Now that the OS can see the
root port, its a bit odd if it only shows up when
something is plugged into the first slot. Lets move the
link up check into the config accessor where it will be used
to restrict sending CFG TLP's out the port when nothing is
plugged in. Thus avoiding a SERROR during probe.

Signed-off-by: Jeremy Linton 
---
 .../Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c   | 5 -
 .../Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c  | 7 +++
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git 
a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
 
b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
index 8587d2d36d..4d4c584726 100644
--- 
a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
+++ 
b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
@@ -204,11 +204,6 @@ Bcm2711PciHostBridgeLibConstructor (
   } while (((Data & 0x30) != 0x030) && (Timeout));
   DEBUG ((DEBUG_VERBOSE, "PCIe link ready (status=%x) Timeout=%d\n", Data, 
Timeout));
 
-  if ((Data & 0x30) != 0x30) {
-DEBUG ((DEBUG_ERROR, "PCIe link not ready (status=%x)\n", Data));
-return EFI_DEVICE_ERROR;
-  }
-
   if ((Data & 0x80) != 0x80) {
 DEBUG ((DEBUG_ERROR, "PCIe link not in RC mode (status=%x)\n", Data));
 return EFI_UNSUPPORTED;
diff --git 
a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c 
b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c
index 6d15e82fa2..b627e5730b 100644
--- a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c
+++ b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c
@@ -105,6 +105,13 @@ PciSegmentLibGetConfigBase (
   return 0x;
   }
 
+  /* Don't probe slots if the link is down */
+  Data = MmioRead32 (PCIE_REG_BASE + PCIE_MISC_PCIE_STATUS);
+  if ((Data & 0x30) != 0x30) {
+  DEBUG ((DEBUG_ERROR, "PCIe link not ready (status=%x)\n", Data));
+  return 0x;
+  }
+
   MmioWrite32 (PCIE_REG_BASE + PCIE_EXT_CFG_INDEX, Address);
   mPciSegmentLastAccess = Address;
 }
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79611): https://edk2.groups.io/g/devel/message/79611
Mute This Topic: https://groups.io/mt/85014310/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 2/7] Platform/RaspberryPi: Break XHCI into its own SSDT

2021-08-19 Thread Jeremy Linton
Lets prepare to switch between XHCI and PCI by moving
the XHCI definition into its own SSDT. That way we can
select it based on the menu settings. The resource
producer/consumer flag is also corrected.

Reviewed-by: Andrei Warkentin 
Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/AcpiTables/AcpiTables.inf |  1 +
 Platform/RaspberryPi/AcpiTables/Dsdt.asl   |  3 --
 Platform/RaspberryPi/AcpiTables/Xhci.asl   | 35 ++
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  8 +
 4 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
index 1ddc9ca5fe..f3e8d950c1 100644
--- a/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/AcpiTables/AcpiTables.inf
@@ -38,6 +38,7 @@
   SpcrPl011.aslc
   Pptt.aslc
   SsdtThermal.asl
+  Xhci.asl
 
 [Packages]
   ArmPkg/ArmPkg.dec
diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index 1ee6379f46..b594d50bdf 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -64,9 +64,6 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 2, "RPIFDN", "RPI", 2)
   Scope (\_SB_)
   {
 include ("Pep.asl")
-#if (RPI_MODEL == 4)
-include ("Xhci.asl")
-#endif
 
 Device (CPU0)
 {
diff --git a/Platform/RaspberryPi/AcpiTables/Xhci.asl 
b/Platform/RaspberryPi/AcpiTables/Xhci.asl
index bc3fea60f9..9b37277956 100644
--- a/Platform/RaspberryPi/AcpiTables/Xhci.asl
+++ b/Platform/RaspberryPi/AcpiTables/Xhci.asl
@@ -9,6 +9,8 @@
 
 #include 
 
+#include "AcpiTables.h"
+
 /*
  * The following can be used to remove parenthesis from
  * defined macros that the compiler complains about.
@@ -24,12 +26,17 @@
  */
 #define XHCI_REG_LENGTH 0x1000
 
-Device (SCB0) {
-Name (_HID, "ACPI0004")
-Name (_UID, 0x0)
-Name (_CCA, 0x0)
+DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4XHCI", 2)
+{
+  Scope (\_SB_)
+  {
+
+Device (SCB0) {
+  Name (_HID, "ACPI0004")
+  Name (_UID, 0x0)
+  Name (_CCA, 0x0)
 
-Method (_CRS, 0, Serialized) { // _CRS: Current Resource Settings
+  Method (_CRS, 0, Serialized) { // _CRS: Current Resource Settings
 /*
  * Container devices with _DMA must have _CRS, meaning SCB0
  * to provide all resources that XHC0 consumes (except
@@ -57,15 +64,15 @@ Device (SCB0) {
 Add (MMBE, XHCI_REG_LENGTH - 1, MMBE)
 Add (MMLE, XHCI_REG_LENGTH - 1, MMLE)
 Return (RBUF)
-}
+  }
 
-Name (_DMA, ResourceTemplate() {
+  Name (_DMA, ResourceTemplate() {
 /*
  * XHC0 is limited to DMA to first 3GB. Note this
  * only applies to PCIe, not GENET or other devices
  * next to the A72.
  */
-QWordMemory (ResourceConsumer,
+QWordMemory (ResourceProducer,
 ,
 MinFixed,
 MaxFixed,
@@ -79,10 +86,10 @@ Device (SCB0) {
 ,
 ,
 )
-})
+  })
 
-Device (XHC0)
-{
+  Device (XHC0)
+  {
 Name (_HID, "PNP0D10")  // _HID: Hardware ID
 Name (_UID, 0x0)// _UID: Unique ID
 Name (_CCA, 0x0)// _CCA: Cache Coherency Attribute
@@ -131,5 +138,7 @@ Device (SCB0) {
 Debug = "xHCI enable"
 Store (0x6, CMND)
 }
-}
-}
+  } // end XHC0
+} //end SCB0
+  } //end scope sb
+} //end definition block
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 87f6b4e7bb..7c5786303d 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -814,6 +814,14 @@ STATIC CONST NAMESPACE_TABLES SdtTables[] = {
 PcdToken(PcdSdIsArasan),
 SsdtEmmcNameOpReplace
   },
+#if (RPI_MODEL == 4)
+  {
+SIGNATURE_64 ('R', 'P', 'I', '4', 'X', 'H', 'C', 'I'),
+0,
+PcdToken(PcdXhciPci),
+NULL
+  },
+#endif
   { // DSDT
 SIGNATURE_64 ('R', 'P', 'I', 0, 0, 0, 0, 0),
 0,
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79615): https://edk2.groups.io/g/devel/message/79615
Mute This Topic: https://groups.io/mt/85014314/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




[edk2-devel] [PATCH v3 1/7] Platform/RaspberryPi: Add XHCI/PCI selection menu

2021-08-19 Thread Jeremy Linton
Arm has standardized a PCI SMC conduit that can be used
to access the PCI config space in a standardized way. This
functionality doesn't yet exist in many OS/Distro's. Lets
add another advanced config item that allows the user
to toggle between presenting the XHCI on the base RPi4
as a platform device, or presenting this newer PCIe
conduit. The CM4 doesn't have an attached XHCI controller
soldered to the PCIe, so PCIe mode is the default.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 42 ++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +++
 .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 17 +
 Platform/RaspberryPi/Include/ConfigVars.h  |  4 +++
 Platform/RaspberryPi/RPi3/RPi3.dsc |  6 
 Platform/RaspberryPi/RPi4/RPi4.dsc |  8 +
 Platform/RaspberryPi/RaspberryPi.dec   |  1 +
 8 files changed, 84 insertions(+)

diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
index 9e78cb47ad..87f6b4e7bb 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
@@ -43,6 +43,7 @@ extern UINT8 ConfigDxeStrings[];
 STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
 STATIC UINT32 mModelFamily = 0;
 STATIC UINT32 mModelInstalledMB = 0;
+STATIC UINT32 mModelRevision = 0;
 
 STATIC EFI_MAC_ADDRESS  mMacAddress;
 
@@ -271,6 +272,40 @@ SetupVariables (
 ASSERT_EFI_ERROR (Status);
   }
 
+  if (mModelFamily >= 4) {
+if (((mModelRevision >> 4) & 0xFF) == 0x14) {
+  /*
+   * Enable PCIe by default on CM4
+   */
+  Status = PcdSet32S (PcdXhciPci, 2);
+  ASSERT_EFI_ERROR (Status);
+} else {
+  Size = sizeof (UINT32);
+  Status = gRT->GetVariable (L"XhciPci",
+ ,
+ NULL, , );
+  if (EFI_ERROR (Status) || (Var32 == 0)) {
+/*
+ * Enable XHCI by default
+ */
+Status = PcdSet32S (PcdXhciPci, 0);
+ASSERT_EFI_ERROR (Status);
+  } else {
+/* 
+ * Enable PCIe
+ */
+Status = PcdSet32S (PcdXhciPci, 1);
+ASSERT_EFI_ERROR (Status);
+  }
+}
+  } else {
+/* 
+ * Disable PCIe and XHCI
+ */
+Status = PcdSet32S (PcdXhciPci, 0);
+ASSERT_EFI_ERROR (Status);
+  }
+
   Size = sizeof (AssetTagVar);
   Status = gRT->GetVariable (L"AssetTag",
   ,
@@ -888,6 +923,13 @@ ConfigInitialize (
 DEBUG ((DEBUG_INFO, "Current Raspberry Pi installed RAM size is %d MB\n", 
mModelInstalledMB));
   }
 
+  Status = mFwProtocol->GetModelRevision ();
+  if (Status != EFI_SUCCESS) {
+DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi revision: %r\n", 
Status));
+  } else {
+DEBUG ((DEBUG_INFO, "Current Raspberry Pi revision %x\n", mModelRevision));
+  }
+
   Status = SetupVariables ();
   if (Status != EFI_SUCCESS) {
 DEBUG ((DEBUG_ERROR, "Couldn't not setup NV vars: %r\n", Status));
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
index 4bb2d08550..e6e22ad82e 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
@@ -94,6 +94,7 @@
   gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
   gRaspberryPiTokenSpaceGuid.PcdFanTemp
   gRaspberryPiTokenSpaceGuid.PcdUartInUse
+  gRaspberryPiTokenSpaceGuid.PcdXhciPci
 
 [Depex]
   gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
index 466fa852cb..5ec17072c3 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
+++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
@@ -57,6 +57,11 @@
 #string STR_ADVANCED_FANTEMP_PROMPT   #language en-US "ACPI fan temperature"
 #string STR_ADVANCED_FANTEMP_HELP #language en-US "Cycle a fan at C"
 
+#string STR_ADVANCED_XHCIPCI_PROMPT   #language en-US "ACPI XHCI/PCIe"
+#string STR_ADVANCED_XHCIPCI_HELP #language en-US "OS sees XHCI USB 
platform device or PCIe bridge"
+#string STR_ADVANCED_XHCIPCI_XHCI #language en-US "XHCI"
+#string STR_ADVANCED_XHCIPCI_PCIE #language en-US "PCIe"
+
 #string STR_ADVANCED_ASSET_TAG_PROMPT #language en-US "Asset Tag"
 #string STR_ADVANCED_ASSET_TAG_HELP   #language en-US "Set the system Asset 
Tag"
 
diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr 
b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
index fa34eab809..18b3ec726e 100644
--- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
+++ b/Pla

[edk2-devel] [PATCH v3 7/7] Platform/RaspberryPi: Add Linux quirk support

2021-08-19 Thread Jeremy Linton
Linux, for the time being has refused to support the Arm
standard SMCCC for PCIe configuration. Instead they
want to continue to maintain per device "quirks".

As the RPI isn't really ECAM this is a bit more
involved because the MCFG can't really describe
the root port+config registers situation. Further
platforms which support the SMCCC shouldn't have
a MCFG, so we need an additional way to tell linux
what it needs to know about this platform.

Signed-off-by: Jeremy Linton 
---
 Platform/RaspberryPi/AcpiTables/Pci.asl | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Platform/RaspberryPi/AcpiTables/Pci.asl 
b/Platform/RaspberryPi/AcpiTables/Pci.asl
index dc2bd7bc9e..50fe2cbdf2 100644
--- a/Platform/RaspberryPi/AcpiTables/Pci.asl
+++ b/Platform/RaspberryPi/AcpiTables/Pci.asl
@@ -62,6 +62,13 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4PCIE", 
2)
 Package (4) { 0x, 3, zero, 178 }
   })
 
+  Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+  Package () {
+Package () { "linux-ecam-quirk-id", "bcm2711" },
+  }
+  })
+
   // Root complex resources
   Method (_CRS, 0, Serialized) {
 Name (RBUF, ResourceTemplate () {
-- 
2.13.7



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79614): https://edk2.groups.io/g/devel/message/79614
Mute This Topic: https://groups.io/mt/85014313/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-




  1   2   3   >