Check out the article on Phoronix.

coreboot was not selected to participate in GSoC 2012. This is
disappointing new for the project. I do not know why we were not
selected this year. I will attend the post selection meeting to see
what we can do to improve our chances of selection next year.

Students, thank you for your interest in coreboot. We are happy that
you are engaging with our community. I hope that you continue
exploring your interest in coreboot. Please let us know what we can do
to assist you in your learning.

Feel free to send me questions, comments, or concerns.

Regards,
Marc

http://google-opensource.blogspot.com/

Flip bits, not burgers!

coreboot is applying for Google Summer of Code 2012. We are currently
looking for mentors, project ideas, and prospective students.

Please visit the coreboot GSoC page: http://www.coreboot.org/GSoC

Students:
Prospective students should join the email list and join IRC #coreboot to
get familiar with the coreboot community. Please forward any potential GSoC students
to the coreboot GSoC page.

Projects:
We are interested in all types of projects that support coreboot,
including payload and infrastructure projects.
If you have project ideas please post them here:
http://www.coreboot.org/Project_Ideas

Mentors:
We need mentors! The more qualified mentors we have registered, the
more GSoC projects/students we can support. We will match students
with mentors once the student proposal phase is complete.  If you might like to be
a mentor, please register with google and add yourself to the mentor
list on the wiki.:
http://www.google-melange.com/gsoc/homepage/google/gsoc2012

Please feel free to contact me by email or in IRC #coreboot if you
have questions.

Regards,
Marc

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

As on any other system, best would be to get some datasheets describing in great details everything about the system. Luckily Prochip, Russian company offers on FTP quite complete SDK even with the GPL redboot sources together with JTAG tools datasheets. The board has 64Mbit flash soldered, and of course producing a little brick is always an option.

Internally the system has PCI bus with USB, Network and NB and SB. Checking the redboot sources it turns out that system initialization is actually quite simple. Setup few registers for memory enable timer1 for system SDRAM refresh, enable flash decoding (chipselect). On SB front, just assign IRQs to PCI routers and USB and network and possibly enable the ROMCS write decoding. Yeah and just set level/edge in ELCR and write BIOS IRQs into the PCI registers. Plus assign few PCI BARs for EHCI/OHCI and network and set serial to internal decode and you are done. No need to worry about the CMOS because there is none.

I have taken the emulation/qemu-x86 as the base, because I really did not need any fancy structures, all initialization is just couple of PCI writes. It is still unknown if CPU can do CAR setup and this target uses romcc. First thingie to do was implementing a bootblock.c which enables whole decode of flash rom. Second step was to fill all init into the romstage.c. Third step was to fill the PCI BIOS IRQs in ramstage as well as filling the system resources like maximum RAM size and PCI MMIO and IO regions.

Ready to flash and boot. Flash but how? The biffboot enables flashing everything except the last 64KB of itself and flashrom has no support for this system (yet). Also I did not want to have a pernament little brick and the bifferboard has a JTAG connector and schematics for the JTAG, which is just buffered Xilinx parallel cable. You can even buy a debrick set (hw + sw) on the bifferboard page for 20 quids, but it would mean to purchase it separately and nearly with the price of whole system.

I did a soldering and produced a JTAG adapter which agreed with schematics and was on purely software side again. The RDC Loader is a Windows application which can be used to flash stuff using the JTAG. My flash was not listed, but there were some similar which gave me hope that could flash it. Now what? I examined the RDC DLL and found out that in Windows 98 version it was doing straight port 0×378 IO. Great time to write a short iopl(3) / ioperm wrapper and run the wine emulator on second coreboot board with parallel port.

With everything ready there was a time similar to big bang, the first try of everything. First connect JTAG and double check all wires, then check again, because if magic smoke escapes out of the chips (which was added there during manufacture process apparently) the magic would be broken and would leave me very sad. Now power on, magic stays inside chips.

Now run the wine wrapper with the application. It does not complain about unconnected JTAG… scan the PCI bus… oh it works! A flashing time! It takes long to move a progress bar but still something is happening. Ah it worked too! Now do reset and run… Yes coreboot is here, and it seems to die quite at the end where all tables are being generated.

It prints just couple of strange letters as last message. I knew what it was. Of course it was just GDB protocol. I seem to get some exception and we still have GDB enabled as default. I really need to push a change to turn it off to receive human readable exception at first. Now re-flash with gdb disabled and check again. Exception 6, unknown opcode 0f a2.

Examing the fail address with objdump we see the culprit immediately. It is the cpuid in the SMBios tables generator (CPU table). Yeah I believe not many 486 had CPUID, lets disable quickly the SmBios tables and re-flash. Boots gets a bit further and it seems to die inside the SeaBIOS.

Now what? I checked the resources and realized that I forgot to add flash resource thus making PCI devices memory BARs overlap flash memory. Same happened for IO ports which overlaped legacy resources, but it still hung. Luckily the JTAG is also an integrated debugger. There was still couple of places in SeaBIOS with CPUID stuff, and one particular hidden in the header which took me some time to find. But it still does not work.

Failing instruction 0f 31 RDTSC. Now it gets interesting. SeaBIOS seems to calibarate the TSC using timer2 and uses TSC for the timekeeping. Rest of the evening is spent to rewrite this using just low accuracy timer1. Late in the night I got “No bootable devices found” which sounds as the best error message I could get! (Yeah Sven likes that too).

Next evening it is a boot Linux time. I want to boot from USB stick (which is not possible from biffboot) using syslinux to boot some custom compiled kernel. SeaBIOS loads syslinux, it loads kernel and… nothing.

JTAG is quite handy… HLT quite early not even running in 0xC0000000 range. I forgot to mention that I tried to load bzImage, most likely it fails in that pre-boot stage. I study the kernel sources and realize even if I enabled early printk’s they go to INT 10H which means I cannot see them.

I quickly hack the function to send it to serial and got this back:

Unable to boot – please use a kernel appropriate to your CPU.

Hm even if cross compiled with ARCH=i386 the menuconfig default was i586. Fix it. Boot again. Linux complains about missing FPU. Oh really a CPU from the past. Turn on FPU emulation in kernel boot again. And nothing again. JTAG came handy again and it fails with invalid opcode again. This time a CMOV instruction. It seems a misc.c file misses -march=i386 and gcc is using CMOV there. After fixing this I got kernel to boot ending with kernel panic.

Something wrong with interrupts. Linux complains that it is unable to route IRQ for OHCI/EHCI and I intended to use USB as rootfs. After short research I realize coreboot writes 0 to PCI 0x3c (BIOS IRQ reg) and I really need to call assign_pci_irq in the ramstage.

After fixing this system finally boots. Sunday trip to visit the parents is partly a flashrom time too, making myself present in living room and not watching TV and hacking flashrom instead (during evening hours again). Afternoon spent fixing sisters car central lock system and fixing unrelated parents radio remote controller. Yeah hacking time all around the clock. Back to flashrom again.

Rule #1 make sure your datasheet matches your chip. I googled the datasheet and found some different one and I even check if the chip’s name under a sticker on board matches. After some time in desperate move I google for full chip name again with last “B” included.

It turns out that the B/T variant of EN29LV640 is something completely different. The chip has a standard JEDEC command set but requires word access (16 bit) for that. The 8bit mode with BYTE# signal grounded is used on bifferboard. The chip probing worked with 8 bit mode and erase too. I even managed to erase the chip. But unable to program anything. The JEDEC toggle bit toggle for eternity and examining the dumps I managed to write first nibble of the byte programmed and also second byte is zero… It sounds fishy but I tried many different things but still no chip programming. Late in the evening I found some kernel module which has biffboot config space writes and they use the 8bit sequence, BUT the programming is in WORD mode, programming two bytes at one.

Fixing flashrom. Verified. Fixing flashrom again, because this “B” variant has non-uniform sectors at the start of the flash.

Now what? Xvilka is working on Vortex86 which is much faster x86 SoC from DMP, but it seems that it has very similar NB and SB. Most likely merging a code is a option here. As for the SeaBIOS programming TSC emulation using timer2 could produce better timming functions even without TSC (task for near future maybe).

As the ultimate goal, maybe reviving the coreboot + u-boot from last April would be nice option here.

More pictures and bootlog.

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.

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.

Dear Intel employee,

I’m sorry to trouble you, especially because this mail is addressed to many people, sorry.

You have been addressed, because you were involved in doing related Linux kernel development or had already direct contact with Carl-Daniel Hailfinger, the main author of flashrom at FOSDEM and may have a good understanding of our situation regarding development and access to information and datasheets from Intel.

I am one of the maintainers of flashrom (http://www.flashrom.org/), a utility for identifying, reading, writing and erasing flash chips via various programmers including a number of Intel’s chipsets. Our tool is used by some computer vendors (e.g. Google, General Electric, Bull, Packard Bell) internally and it is also given to their customers for updating the firmware/BIOS.

1) With the release of the ICH8 (82801H*) a new feature named Soft Straps was introduced. The ICH8 datasheet describes it like this: “Soft Straps are used to configure specific functions within the [chipset] very early in the boot process before BIOS or software intervention.” As part of the SPI chapter the datasheet also lists the meaning of those bits which include switches to disable functional blocks or reroute various pins. In later chipset series they were no longer published publicly, but only in confidential documents (SPI Programming Guides).

I am currently working on dumping these in an open source utility and would like to add parsing and printing human readable interpretations. Therefore i would like to ask for the necessary documentation that lists the meaning of the Soft Straps of all Intel PC chipsets since ICH8.

2) Another thing i am working on is enabling flashrom to update the firmware of modern Intel platforms. This is currently often impossible because there are some protections against unintentional or malicious modifications. This has the drawback that there is no easy and safe way to update Intel based mainboards on operating systems other than DOS(!) and Windows. We know that is possible to tell the ME via HECI/MEI to suspend its write activities and unlock its region to allow the main processor updating it, but we do not know the details of such a communication transaction (neither the MEI address of the “unlocking service” nor the content of the message nor the expected reply). We also do not know how to proceed after that and if the unlocking is reflected in the “protected range” registers. It is also not known to us how to unlock other regions (the descriptor region itself is often configured r/o… which may not be a problem if it should never be updated?). Any information regarding unlocking flash regions would be appreciated.

Thank you.

–
Sincerely, Stefan Tauner and Carl-Daniel Hailfinger

It is of course easy for small FOSS projects to bash big companies for subjectively experienced injustices, but Intel—although always emphasizing there open source engagement—really is not as open as it would be needed to have good flashrom support on their platforms. This is not only a problem for long-haired free software enthusiasts (like myself), but also for businesses. Just yesterday we have received another mail from an employee of a multinational major corporation (over 250k employees) that asked for our help, because they would prefer to use flashrom instead of Intel’s DOS/Windows tool to develop their Cougar Point based devices. The secretiveness does harm Intel, us and humanity as a whole. I rest my case.

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 warning at the user unnecessarily.

I’ve been also working on rebasing, improving and reviewing (very) old patches of others whose discussions just stopped (for example when contributors did not send improvements). My hope is that this will help us shorting the long patch queue, but i doubt that it will suffice

To conclude (or begin) my recap of my GSoC involvement this year, i’d like to first thank google for doing this. This sounds quite pathetic, especially if one knows me better. But it really got me involved in FOSS development with the intensity i wished for (by providing a monetary motivation to get really started). There was some involvement in the past (bug reports and fixes etc.), but flashrom was apparently a nice target to get more involved and learn a lot, not so much about REing and technical details (as i expected and hoped in the beginning), but regarding project management in FOSS (my own proposal, but also flashrom and its patch queue/processing and “upper management’s” free time constraints), interacting with contributers and users, and mastering git (the latter is quite ironical because flashrom does not use it (yet)). It’s a bit sad, that flashrom does not have more contributers (especially reviewers). This is obviously a problem and it might be the time to discuss the development process as a whole. The question is with whom should i discuss this if no one is there

Although my formal project will not be finished on time, i think i have served the flashrom project well and from the feedback i received so far, Carl-Daniel is also happy with my work. So i think i can declare it as successful after all and i would like to thank everyone involved (so far).

My project progress is really slow. As Marc suggested I have done some work to reduce stack usage: wrapped functions to read and use file by 256B peaces (somewhat default granularity). But that still needs testing and cleaning up. Also I need to cleanup my previous work that I haven’t submitted to the list, which enabled running code in car (even though not completely working, as mtrr settings might be wrong or more problems still there).