parameter

[Astralix]

Was?
Also die parameter hätte ich jetzt unter 0x00002000, also (misc) erwartet. Ist eine übliche Adresse für alles, was der Bootloader oder Kernel und Bootloader so an Einstellungen speichern.

Wenn man davon ausgeht, dass man dem Flash mal eine Partitionstabelle verpassen will, dann ist der erste Sektor der MBR und da kann dann auch Code stehen, mindestens aber ein Sprung an die eigentliche Bootloader adresse.

Gruß, Ulrich

 

[fluxflux]

Ja, mit dem rkflashtool kann man das so auslesen, die Adresse dabei ist 0x0000 0x2000 ...

Thomas.

 

[Oma7144]

(misc) erwartet. Ist eine übliche Adresse für alles, was der Bootloader oder Kernel und Bootloader so an Einstellungen speichern.

Heißt das in /misc stehen unsere ganzen Hardwaresettings (Typ, on/off)?

 

[Oma7144]

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.

Mit dem RKAnoid-Tool kann man auch modifizierte Kernels aufspielen, um so ein network file system
zu mounten oder die rootfs zu überschreiben. Kann man das nutzen?

 

[Astralix]

Klar kann man das nutzen, ist nur via SD Card alles viel einfacher, weil man es sozusagen direkt am PC mit hin und her Schubsen von Datein machen könnte.

 

[Oma7144]

Klar kann man das nutzen, ist nur via SD Card alles viel einfacher, weil man es sozusagen direkt am PC mit hin und her Schubsen von Datein machen könnte.

Was muß denn so ein modifizierter Kernel dann können?

 

[Astralix]

Na, die Wünsche für einen modifizierten Kernel haben wir andernorts ja schon diskutiert. Ich wollte halt dem Loox generell mal ein Android 2.3.5 oder 3.0.x oder später auch ein 4.0 spendieren. Der Unterbau sollte aber mitwachsen. Also wäre ein Kernel 3.0.x oder 3.2.x interessant, da gerade im Letzteren einige Verbesserungen im Bereich Netzwerk und Taskswitching vorgenommen wurde. Das Taskswitching und ein paar andere Dinge verbessern zudem auch die Stromsparfunktionen, der Akku hält also länger.

 

[Oma7144]

Mit dem RKAnoid-Tool kann man auch modifizierte Kernels aufspielen, um so ein network file system
zu mounten oder die rootfs zu überschreiben.

Ich meinte: was muß ein modifizierter Kernel können, um ein nfs zu mounten oder die rootfs zu überschreiben?

 

[Oma7144]

Hier stehen ein paar gute Infos zum Aufbau und Funktionsweise von boot.img und recovery.img: HOWTO: Unpack, Edit, and Re-Pack Boot Images - Android Wiki

Interressant: im file /system/recovery.img liegt eine Kopie von /recovery, die jedesmal beim Ausschalten in
die Partition zurückgeflashed wird. D.h. permanente Änderungen der Partition schafft man nur hier ;-)

Weiterhin wird die Funktionsweise von ramdisk.gz erklärt, die es ja braucht, um am Filesystem selbst was ändern zu können ...

 

[D@niel]

Interressant: im file /system/recovery.img
[...]
Weiterhin wird die Funktionsweise von ramdisk.gz erklärt

Hallo Oma7144,
die ein oder andere Erkenntnis kann man da sicher noch herausziehen. Aber entweder ist die Info nicht mehr ganz up to date oder Rockchip hat ein paar Dinge anderst gelöst. Denn eine /sytem/recovrery.img finde ich in der system-Partition nicht und kernel und boot liegt bei uns ja in getrennten Partitionen und wird nicht wie beschrieben zusammengeklebt.
Gruß D@niel

 

[Oma7144]

Wir versuchen hier durch Trial & Error herauszufinden, was sich Odys (oder der Chinesische Wiederverkäufer,
oder der Indische Softwareingenieur, oder ...) bei der Zusammenstellung und Abstimmung des Gesamtsystems
gedacht hat. Wahrscheinlich werden wir herausfinden, daß man das Gesamtsystem "irgendwie" ans laufen
gebracht hat und da, wo es potentiell unstabil reagieren könnte, ist man vielfach auf die sichere Seite gegangen.
Aufgeräumt hat man nach dem "customizen" auch nicht und es können auch durchaus verschiedene Varianten
im Feld sein ...

Man kann immer wieder nur schauen, wie es andernorts gelößt ist; jeder Beitrag zur Substantiierung von Thesen,
die dann das Geheimniss des as-is Designs (als Basis für ein should Design) lüften, hilft.

Die hier aufgeworfenen Fragen zielen ja im Kern darauf, herauszufinden, was man tun muß, um beim Flashen
(egal ob über update.img oder partiell über das RKAnoid-Tool) die Userdaten zu erhalten. Sobald der 2nd Bootloader
nicht den 3rd Bootloader aus /boot startet, sondern den (Spare)-Bootloader aus /recovery, werden anschließend
die Partitionen /data und /cache formatiert. Hast du dazu Erkenntnisse oder Ideen?

 

[D@niel]

Die hier aufgeworfenen Fragen zielen ja im Kern darauf, herauszufinden, was man tun muß, um beim Flashen
(egal ob über update.img oder partiell über das RKAnoid-Tool) die Userdaten zu erhalten. Sobald der 2nd Bootloader
nicht den 3rd Bootloader aus /boot startet, sondern den (Spare)-Bootloader aus /recovery, werden anschließend
die Partitionen /data und /cache formatiert. Hast du dazu Erkenntnisse oder Ideen?

Ich kann den Effekt mit meinem Loox nicht so recht nachvollziehen. Heute habe ich z. B. kernel, boot und system neu geflasht. Und das WLAN funktioniert nach wie vor - und die Einstellungen dafür stecken ja auch irgendwo unter /data/.

 

[Oma7144]

Ich kann den Effekt mit meinem Loox nicht so recht nachvollziehen. Heute habe ich z. B. kernel, boot und system neu geflasht. Und das WLAN funktioniert nach wie vor - und die Einstellungen dafür stecken ja auch irgendwo unter /data/.

Wenn du die drei in ein laufendes System 'reinflashed, dann geht es. Wird misc & recovery mit geflasht, dann startet er
mit einem Recovery-Bildschirm und formatiert fleißig. Flashed man die recovery alleine in ein laufendes System, dann
passiert da auch nichts. Die Frage ist, wo (misc, recovery, user, ...) hinterlegt er die flag?

 

[D@niel]

Wenn du die drei in ein laufendes System 'reinflashed, dann geht es. Wird misc & recovery mit geflasht, dann startet er
mit einem Recovery-Bildschirm und formatiert fleißig. Flashed man die recovery alleine in ein laufendes System, dann
passiert da auch nichts. Die Frage ist, wo (misc, recovery, user, ...) hinterlegt er die flag?

Ich habe die misc ausgelesen (bei mir scheinbar nur voller 00-Bytes), vorne "help" reingeschrieben und zurückgeflasht (per rkflashtool unter Linux). Danach gebootet: Alles beim alten. Danach testweise die recovery mit "Odys Loox Update 1205/rockdev/Image/recovery.img" geflasht und wieder neu gebootet: Nichts besonderes gesehen und das WLAN funktioniert auch noch problemlos. Ist euer Problem vielleicht schlicht ein "feature" des mitgelieferten Windows-Flash-Tools?

 

[Oma7144]

Was passirt denn, wenn du alle Partitionen (also bis auf Loader und Backup) flashst?

 

[D@niel]

Was passirt denn, wenn du alle Partitionen (also bis auf Loader und Backup) flashst?

Aha Du flashst wohl das originale misc-Image aus dem aktuellen update rein. So konnte ich den Effekt erzielen. Aber das ist auch kein Wunder. Schau mal in die Datei (Hexdump):

00004000   62 6F 6F 74  2D 72 65 63  6F 76 65 72  79 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  boot-recovery...................
00004020   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................................
00004040   72 65 63 6F  76 65 72 79  0A 2D 2D 77  69 70 65 5F  61 6C 6C 00  00 00 00 00  00 00 00 00  00 00 00 00  recovery.--wipe_all.............

wipe_all

 

[Oma7144]

Aha Du flashst wohl das originale misc-Image aus dem aktuellen update rein. So konnte ich den Effekt erzielen. Aber das ist auch kein Wunder. Schau mal in die Datei (Hexdump):

00004000   62 6F 6F 74  2D 72 65 63  6F 76 65 72  79 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  boot-recovery...................
00004020   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................................
00004040   72 65 63 6F  76 65 72 79  0A 2D 2D 77  69 70 65 5F  61 6C 6C 00  00 00 00 00  00 00 00 00  00 00 00 00  recovery.--wipe_all.............

wipe_all

Vielen Dank D@niel! Dann haben wir ja den Übertäter ;-)


PS in der misc müssen ja eigentlich div. Hardwaresettings stehen, die brauchen wir also immer mal wieder;
wäre auch für die Jungs, die sich eine update.img bauen, sehr von nutzen!
Kannst du bitte das "wipe all" da löschen und eine clean version zur Verfügung stellen?

 

[D@niel]

PS in der misc müssen ja eigentlich div. Hardwaresettings stehen

Gerät gerade nicht zur Hand. Aber ich glaube die einzigsten Hardwaresettings (Kernel command-line, NAND-Layout usw.) stecken gleich am Anfang des flashs (Sollte mehr oder weniger der parameter-Datei entsprechen)

 

[fluxflux]

Beim Flashen wurden bei mir noch keine Daten gelöscht, wenn ich misc.img und recovery.img weggelassen und nur parameter, boot.img, kernel.img und system.img neu geflasht habe.

Das Recovery-Tool, das beim Starten dann Data, Cache und udisk löscht, wurde da nie aufgerufen.

Thomas.

 

[Oma7144]

Beim Flashen wurden bei mir noch keine Daten gelöscht, wenn ich misc.img und recovery.img weggelassen und nur parameter, boot.img, kernel.img und system.img neu geflasht habe.

Das Recovery-Tool, das beim Starten dann Data, Cache und udisk löscht, wurde da nie aufgerufen.

Danke fluxflux. Haben wir oben auch diskutiert. Der code dies zu tun liegt in /misc. Diese als clean version
(also ohne wipe all) herzustellen, würde das Problem für alle Beteiligten (insbesondere für die update.img
Jungs) beseitigen. D@niel hat eine misc.img komplett überschrieben und geflasht. Geht das so, oder sind
da noch andere Hardware-Settings z.B. USB-Config drin, die auch gebraucht werden?