Hardware driving the MicroSDXC slot?

Hello together!

I’d like to know what is driving the MicroSDXC slot: Is it an ordinary USB Mass Storage adapter or a dedicated SD Host Controller either provided as a PCI or USB device (like the VUB300) or as part of the SoC (as I know quite some Atom CPUs have)?
I’m asking as the latter would allow a more direct access to MicroSD cards than USB adapter speaking the Mass Storage protocol. It being a Mass Storage adapter of course wouldn’t be a deal breaker considering all the other very nice features, but it would be a pity nevertheless to have 3.1 USB ports, but an inferior MicroSD slot… :wink:

Kind regards,

Can you please elaborate why you think that wiring it up through USB is a bad thing? :slight_smile: USB 3.0 has much more bandwidth than any microSD card can provide!

Regarding the bandwidth I agree, but if one has a SDHCI (SD Host Controller Interface) instead of a mass storage adapter then one can directly access the card’s features like the temporary and permanent write protections or the password lock. Of course these would depend on the capabilities of the SDHCI driver, but with a mass storage adapter one doesn’t even have that chance (there is only one mass storage adapter chip I’m aware of that allows such a passthrough: the Cypress Astoria). Also SDHCI does not necessarily exclude USB, as there is the VUB300.
In addition to that the current Atom CPUs for example usually have a SDHCI as part of their chipset as they need that for the eMMC. Usually the hardware manufacturer also provides an SD or MicroSD slot then, plus the SDIO slot could be used for a WiFi, Bluetooth, GSM, whatever card or even a second SD or MicroSD slot.

But isn’t it possible to just use a different driver? Anyway, since we don’t use Atom (so no SoC here), I can’t answer this question directly.
@iKirin @Konstantinos @Mike how is the SD slot wired up?

P.S. you mentioned password lock and write protections - I’ve never heard of these features, can they be used in a smartphone? Also, full-size SD cards have a physical button to toggle write lock - are you talking about the same write lock?

No, it’s not possible to use a different driver as we’re talking about completely different protocols here. The card itself speaks what’s essentially the SD/MMC protocol. A USB mass storage device however talks in what is essentially a SCSI protocol. So an adapter translates the SCSI commands it receives from the host computer to SD/MMC commands and back. However it does not translate each and every one as some commands have no corresponding one in the other. E.g. you can’t translate a SCSI UNMAP command (its a TRIM equivalent) as SD cards don’t support something equivalent ((e)MMC’s would however) while you can’t represent the card’s write protection flags in SCSI commands. That’s why the Cypress Astoria I mentioned provides a passthrough of SD/MMC commands through the SCSI protocol (something akin to ATA passthrough that some USB-SATA adapters support).

At least from a technological point of view it should be possible to use password lock and the write protection bits in smartphones as they usually have a SDHCI or communicate directly with the card on a SPI bus anyway (e.g. many embedded ARM boards do it this way; you could even bitbang the protocol with a few GPIOs).
A quick Google search turned up a few tools that might be of use, though you’d probably need to include corresponding user interfaces for Android yourself:

  • sdtool (to set TMP and PERM write protect flag)
  • mmc-utils (uses a different way of communicating with the driver; for an example see here)
  • sdlock (Tool to lock/unlock the card with a password)
    Note: I’ve just found these and tested neither of them, so handle with care, especially considering the permanent write protect flag as that is exactly what is says on the tin!

Speaking of which: the physical write protect switch is something completely different than the two flags I’m talking about. The switch merely triggers one of the card’s pins (the Write Protect pin) and can be completely ignored by whatever hardware the card is directly talking to (e.g. there can be USB mass storage adapters, especially cheap ones that don’t give a damn about the switch while others might respect it). The two write protect bits TMP_WRITE_PROTECT and PERM_WRITE_PROTECT however are enforced by the card’s firmware and thus can’t be circumvented. As mentioned above especially the latter permanently write protects the card (useful if one distributes software that shouldn’t be manipulated anymore).

USB bus is universal, as it supports many different protocols. Including digital audio, input devices, mass storage… that’s what I meant :slight_smile: maybe we could use a different protocol to enable those features, while still using the USB bus.

Btw i’m just curious, what would be your ise case for these features in a tablet. Pardon my incompetence, but to me it seems like professional tools that are really rarely used in consumer-centric computers.

Yes, USB itself supports many protocols, but a given piece of hardware usually speaks only one protocol. In the case of a mass storage adapter that would be the SCSI based mass storage protocol. Two alternatives that would allow one to connect a SD card by USB while still allowing to utilize all the card’s features are the chips I had linked to earlier: the Cypress Astoria (speaking the mass storage protocol with a SD/MMC passthrough) and the VUB300 (implementing the SD/MMC protocol on top of USB).

It’s not necessarily that I have a use case for it (though thinking about it password protecting the card does sound useful), but that shouldn’t mean that one should restrict oneself, especially considering a community planned device like the Eve V. :wink:
That said my main interest is that I had developed a SDHCI driver for my company’s OS and I’m always looking for hardware to test it with to further refine it. :slight_smile:

Actually, I think most USB hardware is “protofol agnostic”, by which I mean it can support any protocol if you write the right software for it. For example, PCM audio over USB. I have yet to see a computer or smartphone that does not support it - although older Android versions don’t. So a phone that came with, let’s say, Android 2.1 didn’t support it, and when it was upgraded to 2.3 it “learned” it. Which shows that even hardware that was not “supposed” to support a specific protocol works just fine when you update the software. That said, I understand that SD card native protocol is not directly compatible with USB, so there must be specific hardware to “translate” it into USB, which brings us to several different existing protocols. Am I right?
Oh, and shouldn’t your company provide you with test hardware? :slight_smile: Likely the driver was built for a specific purpose of your company, so they ought to have hardware that requires it!

You are comparing apples with pears. Android smartphones are not specialized hardware, they are implementing the general host or client interface (depending on what you’re connecting them with) while hardware chips only support specific protocols. And that’s what we’re talking about here: a mass storage adapter isn’t some fancy ARM core with a Linux running on it so that it can speak any protocol that comes across, but they are rather simple pieces of silicone, maybe some microcontroller that executes firmware, but that’s it (and even then they are more often than not sloppily done, the kinds of workarounds an OS has to do with hardware due to it being crappy are truly amazing; and I’m talking both Linux and Windows here).
We already have quite some test hardware at work, but if I can get my hands on a nice gimmick and use it to test our software and OS on it even the better :stuck_out_tongue: Also the problem is that there are so many different SDHCIs and they all behave slightly different. In addition to that it’s not always obvious how a SD slot is connected to the core until one looks at the PCI bus, the ACPI tables or the connected USB devices - that’s why I’m asking here after all to get an answer before I get my hands on a device.

1 Like

I just gave you an example of a protocol that doesn’t need hardware support :slight_smile:

In your example that only applies to the phone or computer however. The device you’re playing the data with (let’s say a USB headphone) can’t provide a different protocol than what it had been coded/designed with. Linux (and other OSes) can for example without problems provide a mass storage device; this is usually done to access a smartphone’s storage (though nowadays more often than not another protocol is used). Or the smartphone can pose as a network device, thus providing another computer with a network connection.
That however does not change that hardware that does not contain a programmable CPU (be it x86, ARM, AVR or whatever) is restricted to a specific protocol. A mass storage adapter is restricted to the Mass Storage Protocol, while a USB headphone is restricted to the corresponding audio protocols. You can’t use a audio protocol with a mass storage adapter chip or the mass storage adapter protocol with an audio chip (aside from hardware of course that does provide multiple interfaces; e.g. modern USB sticks and USB SATA adapter more often than not provide also USB Attached SCSI in addition to the Mass Storage Protocol).

TL;DR: If you have a chip that does only support a specific set of protocols (normally one) then all the capabilities of an OS to use different protocols won’t help you to talk to that chip with a protocol it doesn’t understand.
When talking about protocols always at least two communication partners are involved and you only looked at one of them in your example.

Yes I know. That’s what I said in the rest of my comment.

But you were also implying that support on the side of the host OS (Windows, Linux, Android, etc.) would be enough to utilize a different protocol on the bus. But it also needs the other side to understand that protocol which is why I asked what kind of chip is used for the MicroSD slot.

Did I say that? I don’t remember saying it…