Gumstix Verdex and USB flash

This article details the (fairly simple) process of connecting and using a USB flash drive with a Gumstix Verdex device. The Verdex already supports being a USB host, so the main work is in making the physical connection itself.

Hardware

The connection can be made by the use of a standard “A” to “mini-B” connector of the type which are often supplied with phones, cameras and many other small gadgets for data transfer or charging. The mini-B end of the connector is to be plugged into the Verdex via the expansion board, while the A end (the larger end that would normally plug into a PC or charger block) is plugged into a gender changer and then the USB flash drive into that. This is shown below. Power will be supplied to the flash drive (on most expansion boards) directly from the main supply via a regulator, not under the direct control of the Verdex itself.

Drive recognition and mounting

Once the physical connection has been made, the Verdex should automatically detect and mount the flash drive into the filesystem. This is assuming you are using a relatively modern build of OpenEmbedded, otherwise you may have to enable or modprobe some additional modules. See the troubleshooting section to get some ideas on which ones. The device (on our build of OpenEmbedded at least) gets mounted at /media/hdd automatically and can then be used as you would any other mass-storage device.

Usage tips

When writing to files on the flash drive on a battery-powered node (especially if there are environmental factors potentially causing additional reliability issues), it is important to ensure that data has actually been written to the drive. There is a level of buffering involved which may mean that in the case of the node losing power or crashing, the last few bytes of data may not yet have been written. To work around this, you should flush your output buffers after writing anything. Note though that this may cause higher battery drain and/or more frequent writes to the flash drive (reducing its potential lifespan). In Python this can be done as

outfile.write(data)
outfile.flush()

A reasonable trade-off may be to do this after a group of writes rather than each individual write.

Troubleshooting

While working on allowing automated logging of much larger amounts of data in my system, I had a problem getting a Gumstix Verdex board running OpenEmbedded to mount a USB flash drive. The Verdex boards have USB host capability (made available via an Audiostix2 board), and the one I was using was recognising the flash drive when it was plugged. It was in fact doing everything needed up to the point of actually mounting the drive into the filesystem. My dmesg output was:

<6>usb 1-2: new full speed USB device using pxa27x-ohci and address 2
<6>usb 1-2: configuration #1 chosen from 1 choice
<5>SCSI subsystem initialized
<6>Initializing USB Mass Storage driver…
<6>scsi0 : SCSI emulation for USB Mass Storage devices
<6>usbcore: registered new interface driver usb-storage
<6>USB Mass Storage support registered.
<7>usb-storage: device found at 2
<7>usb-storage: waiting for device to settle before scanning
<5>scsi 0:0:0:0: Direct-Access CBM Flash Disk 5.00 PQ: 0 ANSI: 2
<7>usb-storage: device scan complete

And that was all that happened. Web knowledge said “it just works” (as long as you tweak your kernel build, depending on the OpenEmbedded revision in use), which obviously it didn’t. The relevant modules being loaded were usb_storage, scsi_mod, ohci_hcd, and usbcore.

Eventually I did the magic correct search and came across this, which points out that the sd_mod module also needs to be loaded. I duly probed my mod and voila:

<5>SCSI device sda: 2068992 512-byte hdwr sectors (1059 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 0b 00 00 08
<3>sda: assuming drive cache: write through
<5>SCSI device sda: 2068992 512-byte hdwr sectors (1059 MB)
<5>sda: Write Protect is off
<7>sda: Mode Sense: 0b 00 00 08
<3>sda: assuming drive cache: write through
<6> sda: sda1
<5>sd 0:0:0:0: Attached scsi removable disk sda

I also got some errors reading the filesystem:

<3>FAT: invalid media value (0x06)
<6>VFS: Can’t find a valid FAT filesystem on dev sda.

But on mounting, it was perfectly valid.

I was intended to detail how to get this all to happen automatically, but on a new out-of-the-box Verdex (or as new as they got before being discontinued), it seems it works as it should. It is possibly a problem with the images we have created, and this post is then not useful for 99% of you in that case. However it has happened to me and at least one other person (and the solution provider knew what to do, so possibly more people also). In summary: YMMV.