Data Scientist at Alert Logic, Founder/Director at Farset Labs
So as part of my IAESTE placement with PC Engines, I’m investigating the possibility of them making a new board based around the AMD Fusion series of APU’s (CPU+(something else, usually GPU) on single die) and for that board to work with the Open Source Coreboot BIOS. This is my story.
I am not a hardware guy, and have never done any pre-OS x86 hardware programming. This will bore the pants of anyone who is an x86 expert, but hopefully some will find it useful and will contribute to the Coreboot project.
Part The First: Intro
My particular board (MS 7698 / E350IA-E45) is not supported by the Coreboot project (yet), but after some investigation, most of the components on the board are, so in theory it should be a case of chopping existing board definitions up and reusing them to make my life easy (that’s always the dream)…
But first, some explanation of whats going on.
I’ll skip CPU for simplicity, but the chipset usually consists of two devices; north-bridge and south-bridge. (Note: I’ve had 5 years of electronics and software education and this project has taught me more about computer architecture than any of that; the case for open source dev work in universities?…).
Put simply, North-bridge is a blisteringly fast (many Gbps) interconnect between the CPU, main memory, and (usually) graphics adapters. Since as we’ll see, this interface is largely interal, one doesn’t need to do to much to ‘wake up’ the Northbridge specifically.
The South-bridge on the other hand, is usually a hundred Mbps, and handles almost all of the ‘lower rate’ interfaces such as PCI, IDE, SATA, USB, etc. Of particular interest is the LPC Bus, shown in the diagram. This Low-Pin Count interface connects the South-bridge to not just the BIOS, but also, to the SuperIO controller.
The SuperIO device looks after a range of low-bandwidth, low level interfaces like Serial, etc.
Now, that’s simple enough when you’re thinking in a CPU-centric perspective; if the CPU needs to send something out the Serial port, it hands it to the NB, which passes it to the SB, which sends it out the serial port via the SIO. Simples!
But what happens when you push the button on the front of your machine? Peter Stuge does a good introduction to this (and Coreboot in general) in his CCC26 Talk, but the long story short is that the power switch wakes up the BIOS; the BIOS wakes up the SIO and (hopefully) the SB, which in turn wakes up the on-board controllers and the NB which eventually initialises the memory controllers, CPU, and all that good stuff. (Peter does a much much better job at explaining this than I do…).
And there in lies my problem: guess which part of this ecosystem of components is currently completly unsupported by Coreboot? The first thing the BIOS touches… the SIO.
Incoming Ranty bit, feel free to skip
This means that if I take the stock Coreboot ROM for a board that is fairly close to mine, it falls at the first hurdle and is completely useless.Oh, and to make matters worse; the chipset on this particular board does not allow booting off LPC, so the nice fast flashrom-to-second-LPC-chip doesn’t work (I discovered this after soldering three different TPM/LPC adapters…), and instead I’ve had to desolder the SPI BIOS off the motherboard, reset it in a chip holder and use a universal serial programmer, which is slow as all hell…
Anyway, after discussing with the very helpful #coreboot IRC channel, they suggested that I first work on getting the SIO recognised by (the even more unsupported) SuperIOTool, which queries device registers on the SIO and compares them against known ‘default’ values. Thats the next fun project, but I’ll leave it at the for today…