The controller supports up to 8 targets in practice (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each one
that responds.
Support for multiple LUNs will be implemented in another series.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-7-nikita.leshchenko@oracle.com>
The PL180 SD host controller driver is only used on emulated ARM
platforms, uses an obsolete version of the MMC host protocol and
does not adhere to the UEFI driver model.
It has been moved into edk2-platforms alongside the only platforms
that use it, so we can drop it from the EDK2 core repository.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The ISP 1716 USB host controller driver does not implement the UEFI
driver model, and is not a suitable example for new drivers to be
based on. Also, it is currently only used on a limited set of ARM
development platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The SiI3132 SATA controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Lan9118 network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Lan91x network controller driver does not implement the UEFI driver
model, and is not a suitable example for new drivers to be based on.
Also, it is currently only used on a limited set of ARM development
platforms.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The Synopsys DesignWare eMMC host controller driver does not implement
that SD/MMC host controller protocol that the UEFI spec defines, but an
obsolete EDK2-specific one that predates it. It also does not implement
the UEFI driver model.
Due to this, it has been moved into the edk2-platforms repository,
alongside its remaining users, which have been updated to refer to it in
its new location. So drop this version from EmbeddedPkg.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
In EDK2, identifiers carrying the EFI prefix are reserved for ones
that are defined in the UEFI or PI specifications.
Since the MMC host protocol defined in EmbeddedPkg is not the one that
the UEFI spec defines, and given the confusion around this, let's rename
it to from gEfiMmcHostProtocolGuid to gEmbeddedMmcHostProtocolGuid.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
The device manager UI library creates a UiApp submenu that contains a
list of network devices in the system. The logic that creates this menu
assumes that all handles have been connected to their drivers, but this
is not guaranteed in the general case: due to the way UiApp is constructed,
this logic runs before the UiApp entrypoint is invoked, which is where
ConnectAll() is normally called to ensure that all existing controllers
are connected to their drivers. Moving this call into DeviceManagerUiLib
is not an option, since it is incorporated into UiApp via NULL library
class resolution, and so it may not be included to begin with.
So work around this by doing an explicit additional ConnectAll() before
populating the pages.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Link: https://edk2.groups.io/g/devel/topic/72879609#57075
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2683
In PEI phase, AP already been waked up through ApInitConfig,
so it can directly wake up it through change wakup buffer
instead of use ApInitReconfig flag. It can save some time.
Change code to only use ApInitReconfig flag in DXE phase
which must need to update the wake up buffer.
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Cc: Chandana Kumar <chandana.c.kumar@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2683
This patch fixes an assertion because AP can't find the CpuMpData.
When AP is waken up through Init-Sipi-Sipi, AP's IDT should
be restored to pre-allocated buffer so AP can get the CpuMpData
through the IDT base address.
Current code already has logic to handle this when CpuMpData->
InitFlag is ApInitConfig but misses the logic
when CpuMpData->InitFlag is ApInitReconfig.
This patch fixes this gap.
Reviewed-by: Ray Ni <ray.ni@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Cc: Chandana Kumar <chandana.c.kumar@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting
the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from
fw_cfg.
These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6
boot. If a PXE version is disabled, the corresponding LoadFile protocol
instance is not produced by UefiPxeBcDxe, and so
EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not
generate corresponding *new* boot options either. (Existent boot options
are not deleted.)
Hook the library into the UefiPxeBcDxe driver. (The driver is already
included from "NetworkComponents.dsc.inc", but we can list it again in the
DSC file, for providing <LibraryClasses> overrides.)
In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does
not have fw_cfg access in the PEI phase. Hence a NULL class library that
can be linked into UefiPxeBcDxe.
When listing the PCDs under [PcdsDynamicDefault], stick with the DEC
default values.
QEMU switches:
-fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn]
-fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn]
The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation
from QEMU's "docs/specs/fw_cfg.txt".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging
debug output to the Xen console.
This will work with both Xen HVM guest and Xen PVH guest whereas the
default PlatformDebugLibIoPort works only in HVM when QEMU is present.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-6-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build
with it due to a circular dependency:
DebugLib : BaseDebugLibSerialPort ->
SerialPortLib : XenConsoleSerialPortLib ->
XenHypercallLib : XenHypercallLib ->
DebugLib
Also, if that dependency is fixed, I think it would be harder to find
which console the debug is sent to when running an HVM guest. The xen
console isn't the serial console used by default. Furthermore,
XenHypercallLib isn't initialised early enough, so we would loose
debug output from the SEC phase and early PEI phase.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200423095358.2518197-2-anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
