summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorArd Biesheuvel <ard.biesheuvel@arm.com>2020-05-29 21:14:10 +0200
committerArd Biesheuvel <ard.biesheuvel@arm.com>2020-06-02 08:55:21 +0200
commit608d71ec939692eace78e6b4b2a44ea7b6e75927 (patch)
tree5e67963a1dc8b3a198c9cee8b99019d70e86ac34
parent747eeac8a8b9fb19f2c81f7983fb6e6c1f6616ec (diff)
Platform/OverdriveBoard: work around network ConnectAll() dependency
The AMD Seattle based platforms have been kept up to date in recent years, even though the hardware is obsolete and was never available that widely in the first place. However, one aspect that has sadly been left behind is the support for the builtin network controllers. These are only wired up and enabled on the Overdrive board to begin with, and the driver was only made available as two separate binary blobs implementing the SNP protocol for each controller separately, without taking the UEFI driver model into account. Even worse, the PHY initialization code that needs to run at boot in order for the OS to be able to use the device never executes unless the upper networking layers start the SNP protocol, which doesn't happen on a fast boot (one that does not use ConnectAll()) unless the boot target is a network device path. We cannot fix the driver, but fortunately, there is another way out: protocols that are installed on a handle during the execution of the entrypoint of a driver will be connected by the DXE core, and so we can ensure that the old behavior is retained regardless of whether ConnectAll() is ever invoked, by reordering the load sequence so that the upper layer drivers have all been registered by the time the entrypoints of the SNP drivers are called. This relies on FV contents to be dispatched in the order they appear in the .FDF file. The AMD SNP driver as well as the upper layer drivers in NetworkPkg are UEFI_DRIVER modules, which means their DEPEXes are implicitly defined as the full set of architectural PI protocols. This means that all these modules become available for dispatch at the same time, and their dispatch order is fully defined by the order of appearance in the FV. Unfortunately, this is an implementation detail rather than something that is supported by the PI spec, but this is unlikely to ever change since other platforms undoubtedly exist that depend on this behavior as well. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
-rw-r--r--Platform/AMD/OverdriveBoard/OverdriveBoard.fdf12
1 files changed, 6 insertions, 6 deletions
diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
index 851ae65b..15b5b1bc 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
@@ -179,18 +179,18 @@ READ_LOCK_STATUS = TRUE
INF MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
#
- # SNP support
- #
- INF Silicon/AMD/Styx/AmdModulePkg/SnpDxe/SnpDxePort0.inf
- INF Silicon/AMD/Styx/AmdModulePkg/SnpDxe/SnpDxePort1.inf
-
- #
# Networking stack
#
!include NetworkPkg/Network.fdf.inc
INF MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
#
+ # SNP support
+ #
+ INF Silicon/AMD/Styx/AmdModulePkg/SnpDxe/SnpDxePort0.inf
+ INF Silicon/AMD/Styx/AmdModulePkg/SnpDxe/SnpDxePort1.inf
+
+ #
# Core Info
#
INF Silicon/AMD/Styx/Drivers/PlatInitDxe/PlatInitDxe.inf