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 N 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 µsoft;/&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 - (limit / 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 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.</para> - - <para>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.</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>µ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 <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>