public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ard.biesheuvel@arm.com>
To: devel@edk2.groups.io
Cc: leif@nuviainc.com, alan@softiron.com,
	Ard Biesheuvel <ard.biesheuvel@arm.com>
Subject: [PATCH edk2-platforms] Platform/OverdriveBoard: work around network ConnectAll() dependency
Date: Fri, 29 May 2020 23:40:19 +0200	[thread overview]
Message-ID: <20200529214019.6063-1-ard.biesheuvel@arm.com> (raw)

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>
---

This is a preparatory patch to ensure that this platform does not break
when core EDK2 drops the EfiBootManagerConnectAll() from the ArmPkg
version of PlatformBootManagerLib.

 Platform/AMD/OverdriveBoard/OverdriveBoard.fdf | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
index 851ae65b5be9..15b5b1bc317f 100644
--- a/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
+++ b/Platform/AMD/OverdriveBoard/OverdriveBoard.fdf
@@ -178,18 +178,18 @@ [FV.FvMain]
   INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
   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
   #
-- 
2.26.2


             reply	other threads:[~2020-05-29 21:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 21:40 Ard Biesheuvel [this message]
2020-06-01 13:19 ` [edk2-devel] [PATCH edk2-platforms] Platform/OverdriveBoard: work around network ConnectAll() dependency Leif Lindholm
2020-06-02  6:56   ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200529214019.6063-1-ard.biesheuvel@arm.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox