-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Ed Swierk Sent: Wednesday, July 14, 2010 12:45 AM To: Coreboot Subject: [coreboot] cbfs for safe flashing
Hi folks,
I'm using Coreboot to implement an old-school Linux-as-bootloader for a prototype board, which has an 8-MByte SPI flash attached to an AMD SB800 southbridge. I'd like to take advantage of that nice roomy flash, as well as the normal/fallback capabilities of Coreboot and the layout and partial-rewrite features of flashrom, to provide a safe firmware upgrade path for end users.
Ideally I'd divide up the flash so that the normal Coreboot+payload are separate from the fallback Coreboot+payload and bootblock. The end user would only rewrite the normal Coreboot+payload. If the rewrite fails leaving the normal area of the flash completely scrambled, the board would still boot using the fallback Coreboot+payload. And for extra credit, I'd try to put the critical fallback bits in an area of the flash that can be turned read-only once it's programmed at the factory.
Following the flashrom layout format, here's how I imagine partitioning the flash:
00000000:003fffff normal+payload 00400000:ffffffff fallback+payload+bootblock
Wouldn't you want three areas? I'd think you'd want another for just the bootblock.
Following Patrick's helpful recipe (http://www.coreboot.org/pipermail/coreboot/2010-February/055944.html) I figured out how to build a rom image with a cbfs containing normal and fallback files. Unfortunately the build system insists on placing each new file at the beginning of the free space; I didn't see any obvious way to convince cbfstool to leave a gap after normal+payload and place the fallback files at 00400000. I hacked around this by creating a dummy pad file and adding it before the fallback files. Is there a better way to do this?
It seems like there used to be a way to specify an address, which would force CBFS to add the empty space for you.
I'm thinking of extending the cbfs format to allow more than one top-level header in the bootblock. In my scheme, there would be two: one pointing to the first normal file, and another pointing to the first fallback file. Searching for a file would involve scanning each series of files linked from the headers in the bootblock, and would simply terminate if no matching filename were found in any of them.
This implies changing cbfstool and any code in Coreboot that touches cbfs. Before I jump off the deep end, is there an easier or better way to achieve this?
Instead of erasing one image to test it, you could add blank images with the same name. That would allow you to test the case of a bad flash. The case where CBFS is corrupted shouldn't happen too often, and when it does it is only inconvenient to have it take a long time to boot. The fact that it recovers will make up for that :)
Thanks, Myles