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