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>
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>
The RPi4 TF-A is much smaller than RPi3 TF-A, and doesn't need
an extra 2MB region.
Note: this depends on the edk2 ArmPlatformPkg/PrePi: fix IS_XIP.
Signed-off-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
Splitting the RAM descriptors is required so that we can make the 3 to 4 GB
segment of the Raspberry Pi 4 a user-configurable option.
This also removes the need for the PcdAcpiBasicMode PCD.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Back in RaspberryPiPkg (before upstream Pi 3) support, I wrote
some extra code in PlatformBootManagerLib and BootGraphicsResourceTableDxe
to clear out the logo/BGRT, so that Windows would always show its own
logo instead of the platform logo. It kind of made sense back in the day,
when they only portion of Windows that "ran" on Pi 3 was the part that
could display a logo before BSODing...
The code in PlatformBootManagerLib (that this patch is removing) only
worked with the matching BootGraphicsResourceTableDxe change*** that
never got upstreamed. Moreover, Windows (for logo/cert) requires BGRT
so these kinds of shenanigans aren't worth the effort.
So, remove the dead code.
***https://github.com/andreiw/RaspberryPiPkg/blob/master/edk2Patches/0003-BootGraphicsResourceTableDxe-properly-handle-SetBoot.patch
Signed-off-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-By: Pete Batard <pete@akeo.ie>
Tested-By: Pete Batard <pete@akeo.ie>
The Raspberry Pi platform contains two UARTs, one PL011-based and the
other (called miniUART) 16650-compatible, that are pinmuxed to the GPIO
serial port according to whether a Device Tree overlay is present in
config.txt or not. In most cases, it takes only the user commenting or
uncommenting an overlay line in config.txt to switch between PL011 and
miniUART.
As such, the use of a build time option to select the UART should be
avoided when it is effectively possible to detect which of the UART is
in use at runtime, through a simple MMIO call.
This patch does just this by adding a new DualSerialPortLib that
directs the SerialPortLib implementation to use either 16650 or PL011
according to the GPIO pinmuxing.
It should be noted that this code mostly a merge of
* MdeModulePkg/Library/BaseSerialPortLib16550
* ArmPlatformPkg/Library/PL011SerialPortLib
with non-relevant elements stripped from BaseSerialPortLib16550 (such
as PCI support) and a new call added to retreive the 16650 baudrate
divisor, since it is dependent on the platform's VPU's clock divisor.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The Genet driver stub used by the Raspberry Pi 4 platform is
designed to set the MAC address according to a PCD.
To be able to set that PCD at runtime, by using the Raspberry
Pi firmware interface, that has a dedicated call to retrieve
the MAC address, and satisfy driver dependencies in a generic
manner, we create a new PlatformPcdLib that can be referenced
by the Genet driver, to set the MAC PCD before use there.
While it is currently only tailored around MAC PCD population
for Genet, we do expect this PCD library to be extended in the
future, to provide additional PCD facilities for other drivers.
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>
When using ACPI OpRegions to poke device registers, Linux will use
the UEFI memory map to decide which memory attributes to use, and
so they should not be described as cacheable memory.
Since MMIO regions that don't require an OS virtual mapping at runtime
don't really belong in the UEFI memory map to begin with, omit them
entirely.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Having RAM and SoC register regions overlap is problematic for MMIO,
since, at the very least, we don't want these regions to be declared
as cacheable.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
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>
Besides the base memory size, we can read the GPU/VideoCore base as
well as the model during early init, which we'll need for improving
the memory mapping.
This patch adds the retrieval of these variables, as well as some
early debug display of their values (which can be useful) and also
removes unused variables such as mGPUMemoryBase and mGPUMemoryLength.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@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>
