Hi Renan,
The UEFI driver model uses a stack of several modular DXE drivers to translate from lower level to higher level interfaces. As a baseline reference, this is what the driver stack would look like for a UFS device on an Intel SoC:
+--------------------------+
| EFI_BLOCK_IO(2)_PROTOCOL | <-- Represents a generic Hard Drive
+--------------------------+
|
V
*-------------*
| ScsiDiskDxe |
*-------------*
|
V
+----------------------+
| EFI_SCSI_IO_PROTOCOL | <-- Represents a SCSI device on a SCSI Bus
+----------------------+
|
V
*------------*
| ScsiBusDxe |
*------------*
|
V
+---------------------------------+
| EFI_EXT_SCSI_PASS_THRU_PROTOCOL | <-- Represents a SCSI HBA (Host-Bus Adapter)
+---------------------------------+
|
V
*----------------*
| UfsPassThruDxe |
*----------------*
|
V
+----------------------------------+
| EFI_UFS_HOST_CONTROLLER_PROTOCOL | <-- Represents a UFS Controller
+----------------------------------+
|
V
*-------------*
| UfsPciHcDxe |
*-------------*
|
V
+---------------------+
| EFI_PCI_IO_PROTOCOL | <-- Represents a PCI device on a PCI bus
+---------------------+
|
V
*-----------*
| PciBusDxe |
*-----------*
|
V
+---------------------------------+
| EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL | <-- Represents the PCIe root complex
+---------------------------------+
|
V
*---------------------------------------*
| MdeModulePkg/Bus/Pci/PciHostBridgeDxe | <-- Requires SoCs specific PciHostBridgeLib
*---------------------------------------*
|
V
+----------------------+
| EFI_CPU_IO2_PROTOCOL | <-- Provides the access to memory mapped I/O and legacy I/O ports
+----------------------+
|
V
*----------------------*
| UefiCpuPkg/CpuIo2Dxe | <-- The only x86 specific driver in this stack
*----------------------*
The important thing to note about this diagram is that the UfsPciHcDxe device driver that is present in MdeModulePkg can only be used for UFS controllers that the SoC exposes as a PCI bus attached UFS controller. If the SoC exposes the
UFS controller as a PCI device, this driver should work. However, if the SoC does not expose the UFS controller as a PCI device, then a SoC specific driver will be required to produce a device handle with an instance of EFI_UFS_HOST_CONTROLLER_PROTOCOL. You
mentioned that no PCI devices with class 01h and subclass 09h exist on this SoC, which means that a SoC specific driver is needed.
After the EFI_UFS_HOST_CONTROLLER_PROTOCOL instance is created, everything above EFI_UFS_HOST_CONTROLLER_PROTOCOL in the diagram above (including UfsPassThruDxe) will work without code change. The drivers below EFI_UFS_HOST_CONTROLLER_PROTOCOL
will obviously be different.
Hope that Helps,
Nate
From: devel@edk2.groups.io <devel@edk2.groups.io>
On Behalf Of renan.moraes2 via groups.io
Sent: Tuesday, January 26, 2021 9:24 AM
To: devel@edk2.groups.io
Subject: [edk2-devel] Questions/doubts about UFS device on UEFI
Good afternoon,
We are studying how to communicate with Universal Flash Storage (UFS) device on UEFI environment. The first step is identify the UFS device, we are using the system Lenovo Flex 5G (It has Snapdragon processor + UFS device).
We tried to identify the UFS device in three ways:
1 - Specific UEFI protocols (UFS_DEVICE_CONFIG_PROTOCOL / UFS_HOST_CONTROLLER_PROTOCOL) -> None of these protocols could be found on our test systems, we compiled the EDK II 2020 (edk2-stable202005) available drivers (UfsPassThru and UfsPciHc)
and loaded them. However, these drivers can't detect the UFS device.
2 - Device Path -> Tried to identify by its type (Type 3 – Messaging Device Path) and subtype (Sub-Type 25 – UFS), but could not find any matches.
3 - Pci bus -> Tried to identify by its class (01h - Mass Storage Controller) and subclass (09h - Universal Flash Storage controller), but could not find any matches.
We would like to know if there is an alternative UEFI UFS driver or other methods to identify and communicate with this type of storage device.
Thank you in advance.