A highly unusual sight? Yes. A pink room filled to the brim with hardware, hackers and pizza boxes.
An unexpected place? Indeed. The architecture faculty building of the Czech Technical University in Prague.
An unusual schedule for four days in Prague? Of course. Intense hacking, talks, discussions and hardware destruction/modding.
Highly unusual sightseeing? Absolutely. A steam-powered wastewater treatment plant and the Prague Signal Festival.
Excellent food? Oh yes. Czech specialties at really low prices.
Disasters? Not really. There were canceled trains/planes from and to Prague affecting quite a few of the attendees, but those were eventually overcome.
Bad things? Possibly. We did unspeakable things to BIOS and EFI images, and we’re proud of it, so I’m not sure if that qualifies as bad.
Great meeting? Awesome meeting!
So what did we do?
– Found a way forward for the dozens of boards which haven’t been tested in ages.
– Overhauled the board status reporting model, so be implemented soon.
– Evaluated ways to get board testing into a state where people can do so easily without manual work.
– Discussed hardware vendor interaction.
– Agreed to ship verified boot functionality by default in a way which still keeps all the freedom for the user.
– coreboot will get a compelling security story out of the box.
– Fixed bugs in some ports.
– Ported a few new laptops.
– Learned new tricks to improve suspend-to-RAM functionality the easy way.
– Made a plan to upstream essential drivers in the chromiumos branch of flashrom.
– Adjusted the flashrom development model to something that works with the scarcity of reviewer time currently available.
– Found out that a video projector is a nice way to test VGA output in case the only VGA capable monitor is in use.
– Noticed that pretty much every question in the form of “does anybody have X” can be answered with “yes” if X is something that may be connected to a computer or is remotely useful for coreboot.
– Didn’t get a lot of sleep.
– Listened to talks about the present and future of coreboot.
– Met some longtime community members for the first time.
Photos of the meeting and sightseeing will be added soon.
flashrom is growing rapidly and we are constantly adding support for new SATA/PATA controllers, network cards, graphics cards, USB devices, JTAG cables, DIY hardware hacks, desktop/server mainboards and even some laptops.
If you own a piece of hardware which has a flash chip and lives in a PC (embedded devices with NAND flash are already covered by other software), and if you want to reflash that piece of hardware, please comment here (with some info on how to reach you) or mail us at email@example.com. We will use this to prioritize support for hardware people are interested in.
If you ever had to work with a clone of a git repo which was created with git-svn, you might have tried to run
git svn info .
to find out about the latest svn revision in the git tree. Instead, you will see the error message
Unable to determine upstream SVN information from working tree history
and you might scratch your head. Turns out that git svn info only works for local trees created with git-svn. Once you clone such a tree, all svn related metadata will be lost. This data loss is by design. Apparently git considers svn info to be “metadata” which will not be cloned, whereas git history is not “metadata” and will thus be cloned. Is is also apparently fairly well known among git developers and advanced users that git svn only works from the repository it is initialized from, but the documentation doesn’t mention this limitation anywhere AFAICS. Similar issues exist for git svn log.
My GSoC 2010 flashrom project has been a full success, and I managed to add lots of features to flashrom which were not part of the original requirements as well.
You can now use flashrom on PowerPC and MIPS with most programmers. I added the last bit of infrastructure in version 0.9.2-r1111, and we got a few success reports since then. All USB/serial/network drivers work, and quite a few PCI drivers work fine as well.
Added bonus: If your flashrom driver selection does not need direct hardware access (e.g. USB programmers, serial programmers, dummy, …) you can now compile flashrom on all architectures, even those which are not explicitly supported. That feature was added in version 0.9.2-r1116.
This is a big step forward for flashrom which had been x86 centric since the beginning.
I merged my Nvidia MCP61/MCP65/MCP67/MCP73/MCP78S/MCP79 SPI support patch a few days ago in version 0.9.2-r1113, but right now flashrom will refuse to erase/write on those chipsets for safety reasons. Details about the patch can be found in my earlier blog post: First successful Nvidia MCP6x/MCP7x SPI access.
Current flashrom is thus well-equipped to handle any x86 mainboard you throw in its way.
A few days ago I added flashrom support for the RayeR SPIPGM hardware by Martin Rehak. It is basically one capacitor and a few resistors attached to a classic parallel port cable, and you can use it to reflash SPI chips. Many recent mainboards from MSI, Gigabyte, VIA and other vendors have either removable SPI flash chips or a JSPI/JSPI1/SPI header where you can attach RayeR’s programmer to perform a BIOS recovery. See http://rayer.ic.cz/elektro/spipgm.htm for schematics and instructions.
If you want to test it, compile flashrom version 0.9.2-r1093 or later. RayeR support is enabled by default. To invoke the RayeR driver, run
flashrom -p rayer_spi
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).
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:
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: