| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
Add VariablePolicyLib and its dependency.
Testing: Pi 4 boot.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.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>
|
|
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.
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>
|
|
Set the supported RPi3 platform language to English (US),
and remove French.
This fixes https://github.com/pftf/RPi4/issues/35
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Pete Batard <pete@akeo.ie>
Cc: Andrei Warkentin <awarkentin@vmware.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Switch the ASIX USB NIC driver used in the RPi3 to the new Ax88772c.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
Add a section to the the RPi3 readme for 'Configuration Settings', with
instructions on scripting from the UEFI Shell.
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.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>
|
|
The scaled resolutions are useful, but are not the default expected
by most users. Linux and BSDs don't set preferred resolution in
their OS loader, so when booting via setup UI, the OS is left
running at 800x600, not the native resolution. This looks crummy.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
Tested-by: Pete Batard <pete@akeo.ie>
|
|
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>
|
|
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>
|
|
For Pi 3 and Pi 4, since the relevant functionality is gone from FdtDxe.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Initially, FdtDxe used an internal (embedded in UEFI) FDT, because it
was neither understood how to consume the one loaded by the VideoCore
firmware, nor understood just how important it is to use the DTB
provided by config.txt.
Embedding the DT was a bad idea, because:
- Permanently stale
- No overlays
Also, on devices like the Pi 4 you _have_ to have a DT around for the
start4 VPU firmware to pick up, otherwise the board is left in an
inconsistent state. So we're being prescriptive now about DT use with
config.txt, which means this internal DT logic is dead code.
Further FdtDxe cleanups are possible and will be handled separately,
specifically:
- probably no need to use a separate allocation for patched DT (optimize
memory used)
- suspicious use of EfiBootServicesData (I filed [0] to sort out the real
requirements)
Testing: Booted Ubuntu 18.04 on Pi 2B (1.2).
[0] https://github.com/ARM-software/ebbr/issues/45
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Now that Pi 3 FDT handling is fixed, let's update the docs. Furthermore,
let's simplify - be proscriptive about the minimal supported
config.txt configuration. Also, fix some factual mistakes:
- device_tree= override is not mandatory when device_tree_address= is used.
Not using it means start.elf can chose the right one for the variant.
- device_tree= override is not mandatory for dtoverlay use.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
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>
|
|
This cleans up the (related) Readme.md files for both platforms.
- The RPi3 target also supports the 3A+, so let's document it.
(The 3A+ lacks the ethernet port and has less RAM)
- Clarify RPi3 is for BCM2837-based variants, while RPi4 is
for the BCM2711-based variants.
- v1.2 (not older) actually uses the same BCM2837 SoC as
Pi 3, and is thus a 64-bit device that this firmware
easily supports as a minor variant of the Pi 3.
The difference from Pi 3 is choice of UART (PL011), no WiFi,
no BT and slower clock due to thermal problems caused by
older board design.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
For PFTF developers working on the firmware, being able to use a
local TF-A build without extra extra copy operations ends up being
very helpful.
This can be accomplished via a TFA_BUILD_ARTIFACTS option passed
to the edk2 build tool.
If/when the Pi 3 and 4 DSC/FDFs become unified, this will be even
more important to trivially perform a full clean upstream build
for either platform, without having to worry about different TF-A
deliverables - Pi 4 uses bl31.bin, while Pi 3 uses fip.bin and bl1.bin.
This is like the Pi 4 patch that went in a month ago or so.
Signed-off-by: Andrei Warkentin <andrey.warkentin@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
* device_tree_address/end was incorrect for RPi3.
* Link to TF-A Readme.md in non-osi was broken.
* RPi4 now uses TF-A binaries built from official source.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
Set the PcdShellLibAutoInitialize for the TFTP dynamic Shell command.
This fixes an ASSERT observed in https://github.com/pftf/RPi3/issues/11
Signed-off-by: Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
|
|
Switch from the PI specific GraphicsConsoleDxe driver to the
common driver in MdeModulePkg. There is no need to carry RPi specific
version.
Signed-off-by: Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Reviewed-by: Andrei Warkentin <andrey.warkentin@gmail.com>
|
|
Enable HTTP Boot (with and without TLS) on RPi3
Signed-off-by: Samer El-Haj-Mahmoud <samer@elhajmahmoud.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
|
|
Instead of going through a model #ifdef, the call to
EFI_ACPI_5_1_GICC_STRUCTURE_INIT () is factorized by
setting up a new set of PCDs.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Improve the CPU frequency settings of the platforms by:
- Adding a "Default" option that sets the frequency to the
official default for each model/submodel.
- Adding a "Low" option, that sets the frequency to a fixed
PCD, custom to each platform.
- Using fixed PCDs to set the maximum and default values for
the custom frequency range, according to the overclocking
capabilities of the platform.
- Ensuring that the firmware defaults to using the platform's
default frequency, instead of a low arbitrary value.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This fixes "WARNING: default value re-defined with different value"
being produced when trying to set default values for the Scaled
VModes in ConfigDxeHii.vfr.
This warning is generated regardless of what the default value is
being set to and since we don't actually care about setting a default
value, as long as the PCD is properly set, we choose to simply remove
the default.
We also ensure that all the PCDs are set to the expected default value.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
With this and the previous commit, ACPI_BASIC_MODE_ENABLE becomes
superfluous so remove it.
New option defaults to enabled on Pi 3, disabled on Pi 4.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Currently some OSes (e.g FreeBSD) can make full use of the maximum
4 GB of RAM a Raspberry Pi 4 can offer, whereas others (e.g. Linux)
must be restricted to only the first 3 GB.
Previously this was a compile-time choice chosen by PcdAcpiBasicMode,
and now we make it user-selectable. The default is a 3 GB limit.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Move away from AcpiPlatformDxe for loading ACPI tables. Instead, use
ConfigDxe. This will allow selective loading/patching to enable
different SBBR/EBBR profiles.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
With the ACPI source for the Pi 3 and Pi 4 being identical, we can
finally factorize it.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This basically copies all of the RPi4 platform ACPI source into RPi3
since the last commit updates the code to serve both platforms.
No alteration of original ACPI source files were applied.
Whereas this commit is pretty much superfluous (apart from the .dsc
changes), since these files will be removed in the next commit, we apply
it nonetheless so that the minimal alterations to the existing Raspberry
3 tables are made apparent.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
The ACPI interrupts are not the same across different Raspberry Pi
platforms therefore moving them into AcpiTables.h will help with ACPI
code factorization.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
The FADT and GTDT tables are virtually identical to the ones we use for
the Pi 4, except for the RPI_SYSTEM_TIMER_BASE_ADDRESS in Gtdt.aslc.
However, 2 changes are required for these tables to work with Windows:
1. The ACPI OEM ID for the FADT table MUST be "BC2836" (else Windows 10
fails to boot) so we change the global value in AcpiTables.h.
2. The values for PcdArmArchTimerVirtIntrNum and PcdArmArchTimerHypIntrNum
seem to have been swapped in our existing .dsc so we swap them back
(Without this swap, Windows 10 simply refuses to boot).
The MADT table is deduced from the original Microsoft blob. The one thing
of notice is that no GIC Distributor section should exist in that table,
otherwise Windows 10 will fail to boot.
Obviously, all of the changes applied by this commit were validated on a
Raspberry Pi 3 running Windows 10.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This brings this table in line with what we have for Pi 4 and
will enable factorization of ACPI code between the two platforms.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Apart from the serial interrupt constants, the SPCR and DBG2 .aslc
we use for the Pi 4 platform can be applied as is for the Pi 3.
As a result, we replace the existing binary blobs with formal ASLC.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
With the new constants added, remove some of the hardcoded values from
the ACPI tables.
Note that because the ASL compiler is very limited in terms of macro
processing, we can not use any arithmetic constants (e.g BASE + OFFSET)
as parameters to MEMORY32FIXED (), and instead must alter the base
address using CreateDwordField () after MEMORY32FIXED () has been
invoked.
To achieve that, we create a MEMORY32SETBASE () macro and move the
MEMORY32FIXED () calls outside of Method (_CRS...).
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
Note that, for the time being, the TF-A binary only outputs to the
miniUART, but work is underway to add runtime UART detection to TF-A,
after which we will use such a binary.
Also note that this patch currently enforces the use of miniUART in
the ACPI tables, as we have to pick one until we can switch to using
DynamicTablesPkg/ConfigurationManagerDxe for ACPI generation.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
This is an improvement of e9db04631b63574b090aeab769cc47dcb75a29f7
where we inhibit serial output of MMIO mapped UARTs to all runtime
drivers rather than just RTC, as other drivers may crash the OS
just the same.
Also add it to the Pi 4 platform where it was missing altogether.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
|
The Bcm283x architecture provides multiple implementations of the
Random Number Generator, that have incompatibilities with one
another.
Because we will need to add a new driver for the Bcm2838 RNG we
rename the existing Bcm2835-compatible driver to Bcm2835RngDxe
and update the one platform that depends on this driver (RPi3).
We also rename the internal function calls from Bcm2836 to
Bcm2835 since, if we ever add platform support for Pi models
that use this SoC (original Pi, Pi Zero, etc), it may look
confusing to reference a feature that seems to belongs to the
next SoC iteration.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
acpiview is a UEFI shell command that can be used to inspect and
validate ACPI tables from the pre-OS environment. Let's add it to
our build of the shell.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
|
Using DEBUG () at runtime can crash the OS if we don't take care to
inhibit serial output to MMIO mapped UARTs that we don't inform the
OS about via the memory map.
So use a version of DebugLib that does exactly that for the RTC
driver.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
|
Define BCM2836_SOC_REGISTERS from PcdBcm283xRegistersAddress. This is
needed in preparation for adding Raspberry Pi 4 support, since the two
Pi's have a different base addresses for the Bcm283x specific registers.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
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>
|
|
TFTP support, which is disabled by default, can be enabled by setting
INCLUDE_TFTP_COMMAND to TRUE.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
|
DEBUG_WARNING was invalid. DEBUG_WARN is the proper channel name to use.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
|
