From owner-svn-doc-head@FreeBSD.ORG Mon Dec 10 15:31:02 2012 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 295ECF2C; Mon, 10 Dec 2012 15:31:02 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 0DA238FC1A; Mon, 10 Dec 2012 15:31:02 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.5/8.14.5) with ESMTP id qBAFV1MK045552; Mon, 10 Dec 2012 15:31:01 GMT (envelope-from eadler@svn.freebsd.org) Received: (from eadler@localhost) by svn.freebsd.org (8.14.5/8.14.5/Submit) id qBAFV1Y9045551; Mon, 10 Dec 2012 15:31:01 GMT (envelope-from eadler@svn.freebsd.org) Message-Id: <201212101531.qBAFV1Y9045551@svn.freebsd.org> From: Eitan Adler Date: Mon, 10 Dec 2012 15:31:01 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40323 - head/en_US.ISO8859-1/books/faq X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 15:31:02 -0000 Author: eadler Date: Mon Dec 10 15:31:01 2012 New Revision: 40323 URL: http://svnweb.freebsd.org/changeset/doc/40323 Log: The PNP one can go... it was only marginally useful back in the day, and now it reads like a bad wikipedia article. - imp. Approved by: bcr (mentor) Modified: head/en_US.ISO8859-1/books/faq/book.xml Modified: head/en_US.ISO8859-1/books/faq/book.xml ============================================================================== --- head/en_US.ISO8859-1/books/faq/book.xml Mon Dec 10 15:30:59 2012 (r40322) +++ head/en_US.ISO8859-1/books/faq/book.xml Mon Dec 10 15:31:01 2012 (r40323) @@ -9364,93 +9364,6 @@ hint.sio.7.irq="12" - - How are Plug N Play ISA cards detected and - initialized? - - - - By: Frank Durda IV - uhclem@nemesis.lonestar.org - - In a nutshell, there a few I/O ports that all of the PnP - boards respond to when the host asks if anyone is out there. - So when the PnP probe routine starts, it asks if there are - any PnP boards present, and all the PnP boards respond with - their model # to a I/O read of the same port, so the probe - routine gets a wired-OR yes to that question. - At least one bit will be on in that reply. Then the probe - code is able to cause boards with board model IDs (assigned - by µsoft;/&intel;) lower than X to - go off-line. It then looks to see if any - boards are still responding to the query. If the answer was - 0, then there are no boards with IDs - above X. Probe will then ask for boards - below X. Finally, probe requests boards - greater than - X - (limit / 4) to go - off-line. It then repeats this query. By repeating this - semi-binary search of IDs-in-range enough times, the probing - code will eventually identify all PnP boards present in a - given machine with a number of iterations that is much lower - than what 264 would take. - - The IDs are two 32-bit fields (hence - 264) + 8-bit checksum. The first - 32 bits are a vendor identifier. They never come out - and say it, but it appears to be assumed that different - types of boards from the same vendor could have different - 32-bit vendor IDs. The idea of needing 32 bits just - for unique manufacturers is a bit excessive. - - The lower 32 bits are a serial #, or something else - that makes this one board unique. The vendor must never - produce a second board that has the same lower 32 bits - unless the upper 32 bits are also different. So you - can have multiple boards of the same type in the machine and - the full 64 bits will still be unique. - - The 32-bit groups can never be all zero. This - allows the wired-OR to show non-zero bits during the initial - binary search. - - Once the system has identified all the board IDs - present, it will reactivate each board, one at a time (via the - same I/O ports), and find out what resources the given board - needs, what interrupt choices are available, etc. A scan is - made over all the boards to collect this information. - - This info is then combined with info from any ECU files - on the hard disk or wired into the MLB BIOS. The ECU and - BIOS PnP support for hardware on the MLB is usually - synthetic, and the peripherals do not really do genuine PnP. - However by examining the BIOS info plus the ECU info, the - probe routines can cause the devices that are PnP to avoid - those devices the probe code cannot relocate. - - Then the PnP devices are visited once more and given - their I/O, DMA, IRQ and Memory-map address assignments. The - devices will then appear at those locations and remain there - until the next reboot, although there is nothing that says - you cannot move them around whenever you want. - - There is a lot of oversimplification above, but you - should get the general idea. - - µsoft; took over some of the primary printer status - ports to do PnP, on the logic that no boards decoded those - addresses for the opposing I/O cycles. I found a genuine - IBM printer board that did decode writes of the status port - during the early PnP proposal review period, but µsoft; - said tough. So they do a write to the - printer status port for setting addresses, plus that use - that address + 0x800, and a third I/O - port for reading that can be located anywhere between - 0x200 and 0x3ff. - - - - What about alternative layout policies for directories?