42PDL6907 jtag Interface

[Wegstaben V. (wegstabenverbuchsler)]

ich habe hier einen defekten Philips 42PDL6907.

Motherboard ist ein qfu2.1e, als Betriebssystem ist ein Linux am 
Werkeln, welches von einem UBoot Loader geladen wird. Über eine serielle 
Konsole wird jede Menge Protokollzeugs rausgegeben.

Zum Anstart des Linux Kernel bekomme ich einen Kernel Panic (siehe 
unten). Vergleichsweise auch mal eine Ausgabe eines funktionierenden 
Systems

Das NAND Flash hab ich schon ausgetauscht gegen ein neues, es ergibt den 
selben Fehler.

Ich frag mich halt, was da los ist. Nach meinem Verständnis läd ja der 
UBoot Loader seinen SPL in den RAM, also müste dieser da doch 
agenscheinlich in Ordnung sein.

Der Hauptprozessor ist ein Fusion P120. Der Kühlkörper des 
Haupt-Prozessors  war übrigens ab, ich könnte mir vorstellen das da 
BGA-Kontakte "hinüber" sind. der Prozessor ist via JTAG ansteuerbar. Der 
Fusion besteht aus einem MIPS Kernel als Hauptprozessor, und einem ?? 
als Standby-Prozessor

Vor langer Zeit hab ich mir mal mit einem selbst gedengelten "JTAG 
Wiggler" am Parallelport erfolgreich irgendwelche SAT-Receiver Flashes 
ausgelesen. Ich stelle mir sowas auch hier vor, vielleicht sogar einen 
einfachen Speicher-Test des RAM-Speichers des Systems ....


--> meine Frage: Kann ich mir da einen "allgemeinen (USB-) JTAG"  den 
Flash-NAND bzw. des Systems auslesen? Oder MUSS das JTAG zwingend 
irgendwas sein, was MISP "spricht"?



------
## Starting application at 0x80100800 ...
flush cache do_go 82

commandline passed to kernel is =
console=ttyS0,115200n8
mtdparts=NAND:
24m(/boot),
22m(/bootenv),
207m(/systemA),
207m(/systemB),
72m(/rwboot),
468m(/rwdata),
24m(/bbt)
mem=70m@0k
mem=80m@2126m
vecaddr=2m@70m
loglevel=3
lpj=1363968
lockd.nlm_grace_period=1
mm_ra_disable=1
BOOTREASON=coldboot
ubi.mtd=3
secureblock.hook=31:9
root=f900
rootfstype=squashfs
ip=none
ph_debug=none ph_sys=A ph_def=A ph_alt=B

--- kaputter philips:

[    0.319967] Kernel panic - not syncing: VFS: Unable to mount root fs 
on unknown-block(249,0)

--- funktionierender philips:

 address of cmdlineparam = 80f34ba4

starting pid 315, tty '': '/etc/init.d/rcS'

[Mutluit M. (mutluit)]

Kann mit JTAG nicht dienen, aber hier allg. Tips:

Wenn du irgendwie Zugriff auf die root-partition hast, dann mach ein 
fsck darüber, oder leg die Datei /forcefsck auf der root-partition an.

Und wenn er mal richtig bootet dann mach Software-Aktualisierung:
Falls es Debian-/Ubuntu-basiert ist:
apt-get update && apt-get upgrade

Evtl. musst du "update-initramfs" machen --> google

Überprüfe auch die Gerätenamen bzw. UUIDs in /etc/fstab und in der 
u-boot Datei (boot.env oder boot.txt oder so was ähnlich).

Eigentlich ein Fall für die Hotline des Herstellers.

[Wegstaben V. (wegstabenverbuchsler)]

Mutluit M. schrieb:
> Wenn du irgendwie Zugriff auf die root-partition hast,

Bisher hab ich es nicht geschafft, die serielle Konsole für 
Eingabezwecke zu nutzen (nur Ausgabe der Logmeldungen). Ansonsten könnte 
ich vermutlich in der UBoot Konsole irgendwas eingeben. Ich kenne mich 
aber mit dem UBoot und dessen Boot-Prozess nicht aus.

Mutluit M. schrieb:
> Überprüfe auch die Gerätenamen bzw. UUIDs in /etc/fstab

Naja, das Kernel startet ja nicht mal (Fehler im Blockdevice 249, siehe 
oben). Und wie sollte ich sonst auf das Filesystem drauf kommen aussser 
"von innen heraus"?

Mutluit M. schrieb:
> und in der u-boot Datei (boot.env oder boot.txt oder so was ähnlich).

Die Sourcen vom UBoot (für dieses Gerät) liegen mir vor, da muss ich mal 
etwas drin rumstöbern.

Es hat sich aber nichts in der Konfiguration getan. Insofern sind 
Änderungen an diesen Parametern ja vermutlich eher ohne Erfolg...

---

Ich frage mich halt, ob man sich dem Problem softwaretechnisch nähern 
kann, und welche Erkenntnisse ich daraus gewinnen kann.

Eine mögliche Haupt-Ursache des Geräte-Ausfalls: Der Kühler auf dem Chip 
war nur mit einer Art "Teppich-Klebeband" befestigt, und purzelte mir 
beim Öffnen des Gehäuses entgegen. Der Prozessor wird schon im 
Ruhebetrieb (ohne Bild-Verarbeitung) ohne Kühlkörper spürbar warm. Wenn 
dann intensiv Bildverarbeitung ohne Kühlkörper statt findet, werden wohl 
irgendwann zumindest die äußeren BGA-Kontakte des Prozessor-Gehäuses 
gestresst sein.

Der Fusion selbst besteht wohl aus 2 logisch getrennten Prozessoren, ich 
vermute mal die liegen nicht auf einem Die, da könnte also auch noch im 
Gehäuse selbst was hinüber sein.

Reparatur-Versuche der Philips Boards mit Wärmebehandlung (IR-Lampe, 
Heißluft) etc. geistern als Reparatur-Tip im Netz herum, und haben wohl 
auch manchmal zum Erfolg geführt.

[Wegstaben V. (wegstabenverbuchsler)]

Wegstaben V. schrieb:
> Bisher hab ich es nicht geschafft, die serielle Konsole für
> Eingabezwecke zu nutzen

wie sich heraus stellte, war mein pl2303 Adapter auf TX tot (die Leitung 
klemmt auf 0). Ich werde demnächst noch mal dran gehen mit einem 
funktioniererenden pl2303