[Saulius Lukse] has been working on some single board computer, seemingly, running Linux. Naturally, that boots from a microSD card – and as development goes on, that card has to be reimaged all the time. Sick of constantly plugging and unplugging the microSD card between the SBC and an SD card reader, [Saulius] started looking for a more automated solution – and it wasn’t long before he found out about the SDWire project, a hardware tool that lets you swap a card between a DUT (Device Under Test) and your personal computer with no moving parts involved.
SDWire is an offshoot from the Tizen project, evidently, designed to be of help in device development, be it single-board computers or smartphones. The idea is simple – you plug your MicroSD card into the SDWire board, plug the SDWire into a MicroSD slot of your embedded device, and then connect a USB cable from the SDWire to your development computer. This way, if you need to reflash the firmware on the SBC you’re tinkering with, you only need to issue a command to the SDWire board over the USB cable, and the MicroSD card appears as a storage drive on your computer. SDWire is a fully open source project, both in hardware and in software, and you can also buy preassembled boards online.
Such shortening of development time helps in things like automated testing, but it also speeds your development up quite a bit, saving you time between iterations, freeing you from all the tiny SD card fiddling, and letting you have more fun as you hack. There’s a clear need for a project like SDWire, as we’ve already seen a hacker assemble such a device using breakouts.
If you got a linux based SBC and network connectivity you can also boot from nfs. That may be even simpler.
The problem is that most SBCs can NOT boot over the network. Even if they can, they couldn’t at one point. The firmware needed to be developed, tested and iterated on.
It works fine only if you only test kernel and system image but if you want test bootloader and whole image it is better do this way. Anyway whole set of tools(SamsungSLAV) was develop for using with Sdwire and MuxPi and it was better than LAVA 1.
That’s an option. U-boot can do this, but swapping full SD (or NAND/NOR flash in other cases) card is more flexible.
One of the advantages of Linux development is that you can shell into the device and update only the things that need updating. Building the whole image each time sounds painful.
But for automated testing this looks pretty nice. Running through a batch of older releases, applying new tests.
well, you could indeed only reflash the bootloader parts, for instance. You have the SD card mounted on your computer, you choose how much you need to update!
It depends. It’s quite common to use SquashFS in embedded applications. It keeps the required memory down by being compressed but is read only.
Interesting stuff, might be handy one day but as usual for this small production run stuff the assembled product is quite expensive. However it’s open source, for anybody curious, they are using a TS3A27518EPWR for the actual switching. If i need something like this one day i would probably make a simpler version with just the switch, some stuff for switching power to the card, a physical switch (*) and a ready-made card-reader.
This remainds me about some hacking i did where i needed a way for a serial FLASH to be switched between a programmer and the DUH (device under hacking :) ). I ordered some analog switch but if was some kind of tiny, tiny QFN package and i had to solder it using “dead bug” technique, this was not fun… But it worked finally.
(*) One could also abuse some control line of an USB to serial adapter to switch between DUT/Programmer. Or even the actual TXD with some logic/flipflop/… to switch if there is any data sent by the PC. It’s a hack but it should work.
Talking about emulation of an SD card, i vagely remember this: https://github.com/scanlime/flipsyfat
>FPGA-based emulator to assist with guessing bootloader SD card filenames
Maybe somebody will find this handy as a starting point? I don’t know about the speed however, that’s probably the most difficult thing if you want to emulate an SD-card (and the fact that iirc the specifications are not completly open…).
Can you eliminate the micro SD entirely?
Have a directory on your PC act as a virtual card, and give access via USB cable and interface board?
Different application, but that’s essentialy what this does:
https://fiber-punk.com/
Thank you for sharing. Missed this gadget.
Is it? Does fiber node provide usb-storage capability for the card and ability to remotely (preferably via usb, too) switch physical sd card between external device and usb-storage?
I imagine that that would be possible with the Glasgow Scots Army Knife, or other similar FPGA-based device. Implement the SDIO protocol in an applet, translate reads and writes to USB messages. Problem is that performance will likely suffer due to the additional latency involved. If you are not dealing with large amounts of data, e.g. for developing uBoot or booting a kernel+initrd, that’s probably not a big deal.
If you are talking about complete OS images, it probably does start to hurt a bit. But then again, the amount of actual data read is probably fairly limited, and the tradeoff between raw performance, and the convenience and speed of each iteration would probably make it worth while.
SD cards are a bad storage medium for embedded applications, because sudden loss of power can brick the card.
That’s a very broad and serious claim to make. Are you talking about read-only boot positions going bad just because power was interrupted? Or are you talking about the cheap bargain-bin SD cards with limited write cycles for cameras/phones that inexperienced makers use in Raspberry Pie, and then complain when the SD goes bad after installing a write-heavy database backed application like Home Assistant? Please clarify.
MicroSD cards generally don’t have load balancing and don’t support TRIM (only a few select ones do), so repeatedly writing to the same location will brick them in short order even if they’re from a reputable brand. Running a full OS with default logging, swap and stuff from one, is enough to seal the deal.
We have been developing similar device https://github.com/armbian/mpads
i hate sd card
please make normal USB A host for booting, normal flash usb disc
(and second question, how long this device work on one charge? for example 2*18650 a week, a month?)
Could this device be used in a trail camera to turn it into a streaming device? I’m imagining Trail Cam –> sdwire –> long usb cable –> laptop.