[coreboot] GSoC 2010
joe at settoplinux.org
Sat Mar 6 17:35:12 CET 2010
On Sat, 06 Mar 2010 11:22:06 -0500, Joseph Smith <joe at settoplinux.org>
> 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
> 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.
More information about the coreboot