BIOS

[Steffen Grunewald]

On Wed, Aug 15, 2007 at 05:44:49PM +0200, Henning Fehrmann wrote:
> 
> We worked a while on the problem of flashing a bios and writing into the nvram of the motherboard.
> Here is a recipe which is still under development. Maybe somebody needs it.

Congratulations for getting thus far!

> Create a bootable dos image
> 
>    1. Go to http://www.freedos.org/ and download an installation-cd image, burn it onto a cd
>    2. Install freedos on a box. We tried it on
>          1. a Single-Dual Core Opteron 2218
>                1. with a Supermicro H8SSL-i2 board
>                2. and WD 1600YS SATA hd's 
>          2. a Single-Dual Core Xeon 3060
>                1. with a Supermicro PDSML-LN2 board
>                2. and WD 1600YS SATA hd's 
>          3. We have not been able to install freedos on a box with a Fujitsu Siemens D2461-A2 board but you can readout and write the board's nvram in a running system 
>    3. Create a dos partition which starts from the first sector using the dos fdisk tool and format it with fat16. Make this partition not to big, since it has to go with pxeboot over the net. We toke approximately 32M.
>    4. Install a basic dos environment with mbr writing tools (smbtmgrx) and other programs you consider to be useful.
>    5. Reboot the box and go into the dos environment, execute a mbr writing tool.
>    6. Reboot again using liveCD Linux system (Knoppix).
>    7. Copy the first 63+N blocks of the hd into a file dd if=/dev/sda of=hd.img bs=512 count=63.
>    8. Copy the the complete dos partition into another file dd if=/dev/sda1 of=dos.img bs=512.
>    9. Combine the files dd if=dos.img of=hd.img bs=512 seek=63 and copy hd.img onto the tftp server. 

This IMHO could be done without touching a real disk's MBR using a file (untested).

> Modify the Image
> 
> The idea is to mount the image to put different tools on there. Unfortunately, the image we just created has an MBR, which mount complains about. To get around that, we cut off the first (in our case: 63) blocks. The dos partition starts on block 64. dd if=hd.img of=dos.img bs=512 skip=63. To find out at which block the partition starts, you can search for the ASCII-string "FRDOS4", which indicates the beginning of a dos partition. This is a dos partition which can be loopback mounted. Copy the needed files into the mounted path. After umount, you update the image of the hd partition using dd again, with the seek parameter indicating the blocks you keep:
> dd if=dos.img of=hd.img bs=512 seek=63.

IIRC loopback mount has an option to skip to an offset inside the image... man mount

> Fill the dos partition with the tools and drivers you need. For us, this was basically:
> 
>     * WATT-32 (TCP/IP stack for DOS) http://www.bgnett.no/~giva/ 

Is there a binary version I have missed when I last looked?

>     * card driver    http://www.georgpotthast.de/sioux/packet.htm

You might also use the UNDI driver that sits on top of the PXE in the card's firmware.

>     In our case it worked with broadcom ethernet cards 
>     * ssh2dos        http://sourceforge.net/projects/sshdos
>     * and misc. tools like vim 
> 
> 
> Booting the dos image
> 
> Assuming you use pxelinux, you can put this in the appropriate config file for the boot start:
> 
>  default fai-generated
> 
>  label fai-generated
>  kernel kernel/memdisk
>  append initrd=path/to/hd.img
> 
> * After that, you should be able to boot into the dos image and see all the tools you have put there. 
> * Next, you need to load the appropriate network drivers. 
> * Search for the bios flash and nvram reading and writing tools.
> * The ssh client works with a key, so you avoid the passwd prompt.
>   ssh the FAI server and change the pxelinux.cfg files to initialize the FAI installation (fai-chboot). 

Of course that's a more elegant solution than having a fake TFTP request which would
trigger an action on the server side. Why didn't you go for a simple rsh instead, which
is already a prerequisite for FAI (writeback of install logs)?

> * reboot
> 
> Put everything in the autoexec.bat and it works automatically. (Has not been tested yet)

If you don't mind I'd like to have a look at your image. I'd suggest to have 
an interface to the possible tasks as clean as possible so that changes to
the payload have to be done in only one place (our vendor for example uses
a zip file that contains the payload, which is unpacked into a ramdisk, and
it's setup.bat is started - this way the autoexec.bat stays unmodified if
you replace the payload) - KISS :-)
(My images are in CVS, faiconfig/files/boot/fai/floppy-images/)

Cheers,
 Steffen