Now that I have examined the lab126 changes to the mmc driver in the K1 kernel source code, I saw that it has additional code for SDHC support (and yes, SDHC cards work in my K1 as long as they are full SD-sized, not microSD in an adapter).
However, most of my microSD cards are large capacity (SDHC), and though the K1 kernel code looks like it TRIES to switch from one-bit mode (not required to be supported by microSD) to 4-bit mode, the slow speed makes me wonder if that code ever works.
I did find something new though -- a 2GB microSD card (not SDHC) that works in my K1, in an adapter (so it fits in the larger SD slot).
So what I have experiences so far, is microSD (not SDHC) seems to work, AND large capacity SDHC (in full SD form factor) also work, but the bulk of my microSD cards are SDHC, and NONE of them have worked so far in a K1.
I have around here somewhere an UNUSUAL card - full-sized SD that is 4GB SD (not SDHC), which sort of violates the SD spec. Many (if not most) devices use signed arithmetic in the mmc driver, which limits is size range between NEGATIVE 2GB and positive 2GB. You need UNSIGNED math to go from 0-4GB, so this 4GB SD card is iffy onto which devices it will work.
The main difference between SD and SDHC protocol is that SD uses BYTE addressing (with the bottom address bits always zero when used as a block device), whereas SDHC uses sector addressing (allowing much more than a mere 2 or 4GB).
The only possible benefit to byte addressing on SD cards would be for tiny devices that do not have enough RAM to hold a 512-byte sector, where they could read and write individual bytes (or smaller blocks of bytes).
I found more of my microSD cards, so I am testing them all again. It was refreshing to find a microSD that works in a K1 (though 2GB is rather smallish). Though really, in my collection in front of me, I have full-sized SD cards with capacities as small as 128MB (yeah, not GB).
And being a "bleeding edge" tech collector, I spent many hundreds of dollars years back on a first-generation USB flash stick, a full 128KB (kilobytes) and it still took over an hour to fill it -- USB 2.0 was not invented yet, and USB was originally meant for slow things like mice and keyboards...
But then again, I still have 5MB hard drives in my collection (which hold the equivalent of about THREE IBM floppy disks), and they only moved the read heads (via stepper motors) at TEN steps per second (just like really old floppy drives). It took several seconds to seek from an inner to an outer cylinder. And we thought that was amazingly FAST back then (when most of our code was stored on boxes full of audio cassette tapes).
And for something more contemporary, the new kindles (like the PW3) are covered with "test points" (little pads on the PCB). I think a lot of those are probably routed to unused GPIO pins on the SoC, and all it takes is a few o them to connect an SD card up and use some custom code to use it as an additional storage device. On my K1, all the GPIO bits are available in the /proc/ tree, so perhaps an SD-card "driver" could even be written in a script (like my eink algorithmic art scripts). But who has enough (unpaid) hobby time to actually do such things?
|