Thanks for the guide!  This makes it a lot easier.

I have a couple of applications that I don't have the source to but are arm compiled as well, this may make it easier to get those running, due to the same reasons you mentioned in your other thread (inability to places files in place).

That's cool, now I can create a few extra mount points that can link to the USB disk.

Great work,  and another reason why Chumby's model is so great.

Assuming you don't overwrite the safe mode partition as well, you should be able to restore the primary partition using a standard USB firmware update.

You are free to distribute modified versions of the primary partition as long as you do *not* include the Flash Player executable (chumbyflashplayer.x)  - that binary is not licensed for redistribution, either by us or Adobe.  You will also be responsible for complying with the terms of the licenses of any software included in the distribution, including availability of source code, etc. Under the GPL, for instance, you must pass on the "written offer" (included in our manual), and any commercial distribution requires you to provide source directly, not simply pointing at our upstream repository.

Obviously, Chumby Industries will not provide any support for devices running modified firmware.

Can somebody from Chumby make it easy on us lazy people and tell us how big the cramfs filesystem can be?  Also, this information should be put on the wiki.  If I get some more information (and time), I will post it (including Duane's disclaimer on licensing).

UPDATE: (I hate threads where I talk to myself)

It appears I needed to offset the first 0x4000 of my dump in dd.  I'm not sure why.  It appears that there is approximately 6 Mb of space NOT used by Chumby that is still available in this area of flash.  I'm sure they'll be using it up over time, but for now that's about how much room we can play with.

My operations:

chumby:~# dd if=/dev/mtdblock5 of=/mnt/usb/mtdblock5-data skip=32 bs=512 count=31344
31344+0 records in
31344+0 records out
chumby:~# md5sum /mnt/usb/mtdblock5-data
71b9597f7c43957ab9d9ff9cb183eaa0  /mnt/usb/mtdblock5-data

This is the md5sum of the shipped image from the 1.5 firmware.  I can successfully mount that on my host system.  Now I'm wondering if I dd a new filesystem over the existing one, do I need to add "seek=32" to a dd command for that to work?  Is it safe to dd while the system is running, and reboot to my new rootfs?

If you don't want to deal with a read-only cramfs partition, you can use mkfs.jffs2 to create a writable root file system.  Just replace the 'mkfs.cramfs' step in deadbydawn's instructions with:

mkfs.jffs2 -l --pagesize=0x200 --eraseblock=0x4000 -d chumby/ rfs1.bin

You may also need to align the partition before zipping by doing:

wget http://files.chumby.com/source/ironforge/build396/align.pl
perl align.pl rfs1.bin
zip rfs1.bin.zip rfs1.bin

Note: I haven't tested this, so be careful

Will that work since the kernel command line includes rootfstype set to cramfs?

chumby:~# cat /proc/cmdline
console=ttyS0,38400 root=/dev/mtdblock5 rootfstype=cramfs chumby_hwversion=3.7

I've thought about that, but dropped it because of the kernel parameter.  I've also thought about using pivot_root to use a filesystem from a USB stick.

What about hacking the kernel to ignore bootloader parameters, and use it's own?  I've seen a thread about that, but it was really out of date.  In fact, I think the OE (OpenEmbedded) kernel has a patch already prepared to ignore the bootloader's parameters.

Also, if you corrupt the bootloader, can you get it back using jtag, or i2c?

FYI, Here's the thread: http://forum.chumby.com/viewtopic.php?id=1469

Looks like "daniel" figured it out and it should work.  I may test this one night this week if I get "chumby time" again.

See this thread for unbricking a chumby (updating the entire firmware, including the bootloader) via serial.

smile.. I managed to lunch 1 chumby classic by following the instructions in the first posting. I was trying to disable the getty to ttyUSB0 . I can get to the special ops screen or during normal boot just to all blue circles page just after the initial 2 circles.

I have restoring release 172 from USB and a reboot... no joy..
I reset to factory parameters no joy
I restored my own debian ext2/3 compatible kernel no joy..
I tried dding the cramfs from another chumby classic updated to 1.7.2 and used the procedure here to try and make a clean copy of the cramfs and recreate it no joy..
which MTD is the cramfs  written  and should I just unpack it from 1.7.2  and write just that component during a special ops USB restore.. which directory..?

update1/update2?? something else??

     need someone to hit me with a clue stick I guess

      gwen

ps and yes once I get this chumby working again then I will try all the above till I either get it working or find out which step I missed

One thing you might try, and this is completely theoretical, is something like this:

cp -a /etc /tmp/etc
mount -obind /tmp/etc /etc
vi /etc/inittab
[edit inittab to remove reference to /dev/ttyUSB0]
kill -HUP 1

That'll temporarily make /etc writable, as it will actually be located in /tmp/etc.