| 1 |
<!-- retain these comments for translator revision tracking -->
|
| 2 |
<!-- $Id: sparc.xml 22935 2004-10-09 18:36:20Z fjpop-guest $ -->
|
| 3 |
|
| 4 |
|
| 5 |
<sect2 arch="sparc" id="sparc-cpus"><title>CPU, Main Boards, and Video Support</title>
|
| 6 |
<para>
|
| 7 |
|
| 8 |
Currently the <emphasis>&architecture;</emphasis> port supports
|
| 9 |
several types of Sparc systems. The most common identifiers for Sparc
|
| 10 |
systems are sun4, sun4c, sun4m, sun4d and sun4u. Currently we do not
|
| 11 |
support very old sun4 hardware. However, the other systems are
|
| 12 |
supported. Sun4d has been tested the least of these, so expect
|
| 13 |
possible problems with regard to the kernel stability. Sun4c and
|
| 14 |
Sun4m, the most common of the older Sparc hardware, includes such
|
| 15 |
systems as SparcStation 1, 1+, IPC, IPX and the SparcStation LX, 5,
|
| 16 |
10, and 20, respectively. The UltraSPARC class systems fall under the
|
| 17 |
sun4u identifier, and are supported using the sun4u set of install
|
| 18 |
images. Some systems that fall under these supported identifiers are
|
| 19 |
known to not be supported. Known unsupported systems are the AP1000
|
| 20 |
multicomputer and the Tadpole Sparcbook 1. See the
|
| 21 |
<ulink url="&url-sparc-linux-faq;">Linux for SPARCProcessors FAQ</ulink>
|
| 22 |
for complete information.
|
| 23 |
|
| 24 |
</para>
|
| 25 |
|
| 26 |
<sect3><title>Memory Configuration</title>
|
| 27 |
<para>
|
| 28 |
|
| 29 |
Some older Sun workstations, notably the Sun IPX and Sun IPC have
|
| 30 |
memory banks located at fixed locations in physical memory. Thus if
|
| 31 |
the banks are not filled gaps will exist in the physical memory space.
|
| 32 |
The Linux installation requires a contiguous memory block into which
|
| 33 |
to load the kernel and the initial RAMdisk. If this is not available a
|
| 34 |
`Data Access Exception' will result.
|
| 35 |
|
| 36 |
</para><para>
|
| 37 |
|
| 38 |
Thus you must configure the memory so that the lowest memory block is
|
| 39 |
contiguous for at least 8Mb. In the IPX and IPC cited above, memory banks
|
| 40 |
are mapped in at 16Mb boundaries. In effect this means that you must have
|
| 41 |
a sufficiently large SIMM in bank zero to hold the kernel and RAMdisk.
|
| 42 |
In this case 4Mb is <emphasis>not</emphasis> sufficient.
|
| 43 |
|
| 44 |
</para><para>
|
| 45 |
|
| 46 |
Example:
|
| 47 |
In a Sun IPX you have a 16Mb SIMM and a 4Mb SIMM. There are four
|
| 48 |
SIMM banks (0,1,2,3). [Bank zero is that furthest away from the SBUS
|
| 49 |
connectors]. You must therefore install the 16Mb SIMM in bank 0; it is
|
| 50 |
then recommended to install the 4Mb SIMM in bank 2.
|
| 51 |
|
| 52 |
</para>
|
| 53 |
</sect3>
|
| 54 |
|
| 55 |
<sect3><title>Graphics Configuration</title>
|
| 56 |
<para>
|
| 57 |
|
| 58 |
Especially in the case of older Sun workstations, it is very common
|
| 59 |
for there to be an onboard framebuffer which has been superseded (for
|
| 60 |
example the bwtwo on a sun IPC), and an SBUS card containing a later
|
| 61 |
probably accelerated buffer is then plugged in to an SBUS slot.
|
| 62 |
Under Solaris/SunOS this causes no problems because both cards are
|
| 63 |
initialized.
|
| 64 |
|
| 65 |
</para><para>
|
| 66 |
|
| 67 |
However with Linux this can cause a problem, in that the boot PROM
|
| 68 |
monitor may display its output on this additional card; however the
|
| 69 |
linux kernel boot messages may then be directed to the original on
|
| 70 |
board framebuffer, leaving <emphasis>no</emphasis> error messages on
|
| 71 |
the screen, with the machine apparently stuck loading the RAMdisk.
|
| 72 |
|
| 73 |
</para><para>
|
| 74 |
|
| 75 |
To avoid this problem, connect the monitor (if required) to the video
|
| 76 |
card in the lowest numbered SBUS slot (on motherboard card counts
|
| 77 |
as below external slots). Alternatively it is possible to use a serial
|
| 78 |
console.
|
| 79 |
|
| 80 |
</para>
|
| 81 |
</sect3>
|
| 82 |
</sect2>
|
Parent Directory
| 
Revision Log