With some super-speed USB mass storage devices it has been observed
that a USB transaction error may occur when attempting the set the
device address during enumeration.
According the the xHCI specification (section 4.6.5) ...
"A USB Transaction ErrorCompletion Code for an Address Device Command
may be due to a Stall response from a device. Software should issue a
Disable Slot Commandfor the Device Slot then an Enable Slot Command
to recover from this error."
To fix this, retry the device slot initialization if it fails due to a
device error.
Change was verified using a superspeed mass storage device that was
occasionally failing to enumerate in UEFI. With this change this failure
to enumerate was resolved. This failure was also only seen in UEFI and not
in the OS.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3007
Currently UsbDevContext is not cleaned up if USB slot initialization is
failed, the wrong context data will affect next USB devices and
the USB devices can not be enumerated.
Need to disable slot if USB slot initialization is failed.
Below test cases are passed on UpXtreme:
a. USB 3.0 thumb drives can be recognized in UEFI shell
b. SUT can boot to Puppylinux from USB3.0 mass storage,
the storage can be recognized in linux
c. Plug in a USB keyboard (hot plug) and enumeration is OK
in UEFI shell and linux
d. Plug in a USB mouse(hot plug) and enumeration is OK in linux.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Heng Luo <heng.luo@intel.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Check the actual TPM1.2 command response to prevent a false positive
when talking to a TPM2.0.
Tested using a ST33TPHF TPM 2.0.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
EDK2 expects PCI bars to be continously be allocated without "gaps" of reserverd
memory in between.
coreboot places PCI bars anyware in the PCI MMIO space, interleaved with MMCONF
and reserved I/O MMIO space.
Warn about this behaviour and refuse to add the BAR to the PCI aperature as it would
cause the PciHostBridgeDxe fo fail.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
As the TerminalDxe significantly slows down the boot menu rendering,
disable it but default and add the option SERIAL_TERMINAL to enabled
it for headless platforms.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
This will make sure the ConsoleInit is able to connect the driver installed
by the VGA Option ROMs.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Install the gPciPlatformProtocol to scan for Option ROMs.
For every device we probe the Option ROM and provide a pointer
to the activated BAR if found.
It's safe to assume that all ROM bars have been enumerated,
reserved in the bridge resources and are disabled by default.
Enabling them and leaving them enabled will do no harm.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
The Option ROM scanner can't work as enumeration was done by the
first stage bootloader. Running it will disable the ability of the
PCIPlatform code to scan for ROMs.
Required for the following patch that enables custom Option ROM
scanning using gPciPlatformProtocol.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Tianocore currently reads/writes a lot of NVRAM variables that
don't actually need to be saved. Occasionally some, specifically
related to the graphical/serial consoles, can become corrupted,
leading to a bricked device. To avoid this, temporarily restrict
the reading/writing of variables to skip console related ones
(starting with 'Con') until a better solution can be found.
Test: build/boot google/eve, inject "bad" NVRAM data, observe
device boots normally instead of hanging with no display detected.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
This is a shoehorned-in implementation of an ACPI BGRT
table, ported pretty much directly from the version used
under CorebootPayloadPkg.
EDK2 provides a facility to do this already, but it assumes
the ACPI tables already exist as EFI structures, so would need
to write code to populate those using the tables already in RAM
created by coreboot. This seemed like the easier option ATM.
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Skip PCI enumeration, which is already handled by Coreboot, by using
PciBusNoEnumerationDxe and PciRootBridgeNoEnumerationDxe from the
deleted DuetPkg.
Check SMM store return code and return on error.
Fixes significant boot delay in case no SMM store is present.
This can happend quite often if the tianocore payload is build standalone
and patched into a coreboot ROM.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
changed: buffer size from 64k to 256k
Change-Id: I7f443b9f36612f79787e1b4b1075176a91107686
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
