aus Wiki, der freien Wissensdatenbank

Inhaltsverzeichnis

1 Allgemeines 1.1 Voraussetzung 2 So funktioniert es 2.1 Bmon 2.1.1 Bmon: gesamtes Netzwerk<-DBox2 2.1.2 Bmon: DHCP->DBox2 2.1.3 Bmon: TFTP<-DBox2 2.1.4 Bmon: TFTP->DBox2 2.2 U-Boot 2.2.1 U-boot: DHCP<-DBox2: 2.2.2 U-boot: DHCP->DBox2: 2.2.3 U-boot: TFTP<-DBox2: 2.2.4 U-boot: TFTP->DBox2:

English: CDK YADD Boot Procedure

Allgemeines

Voraussetzung

Im Netz befindet sich ein DHCP-, ein NFS- und ein TFTP-Server, die natürlich entsprechend konfiguriert sein müssen.

DHCP ist der Nachfolger von BOOTP, daher kann der dhcpd bei Linux auch das Bootstrap-Protokoll (BOOTP).

So funktioniert es

Zunächst läuft der Bmon los, initialisiert die nötige Hardware (CPU, LCD etc.). Danach folgt die Kommunikation, hier der Übersicht halber mit Angabe der Richtung wie folgt.

Bmon

Bmon: gesamtes Netzwerk<-DBox2

Der Bmon sendet einen BOOTP-Request ins Netz

Bmon: DHCP->DBox2

Der DHCP-Server anwortet mit der IP-Adresse der DBox2, der IP-Adresse des Servers und dem Namen der Bootdatei (z.Bsp: "dbox2/tftpboot/u-boot"). Die Bootdatei ist der 2.Phase-Bootloader (der Bmon ist der erste, genaueres hier). Damit weiß der Bmon nun alle nötigen Daten.

Bmon: TFTP<-DBox2

Der Bmon erfragt per ARP die zur TFTP-Server-IP zugehörige MAC (Standardvorgang, Ethernet-Pakete werden an eine MAC-Adresse adressiert, nicht an eine IP). Anschließend fordert er mit einem TFTP-Read Request die Bootdatei an.

Bmon: TFTP->DBox2

Die Bootdatei wird nun an die DBox2 übertragen. Der Bmon legt diese Datei im Speicher ab. Ist die Bootdatei komplett übertragen berechnet er die Signatur. Wenn der Bmon nun nicht im Debug-Mode ist, dann verweigert er an dieser Stelle die weitere Zusammenarbeit falls die Signatur nicht gültig ist und bootet neu. Mit aktiviertem Debug-Mode gibt er zwar eine Fehlermeldung aus, startet aber anschließend die Bootdatei, in unserem Fall also den u-boot.

Der U-boot ist wesentlich intelligenter als der Bmon, er weiß aber nichts von den Dingen, die bis zu diesem Punkt passiert sind. Für ihn hat die DBox2 zunächst wieder keine IP.

Eine Sache ist noch wichtig zu wissen. Der U-boot führt nacheinander die Kommandos aus, die man ihm beim Kompilieren eingebaut hat. Daher ist die nachfolgende Beschreibung nur für die CDK-Konfiguration gültig.

Theoretisch kann man den Autostart des U-boots auch abbrechen und alle Befehle von Hand eingeben. Wer es individuell haben möchte, sollte sich das Verzeichnis u-boot-config im CDK ansehen. Dort sind die einzelnen Konfigurationen abgelegt.

Welche dieser Konfigurationen beim Kompilieren verwendet wird legt der Symlink u-boot.config in diesem Verzeichnis fest, welcher nur bei Nicht-Existenz automatisch auf die CDK-Config angelegt wird. Dadurch kann jeder ohne großen Aufwand seine persönliche Konfiguration erstellen.

U-Boot

U-boot: DHCP<-DBox2:

Der U-boot kennt zwar auch das Bootp-Protokoll, das DHCP-Protokoll erlaubt aber noch einige Dinge mehr, so dass dieses verwendet wird. Zunächst fragt der U-boot per DHCP Discover nach seiner IP.

U-boot: DHCP->DBox2:

Der DHCP bietet dem U-boot eine IP an und weil der U-boot nicht wählerisch ist, akzeptiert er diese.

Da wir einen Bootstrap machen sagt der DHCP dem U-boot auch noch seine Bootdatei. Also genauso wie bei der IP-Vergabe für den Bmon. Das Problem ist natürlich, dass wir nicht nochmal den U-boot laden wollen. Damit der DHCP-Server nun weiß, welche Bootdatei wir möchten, sendet der U-boot ein optionales Feld mit, den sogenannten "Vendor Class Identifier".

Dieser Identifier wird beim DHCP-Server in die DHCP-Konfiguration eingetragen und somit ist es möglich, den Bmon vom U-boot zu unterscheiden.

Der Windows-Bootmanager kennt diese Option nicht, daher wird er immer wieder den U-boot senden. Deswegen braucht man für den Bootmanager auch einen speziell angepassten U-boot.

Als nächstes versucht der U-boot nun die Datei "logo-lcd" und "logo-fb" über das TFTP-Protokoll zu laden. Dies hat keine Bewandnis für den eigentlichen Bootvorgang, sondern dient nur der Bootlogo-Anzeige.

U-boot: TFTP<-DBox2:

Als vorletzter Schritt wird nun die Bootdatei angefordert, es handelt sich um den Linux-Kernel.

U-boot: TFTP->DBox2:

Der Linux-Kernel wird in den Hauptspeicher der DBox2 geladen. Da der Kernel im Prinzip wie ein ausführbares Programm ist kann man ihm auch Parameter übergeben. In der U-boot-Konfiguration werden diese in der Umgebungsvariable "bootargs" gespeichert.

Die CDK-Bootargumente sehen so aus:

root=/dev/nfs rw 
nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off 
console=$(console); 

Über diese Parameter erfährt der Kernel auch alle für ihn wichtigen Dinge.

Die Variablen serverip,rootpath,ipaddr,gatewayip,netmask und hostname werden per DHCP erfragt.

Als letztes führt der U-boot das Kommando "bootm" aus. Dieses startet den Linux-Kernel und übergibt ihm die in bootargs gespeicherten Optionen.

Der Linux-Kernel weiß durch den Parameter "root", dass er über NFS booten soll. Den genauen Pfad entnimmt er dem nfsroot und dieser Pfad wird dann noch während des Bootvorgangs als root-Verzeichnis ("/") gemountet. Anschließend wird das Programm "init" gestartet womit der eigentliche Kernel-Boot abgeschlossen ist. Danach folgt der normale Startvorgang für die Anwendungsumgebung.

Das Booten aus dem Flash funktioniert ähnlich, natürlich wird hier der Root nicht als NFS sondern als das entsprechende MTD-Device angegeben.

---