[coreboot] GSoC 2010
joe at settoplinux.org
Sat Mar 6 17:22:06 CET 2010
On Sat, 06 Mar 2010 17:13:41 +0100, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at 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 at coresystems.de> wrote:
>>> On 06.03.2010, at 15:50, Carl-Daniel Hailfinger
>>> <c-d.hailfinger.devel.2006 at 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
>>>> 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
> Since there is so much interest in flashrom as a payload, I'd like to
> know which variant you prefer:
> 1. 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,
> 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 :-)
More information about the coreboot