From owner-freebsd-hackers Sat Jul 19 07:32:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA27466 for hackers-outgoing; Sat, 19 Jul 1997 07:32:02 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA27444 for ; Sat, 19 Jul 1997 07:31:57 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id AAA14199; Sun, 20 Jul 1997 00:01:49 +0930 (CST) From: Michael Smith Message-Id: <199707191431.AAA14199@genesis.atrad.adelaide.edu.au> Subject: Re: SMBIOS/DMI etc In-Reply-To: from Mike O'Dell at "Jul 19, 97 09:56:19 am" To: mo@UU.NET (Mike O'Dell) Date: Sun, 20 Jul 1997 00:01:49 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, mo@UU.NET, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 [[