Greetings. I've been talking about it for a while, and I've gotten a few people excited, so I figured it was time to actually release something useful.
I believe that there is a lot of power in coreboot for AMD customers, especially in the embedded market which my team supports. Part of that power is in the low cost and high visibility of the open source code, but also in the flexibility of the payload model. Now, for a very low cost a customer can get not only the hardware initialization, but also an blank page where they can add their own special, be it a fully fledged payload, or just an intermediary before loading an operating system.
This is where libpayload comes in - it abstracts away the icky bits of payload initialization, and gives the user a semblance of a normal C library that they can use to develop a payload without having to worry about re-implementing malloc() and printf() and all the other usual friends.
I am happy to release the first proof of concept for libpayload:
http://coreboot.org/~jcrouse/libpayload_0.1.tar.gz
This is a conglomeration of code from three projects - the payload initialization code from FILO, superb curses code from our good friend Uwe Hermann, and various libc and driver bits from coreboot-v3. I combined them together into a library, mixed kconfig into the mix and baked at 300F for 2 hours. This is proof of concept code for the most part, and I wouldn't go off and put this in your airplane autopilot quite yet, but its a good start.
And to celebrate the good start, how about something practical to go with it? Here is something I call coreinfo:
http://coreboot.org/~jcrouse/coreinfo_0.1.tar.gz
Coreinfo is a curses based payload that outputs lots of information about the CPU and system. Or rather, it will - for now it just shows the cpuid of the processor, and has a rather slick PCI device browser. The most important thing is that it shows that libpayload can be used for a relatively complex payload without really breathing hard. Here's a screenshot:
http://coreboot.org/~jcrouse/coreinfo_screenshot.png
So, please, enjoy. Flame me as needed, and once everybody has digested this for a bit, we'll meet back and discuss what the next step is. Obviously, I think more libc functions are needed, filesystem support is useful, and maybe even graphics are in our future.
Jordan