| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch adds checks if Boot Discovery Policy has been changed. Only
in that case EfiBootManagerRefreshAllBootOption() should be called.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Since we are updating the DT memory map and telling it how
we have configured the PCIe, there isn't a reason for moving the
MMIO window. In fact this appears to fix OpenBSD+DT as well as
it makes the linux XHCI reset sequence happier.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
It's a complete tossup whether removing the mailbox call after we have
set up the XHCI works for a given kernel+distro in DT mode. So lets give
users who want to try DT the option of flipping this on/off.
Users that don't want to have to deal with DT, can use ACPI.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
Lets allow some of these options to change when the
system is in ACPI+DT mode. Plus the fan temp should
be disabled when ACPI isn't enabled.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
ImagePropertiesRecordLib is used by DxeMain and PiSmmCore, so it
needs to be added to most platforms.
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
|
|
acpiview complains:
ERROR: On Arm based systems, all cache properties must be provided in
the cache type structure. Missing 'Write Policy Valid' flag.
ACPI specification says:
> Set to 1 if the write policy attribute described is valid. A value
> of 0 indicates that, where possible, processor architecture specific
> discovery mechanisms should be used to ascertain the value of this
> attribute.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
MpServicesTest was dropped in favor of EfiMpServiceProtocolShellUnitTest.
Update the dsc file accordingly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Fix the ARM_MPCORE_INFO table and incorporate the DXE driver and test
app to the build so that EFI_MP_SERVICES_PROTOCOL can be used and tested
on Raspberry Pi 4. Note that the test app is not added to the image - it
can be taken from the build directory and executed from the UEFI shell.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@quicinc.com>
|
|
To make sure the XHCI controller does not get reset by Linux in DT mode,
we remove its pci parent node from the device tree. However, the pci
node address has been updated in the Raspberry Pi 4 device tree [1] and
no longer matches the one we are trying to remove in SyncPcie(). This
results in the XHCI controller actually being reset by Linux, which
leads to errors during USB initialization:
[ 3.563963] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 3.569538] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[ 3.577452] xhci_hcd 0000:01:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000040000000890
[ 3.587725] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 3.593115] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2
[ 3.600693] xhci_hcd 0000:01:00.0: Host supports USB 3.0 SuperSpeed
[ 3.608106] hub 1-0:1.0: USB hub found
[ 3.612026] hub 1-0:1.0: 1 port detected
[ 3.616819] hub 2-0:1.0: USB hub found
[ 3.620726] hub 2-0:1.0: 4 ports detected
[ 3.875902] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 4.008123] usb 1-1: device descriptor read/64, error -71
[ 4.256088] usb 1-1: device descriptor read/64, error -71
[ 4.495882] usb 1-1: new high-speed USB device number 3 using xhci_hcd
[ 4.628111] usb 1-1: device descriptor read/64, error -71
[ 4.872083] usb 1-1: device descriptor read/64, error -71
[ 5.407888] usb 1-1: new high-speed USB device number 4 using xhci_hcd
[ 6.023964] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
[ 6.239977] xhci_hcd 0000:01:00.0: Setup ERROR: setup address command for slot 1.
This patch allows matching any address for the pci node, thus working
with both legacy and new device trees.
[1] https://lore.kernel.org/all/20210831125843.1233488-1-nsaenzju@redhat.com/
Fixes: efff29cdcdb7 ("Platform/RaspberryPi: Always use non translating DMA in DT mode")
Signed-off-by: Adrien Thierry <athierry@redhat.com>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
|
|
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>
|
|
The IORT Specification E.d updates the IORT table revision to 5. To
reflect this change the IORT header file has been updated to rename
the EFI_ACPI_IO_REMAPPING_TABLE_REVISION macro which was at Rev 0 to
EFI_ACPI_IO_REMAPPING_TABLE_REVISION_00.
Therefore, update the usage of EFI_ACPI_IO_REMAPPING_TABLE_REVISION
macro in the IORT table for RaspberryPi platform to
EFI_ACPI_IO_REMAPPING_TABLE_REVISION_00.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3479
Adds an instance for the library class VariableFlashInfoLib that
was recently introduced in MdeModulePkg. This change is made to
allow the new variable driver to build that has a dependency on
this library class and does not require any further platform
changes.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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>
|
|
In theory we should be properly cleaning up all the device drivers before
hitting the big reset. The partition manager will issue flush commands to
attached disks as it goes down. This assures that devices running in WB mode,
which correctly handle flush/sync/etc commands, are persisted to physical
media before reset.
Without this, there are definitely cases where the relevant specifications
don't guarantee persistence of data in their buffers in the face of reset
conditions. We can't really do anything about the many devices that don't
honor persistence requests, but we can start here.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The EFI spec seems to indicate that the EFI uncacheable attribute
should be mapped to device memory rather than normal-nc. This means
that the UEFI mem attribute for the >3G ram doesn't match the remainder
of the RAM in the machine.
So, lets remove the uncacheable attribute to make it more consistent.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
It appears that the locking for many of the mailbox commands is
incorrect. All UEFI firmware calls to the RPi mailbox share a single
mDmaBuffer. That buffer is used to fill out the command passed to the
vc firmware, and record its response. The buffer is protected by
mMailboxLock, yet in many cases the mailbox response is copied from
the buffer after the lock has been released. This doesn't currently
appear to be causing any problems, but should be fixed anyway.
There are a couple other minor tweaks in this patch that are hard to
justify on their own, one is a bit of whitespace cleanup, and the
other is the addition of a debug message to print the returned clock
rate for the requested clock. This latter print would have immediatly
shown that the vc firmware was returning 0 as the emmc clock rate
rather than something reasonable.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
The build has been tossing a warning about having two defaults
for a while now, lets fix it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
One of the many issues with the PCIe on this platform is its inbound
DMA is either constrained to the lower 3G, or on later SOC's a
translation may be used. That translation is problematic with some of
the OS's expected to boot on this platform. So, across the board a 3G
DMA limit is enforced during boot when in ACPI mode. This itself
causes problems because the later boards removed the SPI EEPROM used
by the onboard XHCI controller, instead favoring using a block of RAM
to load its firmware. Hence it is the lower level firmware's
responsibility via a mailbox call, to read the bridge
translation/configuration before telling the XHCI controller where it
can find its firmware.
Everything is great in ACPI land. Now it appears that Linux after
reprogramming the bridge to match the DT (when using a translation)
can't actually get the XHCI/quirk/reset to function. Apparently,
because the firmware only reads the bridge configuration the first
time its called(?), or the kernel reset sequence isn't correct. Worse,
with just the DMA ranges corrected, the XHCI/QUIRK itself then causes
the controller to start having what appear to be DMA issues.
Lets simplify the situation and make all DT's provided by this
firmware have a 3G DMA limit on the PCIe bus. Then remove the ability
for Linux/etc to trigger the quirk by remove the DT node attaching the
reset controller to the XHCI. The latter seems somewhat questionable,
since the DT/PCIe host bridge driver is doing what appears to be a
PERST which might then require a firmware reload, but at the
moment seems to work without.
The first part of this patch also appears to fix a problem with
OpenBSD which interprets the DT as describing how the firmware
has configured the device, and makes no attempt to reconfigure it.
Hence the newer SOC's implementing a translation fail to boot
since the DT being passed to the OS doesn't match the translation
the firmware has setup.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The MMIO host bridge window isn't translated as both the primary
and secondary side are MMIO. So remove the incorrect
TypeTranslation attribute.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
With the upcoming release of Windows 11, Microsoft has introduced a new USB
Device-Specific Method (_DSM) function to enforce 64-bit xHCI registers to
be accessed through two sequential 32-bit requests. The new function (Query
controller register access type - Function 6) is documented at:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-
Support for this feature is required on the Raspberry Pi 4 where there is
a bug/limitation in the xHCI stack that prevents full range 64-bit access
from working correctly. It should be noted that an equivalent for this _DSM
is not required on Linux, as 64-bit xHCI register access is already broken
down into 2x32-bit by the drivers there.
With this _DSM, and unlike what is the case for Windows 10, Windows 11 can
now be installed on the Raspberry Pi 4 without having to alter any of the
installation files, as we were able to validate using the latest Windows 11
Build 22000 Insider image.
Signed-off-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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>
|
|
Linux, for the time being has refused to support the Arm
standard SMCCC for PCIe configuration. Instead they
want to continue to maintain per device "quirks".
As the RPI isn't really ECAM this is a bit more
involved because the MCFG can't really describe
the root port+config registers situation. Further
platforms which support the SMCCC shouldn't have
a MCFG, so we need an additional way to tell linux
what it needs to know about this platform.
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>
|
|
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>
|
|
Since we plan on toggling between XHCI and PCI the PCI
root needs to be in its own SSDT. This is all thats needed
of UEFI. The SMC conduit is provided directly to the running
OS. When the OS detects this PCIe port on a machine without
a MCFG it attempts to connect to the SMC conduit. The RPi
definition doesn't have any power mgmt, and only provides
a description of the root port.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jared McNeill <jmcneill@invisible.ca>
|
|
Lets prepare to switch between XHCI and PCI by moving
the XHCI definition into its own SSDT. That way we can
select it based on the menu settings. The resource
producer/consumer flag is also corrected.
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Jared McNeill <jmcneill@invisible.ca>
|
|
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 2f0188b56ef4 ("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
|
|
This reverts commit efdc159ef7c9f15581a0f63d755a1530ff475156.
This commit is not longer required as Boot Discovery Policy has been
implemented for Raspberry Pi.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
|
|
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>
|
|
Remove non-standard RPI ACPI _CIDs that are not needed.
This also fixes the FWTS failure reported in
https://github.com/pftf/RPi4/issues/67
The windows drivers at https://github.com/raspberrypi/windows-drivers
are still able to match the ACPI objects using the HIDs which
are supported in the drivers, with these two recent changes needed:
6469702898789e555c6947e50216a3f79e0ddeb9
and
5c5e2742b4c983b3001c473b168b0dae2fcba0c2
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Mario Bălănică <mariobalanica02@gmail.com>
Signed-off-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Tested-by: Mario Bălănică <mariobalanica02@gmail.com>
Reviewed-by: Sunny Wang <sunny.wang@arm.com>
Tested-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
This change is based on edk2-platforms-raspberrypi-pl011-bth-noflow.diff
in https://github.com/worproject/RPi-Bluetooth-Testing/ with the
modifications and additional changes below for enabling Bluetooth
and serial port (Mini UART) in Windows IOT.
- Remove RPIQ connection for BT_ON/OFF in Uart.asl because it is
useless. The firmware already turns on the Bluetooth by default.
- Move the GPIO pin muxing stuff from Uart.asl to ConfigDxe driver.
Testing Done:
- Successfully booted Windows Windows 10 IOT (20279.1) on SD (made by
WOR) with the RPi-Windows-Drivers release ver 0.5 downloaded from
https://github.com/worproject/RPi-Windows-Drivers/releases
and checked that both Bluetooth and serial port (Mini UART) can
work fine.
- Successfully booted VMware ESXi-Arm Fling v1.3 with only serial
console connection (PL011 UART).
Signed-off-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>
|
|
The newer BCM2711 SoC's don't have a DMA constraint on the emmc2
controller. So we don't need to do the 1G translation. Lets
allow the AML to detect the SoC revision and return a different
_DMA resource.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Add some additional IORT nodes for the USB & EMMC devices, realistically
we probably only need to have a single node with the lowest AddressSizeLimit
but this is conceptually "cleaner" should anyone actually try and use these
values rather than the _DMA provided ones.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
The arasan caps registers are no longer being overridden by
the brcm iproc driver, so we should be assuring that the
"High Speed Support" bit 21 is set in the capability
register. This significantly improves the wifi perf
using linux.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
As per ACPI 6.3 specification, the DSDT/SSDT table should use revision 2
, so update the revision numbers to 2.
This also fixes https://github.com/pftf/RPi4/issues/94 (FWTS failures).
Testing Done:
- Booted to UEFI Shell and used apciview command to check all ACPI
tables' revision.
- Ran FWTS test and no longer see the ACPI DSDT and SSDT revision
failures. Note that the XSDT revision failure is caused by the FWTS
tool's issue that got fixed in
commit c522bfedc9839a474b8d590ba36bec77436d2e90
Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Signed-off-by: Sunny Wang <sunny.wang@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie> # Windows 10 boot
|
|
Convert SsdtThermal.asl to CR/LF like the rest of the sources.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
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>
|
|
The VPU clock divisor has changed in this commit:
https://github.com/raspberrypi/firmware/commit/1e5456a, thus breaking
the mini UART clock divisor calculation on the Pi 4.
Fix this by reading the core clock from the mailbox instead.
Signed-off-by: Mario Bălănică <mariobalanica02@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246
MdeLibs.dsc.inc was added for some basic/default library
instances provided by MdePkg and RegisterFilterLibNull Library
was also added into it as the first version of MdeLibs.dsc.inc.
So update platform dsc to consume MdeLibs.dsc.inc for
RegisterFilterLibNull which will be consumed by IoLib and BaseLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
DwHcReset expects attributes as the second argument. A reset is
performed if the passed attribute is valued. However 0 is not a valid
attribute and will thus never cause a controller reset.
Passing EFI_USB_HC_RESET_HOST_CONTROLLER will reset the dwc2 controller
as expected.
This enables the USB 2.0 port of the raspberry compute module 4.
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Signed-off-by: René Treffer <treffer@measite.de>
|
|
The new emmc2 device adds a container with a _UID of 0 which duplicates
an existing ACPI container.
This causes windows to fail to boot with a Stop ACPI_BIOS_ERROR. The
workaround without this fix is to go into the BDS menus and set the SD
routing to the Arasan.
Fixes: 311ed3c790 ("Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan")
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
The 3G limit, and the 2G IORT are intended to solve
the same linux problem. They limit PCI DMA operations
to the first 3G of RAM. Older linux kernels, as
used with RHEL/Centos, trigger an assertion*
when a DMA operation starts at a range that
doesn't fit within the 2G range specified by the IORT.
The simple solution is to only enable the IORT
when the 3G flag is disabled and there is more
than 3G installed.
* https://github.com/pftf/RPi4/issues/123
Fixes: dac891da5cf3 ("Platform/RaspberryPi/AcpiTables: add a IORT ACPI table to limit XHCI DMA")
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
|
|
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>
|
