Busybox post on rewriting flash devices

Quote

Subject: Re: flashcp
Date: Thu, 6 Jan 2011 03:59:39 -0600
From: Rob Landley
Organization: Boundaries Unlimited
To: busybox@busybox.net
References: <AANLkTikTLAbTo5aAs7=5TqHsewOq49mDUbVcjfs3AvzR@mail.gmail.com>

On Friday 31 December 2010 03:50:59 Vladimir Dronnikov wrote:
> Hi!
>
> We at #openlgtv have been using "flash_eraseall /dev/mtdX" and then
> "cat newfile >/dev/mtdX". Since there's no atomicity in such a
> process, chances high to brick the device.
>
> Wonder how safe is to use BB flashcp utility?

If you're not using a flash filesystem, there's an inherent lack of atomicity to flash updates. You have to erase an entire erase block, and then rewrite that erase block. These are electrically two separate operations, depending on your flash device that can be anywhere up to a couple megabytes, and could take multiple seconds to do.

This is why your PS/2 says "don't turn off the console while writing to flash". Sony hasn't got a better idea. It's an inherent problem with flash. And this is why things like jffs2 exist, because using ext3 on a flash disk turns out to be a really bad idea:

http://lwn.net/Articles/349970/

In theory, you can get the flash erase block size:

http://processors.wiki.ti.com/index.php/Get_the_Flash_Erase_Block_Size

Then use flash_erase to zap just one block, and then write that block with dd or some such. But is this really an improvement? In practice, will your device be any less bricked if it was halfway through writing a new kernel or
squashfs image and a 128k chunk halfway through got erased but not rewritten?

The solution embedded people use is either:

1) Use a jtag to reflash the device, so no matter how bricked it gets it can be externally driven by shouting "clear", applying paddles, and hooking it up to an IV drip.

2) Have a small bootloader in its own flash erase block (or actual ROM) that never gets overwritten and is capable of loading and booting something from network or serial or some such, so you always have a fallback recovery option.

3) Design the hardware to boot from an SD card, so you can unbrick your embedded device the same way you unbrick a PC, by inserting a boot disk.

Smart phones combine approach #2 and #3, plus have a battery in the device and refuse to start flashing unless there's a minimum remaining battery capacity. (If you yank the battery while it's reflashing itself, you get to keep the pieces.)

Rob