| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The Universal Graphics Adapter (UGA) is a graphic abstraction.
The UGA I/O and Draw protocols are deprecated since UEFI 2.0 was
introduced. Cf. the UEFI spec v2.9:
"Appendix L - EFI 1.10 Protocol Changes and Deprecation List"
section L.2 "Deprecated Protocols"
Remove the UGA support.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
|
|
Commit 7516ab83ff67 ("Update ArmMmuLib library path") did what it says,
but some packages in the tree have their own modules making use of
ArmMmuLib, without previously having declared a dependency on UefiCpuPkg.
Add the missing dependencies.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
|
|
Map individual users of obsolete EmbeddedPkg FdtLib to that version
for now - they will need converting.
Signed-off-by: Leif Lindholm <leif.lindholm@oss.qualcomm.com>
|
|
Commit 991b802e8f70 ("Platform/RPi4: Allocate more space for UEFI
image") reorganized the Flash Device (FD) layout to accommodate the
growing size of the firmware, and reserved some additional space to be
used for ACPI PCC channel data in the future.
This additional allocation was added at the end of the FD, after the
varstore image, while the mapping code in PlatformLib expects the
varstore related regions to live at the very end.
The upshot is that the varstore region in the FD is no longer mapped for
runtime access, resulting in runtime service crashes when attempting to
access the varstore from under the OS.
Fix this in PlatformLib, by extending the varstore memory region to
include everything that comes after it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
edk2-platforms.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
|
|
Replaced the deprecated EFI_D_{INFO,WARN,ERROR,VERBOSE} usage with
DEBUG_{INFO,WARN,ERROR,VERBOSE}.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
|
|
edk2 PR https://github.com/tianocore/edk2/pull/6048 moves
AsmMacroIoLib.h and AsmMacroIoLibV8.h to MdePkg and renames
them to Arm/AsmMacroLib.h and AArch64/AsmMacroLib.h, respectively.
This updates all edk2-platforms in one go, as this is a breaking
change and no functional change.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Continuous-integration-options: PatchCheck.ignore-multi-package
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
Remove all the ArmPlatformLib routines that are no longer used now that
the MPCore SEC drivers have been retired. The prototypes will be removed
from the ArmPlatformLib library class in a subsequent EDK2 change.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Nhi Pham <nhi@os.amperecomputing.com>
Tested-by: Nhi Pham <nhi@os.amperecomputing.com>
|
|
Drop the now unused EfiResetSystemLib implementation, which has been
superseded by the generic one from EDK2.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
Drop the reference to the special reset runtime DXE driver in
EmbeddedPkg, and move to the one in MdeModulePkg shared between all
architectures. This version implements reset notifications, allowing us
to retire the home grown version of that functionality in a subsequent
patch.
Add depexes to the components that rely on the reset notification
protocols to ensure that they are not dispatched before those protocols
are made available by the reset runtime DXE driver.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
Duplicate the logic that is triggered on a system reset into the
platform boot manager driver, and hook it up to the EDK2 platform
specific reset notification driver. This is supported by generic EDK2
code in MdeModulePkg, allowing us to retire the platform-specific
EfiResetSystemLib implementation in a subsequent patch. This is needed
because this library class and its only user ResetRuntimeDxe in
EmbeddedPkg are deprecated and are going to be removed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
Mark RAM ranges as write/execute protectable in the GCD memory map. This
is needed to avoid issues with NonCoherentDmaLib in EmbeddedPkg, which
will fail if it does not manage to set the EFI_MEMORY_XP attribute on
the allocated DMA buffers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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 94e9fba43d7e132be3c582c676968a7f408072c1 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 678f6bff3c46 ("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>
|
|
Port tianocore/edk2@2d233af64b8f73d1b1e138b302e6344f7c2e0f4e
This enables network boot by default on RPi first boot, when all other
boot options fail. This is required for unattended/headless boot cases.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.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>
|
|
Due to the nature of USB init on the Pi platforms, commit
c8000ecccc83b728baf04ced2fedb870bc3bc1b3 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>
|
|
Query the firmware for the clock rate that is used to drive the
16550 baud clock, so that we can program the correct baud rate.
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>
|
|
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>
|
|
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>
|
|
implementation
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>
|
