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 2f0188b56e ("Revert "Platform/RaspberryPi: Setup option for...")
mistakenly introduced to files which are residues from a
conflict resolution. Fix that.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
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 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 94e9fba43d 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 678f6bff3c ("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>
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
c8000ecccc 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>
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>
