[coreboot] GSoC 2010

Joseph Smith 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>
wrote:
> 
> 
> 
> 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
>>>>> 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:
>> 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,
>> 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.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org





More information about the coreboot mailing list