Tag: GSoC

flashrom supports PowerPC and MIPS

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.

Continue reading flashrom supports PowerPC and MIPS

Nvidia MCP6x/MCP7x SPI support merged

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.

Continue reading Nvidia MCP6x/MCP7x SPI support merged

RayeR SPIPGM support in flashrom

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

Continue reading RayeR SPIPGM support in flashrom

First successful Nvidia MCP6x/MCP7x SPI access

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

flashrom progress report #1

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

Payload infrastructure

hi i am Cai Bai Yin. And my GSOC 2010 project is Payload infrastrcuture. The main job may including adding payload build support to the coreboot kconfig and crossgcc build which would make the project as an whole. if time permit, some filo improment will aslo be included.

I am a freshman to coreboot. But i am trying my best to do things better. There may be lots of tough probems stay in front of me. Hope i can deal everything well. I will aslo try to learn as much as i can from the others.

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.

AMD 780 mass porting

It is my second year to join GSOC. In this year, i will take in charge of AMD RS780+SB700 mass porting. I would like to write down each progress here between this summer.

Today, the dediprog ISP-Testclip-SO8 has arrived. although it’s pretty expensive, but it seems pretty cute. I have already tested in in BTDC lab, hope it can helps me much more.

USB development for this year’s GSoC

After starting the USB stack in libpayload in the Google Summer of Code of 2007, I’m back this year to implement some more drivers. So far, we support UHCI Controllers – that is, USB1.x on Via and Intel chipsets.

There are also patches to support OHCI which are under GPL licensing As libpayload ist BSD-licensed, this make it unsuitable for inclusion. So this year I’ll do a clean implementation of OHCI to get this matter settled.

With this, all USB1.x controllers except for some very rare pre-standard controllers will be supported. This also includes USB2 boards, which means all current mainboards out there, as USB2 simply requires “companion controllers” (which are usually OHCI or UHCI) for USB1 modes.

After this is done, I’ll start on USB3 support. USB3 is still relatively new, but there are two reasons to start working on it:

  1. USB3 will be more popular in the next years, so doing it now ensures that we have one issue less to care about.
  2. Unlike with USB2, xHCI (the host controller standard for USB3) doesn’t use the companion concept, but requires the controller to support USB1 to USB3 itself. This means that old drivers (for UHCI, OHCI or EHCI) won’t find any controller to work with on such boards.

Implementing OHCI and xHCI ensures that all current boards as well as those of the near future will be supportable by libpayload and its users.