The Arasan driver now works with the eMMC2 device.
This means that both the PcdSdIsArasan and the
!PcdSdIsArasan result in valid SD controllers on the rpi4.
Lets avoid removing the "stale" boot entry, in this case
which also has the side effect of avoiding a boot assert
when eMMC2 is selected.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Commit 94e9fba43d introduced an unconditional
call to PcdGet32 after we exit boot services, that produces a kernel panic
on Linux reset.
This addendum to the previous commit ensures that we only read the PCD and
apply the delay while we are still in UEFI, which is what we want anyway as
the goal was to fix the storage of NV variables set by the user from within
the UEFI firmware interface.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.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>
Commit 678f6bff3c ("RPi4: reserve/map memory above 4GB when present")
removed the only user of the GpuIndex variable in
ArmPlatformGetVirtualMemoryMap, which causes a build error of NOOPT
profile with gcc 8.3. Delete the variable, and its initialization.
Cc: Andrei Warkentin <andrey.warkentin@gmail.com>
Cc: Pete Batard <pete@akeo.ie>
Signed-off-by: Leif Lindholm <leif@nuviainc.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>
Due to the nature of USB init on the Pi platforms, commit
c8000ecccc introduced a regression
with regards to ensuring that USB devices are operational by the
time the console is up.
This commit fixes this by adding explicit calls to connect USB
controllers before console initialization.
Note that trying to connect a non existent device (e.g. PCI bus
on the Pi 3) is harmless so there's no need to guard these calls
according to the devices effectively supported by the platform.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.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>
The BDS will connect device paths that are considered as boot options,
so there is really no reason to always connect absolutely everything.
So now that all the drivers have been updated to play nice in this
case, remove the ConnectAll() call from the RPi BDS code.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
Acked-by: Leif Lindholm <leif@nuviainc.com>
Take advantage of a recent change to the core EDK2 BDS code that
makes boot options with the LOAD_OPTION_ACTIVE flag cleared visible
in the boot manager menu, so that they can be selected manually
while never being considered for automatic booting (unless selected
specifically via BootNext)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
Acked-by: Leif Lindholm <leif@nuviainc.com>
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>
The Raspberry Pi 3 derives its 16550 baud clock from the variable core
clock, and so any reprogramming of the baud rate needs to take the
actual core clock value into account.
Introduce a DXE phase version of DualSerialPortLib that discovers this
value in its constructor, using the RPi firmware protocol, and wire it
up for the RPi3 platform.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
The 16550 'miniUART' on the Raspberry Pi gets its input clock from
different sources on RPi3 and RPi4. Fix the logic that derives the
divisor for the 16550 baud clock on the respective platforms.
While at it, make the input clock PCD patchable for RPi3 so we can
manipulate it at runtime in a future patch.
Co-authored-by: Pete Batard <pete@akeo.ie>
Co-authored-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Co-authored-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
On DEBUG builds that use the serial port directly for debug output,
every module reinitializes the UART hardware, through the DebugLib
constructor calling SerialPortInitialize.
This is unnecessary, but usually harmless. However, in cases where this
requires information that is non-trivial to obtain (e.g., the rate of
the clock source feeding the baud clock), it results in a special kind
of dependency hell that can only be fully appreciated by seasoned EDK2
connoisseurs [0].
As a first step towards solving this mess, implement a special version
of the Raspberry Pi dual serial port library that only implements the
SerialPortInitialize() and SerialPortWrite() library functions, and make
the former an empty stub. This makes it only suitable for use by modules
that inherit a dependency on SerialPortLib via DebugLib, and requires us
to ensure that the baud clock is programmed correctly by the SEC phase.
Use this version of the library to satisfy all SerialPortLib dependencies
except the ones in PrePi and in SerialDxe. These will retain the full
version, which is the only one that still consumes PcdSerialClockRate.
[0] There are two distinct problems making this mess almost unsolvable:
- SerialPortInitialize() is called directly in various places instead
of relying on constructor ordering, so adding a constructor to a
SerialPortLib implementation does not help,
- Constructor ordering resolution in the EDK2 tooling fails to take
transitive dependencies into account if an intermediate library has
no constructor it self. For instance, if LibA depends on LibB, which
depends on LibC, the constructors of LibA and LibC could be called in
any order if LibB does not have a constructor itself (and fixing this
breaks all the platforms in the tree)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
In preparation of creating different versions of DualSerialPortLib,
split off the parts that will be shared between all versions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-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>
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>
