Hi,
Maybe I missed it, but for the Open BIOS that is being discussed, is there a specific single board computer (SBC), motherboard, chipset (or ?) that the BIOS will be targeted on.
OpenBIOS is meant to be a clean Open Source implementation of the IEEE 1275-94 specification for boot firmware. The most well known example for an implementation of this standard is Sun's OpenBOOT or Apple's PowerPC firmware. Now, this specification mostly deals with interfaces and APIs between device driver roms (PCI cards i.e.) and the firmware as well as an API for a user interface and for operating system hooks. The IEEE 1275-94 specs describes FCODE, a forth based byte code language that allows option roms to be completely instruction set independant (CPU independant) Biggest win is the fact that an expansion card with such a firmware will work with all machines with an IEEE-1275 compliant firmware without any additional x86 emulation like on Alpha platforms. In fact, not having an Open Firmware compliant ROM on a PCI adapter breaks compliance to the PCI standard, which makes total sense. Even though firmware on x86 machines is flawed by design and simply not flexible enough for anything except booting DOS, you need a lot of dirty hacks in boot loaders to get decent systems working (ever seen lilo or milo sources?)
My understanding is that this will be an x86 board, and it sounds like it will be at least partly targeted toward the game industry. However, since my favorite language is actually solder, I am mostly curious. There are a lot of chipset options out there, and each one of these may have a different effect on the workings and architecture of the BIOS.
Chipset support can mostly be developed seperate from the base firmware system. Adding support for a new "platform" requires setting up ram controller, caching etc and initializing the machine so that the fcode evaluator can be started. The real chipset components support (onb. VGA/USB/Keyb/serial/tuning...) is implemented in platform independant fcode, which makes them run on any machine having such a chipset, according to the IEEE-1275-94 spec, even without the need to recompile it.
Incidentally, I would also recommend that you start with a monitor level input / output / short command structure. It really makes it easier to test code and eliminate problems when you have a basic (NOT BASIC) set of commands that you can use to look at or change control registers and memory locations.
At the moment we're developing a C compiler with an FCode backend and an FCode tokenizer, which will allow to easily work with the actual code. The final fcode evaluator will be able to run the tokenizer itself, so it will be possible to debug drivers directly on the firmware console if neccessary. I thought about writing a backend to gcc which outputs the needed FCode, but after following some politically/religious based discussion between the people who wrote the Java Bytecode backend for gcc (which is pretty similar to fcode) and RMS concerning the possibility to work around the GPL using a bytecode backend for gcc, this seems not to be an option. Second, I'd rather prefer not to use the suboptimal output that the gcc mid level language RTL produces (at least it's pretty unusable for stack machines as java bytecode or fcode is) Since written in C, these tools can be included in the bios for direct development (if they fit in the chip, which should be easily possible for any 256K+ flash device).
On new hardware projects, I also like to either get a serial port working first thing, or will hook up a small ASCII LCD panel to the system. That way I can see what is going on inside by using simple print statements, and can check to see that variables are what I expect, and that certain stages of the software are being executed.
Low level serial output as well as port 80 diagnostics work at the moment, allowing the most neccessary debug output.
For further information on these standards, don't hesitate to ask and please check out the links in the link section of the openbios homepage at http://www.freiburg.linux.de/OpenBIOS/
Best regards, Stefan Reinauer