[filtered hyperlink] was the first post I saw about this, with the author shell-injecting perl scripts on the card (yeah, the admin and much of the daemons are written in perl). It also has notes about init.d running autorun.sh from the root of the flash storage area.
[filtered hyperlink] built a kernel with ext4 and swap enabled and has notes about how to re-flash the thing: put image3 (the kernel), initramfs3.gz (it uses this ramdisk as the root filesystem), and/or mtd_jffs2.bin (r/w jffs filesystem to hold config) in the root of the SD card, along with program.bin (derived from uboot), and the bootloader (modified uboot) will reflash whichever are present when it reboots. Then it'll come up with as an access point with a name like SDWIFI1.6. When it shows its version like that, it needs to be rebooted again to load the new kernel etc. Since the bootloader is doing that, as long as you don't replace the bootloader, and as long as the first partition of the card is fat32, you can unbrick it if you screw up.
[filtered hyperlink], reachable from the support page for the WiFi SD card, gives you most of the code used to build the thing, including the ram disk image (the Linux filesystem including the perl and binaries for the apps that make the thing into an end user product). Dmitry noted that the kernel source lacked the config they used, and worse, lacked two modules. I think the AR6000 module is in the tree, but just isn't under arch/arm. I haven't tested building that to see if it works. The other one missing, KA2000_SDHC, is less clear. Related symbols are floating around, but not a module that I can see. Dmitry modified the kernel to load the kernel object (modules) from Transcend's distribution and that seems to work.
I put this into my (from Linux running on the card's point of view) autorun.sh: /sbin/busybox telnetd -l /bin/bash & That let me just telnet in (after the next boot).
I installed Dmitry's kernel and ramdisk (image3, initramfs3.gz), then installed a full busybox. The busybox it comes with is badly stripped down. [filtered hyperlink] has just about everything you could want, including top, mkfs, swapon, etc.
I grabbed a Slackware root image from [filtered hyperlink], which proved not to be an image but a tar.gz created from files in the filesystem. The full busybox gave me enough to work with there though. slack-14.2-miniroot_01Jul16.tar is the latest as I write this and it worked fine.
Reportedly, uboot on the card will refuse to boot if the SD card doesn't contain a fat32 filesystem, but it seemed like I could partition it, leaving a fat32 filesystem as the first filesystem and make an ext2fs on the second, and sure enough, that worked. I stuck it into a Linux machine, using the special Transcend SD-USB adapter, and repartitioned it, creating a large 20gb ext partition and a smaller 10gb fat32 one (first partition).
I was able to do /mnt/sd/busybox-armv5l dd if=/dev/zero bs=1024 count=4096 of=/mnt/sd/swap and then /mnt/sd/busybox-armv5l mkswap /mnt/sd/swap then /mnt/sd/busybox-armv5l swapon /mnt/swap to get some swap going. Likewise I used busybox-armv5l to reformat the ext partition because Dmitry's kernel didn't like the options other-Linux formatted it with, so I made it ext2. Then I was able to use busybox-armv5l to mount that and then to untar the Slackware disk tar file (I pre-gunzip'd it but /mnt/sd/busybox-armv5l tar -xzvf may have worked fine... note that you can run busybox hard-linked to the command you want to run, or passing the command you want to run as the first arg, as I'm doing here). Then I used it again to chroot in. Then after installpkg failed, I eventually figured out I needed dev files, so I exited and did cp -a /dev /mnt/sd1b/ (I mounted the SD ext partition there), then installed a bunch of stuff and things are pretty good.
screen doesn't want to run because it thinks I'm not on a terminal, and I didn't mount another copy of /proc on to there yet so top doesn't work.
This thing piqued my interest because its 32 megs of RAM is the same that my NetBSD MacPPC server ran for ages, very well, and it because it came with a perl already on it. Tiny computer, yay! I was thinking of running it with a micro-SD-to-SD adapter (yes, backwards from usual) and putting it in my Garmin eTrex 20 so I could more easily put routes on it: [filtered hyperlink]
However, testing with a few SD devices I have around, like a silly mp3 player that's shaped as a cassette tape and works as one (kind of like an mp3 player and a tape adapter in one), and an old post-Diamond Rio mp3 player, it doesn't come on line (I have it set to connect to an existing AP; had to use nmap to find it). Likewise for putting it in the Transcend USB-SD adapter and giving that power, but the Transcend USB-SD thing likely somehow inhibits Linux from booting on the card.
There's one script that runs every 60 seconds called "bodyguard" that attempts to remount the SD card. From the point of view of Linux on the thing, the SD card is at /mnt/sd (with a few links to that in other places). There's no magic there... the filesystem is mounted by two machines at the same time, when you plug it into your camera or computer (without using the special adapter, if you have an SD card slot or a different adapter). That works just as badly as you'd think if they're both trying to write. Remounting it must effectively clear the read cache from Linux's point of view but I didn't actually observe the remounts to work.
So, it doesn't ever come online and get on the network and let me telnet in to it unless it is plugged directly into the SD card slot in my computer. Nothing else works (I don't actually have a camera to test it with). It also doesn't function as an SD card under OpenBSD or Linux, but does under Windows. Trying to mount it or fdisk it or anything, I just get read errors. Not sure what that's about.
Doing things like untar'ing, I notice that a sdio process pegs the CPU, so it seems to be the case that it is extremely CPU intensive to do disk IO to the SD card from the Linux running on the ARM chip on it. Downloading to the SD (/mnt/sd), IO seems to be by far the limiting factor. Installing Slackware packages, which involves wget'ing the tgx archive and running installpkg on that, is slow and IO bound.
So, still a few things to sort out and some room for improvement, but still amazing. Getting Slackware running was more than I hoped for. That makes it feel like a real machine. My old server on a virtual machine at a hosting company is running Slackware 8. This is running Slackware 12. It would be handy if I could mail it to them and have them run it instead as had been joked about in the past with nanocolo.com and then done seriously with free Pi hosting.