summaryrefslogtreecommitdiff
path: root/eu/hardware/supported/sparc.xml
diff options
context:
space:
mode:
Diffstat (limited to 'eu/hardware/supported/sparc.xml')
-rw-r--r--eu/hardware/supported/sparc.xml82
1 files changed, 0 insertions, 82 deletions
diff --git a/eu/hardware/supported/sparc.xml b/eu/hardware/supported/sparc.xml
deleted file mode 100644
index 4ee2352eb..000000000
--- a/eu/hardware/supported/sparc.xml
+++ /dev/null
@@ -1,82 +0,0 @@
-<!-- retain these comments for translator revision tracking -->
-<!-- original version: 11648 untranslated -->
-
-
- <sect2 arch="sparc" id="sparc-cpus"><title>CPU, Main Boards, and Video Support</title>
-<para>
-
-Currently the <emphasis>&architecture;</emphasis> port supports
-several types of Sparc systems. The most common identifiers for Sparc
-systems are sun4, sun4c, sun4m, sun4d and sun4u. Currently we do not
-support very old sun4 hardware. However, the other systems are
-supported. Sun4d has been tested the least of these, so expect
-possible problems with regard to the kernel stability. Sun4c and
-Sun4m, the most common of the older Sparc hardware, includes such
-systems as SparcStation 1, 1+, IPC, IPX and the SparcStation LX, 5,
-10, and 20, respectively. The UltraSPARC class systems fall under the
-sun4u identifier, and are supported using the sun4u set of install
-images. Some systems that fall under these supported identifiers are
-known to not be supported. Known unsupported systems are the AP1000
-multicomputer and the Tadpole Sparcbook 1. See the
-<ulink url="&url-sparc-linux-faq;">Linux for SPARCProcessors FAQ</ulink>
-for complete information.
-
-</para>
-
- <sect3><title>Memory Configuration</title>
-<para>
-
-Some older Sun workstations, notably the Sun IPX and Sun IPC have
-memory banks located at fixed locations in physical memory. Thus if
-the banks are not filled gaps will exist in the physical memory space.
-The Linux installation requires a contiguous memory block into which
-to load the kernel and the initial RAMdisk. If this is not available a
-`Data Access Exception' will result.
-
-</para><para>
-
-Thus you must configure the memory so that the lowest memory block is
-contiguous for at least 8Mb. In the IPX and IPC cited above, memory banks
-are mapped in at 16Mb boundaries. In effect this means that you must have
-a sufficiently large SIMM in bank zero to hold the kernel and RAMdisk.
-In this case 4Mb is <emphasis>not</emphasis> sufficient.
-
-</para><para>
-
-Example:
-In a Sun IPX you have a 16Mb SIMM and a 4Mb SIMM. There are four
-SIMM banks (0,1,2,3). [Bank zero is that furthest away from the SBUS
-connectors]. You must therefore install the 16Mb SIMM in bank 0; it is
-then recommended to install the 4Mb SIMM in bank 2.
-
-</para>
- </sect3>
-
- <sect3><title>Graphics Configuration</title>
-<para>
-
-Especially in the case of older Sun workstations, it is very common
-for there to be an onboard framebuffer which has been superseded (for
-example the bwtwo on a sun IPC), and an SBUS card containing a later
-probably accelerated buffer is then plugged in to an SBUS slot.
-Under Solaris/SunOS this causes no problems because both cards are
-initialised.
-
-</para><para>
-
-However with Linux this can cause a problem, in that the boot PROM
-monitor may display its output on this additional card; however the
-linux kernel boot messages may then be directed to the original on
-board framebuffer, leaving <emphasis>no</emphasis> error messages on
-the screen, with the machine apparently stuck loading the RAMdisk.
-
-</para><para>
-
-To avoid this problem, connect the monitor (if required) to the video
-card in the lowest numbered SBUS slot (on motherboard card counts
-as below external slots). Alternatively it is possible to use a serial
-console.
-
-</para>
- </sect3>
- </sect2>