Showing posts with label BSD. Show all posts
Showing posts with label BSD. Show all posts

Tuesday, March 26, 2013

Using Synchrotech's X4SD USB 2.0 SD Card Reader Four (4) Slot for SD Card duplication

X4SD USB 2.0 SD Card Reader Four SlotSynchrotech's X4SD USB 2.0 SD Card Reader allows simultaneous access to four SD Card style media. In Automating X4SD USB 2.0 SD Card Reader Four (4) Slot Operations Synchrotech outlines several techniques for automating the copying of files to the device's multiple slots. Here we explore making exact binary copies of media using the device. A common use of this process is duplication.

There's various ways to do do device duplication or byte-for-byte copies of media. Whether we're duplicating CD-ROMs, hard drive disks, SRAM PC Cards, or other removable media, the Unix dd is frequently preferred for these types of operations. While we can execute card to card duplications from one X4SD slot to another, the most common use for the reader is to write an existing SD Card image to all four slots simultaneously. To that end we'll create a binary image of a master SD Card and then use that master to write to blank cards.

Creating an image of the SD Card

dd works with block devices, so we need to unmount the SD Card. To make this simple, we'll be using just one of the X4SD slots at this stage. We'll be using Mac OS X for our example and detail the difference for OpenBSD and Xubuntu. First, we need to identify the mount point of the inserted card. Calling mount in the terminal shows us the information we need (we're leaving out the rest of the output here).

/dev/disk1s1 on /Volumes/NO NAME (local, nodev, nosuid)

We use that information to unmount the mounted device.

[kyoto:~/Desktop] rds% sudo diskutil unmount /Volumes/NO\ NAME
Volume /Volumes/NO NAME unmounted

OpenBSD and Xubuntu would use umount /[devicepath]. Using the block device reference to the X4SD slot, we can copy the card to a binary file using dd.

[kyoto:~/Desktop] rds% sudo dd if=/dev/disk1s1 of=sdcard.bin
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)

Writing the image to SD Cards

Inserting a new card into the X4SD, then unmounting it, we can create a duplicate of the original. We then test it using cmp to see if it is identical to the binary file.

[kyoto:~/Desktop] rds% sudo dd if=sdcard.bin of=/dev/disk1s1
1951677+0 records in
1951677+0 records out
999258624 bytes transferred in 1203.276878 secs (830448 bytes/sec)
[kyoto:~/Desktop] rds% cmp /dev/disk1s1 ~/Desktop/sdcard.bin
[kyoto:~/Desktop] rds% 

Here we write to all four slots simultaneously on a Xubuntu machine. It's feasible that using hubs and multiple X4SD, we could write to more than four cards at once on a machine with enough CPUs/CPU cores. However, there's a practical limit to the amount of I/O operations one would want to run at the same time. Perhaps writing to each bank of cards sequentially would be the best practice? Since I was only provided a single test unit, that remains an academic question.

rds@okinawa-lin2:~$ sudo dd if=sdcard.bin of=/dev/sdc1 & \
&& dd if=sdcard.bin of=/dev/sdd1 & \
&& dd if=sdcard.bin of=/dev/sde1 & \
&& dd if=sdcard.bin of=/dev/sdf1 &

1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 270.799 s, 3.7 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 423.987 s, 2.4 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 775.1 s, 1.3 MB/s
1951677+0 records in
1951677+0 records out
999258624 bytes (999 MB) copied, 860.479 s, 1.2 MB/s

Appendices

Determining Media Paths

Here's the abridged results of running mount on our various test systems with the X4SD plugged in and all four of its slot occupied. This output will look different based on what's connected to an individual system.

OpenBSD
sd0i on /mnt/s1 type msdos (local)
sd1i on /mnt/s2 type msdos (local)
sd2i on /mnt/s3 type msdos (local)
sd3i on /mnt/s4 type msdos (local)

Xubuntu Linux
/dev/sdd1 on /media/BF2C-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdf1 on /media/02A3-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sde1 on /media/3A3A-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
/dev/sdc1 on /media/5AED-1214 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)

Mac OS X
/dev/disk2s1 on /Volumes/NO NAME 3 (local, nodev, nosuid)
/dev/disk4s1 on /Volumes/NO NAME 2 (local, nodev, nosuid)
/dev/disk3s1 on /Volumes/NO NAME (local, nodev, nosuid)
/dev/disk1s1 on /Volumes/NO NAME 1 (local, nodev, nosuid)

My Test Systems

Here's the results of running uname -a on our various test systems.

OpenBSD okinawa-bsd2.my.domain 5.1 GENERIC.MP#207 amd64
Linux okinawa-lin2 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
Darwin kyoto 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

Code example disclaimer

Technology Musings grants you a nonexclusive copyright license to use all programming code examples from which you can generate similar function tailored to your own specific needs.

All sample code is provided by Technology Musings for illustrative purposes only. These examples have not been thoroughly tested under all conditions. Technology Musings, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.

All programs contained herein are provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.

Sunday, March 20, 2011

Instructions for Unix-like Systems with Elan's U111-M SRAM and ATA Flash PCMCIA PC Card Drive

U111-M USB to PCMCIA PC Card ATA Flash and SRAM
EverythingHerePlus.com recently announced a first draft of a document which outlines the use of the BSD and Linux compatible USB reader for PCMCIA PC Card SRAM and ATA Flash memory devices. While the draft isn't complete, experienced users will have no problems using the command line instructions to complete tasks. They tested the device with OpenBSD and Xubuntu Linux.

Elan's U111-M PCMCIA PC Card reader for SRAM and ATA Flash memory devices is unique in that the reader itself brokers all the interfacing with the PC Card and presents itself to the host computer as a USB mass storage device. In addition to working on The Windows platforms, the device works with various versions of BSDs and Linux. Because of this, the U111-M allows users of Unix-like platforms to perform actions on these cards using common command line tools that usually require specialized and expensive software for The Windows. EverythingHerePlus hopes the document will be helpful to those wanting to deploy the U111-M with Unix-like systems.

Table of Contents
Introduction
Operating Systems uname -a results
Plugging in PC Card SRAM or ATA Flash
PC Card Partition Information
Mounting PC Card SRAM or ATA Flash
Unmount PC Card SRAM or ATA Flash
Formatting/Erasing PC Card SRAM or ATA Flash
Binary Image File to PC Card SRAM or ATA Flash
Binary Notes
Comparing Binary to PC Card SRAM
Manual Checksums Binary vs. PC Card SRAM or ATA Flash
View Hexadecimal of PC Card Memory Area (or Binary File Copies)

Thursday, November 4, 2010

Samba changes in OpenBSD

The other day when I was trying to mount an ISO image for remote burning of SmartCard reader driver discs on our work network, I was getting error messages when trying to log on via samba. Since I usually use NFS instead of samba, I hadn't noticed that OpenBSD had changed the password back-end for samba. This was with 4.8-current, although they might have changed things earlier without me noticing. In fact, it may well have been a samba change rather than an OpenBSD specific one.

Regardless, the new configuration isn't any harder than the previous incarnation, just different. Took all of one minute to get things working again.

See

/usr/local/share/doc/samba/README.OpenBSD

for full details

Monday, October 6, 2008

Getting Gambit to respect prefix settings at configure

After posting a concern about Gambit inserting an additional "version" directory into the installation path, the following was suggested on the Gambit mailing list and works perfectly. When executing make install set the PACKAGE_SUBDIR="" to remove the version number from the installation path.

For me the configure, make, install routine works as follows:

$ ./configure --enable-single-host --enable-gcc-opts --prefix=/Users/Shared
$ make install prefix=/usr/local PACKAGE_SUBDIR=""

This places the Gambit files in the directories I expect them to be in.