OpenBIOS

Download

openbios@openbios.org

September 2003

1 participants
1 discussions

[announce] OpenBIOS Forth Kernel V1.0 released
by Stefan Reinauer Sept. 16, 2003

Sept. 16, 2003

Dear OpenBIOS community, After some months of development I am happy to announce the new OpenBIOS forth kernel "BeginAgain". It is available from the OpenBIOS CVS in the directory "kernel/" or at http://www.openbios.org/bin/kernel-1.0.tar.bz2 Features -------- - indirect-threaded forth engine - openfirmware user interface - small and portable - easily enhancable Platform Notes -------------- Currently targets for X86 PCs and AMD64 exist. The OpenBIOS forth kernel was developed using gcc on Linux systems. Minor changes might be necessary in non-linux/gcc build environments. Design Goals ------------ The design goals of "BeginAgain" were: 1) Portability 2) Maintainability 3) Small Size ---------------------------------------------------------------------- 1) Portability BeginAgain, with minimal changes, will work on new systems. There is support for X86 and AMD64 at the moment. Implementing support for new systems only requires adaptions to the start code and system abstraction. The current code has been developed using gcc 3.x, but no explicit GCCisms are used. Since gcc is the most widely spread compiler, it should be a good base for easily porting OpenBIOS to new platforms. 2) Maintainability The code is split into several parts: _________________________________________ | | | Forth dictionary | |_________________________________________| ^ | forth code ________|_________________________|_________ | | | v native code _____________ ___________________ | | | | | Scheduler | ----> | primitive words | |_____________| |___________________| ^ ^ | | | | _____________ ____________________ | | | | -->| Startup | | system abstraction | |_____________| |____________________| Platform dependent part ----------------------- a) After taking control the "scheduler", in forth context called "inner interpreter, reads the forth dictionary, a list of nested word definitions that are built using primitive words. b) These primitive words are written in C, so they take advantage of the compiler's ability to optimize code. They represent the minimum set of forth words that are needed to define all language constructs, including the Open Firmware system. c) The startup code is probably the most platform sensitive code. It's task is simple - get the scheduler up and running and provide a dictionary to execute. OpenBIOS provides multiple boot targets per platform. For example, on x86 it is possible to run the kernel either from Grub or LinuxBIOS. An additional target (available on all platforms) allows running the code from a Unix shell. d) The system abstraction part ought to be kept as small as possible. The primary words provide an interface for non-memory-mapped IO, and there's a small builtin console due to the fact that OpenBIOS has no device tree and/or drivers at the moment. Once these platform dependent parts are in place, they can be used to create an indirect-threaded dictionary file. This dictionary file contains a platform abstracted version of forth code that currently depends on the endianness and pointer (cell) size of the target platform. To keep the forth dictionary and the native code strictly seperate the unix hosted version of the kernel has a small builtin interpreter able to bootstrap all of the base system including a forth written interpreter, which represents part of the openfirmware user interface. In a second stage the advanced forth written interpreter is used to extend the bootstrap dictionary with additional features. As an example, ANS forth wordlist support is added, which will be used in the device tree code. Currently the OpenBIOS dictionary contains a nearly complete implementation of the Open Firmware user interface. It passes the Hayes ANS Forth test suite that is run when OpenBIOS is built, writing it's output to the file forth.html. Since the machine is abstracted as early and completly as possible, porting OpenBIOS to a new platform requires only minor efforts. 3) Small size The less code that needs to be adopted when porting OpenBIOS to a new platform, the quicker new ports can happen. Therefore the OpenBIOS kernel is really small. Here is a sample: size in | x86 | amd64 bytes | gcc 3.3 | gcc 3.3.1 -----------------+---------+---------------- multiboot kernel | 6724 | 15464 -----------------+---------+---------------- LinuxBIOS kernel | 7016 | 15896 -----------------+---------+---------------- LinuxBIOS kernel | | inc. dictionary | 27048 | 52920 -------------------------------------------- Installation and usage ---------------------- Run "make" to compile all binaries and dictionaries required to run the OpenBIOS kernel $ make Per default all binaries will be placed in the directory obj-{platform}. Then you can execute the kernel from a shell, by giving the command $ make run To boot LinuxBIOS from GRUB, copy openbios.multiboot and openfirmware.dict to /boot, then add a new entry to your menu.lst config file which looks like this: -------------------- 8< -------------------- title openbios kernel (hd0,2)/boot/openbios.multiboot module (hd0,2)/boot/openfirmware.dict -------------------- 8< -------------------- (hd0,2) is the equivalent to the Linux partition /dev/hda3 OpenBIOS can be used as a payload to LinuxBIOS (www.linuxbios.org) or booted in EtherBoot (www.etherboot.org) The simplest way is to use the kernel that includes the full dictionary: openbios.full Bug reports ----------- Any trouble, bugs etc. should be reported to the openbios mailinglist <openbios(a)lists.openbios.org> Further Development ------------------- BeginAgain is pretty much complete now. Expect only bugfixes and optimizations in the future. Interpretation mode versions of most loop constructs should be included although they are not really needed to get more development going. The next steps in writing an Open Firmware implementation is to complete the Device and Client Interfaces. These two parts are needed to set up a device tree, initialize hardware, and boot the operating system. Once there is a device tree and some basic device interface functions it will be possible to run fcode drivers for device initialization in OpenBIOS, using the FCode evaluator that resides in the OpenBIOS CVS directory forth/evaluator/. Regards, Stefan

1 0