BIOS

[Don Holmgren]

We've had some limited success on L440GX motherboards with dumping,
under Linux, the CMOS data area on a node configured to our liking to a
file.  Most, and on some motherboards, all of the BIOS settings are
there.  Then, again under Linux on another _identical_ (same
motherboard, same BIOS revision) system we write the CMOS dump file to
the CMOS data area.  This often succeeds in fixing all of the
settings.  For very large clusters, this is a much better way of
controlling the BIOS settings.  We also use the serial line BIOS
redirects that Steve talks about, but automating the various BIOS
settings via the serial line is quite difficult - impossible without the
serial redirect!

Now for all the caveats.  There is an existing Linux interface to the
CMOS data area, via /dev/nvram, which takes care of computing and
writing the standard checksum (bytes 2E and 2F) which the BIOS uses
during its POST routines to verify that the CMOS data are not corrupted.  
You must open /dev/nvram, lseek to the byte you want to change, and read
or write and the driver will handle the checksum for you.  
Unfortunately, some motherboards like the L440GX have an additional CRC
which covers an undocumented group of bytes and which is computed in an
undocumented order (and so almost impossible to reverse engineer).  
During POST if the CRC isn't correct, the BIOS resets all the settings
to their default values.  Also, some motherboards use more than the
"standard" (if such a standard exists) number of bytes (/dev/nvram lets
you manipulate 50 bytes, IIRC).

Since L440GX boards use more than the standard set of CMOS locations, we
had to write codes that use ioports 0x70 and 0x71 to dump or to write
about 240 bytes in the nvram area.

If only the BIOS and motherboard manufactures would post memory maps for
the nvram area!

Don Holmgren
Fermilab



On Fri, 23 Mar 2001, Steven Timm wrote:

> It depends to some extent on which motherboard you are running.
> The Intel L440GX series, which is most of what we have here at FNAL
> currently, allows to direct the BIOS I/O out one of the COM ports,
> usually COM2.  We have some clusters where we have hooked these
> up to a console server and been able to access all the BIOS from there.
> 
> Intel has a very nice client to do this on the Windows side as well,
> unfortunately it can only cover four nodes at once and they are not
> planning to expand it.
> 
> It would in theory be possible to extend vacm (from VA Linux) to do
> this but the last I talked to their developers they weren't
> moving this way.
> 
> Steve Timm
> 
> ------------------------------------------------------------------
> Steven C. Timm (630) 840-8525  timm at fnal.gov  http://home.fnal.gov/~timm/
> Fermilab Computing Division/Operating Systems Support
> Scientific Computing Support Group--Computing Farms Operations
> 
> On Fri, 23 Mar 2001, Jared Hodge wrote:
> 
> > Howdy (That's Texan for "hello"),
> > 	I've got a question about setting BIOS settings on a cluster's nodes.
> > The way I've been going about making changes is moving the keyboard and
> > monitor to all of the nodes.  I'm sure this isn't what everyone does.  I
> > imagine there's a way to put the settings on a floppy or maybe even send
> > them over  the network, but I don't have any experience with this.  Has
> > anyone done this?  What's the typical way of doing this on one of the
> > really large systems where moving a keyboard and monitor from node to
> > node would be impractical?
> > --
> > Jared Hodge
> > Institute for Advanced Technology
> > The University of Texas at Austin
> > 3925 W. Braker Lane, Suite 400
> > Austin, Texas 78759
> >
> > Phone: 512-232-4460
> > FAX: 512-471-9096
> > Email: Jared_Hodge at iat.utexas.edu