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
|
<!-- retain these comments for translator revision tracking -->
<!-- original version: 69757 -->
<sect2 arch="arm" id="arm-firmware-overview"><title>ARM-Firmware</title>
<para>
Wie bereits vorher erwähnt, gibt es unglücklicherweise keinen
Standard für System-Firmware auf ARM-Systemen. Sogar das Verhalten
verschiedener Systeme, die nominal die gleiche Firmware verwenden,
kann ziemlich unterschiedlich sein. Dies liegt an der Tatsache,
dass ein großer Teil der Geräte, die die ARM-Architektur nutzen,
eingebettete (embedded) Systeme sind, für die die Hersteller
üblicherweise stark angepasste Firmware-Versionen erstellen
und gerätespezifische Patches integrieren.
Unglücklicherweise melden die Hersteller oft ihre Änderungen
nicht zurück an die ursprünglichen Firmware-Entwickler, so dass
die Änderungen nicht in neuere Versionen der Original-Firmware
einfließen.
</para>
<para>
Als Ergebnis daraus verwenden sogar neu verkaufte Systeme oft eine
Firmware, die auf einer mehrere Jahre alten, durch den Hersteller
angepassten Version einer Firmware basiert, deren Original-Codebasis
sich in der Zwischenzeit erheblich weiterentwickelt hat und
zusätzliche Funktionalitäten enthält oder bei bestimmten Aspekten
ein verändertes Verhalten zeigt.
Zusätzlich dazu ist die Benamung von Onboard-Geräten nicht
konsistent zwischen hersteller-modifizierten Versionen der gleichen
Firmware, daher ist es nahezu unmöglich, nützliche geräteunabhängige
Dokumentation für ARM-basierte Systeme bereitzustellen.
</para>
</sect2>
<sect2 arch="armhf" id="armhf-uboot-images">
<title>Durch Debian bereitgestellte U-Boot-Images (System-Firmware)</title>
<para>
Debian stellt für verschiedene armhf-Systeme, die ihr U-Boot
von einer SD-Karte laden können, U-Boot-Images bereit
(siehe &armmp-uboot-img;).
Die U-Boot-Builds werden in zwei Formaten angeboten:
als rohe U-Boot-Komponenten und als fertige Images, die einfach
auf eine SD-Karte geschrieben werden können.
Die Variante mit den rohen U-Boot-Komponenten ist für
erfahrene Benutzer gedacht; der grundsätzlich empfohlene Weg ist
die Verwendung der fertigen SD-Karten-Images.
Sie sind nach dem Schema <systemtyp>.sdcard.img.gz
benannt und können wie folgt auf eine Karte geschrieben werden:
<informalexample><screen>zcat <systemtyp>.sdcard.img.gz > /dev/SD_KARTEN_GERAET</screen></informalexample>
Wie immer beim Schreiben von Images sollten Sie auch hier bedenken, dass
dadurch alle vorherigen Inhalte auf der Karte gelöscht werden!
</para>
<para>
Wenn Debian ein U-Boot-Image für Ihr System anbietet, wird empfohlen,
dass Sie dieses Image verwenden statt einem vom Gerätehersteller
angebotenen U-Boot, da die Version in Debian für gewöhnlich neuer
ist und daher mehr Funktionen bietet.
</para>
</sect2>
<sect2 arch="arm" id="uboot-macsetting">
<title>Setzen der Ethernet-MAC-Adresse in U-Boot</title>
<para>
Die MAC-Adresse jeder Ethernet-Schnittstelle sollte eigentlich
global eindeutig sein, und technisch muss sie innerhalb ihrer
Ethernet-Broadcast-Domain eindeutig sein.
Um dies zu erreichen, reserviert der Hersteller normalerweise
einen Block von MAC-Adressen aus einem zentral administrierten
Pool (für den eine Gebühr gezahlt werden muss) und vergibt dann
eine dieser Adressen an jedes verkaufte Gerät.
</para>
<para>
Im Falle von Development-Boards wollen Hersteller manchmal
die Zahlung der Gebühr vermeiden und stellen daher keine global
eindeutigen Adressen bereit. In diesen Fällen muss der Benutzer
selbst MAC-Adressen für seine Systeme vergeben. Wenn für eine
Ethernet-Schnittstelle keine MAC-Adresse festgelegt ist, generieren
einige Netzwerktreiber eine zufällige MAC-Adresse, die sich dann
bei jedem Neustart ändern kann, und dabei wäre ein Netzwerkzugriff
möglich, ohne dass der Benutzer händisch eine Adresse festgelegt
hat; wenn jedoch z.B. die IP-Adressen über DHCP aus der MAC-Adresse
des anfordernden Clients abgeleitet werden, würde dies
natürlich nicht zuverlässig funktionieren.
</para>
<para>
Um Konflikte mit vorhandenen offiziell vergebenen MAC-Adressen
zu vermeiden, gibt es einen Adress-Pool, der für sogenannte
<quote>lokal administrierte</quote> Adressen reserviert ist.
Er wird über den Wert von zwei speziellen Bits im ersten Byte
der Adresse definiert (der Artikel <quote>MAC address</quote>
in der englisch-sprachigen Wikipedia enthält hierzu eine gute
Beschreibung). In der Praxis bedeutet dies, dass z.B. jede
Adresse, die mit dem hexadezimalen Wert ca beginnt (wie
ca:ff:ee:12:34:56), als lokal administrierte Adresse
verwendet werden kann.
</para>
<para>
Auf Systemen, die U-Boot als System-Firmware nutzen, ist die
Ethernet-MAC-Adresse in der Umgebungsvariablen <quote>ethaddr</quote>
abgelegt. Sie kann über den U-Boot-Befehlsprompt mit dem
Befehl <quote>printenv ethaddr</quote> überprüft und mit
<quote>setenv ethaddr ca:ff:ee:12:34:56</quote> gesetzt werden.
Nach dem Ändern des Wertes wird mit dem Befehl
<quote>saveenv</quote> diese Einstellung fest abgespeichert.
</para>
</sect2>
<sect2 arch="arm" id="uboot-relocation-issues">
<title>Probleme bei der Speicherzuweisung für Kernel/Initrd/Gerätebaum in U-Boot</title>
<para>
Auf einigen Systemen mit älteren U-Boot-Versionen können Probleme
bei der korrekten Speicherzuweisung für Linux-Kernel, Initial-Ramdisk
und Gerätebaum-Abbild während des Boot-Prozesses
auftreten. In diesem Fall zeigt U-Boot die Meldung <quote>Starting
kernel ...</quote> an, aber das System friert danach ohne weitere
Ausgabe ein. Diese Probleme wurden in neueren U-Boot-Versionen
ab v2014.07 aufwärts behoben.
</para>
<para>
Falls das System im Originalzustand eine U-Boot-Version älter als
v2014.07 genutzt hat und dann auf eine neuere Version aktualisiert
wurde, könnte das Problem auch nach dem Upgrade von U-Boot noch
auftreten. Das Aktualisieren von U-Boot modifiziert üblicherweise
nicht die vorhandenen Umgebungsvariablen und der Fix zur Fehlerbehebung
erfordert das Setzen einer zusätzlichen Umgebungsvariable (bootm_size),
was jedoch nur bei frischen Neuinstallationen ohne vorhandene
Umgebungsdaten von U-Boot automatisch erledigt wird. Es ist
möglich, bootm_size händisch auf den neuen U-Boot-Standardwert
zu setzen, indem <quote>env default bootm_size; saveenv</quote>
am U-Boot-Prompt ausgeführt wird.
</para>
<para>
Eine andere Möglichkeit, solche Probleme bei Speicherzuweisungen
zu verhindern, wäre die Ausführung von
<quote>setenv fdt_high ffffffff; setenv initrd_high 0xffffffff;
saveenv</quote> am U-Boot-Prompt; damit wird die
dynamische Speicherzuweisung für Initial-Ramdisk und
Gerätebaum-Abbild vollständig deaktiviert.
</para>
</sect2>
|
