| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
__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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
According to the bug:
https://bugzilla.tianocore.org/show_bug.cgi?id=2777
the deprecated code under DISABLE_NEW_DEPRECATED_INTERFACES
will be removed, which will result in compilation breakage
of the Raspberry Pi platforms. Prevent that by switching to
the different PcdSet API.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
|
|
Add support for configuring the Chassis Asset Tag in the UI as well as
UEFI Shell, and carry the configured value as the Asset Tag string
in SMBIOS Types 2 and 3.
To configure using the UEFI Shell, use 'setvar' command to read/write
the UEFI variable with GUID = gConfigDxeFormSetGuid and Name="AssetTag".
For example:
Shell> setvar AssetTag -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs
-rt -nv =L"ABC123" =0x0000
This resolves this Github issue: https://github.com/pftf/RPi4/issues/54
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
|
|
The "Verbose ExitBootServices" feature was originally added to the RPi
as part of early OS enablement to show that the OS boot loader did
actually call ExitBootServices (back when OS boot used to crash shortly
after that). This is no longer needed, and should be removed as part of
cleaning the RPi PlatformBootManager to be more in-line with the ArmPkg
version.
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
This makes all 8GB usable on the Pi 4 8GB variant.
Like RAM in the 3-4GB range, this is still gated by the
option to limit RAM to 3GB.
Tested on 4GB and 8GB boards, with and without 3GB limit.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Newer Pi 4 boards (such as 8GiB variant) no longer carry a SPI
EEPROM with the VLI805 (USB) controller firmware. So, ask the
VPU firmare to load the image it has into the controller
specified by BDF.
This is benign on non-8GiB boards (reloading that firmware if
VPU fw is new enough or doing nothing on old VPU firmware).
Tested on 4GB. Also have a positive test report for an 8GB board
from a forum member.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
Register an event at EndOfDxe to instantiate the EFI device path protocol
with the GENET MAC address on a new handle, and install the
BcmGenetPlatformDeviceProtocol on that handle. This protocol is used to
pass platform information (GENET MAC address and register base address)
to the GENET driver, which will consume this in its implementation of the
UEFI driver model Supported/Start/Stop methods.
Co-authored-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Co-authored-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Co-authored-by: Andrei Warkentin <awarkentin@vmware.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
|
|
Do some preliminary cosmetic cleanup on ConfigDxe before making
actual changes in a subsequent patch.
Co-authored-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Co-authored-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Co-authored-by: Andrei Warkentin <awarkentin@vmware.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
|
|
Today the Pies can be booted in a way where only ACPI is exposed,
or both ACPI and DT are exposed.
This adds one more mode - DT only, no ACPI. The target audience
is developers. When both are exposed, it's up to the OS to decide
which gets used, and that choice can differ between OSes,
Note: this does _not_ change defaults. Pi 3 still defaults to
ACPI + DT, while Pi 4 still defaults to ACPI only.
We don't really want to remove DT + ACPI mode - it is the default
on Pi 3, and removing it is bound to just annoy users - WoA and
NetBSD (voa UEFI) on Pi 3 only work with ACPI, while everything
else (Linux, FreeBSD) only work with DT. I'd make an analogy of
MPS and ACPI being exposed for the longest time ever together on
PCs.
Testing: OpenBSD on Pi 4 with DT-only and ACPI-only boots.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
To avoid hardcoding constants for non-obvious fields (e.g. enum
instead of basic enable/disable), move variable structure and value
definitions into a separate header, ConfigVars.h.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Now that RPi3 supports CM3, let's edit the flash controller
options a bit.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
The Pi 2B v1.2 uses the same SoC as Pi 3B/3B+, but reports self as model 2.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
SD Host is not usable on Pi 4 so replace it with an eMMC2 option.
Note that is a menu only change at this stage, since we don't have
eMMC support finalized.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Improve the CPU frequency settings of the platforms by:
- Adding a "Default" option that sets the frequency to the
official default for each model/submodel.
- Adding a "Low" option, that sets the frequency to a fixed
PCD, custom to each platform.
- Using fixed PCDs to set the maximum and default values for
the custom frequency range, according to the overclocking
capabilities of the platform.
- Ensuring that the firmware defaults to using the platform's
default frequency, instead of a low arbitrary value.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This fixes "WARNING: default value re-defined with different value"
being produced when trying to set default values for the Scaled
VModes in ConfigDxeHii.vfr.
This warning is generated regardless of what the default value is
being set to and since we don't actually care about setting a default
value, as long as the PCD is properly set, we choose to simply remove
the default.
We also ensure that all the PCDs are set to the expected default value.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
The original change*** used positive logic (PcdPi4GBEnabled), while the
upstreamed change uses negative logic (PcdRamLimitTo3GB), which
requires an additional condition, or it blows up on 1GiB and 2GiB boards.
Tested on 2GB and 4GB boards (with limiting and without)
*** https://github.com/pftf/edk2-platforms/\
commit/968451beb7c9302517098abf72f7e42b57a0e024
Signed-off-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
Group all SD/MMC settings under the SD/MMC form.
Make CPU settings more prominent.
Harmonise form titles and text content.
Reorder forms in the order they are most likely to be queried.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
With this and the previous commit, ACPI_BASIC_MODE_ENABLE becomes
superfluous so remove it.
New option defaults to enabled on Pi 3, disabled on Pi 4.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Currently some OSes (e.g FreeBSD) can make full use of the maximum
4 GB of RAM a Raspberry Pi 4 can offer, whereas others (e.g. Linux)
must be restricted to only the first 3 GB.
Previously this was a compile-time choice chosen by PcdAcpiBasicMode,
and now we make it user-selectable. The default is a 3 GB limit.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Move away from AcpiPlatformDxe for loading ACPI tables. Instead, use
ConfigDxe. This will allow selective loading/patching to enable
different SBBR/EBBR profiles.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
The Raspberry Pi 4 has a new SD controller. As a result we must
handle SD routing according to the model, which we perform in
the Config driver by using the GetModelFamily () call that was
recently introduced.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Define BCM2836_SOC_REGISTERS from PcdBcm283xRegistersAddress. This is
needed in preparation for adding Raspberry Pi 4 support, since the two
Pi's have a different base addresses for the Bcm283x specific registers.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
|
In preparation for adding Raspberry Pi 4 support, the Pi 3 platform
is restructured by factorizing all the drivers and libraries that are
going to be commonly used by the two platforms.
Because much of the Pi 4 SoC is an extension of the Pi 3 one this
means that almost everything, except the ACPI tables, is moved up
into a new common RaspberryPi/ subdirectory that will serve both
platforms. The .dec is also moved to this directory, under a new
RaspberryPi.dec name, and existing references to it are updated.
This commit requires the edk2-non-osi in use to contain commit 243e55f622ea
in order to build.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
