Date: Thu, 18 Sep 1997 16:27:12 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, sos@sos.freebsd.dk, hackers@FreeBSD.ORG Subject: Re: INB question Message-ID: <199709181627.JAA17940@usr03.primenet.com> In-Reply-To: <199709181039.UAA00245@word.smith.net.au> from "Mike Smith" at Sep 18, 97 08:09:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> If Jonathan can get the early-kernel BIOS call stuff working, int15 may > still be the "right" way to go. Until then, how about you look for the > MCA configuration information? One would hope that its location and > format were documented. They are, sort of: INT 0x15 AH=0xCO: Gets a pointer to configuration information storead in the system BIOS ROM. This information often resides at F000:E6F5, but starting with the PS/2, IBM no longer retains a fixed location for this table. Bletch. Exactly the case I wanted. 8-(. > Note that Joerg's comment about a nonresponding bus giving random > values is *WRONG* for most busses; certainly at least ISA and PCI. > > The ISA specification explicitly requires bus pullup resistors. It may > be unwise to depend on reading 0xff back-to-back with a previous read/ > write operation, but the reader is welcome to calculate the RC time > constant for a transmission line with a few pF of capacitance and a 10K > (or less) pullup. Thank you. That's all I needed to know. The test I proposed seemed to work locally, but I don't have a lot of odd-ball hardware. > For PCI, I would expect Stefan or one of the PCI lawyers to have the > ultimate answer. I get the impression that PCI will actually generate > the equivalent of a "bus error" if a peripheral doesn't respond; in > reality the question is moot except in the face of defective hardware. Yes. So will EISA. That's why the port 0x84 inb is a lousy timing mechanism: it's the bus-sync cycle port, but it doesn't apply to ISA. 8-(. > Now, MCA. I *don't* have an MCA board here to look at, or the hardware > standard. If you are reading a port that is guaranteed to return a > known value on an MCA system, and the alternative is that there's > nothing there (ISA), then you are generally safe to assume that you can > expect 0xff to mean ISA, and (magic) to mean MCA. Yep. That's what I was looking at. > ... be wary of address ranges that may be inhabited by other > peripherals. That really goes without saying, doesn't it? Yeah; that's why I picked the extended MCA DMA ports for the detect; that, and I can do the probe non-destructively, with the expectation of a 0 bit in my data and no hardware configuratio changes resulting. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709181627.JAA17940>