[flashrom] GSOC 2011

[Carl-Daniel Hailfinger]

Am 19.03.2011 18:00 schrieb Stefan Tauner:
> i tried to get flashrom to work on my two main computers[1], but they
> don't work because of the EC/Intel's management engine (ME).
> i don't know for sure how the vendor tools do the flashing, but i
> presume that they talk to the ME via HECI to coordinate the process.
>    

Locked region reflashing is considerably harder than handling the rest 
of the flash. Most Intel chipsets released after ICH7 (except later ICH7 
derivatives) support two flash interfaces: One interface which lets 
flashrom do all the heavy lifting (which we use right now), and one 
interface outsources read/write/erase commands to the chipset and just 
tells the chipset in abtract terms what to do. Most locked down boards 
still allow the outsourced interface to read some regions, but that 
interface is not supported in flashrom right now. One of the interfaces 
is called hardware sequencing, the other one software sequencing, but I 
can't remember which one is which. If we can add a driver for the 
currently unsupported interface (which is fully documented), we'd 
already achieve a major step forward.

> my (project) idea is to try to reverse engineer some vendor tools to
> see how they work and try to reproduce it in flashrom to eventually
> support ME enabled motherboards in flashrom. i dunno how big the impact
> would be, but i guess this would allow even many laptops to be
> supported?
> what do you think about this idea and its feasibility?

Having the ME reflash some stuff would definitely be interesting, but I 
have no idea if there is even a consistent interface for that, and the 
problem space is similar to having an EC reflash some stuff. It can be 
done, but each machine would have to be reverse engineered individually. 
Not fun. If you attempt any of this during GSoC, please make sure you 
first support the interface I mentioned above, and if any time is left, 
reverse that for reversing any ME-controlled flashing.


> any volunteers for mentoring? :)
>    

I could serve as mentor.


> also i have some questions about the "official" ideas:
> UI:
>   - With TUI do you mean (something like) ncurses?
>   - the "current" code is [3]? i have not looked into it yet.
>     - has it to use qt and/or that code (i like java *hide* and have a
>       bit of gdk experience)?
>    

To be honest, a GUI would be nice, but right now the bigger problem is 
to get the command line interface and flashrom internals into shape 
before it can be useful to the general population (especially the locked 
down chipset issue needs to be addressed).


> recovery stuff:
> guess it would be mandatory to have a working coreboot setup with real
> hardware for that?
>    

Strongly suggested, yes.


> bitbanging support: this would also require available hardware. would i
> have to buy that myself? can it be borrowed from someone?
> these projects would probably profit from my open workbench logic
> analyzer...
>    

We already support bitbanging for SPI, and some bitbanging code for 
LPC/FWH is available, someone just has to clean it up and get it merged. 
Michael Karcher recently posted bitbanging code for Parallel, so most 
interfaces are covered.


> the infrastructure things sound a bit boring, but from what i saw in
> the source some refactoring would (also) improve the codebase
> somewhat. ;) so the infrastructure-related projects may be even the most
> valuable contribution for longterm goals. ok that was not really a
> question, sorry.
>    

Heh, yes. Our big bottleneck right now is reviewer time. There are quite 
a few refactoring patches waiting for review, and there is more in the 
queue.


> if there are other ideas i would love to hear them (soon).
>    

I'll try to update our GSoC page with ideas.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/