From coreboot
Revision as of 19:39, 4 March 2007 by Quux (talk | contribs) (→‎Developers: USB debug device)
Jump to navigation Jump to search

The wiki is being retired!

Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!


What is LinuxBIOS?

LinuxBIOS is a Free Software project aimed at replacing the proprietary BIOS (firmware) you can find in most of today's computers.

It performs just a little bit of hardware initialization and then executes a so-called payload.

Some of the many possible payloads are: a Linux kernel, FILO, GRUB2, OpenBIOS, Open Firmware, SmartFirmware, GNUFI (UEFI), Etherboot, ADLO (for booting Windows 2000 and OpenBSD), Plan 9, or memtest86.

Our primary motivation for the project was maintenance of large clusters, but not surprisingly interest and contributions have come from people with varying backgrounds. Today LinuxBIOS can be used in a wide variety of scenarios, ranging from clusters, embedded systems, desktop PCs, servers and more.

Why do we need LinuxBIOS?

Why do we need LinuxBIOS for cluster maintainance?

Current PCs used as cluster nodes depend on a vendor-supplied BIOS for booting. The BIOS in turn relies on inherently unreliable devices such as floppy disks and hard drives to boot the operating system. In addition, current BIOS software is unable to accommodate non-standard hardware making it difficult to support experimental work. The BIOS is slow and often erroneous and redundant and, most importantly, maintenance is a nightmare. Imagine walking around with a keyboard and monitor to every one of the 128 nodes in a cluster to change one BIOS setting.

LinuxBIOS with Linux as a payload (other payloads are possible!) gunzip's the Linux kernel straight out of NVRAM and essentially requires no moving parts other than the fan. It does a minimal amount of hardware initialization before jumping to the kernel start and lets Linux do the rest. As a result, it is much faster (current record 3 seconds), which has sparked interest in the consumer electronics community as well. Moreover, updates can be performed over the network.

Using a real operating system to boot another operating system provides much greater flexibility than using a simple netboot program or the BIOS. Because Linux is the boot mechanism, it can boot over standard Ethernet or over other interconnects such as Myrinet, Quadrics, or SCI. It can use SSH connections to load the kernel, or it can use the InterMezzo caching file system or traditional NFS. Cluster nodes can be as simple as they need to be - perhaps as simple as a CPU and memory, no disk, no floppy, and no file system. The nodes will be much less autonomous thus making them easier to maintain.

Why do we need LinuxBIOS for other purposes?


Who is working on LinuxBIOS?

The LinuxBIOS project was started in the winter of 1999 in the Advanced Computing Laboratory at Los Alamos National Laboratory (LANL) by Ron Minnich. Two undergraduate students, James Hendricks and Dale Webster spent their winter vacation putting together the proof of concept implementation.

Since then, a long list of people have contributed both in discussions and actual code. Please don't be shy and let us know if you are missing from the list. It's not a purposeful omission, just an unfortunate mistake.

Who is funding LinuxBIOS?

The LinuxBIOS project is funded by the Los Alamos Computer Science Institute and the Department of Energy's Office of Science.

See also the list of LinuxBIOS sponsors.


Will LinuxBIOS work on my machine?

See the Supported Motherboards page for which mainboards are supported, and also the list of Supported Chipsets and Devices. See the Products page for a list of vendors selling products running LinuxBIOS.

If the above sources don't help, please send the following to the mailing list:

  • Step 1: A very brief description of your system: CPU, northbridge, southbridge, mainboard and optionally other important details.
  • Step 2: Linux lspci output for your system, generated by booting Linux via the original BIOS and runnning lspci.
  • Step 3: Super I/O chip on the mainboard (report the model numbers on the actual chip, for example "Winbond W83627HF").
  • Step 4: Type of BIOS device (see the question "How do I identify the BIOS chip on my mainboard?" below).
  • Step 5: URL to the mainboard specifications page (optional).
  • Step 6: Any other relevant information you can provide.

If you can't do step 1 above, please describe (as best you can) the specific CPU chip and the chipset used on the mainboard.

Usually in less than a day, someone will respond on the LinuxBIOS mailing list saying your mainboard is supported in the main LinuxBIOS source tree, it is currently in development, it is not yet supported or the manufacturer will not release information needed to provide LinuxBIOS support. In the latter case, please let the manufacturer know that you want LinuxBIOS support and his failure to release chipset information is making that very difficult.

What commercial products use LinuxBIOS?

See the products page.

Which different operating systems will LinuxBIOS boot?

  • Linux (of course)
  • Plan 9
  • Windows 2000 (via ADLO)

We have looked at some of the BSD OSes but (e.g.) FreeBSD makes BIOS calls, and we don't support BIOS calls. Possibly ADLO could be used to support FreeBSD, but the right thing to do is remove FreeBSD's dependence on BIOS calls.

What chipsets and Super I/O devices are supported?

See the Supported Chipsets and Devices page.

Where is the mailing list archived?

See Mailinglist.

Where do I get the code?

See the download page.

How do I build LinuxBIOS?

See the documentation.

How can I help with LinuxBIOS?

There are many ways how you can help us:


What kind of hardware tools do I need?

A motherboard (or mainboard as LinuxBIOS calls it) that has a supported chipset on it. Ok... well not exactly. As long as you have the documentation for the chipset/mainboard and it's free of any NDA issues you can use an unsupported chipset/mainboard, but you have a twisty road ahead of you.

And of course you need a Linux development machine. The LinuxBIOS build environment is not supported on Windows. It may be possible to do it under cygwin but nobody has tried.

It's also handy to have one/some/all of the following:

EPROM/Flash programmer that can program the flash on your motherboard

Bios Savior

Photo of an installed BIOS saviour.

A tool that plugs into and replaces the original mainboard Flash device. The BIOS Savior has its own Flash device and a socket for the original mainboard Flash device. The Bios Savior features a switch to allow the developer to choose between which Flash device is accessed by the mainboard during read and write cycles.

POST card

See the What is a POST Card? question in this FAQ.

Compact Flash IDE adaptor


For hardware debugging purposes.

In Circuit Emulator hardware debugger

  • ...


In Circuit chip programmer

Should allow you to program your BIOS even if it is soldered to the motherboard.

EPROM emulators

These hardware devices pretend to be an EPROM chip.

USB debug devices

an alternative to a serial console may be a USB debug device. They are not so common yet. Their advantage is higher speed than a serial console. One might hook an FPGA to it for profiling purposes or some automated checks. Accessing a USB debug device from within BIOS is not different than other USB devices, and is part of the USB standard.

What documentation do I need?

As much documentation as you can possibly get your hands on. At minimum, you will need the docs for the chipset.

There have been reports of people getting LinuxBIOS working by booting with the OEM BIOS. Then, they would read the static contents of the PCI config registers after boot. LinuxBIOS is then built to match the static contents read from the PCI config registers.

The problem with this approach is that chipsets generally require dynamic vs static configuration values during their initialization. The configuration register contents will change from one stage of initialization to the next. Since the contents of the registers read is only the final state of the configuration registers, the chipset won't be properly initialized if these are the only configuration values used.

Getting a mainboard up without chipset docs can be a very long and involved process.

What if my chipset docs are covered by an NDA?

If the documentation for your chipset covered by and NDA with no source release agreement you won't be able to release your code back to to the LinuxBIOS project in general or you will violate the GPL. Many vendors accept releasing the source code produced after reading such specs while they don't allow the specs themselves to be revealed. Also, you can offer them to review the code before releasing it.

Why is the code so complicated and what can I do to make it easier?

The reason is the complexity of the problem. We support a lot of hardware, and a given chip on a given board will most likely not be configured quite the same as the same chip on some other board. To help make code navigation easier, pick a target and build that target. Then, in the build directory, type make tags or make etags to get your favorite tags file.

What is this POST card thing?

A POST card will save your life. The term POST means Power On Self Test and comes from the original IBM specifications for the BIOS. Port 80 is a pre-defined port to which programs can output a byte. The POST card displays the byte in hex on its 2 digit display. We use a lot of POST codes in LinuxBIOS, so if you can tell us the POST code you see, we will have some idea of what happened.

If your LinuxBIOS machine is working properly, you will see it count up from 0xd0 to 0xd9 (while it is gunzipping the kernel) and then display 0x98 (Linux idle loop).

PCI POST cards can be found in various places. POST Cards

How do I contribute my changes?

Please carefully read the Development Guidelines for more information.

How do I identify the BIOS chip on my mainboard?

Modern mainboards store the BIOS in a reprogrammable flash ROM chip. There are hundreds of different flash ROMs, with variables such as memory size, speed, communication bus (LPC vs. ISA/PCI) and packaging to name just a few. The three most common packages are called DIP, PLCC and TSOP. The BIOS copyright holders often place a fancy sticker on the BIOS chip showing a name or logotype, BIOS version, serial number and copyright notice.

DIP: Dual In-line Package

File:ROM BIOS.jpg
A DIP BIOS chip.

A rectangular black plastic block with lots of pins along the two longer sides of the package. DIP ROMs can be socketed which means they are detachable from the mainboard using physical force. Since they haven't been moved in and out of the socket very much (yet, hehe) they can appear to be quite difficult to release from the socket. One way to remove a DIP from a socket is by prying a thin screwdriver in between the plastic package and the socket, along the shorter sides where there are no pins, and then gently bending the screwdriver to push the DIP upwards, away from the mainboard. Alternate between the two sides to avoid bending the pins, and don't touch any of the pins with the screwdriver, see FAQ about ESD, electro-static discharge. If the DIP is soldered directly to the mainboard, it has to be desoldered in order to be reprogrammed outside the mainboard. If you do this, it's a good idea to solder a socket to the mainboard instead, to ease any future experiments.

PLCC: Plastic Leaded Chip Carrier

File:2 W39V040BPZ.png
A socketed PLCC BIOS chip.

Black plastic block again, but this one is much more square. PLCC is becoming the standard for mainboards because of it's smaller physical size. PLCC can also be socketed or soldered directly to the mainboard. Socketed PLCC chips can be removed using a special PLCC removal tool, or using a piece of nylon line tied in a loop around the chip and pulled swiftly straight up, or bending/prying using small screwdrivers if one is careful. PLCC sockets are often fragile so the screwdriver approach is not recommended. While the nylon line method sounds onorthodox it works well. Desoldering PLCC can be painful without specialized desoldering equipment particularly because PLCC chips have leads on all four sides of the package.

TSOP: Thin Small-Outline Package

TSOP chip on a TSOP->DIP adapter

TSOPs are often used in embedded systems where size is important and there is no need for replacement in the field. It is possible to (de)solder TSOPs by hand, but it comes close to wizardry.

How do I (re-)flash the BIOS?

Out of mainboard BIOS (re)flash

If the BIOS chip is socketed, it can be removed and flashed in a rom/flash burner and quickly re-installed. Some of these burners cost $1000 and more plus they complete a flash in 1-2 minutes, but if you are willing to wait 5 minutes for a flash and manually set DIP switches, The Enhanced Willem Universal Programmer will do the job for only $40-60 USD. There are several models of the Willem Programmer, each supporting many chips, but not all, so be sure to get one that supports your BIOS chip. If your chip is PLCC, you will also need a PLCC chip extractor/puller or just thread nylon string under the PLCC chip from corner to corner and yank up it straight up.

Inside mainboard BIOS (re)flash

Download the appropriate flash update utility. Build the romimage as explained above and use the flash update utility to update the BIOS. Be warned that not all update utilities allow you to load your own BIOS image. For example, Intel decided to disallow it for the MS440GX mainboard (probably after hearing about us!) Here are some mainboard specific directions:


LinuxBIOS v2 contains a flash utility called flashrom in the util/flashrom directory. (Old versions had "util/flash_and_burn/flash_rom" instead).


bash$ sudo ./flashrom -V
Calibrating delay loop... Setting up microsecond timing loop
216M loops per second
Found canidate at: 00000530-00000bc4
Found LinuxBIOS table at: 00000530
lb_table found at address 0xb7e1c530
LinuxBIOS header(24) checksum: 404a table(1684) checksum: 2766 entries: 14
vendor id: via part id: epia-m
Enabling flash write on VT8235...OK
Trying Am29F040B, 512 KB
probe_29f040b: id1 0x20, id2 0xe2
Trying ST29F040B, 512 KB
probe_29f040b: id1 0x20, id2 0xe2
ST29F040B found at physical address: 0xfff80000
Flash part is ST29F040B
OK, only ENABLING flash write, but NOT FLASHING.

If neither utility supports your chip, then you could either use the DOS uniflash utility, or use its source code, which is also available for download from the uniflash site (in Pascal!) as a reference for adding support for your flash chip to "flash_rom". Uniflash supports a lot of different flash chips, and chip interfaces.

SiS 630/950 M/Bs

Ollie Lho provided us with flash utilities for these boards under freebios/util/sis. flash_on turns on the flash write enable. This needs to be run before loading the DoC drivers. flash_rom allows you to use your SiS 630/950 M/Bs as a flash programmer. It currently supports JEDEC flash parts, AMD am29f040b models, MXIC MX29F002 models, and SST28SF040C models.

Intel L440GX

Get the System Update Package directly from Intel. mcopy the ten files created from running make phlash onto the Intel flash burner disk and use the update utility to burn the BIOS. To restore the original BIOS, set the recovery boot jumper on the motherboard, put the floppy in, and it will load and reflash the original BIOS. How do I actually burn a flash ROM?

Buy your favorite flash burner (we use a Needham Electronics EMP 30). Use make floppy to create the romimage and copy it to a floppy. Then use the provided software to burn the flash.

BIOS Savior RD1

BIOS Savior RD1

There are some posts about the BIOS Savior RD1 that suggest its integrated flash device is of low quality; it may take 10 or more flash programming attempts to get a good update to the RD1 flash device. As a result, the following steps have proven to be successful while using the RD1:

  • Step 1 - While the system is powered down, remove the original BIOS device from the mainboard and insert it into the RD1's socket.
  • Step 2 - Insert the RD1 into the mainboard's flash BIOS socket.
  • Step 3 - Boot the system with the RD1 set to boot from the original flash device from the mainboard.
  • Step 4 - Program the original BIOS image (or other known good BIOS image) into the RD1's integrated flash device. Do this as many times as needed until the device is properly programmed and the system boots corectly from the RD1's integrated flash device. Be sure to check the settings on the RD1 so that the proper flash device is now being programmed. If the RD1 is not set correctly the working BIOS image will be erased and the system will not boot!
  • Step 5 - Program the test BIOS image (usually LinuxBIOS images are among this group) into the original flash device from the mainboard. The original BIOS device usually programs OK on the first attempt. Be sure to check the settings again on the RD1 so that the proper flash device is being programmed!

The RD1 has been used in the above fashion with great success on the Tyan S2885 mainboard. Unfortunately the RD1 does not work on the nVidia CK8-04 CRB mainboard. The CK8-04 CRB may require a flash device that the RD1 does not support.

The RD1 has worked well as a "do nothing" adapter that allows swapping the BIOS flash device between a flash burner and a mainboard without any wear to the mainboard's BIOS socket.

Can I do any serious damage mucking around with this stuff?

Any time you stick your hand into an open machine while the power is on, you're risking life and limb. That said, there are also some other not-so-nice things that can happen if you mess up (not that we would know).

  • Incorrect insertion of the flash (1 casualty)
  • Incorrect jumper settings (1 casualty)
  • Aggressive and/or inappropriate use of metal objects such as screwdrivers (2 casualties)
  • Miscellaneous miswirings and mishandlings (3+ casualties)

A note on electrostatic discharge (ESD) and ESD protection (thanks to Bari Ari)

ESD can damage disk drives, boards, DoC's and other parts. The majority of the time, ESD events cause the component to degrade, but not fail testing procedures, resulting in failure at a later date. Because components do not fail immediately, technicians often underestimate the cost of not using ESD prevention measures. Provide at minimum some ESD protection by wearing an antistatic wrist strap attached to the chassis ground on your system when handling parts.

Always handle boards carefully. They can be extremely sensitive to ESD. Hold boards only by their edges. After removing a board from its protective wrapper or from the system, place it component side up on a grounded, static free surface. Use a conductive foam pad if available. Do not slide the board over any surface.

To further reduce the chances of ESD, you should create an ESD safe workstation that includes at minimum:

  • Conductive rubber mat, with a lead wire that can be connected to a metal surface to create a ground.
  • ESD wrist strap, which has a resistor inside the strap and a lead wire that can be connected to a metal surface as a ground. The grounding wire on the wrist strap should have between 1 and 10 Megaohms of resistance. The resistor should protect you in case you come in contact with a voltage source. If the resistor is bad or not included, the wrist strap is useless. An accidental shock could be serious and even deadly!
  • Table or workspace that is clean, clear of dust, and away from electrical machinery or other equipment that generates electrical currents.

The idea is to ensure that all components you are going to interact with have the same charge. By connecting everything to the computer case, you ensure that the components of the case, the chair, and your body all have the same charge. If every object has the same charge, the electrons will not jump from one object to another minimizing the risk of ESD damage.

How do I turn off embedded sis630 devices?

From aip@cwlinux.com Mon Mar 25 08:54:07 2002 
Date: Mon, 25 Mar 2002 22:07:54 +0800 
From: Andrew Ip 
To: Kei Furuuchi 
Cc: linuxbios@lanl.gov 
Subject: Re: How to turn off unused pci device. 
> I have pcchips m758lmr which has audio chip besides sis630. 
> those functions in sis630 are not used in the motherboard. 
> But, the functions keep coming up. How do I turn off those? 
The following is from Nikolai Valdych previous message. Hope this help. 
Andrew Ip 
Email: aip@cwlinux.com 
Actualy, it was pretty simple 0x7c00 - All devices enabled, You play with first 4 bits only. Cos there are 4 devices, so you have any combination of 4 bits. 
Set bit to 1 to turn off the device, bit 0 to enable it. 
This is the device list: 
Multimedia Audio controler 
Modem controler 
Ethernet sis930 controler 
USB controler. 
For example, to turn off Ethernet + USB it would be: 
0x7c0c -> 1100 in binary (first 4 bits) 
To turn off Multimedia audio : 
0x7c01 -> 0001 
in binary and so on... maybe there are more detail, but this is enogh for me, Ollie, again thanks! 
p.s. though my modem is not yet working..... damn driver...... 

What is a PIRQ table?

From Adam Sulmicki: 

I found beautfiul descrition of the BIOS implementation of the PIRQ in the red PCI book.

I found the description of the $PIR data structure in the

looking over linuxbios sources I see that it saves the $PIR data structure
somewhere between 0xf0000 & 0x100000.

so it seems I'll have to search for $PIR and then save it before copying
over our bios. sigh. hoped for some fixed address in mem.

http://www.eax.com      The Supreme Headquarters of the 32 bit registers

How do I set up etherboot with LinuxBIOS?

Note from Ron: I have edited this somewhat to remove Geode-specific items.

Christer Weinigel writes: 
To: rminnich@lanl.gov
Cc: linuxbios@lanl.gov
Subject: Re: LinuxBIOS + Etherboot HOWTO?

I had some trouble using LinuxBIOS + etherboot... 

My bad, I messed up and used mkelfImage-1.6 that I got from ftp.lnxi.com, when I realized that I ought to use the one from freebios/util everything started working. 

Here's what I did to get LinuxBIOS + Etherboot loading and booting a Linux kernel using TFTP. 


Get etherboot-5.0 from the CVS tree on etherboot.sourceforge.net. 

Modify etherboot-5.0/src/Config, comment out: 

   # BIOS select don't change unless you know what you are doing
   #CFLAGS32+=     -DPCBIOS

and uncomment the following: 

   # Options to make a version of Etherboot that will work under linuxBIOS.

Compile Etherboot to make an elf file for your ethernet card: 

    make bin32/natsemi.elf

Compile and install mkelfImage from freebios/util/mkelfImage. 

Create a bootimage to put on your TFTP server: 

   mkelfImage --command-line="root=/dev/hda2 console=ttyS0,38400" \
              --kernel vmlinux -o /tftpboot/kernel

Finally, make sure that your BOOT/DCHP server is answering and that the TFTP server is active. 

Tell LinuxBIOS to boot an elf Image, and tell LinuxBIOS where it is: 

   option USE_ELF_BOOT=1

I have placed natsemi.elf in the first 64k of my BIOS flash chip, and LinuxBIOS in the second 64k. 

   insmod bios.o
   dd if=natsemi.elf of=/dev/bios bs=64k
   dd if=linuxbios.rom of=/dev/bios bs=64k seek=1

Finally boot LinuxBIOS. 

How do I set GEODE video?

Please see here.

How do I set up testbios?

From daubin@actuality-systems.com Wed Oct  6 10:23:10 2004
Date: Tue, 5 Oct 2004 15:19:24 -0400
From: Dave Aubin 
To: linuxbios@clustermatic.org
Subject: RE: Testbios help with nvidia 6800Gt and simple how to

I've taken the time to put together a simple testbios faq.
I hope it is helpful.  Feedback and additions are welcome. 


Testbios (vgabios) Faq

Date: 10/5/2004 Author(s): David Aubin daubin@actuality-systems.com

Purpose: Testbios is an i386 emulator that sits on top of userspace linux. It's primary purpose is to provide program video rom's in to the cached memory area.

Where to obtain testbios

Testbios(vgabios) can be retrieved from the linuxbios/freebios source tree: [1]


You must have installed pci-utils

How to build testbios
  • cd freebios/util/vgabios
  • Edit ./Makefile and fill in the correct values for your environment (I build on a 64 AMD so my makefile looks like this)

Begin ./Makefile for x64:

CC       =  gcc
ARCH     := $(shell uname -m | sed -e s,i[3456789]86,i386,)
INCLUDE  =  -I ../pciutils-2.1.11
CFLAGS   =  -Wall -Ix86emu/include -O2 -g $(INCLUDE)

INTOBJS  =  int10.o int15.o int16.o int1a.o inte6.o
OBJECTS  =  testbios.o helper_exec.o helper_mem.o $(INTOBJS)
LDFLAGS  =  -static-libgcc -static

LIBS     =  x86emu/src/x86emu/libx86emu.a ../pciutils-2.1.11/lib/libpci.a

# user space pci is the only option right now.
OBJECTS += pci-userspace.o

ifeq ($(shell if test "$(ARCH)" == "x86_64" ; then echo 1; fi), 1)
        CFLAGS +=-m32 -march=i386

        all: testbios

        testbios: $(OBJECTS) $(LIBS)
                $(CC) $(CFLAGS) -o testbios $(OBJECTS) $(LDFLAGS)

helper_exec.o: helper_exec.c test.h

        $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux

                $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean
                rm -f *.o *~ testbios 

        distclean: clean
                $(MAKE) -C x86emu/src/x86emu/ -f makefile.linux clean

End ./Makefile

  • Edit ~vgabios/x86emu/src/x86emu/makefile.linux and fill in the correct values for your environment (I build on a 64 AMD so my makefile looks like this)

Begin ~vgabios/x86emu/src/x86emu/makefile.linux:

#                                               Realmode X86 Emulator Library
#               Copyright (C) 1996-1999 SciTech Software, Inc.
#  Permission to use, copy, modify, distribute, and sell this software and
#  its documentation for any purpose is hereby granted without fee,
#  provided that the above copyright notice appear in all copies and that
#  both that copyright notice and this permission notice appear in
#  supporting documentation, and that the name of the authors not be used
#  in advertising or publicity pertaining to distribution of the software
#  without specific, written prior permission.  The authors makes no
#  representations about the suitability of this software for any purpose.
#  It is provided "as is" without express or implied warranty.
# Descripton:   Linux specific makefile for the x86emu library.

TARGETLIB = libx86emu.a

debug.o \
decode.o \
fpu.o \
ops.o \
ops2.o \
prim_ops.o \

        ar rv $(TARGETLIB) $(OBJS)

       INCS   = -I. -Ix86emu -I../../include
       ARCH   := $(shell uname -m | sed -e s,i[3456789]86,i386,)
       ifeq ($(shell if test "$(ARCH)" == "x86_64" ; then echo 1; fi), 1)
               CFLAGS +=-m32 -march=i386

#       gcc -m32 -march=i386 -g -O -Wall -c $(CFLAGS) $(INCS) $*.c
        gcc -g -O -Wall -c $(CFLAGS) $(INCS) $*.c

#       gcc -m32 -march=i386 -c $(CFLAGS) $(INCS) $*.cpp
        gcc -c $(CFLAGS) $(INCS) $*.cpp 

        rm -f *.a *.o

validate:       validate.o libx86emu.a
        gcc -o validate validate.o -lx86emu -L.

End ~vgabios/x86emu/src/x86emu/makefile.linux

  • Once built you could have a 32bit testbios executable made. Depending on your embedded environment you might want to have it built shared as the above example makes it static. Just remove -static-libgcc -static from the LDFLAGS on ./Makefile if you wish to have it built shared.
How to retrieve a good video bios

Note: if you are following these instructions to build LinuxBIOS for your motherboard, this is only necessary if you have a motherboard with an embedded VGA card. If your VGA is an add-on card, LinuxBIOS will find and run the ROM by itself.

Anton Borisov has released a number of tools under the GPL (v2) to extract the VGA BIOS from the BIOS ROM images provided by the supplier of your motherboard.

You can download them here:

 Award BIOS: http://kaos.ru/biosgfx/download/awardeco-0.2.src.tar.gz
 AMI BIOS: http://www.kaos.ru/biosgfx/download/AmiDeco_0.31e.src.tar.gz
 Insyde BIOS: http://www.kaos.ru/biosgfx/download/InsyDeco_0.3.src.tar.gz
 Phoenix BIOS: http://www.kaos.ru/biosgfx/download/PhoenixDeco_0.33.src.tar.gz

See the Tyan S2881 Build Tutorial for more information on how to use these tools.

Alternatively, there are sites that have video bios roms on their website. Google is your friend, as always.

In some cases, you should also be able to retrieve your own video bios while running linux. Note however that this does NOT always work. In the case of the Tyan s2881, for instance, this method will generate a 32KB VGA ROM image that is invalid - the real VGA ROM image is 36K long, but the last 4K is not available in RAM, and thus can not be extracted with the following method.

  • Boot up a machine with a commercial bios (not linux bios) with the video card you wish to work under linux bios.

You can see where your vga bios starts and how much space it takes by issuing

 cat /proc/iomem | grep "Video ROM"
  • To extract the bios, enter this command on the command line:
 dd if=/dev/mem of=vgabios.bin skip=1536 count=128

Alternatively, you could use:

 dd if=/dev/mem of=vgabios.bin bs=1k skip=768 count=64

This assumes you card's bios is cached in 0xc0000, and is 64K long. If your bios starts at 0xc0000 and ends at 0xc7fff it is only 32K long, and you need this command:

 dd if=/dev/mem of=vgabios.bin bs=1k skip=768 count=32
      • dd Explained (man dd to learn more):
        • if is the location to retrieve from.
        • of is the output file (your rom image)
        • bs is the block size (the default is 512 bytes)
        • skip jumps n blocks in the source data
        • count is how many blocks you wish to read
    • You now have a video bios image
How to use testbios
  • Currently testbios only works from user space linux (10/4/04)
  • Example from a linux command line or script enter the following to get your video bios programmed:
    ./testbios -d 0x90 -s 65536 --abseg /dev/mem ./vgabios.bin
    • Testbios explained
      • -s how much of the video bios is there
      • --abseg where would you like to write this (/dev/mem default)
      • -d device busdevfun in packed from
        • How to get pci busdevfn in packed notation
        • lspci
        • look for your video card
          • Example:
            2 (00 << 3) | 00 = 0x200
          • Example:
            0 (12 << 3) | 0 = 0x90
      • -t dump
      • -c codesegment Where do you want to start, default is 0xc0000
      • -b base Where do you want base to be default is 0xc000
      • -i instruction pointer usually left off as the default
      • filename of video bios

Followup to Testbios FAQ

See the thread starting here.

/usr/sbin/iasl: Command not found

If you see this error, you have to install iasl, Intel's ASL Optimizing Compiler:

How can I write to port 0x80 from userspace?

This might be useful sometimes:

printf "\001" | dd bs=1 seek=128 of=/dev/port

Probably Obsolete Items

How do I burn a DoC?

Currently, only the DoC Millennium is supported. See the documentation.

How do I put a filesystem on DoC?

OK, here is a little HOWTO on how to set up MTD with a file system.

This is a m810lmr, booting out of DoC. I am going to reserve the first 2M for kernel. So the layout will be the first 2M for linuxbios and kernel, and 6M for a file system. Kernel is 2.4.17, with linux-2.4.17-sis.patch from linuxbios source tree, and config-2.4.17-sis from the linuxbios source tree. Mainboard is the pcchips m810lmr.

So I:

modprobe doc2001 
modprobe docprobe 

which shows:

DiskOnChip Millennium found at address 0xFFFC8000 
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba TC58V64AFT/DC) 
1 flash chips found. Total DiskOnChip size: 8 MiB 
mtd: Giving out device 0 to DiskOnChip Millennium 
Ignoring DiskOnChip Millennium at 0xFFFCA000 - already configured 
Ignoring DiskOnChip Millennium at 0xFFFCC000 - already configured 
Ignoring DiskOnChip Millennium at 0xFFFCE000 - already configured 
Ignoring DiskOnChip Millennium at 0xFFFD0000 - already configured 
Ignoring DiskOnChip Millennium at 0xFFFD2000 - already configured 
Ignoring DiskOnChip Millennium at 0xFFFD4000 - already configured 
Ignoring DiskOnChip Millennium at 0xFFFD6000 - already configured 
Now I need MTD utilities. 
So I: 
cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs login 
CVS password: 

(password is anoncvs) 
cvs -d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd 

Forget the drivers and such, you don't need them. What you need is the tools.

cd mtd/tools 

Go ahead and copy the executables somewhere handy, you'll need them.

Now we need to make the last 6M into a "disk". We need to format it. The tool is nftl_format, so:

[root@carly util]# ./nftl_format 
$Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ 
Usage: ./nftl_format [ []] 
[root@carly util]# expr 2048 \* 1024 
[root@carly util]# expr 6 \* 1024 \* 1024 
[root@carly util]# ./nftl_format /dev/mtd0 2097152 6291456 
$Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $ 
Phase 1. Checking and erasing Erase Zones from 0x00200000 to 0x00800000 
Phase 2.a Writing NFTL Media Header and Bad Unit Table 
Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table 
Phase 3. Writing Unit Control Information to each Erase Unit 

we now have a formatted disk in there. We can now partition it.

[root@carly util]# modprobe nftl 

dmesg shows LOTS of errors, since this was never partitioned ...

Also, if you don't have /dev/nftla,

[root@carly util]# mknod /dev/nftla b 93 0 

Don't use the script just yet, it makes /dev/nftla as b 93 16, which is the wrong unit #.

now fdisk /dev/nftla

[root@carly util]# fdisk /dev/nftlA 
Command (m for help): n 
Command action 
e extended 
p primary partition (1-4) 
Partition number (1-4): 1 
First cylinder (1-1, default 1): 
Using default value 1 
Command (m for help): p 
Disk /dev/nftlA: 1 heads, 12224 sectors, 1 cylinders 
Units = cylinders of 12224 * 512 bytes 
Device Boot Start End Blocks Id System 
/dev/nftlA1 1 1 6111+ 83 Linux 
Partition 1 has different physical/logical endings: 
phys=(768, 0, 0) logical=(0, 0, 12224) 
Partition 1 does not end on cylinder boundary: 
phys=(768, 0, 0) should be (768, 0, 12224) 
Command (m for help): w 
The partition table has been altered! 
Calling ioctl() to re-read partition table. 
WARNING: If you have created or modified any DOS 6.x partitions, please see the fdisk manual page for additional information. 
Syncing disks. 
[root@carly util]# mknod /dev/nftlA1 b 93 1 
[root@carly util]# mke2fs /dev/nftlA1 
mke2fs 1.23, 15-Aug-2001 for EXT2 FS 0.5b, 95/08/09 
Filesystem label= 
OS type: Linux 
Block size=1024 (log=0) 
Fragment size=1024 (log=0) 
1528 inodes, 6111 blocks 
305 blocks (4.99%) reserved for the super user 
First data block=1 
1 block group 
8192 blocks per group, 8192 fragments per group 
1528 inodes per group 
Writing inode tables: done 
Writing superblocks and filesystem accounting information: done 

This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.

[root@carly util]# mount /dev/nftlA1 /mnt 
[root@carly util]# cd /mnt 
[root@carly mnt]# df . 
Filesystem 1k-blocks Used Available Use% Mounted on 
/dev/nftlA1 5915 13 5597 1% /mnt 
[root@carly mnt]# 

and so you now have an ext2 file system on the DoC.

(Above is from Ron Minnich)