Next Previous Contents

4. Software solutions for your Linuxbios

When I started working on this project, I wander around to see different possibilities to build a free bios. The first question was thus indeed : what type of free bios GPL'ed source codes are available ? But second vital one was : which one would enable me to carry out rapidly a prototype ? The stakes were simple, answer theses question, realize this answer concretely, and compile all of my remarks and notices in a reference documentation.

Early in this process Linuxbios set itself as the uniq base solution, and I can say now obvious. Itself falls into many aggregated solutions, Freebios project, Openbios project and Linuxbios have united forces. Indeed, other smaller projects primarily external then became "internalized" solutions as more and more people came by and wanted to use it.

To build a Linuxbios BIOS you basically need to know more about Linuxbios base solution but you need also a flashing solution to burn your Linuxbios into a BIOS chip. Of course, flashing solution study will explain what to use from flash utility to BIOS chip. Moreover, you'll need a logging solution to "see" and record your Linuxbios first run activity. Next is for you to consider what booting solution and what payload i.g Os to boot you will need. At last, you will see that the display solution is still quite a piece of problem, whatever not fully implemented on EPIA motherboard.

4.1 Base solution study : Linuxbios configuration

Well here we are. If you read "why Linuxbios" and "played with kernel building", still you need to know what tools it offers to configure your free and open specifications bios. It's not as complex as you think... except if you are looking to master the subject and/or to develop upon Linuxbios. All the same, you have to go through some short generalities before configuring properly Linuxbios. If you intent to master, you could then dive in Linuxbios advanced features.


When it has begun at LANL, Linuxbios was meant to boot kernel in a clustering environnement (cf. glossary cluster) it was fetching on a server kernels. Application has now extended. Linuxbios fills the gap left by actual proprietary BIOS and corrects their errors which make unrealizable, unsupportable maintenances on machines and which harden human-machine interactions. For instance,"F1 press" after every BIOS update is a dull, repeatitive task when you have hundreds of computer in a grape. Also who would wait memory test to pass at every turn on of a MP3 pocket reader ? And how to "Press F1" without any keyboard if a BIOS update could be made possible ?

In all seriousness, beyond it is obviously unconfortable, beyond it is utterly closed source, it's a matter of fact theses proprietary bioses still maintain alife old fashioned functions. Theses are not used anymore such as DOS support whilst newly requiered functions are not developped such as large ROM storage support, as large RAM storage support, etc..

Linuxbios thanked to full configuration "compilation" mechanism satisfy to this. Since primarily Linuxbios is a divertment, its design and developement is inspired by the wish to write as minimal code as possible in order to let Linux kernel do the rest, what it does from the start. Indeed, as evocated before Linuxbios falls into two major parts : a bootstrap and a Linuxbios Linux Kernel prepared in the howto part of the linux kernel study.

In order not to have any troubles compiling Linuxbios itself, refer to Linuxbios software toolchain

All right, let's come to Linuxbios working. To build up Linuxbios from its source, three elements are involved :

Crt0.S sets enough code to start up binary Linuxbios bootstrap (although written in C). Ldscript.ld defines this bootstrap's reallocation adresses in order it could be found equally into a 256KB BIOS ROM or into a DOC 2000 8MB.

Another Linuxbios fundamental feature is that, all of the info on your build machine hardware is dispatched in all source tree directories involved in your BIOS building. It's you, when tweaking highest level configuration script, whom indicate for what motherboard, extensions and hardwares you wish your BIOS to be built. Below is clarified what you can find in Linuxbios source tree from src/ directory :

arch/        Crt0.S, ldscript.ld as well as Linuxbios Descriptor tables and other pirqs tables for i386.
boot/        bootloaders code : elfboot and filo.
config/      High level Configuration file architecture independant. Options file
console/     Code installing base console (text or vga) as well as UART825038 file
cpu/         Init. and reinit. codes  CPU, MTRR, cpuid.
devices/     For PCI resources assignment and PnP handling.
include/     Same nested tree for headers and definition files.
lib/         Redefined memory allocation code file.
mainboard/   Supported mainboards initialization code. (if it's not in, you're not)
northbridge/ Northbridge chipset init.
southbridge/ Guess what ...
pc80/        8086 arch. common compound init. such as keyboard, etc..
sdram/       Code to probe SDRAM
stream/      Bootload stream check code.

Config. files stands out as landmarks all along the source tree. Either they look like a mini-makefile, either they look rather like dialect codes. For instance, have a look to this one, boot/, which configure boot behavior :

object elfboot.o
object hardwaremain.o
        object filo.o


Theses beneath instructions are indeed compilation directives, they aren't directly understood by Make but they are by Buildtarget.

Buildtarget is a shell script located in target/. When executed it parameters and generates Make file as well as crt0.S and ldscript.ld files in order everything is right to compile.

[root@ge targets]# ./buildtarget
usage: buildtarget target [path-to-Linuxbios]

For instance, target for VIA EPIA is via/epia (base directory is mainboard/). Although second parameter is facultative it is strongly recommended for you shoudn't build targets in sources to prevent corrumption. Buildtarget call Python interpreter with, both of them understand configuration dialect code.

Buildtarget triggering scheme scours file, analyzes syntax, and check used keywords in comparison with dictionnary file located in src/config. This file assigns default values to each keyword. It look like this (truncatured) :

         define LINUXBIOS_COMPILER
                        default "$(shell $(CC) $(CFLAGS) v 2>&1 | tail n 1)"
                        export always
                        comment "Build compiler"
         define ROM_IMAGE_SIZE
                 default 65535
                 format "0x%x"
                 export always
                 comment "Default image size"

"Father" file calls reccursively every "son" Config.lbs which self instructs unit C file compiling by the 'object' keyword (as "son" file boot/ shown it previously). You can retrieve exhaustive instruction list from Stefan Reinauer's AMD64 Port Guide available at or at

I have spotted in my some landmarks for you to compass :

# Sample config file for EPIA
# This will make a target directory of ./epia
# Change for experiments MD
# ven avr 16 16:50:07 CEST 2004
target epia                             -- Target directory specifing 

uses ARCH                               |
uses CONFIG_COMPRESS                    |  Each Variable declaration *compulsory*       
uses CONFIG_IOAPIC                      |   before before use
uses CONFIG_ROM_STREAM                  |


# Comm settings                           
option DEBUG=1                          |  Debugging mode activation &
option TTYS0_BAUD=115200                |  serial port speed config.
option MAXIMUM_CONSOLE_LOGLEVEL=8       |  Verbosity level for debug 
option DEFAULT_CONSOLE_LOGLEVEL=8       |  string displaying to console               

# Graphics settings 
option CONFIG_CONSOLE_SERIAL8250=1      -- Activation of UART8250 dialog protocol for serial port  
option CONFIG_CONSOLE_VGA=0             -- Ggraphic mode  VGA deactivated (if activated serial port redirecting become useless) 
option CONFIG_CONSOLE_BTEXT=1           -- Btext mode activated

# Misc options
option CONFIG_COMPRESS=1                -- Enables gz'compressed kernel handling 
option MAX_REBOOT_CNT=2                 -- Max reboot count in case of error before bailing out
option CONFIG_SERIAL_POST=1             -- Display POST phases debug
option HAVE_HARD_RESET=1                -- System hardware reset native handler
option AUTOBOOT_CMDLINE="hda1:/vmlinuz root=/dev/hda3 console=ttyS0 "
                                        -- Boot command line and Kernel passed parameters :
                                        -- kernel is called vmlinuz and is located on hda1
                                        -- Root partition is hda3, main console is redirected to serial port 

Difference between every "son" and "father" will become more evident to you after editing many time various one. Primarily, are names after that sense guiding you to edit and modify their content in order to make things working properly. But be careful because in a unclever, confusing manner they also named another file, located in sources (!) src/mainboard, which you don't (normally!) have to modify at all. If it's true it "configures" mainboard like their false friend located in src/target and it used the same dialect code, that is over for the rest. Indeed, it is a default base file stuffed with critical values for your mainboard, thus if it is supported, it got to be all right here without your tweakings. I insist heavily, wrong statements in there will immediatly be paid back at "buildtarget stage" !

Equally, be careful with options you use, some of them just exclude each others. In some cases buildtarget script will stop in error while in some other buildtarget won't shout but results are undefined. Every solution that is chosen thus must be activated in father as well as in its various, dedicated or not, son Config.lbs in order to be effectively build.

When buildtarget works correctly you should have something like this below.

                Build ROM size 262144
                Verifying ROMIMAGE fallback
                Verifying ROMIMAGE normal
                Verifing global options
                Creating via/epia/epia/fallback/static.c
                Creating via/epia/epia/fallback/Makefile.settings
                Creating via/epia/epia/fallback/crt0_includes.h
                Creating via/epia/epia/fallback/Makefile
                Creating via/epia/epia/fallback/ldoptions
                Creating via/epia/epia/normal/static.c
                Creating via/epia/epia/normal/Makefile.settings
                Creating via/epia/epia/normal/crt0_includes.h
                Creating via/epia/epia/normal/Makefile
                Creating via/epia/epia/normal/ldoptions
                Creating via/epia/epia/Makefile.settings
                Creating via/epia/epia/Makefile

That is clear enough, this has created standard make files, fallback and normal ROM make files. All's right, makefile is done but before launching a reccursive long Make, you can check out if options are finely reported in Makefile.setting file. By the way, you can notice that crt0 and ldoption are also created here. The later file presents even simplier chosen options, compiling and linking ones.


Change directory to target/_vendor_/_product_/_target_dir and launch "make". In fact, it will runs two differents makes : one for fallback mode and this other for normal mode. By the way, there is another way to get linking and compiling options displayed by typing "make echo". Here are some main make targets : Linuxbios.rom, echo, build_opt_tbl, Linuxbios, Linuxbios.strip, romcc, build rom, clean.

Remark : buildrom, romcc, build_opt_table are compiled upon compiler call represented via $HOSTCC variable. In other codes, it is represented via $CC variable. This is because Linuxbios is build not necessary on the same host/build machine. If it is (false :) then both of theses variables should have "gcc" value.

Targets references self and others in a pointer storm. Here are a overview of main dependencies :

                + Linuxbios.rom
                  + Linuxbios.strip
                    + Linuxbios
                       + Crt0.o
                       + Initobjects
                       + Linuxbios_payload
                       + ldscript.ld
                    + Buildrom

Initobjects are primarily C source files, content files if I can write so. At the opposite, crt0.o and ldscript.ld are the application backbone. Initobjects are designated as such because of the "Object" dialect directive as we've seen in the end of upper part Generalites. Precompilation parameters are mostly located in theses InitObjects. Concretely, precompilation directives are present typically under a '#define' or '#ifdef' form. You can also find them back while compiling as gcc commandlines shows their '-D_XXX' strings which was listed in ldscript file. Here is an exhaustive compiling steps ordered list :

        1.  Linuxbios version file is compiled
        2.  romcc file is compiled
        3.  crt0.s file is assembled, failover.c and auto.c are compiled with romcc
        4.  initobjects objects are all compiled
        5.  initobjects references are gathered into Linuxbios.a
        6.  Linuxbios_c object is compiled with Initobject objects, Linuxbios.a and libgcc.a
        7.  Linuxbios_c exec. code file is done.
        8.  symbol map of this file is recovered into
        9.  linubios boot code is generated with ldscript.ld and crt0.o
        10. Linuxbios objects are copied into Linuxbios_payload
        11. rv2b upon compilation is applied to Linuxbios_payload by compression. New code name is Linuxbios.rom
        12. Linuxbios boot code is regenerated with ldscript.ld and crt0.o
        13. Linuxbios symbol list is stored
        14. Linuxbios objects are copied into Linuxbios.strip
        15. payload is compiled if exists.
        16. buildrom is compiled and called with Linuxbios.strip, Linuxbios.rom and payload.rom

Refer to target building dependencies synoptic flowchart to have a visual reference.

You now have a Linuxbios.rom file generated in target/_vendor_/_product_/_target_dir_ directory. This is a binary code adapted to your cpu and all your hardware specifications according to what was configured in mainboard/ You can have a glance at ROM internal structure. Now, it can be flashed in a EEPROM using a flashing solution.

Before swiching to this stage, maybe you haven't noticed a fundamental thing about Linuxbios compile process that we have just partly discovered. Gcc has compiled a lot of C code file while other files have been processed by another special compiler Romcc. Why ? Let's penetrate Linuxbios bowels...

Linuxbios advanced features

Another Linuxbios big feature is that it's admitted it must run as a standalone program. It mustn't have any external references except for previously considered config. files. That's why you can find a 'memset' code (memory mapping) in src/lib directory : in Linuxbios context it is impossible to use Linux kernel external memset code which supposes a BIOS service at this moment still not set up. I can't help exposing the simplicity of this code which BIOS will use several times such as in caching and shadowing itself. What else could be expected ?

void *memset (void *s, int c, size_t n) {
        int i;
        char *ss = (char*) s;
        for (i = 0; i < n; i++)
                ss[i] = c;
        return s;
Nevertheless it is small it couldn't be called in real mode. Written in C, it requiers a stack and a heap which are defined only while protected mode (If you wish take a look to boot process flowchart to observe it).

All the same, there is no what a pity since memset needn't being called in real mode. But for instance, a cousin code such as RAM summing calculus code must be called in real mode (no heap, no stack). Indeed it must count how long RAM is to future memset mapping. Finally, Gcc shouldn't and can't compile this code, even if it's written in C.

Romcc is a compiler which generates from C, a peculiar byte code for ROM execution. This indicates no writing, no swapping in memory so no stack and heap mechanisms and endly no RAM needed to process. Romcc was bring with V2 version, before in V1 all 'real' codes was in assembly. Major advantage of C upon ASM: portability. RAM summing calculus is thus uniq for all motherboards. Romcc emulates stacks and heaps with CPU registers in processing swaps. Romcc generated code tends to be longer than if it was compiled with Gcc granted, but boot time shouldn't be that plundered.

At boot time, another advanced features is involved. Linuxbios creates tables which was (cleverly called Linuxbios tables. It resides in low memory and holds infos such as active motherboard, as BIOS shadow address field (in a RAM non volatile part) as well as other various Linuxbios parameters. Natively, Linux kernel preserve this table at OS start up and there on. In source tree maybe can you find a utility called 'lxbios' which recovers and reads theses tables in order for instance to validate under OS a checksum.

Linuxbios can thus use this non volatile memory part to store persistant data. Infos like boot time counter (CNT_BOOT) are defined in a structure called CMOS table. Still "visible" from OS, here is what it looks like.

StartbitLength Config ID Name
0 384 r 0 reserved memory
384 1 e 4 boot option
385 1 e 4 last boot
386 1 e 1 ECC memory
387 1 ? ? ?
388 4 r 0 reboot bits
392 3 e 5 baud rate
... ... ... ... ...
400 1 e 1 power on after fail
... ... ... ... ...
412 4 e 6 debug level
416 4 e 7 boot first
420 4 e 7 boot second
424 4 e 7 boot third
428 4 h 0 boot index
432 8 h 0 boot countdown
... ... ... ... ...
1008 16 h 0 check sum
Linuxbios CMOS tables

You can retrieve this file in sources mainboard/ directory. Cmos_xxx utilities are also available in source tree, it enables you to modify CMOS and Linuxbios options real time under OS. Useless to mention that you should know what you do in this...

Upgraded with V2, chained devices handling is another Linuxbios feature. Chips and devices are transparent while it is made lot easier than in V1 to call theses structured functions. On the same design, PCI data structures has been modified too comparing to V1 or Linux kernel ones. Take a look to what it now looks like:

Chip structure (static.c) :

    struct chip_control northbridge_via_vt8601_control = {
   .enumerate = enumerate,
   .enable    = northbridge_init,
   .name      = "VIA vt8601 Northbridge",

Devices strcuture and its device pointers :

struct device {
              struc_bus *                       bus;
              device_t                sibling;
              device_t                next;
              struct device_path                path;
              unsigned short          vendor;
              unsigned short          device;
              unsigned int            class;
              unsigned int            hdr_type;
              unsigned int            enable :1;
              uint8_t                 command;
              struct resource                   resources [MAX_RESSOURCES];
              unsigned int            resources;
              struct bus                        link[MAX_LINKS];
              unsigned int            links;
              unsigned long           rom_adress;
              struct device_operation           *ops;
              struct chip                       *chip;

Just from theses structures you can imagine the chainned organisation : it is said to be PCI centric.

At last, one of the most interesting feature is the ability to detach part of the Linuxbios payload onto a network machine. Indeed via DHCP or TFTP service you can retrieve a distant kernel. In case of clustering, this functionnaly is decisive. It is also possible to imagine a distant BIOS update procedure with no fiction at all. You will find fine details about part detaching and network booting in AMD64 Port Guide. Payload and boot principe are to come further in booting solution study.

You got a Linuxbios.rom file compiled, so what about flashing it in an EEPROM ? But if you didn't touch anything about ROM configuration you will only be able to burn in 256Kb chips (default). Maybe you already know what EEPROM and what software you are going to use. But in case you just don't, let's step forward to flash solution study.

4.2 Flashing solutions study

Flash or burning process which consits basically in writing byte code from a Linuxbios.rom file into a BIOS compound such as CMOS chip is the ultimate achievement. Because flashing solutions depends on chip compound type, theses are at the beginning of this study.

There on, you will remark that there are two ways to get a BIOS burnt : "cold and hot" flashing, plugging. Also I describe a hardware cold flashing and explain why I prefered a software hot flashing. The study is conclude by a scheme which describe what is flashed in Linuxbios ROM.

Virtually you can burn and program any memory based electronical compound. But some dependencies are mostly bound to deadlock. Indeed Linuxbios base solution can concretely identify some chips and I had to find in theses a chip that would be also identified by the flashing solution.

EEPROM chips, "flash" memories

They are plenty of EEPROMs that can host a byte code such as a BIOS. Let's consider the BIOS chip, a CMOS linked via a bus with its protocol. Grosso modo and according to previously described structures this is clearly designating a device. Well, Linuxbios is only capable to read from internal bus (CPU-RAM exchange circuit).

They are plenty of EEPROM on the market from different size, capacity, format. Everything is made clearer thanked to JEDEC standard (cf. IEEE standards site which is a regroupment of standards concerning chip casing and instruction set. Well endly, Linuxbios is JEDEC compliant.

To sum up, here is an overview available EEPROM :

Cold/Hot flashing and plugging considerations

Primarily, I did try to cold flash and plug because hot flash and plug was said to be delicate to realize, even very risky to too dangereous. I say, you don't have to fear to be electrocuted, nor to loose your noze by smelting, or whatsoever. Truely this was really too exagerated... except if you are badly equipped to "operate" or still if you are utterly clumsy and you don't pay attention to what you do. But obviously you do if you read this g.

Hot way : It consists to unsolder original CMOS from the mainboard while running and to remplace it by a spacefree one. Then you burn it using a program. At last, you reboot and look at the result.

Cold way : It consists to unsolder original CMOS from the mainboard while its turn off. Generally, this requiers an external EEPROM programer card.

In order to do this carefuly and properly, be equipped with the adequate tweezers, remember chip notch location while you unsolder it, paid attention to use adapted pin converter if you may use any.At last, upon any doubts just download and read hardware specification properly. Your first burn must be CMOS save one !

Hardware and software

At first I try to do it the cold way and I came to use a Willem EEPROM Programmer v3.1 20-03-2002. This is a "starter" tool, an external device which consits in an epoxy card with a DIP EEPROM slot to setup with jumpers and switchs. The lonely two pages available documentation, if I dare call it like that, and DIP2PLCC adapter botch-up had wasted my time as well as for win32 card device driver which forces me to install a proprietary OS just for testing purposes. It was so confuse I just couldn't write to the chip, only have I managed to read it.

Therefore, I gave up cold way. Actually, it force an external device adjunction thus adding more intermedia, and slowness. It is pityful to setup with its out-of-date jumpers programing. It was hot that summer, I bent dozing over my desk and dreamt I was punching cards at input. Seriously, if you have a relatively recent motherboard, prefer ease of the hot way.

Then I have tested Openbios project's DevBios tool (cf. Openbios site ref.) which reads and writes the hot way. In fact, it is a elegant solution which enables Linux to see CMOS as any other peripherical device such as a disk or a console. That is to say you can write your into it like that : "cat linuxbios.rom >/dev/Devbios". Or save your bios like this : "cat /dev/bios >save.rom". Symetric, simple this solution in a early release version presented nonetheless some powerful cons. First, this early version (first or second "official" release) support a little number of different chips. Second, it couln't write to CMOS because of my C3 Ezra cpu which is not supported by this Devbios version. I had to forget about Devbios too.

The most simple way was what I didn't remark in Linuxbios source tree, a chip flasher. It is a simple to use flash_rom tool as this below overview attest it and it supports most common chips.

        [root@ge utils]# ./flash_rom
        usage: ./flash_rom [-rwv] [-c chipname] [file]
        -r : reads flash and save into file
        -w : write file into flash (default when a file is specified)
        -v : verify flash according to file
        -c : probe only for specified flash chip
         If no file is specified, then all that happens
         is that flash info is dumped

Another solution is available but I had no time studing it. It is "lbflash" command (cf. cmos commands).

Linuxbios ROM structure.

To conclude this study on a graphical resource, you can take a look to Linuxbios ROM memory layout. Lower addresses are at top.

You have achieved to configure, build and flash your free bios Linuxbios. Although I just don't know whether it will be working or not. What you need is a easy to setup and to use logging facility. This is exactly what it is about into next part.

4.3 Logging solutions study

A successful built and flashed bios ROM should allow you to think it will work perfectly. But while no display solution has been set up, neither VGA nor BTEXT mode, sole remaining solution is to checkout debug strings with the resources and tools part described experiment appareil. By the way, also check out your cable with cable pin description.

If DEBUG option and SERIAL_CONSOLE have properly been set in, if cable is properly made up, if transmission protocol is correctly set up, normally debug messages must been sent to ttyS0 serial port. To fetch them back I studied "minicom" which is a program for modem to emit and receive packets on serial port. After several tries and bad protocol setting up, minicom appeared to be too much of a pain to be used for this study propose. Menu commands have to be triggered by several CTRL holding while multiple key hitting. Menu bars are badly refreshed, etc.. This is a recommanded tool but believe me, in fact, it does badly more that it is requiered.

In that case, what does it needs specificly ? Just to retrieve theses strings from ttySO and to display it to console. I've made up a command called Hear! bash script, which is simple to use and to configure. Let's have a synoptis :

[root@ge utils] # ./
Usage ./ log_to_file

Logging Procedure : Howto to proceed with testing and debugging your Linuxbios:

First of all, set up your appareil as evocated just beneath. Linuxbios build machine is now fully qualified bacause you had inserted your Linuxbios CMOS chip into freed CMOS slot while flash procedure.

Second, on your other machine you just have to start Hear script pending.

Endly, just reboot Linuxbios build machine and gather debug strings into Hear logfile.

Here is typical Linuxbios startup truncatured logfile created with Hear!

Hear! Boot Log started on 14/05/04|15:48:02
tty in use : /dev/pts/3 from ttyS0
64      LinuxBIOS- Fri May 14 15:25:51 CEST 2004 starting...$
65      87 is the comm register$
66      SMBus controller enabled$
67      vt8601 init starting$
68      00000000 is the north$
69      1106 0601$
70      0120d4 is the computed timing$
71      NOP$
72      PRECHARGE$
73      DUMMY READS$
74      CBR$
75      MRS$
76      NORMAL$
77      set ref. rate$
78      enable multi-page open$
79      Slot 00 is SDRAM 04000000 bytes $
80      0080 is the chip size$
81      0008 is the MA type$
82      Slot 01 is SDRAM 04000000 bytes $
83      0040 is the chip size$
84      0008 is the MA type$
85      Slot 02smbus_error: 04$
86      Device Error$
87       is empty$
88      Slot 03smbus_error: 04$
89      Device Error$
90       is empty$
91      vt8601 done$
92      00:06 11 01 06 46 00 90 a2 05 00 00 06 00 40 00 00 $
93      10:08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 $
94      20:00 00 00 00 00 00 00 00 00 00 00 00 06 11 10 60 $
95      30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 $
96      40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $
97      50:fe df c8 98 00 00 10 10 88 00 08 08 10 10 10 10 $
98      60:3f aa 0a 30 e4 e4 e4 c4 42 ac 65 0d 08 7f 00 00 $
99      70:c0 88 6c 0c 0e 81 52 00 01 f4 01 00 00 00 00 00 $
100     80:0f 45 00 00 00 00 00 00 03 00 70 07 00 00 00 00 $
101     90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $
102     a0:02 00 20 00 07 02 00 07 00 00 00 00 6e 02 00 00 $
103     b0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $
104     c0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $
105     d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $
106     e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 $
107     f0:00 00 00 00 00 00 01 01 22 42 00 b0 00 10 00 00 $
108     Disabling cache$
109     Clearing mtrr$
110     Setting XIP$
111     Enabled the cache$
112     Copying Linuxbios to ram.$
113     Jumping to Linuxbios.$

Still pending there is two ways of closing script : classical by sending a end-of-file (for instance send /dev/null) or interactivly by pressing CTRL+C. At the end, propose to record your commentars, best is to add there experiments conditions, specific tested configuration options, some remarks/feelings. It will be placed at end of logfile as well as boot time measure.

Here is the end of this same logfile

114      found PCI IDE controller 1106:0571 prog_if=0x8f$
115      primary channel: native PCI mode$
116      Waiting for ide0 to become ready for reset... ok$
117      Testing for hda$
118      Probing for hda$
119      LBA mode, sectors=40021632$
120      Init device params... ok$
121      hda: LBA 20GB: Maxtor 32049U3                        $
122      Partition 1 start 63 length 2040192$
123      Unknown filesystem type$
124      Command terminated by signal 2
real 13.67
user 0.01
sys 0.01
Comments :
This is a BTEXT_CONFIG test
 no payload, no videoROM, no VGABIOS
from a cold boot : no screen "video mode on" (led goes green)
from a warm boot : the screen flashes but nothing written

Results and Remarks :

Indicated '13.67' seconds boot time is actually a relatively long boot time. But remember that in debug mode, tests and displays are very time consuming. Plus in normal mode, you should not need any stream redirection which is also slowed by protocol's baud rate. The 'unknow filesystem' indicates that my payload (none = elfboot) don't accept hda part1 filesystem which is an ext3 partition.

You surely have to multiply tests and reconfiguration. For instance, in beneath exposed example my filesystem is not supported and I had to modify partly my payload and thus my kernel configuration (ext3 native support), to buid it again. I also did try to modify Linuxbios configuration to activated any ext3 option, but I couldn't find any. Maybe it is not just a payload matter then I had to study other boot solution.

4.4 Boot solutions study

This study will clarify a very important notion : the payload. It is the pure useful load, typically the OS. Although Linuxbios ROM layout represents it at top, payload is executed at the end of bios start up as logfile tail can attest. In previous bios boot example , nevertheless there wasn't any payload, bios was allthesame instructed to boot elf payload (default is ELFboot) on hda part. 1.

This clumsy permissiveness design forces to explain what's in a name to be more precise what is to boot ? A bootloader is a program which boot a payload that is an OS. A bootloader which boots an application program should be just called a loader.

I take a concrete case to explain further. For instance, to start with loading a simple payload, you can attach a funny program which would only display "Hello tragic world !" and stops. In this case, you will load from i.e hda1 a program whose format must be understood by the loader. Linuxbios no payload choice induce the activation of default bootloader or loader ELFboot which boots ELF format.

Now if you want to boot an entiere OS, previous loader must mutate into a bootloader such as FILO. But this complex distinction will become clearer further on. Anyway, simplest is to remember both bootloaders and loaders are boot solutions.

There are two conditions limitating payload program constitution. First, payload parts must fit in free and adjacent memory spaces. Second, of course, its bootloader or loader must be payload's format compatible and it must be link statically (no external dependancies, standalone).

Here is represented Linuxbios complete payload layout:

The Media Specific Layer (MSL) is core payload's decoder. Decompressor code exists if core payload is compressed (well, Linux kernel is). RM to PM interface code handles real mode to protected mode interface. For instance, if you want LILO as bootloader, payload will consist in liloprefix.S MSL (cf. ALDO source tree). Make a do-it-yourself payload takes time but Linuxbios offers supports for various ones.

There are two different boot solutions : Linuxbios native one and external ones. According to this, either a boot solution is simple and bios probes first 8KB to look for a ELF image, either it is said advanced and it could even analyse filesystem to check for specified image. Therefore, concerning simple boot solution image file must resides at ROM beginning.

Now let's list how you could design a boot architecture with theses boot solutions. Note that the two first have been internalized :

When you finish testing bootloading mechanisms with ELFboot or FILO, it might not be enough if you want to sketch an advanced boot architecture. Linuxbios ables you to "mount" a complex one provided you do some more coding or some enhancements. I didn't gone that far in, theses are proposals or examples considering some Linuxbios forum posts about boot architecture successfull tests. Theses are called bootchains.

Here are some differents bootchains, from simplest to more complex ones.

Remark : It is obvious ROM/flash memory isn't at will expendable. Therefore in theses boot chains, could space may become a problem notably for longest ones ? Not at all because never a currently running payload ever gives hand back to previous one (which has launched it). In other words, a payload has no execution return, it is useless, isn't it ? Therefore theorically, current running payload can occupy its previous launcher memory, that is to say that theses multibooters/bootloader architectures are not memory spendthrift. If practically feasable, this capacity would although need a strong code enhancement to enable this.

Boot solutions are one of the most active effort in Linuxbios project. But user's boot need are versatile, so remind to keep it as flexible as possible. Keep as simple as possible while not killing Linuxbios fallback mechanism. To start with, best is to try simplest chains. If you make your boot solution to work with enough resilience (flexible and safe mostly) you can consider your free, open, Linuxbios functionnal. Indeed when Linux kernel will take hand over it should (re)initialize and in fact set your display. But you have to admit that before this stage, this wouldn't be considered that resilient without any display configured. Yes I guess what you could be thinking "if all is fine, who cares to see that bios dialog at startup and to have it displayed ?". I do, and you also when you will have some bios prompt or troubles. Anyway, do you really believe you would like to keep and load yourself down with such a strange wired appareil ? Indeed no, you don't. So let's see how to get a valid diplay solution.

4.5 Display solutions study

Experiments don't need any graphic display to get Linuxbios working and to attest it works. But it is not possible in "an product approch", in other words, your users will want a graphic display. You know that Linux initializes a console and sets up a terminal, it also sets up the VGA driver enabling a graphic console and a graphic mode terminal.

Noticing this matter of fact, Linuxbios developpers thus implemented minimal code to initialize graphic card registers into the chipset. Roughly they send a ready-to-display byte stream to the card according to its chipset. It has been realized without a lot of code yet it isn't that simple because they had to know precisely that chipset as well as its specific initialization. Theses infos are either given by the card manufacturer either it is not. If it is then all is right.

If theses infos are declared secret, it clearly set a barrier on designing a video code. Anyway, who ever said you need to do this ? No one and there is always something that's available, the original video code stored into the graphic card ROM. It is called VGABIOS. Simply, it will be copied into Linuxbios ROM (cf. Linuxbios ROM layout).

All the same, a problem remains : theses intializations primarily lie on 16 bits mode BIOS calls whilst Linuxbios is fully 32 bits since a while up to there. To attest this is true, just consider that the first thing to be displayed when a system is turned on is the graphic card name and its manufacturer. This is made possible with 16 bits codes for at this early stage RAM has not been summed up and analysed. (cf. check out boot process to see by yourself).

To make it through Linuxbios developpers have taken the last resort : to use an external emulator x86emu. Sure, this is not a panacea but until Linuxbios gains more support from manufacturers it is efficient. Anyway at Linux kernel graphic driver set up, it will be replaced by vesa (vesafb) or by a frame buffer device (fbdev) or even better a X server (X11). Theses drivers just need chipset to respond to managed I/O.

Stack showing different software layers to handle graphics in Linuxbios :

Of course, nothing stops you from not desactivating SERIAL_DEBUG while building your next Linuxbios. I let you know that it won't prevent this VGA solution to work anyway. Linuxbios source tree provides testbios to check and validate your video ROM. Then you can test direct writing to stress I/O frame buffers and validate your X server. Endly, you can test graphic modes. Theses two tests I've made quickly are graphic tests scripts.

To conclude this section and all the study part I would say that I've reveleaved a lot of Linuxbios globally and peculiarly. This study which is very Linux oriented and very server-client oriented still stays general. As I've stated in the disclaimer remember it is a specified Linuxbios project, an instance if you prefer.

I think you now have all the keys to even develop from Linuxbios project if you have coding knowledges. Linuxbios project like other FLOSS communities is always pleased to welcome all contributors.

Next section is a pure HOWTO configure and combine studied solutions for VIA EPIA-M motherboard.

Next Previous Contents