When use the UsbHcAllocMemFromBlock() and UsbHcFreeMem() to allocate
memory and free memory for the UHC, it should use the corresponding host
address but not the pci bus address.
Signed-off-by: jdzhang <jdzhang@zd-tech.com.cn>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3635
Currently, in order to test the supported attributes,
the PciTestSupportedAttribute() will set the command register
to 0x27 (EFI_PCI_COMMAND_IO_SPACE, EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER, EFI_PCI_COMMAND_VGA_PALETTE_SNOOP) firstly,
and then read back to check whether these attributes are
set successfully in the device.
This will cause the other enabled bits
(other than EFI_PCI_COMMAND_IO_SPACE,EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER,EFI_PCI_COMMAND_VGA_PALETTE_SNOOP)
be cleared for a short of time
This patch fixes this issue by keeping the origina
enabled bits when setting 0x27.
Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
Reviewed-by: Ray <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3418
According to xhci spec, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status
stage. If Data Stage does not exist, the Transfer Type flag(TRT)
should be No Data Stage.
So if data length equals to 0, TRT is set to 0.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The ProcessOptionRomLight() assumes that OpRom has already been
processed in the previous full enumeration and updates
AllOpRomProcessed flag to TRUE by default. However, this may not
be applicable with other pre-stage boot firmwares.
This will update AllOpRomProcessed flag properly by checking
PciRomGetImageMapping().
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3114
Add logic to flush all UART transmit buffers if there is a
config change from Reset(), SetAttributes() or SetControl().
Use a timeout in the flush operation, so the system can
continue to boot if the transmit buffers can not be
flushed for any reason.
This change prevents lost characters on serial debug logs
and serial consoles when a config change is made. It also
prevents a UART from getting into a bad state or reporting
error status due to characters being transmitted at the same
time registers are updated with new communications settings.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
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>
Add check for NULL HostAddress in AllocateBuffer as required by UEFI
specification.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
NonDiscoverablePciDeviceDxe currently #defines the module-internal
PCI_MAX_BARS macro, with value 6 (and type "int").
Remove this private macro definition, and adopt PCI_MAX_BAR from
"MdePkg/Include/IndustryStandard/Pci22.h". Both the value and the type
remain unchanged (the standard PCI_MAX_BAR macro expands to 0x0006).
"NonDiscoverablePciDeviceIo.h" gets the definition of PCI_MAX_BAR via its
existent #include <IndustryStandard/Pci.h> directive.
Build-tested only.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200409113017.18233-1-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
ASSERT in PollMem_Conf, CopyMem_Conf, SetBarAttributes_Conf
Conformance Test.
SCT Test expect return as Invalid Parameter or Unsupported.
Added Checks for Function Parameters.
return Invalid or Unsupported if Check fails.
Added Checks in PciIoPollIo(), PciIoIoRead()
PciIoIoWrite()
Signed-off-by: Gaurav Jain <gaurav.jain@nxp.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed but data transfer timed out.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrupt
status register on failed SD command.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1989
The commit will avoid unmapping the same resource in error handling logic
for function BuildAdmaDescTable() and SdMmcCreateTrb().
For the error handling in BuildAdmaDescTable():
The error is directly related with the corresponding Map() operation
(mapped address beyond 4G, which is not supported in ADMA), so the Unmap()
operation is done in the error handling logic, and then setting
'Trb->AdmaMap' to NULL to avoid double Unmap.
For the error handling in SdMmcCreateTrb():
The error is not directly related with the corresponding Map() operation,
so the commit will update the code to left SdMmcFreeTrb() for the Unmap
operation to avoid double Unmap.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Changed @rtval to @retval in SdMmcHcStartSdClock
function description.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
For eMMC modules we used to notify the platform about frequency
change only after sending CMD13 which meant that platform
might not get a chance to apply required post frequency
change fixes to get the clock stable. To fix this
notification has been moved to SdMmcHcClockSupply function
just after we start the SD clock. During first time setup
the notification won't be sent to avoid changing old behavior.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2118
When a packet is queued/completed for the asynchronous IO queue, the logic
to roll over to the front of the queue doesn't account for actual size of
the IO Submission/Completion queue.
This causes a device to hang due to doorbell being outside of visible
queue. An example would be if an NVMe drive only supported a queue size of
128 while the driver supports 256.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
Whenever a PCI device is discovered, PCI bus calls the
EDKII_DEVICE_SECURITY_PROTOCOL to authenticate it.
If the function returns success, the PCI bus allocates
the resource and installs the PCI_IO for the device.
If the function returns fail, the PCI bus skips the device.
It is similar to EFI_SECURITY_ARCH_PROTOCOL, which
is used to verify an EFI image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Yun Lou <yun.lou@intel.com>
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
RequestMap is used but not Initialized.
RequestMap is called by UhciMapUserRequest, in which RequestMap(Map)
is called by IoMmuMap, and is finally called by IoMmu->Map.
We can not assume RequestMap is given an initial value at any step.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Map is used but not Initialized.
Map is called by IoMmuMap, in which Mapping(Map) is called by IoMmu->Map.
We can not assume Map is given an initial value at any step.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2312
This patch is for fixing unexpected system hang during S3 unlock process.
FatPei driver maintained and updated internal BlockIo devices list
when there is new BlockIo PPI has installed, and it relied on BlockIo PPI
service to get data from devices. Because BlockIo Ppi leverage
NvmExpressPei Ppi to transit Nvm command to device, we should make sure
NvmePassThruPpi installed before BlockIo PPI.
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Add support for allocating aligned pages at an alignment higher
than 4K. The new function allocated memory taking into account
the padding required and then frees up unused pages before mapping
it.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
While allocating pages aligned at an alignment higher than
4K, allocate memory taking into consideration the padding
required for that alignment. The calls to free pages takes
care of this already.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
