Dbox2:CDK (YADD) Bootvorgang

Aus TuxBoxWIKI
Version vom 7. September 2004, 17:44 Uhr von Mogway (Diskussion)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche


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).


Und 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.

  • *=gesamtes Netzwerk
  • DBOX=dbox2
  • DHCP=DHCP-Server
  • TFTP=TFTP-Server
  • NFS=NFS-Server


Bmon

Bmon: *<-DBOX

Bmon sendet einen BOOTP-Request ins Netz


Bmon: DHCP->DBOX

Der DHCP-Server anwortet mit der IP-Adresse der Dbox, 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 im Wiki). Damit weiß der BMon nun alle nötigen Daten.


Bmon: TFTP<-DBOX

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->DBOX

Die Bootdatei wird nun an die dbox2 übertragen. Der BMon legt diese Datei im Speicher ab. Ist sie komplett übertragen berechnet er die Signatur. Wenn der BMon nun nicht im Debugmode ist, dann verweigert er an dieser Stelle die weitere Zusammenarbeit falls die Signatur nicht gültig ist und bootet neu. Mit aktiviertem Debugmode 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<-DBOX:

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


U-boot: DHCP->DBOX:

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, daß 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 angepaßten 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 eigentlich Bootvorgang, sondern dient nur der Bootlogo-Anzeige.


U-boot: TFTP<-DBOX:

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


U-boot: TFTP->DBOX:

Der Linuxkernel wird in den Hauptspeicher der dbox2 geladen. Da der Kernel 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 Linuxkernel und übergibt ihm die in bootargs gespeicherten Optionen.


Der Linuxkernel weiß durch den Parameter "root", daß 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 statt der Root nicht als NFS, sondern das entsprechende MTD-Device angegeben.



Review-KandidatDieser Artikel befindet sich derzeit im Reviewprozess. Hilf mit, ihn zu verbessern! Falls du bei weiteren Artikeln helfen willst, findest du hier eine Auswahl offener Artikel.


Abgerufen von „https://wiki.tuxbox-neutrino.org/w/index.php?title=Dbox2:CDK_(YADD)_Bootvorgang&oldid=3788“