| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Update platform ACPI table sources to include AcpiHelperMacros.h for the
ACPI helper macros that moved out of AcpiLib.h.
For files that only use the helper macros, replace the AcpiLib.h include
with AcpiHelperMacros.h. For SbsaQemuAcpiDxe, keep AcpiLib.h because the
driver also uses AcpiLib APIs, and add AcpiHelperMacros.h for the moved
macro definitions.
This change depends on the companion edk2 change:
"EmbeddedPkg,MdeModulePkg,DynamicTablesPkg: Move ACPI helper macros"
Tested:
Affected platform DSCs: AARCH64 GCC NOOPT
SGI affected platforms passed; other affected platforms fail due to
missing local assets/dependencies unrelated to the include migration.
Signed-off-by: Varshit Pandya <varshit.pandya@arm.com>
|
|
acpiview complains:
ERROR: On Arm based systems, all cache properties must be provided in
the cache type structure. Missing 'Write Policy Valid' flag.
ACPI specification says:
> Set to 1 if the write policy attribute described is valid. A value
> of 0 indicates that, where possible, processor architecture specific
> discovery mechanisms should be used to ascertain the value of this
> attribute.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
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>
|
|
Remove non-standard RPI ACPI _CIDs that are not needed.
This also fixes the FWTS failure reported in
https://github.com/pftf/RPi4/issues/67
The windows drivers at https://github.com/raspberrypi/windows-drivers
are still able to match the ACPI objects using the HIDs which
are supported in the drivers, with these two recent changes needed:
6469702898789e555c6947e50216a3f79e0ddeb9
and
5c5e2742b4c983b3001c473b168b0dae2fcba0c2
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Mario Bălănică <mariobalanica02@gmail.com>
Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Tested-by: Mario Bălănică <mariobalanica02@gmail.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Tested-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
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
|
|
Convert SsdtThermal.asl to CR/LF like the rest of the sources.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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>
|
|
The UART namespace reference in DBG2 is incorrect. Fix to point to the
correct name.
This fixes the certification failure reported by FWTS tests at:
https://github.com/pftf/RPi4/issues/69
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@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>
|
|
Because of its widespread availability and low price, we expect the
Raspberry Pi source to be used by platform developers as a starting
point to create their own platform implementation.
As such, it makes a lot of sense to want to use the most up to date
underlying standards, even if the pay off is limited in this case,
or may even be seen as a liability in terms of ensuring greater
compatibility with older OSes, as it may help others benefit from
the latest improvements and features brought by modern ACPI.
We also happen to already be using ACPI 6.3 constructs, such as
PPTT (which was only introduced in ACPI 6.2 and further extended
in 6.3), and have some reliance on 6.x GIC, as the original MADT
binary blobs from Microsoft were 6.0 and abuse the GICR Base
Address field in order for Windows to boot properly (for reasons
that the proprietary nature of the Windows kernel makes difficult
to determine). So in effect, we did apply a potential breaking
change to Windows when we downgraded MADT to ACPI 5.1, though we
did validate at the time that the downgrade in ACPI version didn't
*seem* to break OS functionality. Still, because we are in the
dark as to what the ACPI fields we removed when downgrading ACPI
version were being used for, we obviously want to add them back.
Therefore, since we do see a need for ACPI 6.x features, and
effectively have a 6.3 table with PPTT, and also since we have
tested that we are not seeing ill effects from doing so for the
most common OSes we support, we bring all of the relevant ACPI
tables to version 6.3.
This is mostly accomplished by simply altering the version of
ACPI being references in the macros, except for the new fields
being initialized in the MADT table where we:
* Use 1 for GICR Base Address in GICC_STRUCTURE_INIT because, even
as this field is not supposed to apply to any of our platforms,
this is what Microsoft used in the original Pi 3 hardcoded MADT
blobs and Windows 10 doesn't boot on the Pi 3 if set to 0.
* Use 2 for GIC version in GIC_DISTRIBUTOR_INIT, since the Pi 4 GIC
is v2 only.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
The PWM controller device specifies both CPU and VPU memory ranges.
CPU base addresses are provided as offsets to BCM2836_SOC_REGISTERS,
and VPU base addresses are constants.
But in Dsdt.asl, both offsets and constant addresses are seen as offsets
by QWORDMEMORYSET macro, result in incorrect VPU memory ranges.
This commits adds a new QWORDBUSMEMORYSET macro to handle VPU memory
ranges with constant base addresses.
Signed-off-by: GH Cao <driver1998@foxmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
GPU devices are in container GPV0 for DMA constraints now, but references in
Rhpx.asl and Uart.asl are not updated, which breaks the rhproxy driver of
Windows 10.
Signed-off-by: GH Cao <driver1998@foxmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
There's no real reason to have the PPTT constants factorized in
AcpiTables.h, and hiding them away with the interrupts is only
going to end up being counter-productive for folks trying to
understand or maintain the code.
Move these sections to Pptt.aslc where they belong.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.
Add a static PPTT table with one L2 cache and an L1I/L1D cache
for each of the 4 cores. The cache size/assc/policy/etc are from
the public docs.
The source from the aslc is derived from the one in:
Silicon/AMD/Styx/Drivers/AcpiPlatformDxe/Pptt.aslc
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Legacy devices on a Raspberry Pi sit behind GPU/VideoCore and can only
address the first GB of RAM.
This address range of 0xc0000000-0xffffffff requires a translation,
since it is aliased to the first GB of memory 0x00000000-0x3fffffff,
which is what this commit accomplishes by introducing a new "GDV0"
device along with a "_DMA" ResourceTemplate that performs the address
translation.
Note that this translation does not apply to the ARM cores, PCIe,
GENET, and 40-bit DMA channels, that all have a wider view of the
address space.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
In order to describe the DMA constraints of legacy devices behind
the Raspberry Pi GPU/VideoCore, we move them into their own separate
ASL file.
This is a straight copy of the existing content from Dsdt.asl, with
no alteration, so that the changes applied in the next patch are
made more obvious.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Only apply the "BC2836" override to the one table that needs it for
Pi 3, instead of setting it globally.
Use more appropriate OEM and Vendor IDs for hardware that is
produced by the Raspberry Pi Foundation.
Ensure that the Pi 3 and Pi 4 have different OEM IDs.
Additionally fix a comment typo (MEMORY32SETBASE -> MEMORY32FIXED).
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Instead of going through a model #ifdef, the call to
EFI_ACPI_5_1_GICC_STRUCTURE_INIT () is factorized by
setting up a new set of PCDs.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Per https://github.com/MicrosoftDocs/windows-uwp/issues/1751,
MsftFunctionConfig () calls can be replaced by PinFunction () calls.
Since these had been converted to VendorLong () blobs due to lack of
implementation of MsftFunctionConfig (), we replace them back now
that PinFunction () is available.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Some of the Pi 4 interrupts were copied from Pi 3 and are incorrect.
We fix the ones that can be found by decompiling the official .dtbs.
We also add a couple more GPIO interrupts, that are used for both
the Pi 3 and the Pi 4, as per the dtbs.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Silence 2 warnings from pep.asl:
* "Warning 3133 - Unknown reserved name (_GPI/_GCI/_GDI)"
* "Warning 3150 - Empty Resource Template", which is caused by
section "Name (_CRS, ResourceTemplate () {})"
Remove "Offset(0)" in Xhci.asl, which produces the warning:
"Unnecessary/redundant use of Offset operator".
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
With the ACPI source for the Pi 3 and Pi 4 being identical, we can
finally factorize it.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
