| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Lets add some further mailbox helpers and convert the existing
RpiFirmwareSetLed into a generic SetGpio() function.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
Lets sync our mailbox commands with the known/Linux
constants so that we have a more complete view of
what we can request from the VPU.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
|
|
Fix https://github.com/pftf/RPi4/issues/100 by swapping RPi DisplayDxe
resolution settings for 640x480 and 800x600, which were incorrectly
mapped to the settings shown in the Setup configuration variable.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
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>
|
|
The Raspberry Pi 3 and Pi 4 platforms (with latest EEPROM) can boot
straight from USB, without the need for an SD card being present.
However, the IsCardPresent () calls from the ArasanMmcHost and SdHost
drivers are currently hardwired to return TRUE, which results in
straight to USB boot failing due to the SD drivers looping on
errors while trying to poke at a non-existent card...
Ideally, we would use the Card Detect signal from the uSD slot, to
report on the presence or absence of a card, but the Raspberry Pi
Foundation did not wire those signals in the Pi 2 and subsequent
models, leaving us with only potentially interfering SD commands
as means to perform card detection.
As a result of this, we are left with no other choice but limit
detection to occurring only once, prior to formal SD card init,
and then return the detected value for subsequent calls. This,
however, is more than good enough for the intended purpose, which
is to allow straight to USB boot. The sequence is a simplified
variant of the identification code in MmcDxe.
Tested on Raspberry Pi 2B, 3B and CM3 (for both SD controllers)
and Pi 4 (for Arasan, as that's the only controller available today)
Addresses pftf/RPi3#13, pftf/RPi3#14, pftf/RPi4#37.
Co-authored-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Tested-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
|
|
Add support for configuring the Chassis Asset Tag in the UI as well as
UEFI Shell, and carry the configured value as the Asset Tag string
in SMBIOS Types 2 and 3.
To configure using the UEFI Shell, use 'setvar' command to read/write
the UEFI variable with GUID = gConfigDxeFormSetGuid and Name="AssetTag".
For example:
Shell> setvar AssetTag -guid CD7CC258-31DB-22E6-9F22-63B0B8EED6B5 -bs
-rt -nv =L"ABC123" =0x0000
This resolves this Github issue: https://github.com/pftf/RPi4/issues/54
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
|
|
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>
|
|
Newer Pi 4 boards (such as 8GiB variant) no longer carry a SPI
EEPROM with the VLI805 (USB) controller firmware. So, ask the
VPU firmare to load the image it has into the controller
specified by BDF.
This is benign on non-8GiB boards (reloading that firmware if
VPU fw is new enough or doing nothing on old VPU firmware).
Tested on 4GB. Also have a positive test report for an 8GB board
from a forum member.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.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>
|
|
To avoid hardcoding constants for non-obvious fields (e.g. enum
instead of basic enable/disable), move variable structure and value
definitions into a separate header, ConfigVars.h.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
As part of the analysis done in:
https://github.com/raspberrypi/firmware/issues/1376:
* Bump up max tries, to avoid command time-outs.
* Macro-ify RaspberryPiHelper.S some more to make code more maintainable.
* Add ".align 4" before every command buffer.
Co-authored-by: Pete Batard <pete@akeo.ie>
Co-authored-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
Add a new RPiFirmwareGetModelInstalledMB () call in RpiFirmwareDxe
to return the amount of detected installed RAM on the system (in MB).
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@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>
|
|
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>
|
|
Add GetModelFamily to RASPBERRY_PI_FIRMWARE_PROTOCOL.
This uses the board revision to return a numeric value representing
the RPi family (1=RPi, 2=RPi2, 3=RPi3 and 4=RPi4).
Knowing the Pi family will help us set the SD card routing when we
introduce support for the Pi 4 and should also be easier to maintain
than if using individual model detection.
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>
|
