New subject: Random comments on LinuxBIOS

16 Apr 2003


      "McMechan, James W CIV" james.mcmechan@navy.mil writes:
...
Here is what I wrote while trying to catch up to list, though there is a FAQ I
produced this while working my way through the emails perhaps some of it could
be added to the FAQ
Would you be interested in maintaining or helping to maintain the FAQ?
You seem to have a nack for putting the information together.
...
LinuxBIOS is a project to replace the original BIOS on motherboards with open
source.
It appears that the two most common uses for LinuxBIOS are for Supercomputer
clusters and embedded systems.
LinuxBIOS no longer always uses a real OS to load the OS.
That is not quite correct.
LinuxBIOS requires a real OS, or at least a piece of software
that can run standalone without any OS or BIOS services on
the bare hardware.  Which is essentially the definition of
a real OS though it is not the definition of a general purpose
OS.
In the case of ADLO, ADLO can be considered a special purpose
OS that mimics the syscall interface of a standard BIOS.
...
LinuxBIOS currently can boot several payloads including:
1 Linux which is what started all this, hence the name.
2 Plan9 Ron Minnich seems to like this one.
3 VxWorks Felix Radensky said he had success with a older boot method
4 EtherBoot which despite its name can also boot from IDE hard disks with a
patch or the dev branch
5 ADLO is a shim to allow the Boch emulator's BIOS to be used on top of
LinuxBIOS to boot some versions of that other OS or to run VGA controller ROMs
which seem to assume that a BIOS is present.
?
The Supercomputer people appear to want remote control, remote booting and fast
boot times without user interaction. For example "Press F2" is a very
inconvenient task on a system with 100 computers
The embedded people appear to want full control of the boot process and very
fast boot times. For example who wants to watch a memory test go by on their
VCR/MP3 player or see "Press F2" without a keyboard.
In addition there is some background work on secure/trusted booting.  I don't
know if anything has really happened with that yet, but ADLO grow out of
the interest in trusted booting.
...
LinuxBIOS is installed into the flash ROM in place of the original BIOS.
Most flash ROMs are currently 2 Megabits in size, i.e. a 29SF020 which is only
256 Kilobytes of storage, or some might be 4 Mbit ROM which provides 512 Kbytes
and so could allow for very squeezed down Linux kernel to also be included in
the ROM, though I don't know of a useful kernel that small.
It would be nice to add a larger flash ROM but many motherboards do not connect
enough address lines to the Flash ROM socket, for even the 4 Mbit part or they
solder the chip down.
For LPC flash parts the address line count is not a real issue, new boards
have them and they current are up to 8Mbit in size, but do not have a theoretical
limit.
...
Another popular if grumbled about option is the disk on a chip the DoC
Millennium which is a paged flash part that can have LinuxBIOS in the first part
and up to 8 Mbytes of other data on other pages of the chip. Very short ~3-10
seconds boot times should be possible with this method.
The BIOS Flash can usually be programmed in place by either just reflashing the
original BIOS or by the hotswap method also known as the dental floss method,
referring to putting dental floss under a PLCC chip to make it easy to remove
without requiring metal tools in a powered on system. The hotswap method is not
for the faint of heart but not all that difficult either, the system is booted
with a working ROM which is then pulled out and the ROM to be programmed
inserted in its place, then the ROM flashing program is run, and when done a
reboot can be tried, this does not require a programmer as it uses the
motherboards ability to update its BIOS as the programmer, if the reboot fails
the original ROM is reinserted and the system rebooted again, all this requires,
is some spare flash ROMs it is a good idea to make and label a couple backups
incase something goes wrong, I have put ROMs in DIP sockets backwards destroying
the ROMs, and ESD is a worry even if it is not a commo!
n problem.
Some people also use a very nice device called the BIOS savior which allows for
two BIOS ROMS to be switched by the user with a switch.
Compact Flash IDE adaptors appear to be popular as the CF does not need the spin
up time of a real hard disk. Very short boot times of ~3-10 seconds are claimed
for this configuration also.
Each model of motherboard currently needs its own build information due to a
lack of standards in how the circuitboards are laid out between models and
manufactures.
If you have a motherboard that is not listed, a "lspci" will show what chipsets
are in use and you can then check to see if they are in the LinuxBIOS tree, if
not some research may be needed to get the documentation for that chipset.
The kexec patches date back to the original LinuxBIOS with the Linux kernel in
the BIOS ROM and allowed for new kernels to be loaded and executed without
rebooting back to the BIOS this would allow for a minimal kernel in the BIOS and
a full featured kernel to be loaded by the first kernel. Also the BIOS ROMs have
a limited programming life and limited space so a small unchanging kernel that
then loads the final kernel from something else prolongs the useful life of the
ROMs.
Ron Minnich at LANL uses similar feature called "two kernel monte"
http://sourceforge.net/projects/monte/
LinuxBIOS now has the ability to make use of the CMOS space for fallback/normal
boot image selection, serial port baud rates, and boot order for Etherboot, Ron
Minnich also used it authentication information for a Plan9 cluster. See the
cmos.layout files for information.
Steven James had nice comments on Normal/Fallback images:
LinuxBIOS for that board (and many others) supports two copies of
LinuxBIOS, fallback and primary. The fallback image is intended to be old
and stable and it's purpose is to act as a sort of rescue image. The
primary image is the one that gets updated to the latest and greatest, and
is meant to be more versatile and complete.
And after the most recent update the ``hair trigger'' problem has been
solved.  In particular it now requires several boot failures in a row
before LinuxBIOS switches into fallback mode.  Generally this is 3 successive
failures.
...
The fallback image is loaded at the top of the flash, and always receives
control at power on or reset. It does very minimal setup (switch to 32bit
flat memory protected mode), checks and clears the CMOS boot bit, and if
it was set, jumps to the primary image. This way, if the primary fails,
hitting reset will boot from the fallback image alone.
The mechanism has been updated to keep a failure count in the CMOS and only
when the failure count crosses a threshold is the boot bit cleared.  The
counter is reset after LinuxBIOS has successfully loaded an image like
etherboot.
Etherboot now implements a similar scheme to allow two images on the disk.
One at the start one at the end, but installing an image at the end of
the disk still requires some work.
...
...
From your config, you were building a primary image. the missing bytes are
for the fallback image to be appended. It didn't work because you didn't
have a fallback image at the top of the flash (the end of the image file).
Ron Minnich expanded on fallback vs. primary:
You need to build TWO linuxbioses, a fallback and a primary. The fallback 
is 64k. The primary is (romsize-64k).
To build a romimage, you build the fallback, build the primary, then:
cat primary/romimage fallback/romimage > final_romimage
flash_rom final_romimage
Steve Gehlbach wrote about using BOOT_IDE:
See pcchips787.config in util/config for complete configuration.
Note significant pieces of this information are not using the ELF
bootloader, and so describes a deprecated feature.  But it will
not be removed in the 1.0.x stable series.  In the development series
the code will not be added.
...
option BOOT_IDE=1
This enables booting from IDE, the file to use is linux.bin.gz:
option IDE_BOOT_DRIVE=2
If you do not use drive 0  (default), then you can set which drive to 
boot; (0,1,2,3) are the four standard PC drives:
option ONE_TRACK=32
The linux.bin.gz file is put in raw form at partition 1, ie, the first 
partition on the disk.  This is located just past the partition table. 
The partition table size varies, it is "one track" from the beginning of 
the disk.  "one track" in c/h/s notation is "s" or the number of sectors 
per track.  ONE_TRACK is in sectors, the software multiplies by 512. 
Most disks are 63 sectors per track (the default), but my CF is 32 
sectors per track.  eg, the partion table is 63x512 or 32x512 bytes.
You can partition your disk as you want, but Linux goes raw in partition 
1; just make sure partition 1 is big enough, not a problem on today's 
disks.  You could put the Linux root file system on partition 2, for 
example.  In pcchips787.config, I put the Linux root file system on IDE 
0, partition 2 (I was experimenting with Linux in partition 1), but I 
eventually put Linux on drive 2 using CF.  You are right, copying of 
linux.bin.gz raw to the partition is dangerous, and something like "cat 
linux.bin.gz > /dev/hda1" will definitely screw the disk if you put the 
wrong disk or partition.  I recommend a shell script, fingers cannot be 
trusted.  You can also use "dd" but "cat" works.
Greg Watsons had some good comments on on the boot process and file layout:
There seem to be two main parts to linuxbios. The first is 
arch/{arch}/config/ctr0.base which does the very low level 
initialization, like turning on memory, etc. The second is 
arch/{arch}/lib/c_start.S which does whatever else is necessary to 
call the C function hardwaremain(). hardwaremain() then does whatever 
else is necessary to load Linux.
c_start.S is linked with linuxbios.a, a library containing generic 
support routines (those found in the lib directory) and anything 
specified using the 'object'  directive in a Config file (and other 
stuff). The resultant 'executable' is called linuxbios_c. The loader 
script used to link linuxbios_c is config/linuxbios_c.ld, and is 
configured to be loaded relative to _RAMBASE.
crt0.base is not linked against anything. Any additional assembly 
routines you need must be specified using the 'mainboardinit' 
directive in a Config file. This causes the specified assembly file 
to be added to "crt0_includes.h" which is in turn included at the 
start of crt0.base (or at the end in the case of the ppc version). 
The loader script used to link crt0.base is in 
arch/{arch}/config/ldscript.base. The resultant 'executable' is 
called linuxbios and will be loaded at _ROMBASE. The tricky thing is 
that this loader script will also load the linuxbios_c 'executable' 
at a location called _payload in this file. The main task of 
crt0.base is then to initialize enough hardware so that this payload 
can be copied from ROM into ram (which may also involve uncompressing 
code). Then control is transferred to _start, which is the first 
location in linuxbios_c.
To get an idea of how crt0.base works, look at the following files. 
This is the order of execution specified by the configuration file 
for sis735.
cpu/i386/entry16.inc
cpu/i386/entry32.inc
superio/sis/950/setup_serial.inc
pc80/serial.inc
arch/i386/lib/console.inc
cpu/k7/earlymtrr.inc
northsouthbridge/sis/735/raminit.inc
arch/i386/config/crt0.base
Next look at c_start.S which will show you what happens once control 
is transferred to _start. Finally, look at 
arch/{arch}/lib/hardwaremain.c to see what other stuff is done to get 
Linux loaded.
Most other files are specific to particular hardware, so it can be 
pretty confusing to just browse the tree.
Hope this helps,
It Looks like a very good summary.
Eric

Re: Random comments on LinuxBIOS