openbiosprog-spi, a DIY Open Hardware and Free Software USB-based SPI BIOS chip flasher using flashrom

openbiosprog-spi device

If you're following me on you probably already know that I've been designing a small PCB for a USB-based SPI chip programmer named openbiosprog-spi.

The main use-case of the device is to help you recover easily from a failed BIOS upgrade (either due to using an incorrect BIOS image, due to power outages during the flashing progress, or whatever). The device only supports SPI chips, as used in recent mainboards (in DIP-8 form factor, or via manual wiring possibly also soldered-in SO-8 variants). It can identify, read, erase, or write the chips.

Of course the whole "toolchain" of software tools I used for creating the hardware is open-source, and the hardware itself (schematics and PCB layouts) are freely released under a Creative Commons license (i.e., it's an "Open Hardware" device). The user-space source code is part of flashrom (GPL, version 2), the schematics and PCB layouts are licensed under the CC-BY-SA 3.0 license and were created using the open-source Kicad EDA suite (GPL, version 2).

openbiosprog-spi schematics
openbiosprog-spi Kicad PCB layout

The schematics, PCB layouts, and other material is available from gitorious:

  $ git clone git://

You can also download the final Gerber files (ZIP) for viewing them, or sending them to a PCB manufacturer.

Some more design notes:

  • The device uses the FTDI FT2232H chip as basis for USB as well as for handling the actual SPI protocol in hardware (MPSSE engine of the FT2232H).
  • Attaching the SPI chip:
    • There's a DIP-8 socket on the device so you can easily insert the SPI chip you want to read/erase/program.
    • Optionally, if you don't want a DIP-8 socket, you can solder in a pin-header with 8 pins, which allows you to connect the individual pins to the SPI chip via jumper wires or grippers/probes.
  • The PCB board dimensions are 44mm x 20mm, and it's a 2-layer board using mostly 0603 SMD components.

Basic usage example of the device on Linux (or other OSes supported by flashrom):

  $ flashrom -p ft2232_spi:type=2232H,port=A -r backup.bin (reads the current chip contents into a file)

openbiosprog-spi PCBs
openbiosprog-spi parts list

Over at the main projects page of openbiosprog-spi at

I have put up a lot more photos and information such as the bill of materials, the Kicad settings I used for creating the PCBs, the Gerber files and the Excellon drill files and so on.

The first few prototype boards I ordered at PCB-POOL.COM (but you can use any other PCB manufacturer of course), the bill of materials (BOM) lists the Mouser and CSD electronics part numbers and prices, but you can also buy the stuff elsewhere, of course (Digikey, Farnell, whatever).

I already hand-soldered one or two prototypes and tested the device. Both hardware and software worked fine basically, you just need a small one-liner patch to fix an issue in flashrom, but that should be merged upstream soonish.

In order to make it easy for interested users to get the PCBs I'll probably make them available in the BatchPCB Market Place soonish, so you can easily order them from there (you do still need to solder the components though). Note: I'm not making any money off of this, this is a pure hobby project.

All in all I have to say that this was a really fun little project, and a useful one too. This was my first hardware project using Kicad (I used gEDA/PCB, also an open-source EDA toolsuite, for another small project) and I must say it worked very nicely. I didn't even have to read any manual really, it was all pretty intuitive. Please consider not using Eagle (or other closed-source PCB software) for your next Open Hardware project, there are at least two viable open-source options (Kicad, gEDA/PCB) which both work just fine.

GSOC Coreboot Kconfig summary

Although the GSOC 2010 is closed,  my patch about coreboot kconfig which involving the payload kconfig is send to the mail list. There are only two payload are supported.”Filo and coreinfo”. I can add more, but i would like to wait a moment. Because the most important of my project is not how hard it is but how to make the users can use it easily. There are also some consideration should be discussed with the others.

The latest patch which i send now support:

1. use coreboot to load the payload’s kconfig. This feature can be used by “make config PAYLOAD=filo” or “make config PAYLOAD=coreinfo”. Coreboot users can use the coreboot as before too. just “make config” and “make” to manually put payload.elf under coreboot directory. The new method will do all of these things automatically. The method which i use is let the coreboot kconfig detect the macro PAYLOAD, if the variable matches filo/coreinfo, it would load the filo/coreinfo kconfig. It also disable the coreboot kconfig’s payload menu which could avoid conflict.

there is a consideration which should be discussed. There is an sinario,the libpayload may be modified between “make config” and “make”. I did not take this into consideration, because it can be avoid by “make clean” to rebuild the project. If anyone thought it’s improper, please let me know.

2. Most of the payload are using libpayload. Libpayload should be installed to certain path to make sure payload can be compiling correctly. The previous patch which i send are using to let payload can load libpayload automatically, it can configure the libpayload each time. Like enable USB features or not. It’s pretty easy to build the payload. the whole things can be worked as one.

I also posted an new patch about filo to use an new method to do these things. The previous method is trying to use filo’s kconfig program to load libpayload config files. Lots of messages are show the same with filo while filo configuring libpayload. The new patch use a remote method which invoke libpayload’s own kconfig program to buid itself. The patch also looks simpler that previous.

The time is passed much quick. But i learned much about the open source. I reviewed the goals of GSOC

Google Summer of Code has several goals:

  • Create and release open source code for the benefit of all
  • Inspire young developers to begin participating in open source development
  • Help open source projects identify and bring in new developers and committers
  • Provide students the opportunity to do work related to their academic pursuits during the summer (think “flip bits, not burgers”)
  • Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)

I am so glad that i can join the open source family before graduation. Coreboot is a wonderful project, from here I can learn much about the X86 systems, firmware things. I also should spend lots of time to learn them. One of my experience is that real-world software should thinking every possibility not only the realization of  features. Marc always told me: thinking about all of the corner cases. That helps a lot. Thanks to google give me this opportunity to join in Coreboot. Thanks to my mentor Marc,  he is a very nice man who knows everything that i want to know He tells me how to join an open source project, how to do real software programming, how to considerate the software. Thanks to QingPei, who helps me a lot during the whole process. He also tells me that: “GSOC is an opportunity to teach new developers rather than a chance to get a pile of free code. It’s a big step for me to learn how to contribute to coreboot. So no matter my last evaluation is passed or not. I will try to do all of these things.

By the way, Any ideas about the coreboot kconfig things is welcome.

There are also some questions that should be completed:

1) What was the final outcome of your project?
well, i am not sure about this. I think i am good, i learned how does coreboot work, how wonderful it is. Although patches are still pending. But the patch is the best way i can realize the feature with my ability.

2) What problems did you encounter and how did you work through them?

The problems which i can not forget is it’s much more hard than i had ever think about low level things. At the beginning, it’s only seems wonderful for me, Coreboot did the all of the legacy system bios things. But after several weeks, i found that the coreboot developer are all genius, it’s too hard to understand the who things. Fortunately i at least know how does coreboot work, i know lots of things that i can not learn from class. i used to call QingPei for 3 hours to let him tell me what’s the coreboot things going on.

3) What did you learn about open source development?

Lots of them, there are two parts. First, the real project programming skills. At least i can read most of the Makefile and understand how does these things doing. I also know pretty much about Kconfig language. By the way, i also learned much about “Bash” “Sed” programming. I learned how to work with linux gcc.there are something more i can not write down one by one. Second, i finally can join an open source project, i knew how does the large open source project are working. It need “singed-off-by” and “ack-by” before checking in the code. the build service will show interesting messaging if there is any error between the building progress.
4) Do you plan to work on other open source projects? Which ones?

Because there are also lots of thing should be done with the coreboot kconfig things. I would like to still my work with coreboot, i hope i can contribute more for coreboot.
5) What did you learn about coreboot?

Pretty much. As i said in question 3.
6) Do you plan to develop or use coreboot in the future?

Sure, i will.
7) What could coreboot do better to help developers in the future?

More manuals for the new developers? Although i thinks the wiki is good enough. If there is more manuals, it will be better.
8) Would you recommend coreboot GSoC to other students?

I will, but i should check if he is smart enough.
9) Do you feel that you passed or failed your GSoC project?

I do not know, it does not matter, as least i learn  pretty much more thank i thought.

Thanks to Google

Thanks to Coreboot

Thanks to Marc Jones

Thanks to Wang Qing Pei

filo payload infrastructure

after several times long discussion with marc. We finally decide to make the filo kconfig as below rules:

1) move filo source code to coreboot/payloads. We should put all of there payloads under this directory right?

2) check the filo libpayload configuration before loading kconfig. The design of the payload infrastructure is gonna to make libpayload be included, but the only method for that is use the makefile “source” command, so we should tell this “source ” where this libpayload is. if the filo located in coreboot/payloads/, then for filo the payload must be under the path “../libpayload”.

3) merge the libpayload configuration into filo payload configuration, after loading libpayload kconfig under the filo kconfig, after this configuration all of the configuration are saved in the default .config file. Then copy the whole .config into libpayload directory. these configuration about filo may be useless for libpayload, but it does not matter, which will not influent the libpayload installation.

4) the next step may be check if there is any conflict between the libpayload and the other paylaods.

successfully porting coreboot to Jetway PA78VM5

I would like to say the first public mainboard porting has already successfully  been done. The whole work also including fintek f71863fg superio supporting. I would like to see the linux login shell shows on the screen. The vgabios is still working under the coreboot and payload process. But it always caused blank or flashing some nonsense character. I really did not know why. the VGA is extracted from the AMI bios. the strange things in that original vbios has an different device id  with (1002,9611). it is (1002,9610). As is known, 0x960 is the 780 vbios (HD3200), but Jetway PA78VM5 has an 780v(HD3100)vbios. I changed the vbios’s device id to make coreboot can load it correctly. it worked, but seems did not work very fine.

the other ongoing progress is digging the coreboot fam10 problems. the latest coreboot can not run very well with most of 780 family mainboard which including mahogany. So i should dig into the code to check out the which revision caused it.

In the next week, i will begin my next mainboard porting which is got from L84Supper. Thanks to him for sending me the board. After i know that shinner coreboot code can not be released, i should trying much more public mainboard porting.

coreboot porting to jetway PA78VM5 have been 95% successful.

i am  glad to say that the Jetway PA78VM5 mainboard can run coreboot sucessfully. The configuration of Jetway PA78VM5 can be found at PA78VM5.the coreboot+filo can work fine. The kernel began booting, but the only problem is after kernel shows”jumping to **” the serial port stoped showing anything. And i have already set the kernel parameter with “console=ttyS0,115200”

First of all thank olsen provide me this mainboard.

The mainboard have an SPI flash W25X80A, my SF100+testchip SO08 can detect the flash type, but can not erase the flash correctly. After contacted with dediprog engineer. i remove the flash from the board, it seems fine, the programming is fine, but i can not use it with the mainboard unless i can bear removing the flash chip every time i need to rebuild the coreboot. After that, i replace that flash chip with an sst 080b. it worked pretty fine. 🙂

another problem is while the coreboot booting, it stoped while corebooting trying to extract the cbfs files. i debugged this for a long time, finally thanks to patrick, i take his advice remove the $(CBFS_COMPRESS_FLAG).it worked.

the latest problem is that amd famlily10 may have much problem with the current build version.

i should find out what difference between btdc and coreboot public version caused problems.

my next step may focus on this things merge the code, and find out why the kernel did not show the booting message.

i am so glad that coreboot can finally booting the Jetway PA78VM5

libpayload xcompile

after a long time learning and code checking, several things has been done:

1)kconfig language have already been learned,  i learned all of these things from “”

2)much clear with libpayload xcompile code and menuconfig things. i reviewed all of the code under libpayload/util.

question is i do not know what interface should be added into the libpayload menuconfig. and i also have an doubt about the coreboot xcompile. why not just put the files into the trunk but instead of making the downloaded with and script?

flashrom 0.9.2 released — Open-Source, crossplatform BIOS / EEPROM / flash chip programmer

The long-pending 0.9.2 version of the open-source, cross-platform, commandline flashrom utility has been released.

From the announce:

New major user-visible features:
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details.

Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers.

Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.

The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming.

Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more.

More details at and in the list of supported chips, chipsets, baords, and programmers.

I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.

Jetway PA78VM5-H porting progress

firstly, thanks to Scott Olsen for supporting the mainboard. PA78VM5 is 780/700/ddr2.

The superio which it used is fintek f71863fg. I have already make all of the code done. but at last i found that i do not have the serial port convert which make me can connect to it.

The following week may be used to 1)extract the vbios. 2)make the linux booting…

i am pretty looking forward that.

Coreboot console over Ethernet

Although this article is about Coreboot I start from beginning. Once upon a time (November 2009) there was nice idea to make SerialICE work through the Ethernet link. Reason is simple, it is slow and Ethernet is way faster. I started to investigate if there is some network adapter which can be used without the need of RAM.

If you check the documentation of most Ethernet chips, the packet descriptors are always located in main memory and they  just use DMA to transfer data to/from the FIFO inside the card. I tried some sophisticated google queries to find out if there is some adapter with internal SRAM, and after a while I found one. Continue reading Coreboot console over Ethernet

Getting TianoCore to work well as a coreboot payload

Hi!  My name’s Robert Austin, and my GSoC 2010 project is to get TianoCore working well as a coreboot payload.   TianoCore is the open source component of Intel’s implementation of UEFI.  TianoCore on it’s own is not a BIOS replacement, but it can do some interesting things, and since a quite a few large companies are already committed to EFI, it makes sense to have an EFI payload as an option in coreboot.

I am very excited about working on this project, and working with the coreboot community.  I will make regular announcements about my progress here on this blog, and I will keep my working code available in a git repository here.  There isn’t anything there yet, but there will be soon.  To anyone who happens to checkout my code during the summer, I welcome any comments or suggestions relating to the style or quality of my code.  I want to write high-quality code, so feedback is appreciated.