Thank you for this information.  I'm going through the procedures on getting a CF-based system built and running.  To get educated, I got the pre-build initramfs_boot(_ext3) and rootfs(_ext3) and put the unzipped contents on the (FAT-formatted) CF card and tried in u-boot:

GUM> fatload ide0 0 a2000000 gumstix-factory.script                            
** Unable to use ide0 0:1 for fatload **                                       

The CF card has gumstix-factory.script, ramdisk.img, uImage-1.6.17-initrd and rootfs.img.

Is there something else I need to do to get this going?  I'm using:

GUM> version                                                                   
U-Boot 1.1.4 (Aug  1 2006 - 10:47:14)                                          
*** Welcome to Gumstix ***                                                     

Thanks for help.

On 8/2/07, Brad House < brad@mainstreetsoftworks.com> wrote:
Well, I'm not sure, but I think U-Boot can only access a
fat partition on a CF card.  But that's not bad, as you're
typically going to have just 3 files on there, your uImage (kernel),
your ramdisk.img (initramfs/initrd) which will in turn load your
rootfs.img (which is an ext2/3 loop file).

I've never tried to _write_ to a CF card from u-boot, I've only
read from it.  You shouldn't need to anyhow though, as long as you
have a Linux loaded, you can simply mount the CF card and rename
(or delete) the current uImage/ramdisk.img/rootfs.img files on
your CF, and write the new data into files of the same name, then
reboot.  As long as you have enough empty space on your CF device
to hold your current data as well as the new data, you should be
fine (since the space won't actually be free'd from the old FS
until you reboot, because that inode will still be referenced).
The rootfs.img file itself will be whatever size you pre-define,
and when not full, it compresses very nicely.  Personally,
I make my rootfs mount read-only, and store user-generated data
in it's own loop file.

Worst case scenario, if you screw something up, you can just
take out the CF card, pop it in your Linux workstation, and
copy over working images...

I updated this page a few days ago to be more relevant to
the current way things work with CF cards:


Peter Lu wrote:
> Hi, Brad,
> You mention that you boot off the external CF card.  I'm currently using
> the on-board 16MB Flash for my rootfs, but am reaching its brim.  I
> would like to be able to use the large (512MB) CF for my rootfs, or at
> least some of it, if possible.  Do you have any suggestions as how I
> could do this, and are there any detriment in doing things this way?
> Linux has chroot, but I don't know how useful it would be here.
> I'm currently only using the CF as an extra ext2 FS for user data.
> While the on-board Flash can be written by Uboot, could the CF?
> Presumably, I could even split up the CF into multiple filesystems to
> allow multiple boot capabilities.
> Note that my CF card will be internal to the box, and hence not easily
> removable for external programming.
> Thanks for help.

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
gumstix-users mailing list