flashcp

Rob Landley rob at landley.net
Thu Jan 6 09:59:39 UTC 2011


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 bock 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
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.


More information about the busybox mailing list