2010-11-17 12:19:47     Flash memory scheme for recovery image

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

2010-11-17 12:19:47     Flash memory scheme for recovery image


Message: 95924   


Hi all,


This maybe better suited to the u-boot project forum, so feel free to move it.


My current development centers around a BF537, whose Flash memory arrangement consists of a single 4MB NOR device containing both the compressed kernel/ramfs and bootloader. I'm looking at designing in some redundant non-volatile memory for storing a recovery bootloader and uimage.


At the moment, upgrades are initiated remotely: the bootloader downloads the uImage by TFTP, and overwrites the previous image.  That's fine, if the download fails, or the next boot fails, it automatically downloads it again, and keeps trying until it wins. 


Upgrading the bootloader is more risky.  If the power goes out part way through the flashing (or a bad image is placed on the server) we're SOL.


The first option that sprang to mind was to use an additional SPI Flash, and let a cheap micro control the boot-mode selector pins and reset line.  If the micro detects that the Blackfin hasn't booted (using a dedicated GPIO or something), then it forces it to boot from the SPI flash.  I haven't worked out exactly what should happen next: does the SPI bootloader attempt to reflash itself, or does it just boot up, allowing an engineer to login and manually fix it?


In my mind, this seems like quite an elegant solution.  Of course, I expect there are even more elegant solutions, so if anyone has any I'd like to hear them!








2010-11-17 12:48:31     Flash memory scheme for recovery image

Wojtek Skulski (UNITED STATES)

Message: 95925    Tim: you can use two SPI flash chips managed by a CPLD. If you route the

SPI signals via the CPLD, then it can swap the SPI connections after a

timeout and boot again. It may also be possible to use one large flash

with two images and let the CPLD translate the SPI addresses, but it

would require some more CPLD programming. Xilinx has app notes with SPI

implementations in VHDL. It may be possible to adapt one of those.


In my BlackStamp design I used two SPI flash chips and a jumper, which of

course is not remote. But in practice it turned out that reflashing the

SPI chip with a cable is so quick and convenient that I never had to

resort to a two-chip solution.




2010-11-17 13:39:34     Re: Flash memory scheme for recovery image

Mike Frysinger (UNITED STATES)

Message: 95929   


the Blackfin on-chip ROM does not provide redundancy as you noticed.  but it should be pretty easy to write your own small app in parallel flash.


assuming you have a flash with "boot" sectors (meaning a few small ones rather than all large), carve out the first one for your small recovery LDR and carve out a second one for u-boot's environment.  then allocate two more portions of flash for two copies of u-boot (depending on the size, you might not all fit into the boot sectors).


the bootrom will boot your small recovery manager LDR first.  since it's so small, you can simply load it into L1.  that program should simply do:

- check first u-boot in parallel flash and calculate the CRC ... if it's valid, use the bootrom's _BOOTROM_BOOT_DXE_FLASH function to let the bootrom boot u-boot as if it were a normal boot.

- if the CRC is invalid, boot the recovery u-boot


now you only need to update the first u-boot at runtime.  if there's a power failure, you can let the 2nd u-boot recover.  probably no need to update the 2nd u-boot, but if you wanted to, that should be trivial too.


it might also be possible to use the multi-dxe booting aspects of the bootrom, but that might be conceptually harder to pull off.  newer bootroms (like on the bf52x/bf54x) do include things like crc/error functions, but you're using a BF537, so those wont help.




2010-11-17 16:53:54     Re: Flash memory scheme for recovery image


Message: 95931   


Thank-you both for your replies.  I like the SPI Flash idea because the system will boot even one of the Flash ICs gets fried..  I think I'd avoid the CPLD and use a cheesy PIC10 or something to direct the chip select, reset, and boot mode.


Mike, your suggestion is appealing because it provides redundancy without requiring additional hardware. Also, it's likely we're going to migrate to a BF527 for the revised system, so we will be able to capitalize on the newer bootrom.  I'll do some reading up on ldr-utils. 


I guess for ultimate redundancy, I could use a combination of both


Thanks again,







2010-11-17 18:26:13     Re: Flash memory scheme for recovery image

Wojtek Skulski (UNITED STATES)

Message: 95932    Tim:

SPI flash is extremely convenient during development if you adopt my

method of using the Xilinx XSPI utility and Xilinx Parallel III cable to

burn stuff into the flash chip. You do not need the CPLD for this. On my

new BF561 board I was re-burning the Uboot into the flash chip ten times a

day until I finally got the ether running and switched to ether. All I had

to do was to hold down the RESET button to make the Blackfin SPI bus

tristated while talking to the SPI chip from the PC.


Using the CPLD or PIC I think you can get away with a very simple solution

of only managing the CS# line. The two chips can be connected to the same

MISO/MOSI lines. There will be no contention because only the one whose

CS# line is active will respond to SPI. The other chip will stay dormant.