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>
