Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Dec 2012 15:31:01 +0000 (UTC)
From:      Eitan Adler <eadler@FreeBSD.org>
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
Message-ID:  <201212101531.qBAFV1Y9045551@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
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"</programlisting>
       </qandaentry>
 
       <qandaentry>
-	<question id="pnp-initialize">
-	  <para>How are Plug&nbsp;N&nbsp;Play ISA cards detected and
-	    initialized?</para>
-	</question>
-
-	<answer>
-	  <para>By: Frank Durda IV
-	    <email>uhclem@nemesis.lonestar.org</email></para>
-
-	  <para>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 <quote>yes</quote> 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 &microsoft;/&intel;) lower than <literal>X</literal> to
-	    go <quote>off-line</quote>.  It then looks to see if any
-	    boards are still responding to the query.  If the answer was
-	    <literal>0</literal>, then there are no boards with IDs
-	    above <literal>X</literal>.  Probe will then ask for boards
-	    below <literal>X</literal>.  Finally, probe requests boards
-	    greater than
-	    <literal>X&nbsp;-&nbsp;(limit&nbsp;/&nbsp;4)</literal> 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 2<superscript>64</superscript> would take.</para>
-
-	  <para>The IDs are two 32-bit fields (hence
-	    2<superscript>64</superscript>) + 8-bit checksum.  The first
-	    32&nbsp;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&nbsp;bits just
-	    for unique manufacturers is a bit excessive.</para>
-
-	  <para>The lower 32&nbsp;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&nbsp;bits
-	    unless the upper 32&nbsp;bits are also different.  So you
-	    can have multiple boards of the same type in the machine and
-	    the full 64&nbsp;bits will still be unique.</para>
-
-	  <para>The 32-bit groups can never be all zero.  This
-	    allows the wired-OR to show non-zero bits during the initial
-	    binary search.</para>
-
-	  <para>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.</para>
-
-	  <para>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.</para>
-
-	  <para>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.</para>
-
-	  <para>There is a lot of oversimplification above, but you
-	    should get the general idea.</para>
-
-	  <para>&microsoft; 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 &microsoft;
-	    said <quote>tough</quote>.  So they do a write to the
-	    printer status port for setting addresses, plus that use
-	    that address + <literal>0x800</literal>, and a third I/O
-	    port for reading that can be located anywhere between
-	    <literal>0x200</literal> and <literal>0x3ff</literal>.</para>
-	</answer>
-      </qandaentry>
-
-      <qandaentry>
 	<question id="alternate-directory-layout">
 	  <para>What about alternative layout policies for
 	    directories?</para>



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