parameter

[fluxflux]

Diese Datei wird beim Erstellen des update.img oder beim direkten Flashen des Loox benötigt, damit das System den Speicher korrekt zuweist.

Ich habe jetzt eine system.img, die ext3-gepackt ist, eine veränderte boot.img, die /system als ext3 mountet, das System bootet auch ein bisschen, dann geht es aer nicht weiter, da ich parameters nicht angepasst habe.

Wie muss parameter

FIRMWARE_VER:0.2.3
MACHINE_MODEL:rk29sdk
MACHINE_ID:007
MANUFACTURER:RK29SDK
MAGIC: 0x5041524B
ATAG: 0x60000800
MACHINE: 2929
CHECK_MASK: 0x80
KERNEL_IMG: 0x60408000
COMBINATION_KEY: F,0,1
CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x500000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00002000@0x00008000(boot),0x00004000@0x0000A000(recovery),0x00040000@0x0000E000(system),0x00042000@0x0004E000(backup),0x0003a000@0x00090000(cache),0x00240000@0x000ca000(userdata),0x00002000@0x0030a000(kpanic),-@0x0030c000(user)

verändert werden, wenn meine neue system.img 256 MB groß ist. Denn diese Variante passt offensichtlich nicht, obwohl sie von mkupdate erstellt wurde.

Ich denke, dass dann ein gerootetes, schreibbares Loox möglich ist ...

Danke für jede Hilfe,

Thomas.

 

[Oma7144]

Pack das mal in cramfs ein: Nextbook premium 7 - SlateDroid.com - Page 3

 

[fluxflux]

Ich habe es gefixt, die Partition für /system war nur zu klein.

Thomas.

 

[Käsebrot]

Ich habe das gleiche Problem: system ist ext3 und das Teil fährt nicht ganz hoch. Was hast Du wo angepasst. Evtl läuft dann auch ICS.
Danke im voraus.
KB

 

[fluxflux]

Die Datei "parameter" muss lediglich hinsichtlich der Speichergröße des system.img angepasst werden.

Ich habe 256 MB, daher habe ich den Eintrag

0x00040000@0x0000E000(system)

geändert in

0x00100000@0x0000E000(system)

und damit dann das Update-Image erstellt.

Oder mit dem Flashtool einfach die neue system.img und parameters aufs Loox flashen

Thomas.

 

[Oma7144]

Die Datei "parameters" muss lediglich hinsichtlich der Speichergröße des system.img angepasst werden.

Drei Verständnisfragen:

1) Der Boot-Prozess wird ja aus einem code angestoßen, der in der CPU hinterlegt ist. Inwieweit sind dort feste
jumps hinterlegt, wo dann später der Anfang einzelner Partitionen zu finden ist? Ist das nur ein jump, um den
Bootloader zu finden, der dann wiederum die anderen jumps setzt?

2) Wenn dann der Bootloader in den RAM geladen ist und läuft, initiiert er ja die Hardwareumgebung (Memory,
Filesystem, Netzwerk o.ä.). Wird hier schon die Sicherheitssequenz, die zu S-ON führt, mit initiiert, oder
kommt die erst später im kernel?

3) Warum eigentlich cramsf? Gibt es Phasen, wo es keine Möglichkeit gibt, code auszupacken um ihn auszuführen?

 

[wusel]

3) Warum eigentlich cramsf? Gibt es Phasen, wo es keine Möglichkeit gibt, code auszupacken um ihn auszuführen?

ich vermute mal aus 2 Gründen:
1. Platz sparen durch Kompression
2. es ist allgemein üblich auf Embedded Sytems das OS von einer R/O Partition zu starten und dann im RAM laufen zu lassen um die Flash-Speicher zu schonen; die Dinger haben eine begrenzte Lebensdauer die durch Schreiben stark verkürzt wird ...

 

[fluxflux]

Drei Verständnisfragen:

Du meinst jetzt aber nicht mich!?

Wenn ich das beantworten könnte, dann würde ich mit "Sowas" mein Geld verdienen ...

Thomas.

 

[fluxflux]

1. Platz sparen durch Kompression

Wo wird denn der Platz gespart oder bei ext3 verschwendet? Auf dem Flashspeicher = NAND?

Nur zum Verständnis, dass ich mir auch ein Bild machen kann ...

Danke,

Thomas.

 

[Oma7144]

ich vermute mal aus 2 Gründen:

2. es ist allgemein üblich auf Embedded Sytems das OS von einer R/O Partition zu starten und dann im RAM laufen zu lassen um die Flash-Speicher zu schonen; die Dinger haben eine begrenzte Lebensdauer die durch Schreiben stark verkürzt wird ...

Sorry, auch hierzu 'ne Nachfrage: auf dem gleichen NAND legt er doch das Filesystem an, um dann wie der Teufel zu schreiben ...

 

[fluxflux]

Sorry, auch hierzu 'ne Nachfrage: auf dem gleichen NAND legt er doch das Filesystem an, um dann wie der Teufel zu schreiben ...

Ich habe wie auch auf anderen Flash-Speichern, auf denen ein Linux läuft, die /system mit noatime,nodiratime gemountet, was die Schreibzugriffe reduziert.

Im übrigen denke ich nicht, dass der Flash-Speicher durch ein r/w-System kaputt geschrieben werden kann.

Die Diskussion gab es ja bereits, als die ersten eeePCs mit Flash-Speicher aufkamen, da habe ich dann erklärt bekommen, dass der Flash-Speicher selbst bei täglichem Dauergebrauch das Leben des eeePCs um ein Vielfaches überdauern dürfte.

Thomas.

 

[fluxflux]

Ich denke, dass ich die parameter-Datei jetzt verstanden habe.

Die Zahl vor dem @ gibt die Speichergröße an, die danach den Offset. Ändere ich jetzt die system.img auf 256 MB, dann verschieben sich alle folgenden Offsets entsprechend. Das habe ich jetzt berücksichtigt und eine neue parameter erstellt, die so aussieht:

FIRMWARE_VER:0.2.3
MACHINE_MODEL:Odys-Loox
MACHINE_ID:007
MANUFACTURER:RK29SDK
MAGIC: 0x5041524B
ATAG: 0x60000800
MACHINE: 2929
CHECK_MASK: 0x80
KERNEL_IMG: 0x60408000
COMBINATION_KEY: F,0,1
CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x500000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00002000@0x00008000(boot),0x00004000@0x0000A000(recovery),0x00100000@0x0000E000(system),0x00100000@0x0010E000(backup),0x0003a000@0x0020e000(cache),0x00100000@0x00248000(userdata),0x00002000@0x00348000(kpanic),-@0x0034a000(user)

Wer kann mir den korrekten Hex-Code bestätigen?

Danke,

Thomas.

 

[Käsebrot]

so wie ich das verstanden habe werden die Größen in 512 Byte Blöcken angegeben. Demnach wären 256 MB = 0x8000 (1024 * 1024 * 256 /512), so habe ich das zumindest verstanden. 0x100000 wären demnach 512 MB. Sollte sich aber leicht mit "df" im Zielsystem nachprüfen lassen.

 

[fluxflux]

df zeigt schon 256 MB an, das sollte also passen, allerdings bootet das Loox mit der parameter nicht!

Ich verwende weiterhin die erste hier gepostete.

Thomas.

 

[fluxflux]

Aktuell verwende ich die folgende parameter, die ich auch zum Flashen bzw. Erstellen des update.img hernehme:

FIRMWARE_VER:0.2.3
MACHINE_MODEL:Odys-Loox
MACHINE_ID:007
MANUFACTURER:RK29SDK
MAGIC: 0x5041524B
ATAG: 0x60000800
MACHINE: 2929
CHECK_MASK: 0x80
KERNEL_IMG: 0x60408000
#COMBINATION_KEY: F,0,1
CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x500000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000(boot),0x00008000@0x00010000(recovery),0x00080000@0x00018000(backup),0x0003a000@0x00098000(cache),0x00100000@0x000d2000(userdata),0x00002000@0x001d2000(kpanic),0x00080000@0x001d4000(system),-@0x00254000(user)

Läuft bisher problemlos mit der system.img auf ext3 rw gemountet.

Thomas.

 

[Astralix]

Drei Verständnisfragen:
1) Der Boot-Prozess wird ja aus einem code angestoßen, der in der CPU hinterlegt ist. Inwieweit sind dort feste
jumps hinterlegt, wo dann später der Anfang einzelner Partitionen zu finden ist? Ist das nur ein jump, um den
Bootloader zu finden, der dann wiederum die anderen jumps setzt?

Ja, das ist richtig:
1st Stage Bootloader ist fest in der CPU und lädt einen kleinen 2nd-Stage Bootloader aus anderen Speichern, die man per Jumper an der CPU konfigurieren kann, ins interne RAM der CPU.
Der 2nd Stage Bootloader initialisiert das RAM und ggf. einen weiteren Speicher aus dem der nächste Code in RAM geladen wird.
Warum? Der Chiphersteller kann ja nicht wissen, was für FLASH (parallel / seriell, Waitstattes, Bitbreite (8/16/32) und was für RAM (SRAM/DRAM DDR2 oder DDR3, Timing, welche Banks, wie viele Chips) sein Kunde verbaut.
Also schiebt der Kunde seinen 2nd-Stage Bootloader nach, der RAM und Speicher initialisiert und den Code dahin kopiert, wo der Kunde ihn braucht. Damit bestimmt der Kunde auch den Bootvector.

Dieser 2nd-Stage Bootloader lädt nun wiederum den 3rd-Stage Bootloader nach, der dann schon auf das funktionierende RAM und den Quell-Speicher zugreifen kann, aber nun nocht weitere Dinge tun kann, wie zum besipiel einen komprimierten Kernel ins RAM entpacken, einen Kernel von einer SD lesen uns ins Flash schreiben....

Dann geht der 3rd-Stage Bootloader hin und entpackt den Kernel, prüft und startet ihn und wird dann irgendwann einfach von Anwendungen oder so überschrieben.

Ich schreibe extra mal Quell-Speicher, weil man diese CPUs wirklich von verschiedenen Medien aus mit Code versorgen kann. Parallele oder serielle FLASH (MMC/SD oder eMMC) werden unterstützt aber der interne Bootloader akzeptiert auch das Download via Serielle oder USB.

Drei Verständnisfragen:
2) Wenn dann der Bootloader in den RAM geladen ist und läuft, initiiert er ja die Hardwareumgebung (Memory,
Filesystem, Netzwerk o.ä.). Wird hier schon die Sicherheitssequenz, die zu S-ON führt, mit initiiert, oder
kommt die erst später im kernel?

Nein, der 3rd-Stage Bootloader ist nach meinem Dafürhalten auf den Tablets schon das, was im Bootloader Image versteckt ist und es kann eigentlich nur den Kernel Starten, oder ein kleines Menü zur Verfügung stellen, um einen Rescue Kernel ala CWM zu starten. Aber es kann auch auf eine SD zugreifen und dort nach Images suchen und diese verifizieren und flashen.
Der 3rd-Stage ist also das, was unter den Linux basierten Routern oder Navis oder Industrie-Steuerungen der UBoot oder das RedBoot machen.
Ein stück Software um ein System zu initiieren, pflegen, flashen, sichern und auch zu starten.

Drei Verständnisfragen:
3) Warum eigentlich cramsf? Gibt es Phasen, wo es keine Möglichkeit gibt, code auszupacken um ihn auszuführen?

Nein, das cramfs wird vom Kernel dem Userspace transparent zur Verfügung gestellt. Sobald es gemounted ist, kann jede System/User Applikation darauf zugreifen, aber nur lesend. Die Kompression ist unsichtbar, allein der Kernel weiss davon.

Wenn ich das aber richtig sehe, ist für das System doch 256 MB im MTD reserviert. Wen kratzt es denn, ob diese 256MB nun zu 60% (cramfs) oder zu 90% (ext3) ausgenutzt wird. Weg ist sie doch eh.

Ich würde eher schauen, ob man nicht an anderer Stelle etwas mehr Speicher abknapsen kann. Ich habe übrigens noch garnicht mit gezählt, wie viele MB das Image in Summe auf die MTDs verteilt. In meinem Tablet ist ein 4GB Speicher Chip verlötet, ein hynix H27UBK-T2A und gleich neben ihm ist noch einmal Platz für einen davon. Und nein, ich meine 4GByte, denn der Chip ist ein 32GBit Typ. Sind die 4GB echt alle weg?

So, ich hoffe, ich konnte etwas Klarheit in die Bootloader-Sequenz geben.
Für mehr Details, bitte fragen, das ist schließlich ein Heimspiel

Gruß, Astralix

 

[Oma7144]

Many thanks. Und Danke für das Angebot!

Hier hatte ich am 29.12. noch eine Frage: "Mich würde darüber hinaus noch das Thema Partitionen (wieviele und wofür) interssieren.
Beispielsweise liegen die mitgelieferte Apps auf /system; hier "gewinnt" man keinen zusätzlichen Speicher durch Löschen von Apps,
denn die Partition wird dadurch ja nicht kleiner."

fluxflux hat am 03.01. die Frage nach der Belegung des 4 GB NAND aufgeworfen, die aber eher in die Richtung ging: wie
setzt Linux unter / dev seine logischen Strukturen von Partitionen und Ressourcen? Ich würde die Frage erst mal so stellen:
ist die Belegung dynamisch adressierbar oder muß man sich an die vom Hersteller "designte" Struktur (Größe, Anfangssektor) halten?

Da wir hier unter parameters diskutieren und der bootloader (3rd) die Datei vor dem kernel lädt, kann man dann doch die Partitionen
auf dem NAND so anlegen, wie man lustig ist?

Und wenn man dann so eine Lösung wie die von Wendal hat (stock-system untouched auf /system, user-system und user-data auf
/data, somit einfrierbar und jederzeit rückflashbar), dann kann man sich doch auch von / recovery verabschieden, denn da würde ja
auch ggf. nur ein bootloader mit einem mini-kernel der ein UI zur Verfügung stellt, liegen, mit dem man dann saubermachen und rückflashen?

Bin ich da ganz falsch?

 

[Käsebrot]

@Astralix: auf das Angebot komme ich gerne zu:

Folgende Situation: wenn ich das Xpress über USB anschließe sagt RKAndroidTool (RKAT) unter Windows immer "Found RKAndroid rock usb" auch wenn ich nur einen Reset mache (also ohne Menü-Taste -> entspricht glaube ich der Vol+ beim Loox). Ich kann das Xpress also Flashen aber es startet nicht mehr.

Wenn beim RKAT den Loader anhakt und noch einen weiteren Punkt wird zuerst IDB gelöscht und neu geflash, dann startet das Tablet anscheinend neu und landet wieder automatisch (also ohne Zutun von aussen -> Menü-Taste) im "Flashmode" und der Rest wird geflasht.

Es muß also intern ein Flag oder ähnliches geben, so dass der Loader nicht den "Rest" startet sondern in den "Flashmode" geht, oder der Loader erkennt, dass kein gültiges System vorhanden ist und geht deshalb in den Flash modus.

Noch eines ist mir aufgefallen:

Der Bereich mit dem Offset 0x610000 und höher lassen sich nicht beschreiben (ca. 3 GB). In welchen Bereich wird denn der Loader geschrieben ? Die Angabe vom Offset ist hier ja offen. Auch beim auslesen dieses Bereichs (rkflashtool unter linux) kommt ein sich anscheinend ständig wiederholender Bereich mit dem Text "USB" raus.

Hat jemand dieses Phänomen (RKAT zeigt ständig "found" an und das Teil fährt nicht hoch) schon mal beobachtet ?

KB

 

[Oma7144]

Hat jemand dieses Phänomen (RKAT zeigt ständig "found" an und das Teil fährt nicht hoch) schon mal beobachtet

Es muß also intern ein Flag oder ähnliches geben, so dass der Loader nicht den "Rest" startet sondern in den "Flashmode" geht, oder der Loader erkennt, dass kein gültiges System vorhanden ist und geht deshalb in den Flash modus.

Negativ. Auf den Loox kann ich flashen was ich will, der kommt immer wieder hoch.

Wenn denn die Phasen 1 und 2 des bootens im SRAM des RK2918 ablaufen und die 2. Phase den externen RAM
vorbereitet und dann den Code (also unsere boot.image) in den externen RAM schiebt, dann kann doch
eigentlich diese flag nur im 2. bootlader sein? Wenn ich mal davon ausgehe (da EMI), daß der code für beide
loader im Boot-ROM des RK2918 hinterlegt ist , dann darf es doch gar keinen "Brick" geben (es sei denn, der NAND
ist korrupt)?

 

[Astralix]

So, jetzt gerät der Thread etwas durcheinander

Hier hatte ich am 29.12. noch eine Frage: "Mich würde darüber hinaus noch das Thema Partitionen (wieviele und wofür) interssieren.
Beispielsweise liegen die mitgelieferte Apps auf /system; hier "gewinnt" man keinen zusätzlichen Speicher durch Löschen von Apps,
denn die Partition wird dadurch ja nicht kleiner."

Es gibt verschiedene Infos dazu bei den verschiedenen Foren. Aber das Loox/Express hat keine wirklich passende Verzeichnis Struktur zu den Beispielen. Es kann halt doch jeder irgendwie immer ein bisschen anders machen.
Zu den Partitionen: Die MTD Angaben werden dem Kernel vom Bootloader (3rd-Stage) aus der Parameter Datei übergeben. Damit kann man diese beliebig verschieben, verglössern oder verkleinern.

fluxflux hat am 03.01. die Frage nach der Belegung des 4 GB NAND aufgeworfen, die aber eher in die Richtung ging: wie
setzt Linux unter / dev seine logischen Strukturen von Partitionen und Ressourcen? Ich würde die Frage erst mal so stellen:
ist die Belegung dynamisch adressierbar oder muß man sich an die vom Hersteller "designte" Struktur (Größe, Anfangssektor) halten?

Da wir hier unter parameters diskutieren und der bootloader (3rd) die Datei vor dem kernel lädt, kann man dann doch die Partitionen
auf dem NAND so anlegen, wie man lustig ist?

Nur der Bootloader muss an der richtigen Stelle wiedergefunden werden, und zwar alle Bootloader. Wobei der 1st-Stage ja in der CPU drinn ist und der 2nd Stage sich vermutlich am Anfang des FLASHes versteckt.
Alle anderen MTD Partitionen können dann verändert werden.

Und wenn man dann so eine Lösung wie die von Wendal hat (stock-system untouched auf /system, user-system und user-data auf
/data, somit einfrierbar und jederzeit rückflashbar), dann kann man sich doch auch von / recovery verabschieden, denn da würde ja
auch ggf. nur ein bootloader mit einem mini-kernel der ein UI zur Verfügung stellt, liegen, mit dem man dann saubermachen und rückflashen?

Ich bin mir nicht sicher, ob die Recovery nicht ein Bestandteil von Android ist. Das CWM residiert zum Beispiel dort und macht sich dort auch ganz praktisch. Es ist schließlich eine Sache, sein Tablet mit einem Custom oder Stock Flash zu beleben, oder mit einem kompletten Backup, welches man zurückspielt und damit auch gleich alle Apps.

Es ist aber die Frage, ob das CWM wirklich volle 256MB braucht und nicht mit sehr viel weniger zurande kommt.

Bin ich da ganz falsch?

Teile der Weisheit du bereits erlangt hast