.

Bei der Suche und dem Durchforsten unseres im täglichen Betrieb laufenden funktionierenden Zyxel NAS-542 Servers habe ich diese 3  Script-Dateien (solche Script-Dateien beginnen innen im Text immer mit "#!/bin/sh") gefunden :

1. /init (ich nene es erst mal "init(1)"
   
2. /etc/init.d/rcS und
3. /ram_bin/etc/init.d/rcS2

.
Es gibt mehrere "init" Scripte, die anderen Scripte sind eindeutig bennannt.
.

Bislang hatte ich noch nicht herausgefunden, welche Boot-Stufe (Stage) dieses vermeintlich erste "init (0)"- Script - also eigentlich das allererste "init(1)"-Script aufruft, welches wiederum "rcS" aufruft und dann "rcS2" aufruft. Weiterhin hatte ich anfänglich auch noch nicht gefunden, was am Ende des "rcS2" Scripts weiterhin passiert ? Denn es geht ja weiter, - aber wie ? Dort am Ende finde ich nichts.

Ich vermute, das es verschachtelte shell-Sripte sind, daß also ein Script aus dem "Environment" (das ist die spi-flash partition-3 "env") das allererste init-Script aufruft und nach dem Ende der Verkettung - also des Umwegs der drei Start-Scripte zu dem ursprünglichen Script wieder zurückkehrt. In den beiden Scripten "rcS" und "rcS2" wird jeweils ganz am Anfang das für das Setzen der Varioablen zuständige "profile" Script aufgerufen und dann gehts in dem jeweiligen Script wieder weiter.

Daher muß es ein initiales Script geben, das diese weiteren Scripte kaskadiert aufruft und am Ende in einem Verzeichnis auf der ersten Festplatte landet und dort weitere Scripte ausführt.
.

Die gesamten Sourcen auch dieser Zyxel Firmware sind public unter GPL. Doch die als tar.gz zusammengepackten 1,7 Gigabyte Sourcen jetzt Stufe für Stufe zu entpacken, das braucht Geduld und riesige Platten-Kapazitäten.

Am Ende des Suchens in den entpackten verschachtelten Unterverzeichnissen (auf unserem hausinternen Server !!) landet man hier im "default env" des "barebox"- Boot-Loaders :

"\NAS-542_521V7\sourcen\src\barebox\defaultenv\bin\boot"
.

(1) Im ROM auf dem "SoC" ist der PPL der "primary program loader" unveränderbar abgespeichert. Der wird beim "POS" (Power On Start) ins SRAM (L2 oder L1 Cache auch im SoC) geladen (ähnlich einem BIOS) und dort von der ersten CPU ausgeführt.

(2) Dieser PPL lädt per serieller Anbindung den SPL, den "secondary program loader" aus dem spi-flash - (aus Partition 1 = "uloader") in das SRAM (?) und führt das 2. Loader-Programm aus.

(3) Dies SPL mit seinem NAND Treiber lädt (aus partition 2 = "barebox") den TPL, den "barebox" boot-loader - und der ist bereits ein richtiges Mini-Btriebsystem - in den Hauptspeicher und führt das Prog´ramm aus.

(4) Der TPL - also der "barebox" Loader holt sich aus der 3. spi-flash Partition ("env") seine Boot-Konfiguration in Form von ATAG- Listen und config- Scripten und führt sie aus.

So weit meine bisherige Kenntnis. Darum habe ich die beiden erkennbaren Boot-Scripte aus dem boot-Envoiromment (Partition 3 "env") hier unten drunter eingefügt, um daruzulegen, was da alles während des Boot-Vorgangs passiert.
.

.

• Aus dem Script nur einige wenige erklärende Teile !! und die Kommentare:

.
#!/bin/sh
. /env/config
.

• Das bedeutet, daß der SPL urloader aus der partition-1 bereits Partitonen unterscheiden konnte und der TPL "barebox" das geerbt hatte. "barebox" kann das spi-flash filesystem lesen und eine Verzeichnisstruktur wird auch akzeptiert. So kann in diesem Script die Datei "/env/config" aus Partition 3 geladen werden.

 .

• Hier standen diverse Abfragen, die hier übesprungen sind, mit wirklich komplex verschachtelten "if then else" Routinen,

.

1. welche Netzwerkverbindung und IP NUmmer ?
2. welches Filesystem und welcher Kernel ?
3. Zusammenbau der "bootargs"

.
local boot : bootargs="$bootargs root=/dev/ram0 rdinit=/sbin/init"
.

• per Variable festgelegt : aus den NAND flash booten :

.
rootfs_mtdblock=$rootfs_mtdblock_nand
.
bootargs="$bootargs root=/dev/mtdblock$rootfs_mtdblock"
.

• # arm raw kernel images are usually located at sdram start + 0x8000
• # addpart /dev/ram0 8M@0x8000(kernelraw)

 .

• hier leicht zu lesen :

.
if [ ! -e /dev/ram0.kernel ]; then

• # Here we can safely put the kernel without risking of overwriting it while extracting

.

    addpart /dev/ram0 8M@8M(kernel)
.

• So wird der etwa 8 MB große Kernel nach all den Abfragen hier aus einer der 10MB Partitionen aus dem NAND-flash ins RAM geladen.
  
  Ganz am Ende kommt dann :

.
elif [ x$kernel_loc = xnand ]; then
    kdev="/dev/nand0.kernel.bb"
.
echo "booting kernel of type $kernelimage_type from $kdev"
.
bootu /dev/ram0.kernelraw
.

• Der sogenannte "raw"-Linux-Kernel (ca. 8 MB gross) wird somit gestartet.
  

.

.

.

• Dieses init-Script könnte zuerst kommen, weil hier der Pfad gesetzt wird.Ichhabe es ganz bewußt init(0) benannt, weil es noch weitere gleichlautende "init"Scripte gibt bzw. geben könnte.

.
!/bin/sh
PATH=/env/bin
export PATH

• # Auch hier wird die Datei "config" aus Partition 3 (env) geladen.

. /env/config

    addpart /dev/nand0 $nand_parts
    nand -a /dev/nand0.*

    # Uh, oh, hush first expands wildcards and then starts executing
    # commands. What a bug!

• # hier müssten dei Hardware Infos abgerufen werden

    /env/bin/init_board

echo -n "Hit any key to stop autoboot: "

• und das hier ist ein typischer Befehl für den ins RAM kopierten Kernel, jetzt anzufangen

boot
.

Was steht in den Dateien

"/env/config" und " /env/bin/init_board" ???
.

.
Hier geht es zu dem "init(1) Script. Sobald ich den sauberen "chronologischen Weg" gefunden habe, wird der hier eingebaut.
.