Rock64 micro-sd controller defective?

[z4v4l]

Can you please calm down and just have a look at the schematics for Rock64... the SD-Card interface has a fixed 3.3V supply, so it will only support 3.3V modes, the eMMC has a fixed 1.8V supply, so it will support 3.3V and 1.8V modes (the lower speed modes also work on 1.8V). To support dual voltage modes, you need hardware support for dynamic adjustment of VCC_IO which is not trivial to implement for u-boot and Linux which is why you don't see that configuration a lot on single board computers...

VDD to the card should be fixed at 3.3V for UHS-I cards as per the SDA host controller spec.

1.8 Signaling Enable field of the Host Control 2 register
This bit controls voltage regulator for I/O cell. 3.3V is supplied to the card regardless of signalling voltage.

What hardware support do you mean? Isn't it rk3328 SDA host controller compliant controller? Setting that bit should transit I/O into 1.8V (3.6.1, Voltage switch procedure (for UHS-I), part A2, page 177). Why it is not the case on Rock64?

[xalius]

Observe that there is only one VCC pin on SD-Cards, you need a level shifter to support both 3.3V and 1.8V modes (for the actual SoC I/O port and the card...)

   

[dkryder]

Can you please calm down and just have a look at the schematics for Rock64... the SD-Card interface has a fixed 3.3V supply, so it will only support 3.3V modes, the eMMC has a fixed 1.8V supply, so it will support 3.3V and 1.8V modes (the lower speed modes also work on 1.8V). To support dual voltage modes, you need hardware support for dynamic adjustment of VCC_IO which is not trivial to implement for u-boot and Linux which is why you don't see that configuration a lot on single board computers...

VDD to the card should be fixed at 3.3V for UHS-I cards as per the SDA host controller spec.

1.8 Signaling Enable field of the Host Control 2 register
This bit controls voltage regulator for I/O cell. 3.3V is supplied to the card regardless of signalling voltage.

What hardware support do you mean? Isn't it rk3328 SDA host controller compliant controller? Setting that bit should transit I/O into 1.8V (3.6.1, Voltage switch procedure (for UHS-I), part A2, page 177). Why it is not the case on Rock64?

in attempt to educate ,
here are a couple clips of the vcc out of the pmic to the tf [sdcard] one is the 3328 the other is the 3399. you should be able to notice that the 808 on the 3399 sends 1.8-3.3v, on the other hand the 805 of the 3328 sends just 3.3v as remarked in the box in the upper right corner.

   


   

and then the tf [sdcard] for each

   

   

with the 3328 vcc_sd is3.3 and with 3399 vcc_sdio as shown above is 1.8-3.4v

[z4v4l]

again and again...
voltage level of the I/O lines to the card is driven by the host controller. HC supporting UHS-I modes has the ability to switch voltage of I/O signals to the card. Its I/O cells voltage supply should be capable of 1.8-3.3V range. what you show is not a voltage supply for SDMMC interface on the SoC, it's the same reference to the TF card cage. and then again, if HC's I/O cells are powered 3.3V only, then the question is why so, if the interface is capable of supporting high speed modes, synthetically cut of this possibility not providing a proper power supply to it?

since, it seems, nobody does really care, it's better to stay with 20 MB/s. A user has bought a bunch of not exactly cheap UHS-I SD cards in the hope to use them with the board, but let's direct him to buy even more expensive eMMC module! after all it's faster! Or let him buy an SSD and plug it into USB3.

[dkryder]

it can only provide it if it is available and it is not.

z4v4l said, "the question is why so, if the interface is capable of supporting high speed modes, synthetically cut of this possibility not providing a proper power supply to it?"

well, your guess is as good as mine but i say they do not want to provide specs of top line to the base model or some people might just pick the base model over the top line.

[z4v4l]

In fact, rk3328 and rk3399 both seem to have the same set of the SD/eMMC contollers. Namely, and it looks the first two instances are one IP, and the third is another. They are called SDMMC, SDIO and EMMC respectively. SDIO is specifically made to serve SDIO protocol, but both of these IPs look as capable of managing both SD memory cards and eMMC modules. The SDMMC looks a bit older design, it can do DDR50 but can't SDR104. EMMC does support all the UHS-I modes. I guess the SD card cage is routed to SDMMC, on both boards and eMMC module - to EMMC, right?

The question is does anybody really know here of why UHS-I doesn't work on rock64, and i guess the same goes to rockpro64? Nobody is interested in that? Of course, there is eMMC, USB3, and even frigging PCIe for NVMe SSDs, but does it validate screwing up the SD interface? It is already there, the SoC internals are ready for UHS-I speed modes, that could at least double the throughput on SD cards, that still play the special role of installation media so often on SBCs! Unfortunately I am too far away of trying it by myself. The voltage switch sequence requires supporting interrupts and timers. It's not working on my project for these boards yet. I own rock64 but I don't have rockpro64. But Odroid N1 with the same rk3399 does UHS-I modes! Renegade as well. Maybe some of you own an rk3328 set top box, maybe there, UHS-I is implemented, do you have numbers for those? Share please. Rockchip for incomprehensible reasons doesn't want to release the full manual on rk3328.

Please, whoever authoritative, explain clearly, is this lack of UHS-I on rock64, rockpro64 due to the software (linux) support or it hasn't been done properly on the board level?

I read the rk3399 manual. EMMC IP is crappily documented, SDMMC is much better. There is a lot of guidances, there is a chapter for voltage switching as well. so cool. But in the chapter, there is a funny thing, the problem is they decided to be funny in a wrong place. On the most interesting and serious moment, some mystery surfaces - when it comes to the real voltage switch, the manual says: "write Voltage Register", on the timing figure, it's called "register 74". Ok, but what is that? Of what module this register is? Does anybody know this?

PS. Even A64 of Pine64 is capable of UHS-I according to the Allwinner manual.

[z4v4l]

Well. I looked into the boards schematics, rk805 and rk808 PMIC datasheets and it looks like on Rockpro64 it is theoretically possible to have voltage switching working. Because there SDMMC0 module is fed with LDO4 regulator of rk808 specifically, VCC_SDIO is provided through it. Nothing else is connected to it, so you can switch voltage safely. I guess. I don't have this board anyway. Could anybody show numbers with UHS-I capable cards on Rockpro64?

With rock64, the situation is less clear and not this optimistic. rk805 is used as a PMIC, right? It has fewer LDOs/BUCKs and looking at the board schematics shows rather confusing results. There is a figure and table. In the figure, power domain of SDMMC0 is shown as VCCIO3 and it's listed among with VCCIO1 and VCC_PMU. Who knows is this just a conventional grouping for making it more readable or really this grouping has meaning. Because there are yet other groups and all of them are coming from VCC_IO, and it is sourced by BUCK4 of rk805. All of them are sourced from this regulator, that means, that switching voltage on BUCK4 will affect every of these domains. But in the table, the picture is a little bit different:

Code:

.--------------------------------------------------------.
|IO power domain | IO voltage = 3.3V | IO voltage = 1.8V |
|----------------'-------------------'-------------------'
|VCCIO_PMU       |        3.3        |   not supported   |
|----------------'-------------------'-------------------'
|VCCIO1          |        3.3        |   not supported   |
|----------------'-------------------'-------------------'
|VCCIO2          |                   | 1.8 (default) eMMC|
|----------------'-------------------'-------------------'
|VCCIO3          |   3.3 (default)   |                   |
|----------------'-------------------'-------------------'
|VCCIO4          |   3.3 (default)   |                   |
|                |  WIFI:RTL8723BS   |                   |
|----------------'-------------------'-------------------'
|VCCIO5          |   3.3 (default)   |                   |
|----------------'-------------------'-------------------'
|VCCIO6          |   3.3 (default)   |                   |
'--------------------------------------------------------'

So the question is what this table really shows? Empty cells left, do they mean that alternative voltage for the power domain is possible without affecting other ones? For example this table suggests, that I can switch VCCIO3, which is the SDMMC power domain, into 1.8V without affecting VCCIO1, for which 1.8V is not possible? And the voltage for VCCIO3 is 3.3V only as "default". Nothing says it can't be different. There is no "not supported" mark. But how is this possible? If all they are connected to the same BUCK4 regulator? This PMIC, rk805, is specifically designed for rk3328 (among another SoC), but it looks like they made it nearly impossible to provide a dedicated regulator for SDMMC0 power domain, that is allowed to switch voltage, without affecting other modules. And the same time they embedded a UHS-I capable controller inside of rk3328, that does require voltage switch for operating in this fast mode. Could anybody clarify this situation? What the above table does really tell? tllim please.

[tllim]

Well. I looked into the boards schematics, rk805 and rk808 PMIC datasheets and it looks like on Rockpro64 it is theoretically possible to have voltage switching working. Because there SDMMC0 module is fed with LDO4 regulator of rk808 specifically, VCC_SDIO is provided through it. Nothing else is connected to it, so you can switch voltage safely. I guess. I don't have this board anyway. Could anybody show numbers with UHS-I capable cards on Rockpro64?

With rock64, the situation is less clear and not this optimistic. rk805 is used as a PMIC, right? It has fewer LDOs/BUCKs and looking at the board schematics shows rather confusing results. There is a figure and table. In the figure, power domain of SDMMC0 is shown as VCCIO3 and it's listed among with VCCIO1 and VCC_PMU. Who knows is this just a conventional grouping for making it more readable or really this grouping has meaning. Because there are yet other groups and all of them are coming from VCC_IO, and it is sourced by BUCK4 of rk805. All of them are sourced from this regulator, that means, that switching voltage on BUCK4 will affect every of these domains. But in the table, the picture is a little bit different:

Code:

.--------------------------------------------------------.
|IO power domain | IO voltage = 3.3V | IO voltage = 1.8V |
|----------------'-------------------'-------------------'
|VCCIO_PMU       |        3.3        |   not supported   |
|----------------'-------------------'-------------------'
|VCCIO1          |        3.3        |   not supported   |
|----------------'-------------------'-------------------'
|VCCIO2          |                   | 1.8 (default) eMMC|
|----------------'-------------------'-------------------'
|VCCIO3          |   3.3 (default)   |                   |
|----------------'-------------------'-------------------'
|VCCIO4          |   3.3 (default)   |                   |
|                |  WIFI:RTL8723BS   |                   |
|----------------'-------------------'-------------------'
|VCCIO5          |   3.3 (default)   |                   |
|----------------'-------------------'-------------------'
|VCCIO6          |   3.3 (default)   |                   |
'--------------------------------------------------------'

So the question is what this table really shows? Empty cells left, do they mean that alternative voltage for the power domain is possible without affecting other ones? For example this table suggests, that I can switch VCCIO3, which is the SDMMC power domain, into 1.8V without affecting VCCIO1, for which 1.8V is not possible? And the voltage for VCCIO3 is 3.3V only as "default". Nothing says it can't be different. There is no "not supported" mark. But how is this possible? If all they are connected to the same BUCK4 regulator? This PMIC, rk805, is specifically designed for rk3328 (among another SoC), but it looks like they made it nearly impossible to provide a dedicated regulator for SDMMC0 power domain, that is allowed to switch voltage, without affecting other modules. And the same time they embedded a UHS-I capable controller inside of rk3328, that does require voltage switch for operating in this fast mode. Could anybody clarify this situation? What the above table does really tell? tllim please.

Your assumption is correct. In order to get the UHS-I capable on RK3328, the voltage switching is needed.

[z4v4l]

Your assumption is correct. In order to get the UHS-I capable on RK3328, the voltage switching is needed.

Is it possible on Rock64? Is the power domain of SDMMC0 (VCCIO3) sourced from a dedicated voltage regulator?

Of course it's not. I looked over the Rockchip dts files for rk3328, and none board had a dedicated voltage regulator for SDMMC0. Why they put UHS-I capable controller there then, if they made it impossible to use it? Funny, it's claimed to be compatible with rk3288's and that is SDR104 capable. wahoo. this thing could achieve ~75MB/s (given 150MHz limit exposed in the dts for the contoller functional frequence) but instead it is trice as slower.

Interesting, there is a regulator for a bunch of 1.8V domains, - LDO1. Why it was necessary to allocate a different one for eMMC, - LDO2? Couldn't it be fed from LDO1 as well and LDO2 instead would be used for SDMMC0? Were there technical reasons behind this decision? Isn't it possible to reevaluate it and consider allocating LDO2 for the SDMMC0 interface, bringing UHS-I at least to the future Rock64 revisions?