parameter

[Oma7144]

Ich versuche noch mal eine Zusammenfassung:

Nachdem der Stg 1 Bootloader im SRAM des RK2918 läuft, muß er folgende features zur Verfügung stellen:

Erfolgreiche Abfrage einer Tastatureingabe
1) Starten im Fastboot - Verbindung zum PC; mittels des RKAnoid-Tool können auf dem NAND Lösch- und
Flashvorgänge ausgeführt werden
2) Starten im Recovery - Stg 2 wird nachgeladen, initialisiert den RAM und lädt aus /recovery eine
Ramdisk in den RAM

Keine Tastatureingabe
3) Starten in Normalboot - Stg 2 wird nachgeladen, initialisiert den RAM und lädt Stg 3 nach, die dann das
Filesystem aufsetzt und nach Abfrage der flag in /misc den Kernel lädt

Läuft Stg 2 und schlägt das Laden von Images fehl
4) Starten einer Console (Gedächniswiedergabe von fluxflux)
1. Neu booten.
2. Reset/Werkseinstellungen wiederherstellen.
3. Von SD-Karte installieren.
4. Von uDisk installieren.
5. Recovery starten.


Könnte das in unserem Fall so hinkommen?

Was passiert beim Booten von update.img über den SD-Card slot? Ist das die Anwendung von 2) ?
Es läßt sich offensichtlich mit keinem (üblichen) Tastencode in 2) Recovery starten.

Auch funktionieren die (übliches) Telefon-Codes nicht, um in ein Enginereering- oder Factory-Setup
zu kommen.

 

[Astralix]

Schöne Beschreibung, wie ein normales (teures) Android Handy bootet.

Das RK29SDK und damit das Odys machen es aber leider etwas anders, wie ich es hier schon mehrfach gepostet habe und wie man leicht am Verhalten des Loox in bezug auf ADB und FASTBOOT feststellen kann.

Das 'etwas andere' Verhalten des Loox beim Booten liegt daran, dass die eben keinen echten Fastboot drinn haben. Ich würde diesen Begriff auch gerne vermeiden, legt er doch nahe, dass man das fastboot Tool von Android verwenden kann.
Aber das RK29SDK bleibt nach einem adb reboot bootloader nicht einmal in selbigem, sondern startet einfach neu.

Der Bootloader aus dem RK29SDK ist etwas halbgares, das halt das nötigste kann, aber nicht zu dem kompatibel ist, was man von teuren Tablets oder Mobiles der Klasse HTC oder so gewohnt ist.

Korrekturen zu Deiner Beschreibung:

Der interne 1st Stage Bootloader läuft aus einem internen ROM des RK2918 und kann auch nur lesend auf einen externen Fest-Speicher (FLASH, SD, eMMC) zugreifen.
Er kann über USB gesteuert werden. Er hat zuerst einmal nur die 16kB internes SRAM zur Verfügung.

Der 2nd-Stage taucht nicht wirklich mit sichbarer Aktion auf. Er hat auch nur Zugriff auf die internen 16kB SRAM und initialisiert die für alles weitere benötigten Speicher, also das DRAM, weitere FLASHes u.s.w. Dann lädt er den 3rd-Stage in das DRAM und startet es.

Der 3nd-Stage kann nach nem Knopp gucken, ob der gedrückt ist und er kann flashen, das wars. Der 3rd-Stage erscheint auch mit Meldungen auf der Konsole.
Er kann noch nachsehen, ob ein Image im boot ist, oder ein Image im recovery. Findet er da nix, bleibt er aktiv und hofft auf Rettung via USB.

Ob er auch von einer SD ein Image flashen kann oder ob dazu ein System auf der SD sein muss, weiss ich nicht, dazu müsste man mal EraseIDB machen und dann ein update.img auf einer SD einstecken.

Gruss
Astralix

 

[Oma7144]

Der 3nd-Stage kann nach nem Knopp gucken, ob der gedrückt ist und er kann flashen, das wars. Der 3rd-Stage erscheint auch mit Meldungen auf der Konsole.
Er kann noch nachsehen, ob ein Image im boot ist, oder ein Image im recovery. Findet er da nix, bleibt er aktiv und hofft auf Rettung via USB.

Gut. Danke.

Der 3nd Stge ist doch der code aus unserer boot.img, oder?

In recovery.img ist nicht wirklich was Brauchbares drin, oder?

 

[Astralix]

Ich sagte ja schon, dass das System auf dem Loox eher eine freie Interpretation eines Android Systems ist. War eher für eine schnelle Markteinführung gedacht.

Daher ist der Kernel nicht im boot.img wo er normalerweise ist, was uns jetzt die Probleme mit der initrd beschert. Die Recovery ist vermutlich ziemlich leer, denn wenn man die 1205 auf einem zerflashten Dateisystem startet, dann sieht man auf der Seriellen etliche versuche etwas von recovery woanders hin zu kopieren, was aber mangels Daten auf der recovery dann fehlschlägt.

 

[Oma7144]

Sorry der Nachfrage, aber ich wollte verifizieren, wo denn der 3rd Stg Bootloader ist. Um es mal an der Maske im RKAnoid-Tool festzumachen:

Loader = 2nd Stg Bootloader

Boot = boot.img = 3rd Stg Bootloader


D@niel hatte ja mal eine Bootsequenz mitgeschrieben:

... wäre rot = Stg 2 und blau = Stg 3 ?

In
DDR3
bus width=32 col=10 bank=8 row=14 CS=1
cap=512MB
OUT
BUILD[0006]=====0
GetRemapTbl flag = 0
OK!
Boot ver: 2011-04-22#1.61
Unknow param: FIRMWARE_VER:0.2.3!
Unknow param: MACHINE_MODEL:Odys-Loox!
Unknow param: MACHINE_ID:007!
Unknow param: MANUFACTURER:RK29SDK!
ORG 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),0x00080000@0x0000E000(system),0x00082000@0x0008E000(backup),0x0003a000@0x00110000(cache),0x00100000@0x0014a000(userdata),0x00002000@0x0024a000(kpanic),-@0x0024c000(user)
get command in misc
no command
Normal boot
Loading boot ...
Check image...
Check OK!
Load ok!
Loading kernel ...
Check image...
Check OK!
Load ok!
END ===== 8919
CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x040000 mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00002000@0x00008000(boot),0x00004000@0x0000A000(recovery),0x00080000@0x0000E000(system),0x00082000@0x0008E000(backup),0x0003a000@0x00110000(cache),0x00100000@0x0014a000(userdata),0x00002000@0x0024a000(kpanic),-@0x0024c000(user) bootver=2011-04-22#1.61 firmware_ver=
Starting kernel...@0x60408000

 

[Astralix]

Hi!

Ich bin da geerade etwas unsicher. Im abgespeckten RK29 Datenblatt steht etwas wie Manufacturer Data for DDR setup parameters oder so ähnlich.

Das kann bedeuten, dass die ganzen bytes vor dem eigentlichen Bootloader Code eine ganz andere Bedeutung haben, nämlich eben die Parameter für den zu nutzenden Speicher.
Der 1st-Stage Bootloader würde diese Parameter aus dem Header des 2nd-Stage auslesen, den Speicher initialisieren und dann den 2nd-Stage starten. Das ist aktuell jedenfalls eine mögliiche Erklärung, warum der bootloader nicht sofort mit Code anfängt, sondern nach dem Token BOOT noch einige Bytes merkwürdiger Daten enthält und erst viel Später dann Code zu finden ist.

Damit gäbe es dann keinen 3rd-Stage mehr in unserem Fall, da der 2nd-Stage Bootloader gleich das Image bootet. Den Fastboot haben die RockChip Jungs im SDK einfach eingespaart.

Ich kann es noch nicht genau sagen, weil mein Disassembler mit ARMv7 / THUMB2 noch nicht klar kommt.

 

[D@niel]

warum der bootloader nicht sofort mit Code anfängt, sondern nach dem Token BOOT noch einige Bytes merkwürdiger Daten enthält

Siehe https://www.android-hilfe.de/forum/...schnittstelle.187512-page-3.html#post-2543479 . Wenn man sich den zwischengeparkten loader auf misc anschaut, entspricht der nicht direkt dem 29xxLoader-Binary. Erst weiter hinten im 29xxLoader-Binary tauchen Daten auf, welche man in misc wieder finden kann. Da ist wohl außen herum nochmal ein Paketformat, welches der erste Verschiebe-Schritt beim Update haben möchte...

 

[wickiw]

gibt es irgendwo eine verlaessliche doku darueber, was der interne bootloader kann? theoretisch muesste man es doch hinbekommen, (ggf. ueber einen zwischenschritt) einen kernel von der sd-karte zu laden und dann zu starten. und dann ein "normales" linux zu booten. hat da schon mal jemand was geschafft ?

 

[Astralix]

Hi,

In dem Werbeblatt des RK2918 steht, dass er von SD Booten kann. Dazu wird es die richtige Bestückung von Widerständen oder Brücken an bestimmten Pinnen erfordern.
Oft ist es aber so, dass damit nicht an eine externe SD-Card sondern an einen aufgelöteten eMMC Flash gedacht wird. Und daher ist diese Option gerne auf den SDHC0 begrenzt. Der SDHC0 ist aber nur intern verfügbar und auf einigen Varianten (z.B. Xpress) ist dort der WLAN Chip verlötet. Der SD-Card Slot ist auf allen Tablets an SDHC1 angeschlossen.

Also:
Boot-Pin Konfiguration: Unbekannt
Boot-Pins auf Platine erreichbar: Unbekannt
Booten auch von SD-Card möglich oder nur MMC: Unbekannt
Booten auch von SD1 oder nur SD0: Unbekannt
Bootloader patchbar auf SD1 statt onBoard Flash: Unbekannt
Quellcode/ Format des Bootloaders: Unbekannt
Vollständiges Datenblatt RK2918: Unbekannt
Kooperation von RockChip: Nein
Herausgabe des EntwicklerDatenblatts gegen Unterzeichnung NDA: Nein
(oder genauer: Sie antworten nicht einmal auf freundliche Anfragen)

Chance das erfolgreich umzusetzen: < 20%... Sorry

Gruß, Astralix

 

[Oma7144]

Was ist mit der Möglichkeit mit dem RKAnoid-Tool ein network file system aufzuspielen?

 

[wickiw]

Hi,

In dem Werbeblatt des RK2918 steht, dass er von SD Booten kann. Dazu wird es die richtige Bestückung von Widerständen oder Brücken an bestimmten Pinnen erfordern.
Chance das erfolgreich umzusetzen: < 20%... Sorry

aber wenn ich das richtig verstanden habe, dann wird das update.img
doch von der sd-karte gebootet. nur laedt der dann keinen kernel sondern
brennt ein neues image. (oder kommt dieses zeugs schon aus einem zuvor
gebooteten mdt? - dann waere das ding ja auch brickbar)

--------------------
print "\nPlease KEEP your USB cable or DC-in connected\n"
print "Do NOT remove SD card form the device\n\n"

# ....kernel
write_image PACKAGE:kernel KERNEL:
check_image PACKAGE:kernel KERNEL:

# ....boot
write_image PACKAGE:boot BOOT:
check_image PACKAGE:boot BOOT:
.....
# ....recovery
usw....
-------------------

und dieser bootloader wird doch ein
bisschen mehr koennen als nur
check_image, write_image, print...
oder ?

munter bleiben wicki

 

[Astralix]

Der kernel kennt kein NFS.
In meinen experimentellen kernel könnte man NFS hinzufügen. Dafür műsste dann aber WLAN erst mal laufen. Dann műsste man aber die blobs fűr den WLAN chip im Kernel unterbringen...

Fűr Experimente mit Android und so weiter ist das vielleicht hilfreich... Aber recht aufwändig.

Astralix

 

[wusel]

aber wenn ich das richtig verstanden habe, dann wird das update.img
doch von der sd-karte gebootet. nur laedt der dann keinen kernel sondern
brennt ein neues image. (oder kommt dieses zeugs schon aus einem zuvor
gebooteten mdt? - dann waere das ding ja auch brickbar)

--------------------
print "\nPlease KEEP your USB cable or DC-in connected\n"
print "Do NOT remove SD card form the device\n\n"

# ....kernel
write_image PACKAGE:kernel KERNEL:
check_image PACKAGE:kernel KERNEL:

# ....boot
write_image PACKAGE:boot BOOT:
check_image PACKAGE:boot BOOT:
.....
# ....recovery
usw....
-------------------

und dieser bootloader wird doch ein
bisschen mehr koennen als nur
check_image, write_image, print...
oder ?

munter bleiben wicki

das update.img wird nicht von SD-Card gebootet sondern nur von dort gelesen; und es wird doch dazu ein Kernel geladen, uind zwar steckt dieser in der recovery.img und nicht in irgendeinem Bootloader. Die Befehle sind ja im update-script enthalten und werden wohl vom Recovery-System interpretiert und abgearbeitet. PopEi und ich haben heute mal 'ne Menge recovery.img von verschiedensten RK29xx Boards geflasht in der Hoffnung ein System zu erwischen dass etwas mehr kann als die paar Befehle die uns vom update-script her bis jetzt bekannt sind - leider negativ bis jetzt. Es gibt zwar einige die funtkionieren und auch deutlich mehr Auswahl-Optionen bieten, aber das wars dann auch schon; sogar Befehle wie format SWAP: die ja im recovery-script vorhanden sind und sehr wahrscheinlich ja auch vom Recovery-System interpretiert werden führten im update-script zu einem Fehler und Abbruch des Update-Prozesses
Das Ziel der ganzen Spielerei war in erster Linie herauszufinden ob es irgendwie möglich ist ein Erase IDB aus einem SD-Card Update heraus anzustossen damit es auch möglich ist neue Systeme via SD-Card zu flashen die ein Löschen des IDB erfordern ...; leider war diese Aktion bis jetzt erfolglos ...
Man müsste also mal ein gutes recovery.img auseinander pflücken und genauer analysieren - eventuell lässt sich da noch was machen ...

 

[Oma7144]

es wird doch dazu ein Kernel geladen, uind zwar steckt dieser in der recovery.img und nicht in irgendeinem Bootloader.

... da muß dann aber auch noch eine Ram-Disk drin sein, oder?

ob es irgendwie möglich ist ein Erase IDB aus einem SD-Card Update heraus anzustossen

... ich wäre eher am umgekehrten Weg interressiert: wie sichert man ein komplettes ROM weg (oder zumindest /data)?

 

[wusel]

... da muß dann aber auch noch eine Ram-Disk drin sein, oder?

yep, ist auch - das recovery.img scheint ein kombiniertes boot/kernel Image zu sein ...

... ich wäre eher am umgekehrten Weg interressiert: wie sichert man ein komplettes ROM weg (oder zumindest /data)?

hmm, da habe ich Dir doch schon eine Möglichkeit zu vorgeschlagen mit ADB? Klappt das nicht? Aber dazu sollten wir vielleicht mal einen neuen Thread aufmachen ...

 

[wickiw]

das update.img wird nicht von SD-Card gebootet sondern nur von dort gelesen; und es wird doch dazu ein Kernel geladen, uind zwar steckt dieser in der recovery.img
.....
Man müsste also mal ein gutes recovery.img auseinander pflücken und genauer analysieren - eventuell lässt sich da noch was machen ...

also in der recovery.img, die ich hier habe, steht das hier drin:<br />

drwxrwx--- 2 1001 1001   4096 1970-01-01 01:00 cache
drwxrwx--x 2 1001 1001   4096 1970-01-01 01:00 data
-rw-r--r-- 1 1001 1001    217 1970-01-01 01:00 default.prop
drwxr-xr-x 2 1001 1001   4096 1970-01-01 01:00 dev
drwxr-xr-x 2 1001 1001   4096 1970-01-01 01:00 flash
-rwxr-x--- 1 1001 1001  94200 1970-01-01 01:00 init
-rwxr-x--- 1 1001 1001   1057 1970-01-01 01:00 init.rc
drwxr-xr-x 2 1001 1001   4096 2012-02-17 09:15 lib
drwxr-xr-x 2 1001 1001   4096 1970-01-01 01:00 proc
drwxr-xr-x 3 1001 1001   4096 2012-02-17 09:15 res
-rw-r--r-- 1 1001 1001 113525 1970-01-01 01:00 rk29xxnand_ko.ko
drwxr-x--- 2 1001 1001   4096 2012-02-17 09:15 sbin
drwxrwxrwx 2 1001 1001   4096 1970-01-01 01:00 sdcard
drwxr-xr-x 2 1001 1001   4096 1970-01-01 01:00 sys
drwxr-xr-x 4 1001 1001   4096 2012-02-17 09:15 system
drwxr-xr-x 2 1001 1001   4096 1970-01-01 01:00 system_mount
drwxr-xr-x 2 1001 1001   4096 1970-01-01 01:00 tmp

das init ist schon wieder so ein ver$$$-android-init :-(

aber egal. wenn man das austauscht gegen ein ordentliches
linux-init, wieder einpackt und auf die sd-karte packt, dann
sollte es doch booten.

oder sehe ich das falsch?
wird beim booten von sd-karte (also wenn ein update.img drin
ist) wirklich das darin enthaltene recovery.img ausgefuehrt?
oder wird es erst ins flash gebrannt und dann ausgefuehrt?

ich will doch nur ein ordentliches linux von der SD-karte starten
koennen. ohne was zu brennen.

munter bleiben

wicki

 

[wusel]

Hi wicki,

aber egal. wenn man das austauscht gegen ein ordentliches
linux-init, wieder einpackt und auf die sd-karte packt, dann
sollte es doch booten.

oder sehe ich das falsch?

nö, das sollte schon gehen solange Du auch den Rest (kernel) wieder dazu packst ...

wird beim booten von sd-karte (also wenn ein update.img drin
ist) wirklich das darin enthaltene recovery.img ausgefuehrt?
oder wird es erst ins flash gebrannt und dann ausgefuehrt?

nein, glaube ich nicht. Das update.img wird nur erkannt, es wird irgendwo ein Flag gespeichert und dann rebootet; beim Boot wird das Flag getestet, und wenn gesetzt dann nicht normal (boot.img) sondern speziell (recovery.img aus Flash-Speicher) gebootet; und das Recovery übernimmt dann alles Weitere wie Prüfen und Flashen des Images; außerdem sollte es auch noch eine Option geben die nur das system.img neu flasht was dann das Recovery wäre (das update.img liegt komplett im Flash als backup.img = update.img im alten RKAF Format)

ich will doch nur ein ordentliches linux von der SD-karte starten
koennen. ohne was zu brennen.

das sollte auch möglich sein wenn Du dem recovery.img eine zusätzliche Auswahl beibringst - nämlich von SD ein Linux ins RAM zu laden und dort zu starten; also am "einfachsten" ist wahrscheinlich wenn man einen Bootloader wie syslinux entsprechend modifiziert ...
Schau Dir mal dieses recovery.img an - kannst Du mit dem Windoof Flashtool separat flashen ...
Noch ein Tip: schau Dir mal die Ausgabe von cat /proc/mtd an ...

 

[Oma7144]

Irgendwo steckt da doch was ;-)

 

[Astralix]

Das Ziel der ganzen Spielerei war in erster Linie herauszufinden ob es irgendwie möglich ist ein Erase IDB aus einem SD-Card Update heraus anzustossen damit es auch möglich ist neue Systeme via SD-Card zu flashen die ein Löschen des IDB erfordern ...; leider war diese Aktion bis jetzt erfolglos ...
Man müsste also mal ein gutes recovery.img auseinander pflücken und genauer analysieren - eventuell lässt sich da noch was machen ...

...

Nachtrag:
Man sollte ein paar mehr Posts lesen, bevor man Antwortet. Ihr habt das Image ja schon ausgepackt

Init ist übrigens nicht verammt-Android, sondern in Embedded Systemen üblich.

Du kannst ein komplettes kernel-image mit initramfs als combined image machen. Wenn Du das Pad dazu bekommst, dieses image als bootbar anzusehen (eventuell durch vorgaukeln, dass es ein update.img sei) dann hast du gewonnen, weil du deine eigene init im initramfs drin hast, die dann die von Dir gewünschten Befehle ausführt. Damit kannst Du auch bestimmen, welche Partitionen gemountet werden u.s.w.
Damit bleiben andere inits und fstabs u.s.w. aussen vor.

Gruß, Astralix

 

[wishmasterf]

Ok ich hab jetzt vielleicht ne ganz saublöde frage, aber "clockworkmod" könnten wir nicht als recovery flashbar machen?