Topic: chumby One ROM image

If you're hacking around on your chumby One and manage to accidentally overwrite the bootloader, or if you want to upgrade to a bigger SD card, you can now go grab a zipped copy of ROM 1.0.3, unzip it, and then write the resulting image out to an SD card.

Windows users can use win32imagewriter.  Linux users should make sure the drive is unmounted, then dd the unzipped rom to /dev/sdX (where X is the letter of the USB reader).  OS X users should make sure the drive is unmounted (not ejected) and dd the image to /dev/diskN (where N is the number of the drive).

When you boot off of a freshly-formatted SD card, it will repartition itself such that partition 6 (eventually formatted as /mnt/storage/) fills up the remainder of the card, so you'll notice it reboot once on its own.  Also, since it'll need to reformat /mnt/storage/, it will take a long time on the screen with the colored circles (possibly several minutes), so just leave it on that screen.

I'd be curious to know if anyone finds this useful.

Re: chumby One ROM image

This was a great tip.   I upgraded the stock 2GB caard with a 8GB I had in my phone.  Now I just need to fill the card up with music.  Beside music is there other things we can put on the card that the chumby can recognize?

Re: chumby One ROM image

Cool!  Were there any issues booting?  During testing we tried a 16 GB card, and there was something like a 10-second delay before it loaded the bootloader.  Do you see anything like that?

4 (edited by likearaptor 2009-12-28 13:25:25)

Re: chumby One ROM image

Maybe a 5 second delay?  I didn't really notice much delay.  After it booted up it rebooted once and has been working great.  I didn't have any issues.  I was hoping the chumby supported the MicroSD HC, and it does.  So is there a size limit?  I can only find a 16GB card out but I am sure in the future it might go to 32 or 64 GB.

Thanks for all your help.

Re: chumby One ROM image

I haven't even received mine yet and I think this is cool!  Cannot wait to start playing around/experimenting with mine!

Re: chumby One ROM image

I just upgraded my C1 to 4GB using a spare microSD I had lying around.  I actually did my upgrade manually, doing a dd copy from the old card to the new one to be sure to duplicate the partitioning scheme correctly.  I then used fdisk on the PC to manually delete and recreate the final two partitions, giving the extra space to the /mnt/storage one, then a mke2fs and a cp -a to populate it.

I was curious, why are there overlapping partitions?  Is that a weird extended partition scheme where the start of the first one has the kernel image for easy loading directly from the block device, with there also being the protected disk image for the recovery mode?

Re: chumby One ROM image

I was also wondering about the overlapping partitions. It threw me a curveball for a while.
Not to mention how the kernel seems to be dd'ed to the partition after the bootloader. (but I could be wrong)

8-)

8 (edited by tiersten 2009-12-30 06:30:51)

Re: chumby One ROM image

unwiredben wrote:

I was curious, why are there overlapping partitions?  Is that a weird extended partition scheme where the start of the first one has the kernel image for easy loading directly from the block device, with there also being the protected disk image for the recovery mode?

The weird partitions are how the iMX233 wants it from what I can gather.  The documentation is pretty unclear but the FS type ID byte in partition 1 should be an S to signify SIGMATEL.  The start LBA field is the address of the bootloader and here is where it gets odd, the length of the bootloader appears to overlap with part of the entry for partition 2.

The CPU reads the MBR from the SD card, loads the initial bootloader from the start of partition 1 which then starts a second stage bootloader which loads a bunch of binary blobs and the kernel from inside partition 1.

Re: chumby One ROM image

The boot partition has a primitive "filing system" of sorts. The first thing on the partition is a configuration directory where files used by the first and second stage bootloaders are addressed using 4 character names, the names being mapped to offset and length pairs. The second stage bootloader is called "boot".

I ended up changing the scheme a little so that one could optionally exclude the length, and instead read it from the object being loaded (in my case, a Symbian ROM image). This means I can add or replace a ROM image with dd, rather than having to use the provided config util. This makes things a little simpler for me, but probably wouldn't work for Linux kernel images.

Re: chumby One ROM image

It looks like the first partition does overlap the entirety of the second, as well as the first third or so of the third partition.  This isn't too much of a concern, because the first stage bootloader (which gets loaded by the on-die ROM) contains an embedded "size" parameter that defines how big the image is.  It's usually about 30k, if that.  The first-stage bootloader pulls size and offset information out of the config block, which it then uses to load the second-stage bootloader.

The other partitions don't really overlap, because they're sector-aligned not cylinder-aligned.  You can verify this by running "fdisk -u -l /dev/mmcblk0p1".  If you don't specify "-u", it will give you cylinder-sized offsets, which can appear to overlap.  Because the same image can be written onto different SD cards, and because we don't really have a need to boot DOS, we sector-align rather than cylinder-align partitions.

Re: chumby One ROM image

Hi,

is there a way to make ourself such an ROM image, so we can ommit parts we don't need?

Best regards,
Andreas

Re: chumby One ROM image

Was that 5 minute delay with every boot or just the first one?  My understanding is that with a larger card, the first boot spends some time resizing the file system, but I wouldn't expect that delay in the future.

Re: chumby One ROM image

The bootloader (stage two, in fact) is the thing that draws the first pair of eyes to the screen.  On the 16 GB card I tried, it took 10 seconds to load the first-stage bootloader every time, but in retrospect it could have been a defective card.

unwiredben is correct in that the first boot will stay on the colored-eyes screen for a very long time (5 minutes sounds about right) while it reformats the /mnt/storage partition.

Re: chumby One ROM image

Great mission!
After a defect microSDcard, I dl the file, copied the image via imagewriter @Windows system to the card and restarted the system. Now, my chumby is up and is working again. THANKS!

Question: is this another offline FW (like zurk's), cause there was no error message ("chumby server not reachable") after connecting my WLAN. big_smile