public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Nate DeSimone" <nathaniel.l.desimone@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"renan.moraes2@fit-tecnologia.org.br"
	<renan.moraes2@fit-tecnologia.org.br>
Subject: Re: [edk2-devel] Questions/doubts about UFS device on UEFI
Date: Wed, 27 Jan 2021 01:19:55 +0000	[thread overview]
Message-ID: <DM5PR1101MB215479DF0B7E57111A634209CDBB9@DM5PR1101MB2154.namprd11.prod.outlook.com> (raw)
In-Reply-To: <L2Fd.1611681810399785355.JEvM@groups.io>

[-- Attachment #1: Type: text/plain, Size: 5136 bytes --]

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.


[-- Attachment #2: Type: text/html, Size: 20579 bytes --]

  parent reply	other threads:[~2021-01-27  1:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 17:23 Questions/doubts about UFS device on UEFI renan.moraes2
2021-01-27  0:28 ` [edk2-devel] " Andrew Fish
2021-01-27  1:19 ` Nate DeSimone [this message]
2021-01-28 16:36   ` renan.moraes2

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM5PR1101MB215479DF0B7E57111A634209CDBB9@DM5PR1101MB2154.namprd11.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox