On Sat, 06 Mar 2010 11:22:06 -0500, Joseph Smith joe@settoplinux.org wrote:
On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 06.03.2010 16:19, Joseph Smith wrote:
On Sat, 6 Mar 2010 16:06:50 +0100, Stefan Reinauer stefan.reinauer@coresystems.de wrote:
On 06.03.2010, at 15:50, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net
wrote:
To summarize: I don't think porting flashrom to Windows would be a good GSoC task.
Porting flashrom to DOS would be interesting, but I have no idea if our coding style allows usage of old compilers for DOS.
Porting it to FILO/libpayload would be a nice project, too! With that feature and an easy way to do partly coreboot flashing, we'd have an incredible fallback payload that can even work as a restore point if it's not even possible to boot an OS.
YES! Flashrom as a coreboot payload would be truly awesome!
Doable, but AFAICS a good student would only need 1 week (maybe 2) to achieve the simplest variant, so I have to recommend against it as a GSoC task. It would be a truly good test for GSoC applicants, though. (Implement a part of that, and we believe you can implement the other tasks.)
Since there is so much interest in flashrom as a payload, I'd like to know which variant you prefer:
- Full flashrom with GUI as payload (may easily exceed 200 kB
uncompressed and 60 kB lzma compressed). 2. Tiny flashrom stub for remote flashing over serial/network/whatever (~10 kB uncompressed and 3 kB lzma compressed, maybe even smaller). 3. Load flashrom from an external medium (serial/USB/floppy/whatever) to RAM and execute it (no space requirements).
Variant 1 does waste a lot of flash space and is unable to cope with new flash chips, and you have no way to recover if flashing goes wrong because you can't upgrade flashrom in the first place. It is the only standalone solution, though, and it is fast. Variant 2 is essentially a stripped down SerialICE with one or two extra commands. Rather slow, but you can upgrade the controlling flashrom app on the master computer (and test patches) without having to mess with the contents of the flash in the slave (to be reflashed) computer. Besides that, it allows even such stuff as PCI card reflashing (for gPXE and stuff). Variant 3 has a high initial load time, but flashing will be fast. No guarantees on how to recover if flashrom crashes or exits prematurely, though.
Now if you think these tasks (or a combination thereof) are sufficiently difficult for GSoC, I'd like to apply for solving them ;-)
What about Variant 1 but with Kconfig options to choose only certain
flash
chips supported by your board, thus reducing the overall size. This combined with bayou and a normal OS booting payload would be incredible
:-)
Or like Stefan said, just make it part of FILO, that way it already has disk access to find the bios image to flash.