[OpenBIOS] Platform for the OPENBIOS question

[Stefan Reinauer]

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 

-- 
Mad, adj.:
        Affected with a high degree of intellectual independence.
                -- Ambrose Bierce, "The Devil's Dictionary"
-
To unsubscribe: send mail to majordomo at freiburg.linux.de
with 'unsubscribe openbios' in the body of the message