parameter

In der misc.img steht tatsächlich nur drin: boot-recovery, recovery --wipe-all. Ist ja auch nur 48K groß ...

Und in der recovery.img ist dann ein kleines recovery-System, das neu formatiert, man kann sich das entpackt in Ruhe ansehen.

Thomas.

fluxflux schrieb:

In der misc.img steht tatsächlich nur drin: boot-recovery, recovery --wipe-all. Ist ja auch nur 48K groß ...

Und in der recovery.img ist dann ein kleines recovery-System, das neu formatiert, man kann sich das entpackt in Ruhe ansehen.

Zum Vergrößern anklicken....

Um es zu verstehen: in der misc.img steht kein ausführbarer Code und es ist auch keine flag, die der recovery was signalisiert?

Zur Verifizierung: ich konnte ein recovery.img solo in das laufende System flashen - da ist nichts passiert ....

Richtig, so wie ich es sehe, startet das misc.img das Recovern, fehlt dann die recovery.img, dann kommt man an die Android-Boot-Console, an der man dann 5 Optionen zur Auswahl hat ... das habe ich alles schon durch ...

Thomas.

fluxflux schrieb:

fehlt dann die recovery.img, dann kommt man an die Android-Boot-Console, an der man dann 5 Optionen zur Auswahl hat ... das habe ich alles schon durch ...

Zum Vergrößern anklicken....

Bin total erstaunt. Wie machst du denn das, daß die recovery.img fehlt?

Zum Sachstand: wenn beiden Partitionen (misc & recovery) quasi leer sind dann transportiert die Abfolge der
Bootloader die kernel.img ins RAM und das System läuft somit?

Oma7144 schrieb:

Zum Sachstand: wenn beiden Partitionen (misc & recovery) quasi leer sind dann transportiert die Abfolge der
Bootloader die kernel.img ins RAM und das System läuft somit?

Zum Vergrößern anklicken....

Da sieht man doch die Abfolge genau ( https://www.android-hilfe.de/forum/...rielle-schnittstelle.187512.html#post-2501422 ):

[...]
get command in misc
no command
Normal boot
Loading boot ...
Check image...
Check OK!
Load ok!
Loading kernel ...
Check image...
Check OK!
Load ok!
[...]

Solange die misc da nichts auslöst, ist die recovery völlig egal. Und der bootloader holt boot und kernel in den RAM und dann wird der Kernel ausgeführt...

Oma7144 schrieb:

Bin total erstaunt. Wie machst du denn das, daß die recovery.img fehlt?

Zum Vergrößern anklicken....

Beim Erstellen der neuen parameter habe ich die recovery übersehen und habe dann gesehen, wohin man da kommt ...

Thomas.

fluxflux schrieb:

Beim Erstellen der neuen parameter habe ich die recovery übersehen und habe dann gesehen, wohin man da kommt ...

Zum Vergrößern anklicken....

Das unentdeckte Land ...

... was gibt es denn da für 5 Optionen?


Zusammenfassend: misc.img mit Null überschreiben und das Problem ist gelöst?!

1. Neu booten.
2. Reset/Werkseinstellungen wiederherstellen.
3. Von SD-Karte installieren.
4. Von uDisk installieren.
5. Recovery starten.

Oder so ähnlich, habe es mir nicht aufgeschrieben ...

Thomas.

Oma7144 schrieb:

Zusammenfassend: misc.img mit Null überschreiben und das Problem ist gelöst?!

Zum Vergrößern anklicken....

Bitte nicht so kompliziert: Die Befehle müssen nach getaner Arbeit vom System doch eh wieder rausgeworfen werden. Ansonsten hättest Du ja endlos-recovery. Sprich einfach nicht wieder die misc einspielen. Die mit Null-Bytes zu überschreiben tut zwar nicht weh, aber ist nur eine Arbeitsbeschaffungsmaßnahme

fluxflux schrieb:

1. Neu booten.
2. Reset/Werkseinstellungen wiederherstellen.
3. Von SD-Karte installieren.
4. Von uDisk installieren.
5. Recovery starten.

Oder so ähnlich, habe es mir nicht aufgeschrieben ...

Zum Vergrößern anklicken....

Cool. Wobei 4. (booten von USB-Stick) sicherlich noch mal interessant sein wird ....

Wäre interressant zu wissen, wie man noch (Tastenkombi?) in dieses Boot-Menue kommt?

D@niel schrieb:

Bitte nicht so kompliziert: Die Befehle müssen nach getaner Arbeit vom System doch eh wieder rausgeworfen werden. Ansonsten hättest Du ja endlos-recovery. Sprich einfach nicht wieder die misc einspielen. Die mit Null-Bytes zu überschreiben tut zwar nicht weh, aber ist nur eine Arbeitsbeschaffungsmaßnahme

Zum Vergrößern anklicken....

Lößt das Problem leider nicht für diejenigen, die per SD-Card (update.img) updaten wollen ....

Oma7144 schrieb:

Lößt das Problem leider nicht für diejenigen, die per SD-Card (update.img) updaten wollen ....

Zum Vergrößern anklicken....

An die armen Schweinchen habe ich jetzt nicht gedacht

P.S.: Vielleicht reicht es ja die misc-Zeile aus package-file zu löschen und nochmal per "mkupdate" die update.img erzeugen zu lassen...

Lieb von euch, das ihr euch solche Gedanken um uns macht

Astralix schrieb:

Das ist echt ärgerlich!

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.

Zum Vergrößern anklicken....

Herausgearbeitet in Post #69 und #70.

Oma7144 schrieb:

Herausgearbeitet in Post #69 und #70.

Zum Vergrößern anklicken....

Astralix will wohl eher direkt von der SD booten, als selbige als Installationsquelle zu verwenden.

D@niel schrieb:

eine /sytem/recovrery.img finde ich in der system-Partition nicht

Zum Vergrößern anklicken....

Das Herunterfahren dauert sehr lange. Die Lese- und Schreibpuffer sind sicherlich relativ schnell
weggeschrieben (wäre dann wohl der Unterschied zum Reset). Bleibt die Frage: was passiert in der
restlichen Zeit?

Beachte, dass das Schreiben im Flash unendlich viel langsamer geht, als das Lesen!

Noch was interessantes zum Thema flash: Ab offset 0x007ba7e1 bekommt man mit dem rkflashtool nichts vernünftiges mehr ausgelesen. Gleichzeitig meckert auch die serielle Konsole:
FW_FlashReadLBA FLT_ERROR,LBA=7ba7e1,iret = ffffffff,tick=603816
Jetzt frage ich mich was da wohl zwischen 0x007ba7e1 und 0x800000 steckt? Vielleicht der stage 2 bootloader?
Gruß D@niel

D@niel schrieb:

Noch was interessantes zum Thema flash: Ab offset 0x007ba7e1 bekommt man mit dem rkflashtool nichts vernünftiges mehr ausgelesen. Gleichzeitig meckert auch die serielle Konsole:
FW_FlashReadLBA FLT_ERROR,LBA=7ba7e1,iret = ffffffff,tick=603816
Jetzt frage ich mich was da wohl zwischen 0x007ba7e1 und 0x800000 steckt? Vielleicht der stage 2 bootloader?

Zum Vergrößern anklicken....

Der 2nd Bootloader sollte ja im SRAM des RK2918 laufen. SRAM ist 16 KB da und dort liegt ja schon der code aus dem ROM (10KB) drin.

Was passiert denn hier:

<4>[ 0.000000] Memory policy: ECC disabled, Data cache writeback
<7>[ 0.000000] On node 0 totalpages: 92928
<7>[ 0.000000] free_area_init_node: node 0, pgdat c09363a8, node_mem_map c0000000
<7>[ 0.000000] Normal zone: 726 pages used for memmap
<7>[ 0.000000] Normal zone: 0 pages reserved
<7>[ 0.000000] Normal zone: 92202 pages, LIFO batch:31
<6>[ 0.000000] bootconsole [earlycon0] enabled
<4>[ 0.000000] CPU SRAM: copied sram code from c0937000 to ff400000 - ff401b40
<4>[ 0.000000] CPU SRAM: copied sram data from c0938b40 to ff402000 - ff4021c8

Der A8 hat eine MemoryManagementUnit (MMU). Mit dieser kann er den Speicher in Bereich aufteilen und ihn vor Zugriffen schützen. So kann er verhindern, dass eine (User-) Application auf Speicher zugreift, der dem Kernel gehört und für dessen Überleben wichtig ist. So kann er auch freien Speicher entweder dem Kernel oder dem User zuteilen.
Das gilt auch für die in den Speicher gemappten Adressen der Hardware (Ports, Schnittstellen, Video...)
Was er hier genau macht, müsste man man in dem Startup Bereich der RK29 Sourcen im Kernel nachsehen, ist aber vermutlich nicht unser oberstes Problem. Im originalen Quellcode macht er das auch.

Zum Bootloader:
Der 1st-Stage Bootloader liegt in einem ROM, das ebenfalls im Adressbereich der CPU liegt und ganz normal angesprungen werden kann. Es gibt in vielen CPUs die Möglichkeit diesen per Software unerreichbar zu machen.
Der 2nd-Stage Bootloader liegt, wie der 3rd-Stage im Flash, und ich muss ehrlich sein, ich schütze meine Bootloader auch gegen sich selbst. D.h. ich lasse keine Lese oder Schreibzugriffe darauf zu. Es ist sicherlich Geschmackssache, aber bei meinen Entwicklungen kann die Applikation den Bootloader und der Bootloader die Applikation flashen, bzw. der Bootloader kann garnicht aktualisiert werden. Der Versuch einen Bootloader durch sich selbst zu aktualisieren kann immer durch irgendwen so unterbrochen werden, dass das System garnicht mehr startet. Da reicht ein Reset oder ein Stecker ziehen und Ende.