| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The mailbox property interface expects every tag's value buffer to be
padded to a 32-bit boundary so the following tags and the end tag stay
aligned.
Commit 61708392042b ("RPiFirmwareDxe: Fix and consolidate incorrect
pragma pack blocks") wrapped every mailbox tag struct in a module-wide
#pragma pack(1). RPI_FW_MAC_ADDR_TAG then no longer rounds up to a
multiple of 4: the packed tag is 10 bytes (6-byte MAC address + 4-byte
"UINT32 Padding"), which leaves the trailing end tag misaligned. Recent
VideoCore firmware rejects such a request with a 0x80000001 partial
response, so RpiFirmwareGetMacAddress () fails and callers fall back to
an all-zero MAC address.
None of these tag structs actually need packing - they are all built
from UINT32 fields and are laid out identically packed or not. The sole
exception was RPI_FW_SERIAL_TAG's UINT64, which would otherwise be
padded to an 8-byte boundary inside the tag body. Drop the #pragma pack
block entirely, express the serial as UINT32[2] (read back with CopyMem)
and remove the now-unneeded RPI_FW_MAC_ADDR_TAG padding member; the
enclosing command struct's natural alignment keeps the end tag aligned.
Signed-off-by: valtzu <valtzu@gmail.com>
|
|
This reverts commit 29203d6aa8d2197be9401dd96c112ccb320708d0.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
Add support for the Raspberry Pi variant Zero 2 W, which is based on the
same SoC as the Raspberry Pi 3. This is needed in order to correctly
identify the SoC peripherals such as the MMC/SD controller.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Use SMBIOS_CACHE_SIZE, SMBIOS_CACHE_SIZE2 and AArch64 PROCESSOR_ID_DATA
structures.
Signed-off-by: Sarah Walker <Sarah.Walker2@arm.com>
|
|
EmbeddedPkg FdtLib is getting deleted. Migrate RPI to MdePkg BaseFdtLib
which is the replacement.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
|
|
edk2 commit ae83c6b7fd83a5906e016a32027c1bcd792a624e updates the 'null'
variants of the DebugLib macros (used when MDEPKG_NDEBUG is defined) so
that they explicitly discard their parameters using `if (FALSE)` code
blocks. These are understood as marking the contained code as referenced
but unused by all supported compilers. This avoids the need for additional
MDEPKG_NDEBUG dependent code in c files, to conditionally hide static
methods or functions which are only used in debug macros. Now, such code
can and must be removed.
This commit updates the relevant MDEPKG_NDEBUG code in c files throughout
edk2-platforms (there are only some 20 instances).
We also fix a couple of cases where the wrapped variables had incorrectly
not been marked STATIC.
Since the RELEASE builds of all platforms which used this kind of code
break after the above-mentioned edk2 commit, it is considered preferable
to have one single cross-platform commit to edk2-platforms which resolves
this, rarther than spreading the fix across multiple commits.
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
|
|
pack blocks
This fixes serial number on RPi4 – it is now the actual serial number instead of MAC address.
Signed-off-by: valtzu <valtzu@gmail.com>
|
|
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
edk2-platforms.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
|
|
Drop the now unused EfiResetSystemLib implementation, which has been
superseded by the generic one from EDK2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
Drop the reference to the special reset runtime DXE driver in
EmbeddedPkg, and move to the one in MdeModulePkg shared between all
architectures. This version implements reset notifications, allowing us
to retire the home grown version of that functionality in a subsequent
patch.
Add depexes to the components that rely on the reset notification
protocols to ensure that they are not dispatched before those protocols
are made available by the reset runtime DXE driver.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
In addition to setting up the home grown reset notification, register
with the generic EFI protocol that does the same. This event is
triggered from the reset runtime implemented in MdeModulePkg, to which
we will be switching the RPi platforms in a subsequent patch.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
The DumpVars() routine is called directly and via an event notification
callback, and the latter therefore defines the function's prototype,
even though the arguments are unused.
We will introduce another callback into this logic, but via a reset
notifier, which has yet another prototype. So to keep things tidy, drop
the formal parameters from DumpVars() and invoke it via a helper
function that discards the arguments when called as a event notification
callback. We will do the same for the reset notification once that
functionality gets added.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
The VarBlockServiceDxe driver needs to be dispatched before the common
VariableRuntimeDxe, but we are currently relying on FDF order and lack
of transitive dependencies for this, which is fragile, and will break
once we move to the generic reset runtime.
So use the existing helper library for this, which can be plugged into
the generic variable drivers, and force them to depex on a GUID that can
be installed as a NULL protocol in VarBlockServiceDxe.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
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 <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
It's 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 who 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 <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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 <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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 0000:01:00.0: xHCI Host Controller
[ 3.569538] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[ 3.577452] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000040000000890
[ 3.587725] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 3.593115] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[ 3.600693] xhci_hcd 0000: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 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[ 6.239977] xhci_hcd 0000: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.
[1] https://lore.kernel.org/all/20210831125843.1233488-1-nsaenzju@redhat.com/
Fixes: efff29cdcdb7 ("Platform/RaspberryPi: Always use non translating DMA in DT mode")
Signed-off-by: Adrien Thierry <athierry@redhat.com>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
|
|
Describe the miniuart clock frequency in a _DSD property, so that it can
be read from the Linux driver [1]
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.
[1] https://lore.kernel.org/all/20220207232129.402882-1-athierry@redhat.com/
Signed-off-by: Adrien Thierry <athierry@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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 <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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 <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
The build has been tossing a warning about having two defaults
for a while now, lets fix it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
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 <jeremy.linton@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Since we plan on toggling between XHCI and PCI the PCI
root needs to be in its own SSDT. This is all thats needed
of UEFI. The SMC conduit is provided directly to the running
OS. When the OS detects this PCIe port on a machine without
a MCFG it attempts to connect to the SMC conduit. The RPi
definition doesn't have any power mgmt, and only provides
a description of the root port.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jared McNeill <jmcneill@invisible.ca>
|
|
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 <awarkentin@vmware.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jared McNeill <jmcneill@invisible.ca>
|
|
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 <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-By: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Tested-by: Jared McNeill <jmcneill@invisible.ca>
|
|
This reverts commit efdc159ef7c9f15581a0f63d755a1530ff475156.
This commit is not longer required as Boot Discovery Policy has been
implemented for Raspberry Pi.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
|
|
This change is based on edk2-platforms-raspberrypi-pl011-bth-noflow.diff
in https://github.com/worproject/RPi-Bluetooth-Testing/ with the
modifications and additional changes below for enabling Bluetooth
and serial port (Mini UART) in Windows IOT.
- Remove RPIQ connection for BT_ON/OFF in Uart.asl because it is
useless. The firmware already turns on the Bluetooth by default.
- Move the GPIO pin muxing stuff from Uart.asl to ConfigDxe driver.
Testing Done:
- Successfully booted Windows Windows 10 IOT (20279.1) on SD (made by
WOR) with the RPi-Windows-Drivers release ver 0.5 downloaded from
https://github.com/worproject/RPi-Windows-Drivers/releases
and checked that both Bluetooth and serial port (Mini UART) can
work fine.
- Successfully booted VMware ESXi-Arm Fling v1.3 with only serial
console connection (PL011 UART).
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
|
|
Changes:
1. Add code to ConfigDxe driver and AcpiTables module to dynamically
build either Mini UART or PL011 UART info in ACPI. This also fixes
the issue discussed in https://github.com/pftf/RPi4/issues/118.
2. Cleanup by moving duplicate Debug Port 2 table related defines and
structures to a newly created header file (RpiDebugPort2Table.h).
Testing Done:
- Booted to UEFI shell and use acpiview command to check the result of
the different UART settings in config.txt (enabling either Mini UART
or PL011) and SPCR, DBG2 tables and device BTH0 are dynamically
changed as expected.
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
|
|
Now that we are doing SoC detection and adjusting the DMA
window it should be safe to turn DMA on by default.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
This is a fix for https://github.com/pftf/RPi4/issues/114.
Changes:
1. Add a setup option called BootPolicy and consume the setting
during boot to decide whether to perform or skip ConnectAll.
2. The Default setting is set to Full discovery because it is not
worth enabling Fast boot by default on RaspberryPi systems.
Enabling it just saves boot time about 1 second, but caused a
lot of issues.
Testing Done:
- Booted to Standalone UEFI shell on SD card and use drivers
command to check the result with Fast Boot and Full discovery
settings. Then, child/device handles are created as expected.
Note and to-do items:
- The root cause looks like that boot loaders and some tools like
grub and iPXE haven't supported selective connect/Fast boot.
However, system firmware should still provide a setup option for
user to enable Fast boot with old version boot loaders and tools,
which is why we proposed this change. We will also report this
issue to boot loader and tool vendors/open source GitHubs.
- We will add more options for connecting specific type devices so
that we can still have the shortest boot time for all use cases.
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Link: https://github.com/pftf/RPi4/issues/144
Link: https://github.com/pftf/RPi4/issues/114
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Acked-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
DwHcReset expects attributes as the second argument. A reset is
performed if the passed attribute is valued. However 0 is not a valid
attribute and will thus never cause a controller reset.
Passing EFI_USB_HC_RESET_HOST_CONTROLLER will reset the dwc2 controller
as expected.
This enables the USB 2.0 port of the raspberry compute module 4.
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Signed-off-by: René Treffer <treffer@measite.de>
|
|
The 3G limit, and the 2G IORT are intended to solve
the same linux problem. They limit PCI DMA operations
to the first 3G of RAM. Older linux kernels, as
used with RHEL/Centos, trigger an assertion*
when a DMA operation starts at a range that
doesn't fit within the 2G range specified by the IORT.
The simple solution is to only enable the IORT
when the 3G flag is disabled and there is more
than 3G installed.
* https://github.com/pftf/RPi4/issues/123
Fixes: dac891da5cf3 ("Platform/RaspberryPi/AcpiTables: add a IORT ACPI table to limit XHCI DMA")
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
DMA translation on the eMMC2 vary based on SoC, and
this is made worse by the poor _DMA support in Linux.
For now the "safe" option is to simply run the eMMC2
controller in PIO mode. More advanced users or !Linux
operating systems may choose to enable this to gain
a perf boost.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
The primary problem with the RPi's Arasan controller is
the lack of a meaningful capabilities register. With just
a sdhci-caps _DSD entry we can provide that information. It
can then be bound to the Linux sdhci_iproc driver which
already hardcodes the remaining controller bugs.
Further we have gotten BRCME88C approved as the HID
for the newer eMMC2 controller. So lets define an
ACPI object to describe it.
Of course both devices are sharing an interrupt so
we should also indicate that in the table as well.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
Turns out its helpful to have a !PcdToken flag
that enables a DSDT/SSDT. That simplifies
both the emmc2 SSDT (it only installs when
!SdIsArasan) and later for the XHCI/PCIe switch
where we want to install one of two tables
depending on whether a single Pcd is set.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
It seems we should be powering up the SD cards, and possibly
the clocks as well to assure they are setup properly before
we attempt to access the controller.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
The firmware reports the eMMC2 frequency with a slightly
different mailbox command, lets select the correct one
based on which controller we are binding to.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
The uboot and Linux drivers have notes that there is a clock domain crossing
problem that happens with back to back writes to the SD controllers on the
rpi. Its not clear if this is still applicable to the rpi4/eMMC2 but
it seems wise to add it.
Further, we need to assure that the card voltage is set to 3.3V, and
we should try and follow some of the SDHCI docs when it comes to
changing the clock.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
The current MMC (really SDHCI) definitions are tied to the
Arasan controller. As we intend to reuse the definitions lets
make the base address configurable when the driver loads.
This assumes we won't ever want to run both the eMMC2
and Arasan SDHCI controller at the same time.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
Lets add some further mailbox helpers and convert the existing
RpiFirmwareSetLed into a generic SetGpio() function.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
REF: https://github.com/pftf/RPi4/issues/88
Fix SCT failures in the RPi USB2_HC_PROTOCOL by adding input parameter
validation in Reset(), SetState(), GetState(), and
SyncInterruptTransfer()
Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
Due to the method in which NV variables are stored on removable media
for the Raspberry Pi platform, and the manner in which we dump updated
variables right before reset, it is possible, and has been repeatedly
demonstrated with SSD-based USB 3.0 devices, that the updated file does
not actually end up being written to permanent storage, due to the
device write-cache not having enough time to be flushed before reset.
To compensate for this, since we don't know of a generic method that
would allow turning off USB mass storage devices write cache (and also
because we are seeing an issue that seems related for SD-based media),
we add a new reset delay PCD, which can be set by the user, and which
we also set as required when NV variables are being dumped.
Our testing show that, with more than 3 seconds of extra delay, the
storage media has enough time to finalize its internal write, thus
solving the issue of configuration changes not being persisted.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Tested-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
|
|
Like the Pi 4B, the 3GB/4GB choices apply to it as well.
Values taken from
https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
|
|
Updated the pinout to match the Pi4 datasheet, tested with the RPi4.
RPi3 Datasheet has same pinout.
Signed-off-by: Jeff Booher-Kaeding <Jeff.booher-kaeding@arm.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Pete's review pointed out some whitespace issues in the
context of a previous patch. Since there are a number of
similar errors in the file lets fix them separately.
[ardb: use MmioOr32/MmioAnd32 instead of separate reads and writes]
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Now that we have the ability to enable an AML fan object,
allow the user to select the temperature at which the
fan cycles on.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Add a menu item that allows the user to enable GPIO based
fan control via SSDT and the previous NameObj replacement
commit. This should only be seen/enabled on RPI4
because that is what its been tested with.
Given GPIO pin current limitations its likely that a bit of
additional circuitry is required to drive a fan, and the GPIO
high/low signal can only be used as a enable/disable signal. A
search for "rpi npn gpio fan" or similar should turn up some
hits for how to do this. Alternatively there are some commercial
boards (FAN SHIM) which operate via simple GPIO control.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Hook the ACPI table install sequence and add some
basic conditional and AML NameOp update logic. If
a table has a non-zero PCD declared that pcd is
checked for a non-zero value before allowing the table
to be installed. We also add a table of NameOp to
PCD's which will be written into a DSDT/SSDT table
as part of its install process.
With this change we can declare something in
ASL like:
Name (VARN, 0x1234)
and then add a table entry like:
{"VARN", PcdToken(PcdVarn)}
and the value of PcdVarn will replace the
0x1234 declared in the ASL above.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
|
|
Commit 0c2af04985f0bf152ac3edc70d9c6d9fe884cdcb added mDriverBinding
extern module global, but did not remove the STATIC declaration, which
caused the build to break. Fix the build error by removing STATIC for
that module global variable.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
|
