Skip to content
  1. Apr 21, 2020
  2. Apr 20, 2020
  3. Apr 17, 2020
  4. Apr 15, 2020
  5. Apr 14, 2020
  6. Apr 13, 2020
  7. Apr 09, 2020
    • Ard Biesheuvel's avatar
      Silicon/SynQuacer/NetsecDxe: move device path to root device · c69ff250
      Ard Biesheuvel authored
      
      
      Currently, SynQuacer's platform DXE driver installs a non-discoverable
      device protocol onto a new handle to declare the existence of the NetSec
      network controller. This protocol is consumed by the NetSec DXE driver
      in its implementation of the UEFI driver model supported/start/stop
      routines. Only when the driver is started, an instance of the device
      path protocol is installed onto the handle, annotating the handle as
      supporting the MAC flavor of the messaging device path.
      
      This approach works as long as the non-discoverable driver is always
      connected at some point during the boot. However, it breaks the intent
      of the UEFI driver model, since it is not possible to defer connection
      of the driver to the controller to the point where it is actually being
      used.
      
      For instance, the following device path could be attached to a boot
      entry to trigger HTTP boot once the entry is chosen:
      
        MAC(408d5cb1e6fa,1)/IPv4(0.0.0.0,0,0)/Uri()
      
      This only works as expected if some part of this device path resolves
      to a controller which can be connected recursively. In other words,
      an instance of the EFI device path protocol needs to already exist,
      covering at least the first level of the path.
      
      Fix this by moving the instantiation of the device path protocol to
      the platform DXE code that instantiates the handle.
      
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@arm.com>
      Reviewed-by: default avatarLeif Lindholm <leif@nuviainc.com>
      c69ff250
    • Ard Biesheuvel's avatar
      Silicon/SynQuacer/PlatformDxe: defer device registration until EndOfDxe · 4be1e20c
      Ard Biesheuvel authored
      
      
      EDK2 carries an interesting quirk which dates back to the EFI 1.02 days,
      where each protocol that is installed onto a handle during the execution
      of a DXE driver's entrypoint is connected immediately (in the UEFI driver
      model sense) after the entry point returns.
      
      This means that, depending on the order that these drivers happen to end
      up being dispatched, we may enter the BDS phase with the device's driver
      stack fully connected, even if the device in question is not being used
      to boot the machine.
      
      Given the substantial delays that this might incur, let's work around
      this 'feature' by deferring the registration of the network and eMMC
      controllers to an EndOfDxe event handler.
      
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@arm.com>
      Reviewed-by: default avatarLeif Lindholm <leif@nuviainc.com>
      4be1e20c
    • Ard Biesheuvel's avatar
      Platform/DeveloperBox: omit TPM from DT when building without TPM support · 9c4e5fe3
      Ard Biesheuvel authored
      
      
      The recently added support for TPM2 measured boot added a description of
      the TPM to the device tree, but failed to take the build configuration
      into account, and so it adds it unconditionally.
      
      Fix this, by #define'ing a TPM2_ENABLE CPP macro that can be referenced
      in the device tree source file.
      
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@arm.com>
      Reviewed-by: default avatarLeif Lindholm <leif@nuviainc.com>
      9c4e5fe3
  8. Apr 08, 2020
  9. Apr 06, 2020
  10. Apr 01, 2020
  11. Mar 31, 2020
  12. Mar 30, 2020
  13. Mar 27, 2020
  14. Mar 26, 2020
  15. Mar 25, 2020
  16. Mar 18, 2020
Loading