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_REVISION_00.
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_REVISION_00.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@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 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 <kettenis@openbsd.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
With the upcoming release of Windows 11, Microsoft has introduced a new USB
Device-Specific Method (_DSM) function to enforce 64-bit xHCI registers to
be accessed through two sequential 32-bit requests. The new function (Query
controller register access type - Function 6) is documented at:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-
Support for this feature is required on the Raspberry Pi 4 where there is
a bug/limitation in the xHCI stack that prevents full range 64-bit access
from working correctly. It should be noted that an equivalent for this _DSM
is not required on Linux, as 64-bit xHCI register access is already broken
down into 2x32-bit by the drivers there.
With this _DSM, and unlike what is the case for Windows 10, Windows 11 can
now be installed on the Raspberry Pi 4 without having to alter any of the
installation files, as we were able to validate using the latest Windows 11
Build 22000 Insider image.
Signed-off-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
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 <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-By: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
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>
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>
The newer BCM2711 SoC's don't have a DMA constraint on the emmc2
controller. So we don't need to do the 1G translation. Lets
allow the AML to detect the SoC revision and return a different
_DMA resource.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Add some additional IORT nodes for the USB & EMMC devices, realistically
we probably only need to have a single node with the lowest AddressSizeLimit
but this is conceptually "cleaner" should anyone actually try and use these
values rather than the _DMA provided ones.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
The arasan caps registers are no longer being overridden by
the brcm iproc driver, so we should be assuring that the
"High Speed Support" bit 21 is set in the capability
register. This significantly improves the wifi perf
using linux.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
As per ACPI 6.3 specification, the DSDT/SSDT table should use revision 2
, so update the revision numbers to 2.
This also fixes https://github.com/pftf/RPi4/issues/94 (FWTS failures).
Testing Done:
- Booted to UEFI Shell and used apciview command to check all ACPI
tables' revision.
- Ran FWTS test and no longer see the ACPI DSDT and SSDT revision
failures. Note that the XSDT revision failure is caused by the FWTS
tool's issue that got fixed in
commit c522bfedc9839a474b8d590ba36bec77436d2e90
Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # Windows 10 boot
The new emmc2 device adds a container with a _UID of 0 which duplicates
an existing ACPI container.
This causes windows to fail to boot with a Stop ACPI_BIOS_ERROR. The
workaround without this fix is to go into the BDS menus and set the SD
routing to the Arasan.
Fixes: 311ed3c790 ("Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan")
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
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>
The current mainline DT indicates that the thermal offset
on the rpi is 410040 rather than the 419949 being used.
This means our temp calculation is offset nearly 10C higher
when running in ACPI mode vs DT.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Add an IORT table that will limit XHCI DMA to 2 GB, by setting the
DMA width to 31 bits. This is needed for Linux/arm64, which can
only reliably deal with devices that are unable to perform DMA to
the entire 32-bit address range if it can discover their existence
early during boot, and this is before the ACPI interpreter is up
and running (which rules out calling the _DMA method of the XHC0
object)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
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>
Now that we have a thermal zone we can add active cooling
by specifying active cooling points (_ACx) which can
be tied to fan objects that turn fans on/off using GPIO
pins.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Rather than exporting the temp sensor or mailbox
in ACPI land we can wrap them in AML and use the default
ACPI drivers provided by the OS. This enables the use of
"sensors" in linux to report the SOC temp.
As a first pass add a basic passive cooling ACPI thermalzone
with trip points for passive cooling (throttling) handled
by the vc firmware, hibernate and critical shutdown. The
vc apparently kicks in at ~80C, so the hibernate and critical
set points are set at +5 and +10 of that. In the future
CPPC should be able to monitor the thermal throttling.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Move PCDs from GENET driver to Raspberry Pi and Bcm27xx packages.
The Genet driver follows the UEFI driver model, so it should not have
PCDs defined that describe MMIO and MAC addresses of a single instance.
Also, move related definitions around, and update references accordingly.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
