parameter

[Oma7144]

M.E. läuft der Boot-Prozess so:

1) Der Code für Bootloader Stg1 ist im ROM des RK2819 hinterlegt
2) Der Code wird in den SRAM des RK2918 geladen und ausgeführt
3) Stg1 detektiert über das EMI den externen RAM und setzt ihn auf
4) Stg1 befördert den Code für Stg2 (also unsere boot.img) in den RAM
5) Stg2 setzt das Filesystem (u.ä.) auf
6) Stg2 befördert die parameters und den Kernel in den RAM
7) Der Kernel übernimmt die Kontrolle über das System
8) Der Kernel setzt Virtual-Memory und alle weiteren Systemprozesse auf

 

[Astralix]

Hi Oma!

Mal ein wenig Kopieren aus dem Datasheet des RK2918:
- Internal Boot Rom
* Size : 10KB
- Support system boot from the following device :
* 8bits/16bits Async NAND Flash
* SPI0 interface
* eMMC interface
- Support system code download by the following interface:
* USB OTG
* UART1
* Internal SRAM
* Size : 16KB
* Support security and non-security access

Nein, es ist also wirklich so wie ich es geschrieben habe:
1) Der interne 1st Stage BLD lädt den 2nd-Stage aus einem der gelisteten Inertafces
2) Der 2nd-Stage muss dann das RAM und weitere Speicher initialisieren
3) Der 2nd-Stage lädt dann den Android/Linux/Whatever 3rd-Stage Bootloader
4) Der 3rd-Stage hat dann Kontrolle über alles was man braucht zum Flashen oder starten von Linux/Android

Kein Wenn und Aber, denn der 2nd-Stage kann ebenfalls erst einmal nur auf das interne RAM zugreifen, bis er das externe initialisiert hat und damit dann auch megabyte weise Code aus einem Flash oder einer SD in selbiges schaufeln kann.

Der Kernel und das Android Basisystem laufen immer ausschliesslich aus dem RAM, denn das Flash wäre zu langsam, trotz allem Cache. Selbst das DDR3 RAM ist alleine schon zu langsam und Zugriffe darauf weden über den Cache geführt.

 

[Oma7144]

Danke Astralix. Dann passt es ja. Ich war davon ausgegangen, daß die Stg2 keine eigene Softwarelösung ist, sondern
hardwaremäßig über das External Memory Interface (EMI) gesteuert wird. So bewirbt es zumindest Rockchip.

 

[Astralix]

Das EMI ist eine sog. IP, also ein meist zugekauftes Stück Silizium, dass eine Liste verschiedener Speicher ansteuern kann. So kann es z.B. bei Flash automatisch die nötigen Waitstates einfügen oder bei DRAM im Hintergrund den Refresh machen. Es kann auch bei Anschluss gleicher Speicher für ein Paging sorgen, also immer abwechselnd auf die Speicher zugreifen, damit es schneller geht.

Das EMI ist aber einfach nur eines der verschiedenen Devices, ebenso wie die Serielle oder das LCD oder der USB. Es muss erst mal programmiert werden. Lediglich seine Gruneinstellung ist so, dass es bereits einen Flash lesen kann. Es ist nicht einmal sicher, dass es ihn auch ohne weitere Konfiguration schreiben könnte.

Was das Windows Tool übrigens machen könnte wäre den 3rd-Stage Bootloader dazu aufzufordern in den internen Bootloader zu starten. Damit kann das Tool dann den kompletten Speicher, also auch das externe Flash reprogrammieren. Denn dieses ist ja bereits initialisiert, bzw. der Bootloader wird über Funktionen verfügen, über die er das EMI für weitere Zugriffe initialisieren kann. Das kann vermutlich alles über das USB konfiguriert werden.

Ich werde bei Gelegenheit mal meinen USB Debugger drauf ansetzen und sehen, was da so genau passiert.

 

[Oma7144]

Gut, danke. Wir finden immer mehr Ansätze, wo und zu welchem Zeitpunkt wir uns "einmogeln" können ;-)


Nachtrag: Der EMI ist mit auf dem SoC.

 

[Oma7144]

Warum sind nach dem flashen eines Custom Rom die User-Daten weg? Ein Auslesen und Rückflashen der
Data-Partition unter Beachtung der parameters könnte da die Lösung sein. Wird aber vermutlich nichts
bringen, da der Bootloader uns ärgert ...

Bootloader sind vom Hersteller verschlüsselt und haben eine flag, die nur signierte Stock-Roms zuläßt.
Wendal wird nur die flag (ro.secure=0) killen, um dann das unsignierte Rom (oder einzelne unsignierte
Partitionen) einspielen zu können. Bei der Einspielung eines unsignierten Roms löscht der Bootloader
den NAND, genauer den User Bereich (/ data und / cache), stellt also den Werkszustand wieder her.

@fluxflux: hast du da eine Lösung? Schützt du deine User-Daten oder ist Titanium angesagt?

@Astralix: kannst du den 2nd bootloader manipulieren bzw. neu schreiben/setzen (der Hersteller muß das
ja auch irgendwie machen)? Dann wären wir die ganzen Sicherheitsmechanismen los ....

 

[fluxflux]

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

Mit der neuen Partition /data (ext3, 1 GB) und der /system (ext3, 256 MB) verwende ich diese 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),0x00008000@0x00008000(boot),0x00008000@0x00010000(recovery),0x00082000@0x00018000(backup),0x0003a000@0x0009a000(cache),0x00200000@0x000d4000(userdata),0x00002000@0x002d4000(kpanic),0x00080000@0x002d6000(system),-@0x00356000(user)

Thomas.

 

[Oma7144]

Mit der neuen Partition /data (ext3, 1 GB) und der /system (ext3, 256 MB) verwende ich diese parameter:

Ich sehe klare Vorteile deiner Lösung! Bitte um eine Alpha zum testen.

Übrigens hier ist ein neuer "Sparingspartner" für dich (will nativ Linux auf den Loox bringen): Linux auf Odys Loox / Serielle Schnittstelle

 

[Astralix]

Warum sind nach dem flashen eines Custom
Bootloader sind vom Hersteller verschlüsselt und haben eine flag, die nur signierte Stock-Roms zuläßt.

Das muss nicht so sein. Odys hat sich ja nicht einmal die Mühe gemacht im Kernel u.s.w. die USB Device Daten so zu ändern, dass es sich komplett mit Odys meldet. Stattdessen meldet sich ein RS29SDK... Peinlich

Wendal wird nur die flag (ro.secure=0) killen, um dann das unsignierte Rom (oder einzelne unsignierte
Partitionen) einspielen zu können. Bei der Einspielung eines unsignierten Roms löscht der Bootloader
den NAND, genauer den User Bereich (/ data und / cache), stellt also den Werkszustand wieder her.

Das ist echt ärgerlich!

@fluxflux: hast du da eine Lösung? Schützt du deine User-Daten oder ist Titanium angesagt?

@Astralix: kannst du den 2nd bootloader manipulieren bzw. neu schreiben/setzen (der Hersteller muß das
ja auch irgendwie machen)? Dann wären wir die ganzen Sicherheitsmechanismen los ....

Das Loox war ein Geschenk, daher musste ich es auch erst mal ein paar Tage seinem ursprünglichen Einsatzsweck widmen. Jetzt kann ich mal ein wenig flashen. Allerdings habe ich aktuell ein wenig den Überblick verloren, was man am besten nun so flasht. Also ein ext3 mit 1GB und angepasster Speicheraufteilung wäre mir schon recht.

Dann würde ich gerne mal ein paar linux progrämmchen schreiben, direkt corss für das Loox und sehen, ob sie laufen. Dann würde ich die Busybox etwas aufrüsten, da fehlen ein paar Sachen.

Wenn damit bewiesen ist, dass alle Tools funktionieren, dann kann man ans Eingemachte gehen. Also auch Bootloader zerpflücken oder so etwas.

Den Bootloader austauschen oder modifizieren, wird eine heikle Sache. Das original SDK Flash-Tool habe ich noch nicht gesehen, und es ist möglich, dass der USB Download ohne dieses Tool, oder ohne den passenden Widerstand auf den Pads nahe der CPU garnicht funktioniert. Damit hätte man dann nur einen einzigen Versuch

Ich werde aber mal sehen, ob der 2nd Stage schon so akribisch nach einem gültigen 3rd-Stage sucht, oder ob der nur die passende Kennung an einer bestimmten Adresse erwartet.

Im Grunde hätten wir alle es viel viel leichter, wenn man der CPU sagen könnte, sie soll von SD booten. Dann kann man sich sein System auf der SD zurech basteln und auch mal schnell komplette Dateisysteme im Kartenleser erstellen, ändern...

Ich kann mir vorstellen, dass die Chinesen das sogar so machen. Die Boards haben ja keinen JTAG bestückt und auch keine Hinweise auf irgendeinen Kontakt mit einem Nadelbett. Also werden die entweder von fleissigen Händen an USB gesteckt oder mit einer SD gebootet. Dann flasht sich das Teil und zuletzt wird der Widerstand entfernt, der das erlaubt.

Oder die bekommen tatsächlich fertig programmierte FLASH Bausteine. Aber einer gewissen Menge lohnt sich das.

Gruß, Astralix

 

[fluxflux]

Ich kann die boot.img, system.img und parameter zur Verfügung stellen, wenn es jemand hostet. Zum Flashen kann das Odys-Update-Flashtool verwendet werden, zusammen mit den fehlenden *.img-Dateien aus dem Odys-Update.

Das ist aber eine Custom-Version ohne Gmail, Email und Launcher2, dafür mit Go Ex Launcher, TitaniumBackup, k9Mail, GhostCommander und ES Datei Explorer. /etc/hosts wurde angepasst, /etc/gapps.xml geändert und /system/build.prop erweitert.

Änderungen muss dann jeder selber vornehmen.

Thomas.

 

[Oma7144]

Ich kann die boot.img, system.img und parameter zur Verfügung stellen, wenn es jemand hostet. Zum Flashen kann das Odys-Update-Flashtool verwendet werden, zusammen mit den fehlenden *.img-Dateien aus dem Odys-Update.

Das ist aber eine Custom-Version ohne Gmail, Email und Launcher2, dafür mit Go Ex Launcher, TitaniumBackup, k9Mail, GhostCommander und ES Datei Explorer. /etc/hosts wurde angepasst, /etc/gapps.xml geändert und /system/build.prop erweitert.

Änderungen muss dann jeder selber vornehmen.

Thomas.

Danke fluflux! Ändern ist ja kein Problem ;-)

Vielleicht kannst du ein update.img (flux512) daraus machen und es PopEi zum "Vertrieb" schicken?

 

[fluxflux]

Mit der update.img muss ich mich erst noch beschäftigen, da ich nicht weiß, ob die Wendal-/Odystools auch ext.images korrekt verarbeiten .,.

Thomas.

 

[Oma7144]

Am einfachsten nimm die:

kostenlos Dateien hochladen bei File Upload X

satwilli ist auch immer für einen Tipp gut ;-)

 

[PopEi]

Danke fluflux! Ändern ist ja kein Problem ;-)

Vielleicht kannst du ein update.img (flux512) daraus machen und es PopEi zum "Vertrieb" schicken?

Das wäre eine gute Idee! Dann habe ich endlich ruhe, die rennen mir die Bude ein

Alles brauch seine Zeit, also bloß nichts überhasten.
Die müßen warten, morgen gibt es die Welt ja auch noch.
Jedenfalls macht Ihr eine Tolle Arbeit!!!

 

[Oma7144]

Das wäre eine gute Idee! Dann habe ich endlich ruhe, die rennen mir die Bude ein

Die Geister, die ich rief ...


PopEi, schön das du dabei bist!

Buy the way: hast du noch Kontakt zu darkwing?

 

[PopEi]

Mit der update.img muss ich mich erst noch beschäftigen, da ich nicht weiß, ob die Wendal-/Odystools auch ext.images korrekt verarbeiten .,.

Thomas.

Ich könnte mal wusel fragen oder bitten sich das anzugucken, so wie ich das gestern mit bekommen hab wollte er sich sowieso mal damit auseinandersetzen, wenn ich ihn den auch erreiche, habe ihn heute morgen versetzt.Vieleicht heute Nacht

Nein zu darkwing habe ich keinen Kontakt, keine Ahnung was mit ihm ist?

PS:wir haben zuwachs bekommen D@niel (Linux) sieht sehr interessant aus

 

[fluxflux]

Ja gerne, ihr könnt ja die system.img, boot.img und parameter haben und ein update.img daraus erstellen.

Thomas.

 

[PopEi]

Schicke mir eine pn mit dem download und ich gucke das ich wusel ran bekomme zum Finale!

 

[Astralix]

Ich habe da noch unbeantwortete Fragen gefunden, die uns helfen können:

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?

Normalerweise wird Code aus einem parallelen oder eMMC Flash immer ab der Adresse 0x0 geladen. Dort steht bei einem ARM entweder die Interrupt Sprungtabelle oder ein Token, dass den Code als ausführbar identifiziert und dann die Interrupt-Sprungtabelle.
Wenn die Cortex A8 Archtiektur so ist, wie die M3, dann beginnt das ganze zuerst mit dem Stackpointer Init-Ẃert und dann dem Reset-Vector. Danach folgen die Vectoren für alle anderen Interrupts.
Muss ich mal nachsehen, das hier sollte ja ein ARMv7 sein.

Jedenfalls fällt es auf, dass die ersten 8MB des NAND FLASH ausgespart sind, wenn man die MTD Belegung betrachtet. Also wird hier vermutlich der 2nd Bootloader stecken. Das AFTool kann aber nur schreiben, ich habe nichts darin gesehen, um einen Flash Dump zu machen. Muss ich also unter Linux selbst mal drauf zugreifen.

Wer es ausprobieren möchte, kann in die Parameters mal eine weitere MTD hinzufügen:
0x00002000,0x00000000(2ndboot)
Dann müsste diese Partition als mtd device 2ndboot erscheinen und man kann es mit
dd if=/dev/2ndboot of=/sdcard/2ndboot.bin bs=1024 count=8192
in eine datei auf die SD kopieren und von dort auf den Rechner bringen.

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

Nur noch mal der Vollständigkeit wegen:
das cramfs erscheint transparent, d.h. Programme und Dateien, die komprimiert im cramfs liegen, können einfach gelesen werden, ohne dass das lesende System die Dekompression bemerkt.
Nur Schreiben ist nicht möglich, das Ausführen von Programmen aber sehr wohl.

 

[fluxflux]

IJedenfalls fällt es auf, dass die ersten 8MB des NAND FLASH ausgespart sind, wenn man die MTD Belegung betrachtet. Also wird hier vermutlich der 2nd Bootloader stecken. Das AFTool kann aber nur schreiben, ich habe nichts darin gesehen, um einen Flash Dump zu machen. Muss ich also unter Linux selbst mal drauf zugreifen.

Wer es ausprobieren möchte, kann in die Parameters mal eine weitere MTD hinzufügen:
0x00002000,0x00000000(2ndboot)
Dann müsste diese Partition als mtd device 2ndboot erscheinen und man kann es mit
dd if=/dev/2ndboot of=/sdcard/2ndboot.bin bs=1024 count=8192
in eine datei auf die SD kopieren und von dort auf den Rechner bringen.

Soweit ich das beim Flashen unter Linux gesehen habe, enthalten die ersten 0x2000 den Inhalt der parameter. Und zwar so:

0x00 0x20
0x20 0x20
0x40 0x20
0x60 0x20
0x80 0x20

Wenn man das überschreibt, dann ist meines Erachtens die Partitionierung weg/beschädigt ... aber dazu bin ich nicht Fachmann genug, ist mir nur aufgefallen.

Thomas.