The new changes in SecureBootVariableLib brought in a new dependency
of PlatformPKProtectionLib.
This change added the new library instance from SecurityPkg to resolve
RaspberryPi platforms build.
Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
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 CM4 has a number of carrier boards with PCIe
slots. With the PCIe changes in place its quite
possible to utilize a NVMe root device. Lets allow
people to boot from it.
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-By: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
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>
Commit 2f0188b56e ("Revert "Platform/RaspberryPi: Setup option for...")
mistakenly introduced to files which are residues from a
conflict resolution. Fix that.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
The genet is capable of addressing the entire memory space
on the RPI4. Lets allow it to dma into those regions.
This solves intermittent issues with grub/etc being able
to communicate when the 3G limit is lifted on 8G boards.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Jared McNeill <jmcneill@invisible.ca>
This commit allows to initialize Secure Boot default key
and databases from data embedded in firmware binary.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # on Raspberry Pi 4
The edk2 patch
SecurityPkg: Create library for setting Secure Boot variables.
removes generic functions from SecureBootConfigDxe and places
them into SecureBootVariableLib. This patch adds SecureBootVariableLib
mapping for each ARM platform which uses SecureBootConfigDxe.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Graeme Gregory <graeme@nuviainc.com> #SbsaQemu
Reviewed by: Sami Mujawar <sami.mujawar@arm.com> #ArmVExpress
Modify platform boot to check the value of BootDiscoveryPolicy variable
and use BootPolicyManager Protocol to connect devices specified by the
variable.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-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>
In order for the WiFi to work, and the SD to run at full
speed we need to bind the SD slot to the eMMC2 controller.
Since we now have a driver for the eMMC2 controller
there isn't any reason to leave the SD card bound
to the older Arasan controller.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
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>
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 b5701a4c7a0fb185e0c5b9db9525939c78664bfd introduced RngLib
dependency for OpensslLib, and caused the RPi build to break for lack
of an RngLib instance.
This patch adds RngLib using the DxeRngLib flavor, which is a wrapper
around the the EFI_RNG_PROTOCOL that the platform already produces.
Tested booting OSes and running the SCT test for EFI_RNG_PROTOCOL.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.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>
