Well, it’s hard to believe that the GSoC midterm evaluations are here already. I guess it’s true what they say, time flies when you’re sitting in a basement in front of a computer all day. If I were to evaluate myself, I’d give myself a barely passing grade based on results –I’m nowhere near where I expected to be this summer. I think I mentioned before, partly this is due to TianoCore being massively more complicated than I expected when I wrote my project proposal –seriously, I ran cscope on the edk2 branch of TianoCore, and it reported over 160,000 files… the resulting index itself took up half a gig– and partly it’s due to there being so much about sophisticated C usage (and makefiles, and preprocessor directives, and macros, and calling conventions…) that I didn’t understand going into this. (But, having said that, part of the reason I applied to coreboot was I knew there were a lot of important details that had been glossed over in my classes, things that I needed to know and would be forced to learn if I worked on a close-to-the-hardware project.)
Moving on to the status of my project. In my proposal I assumed a couple weeks to improve the state of TianoCore as a payload, a month or so to write a CBFS driver for TianoCore, and a month or so to write the VGA driver. It turns out that the state of TianoCore as a payload was not very good, and so that is what I am working on.
Let me try to briefly explain my current approach. UEFI itself does not initialize the hardware. Before the UEFI firmware can be run, the system (from a cold boot) has to go through the Platform Initialization stage. The PI stage is itself made up of the Security stage (the initial booting, and some optional checksums to make sure the image hasn’t been tampered with), the Pre-EFI Initiialization (PEI , where the memory and chipsets are woken up and initialized) and the Driver Execution Environment (DXE, which loads additional drivers, then starts the UEFI). Coreboot already does most of this work in its own way, so it seems the best strategy would be for a coreboot payload to impersonate one of these stages (each stage is it’s own binary in the firmware volume), provide all the functions and data stuctures that the following stage expects, then jumps to it. Inserting the payload immediately after the Security stage seems redundant and dangerous (the PEI stage would end up trying to reinitialize hardware that’s already in use), and after the DXE stage seems too late, because then the payload would have to know how to load DXE-stage binary drivers. So I’m working on implementing a pseudo-PEI stage, that translates the coreboot provided data structures into the form that the DXE stage expects, and writing a couple dozen functions that the DXE stage expects to be available. This way we can have a minimal-sized payload that can leverage a separate DXE and UEFI stage compiled directly from the TianoCore codebase (or borrowed from a manufacturer supplied image, like a traditional option ROM). I think I can have this working by the end of summer. Thoughts?
I’ve been holding off on writiing a post until I had some significant chunk of code I could point to to show that I’m making progress. Well, I am making progress, but there’s no “significant amount” of code yet. I’m not worried about the slow start, because what I’m doing makes sense and I am writing code, but there are still so many things I run into every day where I have to stop and look something up to try to figure out why it was done a particular way. Almost all of the confusion comes from the TianoCore codebase, which is 1) huge, and 2) written in a consistent but unfamiliar style. Like this line,
IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor OPTIONAL,
What’s with the IN, OUT and OPTIONAL? I haven’t been able to find them defined anywhere, I’m assuming they’re special comments that Visual Studio knows about, but I haven’t found any reference to them. In comparison, reading the coreboot code is fun and easy. It’s just straightforward c.
Since a few hours, my Nvidia MCP61/MCP65/MCP67/MCP73/MCP78S/MCP79 SPI driver is tested and it works well. Only probing for a flash chip was tested, but still… this means my SPI bitbanging code is correct, and Michael Karcher’s reverse engineered docs are correct, and my implementation of the Nvidia GPIO interface used for bitbanging SPI is correct as well.
This is big news because with this patch flashrom finally has 100% support for all x86 chipsets we saw in the last ten years.
Huge thanks go to Michael Karcher for reverse engineering the interface and writing up cleanroom documentation which I could use for implementing the interface.
Huge thanks to Johannes Sjolund for testing my patch on his hardware although it was completely untested before.
Get the patch here: http://patchwork.coreboot.org/patch/1520/ (click on the “patch” link on that page to get a download).
Continue reading First successful Nvidia MCP6x/MCP7x SPI access
I’m finally past the point where I’m scratching my head over what I’m reading and know what I have to do. This changes my initial schedule, somewhat. I hadn’t really understood how much work needed to be done to make TianoCore an effective payload, so my original estimate of “two weeks” was totally wrong, but now that I’ve started I’m feeling good about it. Right now I’m working on getting TianoCore to build with the coreboot reference toolchain, and adapting the Makefile and kconfig stuff from FILO. The current way of building TianoCore’s edk2 package involves building their toolchain, and I’d like to cut that part out, or automate it if I can’t cut it out entirely. The goal is to reduce the number of hoops that potential users and developer’s have to jump through in order to try EFI with coreboot.
I would like to report that I’m making some progress, but that wouldn’t quite be accurate. I am making progress: I’m putting in adequate hours, reading code, reading specifications, but… let’s just say I’m starting to appreciate some of the less than complimentary things I’ve read about [U]EFI. It is extremely complicated. My inner engineer is constantly frowning as I read page after page of documentation, thinking, really? they couldn’t think of a simpler way to design this? Not trying to complain. There are a few things I really like about EFI, but this sort of software development –the kind that starts with 3000+ pages of specifcations– is unlike anything I’ve ever dealt with.
Getting the flashrom 0.9.2 release out of the door was a really labor-intensive process because we wanted to make 0.9.2 the 1000th commit in the repository. That worked and 0.9.2 is a really nice release with no known regressions, but a lot more features and improved reliability. Speaking from experience of the last 3 releases, acting as release manager is really a full-time job and will not leave any spare time for developing cool features.
flashrom GSoC development is right on track. So far, I have posted patches for:
Continue reading flashrom progress report #1
The flashrom developers are happy to announce the release of flashrom 0.9.2.
flashrom is a utility for reading, writing, erasing and verifying flash ROM chips.
flashrom is designed to update BIOS/EFI/coreboot/firmware/optionROM images on mainboards, network/graphics/storage controller cards, and various programmer devices. It can do so without any special boot procedures and from your normal working environment.
After over nine years of development and constant improvement, we have added support for every BIOS flash ROM technology present on x86 mainboards and every flash ROM chip we ever saw in the wild.
Highlights of flashrom:
Continue reading flashrom 0.9.2 released