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>