coreboot developer blogs

I’ve started that port in November 2011, and made it finally working in January. Well, at least working on my Supermicro X7DB8 Board. Compared to the vendor BIOS which takes about 30 seconds from power-on to grub, coreboot finishes the same task in 3s. Unfortunately the VGA BIOS takes about 2 seconds to program the register to do 80×25 resolution, so eventually we end up with 5s. If you don’t need a VGA console, and prefer a serial console, you can save even these two seconds.

Actually i didn’t expect the port progressing so fast. One tool that was a great help was serialice. I used it to watch the original BIOS initializing memory. To get serialice running, all you have to do is writing a few lines of board specific C code, which initializes the serial port and some basic chipset parts required for accessing the serial port registers. On the host side, a patched QEMU is running, executing the vendor BIOS while redirecting HW accesses to the target computer. Which HW accesses are redirected can be configured by a small lua script. LUA can also be used to pretty print the output from serialice. So with a bit of hacking i had the following output from serialice:

pci_mmmo_read_config32(PCI_ADDR(0, 16, 1, 0), MC) == 0x0040000;
pci_mmio_write_config32(PCI_ADDR(0, 16, 1, 0), MC, 00040000);
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, EI);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDHPC, STATE_INIT);
pci_mmio_read_config8(PCI_ADDR(0, 21, 0, 0), FBDST) == 0x10;
amb_smbus_write_config32(0, 1, 0, 1, AMB_FBDSBCFGNXT, 0x20b1b);
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDSBTXCFG0, 0x05);
pci_mmio_write_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBTXPAT2EN, 00000000);
pci_mmio_write_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBRXPAT2EN, 00000000);
pci_mmio_read_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL) == 0x1000032;
pci_mmio_write_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL, 00000012);
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS0);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS1);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_read_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL) == 0x0000016;
pci_mmio_read_config32(PCI_ADDR(0, 21, 0, 0), FBD0IBPORTCTL) == 0x0000016;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS2);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_read_config8(PCI_ADDR(0, 21, 0, 0), FBDLVL0) == 0x14;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS2);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDICMD0, TS3);
pci_mmio_read_config16(PCI_ADDR(0, 21, 0, 0), FBDISTS0) == 0x1FFF;
pci_mmio_write_config8(PCI_ADDR(0, 21, 0, 0), FBDHPC, STATE_READY);
pci_mmio_read_config8(PCI_ADDR(0, 21, 0, 0), FBDST) == 0x20;
pci_mmio_write_config16(PCI_ADDR(0, 21, 0, 0), AMBPRESENT0, 0x8FFF);
pci_mmio_write_config16(PCI_ADDR(0, 21, 0, 0), AMBPRESENT0, 0x8FFF);
MEM:  readl AMB_ID => 0482111d *
MEM: writel AMB_FERR <= 00000009 *
MEM: writel AMB_NERR <= 00000009 *
pci_mmio_write_config16(PCI_ADDR(0, 21, 0, 0), AMBPRESENT0, 0x8001);
pci_mmio_read_config32(PCI_ADDR(0, 16, 1, 0), MC) == 0x0040000;
pci_mmio_write_config32(PCI_ADDR(0, 16, 1, 0), MC, 40040020);

As you can see, this almost looks like C code. Even if it looks like porting coreboot to this chipset should be simple with that level of output, there where some challenges.

First, i5000 uses FBDIMMs. Each of the memory modules contains an AMB (Advanced Memory Buffer) in addition to the memory chips. This AMB has to be initialized and trained during the Memory initalization sequence. So you have three things to setup right to get working memory:

• The Northbridge (MCH in Intel’s terminologie)
• The AMB
• The memory chips on the module itself.

The training sequence is needed to account for the high bit rate used on this communication channel: stuffing 12 Bits into one Clock cycle at 166Mhz. But even if it makes initialization more complicated, the AMB can be really helpful during development. It allows to test the Memory chips without help from the MCH, so you can test if the memory module itself is working without having to rely on MCH setup. We’re (and the vendor BIOS does as well) are using it also for clearing the Memory during initialization. But we made one difference: The vendor BIOS clears the memory modules one after another, while the coreboot code sends the command to clear the memory to all modules at the same time, and collects the status response afterwards from all modules. This has the advantage of requiring only the time the slowest module needs, instead of the sum of all modules.

I spent several evenings investigating why Interrupts were not working, just to discover that i accidentally reset the Busmaster Flag on the Northbridge. This had the effect of having Interrupts in Virtual Wire mode, but not in APIC mode. After fixing this nasty bug, linux was booting properly, and i even had a working keyboard and mouse

Having i5000 code in coreboot, i’m aiming at supporting the following Boards in coreboot:

• Supermicro X7DB8(+)
• Asus DSBF-D12 (i have this board in my Desktop  Box)

There are also a lot of HP/Dell/FSC servers out there using this chipset, which might also be a nice target. Unfortunately i don’t have such hardware at home

Ever heard about the bifferboard? It is a small RDC x86 SoC with 150MHz 486 compatible CPU, 8MB flash and 32MB RAM, ethernet and TTL serial line and a few GPIOs. It comes with very tiny loader called biffboot. Quite natural target for coreboot and u-boot. My flatmate purchased one but never had actually time to do anything with that so here it comes. (more…)

We are starting to see coreboot in more shipping products this summer and I expect even more in the fall. The exciting thing is that coreboot is becoming a piece of technology that vendors are starting to advertise. A recent example is the Portwell PCS-8277:

PORTWELL ANNOUNCES REVOLUTIONARY IN-VEHICLE PC
WITH THE BOOT SPEED OF AN APPLIANCE New PCS-8277 telematics system based on Coreboot® technology with HD graphics processing engine 

I think that we are starting to see vendors and customers becoming more knowledgeable about what is going into their products and how coreboot is an advantage in many situations. I hope to see more announcements in the coming months.

Yeah! it`s came the time to write another report on GSoC status. In fact I`ve – intentionally – postponed it for quite some time and it doesn`t exactly mean there was a lack of informative emails between me and Marc(my mentor).

The need to finish some stuffs justifies – in some ways – the aforementioned delay. I understand you don`t need to report you aren`t done with something, a mail stating “I`m not done yet” would be enough - well, maybe not anyway…

OpenEmbedded Journey

With the second half of my project I jumped in the OpenEmbedded ecosystem and believe it, I`ve loved to get in touch with.

Putting my hands on OE is something I`ve planned for some time, I just hadn`t had the time to do so.

OpenEmbedded is something amazing, and it does what I realized years ago when I worked with gentoo. I always saw gentoo as a great meta-distribution, something you can bend and forge as you need – customizing it according to your needs.

Despite all the conceptual things touching OE wasn`t as easy as I initially tought it would. Bitbake(the great maestro behind OE) was designed with portage in mind and theoretically it was I good advantaged to me – look, theoretically.

Nothing is exactly smooth as you plan, you`ll always get troubles in the way – with OE wasn`t an exception.

OE transitions and yocto project

One of the biggest problems I faced was mainly due the transition the OE project is getting through. The docs(Getting started wiki page for example) are out dated and you get conducted by the old code base, and trust me, it`s not a good way to get started.

My first two weeks was full of crazy hacks, searching for old tarballs, setting up local source repositories, doing everything I could to make that thing to work – it was a bad race doing my best to proof the howtos.

The true is OpenEnbedded has moved to what we name bblayer, it`s a bitbake feature to ease to extend a base system. The intention(as I see) is to keep a minimal, clean and stable set of core packages and yet make it possible to “third party” vendors to append it to fit their needs.

The yocto project has extensively used OpenEmbedded as their base system, both the projects have exchanged a lot and sometimes you loose yourself if you`re touching one or the other. One of the tools provided by yocto project is Poky – which`s actually an OE layer.

There isn`t plenty of docs describing how the bblayer and bbappend work – the bitbake docs aren`t much precise and the OpenEmbedded barely mention it, yocto just describes how it`s fit within poky(or something close to that).

I would really like to recommend newcomers to first play with poky then later consider starting a new third-party layer.

The project as a bblayer

A third party layer is what best fits my project, not exactly a full yocto/poky layer, maybe and extension of it or not even that but an own layer itself, to accomplish that I had to experiment a lot, setting the environment up and watching how everything get together.

Packaging

After many years not touching a single ebuild and having never touched a bb package I jumped in the task to pack some components. The spice client has a bunch of dependencies – of course, I hadn`t to pack everything myself, a great number of things were already done.

Among the things that got me longer then I expected was cyrus-sasl, the old OE tree had it packaged but it was an old version – should I mention it was broken as well?

So, bringing the recipes wouldn`t be enough but I would have to fix things up, once fixing stuffs was the only alternative I decided to upgrade it to the latest version 2.1.31.

Anyway, it brought me a lot of work to pick patches to fix its building and fixing what hadn`t got fixed already. My final PR was 177 what means I came through 177 builds, debugging, testing and working everything around.

The cyrus-sasl code has a bug introduced after 2.1.21, it wasn`t possible to build it –with-static. I did an ugly and ridiculous fix. Everything I found out there – searching the internet – was even uglier. Suggestions to run make twice was one of them. The build system was kind of messed up.

The other packages weren`t so painful and I could quickly move forward.

Slimming the image

I still have to slim few things, I need to cut some X11 packages I included in the image, append the yocto kernel with my own .config and write a small shell script(or something smarter than that) to launch the spice client.

BuildRom

The first thing I worked on in the beginning of my project was buildRom, I wanted to bring all the tasks involved on building the OS image and bios/firmware into to it. But, with my move to OE for building the OS image I realized I could go the reversed way and bring the tasks for building the bios/firmware to OE.

Now I`ve manually packaged the things but have already started to write bbclass to controll bios/firmware + image building and packaging them. I see it as a second generation to BuildRom project, a OE layer with coreboot bb packages and recipes plus the needed bb classes.

Conclusion

After the great effort I had, getting in touch by the first time with OE, I feel comfortable to say it was a good experience to me, I realized many possibilities. I`m really happy with everything I learned on the path and I`m sure I still have a lot to contribute to Coreboot and OE as well.

As mentioned in my GSoC recap, Carl-Daniel and i have sent a letter to Intel to get more information regarding the descriptor section and unlocking the ME flash protection (my official GSoC main project). It was sent about 3 weeks ago (2011-07-29). No reply was received so far. This is the whole message we have sent them: (more…)

Final evaluation deadline for this year’s GSoC is in 2 weeks. Most of what i have written in my midterm evaluation is still valid.

We have formulated and sent an email to various Intel representatives in the hope to get at least a few hints regarding ME unlocking (and descriptor semantics). I had the idea to send them a mail earlier, but thought it is an ludicrous attempt from all i have gathered regarding Intel’s cooperation with coreboot. Carl-Daniel suggested giving it a go anyway and it provided me a good excuse to not work on REing until we get an answer. Of course we have not received any reply to date

So i think it is quite clear that my main GSoC project will fail to be delivered on time. But i won’t vanish after GSoC and i still plan to implement ME unlocking eventually.

What’s up besides the GSoC project?

The integration of my patches still lacks reviewing power. Everyone but Carl-Daniel seems to be not much interested in my work and he has not the time to look at everything i produce. Right now flashrom has about 150 patches requiring some action to merge them. Thereof are 41 from me (TBH there is a number of patches that are just rebased and improved a little bit) and 37 from Carl-Daniel. meh.

With the help of Florian ‘florz’ Zumbiehl i was also able to find, fix and report a bug in dmidecode which has direct influence on flashrom. Due to an error in decoding the chassis type in dmidecode, flashrom falsely declares some boards to be mobile devices, which makes it shout a big s of code.

As stated in my midterm report I’m working this first 2 weeks after midterm to work on building the payload image. I wanted to hardcode everything but we(my mentor and I) understood it would be better to use something like OpenEmbedded for that.

 
This first week I studied OpenEmbedded. I tested many distributions starting with angstrom, they showed too heavy for our purpose. After those tests I found micro and realized it would be a better start.

 
With that I’m working around micro to build our own distro, I’m adding X11 dependencies and right now I’m packing the spice client and its dependencies. In the end of the week I must have sorted every details.