summaryrefslogtreecommitdiff
path: root/es/hardware/supported/sparc.xml
blob: fe301182081988d11c9348d8d8d29793e5db5f13 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- original version: 28997 -->
<!-- Revisado por Rudy Godoy -->


  <sect2 arch="sparc" id="sparc-cpus"><title>Soporte de CPU, placas base y vídeo</title>
<para>

Actualmente la adaptación para <emphasis>&architecture;</emphasis>
soporta diversos tipos de sistemas Sparc. Los identificadores
más comunes para sistemas Sparc son «sun4», «sun4m», «sun4d» y «sun4u».
Actualmente no se soporta hardware «sun4» muy antiguo. Sin embargo,
los otros sistemas están soportados. «Sun4d» ha sido el último de
estos en probarse, así que es probable que existan problemas
respecto a la estabilidad del núcleo. «Sun4c» y «Sun4m», los más
comunes en el hardware más antiguo de Sparc, incluyen sistemas
como SparcStation 1, 1+, IPC, IPX y las SparcStation LX, 5,
10 y 20, respectivamente. Los sistemas de clase «UltraSPARC»
caen bajo el identificador «sun4u», y están soportadas usando el
juego de imágenes de instalación «sun4u». Se sabe que algunos sistemas
fallan incluso estando dentro de estos identificadores soportados. Los
sistemas no soportados que se conocen son el multicomputer y el Tadpole
Sparcbook 1. Vea
<ulink url="&url-sparc-linux-faq;">FAQ de Linux para procesadores SPARC</ulink>
para información detallada.

</para>

   <sect3><title>Configuración de la memoria</title>
<para>

Algunas estaciones de trabajo Sun muy antiguas, notablemente la Sun IPX y
Sun IPC tiene bancos de memoria ubicados en posiciones fijas en la
memoria física. De modo que si los bancos no están llenos habrá huecos
en el espacio físico de memoria. La instalación de Linux requiere un
bloque de memoria contiguo en el cual cargar el núcleo y el disco
de memoria inicial (RAMdisk). Si éste no está disponible finalizará
mostrando el siguiente mensaje: <quote>Data Access Exception</quote>.

</para><para>

De modo que debe configurar la memoria para que el bloque de
memoria más bajo sea contiguo y de al menos 8 MB. En la IPX e IPC
citadas anteriormente, los bancos de memoria están mapeados en
límites de 16 MB. Lo que significa que debe tener un módulo
SIMM suficientemente grande en el banco cero para albergar el
núcleo y el disco de RAM. En este caso 4 MB <emphasis>no</emphasis>
son suficientes.

</para><para>

Ejemplo:
En una Sun IPX tiene un módulo SIMM de 16 MB y otro de 4 MB. Existen
cuatro bancos SIMM (0,1,2,3). [El banco cero es el más alejado de los
conectores SBUS]. Entonces debe instalar el SIM de 16 MB en el
banco 0; se recomienda instalar el SIMM de 4 MB en el banco 2.

</para>
   </sect3>

   <sect3><title>Configuración gráfica</title>
<para>

En el caso de las Sun Workstation en especial, es muy común
el que tengan un «framebuffer» en la placa el cual ha sido
sustituido (por ejemplo por la «btwtwo» en una sun IPC), y una tarjeta SBUS
conteniendo un buffer más reciente probablemente acelerado, el cual es
conectado en una ranura SBUS. Bajo Solaris/SunOS esto no causa
problemas debido a que ambas tarjetas son inicializadas.

</para><para>

Sin embargo con Linux esto puede causar un problema, porque el
monitor de PROM de arranque podría mostrar su salida en una tarjeta
adicional; no obstante los mensajes de arranque del núcleo Linux
pueden ser direccionados al «framebuffer» en placa, <emphasis>sin</emphasis>
dejar mensajes de fallo en la pantalla, teniendo a la máquina
aparentemente parada mientras se carga el disco de RAM (RAMdisk).

</para><para>

Para evitar este problema, conecte el monitor (si es necesario) a la
tarjeta de vídeo de la ranura SBUS con menor numeración (en la placa base
la numeración esta debajo de las ranuras externas). Alternativamente es
posible usar una consola a través del puerto serie.

</para>
   </sect3>
  </sect2>