Odys Loox - Mit Linux / Serielle Schnittstelle

[Astralix]

Ok, das habe ich noch nicht versucht.
Über das Linux-Script kann man den Bootloader ja nicht lesen... Kann man ihn flashen?
Über das Windows-Tool ist das Flashen des Bootloaders ja auf jeden Fall schon mal vorgesehen, aber weder eine Adresse noch eine Datei voreingestellt.

Werde mir das heute Abend mal ansehen

 

[wusel]

Ok, das habe ich noch nicht versucht.
Über das Linux-Script kann man den Bootloader ja nicht lesen... Kann man ihn flashen?
Über das Windows-Tool ist das Flashen des Bootloaders ja auf jeden Fall schon mal vorgesehen, aber weder eine Adresse noch eine Datei voreingestellt.

Werde mir das heute Abend mal ansehen

schau mal ins update-script:

write_loader PACKAGE:bootloader MISC: 0xC000

 

[D@niel]

Stellt sich also nur die Frage, warum Android nicht startet.

Ich habe das System einmal mit einem Standard-Kernel und dann mit einem selbstcompilierten gestartet. Danach dann jeweils das Android system debug log ausgelesen (mit "logcat -d"). Siehe die beiden Textdateien im Anhang. Leider habe ich gerade wenig Zeit und kann sie mir noch nicht genau anschauen. Aber vielleicht entdeckt ja noch jemand etwas interessantes. Evtl. könnte man auch noch einen Blick in "logcat -b events -d" werfen. Das habe ich aber leider vergessen mitzuschneiden...

 

[Astralix]

Hallo Daniel,

Die Android Engine stirbt auf dem eigenen Kernel an mehreren Stellen. Es gibt ein paar Dumps nach einigen Prozessen, dann terminiert sich zygote.

Bei Dir ist der Screen auf jeden Fall noch falsch eingestellt, wie bei mir ist auch das Clock-Setup der CPU noch falsch. Die letzten drei MHz Angaben sind vermutlich für die AHB Busse der Periperie zuständig und die läuft mit dem falschen Timing.
Das sind auf jeden Fall mal noch ein paar Zeilen Sourcecode, die da auf uns warten.

Gruß, Ulrich

 

[D@niel]

Bei Dir ist der Screen auf jeden Fall noch falsch eingestellt

Da hatte sich noch irgendwie alter objectcode bei lcd_AT070TNA2 eingeschmuggelt. Nach einem make clean sieht der Pinguin gut aus. Habe folgendes geändert:

#define OUT_CLK 500000000
#define H_BP 46
#define H_VD 800
#define V_BP 23
#define V_FP 12

Sollte dann vom Timing her ca. 46,9 kHz horizontal und 72,7 Hz vertikal sein, wenn ich da alles richtig interpretiert habe. Ich glaube das ist so halbwegs im Rahmen. Ein Datenblatt in Richtung fsl070.024 habe ich leider nicht gefunden.
Gruß D@niel

 

[Astralix]

Dann müsstest Du jetzt noch mal das Android starten und das log posten für weitere Analysen

 

[D@niel]

Dann müsstest Du jetzt noch mal das Android starten und das log posten für weitere Analysen

Da der Pinguin jetzt sehr gut aussieht, reicht mir das vorerst mal als Indiz für ein korrektes LCD-timing Hat ja leider erst mal keinen weiteren Einfluss auf die anderen Problemstellen...

 

[Astralix]

Darum ging es mir nicht, sondern darum zu sehen, ob jetzt der video-server vom Android nicht wieder in den Boden geht.
Ich habe bei meinem Kernel im grunde auch nur die Boot-Logs abgegrast und so lange die config verändert, bis es weniger und weniger wurden.
Jetzt wollte ich sehen, ob das logcat weniger Fehler meldet.

Es ist aber grundsätzlich so, dass im logcat auf dem selbstbau-kernel viele Verweise auf nicht vorhandene Dateien sind, die auch im recovery nicht gefunden werden. Das deutet eher auf ein Dateisystem-Problem hin und scheint auch eine der Haupursache für die hohe Sterberate von prozessen zu sein.

 

[D@niel]

Darum ging es mir nicht, sondern darum zu sehen, ob jetzt der video-server vom Android nicht wieder in den Boden geht.

O.K. - siehe Anhang

 

[Astralix]

Naja, wir haben noch Arbeit vor uns:

I/sysproc (  150): System server: starting Android runtime.
I/sysproc (  150): System server: starting Android services.
I/SystemServer(  150): Entered the Android system server!
D/SensorService(  150): nuSensorService thread starting...
I/sysproc (  150): System server: entering thread pool.
I/SystemServer(  150): Entropy Service
I/SystemServer(  150): Power Manager
I/SystemServer(  150): Activity Manager
I/ActivityManager(  150): Memory class: 48
I/DEBUG   (  144): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  144): Build fingerprint: 'rockchip/rk29sdk/rk29sdk:2.3.1/GINGERBREAD/eng.root.20111202.165559:user/test-keys'
I/DEBUG   (  144): pid: 150, tid: 157  >>> system_server <<<
I/DEBUG   (  144): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000004
I/DEBUG   (  144):  r0 00000000  r1 001f0ec0  r2 8490124d  r3 00000000

SIGSEGV heisst SegmentationFault, da greift also irgend eine Funktion ins Leere, also auf eine Adresse zu, die sie entweder nicht addressieren darf, oder die es garnicht gibt.

Zwischendurch gibt es immer wieder mal Audgaben, die verstümmelt sind:

D/        (  160): Vivante Driver Version : K8ä - U2.2.2_for1.28!

was es im originalen kernel-log nicht gibt. Also sind immer noch interne Clocks des RK29 nicht korrekt.

 

[D@niel]

Nochmal kurz zum Thema Bootloader und Flash:

Ich habe über die SD-Card ein update.img eingespielt und auf der Konsole mitgeschnitten. Der neue bootloader wird anscheinend erst einmal zwischengeparkt:

[ 68.916982] [write_loader]: src=PACKAGE:bootloader dest=MISC: offset=49152

... und dann nach einem reset über den Befehl update-bootloader über die misc geflasht:

bootloader cmd: update-bootloader

Details im Anhang

 

[Oma7144]

bootloader cmd: update-bootloader

OK, holt den Befehl zum Formatieren von /data aus misc, lädt dann den 2nd Bootloader und überschreibt dann misc.

Die Adressen da unten: wo schreibt er denn dann hin auf dem NAND?

get command in misc
execute command
##########################
GetRemapTbl flag = 1
bootloader cmd: update-bootloader
--- update bootloader ---
>>> ENTER update loader
get loader
SecPerBlock=1024
create flash block map
Search all id block...
ID BLOCK:
0
1
2
3
4
generic id block
DDDDD...
OK
update loader data
update date and version
EEEEE...
OK
write id block
Enter write idb
Erase block 0
Set Loader flag is 1888aaff
write IDB0 to SEC0
write sector 00000000 ~ 00000019
read sector 00000000 ~ 00000019
check data...
Okay!
write sector 00000020 ~ 00000039
read sector 00000020 ~ 00000039
write sector 00004276 ~ 00004283
read sector 00004276 ~ 00004283
check data...
Okay!
IDB[4] write complete
>>> LEVEL update(0)
##############################
Clear misc okay!
reboot
Set Loader flag is 0

 

[D@niel]

Die Adressen da unten: wo schreibt er denn dann hin auf dem NAND?

Auf jeden Fall nicht im "normalen" NAND-Flash-Bereich, auf den man einfach so Zugriff hat. Denn ich habe in einer kompletten Flash-Sicherung nach einem Daten-Stück gesucht (3C6D1ECA41C0B0B8), welches ich sowohl in der Datei RK29xxLoader(L)_DDR3_400Mhz_V1.64.bin als auch in der misc-Partition (kurz vor dem Bootloader-Update rausgezogen) gefunden habe. Das einzigste Auftreten war kurz nach Beginn der backup-Partition, was dann vermutlich auch wirklich nur "backup" ist. Höchstens einen Fall würde man so nicht erkennen: Wenn die beim bootloader flashen noch irgend etwas mit den Daten machen (Entkomprimieren, Metadaten rauswerfen o.ä.). Ich frage mich da auch gerade etwas, welchen stage wir da gerade haben. Ich finde zum Beispiel nichts was nach dem bootloader, welchen man auf der seriellen Schnittstelle sieht, aussieht (habe z.B. mal nach "get command in misc") gesucht. Oder es ist irgendwie verschleiert / komprimiert

 

[Oma7144]

Oder es ist irgendwie verschleiert / komprimiert

Ja, es besteht die Möglichkeit, das der Bootloader vom Hersteller verschlüsselt wurde. Wäre ja ein Versuch, sein System zu schützen ...

 

[Astralix]

Also wenn die CortexA Architektur so arbeitet, wie die CortexM, dann müssten die ersten beiden Words des Binärfiles aus dem Stackpointer und dem Reset-Vector bestehen.
Und das müsste man an den Inhalten der beiden Words fest machen können, denn der Stackpointer muss im RAM liegen und es kann zu diesem zeitpunkt nur das OnChip RAM (16k) sein. Der ResetVector müsste auch im RAM liegen, denn der 1stStage lädt diesen Bootloader vermutlich auch ins RAM, kann aber auch sein, dass sie im FLASH liegt und er ihn direkt von da aus ausführt.

Leider haben wir kein wirklich vollständiges Datenblatt, sondern eher so einen Appetit-Macher. Vielleicht findet ja noch jemand das vollständige. Es werden vermutlich eher 2..3 Datenblätter sein, Die CortexA8 Architektur mit Memorymanagement, das Peripherie-Datenblatt und vielleicht auch eines über die GPU.

 

[wusel]

Nochmal kurz zum Thema Bootloader und Flash:

Ich habe über die SD-Card ein update.img eingespielt und auf der Konsole mitgeschnitten. Der neue bootloader wird anscheinend erst einmal zwischengeparkt:

[ 68.916982] [write_loader]: src=PACKAGE:bootloader dest=MISC: offset=49152

... und dann nach einem reset über den Befehl update-bootloader über die misc geflasht:

bootloader cmd: update-bootloader

Details im Anhang

diese Commands stehen im update-script:

# дÈëÃüÁÔÚbootloaderÆô¶¯Ê±Éý¼¶bootloader
write_blcmd update-bootloader

# ½«bootloader´æ·Åµ½MISC·ÖÇø
write_loader PACKAGE:bootloader MISC: 0xC000

 

[D@niel]

write_loader PACKAGE:bootloader MISC: 0xC000

...und der "offset=49152" entspricht genau dem 0xC000. Das ist das Byte-Offset innerhalb dem "misc"-Flash-Bereich, ab dem das image dann temporär für den nächsten Update-Schritt geschrieben wird.

Falls Interesse besteht kann ich gerne den Stand von misc in diesem Zwischenschritt zur Verfügung stellen. Vielleicht haben wir hier ja einen Disassemblierfreak der sich den Maschinencode des loaders anschauen möchte

 

[Astralix]

Dann muss ich wohl mal schauen, ob mein Disassembler mit Cortex auch schon klar kommt. Bislang habe ich den immer nur auf ARM angesetzt...

Nützt aber nicht sehr viel, wenn man das Datenblatt zum Chip nicht hat und damit nicht erkennen kann, was ein Register tut, wenn man da hinein schreibt. Wird also etwas mühsam aus den Kernel-Quellen die Register und deren Bit-Belegung heraus zu dröseln. Zumal die Adressen der Register zum Grosssteil auch noch von Linux abweichen kann, da sie womöglich per MMU auf eine andere Basisadresse gemappt werden...

 

[D@niel]

Dann muss ich wohl mal schauen, ob mein Disassembler mit Cortex auch schon klar kommt. [...] Nützt aber nicht sehr viel, wenn man das Datenblatt zum Chip nicht hat und damit nicht erkennen kann, was ein Register tut, wenn man da hinein schreibt.

Da hast Du Recht. Aber für den Fall, dass Du zumindest mal schauen möchtest ob der Dissassembler was damit anfangen kann bzw. oder ob sich überhaupt um "rohen" Maschinencode handeln kann, hänge ich den misc-dump an. Ich vermute ab 0xC200 wird es interessant.
Gruß D@niel

 

[wusel]

Falls es Euch für Experimente interessiert: ich habe 2 neuere Bootloader in anderen RK29XX Tablet Updates gefunden:
Index of /odys-tablets/playground