Tuesday, March 23, 2010

Trashed NAND storage rebuilding

The great thing about OMAP processors is that they offer a huge number of functions on a single chip. The most advanced models include an ARM, a DSP, video and 3D accelerators, and a long list of connectivity options. The problem is that all of these features make OMAP a complicated chip. Building a system around such a complex chip is a major challenge. Hence, OMAP has historically been use for high-volume apps where the design effort could be justified.

Gumstix is changing the rules. Its modules include basic features like power supplies, memory (Ram and NAND Flash Rom), and WiFi/Bluetooth interfaces. These COM modules plug into expansion boards with I/O such as DVI and USB. (Gumstix offers four different COM [Computer on Module] base modules and five expansion boards, all of which are pin-compatible with each other.) If you are interested you can check out the complete Gumstix line here: Gumstix Website These modules take away a huge part of the basic engineering, letting you focus on the value-added work. One commonality among all the Gumstix COM modules is the amount and type of Ram and NAND Flash Rom on board. Since this is a common ‘trait’ of the COM board’s restoration of the NAND Flash Rom content is the same across the Overo line of COM computer modules.

Part of the process of performing value-added work involves developing software to take advantage of the different capabilities of the Omap processor. Once you have that bright, shiny new Overo COM board and expansion module you decide you want to do some "programming" and/or "installations" and proceed to go about re-programming the on-board 256-meg storage on the COM (computer on module). Why not? Installing software in the NAND Flash Rom makes sense as all of the system is contained within a very small footprint and it does not add anything to the power budget (requirements). Things are proceeding right along and the updates are occurring and you get to a critical update point when suddenly the power flickers! (No lie - had that exact thing happen to me!). Now the system is no longer responsive! What do you do???

When you try cycling the power no changes are noted and the computer does not do anything as the Overo computer just sits there with its unflinching power indicator lit and nothing else happening - other than your imagination taking hold and you are thinking you have a very small computer BRICK (in other words – non-responsive). In a panic now you decide to see if the computer will boot-up from that microSD card you set up with a bootable Overo image. Will it boot up as it did once before - yes it does! Well, at least you feel the hardware is working since it booted off the microSD card but it will not boot up from the internal NAND memory. Now what - you want to run the system from NAND and use the microSD card for removable storage - not for the operating system itself - or not use the microSD card slot at all to keep power requirements to the absolute minimum. Now the question you ask yourself is "How to 'restore' the NAND to a bootable state as it was from the factory - or at least some facsimile"?

Well - that is not such a hard problem to solve at all. The folks at Gumstix thought it best to make the system test and boot off the microSD card first in the boot up sequence to cover such contingencies. We can setup a microSD card to boot up the computer and use it to restore the contents in the on-board NAND memory for those cases where things go terribly wrong. If you read my previous posting (Overo Information Blog) on how to setup a bootable microSD card then you are already ahead of the game. If you did not I would suggest you do so as you will need to install a bootable system in a microSD card in order to restore the contents into the on-board NAND rom.

It is recommended that you use the linux mtd utilities to write images to NAND Rom. Microsoft Windows tools just seem to have issues with doing this sort of work and most of the tools will not allow performing some of the steps required to setup a microSD card for boot up in the Overo COM computers. If you don’t have a linux machine setup you can always download and install VMware’s Free Server software and build a linux system in VMware on your Windows machine.

The following steps are performed with the microSD card mounted to your Linux Overo development system machine. You can mount the microSD card either through a SD Card adaptor installed directly on your computer or use a USB to microSD adaptor.

Setup a bootable microSD card with an operating system image that boots up on the Overo COM board then follow the steps below to setup the system to restore the contents in the NAND rom on-board the COM.

Next, copy the image files you are going to restore to the NAND rom to the microSD card (say to /home/root/images). Create the following script in the same directory as you copied the image files. You may need to modify the script to reflect the names of your image files if they are not the default file names.

Make sure the script is marked as executable.

Unmount the microSD card from your development machine, insert it in the Overo microSD slot and apply power to boot up the machine.

Once your COM computer has booted up to the login prompt login and run the script you created earlier. You should see messages from the script as the NAND rom reloading process proceeds. If there is an error during the update process the script will print an error message to let you know what the error was. If there are no errors during the restoration process the script will inform you the restoration is complete.

Once you have successfully restored the NAND rom contents you should be able to shutdown the COM, remove the microSD card then apply power to reboot the COM back up again. Don't just remove power when the NAND rom updates are complete as that could corrupt the contents of your microSD card! You are running a Linux system so you don't want to just power down improperly...

----------------------------------- script ----------------------------------

# script to reload the NAND Flash rom with a bootable OS


# reload the boot loader

if [ -e $uboot ]; then
          echo "Erasing u-boot partition ..."
          flash_eraseall /dev/mtd1
          echo "Erasing u-boot environment partition ..."
          flash_eraseall /dev/mtd2
          echo "Writing u-boot to NAND ..."
          nandwrite -p /dev/mtd1 $uboot
          echo "u-boot image has been written to NAND ..."
          echo "ERROR: couldn't find u-boot binary"

# reload the kernel image

if [ -e $uimage ]; then
          echo "Erasing kernel partition ..."
          flash_eraseall /dev/mtd3
          echo "Writing kernel to NAND ..."
          nandwrite -p /dev/mtd3 $uimage
          echo " Kernel image has been written to NAND ..."
          echo "ERROR: couldn't find kernel binary"

# reload the root filesystem

if [ -e $rootfs ]; then
          umount /dev/mtdblock4
          echo "Erasing and formatting rootfs partition ..."
          flash_eraseall -j /dev/mtd4
          echo "Mounting rootfs partition ..."
          mkdir -p /media/mtdblock4
          mount -t jffs2 /dev/mtdblock4 /media/mtdblock4
          cd /media/mtdblock4
          tar xjf $dir/$rootfs
          echo "The rootfs has been written to the NAND ..."
          echo "The NAND restoration is complete ..."
          echo "ERROR: couldn't find rootfs tarball"

# end of script

---------------------------- End of Script --------------------------------

Keeping a bootable microSD card around with a restorable NAND image is not a bad idea. It is always good to have a method of restoring the NAND Rom content - especially if you do a bit of experimentation with the NAND rom content. It is always nice to be able to restore to a known configuration for experimentation. This concept also works if you decide to make changes and modifications to the original Overo BitBake / OpenEmbedded recipes for the omap-desktop-image as you can setup the image to a specific configuration then restore it if something gets trashed. Nice insurance to say the least.

This technique can also be used for major upgrades in the field - just pop in a microSD card with the new images and kernel and let it perform the update itself. You can even automate the update process by having the script start execution as final part of the boot up process to make it totally automatic for the installation process.

If you have ideas or want to leave me a message here.

A second item - I have listed several hardware sites where you can get really good pricing and I make a very small commission from the sale - I realize this seems tacky but I have to do something given the current financial hole I find myself in at the moment.

Third Item:  Here is a link to microSD and microSDHC cards that can be used with the Overo COM computers.  Click Here to Access MicroSD hardware

Thanks for understanding and a Special Thanks to those who help out!

If you would rather have a PDF e-Book on this subject you can find it here:

Overo COM NAND Flash Memory ROM Restoration

Sunday, March 21, 2010

Creating a bootable microSD card

In my mind one of the nicer features of the Overo COM computer is it will boot directly from a properly prepared microSD card.  The 'advantage' to having the Overo COM computer boot up from the microSD card first is you do not have to make any modifications to the onboard NAND image - if you trash the installed Operating System on the microSD card you can just remove the card and the Overo COM computer will bootup off the NAND rom code instead - I can think of several situations where this could be a handy feature!

The Overo boot rom sequence checks the microSD slot first to see if there is a device and if one is found it checks to see if there is a boot sector prior to checking the onboard NAND Rom.  If a boot sector is found on an installed microSD card the boot loader will attempt to load and execute the boot sector information.  In order to create a bootable microSD compatible with the OMAP3 boot ROM, you must set the geometry of the microSD card correctly otherwise the boot rom will not recognize the microSD card as a bootable device and pass control on to the code loaded in the NAND memory onboard the Overo COM.

The following instructions are performed on your development system - they are performed in a Linux environment and since your Overo development system is a Linux environment that seems like the logical machine to use (grin).  In order to configure the microSD card for the proper device geometry you use the fdisk "Expert mode".  The following instructions outline how to partition and format a bootable microSD card.

The following information describes the steps for setting up a brand new 2GB microSD card.  Since there are several different sizes of microSD cards I have included the instructions to setup the different sized cards.  The majority of the difference is in the calculation of the number of 'sectors' that you will need to enter when setting up the geometry of the microSD card.

One thing you will need is a flash card reader that is capable of working with microSD HC cards as well as microSD cards.  If the flash card reader cannot read (and write) to microSDHC cards then you will be limited to a maximum of 2-gig microSD card size (maximum size of microSD card - the HC specifications allow for up to 32-Gigs of storage).  If your machine has a SD Card slot check to see if the machine is capable of reading (and writing) to SDHC cards - if not obtain an external USB 2.0 card reader that does.  You will be much happier with the additional storage capacity of the SDHC cards.

Here is one type of microSD card reader that is USB 2.0 capable - it can be found here at Amazon.com - It is a great deal for the price!

Insert the microSD card into the development machine's flash card slot (or the external card reader). You may need to use a microSD to SD card adaptor to fit your slot.  On my Ubuntu 8.04 machine, the newly inserted card shows up as /dev/sdc and that is the device name that I will use for the following instructions. You will need to substitute the proper device name for your machine as I am sure our two machines are not configured the same (grin). You can use 'mount' or 'df' to see where the card mounts on your machine.  If you type 'mount' without anything else it will show you what is mounted where - df, which stands for 'disk files', shows you the information about the different partitions on your machine along with the device names and mount points.

Since your development system probably is configured to 'auto-mount' mountable devices and the microSD cards come formatted with Windows filesystems (seems to be the pervasive standard) the microSD card was most likely mounted to the filesystem automatically.  We do NOT need the card to be mounted at this time as we need to change the storage geometry of the card.  Let's unmount the device's existing file system before we get started with fdisk (type the command listed in blue then press ENTER):

 sudo umount /dev/sdc1

NOTE: Substitute the device name for your microSD card in place of the 'sdc1' listed above.

Partitioning the card

To perform the partitioning steps we need to launch the fdisk application and create an empty partition table on the microSD card. Note that the argument for fdisk is the entire device (/dev/sdc) not just a single partition (i.e. /dev/sdc1):
 sudo fdisk /dev/sdc      <--- be sure to specify your device for the microSD card here

Command (m for help): o

Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Let's first look at the current card information:

Command (m for help): p

Disk /dev/sdc: 2032 MB, 2032664576 bytes
64 heads, 63 sectors/track, 984 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Disk identifier: 0x00aa8e5c
Device Boot Start End Blocks Id System

Note the card size in bytes - I have it listed in RED above but it displays the same as the rest of the information on your development system. Write the information down as we will need it later in the process.  This is also one of the differences I mentioned earlier for creating bootable microSDHC cards.

Now go into fdisk "Expert" mode:

Command (m for help): x

Next we will set the geometry to 255 heads, 63 sectors and a calculated value for the number of cylinders required for the particular microSD card.  The 'calculated number of cylinders' is the difference for the different sized cards and is calculated the same across microSD cards.

There are a couple of methods we can use to calculate the number of cylinders for a specific microSD card:

1.  We can do it the hard way - To calculate the number of cylinders, we take the 2032664576 bytes reported above by fdisk divided by 255 heads, 63 sectors and 512 bytes per sector:
2032664576 / 255 / 63 / 512 = 247.12 which we round down to 247 cylinders.


2.  The easy way - divide the size in bytes by 8225280 (which is 255 * 63 * 512) to get the number of whole cylinders (drop the fractional part which is also done in the "hard way" method).
2032664576 / 8225280 = 247.12, drop the fractional part to yield 247 cylinders.

Personally - I prefer the easy way myself!

Now that we have the number of cylinders we need for the specific geometry we are setting up on the microSD card we can proceed to do precisely that:

Expert command (m for help): h

Number of heads (1-256, default 4): 255

Expert command (m for help): s

Number of sectors (1-63, default 62): 63

Warning: setting sector offset for DOS compatiblity

Expert command (m for help): c

Number of cylinders (1-1048576, default 984): 247  <--- our calculated cylinder count

At this point we have configured the settings for the geometry of the microSD card and are finished with the 'expert' mode in fdisk - we need to return to the main mode to finish up the configuration of our microSD card and create a new 32 MB FAT partition to allow the Overo COM boot rom to recognize our boot partition:

Expert command (m for help): r

Command (m for help): n

Command action
e extended
p primary partition (1-4)


Partition number (1-4): 1

First cylinder (1-247, default 1): 1

Last cylinder or +size or +sizeM or +sizeK (1-247, default 15): +32M

Change the partition type to FAT32:

Command (m for help): t

Selected partition 1

Hex code (type L to list codes): c

Changed system type of partition 1 to c (W95 FAT32 (LBA))

And mark it bootable:

Command (m for help): a

Partition number (1-4): 1

Next we create an ext3 partition for the rootfs - the 'boot' partition we created is just to allow boot-up of the system - the next partition is where our operating system and filesystem will live:

Command (m for help): n
Command action
e extended
p primary partition (1-4)

Partition number (1-4): 2

First cylinder (6-247, default 6): 6

Last cylinder or +size or +sizeM or +sizeK (6-247, default 247): 247

To verify our work, let's print the partition info:

Command (m for help): p

Disk /dev/sdc: 2032 MB, 2032664576 bytes

255 heads, 63 sectors/track, 247 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x00aa8e5c

Device       Boot     Start     End       Blocks       Id         System

/dev/sdc1     *           1         5        40131        c         W95 FAT32 (LBA)
/dev/sdc2                 6      247    1943865       83         Linux

Up to this point no changes have been made to the card itself - all of the changes exist in the partition table located in memory, so our final step is to write the new partition table to the card and then exit:

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional

Syncing disks.

At this point we have exited the fdisk program after it altered the partition table of the microSD card.  We still have some things to do to the microSD card before we can use it with the Overo COM machines...

Formatting the new partitions

As you recall - we created two distinct partitions on the microSD card after we changed its geometry - one partition was a FAT-32 partition of about 23-megs in size and the second partition was a Linux ext3 partition comprised of the rest of the remaining microSD card storage space.

We format the first partition as a FAT file system (the -n parameter gives it a label of FAT, you can change or omit this if you like):

 sudo mkfs.vfat -F 32 /dev/sdc1 -n FAT

mkfs.vfat 2.11 (12 Mar 2005)

NOTE:  If you run into the issue where your development system does not recognize the mkfs.vfat command you need to install the mkfs.vfat application.  Some Linux versions do not install the DOS format program normally as part of their installations.

We format the second partition as an ext3 file system:

 sudo mkfs.ext3 /dev/sdc2

mke2fs 1.40.8 (13-Mar-2008)

Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
121920 inodes, 485966 blocks

24298 blocks (5.00%) reserved for the super user

First data block=0
Maximum filesystem blocks=499122176
15 block groups
32768 blocks per group, 32768 fragments per group
8128 inodes per group

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Writing inode tables: done

Creating journal (8192 blocks): done

Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

At this point in the process we now have a microSD card with the proper storage geometry and properly formatted partitions.  Our next objective is to load a bootable operating system on the microSD card.

Installing the boot files

There are three files required on the first (FAT) partition to boot your Overo:

1.  MLO :

The boot-loader loader - this small program is loaded into the OMAP3 processor's static RAM.  It does some minimal configuration of system memory and io pins and then loads the second file.

2.  u-boot.bin :

The boot loader - This low-level application performs so housekeeping and loads the Linux kernel, then transfers control to the Linux kernel.  Probably would be considered the 'grub' of the Overo system.

3.  uImage:

The linux kernel - the actual kernel that will control the operating system operations.

You can build these components of the boot partition yourself or download pre-built images.  The uImage kernel is the one created during the Bitbake/Openembedded build process so would need to be loaded into the boot partition so it matches the rootfs installed in the second partition.  Failure to do this can (and usually does) result in different types of runtime issues from wrong kernel drivers (modules) all the way to kernel panics.  One advantage of building the different components yourself is you know what exactly is in them - if you actually study the source code that is (grin)...  Since the MLO initially configures the Omap processor pin configurations you will NEED to build this file if you need to change the default configurations.

It is very important that these three files have precisely these names and are loaded into the boot partition in a very specific order.  The Overo boot loader does not use the names per-se but instead loads the FIRST installed file on the boot partition (MLO) which does look for specific name 'u-boot.bin' when it is time to load the boot loader.  The boot loader also looks for the specific name uImage to load the Linux kernel.

Given the above information it becomes apparent why the names of the file must match and also the sequence used to load the specific files into the bootable partition on the microSD card.

It is beyond the scope of this posting on "how" to create the above listed files - this is an exercise left up to you (and a later posting - grin).   Once you have completed building or downloading these files, mount the FAT partition of your microSD card. This example will assume that you have mounted it at /media/card:

NOTE: If there is not a /media/card mount-point you will need to create it using the following command:

sudo  mkdir  -p   /media/card

Now mount the microSD card filesystem to the development system's filesystem:
sudo  mount  /dev/sdc1  /media/card  <--- remember to use your device specification here
Due to constraints of the mask boot ROM in the OMAP processor, MLO MUST be written first:
({directory-path} is the directory path to where the MLO-overo file is located on your system)

sudo  cp  {directory-path}/MLO-overo  /media/card/MLO

Then copy u-boot and the linux kernel to the card:
(The order of the copy commands is not important here - just that MLO was copied to the boot partition FIRST)
sudo  cp  {directory-path}/u-boot-overo.bin   /media/card/u-boot.bin

sudo  cp  {directory-path}/uImage-overo.bin   /media/card/uImage

We are done with the construction of the boot partition on the microSD card so you can now unmount the FAT partition:

sudo umount /dev/sdc1

At this point you have a bootable FAT partition.  Pat yourself on the back - grab a beer (if of legal age!) and enjoy!!!  You have accomplished something here today!

We still have one final task to complete in order to have a full-fledged bootable operating system on the microSD card - The final step is to untar your desired rootfs onto the ext3 partition that you created above.  It is outside the scope of these instructions - the rootfs file referenced here is created as part of the build process performed by the Bitbake/Openembedded development system for the Overo COM.  You can download pre-compiled versions from the Overo Development site or create your own using the Bitbake/Openembedded development system.

Note that this step can be dangerous. You do not want to untar your Overo rootfs onto your development machine - be careful!

This example will assume that you have mounted it at /media/card - following step performs this task:

sudo mount /dev/sdc /media/card

Now untar your desired rootfs - very important, you want to be in the partition on the microSD card to perform the untar operation!  Perform the following step!

cd /media/card

VERY IMPORTANT - Be sure to list the full path to the rootfs file in the following instruction...
sudo tar -xvjf   /path/to/omap3-console-image-overo.tar.bz2

Once the system has finished installation of the root filesystem on the second partition of the microSD card you can check it out using the ls command to see the content.  You can also use the df command to see how much of the second partition is used and how much free space there in the microSD card.  Once you are satisfied things look correct you can unmount the microSD second ext3 partition from your development system:

sudo umount /dev/sdc2

Congratulations!!!!!  You have reached that thrilling moment of truth!

You are now the proud owner of a microSD card with a bootable Overo operating system in it. 

If you have done everything correctly and you have a viable MLO, u-boot.bin, uImage and rootfs system installed on the microSD card and the uImage and rootfs cross-compiled correctly (a lot of if's I know!) you should be able to boot up the Overo from the microSD card simply by inserting the microSD card into the Overo microSD card socket and applying power to the Overo COM machine.  Watch the information displayed from the console output of the Overo during bootup to verify it is indeed booting from the microSD card.

Let me know how it goes for you!  Good, bad or indifferent I want to hear from you!!!

A couple of notable items:

1.  You want to use microSD cards that are rated as Class-6 cards.  There are several Class ratings and the lower numbers are slower microSD cards.

2.  You get what you pay for in microSD Cards - if you use a cheap card then you most likely will have issues later - I did not say inexpensive cards as there are some good inexpensive cards out there - I am referring to "cheap" inferior cards that use old flash rom technologies.

3.  If there is an interest I will build pre-configured microSD Cards for a small fee - you supply the cards and I will reset the geometries and perform the partitioning and formatting operations - let me know if this is something of interest to my readers (grin).  For an additional small fee I will load the cards as well with the boot partition and root filesystem.  Contact me here if interested (leave me a comment)...

A second item - I have listed several hardware sites where you can get really good pricing and I make a very small commission from the sale - I realize this seems tacky but I have to do something given the current financial hole I find myself in at the moment.  

Thanks for understanding and a Special Thanks to those who help out!

Time to a Build...

Having been away for a while I decided I needed to just "start over" with the development system.  Since it has been over a year since I have used my development system I figured there 'may' have been some changes and upgrades done to the original bitbake/openembedded development environment and with the actual applications for the Gumstix line.

After configuring a new virtial machine (VMWare) and loading Ubuntu 8.04 Desktop I followed the instructions on the Gumstix WiKi (web link below) to install the bitbake/openembedded development system.  I use VMWare's free server package to allow me to run several different virtual machines on my development home computer.  If I did not use my machine in this fashion it would be a waste of resources (and I can do other things) while the Gumstix development system is performing long cross-compile operations - they can run as long as 18 - 24 hours at times.  I use the Linux Ubuntu 8.04 workstation (also free) as the core development system environment as that is the OS I am comfortable with - others use newer versions of Ubuntu along with other different versions of Linux (Debian, Centos, etc.) and have good success - I just like the Ubuntu 8.04 release and since the compile operations for the Gumstix is performed in a cross-compiler environment running Ubuntu 8.04 has minimal effect on the compiled output.  A Note:  Make sure you have all the tools or equivelent tools installed on your version/flavor of Linux to allow the Bitbake/Openembedded developement system to perform it's job otherwise you will get some errors during a build - sometimes very difficult to debug.

Speaking of installed tools - A couple of items I ran into during the installation and testing of the cross-compiling bitbake/openembedded environment - just some things to watch out for...  The list of additional items needed on the WiKi page left out the 'gettext' application - this is needed for some parts of the tools compilation process near the beginning of the environment build in performing the omap-console-build process.  It seems to me this was forgotten over a year ago - I guess they have some issues keeping track of the little problems but given the complexity of the environment it is understandable.

You can find the environment installation instructions here:  Setting Up a Gumstix Overo Build Environment   To install the 'missing' application just add 'gettext' to the list used for the apt-get installation for Ubuntu otherwise whatever your Linux version requires.  One nice feature of the Bitbake/Openembedded development system is the system will give you fairly accurate error messages so you should be able to determine if there are any tools missing that are required by the development system.

Once I had the development system setup and configured by the instructions listed above I built the omap-console-image package as instructed.  The installation (download of source code, dependency resolution and compiling of the required tools) of the cross-compiler toolsets was performed by the Bitbake/Openembedded system and the omap-console-image package was created as expected.  I have done this several times so know when it works and when it does not.  Only took about 16 hours or so to perform this 'initial' build due to all the tools needing to be compiled the first time through.  If you think you don't need to perform all of the steps in the setting up of the development environment you really do.  The last couple of steps (compiling the omap-console-image) actually installs the bulk of the specific tools you need on your version of Linux as they are tuned to your version.

Now the development system has performed the initial installation of all the software tools needed to build a console version of the Gumstix operating system (actually a version of Debian Linux) I performed the build of the 'omap-desktop-image'.  This image is the GUI version of the console image so uses the console image built components and additionally builds (cross-compiles) the Graphica Interface and a list of applications to install in the image.  Performing this build gets the GUI components compiled for the Gumstix so the next time they are needed they have already gone through the cross-compile process which saves considerable time when you make changes to the installed applications in an image.

Thank you!

Sunday, March 14, 2010

Space to play in

Sorry for no postings in the last 6 - 7 months.  I have changed jobs and have been working in a vertical learning curve for the moment.  I now work in the Information Security realm and it is very interesting where Information Security has gone to in the last three or so years - more 'compliance' than 'security' - I guess the suits are looking for ways to 'understand' the concepts (grin) and feel warm fuzzies so they can sleep at night (I know better so I don't!).  As a distraction, hopefully I can now do some more postings and work with the Gumstix that will be of interest to others.  I may even be able to work the Gumstix into a security roll - who knows.

About a year ago I posted information on the use of a MicroSD card to increase the usable storage in a Gumstix system. At that point in time the largest, reasonably priced, microSD card was 8-gigs. Today you can find 16-Gig MicroSD HC (High Capacity) cards at less cost than the 8-Gig MicroSD HC cards of a year ago.  A search on Google for 'microsd card' yields around 4,990,000 hits on the subject.  Most of the median priced MicroSD HC cards of today boost Class-6 (6-MB/sec) data transfer rates.  This is three times faster than the older Class-2 devices.  If your applications run mainly in RAM memory the actual speed of the MicroSD card will only play a part when loading applications or data - in this environment you really don't need the Class-6 devices if cost is the main concern otherwise So what does this have to do with Gumstix computers?  Plenty!  If you are planning to build a Gumstix machine and need more than embedded basic functionality you will need more storage space.  A couple of ways to get more space is to either connected additional external storage through one of the USB ports or to insert a MicroSD card into the Gumstix COM MicroSD receptacle on the board.  Unless you need more than 16-Gigs of storage capacity the MicroSD card method is the better of the two - less hardware and much lower power requirements.  If you need more space then I would suggest a SATA (Serial ATA) solid-state drive, 32-Gigs to 64-Gigs MLC drives are reasonably priced but slower than SLC based drives, with a USB to SATA adaptor.  Of course you will need a USB hub that supplies power as the Gumstix COM does not have enough power capacity on it's USB ports to handle the power needed.

Some microSD cards that work well with the Overo COM computers:

Note - I think these are Class-2 Devices so will read and write at 2-megabytes per second.  Given the cost that is not bad at all.

On a different note - I know this sounds really lame but if you don't mind would you please click on one or two of the ad's liste here???  It does not cost anything to you and it may help offset the cost of hardware to continue working with the Gumstix machines.

 Thank you!