ucplay: I've looked into that ez Share card a bit, and it seems to require a windows application to update the firmware. I can find the update application, but not the firmware itself. Still, that seems to suggest that, like the FlashAir, it's probably not KeyASIC-based. If you do pick one up, let us know what you find.

Also, the PQI AirCard (when writing from a host device) seems to be limited only by the microSD card you put in it. I was able to reliably get about 11.5MB/s with the PQI-branded class 10 16GB microSD card that came with the device, and 5.1MB/s with a SanDisk class 4 8GB microSD card I have lying around. This is consistent with using a normal microSD card adapter. These were all done with large sequential writes (which is typical of the load imposed by a camera writing photos or video).

From within the card, the rates are pretty abysmal, regardless of what kind of microSD card you have inserted. With large sequential writes, I get around 1.3MB/s.

Writing to the internal NAND is similar to internal SD - less than 1.5MB/s, though my testing in NAND was not too rigorous.

Take these benchmarks with a grain of salt - I only tested large sequential writes, and I made sure only one thing was writing at a time (host or internal). If you are really concerned about performance for a particular workload, you'll want to simulate that workload and benchmark it yourself.

Xylosis: it's possible to use these as stand-alone devices, but I understand that unless you initialize the SD card from the host side, the internal device can't access SD storage. NAND and WiFi still work though. I think someone is working on a driver to deal with this, but nothing has materialized. I think cnlohr would know more than I about this though.

I know that's not what you asked for, but as I did them, I'll post those results so they don't go to waste :

(All tests performed on a Transcend USB3 SDCard reader in a USB3 port, with the cards previously formated usinfg SDFormat)

WifiSD 16Go Class 10

FluCard 8Go Class 6

AirCard with a Kingston 16GO Class 10 µSD

The same µSD directly in the reader

A Sandisk 16Go U1 µSD, that sadly the Aircard can't read

(Last edited by pixelk on 1 Nov 2013, 17:56)

Here are my results of looking at the debug pads on the PQI AirCard:

TP6   - constant 1.8v, it's connected to a thick track to the wifi, so I think it's the power of the Wifi chip
TP8   - unknown (constant 1.8v, it might has something to do with the wifi)
TP9   - unknown (constant gnd, again, it might has something to do with the wifi)
Any idea on TP 8 and 9?

TP10   - HOST D3
TP11   - HOST CMD
TP12   - HOST CLK
TP13   - HOST D0
TP14   - HOST D1
TP15   - HOST D2

TP16   - SD D3
TP17   - SD CMD
TP18   - SD CLK
TP19   - SD D0
TP20   - SD D1
TP21   - SD D2
TP22   - SD VCC (it's just vcc actually) (name of TP20 and TP22 is a guess, based on the visible parts)

So nothing particularly interesting here.

Unlabelled pads:

PWM0 and PWM1 (i just made up the names): by their looks, here would be connected the tiny buzzer (it even has its place in the case, and also painted on the pcb), but i might be wrong. One of them is 0v, the other is 3.3v. The dmesg says at boot "pwm set 0 \ pwm set 33685506", so I guess 33685506 is 100% duty cycle. I tried to play with the "buzzer" applet, which generated differend sets of values in dmesg, but no difference on the pads, so it might be that it's not properly implemented in software, or that these pads serve some other purpuse. Do we have the source code responsible for /dev/pwm and /dev/pwm1?

Grab PQI Firmware v1.47 and look in Linux_KA_2_6/arch/arm/mach-ka2000/ka2000-pwm.c for the source to /dev/ka-pwm, which I believe is the device you're looking for.

(Last edited by dankrause on 5 Nov 2013, 21:02)

Nice work hskorbi !
Maybe there's also some capacitors that aren't populated between the GND and PWM0/PWM1, even if there isn't one in the FluCard that has a working buzzer.

Hello everyone.
Been following this thread since the beginning and i have to say the work everyone is making is amazing. Who would think that such a tiny card could be capable of so much !? Can't wait to have openwrt on it one day!

Anyway, i've been experimenting with dankrause firmware release 0.2 for a few days on a PQI Aircard. After setting up a chrooted debian filesystem, i realized that the card felt slower then with the original firmware. Is it because the PLL is turned off to lower the power consumption? If so, is there any way to turn it on 'on-the-fly'?

The main difference i could see on dmesg was

[    0.000000] (192-192-1)pclk rate 96000000

[    0.030000] Calibrating delay loop... 421.06 BogoMIPS (lpj=2105344)

on the original firmware

[    0.000000] (192-96-1)pclk rate 96000000

[    0.030000] Calibrating delay loop... 50.68 BogoMIPS (lpj=253440)

on dankrause firmware 0.2

hybridmetta: As far as I can tell, that's caused by the kernel. The kernel included in my release was built by Dmitry Grinberg here. I'm guessing that if we want to change that setting on boot, we'll need to change it in the kernel config. I haven't had time to dig into a way to configure it at runtime though. I'll check it out when I have a moment.

I just got my boards in today and soldered one up.  (This is still for the Transcend card)

http://imgur.com/a/OnEm3

I am still trying to find alternative mechanisms to communicate from Linux inside the card, via the SD interface to my AVR outside. 

I have tried CMD56, but have been getting some very confusing results.  Whenever I try to do a CMD56 read, it fails, and I can't seem to abord.  Same to writing.  It doesn't look like I can use any other general registers to communicate back and forth.  Does anyone know if you can read back from the password area in CMD42?

Any other ideas for a mechanism to communicate back and forth over the SD interface?

(Last edited by cnlohr on 19 Nov 2013, 23:26)

cnlohr: I'm not to familiar with the SD SPI protocol, but I'm going over some docs right now. Have you attempted using CMD55? Is it fair to assume you're patching (or temporarily replacing) the ka2000-sdio driver to handle communication from that side? There's a reasonable chance you'll run into problems with the keyasic chipset not passing commands into the bus that the kernel uses to talk to the SD host.

Eeeyup.

Nope.

@dankrause Thanks for the clarification.

Has anyone successfully used the PQI Aircard in SPI mode? I gave it a shot myself but i don't seem to get any valid response from CMD0. All the other regular SD cards i tested responded correctly with 0x01 but the PQI always responds with 0x80 for the first try and 0xFF for the retries. That looks weird because the start bit should be 0 but it always comes back as 1. Did PQI decide not to implement SPI or am i missing something?

@cnlohr Did you try CMD53 (IO_RW_EXTENDED)? I skimmed though the SDIO specification in https://www.sdcard.org/developers/overv … d_Spec.pdf and it looks like there might be some usable registers for special functions. For what i could tell, SDIO devices should be available though SPI. If the card exposes an SDIO interface then maybe we can send something like 0x75 (command) 0x04 0x00 0x00 0x00 (argument) 0x01 (assuming CRC is off) and receive 512 bytes containing the functions available?

EDIT: https://www.sdcard.org/downloads/pls/si … E1_300.pdf is the file with more up to date specs

(Last edited by hybridmetta on 3 Dec 2013, 02:05)

Hello guys.
I wonder, is it possible to add WebRadioReciever ability to this SD card?

Just insert such card in your car stereo and listen TuneIn. Great feature, is not it?

Okey - so an awsome hack on its own, but not terribly useful without proper IO capabilities. And I don't count doing IO over sd card very proper (great hack, but still). So i was thinking...

Only built in and accessible IO capability is the slave SD card on PQI Air.
So if one does something like so:
[PQI Air card]-->[FPGA]-->[uSD card]

You make the FPGA just pass through the SD interface - except when PQI Air card attempts to read/write block X, doesnt have to be in a partitioned section of the card at all.
In such a case you read/write the data to FPGA internal or external ram instead of passing it to uSD.
By this point you already have full IO capability.
To make it "proper" one could make a task in Linux that periodically syncs a memory region to said "disk block".
And hey presto - you have a memory link between card RAM and external RAM (or registers of hardware interface x - whatever you want on the FPGA). So your programs see any interfaces you put on fpga as local memory space.

While I can do FPGA programming (so-so) my Linux-fu approaches zero.
So im not 100% sure this approach would work - thus I would appreciate some feedback on the idea.

Meanwhile im waiting for a PQI card and Transcend card I bought, so it will be quite a while before I get around to testing the idea on my own. Anyone else interested and capable of testing the idea?

I think this would work just fine, however at the point where you involve an FPGA to do it you're probably better off to go for a better SoC to begin with.

A different possible angle:
At the recent 30C3 conference there was a talk about running your own code on the microcontroller in normal SD cards (8051 in that case):
http://bunniefoo.com/bunnie/sdcard-30c3-pub.pdf

If you could program the uSD or SD controller behind the PQI or Transcend card you could implement special SD commands for a host to host communication channel in a mailbox manner.
e.g. implement 4 custom SD commands:
cmd1) poll data for hosta
cmd2) poll data for hostb
cmd3) send data to hosta
cmd4) send data to hostb

Then communication could go

[PC]-->uSD card-->[PQI SoC]

and vice versa without resorting to abusing the filesystem.
OTOH if you do this you could just implement the same on raw disk blocks.
e.g. make sure it's partitioned with a parititon table and use the unused blocks between partition table and first filesystem to
implement this even without custom commands (but at the expense of increased flash wear).

I agree with moroboshi, a FPGA is just overkill.

The work talked about at 30C3 by bunny is very dependent on the memory microcontroller and would only work with very few cards. If it targets SD cards with embeded memory, we have no guarantee the vendor won't change the chip the next day.
Those both sound like a lot of work to solve a problem that doesn't really exist.

GPIO are nice but are not a main feature of an OpenWRT setup. If you're so desperate for IO in a small package there's a ton of cheaper and simpler solution (I won't even try to list them).

I've done small research and found out that there are register definitions for sdio switch in Linux_KA_2_6/arch/arm/mach-ka2000/include/mach/ka2000_define.h (everything that starts with SDSW_). Not many information, but at least a hopefully meaningful names.

Also, there is u-boot-gpl/arch/arm/cpu/arm926ejs/keyasic/sdctrl-m2.c "library" for controlling M2, that seems to be statically compiled or copy-pasted into ka2000-sdhc module (same functions present).

Furthermore, it seems that ka2000-sdhc module setups and receives interrupts on some (every? predefined? --- don't know yet) commands been sent from host.

Meh, FPGA-s are much easier than many people think. Easier than hacking SD cards to do something its not meant for.
By IO I didnt really mean GPIO specifically, just general device IO-s. SPI-s, UART-s, I2C-s, adc, MII, whatever you need or want.
Sure every MCU does much of that all that and more(rarely all of that at the same time), but what is not easy to do on your own hardware is Linux and wifi.
And wifi is an awesome way to get debug access.

With this SD card hack I can get MPU, Memory, Storage, Wifi all in one small package already running a full opsys.
Thats a huge amount of work i dont have to spend on making the base system and can instead spend on designing and programming the application (and that is 100X easier to do because you are running your code on Linux not opsys-less)

I will deffinitely attempt this hack, potential benefits are just too awesome to pass by.
IO capability of a FPGA (if its digital you can do it)
Programming capabilities of Linux
And wifi as cherry on top.
All that in a damn small package.

Intel didn't announce Edison for nothing, this kind of approach will become very common in near future (my humble prediction).
May not be a SD card format, but this kind of plug and play entire computer to your application - this will become very common.
These wifi sd manufacturers are idiots to market the products for end user. Open it up and market for hardware devs and everyone will want to use one in their product, because it makes development and prototyping cycle so much easier and shorter.

Sure you could go with some off the shelf SoC solution, like say xilinx zynq, but these are not exactly cheap, some 59$ for cheapest ic of the range alone, not something you can afford to stuff into your volume consumer product. And if you dont have volumes to justify making a custom SoC... well tough luck.

i wish to use wifi sd card as ordinary sd card in windows with drag & drop operations with files/folders.
is it possible to get operate with wifi sd card by this method and access to it like ordinary net share by \\ip_address path name?

//im sorry if i miss answer of my question.

I've removed ka2000_sdhc.ko from firmware and did a few experiments with sd switch interrupts.
First of all, removal of that module leaves device completely operational, yet sd storage is inaccessible. You can connect via wifi and so on.

It seems possible to catch at least read accesses to sd, proof-of-concept here: https://bitbucket.org/generatorglukoff/ … at=default

Nice find, seems I didn't download the GPL release that included that one.

Yeah, I know that some things are possible with the switch module, but haven't had time to play with it much at all yet.

Well, my main thinking is that if you go with an FPGA and all the supporting bits then you'll end up much bigger than the SD card form factor and could have gone with a beablebone or RasPi to begin with.

Would still be a very cool hack of course.

Hi. I know I am a bit late to this party, but I really got interested in those hackable devices.
I've bought cheaply the 16GB transcend on eBay from some guy who didn't have a use for it...
I am following instructions from here to make it usable and everything going fine so far.

The other thread is looking at alternative SD WiFi cards. I wanted to find more information about ez share cards.
I've found http://www.dealwinwin.com/Consumer-Elec … --ID46456/ and my helpful wife helped me read the FCC id.
So I got here: https://apps.fcc.gov/oetcf/eas/reports/ … =A7JEZS126

Especially interesting part is internal photos document. Do you more experienced SD Wifi hackers recognize these internals? Does it look like KA2000?

(Last edited by sjachim on 16 Jan 2014, 02:02)

I personally dream of having sd storage + wifi + accelerator of whatever (e.g. crypto) in such small package and actually use it in RPi.

Anyway, right now I'm working with disassembly of ka2000_sdhc.ko from transcend's firmware v1.6+. I seems found dma regs for sd switch, but I haven't yet luck to correctly implement transfers.

It seems, that stock wifi sd card has some vendor specific sd/mmc commands --- cmd 48 & cmd 49. One is for reading and other is for writing a block of 0x200 (512) bytes into ka2000_sdhc.ko memory. I haven't yet found any usage for that memory address, except they are been accessible via ioctl to /dev/sdsw device file.

Also, it strongly seems, that dma for switch implementation are equal to other ka2000 dma implementations (e.g. for sd card and for sdio). They are following:
#define SDSW_BUF_TRAN_CTRL_REG     SDSW_BASE + 0x22C
#define SDSW_DMA_SACH0_REG         SDSW_BASE + 0x230
#define SDSW_DMA_TCCH0_REG         SDSW_BASE + 0x234
#define SDSW_DMA_CTRCH0_REG        SDSW_BASE + 0x238
#define SDSW_DMA_DACH1_REG         SDSW_BASE + 0x240
#define SDSW_DMA_TCCH1_REG         SDSW_BASE + 0x244
#define SDSW_DMA_CTRCH1_REG        SDSW_BASE + 0x248
#define SDSW_DMA_INTS_REG          SDSW_BASE + 0x24C

These are explicitly used in the module and their usage is consistent with usage of other dmas.

Hi,

Is there anyone experiencing stability issue with the Transcend 16Gb V1.8? Everything connects fine, I am doing my thing on a telnet connection and boom for no reason after a while (could be after 1 or 10 min), the card is no longer responding. Then I need to unplug the card to restart the system. I tried to figure out a pattern why the card crash but I don't have any answer right now. 

So I was wondering how is the stability in general with the Transcend card? What's your experience out there?

Thanks!

ttytt, What are you using as host/power supply for your card? My card doesn't work at all when inserted into laptops SD card slot, but when I use cheap external USB multi card reader it works no problems.