Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Jul 1997 00:01:49 +0930 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        mo@UU.NET (Mike O'Dell)
Cc:        msmith@atrad.adelaide.edu.au, mo@UU.NET, hackers@freebsd.org
Subject:   Re: SMBIOS/DMI etc
Message-ID:  <199707191431.AAA14199@genesis.atrad.adelaide.edu.au>
In-Reply-To: <QQcywl13112.199707191356@rodan.UU.NET> from Mike O'Dell at "Jul 19, 97 09:56:19 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Mike O'Dell stands accused of saying:
> 
> reading the info shouldn't be hard. it's just a couple
> of ISA IO ports (usual "address" and "value" stupidity).  it can
> do interrupts to either ISA or SMI. i haven't checked for certain,
> but i'd put a six-pack of beer that the BIOS programs it for SMI
> interrupts.

OK.  As long as it doesn't have one of those stupid "lock
configuration" bits, all will be well.

> at the moment, i'm trying to print the LM78 data sheets
> (on www.national.com as a PDF file) but Acrobat generates
> broken postscript!!! GRRRRRRRRRRRRR.....

It does?  Prints fine here to an HP JLIII ps cart or via ghostscript.
Try fiddling the level 1/level 2 option.

> BTW - has there been any thought to using the SMI mode?
> it essentially gives you one mostly-virtual processor. 

I'm not sure I follow you here.  All the SMI information I have
applies to the sucky SMI calling interface and function list (16-bit
protected mode?  Who do they think they're kidding?)

If you have more documentation references, I'm all ears.

If it's of any interest to you, the bios32 code I was working on
(knows how to locate the SMIBIOS and DMI tables in the BIOS image) is
available at ftp://smith.net.au/misc/bios32/.  It's mostly just a 
signature-hunter and some structure definitions.  

Stick bios32.c in i386/i386 and bios32.h in i386/include, add bios32.c
to files.i386 and reconfig your kernel.  It'll search for a BIOS32
Service Directory and then the _SM_ and _DMI_ cookies as well.

If you _do_ turn out to have a BIOS32 Service Directory, it'd be great
if you could :

 - change the #if 0 in bios32_init() to #if 1
 - build a new (test) kernel
 - boot to ddb (boot with -d)
 - set a breakpoint : `break bios32_SDlookup'
 - run to the breakpoint : `cont'
 - single-step through the BIOS routine that this calls and make a note
   of the value(s) that it compares %eax with.  

The reason I ask is just to attempt to identify whether the BIOS32
thing ever took off; I can't find _diddly_ about it online, but it
does appear to be reasonably widely implemented.

Sorry for the handholding ddb-walkthrough above; not sure how deep
your experience with it goes.  Note that you should expect a GPF when the 
BIOS routine tries to return; I don't know why.

> 	-mo
-- 
]] Mike Smith, Software Engineer        msmith@gsoft.com.au             [[
]] Genesis Software                     genesis@gsoft.com.au            [[
]] High-speed data acquisition and      (GSM mobile)     0411-222-496   [[
]] realtime instrument control.         (ph)          +61-8-8267-3493   [[
]] Unix hardware collector.             "Where are your PEZ?" The Tick  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707191431.AAA14199>