Ausgehend von meinem hier beschriebenen Problem einer "defekten" SDHC Karte : https://www.ip-phone-forum.de/threads/help-osbiz-x3-sd-karte-zerschossen.308035/
habe Ich mir den Bootvorgang der OsBiz und die SD Kartenstruktur mal ein bisschen näher angeschaut und jetzt ist auch klar, warum blosses Kopieren der ext3 Partition von einer funktionsfähigen SDHC Karte nicht ausreicht, um eine bootfähige Karte zu erhalten.
Die CPU der OsBiz hat einen ROM-Loader (first-stage-loader) der nach dem Einschalten unter anderem am SDHC Interface nachschaut, ob dort eine bootfähige Karte zu finden ist. Die erkennt er an einer Signatur (0x42, 0x4F, 0x4F, 00x54 entspricht im ASCII der Zeichenfolge BOOT ) an Offset 0x40. Ist diese Signatur nicht vorhanden, ist der Bootvorgang an der Stelle zu Ende.
Da für den weiteren Bootvorgang das an der CPU angeschlossene DDR Ram gebraucht wird, liegen hinter der Signatur die entsprechenden Konfigurationsparameter für den DDR RAM Controller, mit dener der Loader den Controller konfiguriert. Ist das RAM bereit, wird von der Karte ein second-stage-bootloader (so wie es aussieht wohl uboot) gelesen, ins RAM kopiert und dort angestartet. Erst dieser Loader kann dann auf die ext3 Partition zugreifen und das Linux starten.
Signatur, RAM Parameter und der second stage boot loader liegen alle ausserhalb der ext3 Partition im nicht partitionierten Bereich am Anfang der Karte und werden dann natürlich nicht mitkopiert, wenn man nur die Partition auf eine andere Karte kopiert.
dd kopiert sektorweise, völlig unabhängig vom Filesystem oder Datenträgerstruktur , etc, daher funktioniert das Klonen der Karte mit dd.
Was leider nicht geht, ist die auf eine 16GB Karte geklonte 7.29GiB Partition einfach zu vergrößern, um den zusätzlichen Platz auf der Karte auch nutzen zu können (z.B. um auf V3 Software updaten zu können). Ich habe das mit zwei verschiedenen Tools (gparted und Linux und DiskGenius unter Windows) versucht und beide überschreiben ungefragt und ohne Warnung den nicht partitionierten Bereich vor der ext3 Partition, wodurch Signatur, RAM Parameter und boot loader verloren gehen, womit die Karte dann nicht mehr bootfähig ist.
Ich hatte mal ein bisschen experimentiert und den Bereich von 0x0 bis 0xEA6FFF einer frisch geklonten SD Karte (also die ersten 30008 Sektoren ) mit einem Diskeditor ausgelesen und gesichert. Danach hatte ich die Partition vergrößert (nur nach hinten, der Bereich vor der Partition muss natürlich frei bleiben) und anschließend die jetzt geänderte Partitionstabelle an Offset 0x1B8 gesichert (Länge 72 Byte). Danach habe ich die gesicherten Sektoren wieder auf die Karte zurückgeschrieben um die Karte wieder bootfähig zu machen. Dabei wurde die vom Partitionierungstool durch das Vergrößern veränderte Partitionstabelle natürlich wieder mit den alten Daten überschrieben. Daher habe ich dann die Tabelle wieder durch die zuvor gesicherte Tabelle ersetzt. Die Karte wurde unter Linux bzw. auch im Windows-Tool dann auch mit der korrekten Partitionsgröße erkannt. Trotzdem ließ sich die Anlage nicht mit der Karte starten. Sie wurde zwar als Bootmedium erkannt, die grüne LED blieb aber dauerhaft an und weiter passierte nichts mehr.
Irgendwas habe ich also offensichtlich übersehen (vielleicht muss bei einer größeren Partition doch noch irgendein Konfigfile oder der boot loader irgendwie angepasst werden). Hat da jemand eine Idee?
Bei Gelegenheit werde ich mal eine auf diese Art erzeugte Karte mit einer durch den Cardmanager beschriebenen 16GB Karte vergleichen, vielleicht ergibt sich daraus, wo hier der Fehler liegt.
habe Ich mir den Bootvorgang der OsBiz und die SD Kartenstruktur mal ein bisschen näher angeschaut und jetzt ist auch klar, warum blosses Kopieren der ext3 Partition von einer funktionsfähigen SDHC Karte nicht ausreicht, um eine bootfähige Karte zu erhalten.
Die CPU der OsBiz hat einen ROM-Loader (first-stage-loader) der nach dem Einschalten unter anderem am SDHC Interface nachschaut, ob dort eine bootfähige Karte zu finden ist. Die erkennt er an einer Signatur (0x42, 0x4F, 0x4F, 00x54 entspricht im ASCII der Zeichenfolge BOOT ) an Offset 0x40. Ist diese Signatur nicht vorhanden, ist der Bootvorgang an der Stelle zu Ende.
Da für den weiteren Bootvorgang das an der CPU angeschlossene DDR Ram gebraucht wird, liegen hinter der Signatur die entsprechenden Konfigurationsparameter für den DDR RAM Controller, mit dener der Loader den Controller konfiguriert. Ist das RAM bereit, wird von der Karte ein second-stage-bootloader (so wie es aussieht wohl uboot) gelesen, ins RAM kopiert und dort angestartet. Erst dieser Loader kann dann auf die ext3 Partition zugreifen und das Linux starten.
Signatur, RAM Parameter und der second stage boot loader liegen alle ausserhalb der ext3 Partition im nicht partitionierten Bereich am Anfang der Karte und werden dann natürlich nicht mitkopiert, wenn man nur die Partition auf eine andere Karte kopiert.
dd kopiert sektorweise, völlig unabhängig vom Filesystem oder Datenträgerstruktur , etc, daher funktioniert das Klonen der Karte mit dd.
Was leider nicht geht, ist die auf eine 16GB Karte geklonte 7.29GiB Partition einfach zu vergrößern, um den zusätzlichen Platz auf der Karte auch nutzen zu können (z.B. um auf V3 Software updaten zu können). Ich habe das mit zwei verschiedenen Tools (gparted und Linux und DiskGenius unter Windows) versucht und beide überschreiben ungefragt und ohne Warnung den nicht partitionierten Bereich vor der ext3 Partition, wodurch Signatur, RAM Parameter und boot loader verloren gehen, womit die Karte dann nicht mehr bootfähig ist.
Ich hatte mal ein bisschen experimentiert und den Bereich von 0x0 bis 0xEA6FFF einer frisch geklonten SD Karte (also die ersten 30008 Sektoren ) mit einem Diskeditor ausgelesen und gesichert. Danach hatte ich die Partition vergrößert (nur nach hinten, der Bereich vor der Partition muss natürlich frei bleiben) und anschließend die jetzt geänderte Partitionstabelle an Offset 0x1B8 gesichert (Länge 72 Byte). Danach habe ich die gesicherten Sektoren wieder auf die Karte zurückgeschrieben um die Karte wieder bootfähig zu machen. Dabei wurde die vom Partitionierungstool durch das Vergrößern veränderte Partitionstabelle natürlich wieder mit den alten Daten überschrieben. Daher habe ich dann die Tabelle wieder durch die zuvor gesicherte Tabelle ersetzt. Die Karte wurde unter Linux bzw. auch im Windows-Tool dann auch mit der korrekten Partitionsgröße erkannt. Trotzdem ließ sich die Anlage nicht mit der Karte starten. Sie wurde zwar als Bootmedium erkannt, die grüne LED blieb aber dauerhaft an und weiter passierte nichts mehr.
Irgendwas habe ich also offensichtlich übersehen (vielleicht muss bei einer größeren Partition doch noch irgendein Konfigfile oder der boot loader irgendwie angepasst werden). Hat da jemand eine Idee?
Bei Gelegenheit werde ich mal eine auf diese Art erzeugte Karte mit einer durch den Cardmanager beschriebenen 16GB Karte vergleichen, vielleicht ergibt sich daraus, wo hier der Fehler liegt.
