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>
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>
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>
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>
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>
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>
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>
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>
Remove the PlatformPcdLib. It is completely unnecessary. Originally,
this was meant for the GENET driver, but now that ConfigDxe registers
the platform device, the library is superfluous.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
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>
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>
Initially, FdtDxe used an internal (embedded in UEFI) FDT, because it
was neither understood how to consume the one loaded by the VideoCore
firmware, nor understood just how important it is to use the DTB
provided by config.txt.
Embedding the DT was a bad idea, because:
- Permanently stale
- No overlays
Also, on devices like the Pi 4 you _have_ to have a DT around for the
start4 VPU firmware to pick up, otherwise the board is left in an
inconsistent state. So we're being prescriptive now about DT use with
config.txt, which means this internal DT logic is dead code.
Further FdtDxe cleanups are possible and will be handled separately,
specifically:
- probably no need to use a separate allocation for patched DT (optimize
memory used)
- suspicious use of EfiBootServicesData (I filed [0] to sort out the real
requirements)
Testing: Booted Ubuntu 18.04 on Pi 2B (1.2).
[0] https://github.com/ARM-software/ebbr/issues/45
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
A rev-up of start.elf VPU firmware meant that the previous scheme of
loading the DTB over top of RPI_EFI.FD no longer works - the DT is now
loaded way before the armstub, so any overlap means the DT is overridden.
This change re-arranges a few items in the FD, allowing the DTB to loaded
directly after the FD in physical memory.
Unlike the Pi 4 implementation, we can't move the UEFI image down in memory,
as that needs a TF-A changem so it just reduces the size by 0x10000. The
same base address (0x1f0000) is used as on the Pi 4.
The Pi 3 FDF can be further unified with Pi 4 after work on TF-A to move
to a single BL32-based Pi 3 TF-A implementation.
Tested: Pi 3A+, Pi 2B v1.2, Pi 4B (4GB).
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
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>
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>
A rev-up of start4.elf VPU firmware meant that the previous scheme of
loading the DTB over top of RPI_EFI.FD no longer works - the DT is now
loaded way before the armstub, so any overlap means the DT is overridden.
This change re-arranges a few items in the FD, allowing the DTB to loaded
directly after the FD in physical memory.
This moves UEFI image down by 0x10000, and reduces the FD image size by
0x10000, leaving space for a DTB to be loaded by config.txt at 0x1f0000.
You need a matching "rev RPi4 TF-A for DTB fix" patch to edk2-non-osi,
as it requires a TF-A build with these options:
PRELOADED_BL33_BASE=0x20000 RPI3_PRELOADED_DTB_BASE=0x1f0000
Note: the same problem still affects the Pi 3, and will be
fixed in a separate change.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
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>
Add an ACPI_BASIC_MODE_ENABLE flag to produces builds intended to run in
ACPI mode without any additional requirements (memory limits, acpi=force,
etc).
This flag is disabled by default.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
This patch improves memory initialization for the Raspberry Pi Platform by:
Using VideoCore mailbox data to reserve only the regions that are actually
mapped. Especially, besides the base RAM size, which was already set using
VideoCore data, we can set the GPU/VideoCore base address as well as the
extended RAM, which is the memory beyond 1 GB that is available on models
such as the Raspberry Pi 4 (for the 2GB or 4GB versions).
Introducing a new PcdExtendedMemoryBase PCD for the base address of the
extended memory region, which currently cannot be retrieved from VideoCore
(MBOX_GET_ARM_MEMSIZE still only returns a single region on Bcm2711).
Introducing a new RpiPlatformGetVirtualMemoryInfo() companion call to
ArmPlatformGetVirtualMemoryMap() that allows us greatly simplify the
registration of each segment in MemoryPeim() as well as making it easier
to maintain for future models.
We also fix SoC register space that should have been marked as reserved
but wasn't until now and remove the unreferenced mSystemMemoryEnd extern
in MemoryInitPeiLib.c.
RaspberryPiMem.c incorporates some code from ArmJunoMem.c.
Signed-off-by: Pete Batard <pete@akeo.ie>
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>
