UFS1 Support on J5?

[olearypa]

For a carrier board design, we are investigating taking advantage of the UFS1 interface available on J5 of the VOXL2 for additional storage beyond that on board the SOM. Are there any gotchas we should be aware of? Would we need to make any device tree changes if we wanted to use it?

[Moderator]

@olearypa Hi, we asked around. It seems like it should work as is, but we have not confirmed or tried it

[Vinny]

Hi @olearypa
I suggest trying it on this board first: https://www.modalai.com/collections/expansion-board/products/m0062-2
That socket is a UFS/uSD combo mode socket and has the UFS signals on it: https://docs.modalai.com/m0062-datasheet/#j7---usdufs-combo-card-slot

[olearypa]

While we do have an M0062-2, UFS cards are like hens' teeth. Looks like eBay is about the only way to get one; Samsung seems to have stopped making them.

We did notice the SD_UFS_CARD_DET_N signal on J5 pin A12; is it reasonable to assume that we'd need to pull that pin low even if using a UFS chip (rather than a card) in order to signal the presence of the device?

[Vinny]

Hi @olearypa
Oh wow, you are right.
I guess UFS never took off since SD cards are so awesome now....
Last year these little sharkfin cards were easy to get...

I guess not so much anymore.

Sadly, I'm not sure how easy it is to design a plug-in board with UFS discrete since it requires other signals that we did not expose (given at the time UFS cards were abundant). The core 1.2V power rail is not brought to J5, and we have not verified if you do your own 1.2V supply that the power on timing will be satisfied. It's a risk to do it since we have not verified it, but give yourself an option to adjust power on timing if you try it. I'm not sure how the device tree needs to be changed, but I'm thinking there should be a way to indicate a non-removable device such that the DET signal is not needed. But, as a back-up, you should give the option to GND it as if it was using a socket.

[olearypa]

@Vinny For sure I think SD Express--with a major consumer device which uses them coming out in a week--won the very short lived MicroSD replacement war, even though UFS is (thankfully) taking over the internal storage market. Thanks for the hints; we'll see what we can come up with.

[wetherbeej]

@Vinny, I'm adding a little more context to our efforts on UFS1 support.

We tied the detect pin to ground but the clock line on J5 still doesn't show a clock signal on an oscilloscope.

We tried going back to the M0062-2 with an SDCard to see if that would work. In our tests, the voxl2 did not communicate correctly with the SDCard. We get the following dmesg output:

[   75.085028] mmc0: sdhci_msm_execute_tuning: no tuning point found
[   75.085083] mmc0: tuning execution failed: -5
[   75.085126] mmc0: error -5 whilst initialising SD card

We also tried digging around on Qualcomm's website to check the device tree. I found this handy website that lists some of the addresses used for UFS.
https://docs.qualcomm.com/doc/80-88500-4/topic/90_UFS_hardware.html

It shows the UFS_MEM_MPHY_UFS register as 0x01D87000 and UFS_MEM_UFS at 0x01D8400. for the "Embedded UFS memory address" I see these in the m0054-kona.dtsi device tree:

        ufsphy_mem: ufsphy_mem@1d87000 {
                reg = <0x1d87000 0xe00>, <0x1d90000 0x8000>; /* PHY regs */
                reg-names = "phy_mem", "ufs_ice";
               ...
         };

and

       ufshc_mem: ufshc@1d84000 {
                compatible = "qcom,ufshc";
                reg = <0x1d84000 0x3000>, <0x1d90000 0x8000>;
                reg-names = "ufs_mem", "ufs_ice";
                ...
     };

That same website also shows the UFS_CARD_MPHY_UFS as 0x01DA7000 and UFS_CARD_UFS as 0x01DA4000. I do not see those addresses used in m0054-kona.dtsi.

I do see the SDC 2 memory addresses of 0x08804000 (https://docs.qualcomm.com/doc/80-88500-4/topic/97_SD_SDIO_hardware.html) listed in the m0054-kona.dtsi.

        sdhc_2: sdhci@8804000 {
                compatible = "qcom,sdhci-msm-v5";
                reg = <0x8804000 0x1000>;
                reg-names = "hc_mem";

1. Do you know if the current device tree should support the UFS Card interface? It seems curious to me that we do not see the UFS Card addresses in the device tree.

2. Should we expect an SDCard to work on the m0062-2? If so, I'll experiment further with other boards and other SD cards to try to isolate the issue.

[Vinny]

Hi @wetherbeej
We still never actively pursued support due to lack of demand.
Additionally, one of our other customers that is very savvy with QC chips tried for a few months and then gave up... seems this may be a fundamental QC QRB5165 issue that we may not be able to solve or even push for resolution either. It would not be the first SoC feature that was promised but then never supported. I think the lack of UFS cards in the market is a key indicator this product segment is going to eventually be left to dry.
Sorry I do not have better news for you.

As we push towards a later Ubuntu release, we can try again, but those efforts have been slow going and tedious.

Our other customer went towards a SSD over PCIe using J5 PCIe interface. That seems to be also where the market is heading... PCIe and USB-C based SSD's, but predominantly USB-C.

[wetherbeej]

@Vinny

We attempted one more approach. We swapped out the UFS chip on the VOXL2 for a larger UFS chip. Do you need to use the Qualcomm Product Configuration Assistant Tool (PCAT) or any other specific tool to initially provision the LUNS on the UFS chip prior to installing your image?

[Vinny]

Hi @wetherbeej
Oh yikes..
You should really work with us on that change. There is a high likelihood to damage your VOXL 2 and the MEMs sensors are likely all broken now from the extra reflow cycles.

Flash provisioning is all done over QFIL tools, not PCAT.