GSoC project: Coreboot panic room. Diagnostics (also remote flashing)

I’m very excited to announce my GSoC project which is intended to bring some light for coreboot users. To begin with, I would like to introduce myself. I’m 20 years old student living in Lithuania. I’m studying Informatics Engineering at Kaunas University of Technology. This year we have two interesting modules here: one about operating systems and the other is introduction to computer architecture, which is crucial for learning coreboot. Some time ago I have played with avr microcontrollers, so I have good soldering skills. One day during my free time I thought:

What the hell my old computer’s bios is so badly written that it can’t boot from usb flash and it can’t suspend correctly on Linux? I have a laptop that is running bios stuff more time than the old computer. I thought I can’t live with that and then I found coreboot 🙂 I was very excited that it was so configurable, so open alternative 🙂

Not to waste time on cheap talks, here is my project:

To help developing coreboot code, we have to set-up remote diagnostics (also flashing) interface in coreboot. We will be a able to renew bricked board through serial port or even do some research through registers in case of panic(). This will enable easier development of CAR, chipset, payloads code.

Abbreviations used later:
TARGET – machine running coreboot;
HOST – machine running serial port application, connected to TARGET through serial port
The platform that I will use for development is traditional x86. In case coreboot is supported on ARM, I will be hapy to buy one board to make my code working on both platforms.

 

There will be a diagnostics shell, similar to Serial ICE (or LLshell). Invocation of the shell may occur at any time (when we have (cache or ram) memory or not). It would be invoked by (we should discuss this):
1) serial port data received interrupt (HOST triggers diagnostics mode)
2) if user specified it in code (we may add something like checkpoints in coreboot’s code where TARGET will send command through serial port to HOST and if receives the answer – it enters diagnostics mode)
3) in case of panic() invocation (or something like die())

 

In that shell’s loop we will be able:
1) to run the code instructed through serial port (like Serial ICE): manage register contents, do some research or even like Carl-Daniel suggested to initialise CAR
2) to flash memory through serial port, when we have some memory (CAR or RAM) initialised. Some generic flashing code will be pumped through serial port to memory and then executed.

 

Some small specific goals:
1) analyse different code handling schemes in cases of memory we have (no memory, CAR, RAM)
2) define how Serial ICE will be integrated to coreboot
3) integrate defined Serial ICE stuff to coreboot as our new shell
4) add memory handling funcions to our new shell (for checking how much memory we have, and if we have – for uploading code to memory)
5) analyse flashing protocols
6) develop uniform flashing scheme (for SPI, parralel flash…) define what commands are required, where these commands should reside.
7) make serial port application for HOST (maybe we will use flashrom’s serprog code, it might require enhancing)

 

These are just milestones, some points may change after deeper investigation, when we will have something done.
We may experience the risk of problems in different operating modes when having different memory (no memory, CAR, RAM).

 

Yesterday I was looking at flashrom sources. People have done very good job in preparation for porting it to libpayload. Maybe I should concern making a complete flashrom port on libpayload?
Anyway, thanks for reading about my project. You are welcome to post some comments (maybe on the mailinglist). Your experience would be helpful.
Thanks to our mentors for their patience 🙂

AMD commits to coreboot

Kevin Tanguay at AMD writes about AMD’s focus on coreboot.

 

Finally, AMD is now committed to support coreboot for all future products on the roadmap starting next with support for the upcoming “Llano” APU.  AMD has come to realize that coreboot is useful in a myriad of applications and markets, even beyond what was originally considered.  Consequently, AMD plans to continue building its support of coreboot in both features and roadmap for the foreseeable future.

 

This is great news for coreboot and I hope to see some announcements from other vendors on their coreboot offerings later this year.

FOSDEM 2011 photos

I just found out that nobody wrote a few lines about this year’s FOSDEM 2011. This year we had a booth (aka a “table”) in one of the buildings. We had total 4 speeches. I did one lightning talk about the coreboot and x86 init (video) and a lecture about coreboot and its speed. Carl-Daniel Hailfinger had lightning talk (video) and a talk about RAM Cold Boot Attacks The talks had a great success and a lot people attended. Continue reading FOSDEM 2011 photos

u-boot as coreboot payload

U-boot is bootloader on ARMs, PowerPCs and other platforms, it has a nice set of commands and in general it feels like a small operating system. I’m not certainly sure if it is good direction, please feel free to compare with UEFI 😉 but I simply miss it on x86. I work at SYSGO with u-boot in daily basis and even port it to different boards/platforms. The x86 is no easy to init and I think this is the reason why there is only one x86 board in whole u-boot tree. This board is called eNET and it has a AMD ELAN SC520 SOC. But luckily, with coreboot we can init much more x86 boards and this leads to natural conclusion to have the u-boot as the coreboot payload. I would like to share with you part of this “fantastic” hacking journey to make it happen. Continue reading u-boot as coreboot payload

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 identi.ca 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://gitorious.org/openbiosprog/openbiosprog-spi.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

  http://randomprojects.org/wiki/Openbiosprog-spi

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.