.

Um zu verstehen, warum manche gut gemeinten Anleitungen in der Zyxel Welt doch nicht funktionieren, habe ich mir die Mühe gemacht, den Boot-Prozess zu recherchieren und mal detailliert zu beschreiben. Doch dazu muß man tief einsteigen und ganz viel lesen und lernen.

Die einzelnen "Brocken" habe ich mühsam aus allen Enden und Ecken des Internet, auch aus dem/den Zyxel Forum/Foren und "von oder aus" weiteren einsamen Wissens-Inseln zusammengetragen. Das muß also nicht alles so stimmen, denn es gibt viele verschiedene Wissens-Stufen und auch "Meinungen" !! und dazu immer noch Lücken.
.

Das sind erstmal die temporären unvollständigen Einzelheiten. Und die werden fortlaufend ergänzt bzw. verbessert. Und das ist gar nicht so einfach.
.

.
In einem "SoC" (System on Chip = alles auf einem Chip) gibt es immer ein Boot-ROM (allermeist kein PROM und auch kein E-Prom ! - das wären programmierbare "Nur-lese"-Speicher). Dieser ROM-Speicher wird bei der Herstellung der Haupt-Platine des "Embedded Sytems" einmalig mit dem "PPL" gefüttert (beschrieben). Das geht aber erst, wenn dieser "SoC" auf der Platine entweder aufgelötet ist oder aufgesteckt ist. Erst dann ist die notwendige Peripherie vorhanden, um solch ein ROM mit einem ersten initialen Loader-Code (dem PPL) zu füllen.
.

.

• In diesem ROM (oft nur 2 Kilobyte) ist also der vom Hersteller erzeugte PPL (Primary Program Loader) enthalten.
  
  
• In dem "SoC" ist außer dem ROM weiterhin (laut der FreeScale "SoC Infos") (in oder auf der CPU) ein Static-RAM mit (oft) 32 Kilobyte (der L1 oder der L2 Cache) oder etwas mehr als 32KB SRAM (manchmal auch der L2 Cache mit 128KB) vorhanden, in den dieser PPL Boot-Code beim Power-On rein geladen und dann ausgeführt wird.
  
  
• Dieser PPL Schmalspur-Code kann aber nichts weiter als den SPL (den Secondary Program Loader - auch MLO benannt) aus der "uloader"- Partition-1 des spi-flashs (256 kB read-only) abholen und in den chipeigenen SRAM-Speicher schreiben.
  
  
• Dieser SPL (Secondary Program Loader) weiß entweder genau (oder er sucht selbst), wo der richtige große TPL (Tertiary Program Loader) "barebox" ebenfalls im spi-flash - aber in der 2. Partition "barebox" (das sind bereits 512 kB read-only) liegt.
  
  
• Der TPL "barebox" boot-loader ist mit seinem Mini-Linux bereits recht intelligent und lädt seine eigene Konfiguration (das Environment) aus der 3. Partition ("env") des spi-flashs (wieder 256 kB) - diese Partition ist aber bereits read/write, damit er da auch etwas rein schreiben kann.
  
  
• Der "barebox" boot-loader hat dann auch schon Treiber für das Filesystem des 256 Megabyte großen NAND-flash Speichers und kann aus dessen Partitionen einen Kernel sowie ein vorbereitetes Filesystem (ein 150 MB großes Disk-Image) als RAM-Disk in den 1 Gigabyte großen Hauptspeicher installieren.

.
In den mehreren Gigabyte großen Zyxel (Bereich "barebox") Sourcen (dem boot-Sourcecode) steht ausführlich, in welchen Stufen (stages) gestartet wird. Diese ganzen Scripte kommen aus der 3. Partition ("env") des spi-flashs.
.

Den Boot-Code im ROM des SOC betrachten wir nicht als Script, sondern eher als Code, die danach folgenden (sieben oder mehr) Dateien aber schon.
.

• (1a) ein kleines "init" Script ist in den Sourcen enthalten (dort habe ich es gefunden). Dieses Script ruft eine Datei "env/config" (1b) auf und später eine Datei "init_board" (1c). Am Ende des Scriptes wird "boot" aufgerufen ???.
• (2a) Ein zweites Script aus den Sourcen "env" rufte ebenfalls die Datei "env/config" (1b) auf und endet mit dem Programmaufruf "bootu". Wie (bzw. von wem oder aus welchem Script) diese beiden Scripte (in welcher Reihenfolge) aufgerufen werden, ist noch nicht ersichtlich.
• (3) Ein weiteres init-Script aus dem Ram-Disk "root"-Verzeichnis "/init" setzt viele Variablen und initialisiert unter anderem die USB-Ports und das Netzwerk. Am Ende ruft dieses Script das nächste Script auf - über einen sonderbaren Link "/linuxrc", ein Link auf "rcS".
• (4) Das Start-Script Nummer 1 = "rcS" ruft ganz am Anfang eine Variablen-Sammlung "./etc/profile" (4a) auf und ruft am Ende eine weiteres Scriot "${IMG_PATH}/etc/init.d/rcS2" auf.
• (5) Das Start-Script Nummer 2 = "rcS2" ruft ganz am Anfang noch einmal diese Variablen-Sammlung "./etc/profile" (4a) auf und ist dann ohne weiteren Aufruf zuende. Ganz offensichtlich kehrt dieses Script an den Ausgangspunkt der Verschachtelung der Script-Konstruktion zurück, aber an welchen Ausgangspunkt ?

.

In der Aufeinanderfolge der Scripte vom ersten boot-loader PPL über barebox bis zum Laden eines raw-kernels hin bis zum ersten init-Script ist noch ein (Wissens-) Loch ........
.
Dazu habe ich jede Menge an Wissens-Fragmenten gefunden und baue die gerade zusamen. Merkwürdigerweise glänzen alle "Experten" nur mit einem Teilwissen .......
.