> -----Original Message----- > From: [email protected] [mailto:[email protected]] > 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
