Next Previous Contents

5. HOWTO VIA EPIA-M motherboard case

The objective of this part is to describe how to boot a kernel with a Linuxbios. In order to realize it are deployed Linuxbios studied solutions. Mainly, it is and howto for developpers to deploy quickly a Linuxbios prototype using theses "solutions". Thus it condenses at most previous work behind this document. If you get yourself directly parachuted in here, consider reading some part of the study if you are in trouble.

It was a choice to make the distinction between study and all that is not what is you're going to read g, Study explains while describing functionnalities, while demonstrating how it works, while theorically conjecturing about. This pure HOWTO implement what is bound to this study and well really sets practically what I was enable to achieve onto VIA EPIA-M based machine. (Without any other conjecture) Therefore alternatively this part also express this gap and go further to put Mangrove Linuxbios on a derivated development branch.

5.1 How to get started

Primarily it is vital to gather specifications of your build machine and your target machine hardware as I did (cf. my build machine). Launch a lspci -vv > myconfig to get your config. and dump it to file because if you go for help in forum, you could then send it to basically express what type of config. you have.

Check out how up all your hardware is supported, look for motherboard support page on Linuxbios project site (cf. ref. Linuxbios project). If you have a VIA EPIA-M 1000 note that it is almost fully supported. For each type of solutions, it is another matter so try to early answer to that Skakespearian "supported or not" question, scour the site forum. (cf. landmarks to forum maillist archive). If not also I let you know you always could then realize a port from a supported motherboard or/and ask for help to do it.

Check out Project's tools and resources part for some details.

Finally get your development/experiement platform up to date in order to prevent any versionning trouble :

o There you'll find the toolchain to build a Linux kernel

o There you'll find the toolchain to build a Linuxbios.

Personally I used a Red Hat 9.0 because it complies with all the above referenced requierements. Note that by the time I worked on Linuxbios, I found not ext3 filesystem support, so checkout if ext3 is supported and for what boot solutions it is or consider booting on an ext2.

This consideration is bound to how you prepare your Linux kernel payload. Also you should know what is your Linuxbios specific needs. Check out theses innerdoc links to draw out yours :

o Know what are Linuxbios pros and cons, there in feasability section of Project part.

o Know what is your boot wish, there in boot solution study.

Ok let's go. Edit your mainboard/via/epia (main) Tweak everything like you want, take a glance to following option explanations

        Activates debugging mode.

        Transmission speed on the (crosswired) RS232 cable DB9 pins. Faster is best...

        Levels are described in arch/i386/include/printk.h. 
        1 : EMERG       4 : ERR         7 : INFO
        2 : ALERT       5 : WARNING     8 : DEBUG
        3 : CRIT        6 : NOTICE      9 : SPEW        10 : everything

        Number of boot tries

        Activates POST debuging if you have a POST compliant device... 
        or not anyway you'll have a hex decimal POST indication telling what stage of
        the boot sequence you're at.

        Indicates to the booter/bootloader that ROM image is compress or not.

  HAVE_HARD_RESET=1 (better not to touch this)
        Hot reset handling.

  i686=1 or i586=1
        Set them to 1. It's architecture specific registers parameters.

        Usefull in some case (which one ?). Patch for CPU, just activate it
        if it wrecks everything turn it off, if it still wrecks all plus your 
        head... go have some aspirin.

        Graphic MTRR registers.

        Part of the Linuxbios table.

        -"The J option"
        Unset it if you really believe there are spiders on Mars.        
        BIOS compound/CMOS chip you have to store your Linuxbios (ROM_SIZE value in bytes)
        Fallback mode size in Linuxbios ROM (number value is expressed in bytes)

        Begin of Linuxbios code into the CMOS.

        Activates boot on IDE.

        Open a stream onto the filesystem. By default also activates builtin booter/bootloader FILO.

        Open a strean onto a linear memory structure. (ROMBOOT)

 AUTOBOOT_CMDLINE="hda1:/vmlinz root=/dev/hda3  console=tty0,ttS0"
        Booter/Bootloader boot command line and parameter passing to kernel.
        IF NO STREAM IS OPENED, Native buildin booter/bootloader ELFBOOT is in charge. 

        Activates x86emu emulation for VGABIOS.

        Pointer on the VGA Bios code in Linuxbios ROM.

        Relay debugging strings to serial port.

        Active a uniq console, the 'sole console'.

        Active a graphical console supporting X11.

Equally, look at the romimage structure

romimage 'fallback'
        Section title : fallback or normal ROM image.

        Fallback ROM in case of normal feinting.
        Taille de la rom de secours.

  mainboard via/epia
        Mainboard which it is supposed to boot

  payload null
        Payload to boot with. Null indicates nothing of course, or 
        rather that it is an internal solution ELFBOOT or FILO (elf format)


Now properly launch buildtarget on via/epia. You must have something pretty much like this.

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

Check out Makefile.settings file or Makefile.rules... err check out makefile config files to compare with this :

Normal rom sizing value :
export ROM_IMAGE_SIZE:=0x10000
export PAYLOAD_SIZE:=0x0
export _ROMBASE:=0xfffc0000
export CONFIG_ROM_STREAM_START:=0xfffc0000
export ROM_SIZE:=0x40000
export FALLBACK_SIZE:=0x30000
export ROM_SECTION_SIZE:=0x10000
export XIP_ROM_SIZE:=0x10000
export XIP_ROM_BASE:=0xfffc0000

fallback rom sizing value :
export ROM_IMAGE_SIZE:=0x10000
export PAYLOAD_SIZE:=0x20000
export _ROMBASE:=0xffff0000
export CONFIG_ROM_STREAM_START:=0xfffd0000
export ROM_SIZE:=0x40000
export FALLBACK_SIZE:=0x30000
export ROM_SECTION_SIZE:=0x30000
export XIP_ROM_SIZE:=0x10000
export XIP_ROM_BASE:=0xffff0000

Unless "you know what you're doing" (Pat.:) if you don't have this values... umm... figure out why, because it is going to waste your time compiling before reaching an error.

Then it's time to launch make, type it. You have your linuxbios.rom, so get it saved somewhere and prepare to flash. Replace with care, unsolder the bios chip with a adapted tweezer (yes, when your mainboard is online ! If you're not feeling confident with this read flash solution study.)

Place your new erased chip in (your target machine CMOS slot of course). Find the flash_rom utility into the Linuxbios source tree. Basically you need to launch a flash_rom linuxbios.rom. If your chip is supported this utility will find it. If not, change tool... still not change compound... still not ? you must be kidding... If you want to erase your chip, there must be a switch to do this... Anyway, consider creating a zero filled file to flash with, use a dd if=/dev/zero of=zerofile bs=1024 count=rom_size_in_KB command to create that file.

Programming Page: address: 0x0003f000
Programming chip... Stand by for 40 seconds approx...
Calibrating timer since microsleep sucks ... takes a second
Setting up microsecond timing loop
144M loops per second
OK, calibrated, now do the deed
Enabling flash write on VT8231...OK
Trying W49F002U, 256 KB
probe_jedec: id1 0xda, id2 0xb
W49F002U found at physical address: 0xfffc0000
Part is W49F002U
Programming Page: address: 0x0003f000
All right.

Get your cable set properly, between host and target. Launch the hear script. Do not forget to have in the same directory, the digest script also. Ok, if you feel low on bash scripts, you can still use minicom. But in this case, for this target, this is really too much. Maybe you're using Linuxbios for embedded devices, true guess ? Well then embedded means least "structure", so just size your soft properly and stick to this.

Well that's it, your bios is over. Congratulations ! And what about adding a VGA BIOS to your BIOS in order to take advantage of activated parameters and of a full-featured modern bios !

5.2 How to go (a bit) further (in with the VGA display on target)

Having a target standalone display is far from being superficial. So you can wonder why I come to this at the end. Look, if you want your Linuxbios to run an appliance, a black box, for example a machine such as a router do you really need any sort of display, I mean when it'll run stable ? Do you need a VGA display ? Remember syslog facility is able to redirect a logging facility to a remote host.

Ok, you know what you're doing anyway I was just proposing...Right, you need to do some handcraft in here.

Recent Linuxbios developments must been hiding this, check for updates. All the same, what fellows surely stands still behind.

You need first to recover original video bios (check display solutions study to know why). It is maximum 64KB long, EPIA's one is 44KB long. Let's assume it begins in 0xC0000 and ends in 0xD0000, because it is often true (check out with a hexdump tool if it is coherent). The beginning has a ELF header which size is 0x01000. You'll have to cut from 0xC1000 because that header will be rebuilt. As a result, pure VGABIOS code is 0xC1000-0xD1000 that is to say from 790528th byte to the 856064th byte (clue : conversion powered by bc)

Kcore is a peculiar entry in the /proc filesystem which is by default compiled in ELF format in the Red Hat 9 kernel. Check if you have something relevant by doing something like : readelf -e /proc/kcore . Kcore express all the physical mapped memory by the kernel, thus it fluctuates in "real-time". The next command with fetch back the VGABIOS in kcore.

        dd if=/proc/kcore of=video.bin bs=1\
           count=65536    skip=790528

Resulting video.bin is your original VGABIOS. Heh, remember this better be done with the original BIOS plugged onto target machine, EPIA mainboard CMOS slot. Then you could safely test your video.bin file with testbios from V1/util/vgabios/testbios. To do so, you'll need a proper graphical framebuffer driver to get insmoded.

       insmod fbdev.o &&\
       ./testbios -s 65536 video.bin

I've hacked up in speed some graphical test scripts to test video display, since they actually stress framebuffer and framebuffer driver actually do VGABIOS calls, it should somehow test VGABIOS. If you want to measure a more specific performance, you'll consider finding a real tool to do so.

Endly you can concatenante your VGABIOS with linuxbios.rom file after the rom making stage, look at bios's ROM structure to see where to operate precisely. So you basically needs to do this : cat linuxbios.rom video.bin >linuxbios

Flash the linuxbios resulting file as explained in the upper howto section. If you have something stable, remember disabling all debug features and compiling a new Linuxbios...theses slown down boot time. If you spared so much space that it is just remaining finally too much space, know that you can add a bootsplash screen bitmap at boot startup !

Pardon ? Yes true, VGABIOS is a binary image copy. So if you want a compiled from source VGABIOS note that OpenGraphic project development aims towards provinding a generic graphic support.

There you have a Linuxbios CMOS running ? well you know it's not over. You're happy-happy yet still wondering when or why, that super feature you dream of, will be implemented and how it will be. Then think in 3d : derivate, deploy, develop !

Next Previous Contents