Suche: (Low-level-)Dokumentation zum Dateisystem / Bootvorgang des SGS2

Hallo zusammen!

Als recht neuer, aber sehr technikinteressierter Nutzer eines SGS2 habe ich mich, speziell auf Empfehlung von Bekannten hin, recht schnell mit Custom-ROMs beschäftigt und nutze derzeit das Cyanogen Mod.

Die Vielzahl von Postings, Anleitungen und Informationen zu dem Thema, "wie flashe ich dies", "welche Kernel gibt es" etc. verwirren aber teils mehr als sie helfen. ;) Speziell, wenn sie unpräzise Formulierungen oder sogar widersprüchliche Informationen enthalten.

Ich würde daher gerne etwas tieferen Einblick in die zugehörigen Abläufe gewinnen, um die Anleitungen besser einschätzen zu können, und hier daher meine Frage:

Gibt es verläßliche Dokumentation zum Thema Dateisystemaufbau und Bootvorgang, für Android allgemein und das SGS2 speziell? Folgende Fragestellungen interessieren mich dabei besonders.

1. Ich habe per Root-Shell entdeckt, daß der interne Flash-Speicher offenbar in Partitionen unterteilt ist. Es gibt aber um die 10 Partitionen, und nur 4 davon sind gemountet (system, data, cache, efs). Was steckt in den anderen Partitionen? Ich vermute Boot-Image etc...?
2. Ich lese/sehe des öfteren von verschiedenen "Images", boot.img, recovery.img etc. Welche Rolle, im Vergleich zu einem PC-Linux-System, spielen diese genau?
3. Ich sehe beim SGS2 drei Boot-Modi. Normaler Boot, Recovery-Boot und KIES-Download-Boot. Welche Komponenten des (Datei-)Systems sind genau für diese Modi zuständig? Welche Images werden benutzt/geladen, um in diese Modi zu kommen? Könnte man sich beim SGS2 auch den Download-Boot zerschießen und das Gerät so komplett bricken?
4. Ich blicke noch nicht so ganz durch, wo die Überschneidungen zwischen "ROM", "Firmware", "Kernel" und "Recovery" liegen. Welche Teile des Dateisystems umfassen diese Dinge? Welche Teile umfassen herunterladbare Mods und Kernels? Wenn ich z.B. den "CF-Root" Kernel flashe, beinhaltet dieser auch das CWM-Recovery. Gehört Recovery generell zum Kernel? Oder besteht CF-Root einfach aus zwei Teilen? Gleiches gilt für Cyanogen. Auch der ersetzt den CWM-Recovery. Von PC-Linux her kenne ich "Kernel" eigentlich als eine einzelne Datei, die nichts mit dem Bootloader oder Recovery-Funktionen zu tun hat.
5. Wie läuft der Bootvorgang speziell beim SGS2 genau ab? Analog zum PC-Linux gibt es hier offenbar auch einen Bootloader, einen Kernel, ein Init-RAM-FS, ein Dateisystem mit bin, etc und sonstigen Linux-Dingen. Wo liegt hier was, und wie wird es aufgerufen?
6. Die ODIN-Software führt neben den bisher genannten Begriffen Eingabefelder für "Bootloader", "PDA", "Phone" und "CSC" auf. Ich habe eine ungefähre Vorstellung, was damit gemeint ist. Wie sieht das technisch aus? Flasht man bei Ausfüllen dieser Felder bestimmte Partitionen des Telefonspeichers?
7. Ich lese des öfteren von einem "USB Jig" (ein speziell belegtes USB-Kabel?), das u.a. auch bei kaputtem KIES-Downloader noch ein Firmwareeinspielen erlauben soll. Bedeutet dies, daß es einen hardverdrahteten "Notfall-Downloadmodus" gibt, der auch durch wildes Fehlflashen nicht zerstört werden kann? Würde aus Support-Sicht ja auch Sinn machen, wenn für eine "Reparatur" wegen Kaputtflashens nicht das Gerät auseinandergenommen werden muß, um den Flashchip in ein Programmiergerät zu stecken. Speziell weil der Flashspeicher bei der flachen Flunder bestimmt nicht gesockelt ist. ;)

Okay, ich denke der low-level-Fragenkatalog genügt erstmal. Wäre spitze, wenn mich jemand in die richtige Richtung schubsen könnte, ob und wo es Dokumentation zu diesen Dingen gibt. Besten Dank schonmal!

Viele Grüße,
Frank Zavelberg

— geändert am 01.11.2011, 14:07:15

Hallo anderer Frank!

Hui, direkt die erste Antwort von der Androiden-Gottheit. Dann mal ein doppeltes Danke für die Informationen und die nette Begrüßung!

Zu 1+2:

Vom PC-Linux her kenne ich es so, daß auf der Boot-Partition (so man denn eine separate eingerichtet hat) der Kernel und die Initramfs (RAM-Mini-Dateisystem mit den wichtigsten zum Systemstart notwendigen Dateien wie Treibern) liegen. Der Bootloader (Grub z.B.) enthält ein Menü, über das man verschiedene Boot-Ziele auswählen kann.

Kann ich mir das unter Android ähnlich vorstellen? Sprich ich habe Kernel, Initramfs und evtl. Dateisystem, jeweils für Standardboot und Recovery? Und die Dateien liegen auf verschiedenen Partitionen des Flashspeichers?

Welche Rolle genau spielt der Bootloader, aka. "boot.img"? Ist er mit Grub vergleichbar? Sprich ohne den läuft gar nichts, auch kein Recovery? Oder beinhaltet das boot.img eher die Initramfs der jeweiligen Bootmodi?

Ich stelle diese Fragen zum einen aus Interesse (ich bin ein Typ, der am liebsten jede Blackbox aufmachen und verstehen möchte ), und zum anderen weil ich einschätzen möchte, wie groß die "Zerschießgefahr" ist, wenn man das eine oder andere File flasht.

Zu 7:

"JTAG" ist in der Tat ein Standard-Verbindungsprotokoll, über das man grob gesprochen mit Hardwarebausteinen kommunizieren kann. Meist wird es zum Programmieren von Flashspeichern oder FPGAs, zum Auslesen von Debuginfos und Einspielen von Testmustern verwendet. Wenn die Flashspeicher im Smartphone in der Tat eine JTAG-Schnittstelle hätten, wäre das fein.

— geändert am 01.11.2011, 14:47:10

Ich kenne das Gefühl.


Ja das wär klasse! Das Netz ist ja wie geschrieben voll von Flashanleitungen, viele davon fundiert, einige aber auch mit "gefährlichem Halbwissen".

Ein aktuelles Beispiel, warum ich gerne mehr über die Zusammenhänge wissen möchte: Gestern habe ich im ROM-Manager von Cyanogen die Funktion "Flash Clockwork Mod" aufgerufen, weil er mir anzeigte, daß er eine neuere Version hätte als installiert ist. Blöd nur: nach dem Flashen bootete das Handy nicht mehr (bliebt beim Androiden mit dem gelben "!" hängen), weder Standard noch Recovery. (Zum Glück funktionierte der KIES-Modus noch, und über Odin konnte ich die Flunder wiederbeleben.) Da frage ich mich, warum wurde der Standardboot zerschossen, wenn man ein vielleicht unpassendes Recovery-Image flasht...

Dieses Problem braucht nicht unbedingt jetzt im Detail behandelt zu werden. Daraus entstand aber das Bedürfnis, genauer zu verstehen, was da wie wo geflasht und wann wofür genutzt wird.

— geändert am 01.11.2011, 15:35:10

Vielleicht spielt der Siyah-Kernel noch eine Rolle dabei... Das wäre das einzige, was mir in der Richtung noch einfällt. Wobei ja der Kernel des Standardsystems beim Recovery eigentlich gar nicht zum Tragen kommen sollte...

Da fällt mir noch ein, daß der Macher des CF-Root Kernels in seiner Beschreibung ausgeführt hat, daß er immer "eigene Recovery-Images macht, weil das Stock-CWM gewisse Samsung-spezifische Dinge nicht korrekt behandelt". Hmm. CF-Root bringt auch einen eigenen ROM-Manager mit, nicht die Standard-App.

Dann wundert mich noch, daß der ROM-Manager sagt: "Current Recovery: ClockworkMod 4.0.1.5", aber wenn ich ins Recovery boote, eine Versionsnummer mit 5.x angezeigt wird. Hmm?

Vielleicht erkennt/flasht der ROM-Manager unter Cyano/Siyah was falsches.

— geändert am 01.11.2011, 16:25:51

Ah richtig, hierzu bitte eine Frage, im Zusammenhang mit dem "Zusammenhang".

Wenn ich meine bisherigen Gedankengänge dazu richtig in Reihenfolge bringe, müßte doch das Recovery-System komplett unabhängig vom Live-System, sprich dem "ROM" sein, oder? Das Recovery dient doch auch dazu, selbst bei leerem boot, system, data und cache noch ein System aufspielen zu können? Oder gibt es Teile des "ROM", die auch bei Recovery zum tragen kommen?

Offenbar hatte das Problem gar nichts mit dem Flashvorgang, den ich da angestoßen hatte, zu tun.

Ich habe eben mal zum Testen aus dem ROM-Manager heraus einfach nur "Reboot to recovery" gemacht. Ergebnis: Krach bumm, kein Boot mehr. Ich gehe stark davon aus, daß die Kombination aus "Siyah-Kernel" und dem "NexS-Tweaks", die ich beim Test installiert hatte, Schuld daran ist. Denn nach dem neuerlichen Restore via Odin eben geht das "Reboot to recovery" wieder.

Allerdings: Sehr merkwürdig ist folgendes. Wenn ich mit Power Off, Volume Up, Home, Power on ins Recovery gehe, kriege ich die Version 5.0.2.7 (blaue Schrift). Diese wurde offenbar von Cyanogen 7.1 Nightly 99 installiert.

Mache ich aber "Reboot to recovery" im ROM-Manager, kriege ich 4.0.1.5 (orangene Schrift). Äääh... Habe ich zwei Recoveries auf meiner Gurke? Oder führt der ROM-Manager irgendeine Aktion durch bevor er rebootet? Ersetzt er temporär das Recovery-System mit dem, was er für richtig hält? Gibt es mehrere Recovery-Images, von denen vor dem Reboot eins ausgewählt werden kann?

Meine Verwirrung steigt...

— geändert am 01.11.2011, 18:23:57

Noch drei Beobachtungen:

1. Wähle ich im Reboot-Menü von Cyanogen (Power-Taste festhalten) "Recovery", wird die 5.0.2.7 geladen.
2. Mache ich "Reboot to recovery" im ROM-Manager, wird zum einen ein "Forced reset" gemacht (sofortiger schneller Reset scheinbar ohne Gelegenheit fürs OS für Shutdown), und
3. zum anderen erscheint, bevor das CWM 4.0.1.5 Menü angezeigt wird, kurz ein kleiner Androide mit einer Progressbar darunter. Das passiert beim Laden von 5.0.2.7 nicht! Wird da spontan irgendwas geflasht, oder ist diese Grafik Standard bei CWM 4?

— geändert am 01.11.2011, 18:27:16

Oh, ja, das sind alles sehr interessante Links!

Es wäre genial, die derzeit überall verstreuten Informationen mal an einer Stelle zu bündeln. Auch wenn ich erst ein paar Wochen bei Android dabei bin... Ich stelle mir eine Art Kompendium vor, sowas wie das "Androidpitiden-Buch", für Lowlevel-Sachen.

Der erste Link ist ja schon etwas älter. Während die grundlegenden Android-Sachen sicher immer noch gelten, ist natürlich die Frage, in wieweit spezielle Telefonhersteller an einigen Stellen vom "Standard" abweichen.

Zum Kernel: Ich hatte schonmal durch die System-Partition geblättert, konnte dort aber in der Tat nichts finden, was nach Kerneldatei aussieht. Unter PC-Linux wäre der Kernel meist eine Datei namens "vmlinuz*", üblicherweise im Rootverzeichnis, oder in der Boot-Partition. Wenn ich es richtig verstanden habe, befindet sich der Kernel bei Android in einer Imagedatei, bzw. der Boot-Partition in die ein solches Image geflasht wird ("zimage"? So heißt jedenfalls die Datei, die man beim Galaxy oft in TAR-Format Flashdateien findet, z.B. CF-Root), zusammen mit der Init-Ramdisk.

Das dopplete Recovery ist mir immer noch ein Rätsel. Bzw. okay, man kann sich sicher vorstellen daß es zwei davon gibt. Warum auch nicht, unter PC-Linux kann man ja auch diverse Kernel in die grub.cfg schreiben.

Ich stelle mir jetzt lediglich die Frage, sind beide Versionen auf dem Telefon "installiert", und der ROM-Manager schaltet nur für den nächsten Boot auf seine um? Wenn ja, wie?

Oder ersetzt er das Recovery-Image komplett durch sein eigenes, und beim nächsten Standard-Boot von Cyanogen schreibt das sein "originales" Recovery-Image automatisch wieder neu?

Für beide Theorien spricht jeweils einiges. Kann man irgendwie rausfinden, wie es wirklich gehandhabt wird? Und was genau schiefgeht, wenn ich den Siyah und diese "NexS-Tweaks" installiert habe? (Ich sollte vielleicht nochmal testen, ob es jetzt an dem einen oder anderen liegt. Ist nur ein unschönes Gefühl, wissentlich das Telefon nochmal halb zu bricken. ;) )

Eigentlich sollte weder Siyah noch NexS mit dem Recovery-Start etwas zu tun haben, da, wenn ich es richtig verstanden habe, der Hauptkernel (Siyah) gar nicht zum Einsatz kommt, und NexS legt lediglich ein paar Skripte in system/etc/init.d ab, die Kernelparameter tweaken. Aber möglicherweise geht bereits das Aktivieren der CWM-Variante von ROM-Manager schief, wenn diese Tweaks durchgeführt wurden und/oder der Siyah-Kernel läuft, und deshalb failt dann der nächste Boot, egal was man booten will. Der KIES-Modus des SGS setzt dann wohl noch früher als die Auswahl der Bootpartition an, so daß er unbeeinflußt bleibt.

— geändert am 01.11.2011, 22:20:37

So, habs jetzt nochmal getestet. Der Siyah hat die Bootprobleme verursacht:

Vor Siyah-Installation:
Cyanogen-Powerbutton startet Recovery 5.0.2.7
ROM-Manager startet Recovery 4.0.1.5

Nach Siyah-Installation:
Cyanogen-Powerbutton startet Recovery 5.0.2.6
ROM-Manager zerschießt den Boot und Recovery

Siyah bringt also offenbar eine eigene, andere Version von CWM mit als Cyanogen und zerschießt vielleicht die Version, die der RM anspringen will. Wobei ich immer noch nicht verstehe, wo diese beiden unterschiedlichen Versionen von RM und Cyano herkommen.

Weitere Vermutung: Der normale Boot ist gar nicht wirklich zerschossen. Das System wurde aber so konfiguriert, beim nächsten Start automatisch ins RM-Recovery zu springen, was fehlschlägt. Zur Wiederherstellung der normalen Startkonfiguration kommt der Recovery somit nicht, und der Boot läuft immer wieder in das zerschossene Recovery, auch wenn ich keine Taste beim Einschalten drücke.

Dafür würde eine Beobachtung sprechen, die ich letztens gemacht habe. Ich hatte aus dem ROM-Manager heraus ein Backup angestoßen. Das Recovery konnte aus irgendeinem Grund nicht starten (war meine ich nicht das Siyah-Problem sondern was anderes). Nach ein paarmal Reset-Drücken und sogar zwischendurch mal KIES-Downloadmodus wurde das beauftragte Backup dann plötzlich doch noch durchgeführt. Offenbar kann das SGS so konfiguriert werden, beim Boot zwingend das Recovery-Image anzuspringen und sogar ein bestimmtes Kommando dort auszuführen, und das auch evtl. viel später erst.

An der Stelle wäre interessant zu wissen, wie und wo dieser "Boote ins Recovery" Auftrag reingeschrieben wird. Bei PC-Linux würde man für sowas den Default-Booteintrag in der Grub-Config ändern, oder die aktive Partition der Festplatte.

— geändert am 02.11.2011, 20:25:44