summaryrefslogtreecommitdiff
path: root/de/boot-installer/arm.xml
blob: a53c0f06c6f7534e429dcdd1df5b33d0ef0b5ab4 (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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
<!-- retain these comments for translator revision tracking -->
<!-- original version: 69213 -->

  <sect2 arch="arm" id="boot-image-formats">
    <title>Boot-Image-Formate</title>
    <para>
      Auf ARM-basierten Systemen wird in den meisten Fällen eines
      dieser beiden Formate für die Boot-Images verwendet: a)
      Standard-Linux-Kernel im zImage-Format (<quote>vmlinuz</quote>)
      zusammen mit einer Standard-Linux-Initial-Ramdisk
      (<quote>initrd.gz</quote>) oder b) Kernel im uImage-Format
      (<quote>uImage</quote>) zusammen mit dazu zugehöriger
      Initial-Ramdisk (<quote>uInitrd</quote>).
    </para>
    <para>
      uImage/uInitrd sind Image-Formate, die für die u-boot-Firmware
      ausgelegt wurden, welche auf vielen ARM-basierten Systemen
      eingesetzt ist. Ältere u-boot-Versionen können nur Dateien
      im uImage-/uInitrd-Format booten, daher werden diese Formate oft
      auf älteren armel-Systemen genutzt. Neuere u-boot-Versionen können -
      neben uImage/uInitrd - auch Standard-Linux-Kernel- und Ramdisk-Images
      booten, aber die Befehlssyntax dafür ist etwas anders als beim
      Booten von uImages.
    </para>
    <para>
      Für Systeme, die einen Multiplattform-Kernel verwenden, ist
      zusätzlich zu Kernel- und Initial-Ramdisk-Image noch eine
      sogenannte Gerätebaum-Datei (auch Gerätebaum-Abbild /
      device-tree blob, <quote>dtb</quote>) erforderlich. Diese ist
      spezifisch für jedes unterstützte System und enthält eine
      Beschreibung der jeweiligen Hardware.
    </para>
  </sect2>

  <sect2 arch="arm" id="boot-tftp"><title>Booten per TFTP</title>

&boot-installer-intro-net.xml;

    <sect3 arch="arm" id="boot-tftp-uboot">
      <title>TFTP-Boot in u-boot</title>
      <para>
       Das Booten von Systemen über das Netzwerk mittels der u-boot-Firmware
       erfordert drei Schritte: a) Konfigurieren des Netzwerks, b) Laden
       der Images (Kernel/Initial-Ramdisk/dtb) in den Speicher und c)
       das eigentliche Ausführen des vorher geladenen Codes.
      </para>
      <para>
       Als erstes müssen Sie das Netzwerk konfigurieren, entweder
       automatisch über DHCP, indem Sie dies ausführen:
<informalexample><screen>
setenv autoload no
dhcp
</screen></informalexample>
       oder manuell, indem Sie verschiedene Umgebungsvariablen setzen:
<informalexample><screen>
setenv ipaddr &lt;ip-adresse des clients&gt;
setenv netmask &lt;netmask&gt;
setenv serverip &lt;ip-adresse des tftp-servers&gt;
setenv dnsip &lt;ip-adresse des nameservers&gt;
setenv gatewayip &lt;ip-adresse des standard-gateways&gt;
</screen></informalexample>
       Falls Sie möchten, können Sie diese Einstellungen auch
       fest einrichten mit:
<informalexample><screen>
saveenv
</screen></informalexample>
      </para>
      <para>
       Danach müssen Sie die Images (Kernel/Initial-Ramdisk/dtb)
       in den Speicher laden. Dies wird mit dem tftpboot-Befehl
       erledigt, der zusammen mit der Adresse, an der das Image
       im Speicher abgelegt werden soll, angegeben werden muss.
       Unglücklicherweise kann die Lücke im Speicher von
       System zu System variieren, daher gibt es keine grundsätzliche
       Regel, welche Adresse hierfür verwendet werden muss.                     
      </para>
      <para>
       Auf einigen Systemen legt u-boot einige Umgebungsvariablen mit
       passenden Ladeadressen an: kernel_addr_r, ramdisk_addr_r und
       fdt_addr_r. Sie können überprüfen, ob diese definiert sind,
       indem Sie dies ausführen:
<informalexample><screen>
printenv kernel_addr_r ramdisk_addr_r fdt_addr_r
</screen></informalexample>
       Falls sie nicht definiert sind, müssen Sie die Dokumentation
       des Systems konsultieren bezüglich näherer Angaben zu passenden
       Werten und diese händisch setzen. Für Systeme, die auf
       Allwinner SunXi-SoCs (z.B. dem Allwinner A10,
       Architekturname <quote>sun4i</quote> oder dem Allwinner A20,
       Architekturname <quote>sun7i</quote>) basieren, können Sie
       z.B. folgende Werte nutzen:
<informalexample><screen>
setenv kernel_addr_r 0x46000000
setenv fdt_addr_r 0x47000000
setenv ramdisk_addr_r 0x48000000
</screen></informalexample>
      </para>
      <para>
       Sind die Ladeadressen bereits definiert, können Sie die
       Images von dem vorher definierten TFTP-Server in den Speicher
       laden mit:
<informalexample><screen>
tftpboot ${kernel_addr_r} &lt;dateiname des kernel-images&gt;
tftpboot ${fdt_addr_r} &lt;dateiname des dtb&gt;
tftpboot ${ramdisk_addr_r} &lt;dateiname des initial-ramdisk-images&gt;
</screen></informalexample>
      </para>
      <para>
       Der dritte Schritt ist das Setzen der Kernel-Befehlszeile
       und das eigentliche Ausführen des geladenen Codes. u-boot
       übergibt den Inhalt der Umgebungsvariable <quote>bootargs</quote>
       als Befehlszeile an den Kernel; also können alle Parameter für
       den Kernel und den Installer - wie z.B. die Konsolen-Gerätedatei
       (lesen Sie dazu <xref linkend="boot-console"/>) oder eventuelle
       Voreinstellungsoptionen (Näheres in <xref 
       linkend="installer-args"/> und <xref linkend="appendix-preseed"/>) -
       mit einem Befehl wie dem folgenden gesetzt werden:
<informalexample><screen>
setenv bootargs console=ttyS0,115200 rootwait panic=10
</screen></informalexample>
       Der exakte Befehl zur Ausführung des vorher geladenen Codes hängt
       vom verwendeten Image-Format ab. Bei uImage/uInitrd lautet der Befehl:
<informalexample><screen>
bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
</screen></informalexample>
       Bei nativen Linux-Image ist es:
<informalexample><screen>
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
</screen></informalexample>
      </para>
      <para>
       Beachten Sie: wenn Sie Standard-Linux-Images booten, ist es
       wichtig, dass das Initial-Ramdisk-Image nach dem Kernel und der
       DTB geladen wird, da u-boot die filesize-Variable (Dateigröße)
       auf die Größe der letzten geladenen Datei setzt und der
       bootz-Befehl benötigt die Größe des Ramdisk-Images, um korrekt
       zu arbeiten. Beim Booten eines plattformspezifischen Kernels, also
       eines Kernels ohne Gerätebaum-Abbild (DTB), lassen Sie den
       ${fdt_addr_r}-Parameter einfach weg.
      </para>
    </sect3>
  </sect2> 

<!-- # None of the arm systems supported in Jessie is able to boot from
     # CD/DVD -> commenting out the "Booting from CD-ROM section" for arm
     
  <sect2 arch="arm"><title>Booten von CD-ROM</title>

&boot-installer-intro-cd.xml;

  </sect2>
-->

<!--

  <sect2 arch="arm" id="boot-firmware"><title>Booten von Firmware</title>

&boot-installer-intro-firmware.xml;

   <sect3 arch="arm" id="boot-firmware-ss4000e">
   <title>Booten des SS4000-E</title>
<para>

Aufgrund von Einschränkungen in der SS4000-E-Firmware ist es derzeit
unglücklicherweise nicht möglich, den Installer ohne Verwendung eines
seriellen Ports zu booten. Um den Installer zu booten, benötigen Sie
ein serielles Nullmodem-Kabel, einen Rechner mit einem seriellen
Port<footnote id="arm-s4ke-port">

<para>
Ein USB-Seriell-Converter funktioniert auch.
</para>

</footnote> und ein Flachbandkabel mit einem männlichen DB9-Anschluß
auf der einen und einem 10-poligen .1" IDC-Stecker auf der anderen
Seite<footnote id="arm-s4k-rib">

<para>
Solch ein Kabel findet sich oft in älteren Desktop-Rechnern mit
eingebauten 9-poligen Anschlüssen für die seriellen Ports.
</para>

</footnote>.

</para><para>

Um den SS4000-E zu booten, verwenden Sie Ihr
Nullmodem-Kabel und das Flachbandkabel, um sich mit dem seriellen Anschluß
des SS4000-E zu verbinden und starten Sie die Maschine neu. Sie müssen
ein serielles Terminal-Programm benutzen, um mit dem Rechner zu kommunizieren;
auf &debian; GNU/Linux-Systemen ist es eine gute Wahl, das Programm
<command>cu</command> aus dem gleichnamigen Paket zu verwenden.
Angenommen, der serielle Port auf Ihrem Rechner ist
<filename>/dev/ttyS0</filename>, benutzen Sie folgende Befehlszeile:

</para>

<informalexample><screen>
cu -lttyS0 -s115200
</screen></informalexample>

<para>

Wenn Sie Windows verwenden, sollten Sie vielleicht das Programm
<classname>hyperterminal</classname> nutzen. Wählen Sie eine
Baudrate von 115200, 8 Bit Wortlänge, kein Stopbit und ein Parity-Bit.

</para><para>

Beim Starten der Maschine werden Sie folgende Ausgabe sehen:

</para>

<informalexample><screen>
No network interfaces found

EM-7210 ver.T04 2005-12-12 (For ver.AA)
== Executing boot script in 1.000 seconds - enter ^C to abort
</screen></informalexample>

<para>

Drücken Sie an diesem Punkt Strg-C, um den Bootloader zu 
unterbrechen<footnote id="arm-s4ke-sec">

<para>
Beachten Sie, dass Sie dazu nur eine Sekunde Zeit haben; falls Sie dies
Zeitfenster verpasst haben, trennen Sie kurz die Stromzufuhr des Rechners und
versuchen Sie es nach dem Start erneut.
</para>

</footnote>. Sie kommen jetzt zum RedBoot-Prompt. Geben Sie folgende Befehle
ein:

<informalexample><screen>
+load -v -r -b 0x01800000 -m ymodem ramdisk.gz
+load -v -r -b 0x01008000 -m ymodem zImage
+exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000" -r 0x01800000
</screen></informalexample>

</para><para>
 
Nach jedem <command>load</command>-Befehl erwartet das System die Übermittlung
einer Datei mittels des YMODEM-Protokolls. Wenn Sie cu verwenden, stellen
Sie sicher, dass Sie das Paket <classname>lrzsz</classname> installiert haben,
drücken Sie dann Enter, gefolgt von der <quote>~&lt;</quote>-Escape-Sequenz,
um ein externes Programm zu starten, und führen Sie dann
<command>sb initrd.gz</command> bzw. <command>sb vmlinuz</command> aus.

</para><para>

Alternativ dazu ist es möglich, den Kernel und die Ramdisk mittels HTTP
statt YMODEM zu laden. Dies ist schneller, erfordert jedoch einen funktionierenden
HTTP-Server im Netzwerk. Um diesen Weg zu gehen, schalten Sie zunächst den
Bootloader in den RAM-Modus:

<informalexample><screen>
fis load rammode
g
</screen></informalexample>

</para><para>

Dies führt scheinbar dazu, dass die Maschine neu startet; tatsächlich wird
jedoch reboot in den RAM geladen und die Maschine von dort neu gestartet.
Ohne diesen Schritt würde das System sich im nächsten, zwingend notwendigen
IP-Adressen-Schritt aufhängen.

</para><para>

Sie müssen nochmals Strg-C drücken, um den Bootvorgang zu unterbrechen.
Führen Sie dann folgendes aus:
 
<informalexample><screen>
ip_address -l <replaceable>192.168.2.249</replaceable> -h <replaceable>192.168.2.4</replaceable>
load -v -r -b 0x01800000 -m http /initrd.gz
load -v -r -b 0x01008000 -m http /zImage
exec -c "console=ttyS0,115200 rw root=/dev/ram mem=256M@0xa0000000" -r 0x01800000
</screen></informalexample>

Dabei entspricht <replaceable>192.168.2.249</replaceable> der IP-Adresse
des installierten Systems und <replaceable>192.168.2.4</replaceable> der
IP-Adresse des HTTP-Servers, der die Kernel- und Ramdisk-Dateien enthält.

</para><para>

Der Installer wird nun wie gewöhnlich starten.

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

-->