SD card proprietary modes - have these escaped into the wild?

[peter-h]

AFAICT the only one of the multiple SD modes which is not secret is the "SPI" serial mode, described e.g. here
https://openlabpro.com/guide/interfacing-microcontrollers-with-sd-card/
It seems to be limited to about 5mbps, which is fine for writing mp3 files in say a sound recorder, but not much good for anything faster.

I did a google on whether any of the proprietary modes have been reverse engineered and documented but haven't found anything. Well, the file is called
Part_1_Physical_Layer_Specification_Ver3.00_Final_090416.pdf
and there are many google hits but none of them lead to a real PDF.

ST seem to have implemented it in the 32F4 but one needs proprietary software to drive it.

[DavidAlfa]

Have a look there:
https://forum.arduino.cc/t/documentation-for-the-sd-4-bit-protocol/481051
http://alumni.cs.ucr.edu/~amitra/sdcard/Additional/sdcard_appnote_foust.pdf

But 4-bit mode enforces CRC, it's not optional like in SPI mode.
Not only that: Each of the 4 data lines use its own CRC, it would be a lot of processing power if done in software.

CubeMX works with 4-bit SD, you can investigate ST code and implement your own.

[Yansi]

ST seem to have implemented it in the 32F4 but one needs proprietary software to drive it.

Bullshit. 

//All required code is freely available even from the vendor, ST. Even the initialization command sequence for 1/4/8 bit SDIO is freely available even from the horses mouth, sdcard.org ( https://www.sdcard.org/downloads/pls/ )

I have no clue what do you have a need to reverse engineer here.

[peter-h]

OK, so it is all provided, and you just need to purchase the license from SDCARD?

I am informed that the fastest 4 bit mode is still proprietary. Is that incorrect?

Yansi - you may call it "bullshit" but what does this text mean?

Notice of SD Simplified Specifications
The following conditions apply to the release of any and all parts of the simplified specifications (“Simplified Specifications”) by the SD Card Association and the SD Group. The Simplified Specifications are a subset of the complete SD Specifications which are owned by the SD Card Association and the SD Group. These Simplified Specifications are provided on a non-confidential basis subject to the disclaimers below. Any implementation of the Simplified Specifications or any portions there of may require a license from the SD Card Association, SD Group, SD-3C, LLC or other third parties.

How do you translate "simplified" into English?

[Nominal Animal]

Teensy 3.5, 3.6, and 4.1 have microSD sockets built-in using SDIO.  The relevant Teensyduino/Arduino library is SdFat, which is licensed under the MIT license.  You'll find the SDIO specifics in src/SdCard/Sdio{Card.h, Teensy.h, Teensy.cpp}.  The source for the information needed is NXP Community thread #99202, and the SDHC_K60_Baremetal.ZIP therein provided by NXP's Petr Gargulak.

As far as I know, implementing SDIO on hardware that does have the hardware support for SDIO, does not actually require access to the proprietary non-free SDIO protocol documentation.  The existing information available on the net provides enough information to implement this.

Now, whether you need an additional license, depends on whether you need to mention "SD", "SD card", associated logos, or pictograms; and your own local legal jurisdiction.  The main point of said licenses is to give you permission to use the related trademarks, logos, and possibly patents/utility patents.  As of 2021, the SD Host/Ancillary Product License Agreement is $5000 per year, but if you use a dev board, dev kit, or an MCU, you may already be covered by the manufacturer's license anyway.

[peter-h]

Interesting - thank you.

The impression one gets from googling around is that ST obviously got the license in order to design their silicon but they are not offering a license to ST CPU users, which seems equally obvious to me otherwise every ST CPU user would be doing the SD card consortium out of a large amount of money

My main interest in this is as an easy way to store large amounts of data in a linear manner and I could probably just use the SPI mode, which is also easy since I have an SPI channel dedicated to various peripherals, mutex protected so it is thread-safe, with dynamic re-initialisation for different slaves, etc. The max clock frequency isn't clear though; some cards (e.g. Kingston) spec 25MHz, while others seem to be much less. I can go up to 21MHz on my board.

And a key point is that the SD card would not be externally visible, even though that's not relevant because the SPI mode is license-free.

AFAICT using an SD card for lots of memory is a good way of futureproofing a design, because if you solder a FLASH chip to the PCB, a few years later you won't be able to get that chip anymore.

[PlainName]

I'm a bit puzzled by this. Back in 2009 I was accessing SDCards (also better known as MMC in those days) via the Linux kernel drivers, which seem to be the complete source. This was using 4 data lines rather than SDI. OTOH, we made our own interface (aka GPIO on the CPU) and the magic was obviously via software. As I recall, using a hardware interface was deemed to be a few pennies too many on the product.

[thm_w]

AFAICT using an SD card for lots of memory is a good way of futureproofing a design, because if you solder a FLASH chip to the PCB, a few years later you won't be able to get that chip anymore.

Yes its a good plan, if you want long term lower cost product, as flash chips can die over time but SD card can easily be replaced.
However there are a lot of limitations as well. I think the max response time can be in the order of seconds, due to internal ECC processing. Speeds may be slower in general.

Also something like a 8pin SOIC flash is always going to be available, its just too commonly used.

[peter-h]

"Back in 2009 I was accessing SDCards (also better known as MMC in those days) via the Linux kernel drivers, which seem to be the complete source"

AFAICT the issue is not the software. Anyway, nobody can control how far software spreads. The patent issue would be over an actual implementation i.e. the hardware, and the software to drive it.

That PDF I could not find is all over Chinese sites but none of them actually deliver it, which suggests that this was the full spec including the "confidential" parts referred to at the SDCARD website. The same PDF also comes up on stackexchange and other "western" sites but has been removed from all the ones I found. If that info became public then lots of people could do an FPGA implementation. It's not worth doing this unless you want the full speed, and the full speed won't be achievable if you have to do a software CRC on each of the four data lines.

Most Linux installations are running on 80x86 hardware i.e. a PC motherboard and/or add-on cards, and SDCARD will be collecting the royalties from the chipset makers.

"something like a 8pin SOIC flash is always going to be available, its just too commonly used."

Yes although they vary in pinouts and - right now - availability. Look at Adesto. Two sets of pinouts... I am using these already (the 4MB version - AT45DB321) and they are almost unobtainable. Whereas SD cards are ok.

[Nominal Animal]

While I am not a lawyer, I have dealt a lot with different software licenses (both as a client and as a vendor), and although hardware licensing is somewhat different, I do claim I recognize certain things in the language used here.

If I were you, I'd happily use SDIO to access an internal microSD card, and not bother getting a commercial host license.  I would simply be diligent in that nothing in the product or its documentation referred to "SD card" or the SD pictogram (except for on the physical SD card), and consistently used e.g. "memory card with a FAT-compatible filesystem on it".  At the point when the product sales exceed 1000 units in a single year, I'd reconsider the situation (but most likely continue with the same strategy).

Note that I am somebody who is extremely diligent with respect to copyright and licensing; only somewhat immune to copyright and license marketing and hoodwinkery, which I absolutely detest.  I respect the idea and the execution, and lawful contracts, but I am not going to pay for salespeoples wet dreams.

The reason why I'd not worry about a license at small volumes of sales for internal use, is the exact wording on the sdio.org website about who requires what kind of a license, and what that license provides; and the relationship between MMCplus and SDIO, especially wrt. the 4-bit data bus, and what that means with respect to patent coverage, considering MMCplus has no host license requirements.  The fact that that list of patents is kept extremely carefully under wraps tells me a lot.

The way I see it, the license covers the registered trademarks and pictograms, and defuses an implied threat of litigation wrt. undisclosed patents.  OneLaptopPerChild community news on 2006-09-16 mentions they do not believe their implementation requires a commercial license, for example.

When you make a decision yourself, do not rely on my opinion here, obviously.  But do consider pointing out these things to the lawyer you consult with, to make sure they grasp the whole picture.  Then again, consulting a lawyer is likely going to cost at least the same as a host license for a year, so...

That PDF I could not find is all over Chinese sites but none of them actually deliver it, which suggests that this was the full spec including the "confidential" parts referred to at the SDCARD website.

Are you referring to the Physical Layer Simplified Specification v6.0, as linked from the Wikipedia Secure Digital page?  See the Openness of specification chapter.  In chapter 4.5, it mentions that the CRC7 is 7-bit, and uses generator polynomial G(x)=x⁷+x³+1; and CRC16 is 16-bit with generator polynomial G(x)=x¹⁶+x¹²+x⁵+1.

[peter-h]

"Are you referring to the ..."

I was referring to the mysterious file called
Part_1_Physical_Layer_Specification_Ver3.00_Final_090416.pdf

which appears referenced on many sites (but has been removed from all) and appears linked on many chinese sites (but all those links appear dead).

Something tells me that is some sort of confidential spec.

"The fact that that list of patents is kept extremely carefully under wraps tells me a lot."

That's bizzare. Most patent owners plaster the numbers all over their product, to discourage casual ripoffs.

Who came up with a CRC per data pin? It must have been done to obscure the interface, before that aspect was published. Basically any attempt to reverse engineer it would be very unlikely to succeed because who would suspect that was done? Unless somebody found a software implementation, but that's unlikely to exist because it would be too slow.

[Nominal Animal]

Part_1_Physical_Layer_Specification_Ver3.00_Final_090416.pdf

I do believe it is superceded by "Part_1_Physical_Layer_Simplified_Specification_Ver_3.01_Final_100518.pdf", and that the PDF I linked to, "SD Specifications, Part 1, Physical Layer Simplified Specification, Version 6.00, April 10, 2017", provides essentially the same information, is the currently latest version of it. Ver 3.01 is available at eg. cs.utexas.edu.  (Again, that v6.00 PDF is linked to from the Wikipedia SD card article, section "Openness of specification", paragraph "The Simplified Specification is available.")

The fact that that list of patents is kept extremely carefully under wraps tells me a lot.

That's bizzare. Most patent owners plaster the numbers all over their product, to discourage casual ripoffs.

It is typical for licenses that are designed to be cheaper than a minimal response to a lawsuit.  If the vendor ever does actually initiate a lawsuit, it will carefully avoid naming the patents, and instead lists things like current licensees in an effort to convince the judge that "it is so obvious a license is needed" (that we shouldn't be forced to weaken our position by exposing the privileged patents list).  This is extremely common in the software world, where most of the patents are invalidated when actually challenged.  But challenging them costs a lot of money, at least an order of magnitude more than the SD card host license, probably two orders of magnitude more.

As an example, in 2004, Microsoft applied for a patent on the "IsNot" operator (! in C, C++, Javascript, etc.).  The patents could be obviously invalid like that, or worded so vaguely that fitting prior art can be found.

[peter-h]

Indeed, most patents in technology are invalid - on prior art, or "obvious" grounds - if challenged under the proper application of funds

But that's a whole other discussion, which somebody usually starts with a "prove it" challenge

Referring to the "simplified specification", what would be a non-simplified specification and where can it be found?

[PlainName]

Who came up with a CRC per data pin?

That would make sense to verify the integrity of the pin data. If you're doing it in hardware you'd probably want a bit-stream, which is simple if it's per pin and a bit tricker if it's per 2x4 pins.

[peter-h]

Sure, but isn't this a bytewide protocol, fundamentally, like nearly all the rest of computing?

With say SDLC you are nearly always sending the data serially but there are still two CRC bytes.

I reckon this was done to make a software implementation too slow to be useful, which helps to enforce licensing because collecting royalties from a chip maker is far easier than collecting royalties from software driving half a dozen CPU GPIO pins.

A parallel example might be DES which, it was claimed by some in the early days, was designed to be slow in software, thus forcing the use of DES chips which could be export controlled. That claim was probably only partially true because there are fast software implementations, albeit needing lots of RAM.

I can't see why this should be more complicated than a nibble-wide bus with a clock and a /cs pin.

[PlainName]

Deleted my first reply, sorry.

Sure, but isn't this a bytewide protocol, fundamentally, like nearly all the rest of computing?

Only because you're using a byte-oriented computer to deal with it.

I think this page explains things better than the Wiki page I previously linked to. You can see that the CRC calculation lends itself to a shift register (not surprising since the data was originally assumed to be a serial stream).

http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html

[thm_w]

Yes although they vary in pinouts and - right now - availability. Look at Adesto. Two sets of pinouts... I am using these already (the 4MB version - AT45DB321) and they are almost unobtainable. Whereas SD cards are ok.

That is a 32 pin TSOP though.
8 pin SOIC should almost always have the same pinout, width can vary, but footprint could account for multiple widths.

https://www.digikey.ca/en/products/detail/winbond-electronics/W25Q32JVSSIQ/5803981

[peter-h]

They are both SO-8, and the Adesto (whose pinout varies) is 512 byte sectors which is much better for producing a windows compatible file system. The Winbond devices are cheap for sure but have 4k sectors.

Haven't read the huge sd card spec but that must be emulating 512 bytes with a 4k RAM buffer, to present a logical block device with 512 byte sectors.

[Rasz]

rpi pico 4bit SDIO implementation
https://github.com/raspberrypi/pico-extras/tree/master/src/rp2_common/pico_sd_card