Philips 42PD26907 SMD Mode Blinkcode 53

[netter_Mensch]

Hersteller: Philips

Typenbezeichnung: 42PD26907

Inverter:

Chassi: QFU2.1E LA

kurze Fehlerbeschreibung (2-3 Worte): SMD Mode Blinkcode 53

Meine Messgeräte::
kein Messgerät

Schaltbild vorhanden?:
Ja, als PDF



Ich habe hier einen defekten Philips 42PD26907 (Motherboard QFU2.1E LA). Servicemanual liegt vor.

Beim Öffnen purzelte mir der Keramik-Kühlkörper des Fusion Chip entgegen, er hatte sich vom Chip gelöst. Nachdem ich diesem mit Wärmeleitkleber wieder befestigt hatte, konnte ich den Fernseher in den "analogen" SDM Modus bringen und ein Blinkcode 53 entlocken.

Error 53. This error will indicate that the Fusion device has
read his bootscript (when this would have failed, error 15
would blink) but initialization was never completed because
of hardware problems (NAND flash, DDR...) or software
initialization problems. Possible cause could be that there
is no valid software loaded (try to upgrade to the latest main
software version)

Ein Hyperterm (Serielle Kommunikation) habe ich noch nicht angeschlossen. Meine Hoffnung ist der Hinweis in der Beschreibung zum Error 53, das ein Software Update helfen könnte.

--> wo bekomme ich eine passende Software her? Könnte mich jemand erhellen oder kontaktieren?

 

[HermannS]

CPU wird einen Reflow brauchen. Die meisten dieser Fälle hören im Log einfach mit dem Buchstaben K auf, kurz bevor das Booten vom NAND dran wäre.

Das Gerät heißt wohl eher 42PFL6907?

 

[netter_Mensch]

du hast Recht. Ich weiß auch nicht woher ich die andere Bezeichnung hatte, vielleicht vom Servicemanual abgeguckt.

Da wird es also doch mal Zeit, erst mal die V24 Schnittstelle in Betrieb zu nehmen. Irgend so ein PL2303 basierendenes USB Stöpselchen hab ich noch hier rumliegen, damit hatte ich mich schon mal gegen irgendwas anderes verbunden. Sollte also gehen.

Ich hoffe ja immer noch insgeheim, das irgendwo ein Image auftaucht, was man da reinflashen kann, und "alles wird gut" danach.

 

[HermannS]

Diese Hoffnung würde ich besser gleich begraben. Ich habe inzwischen etwa ein Dutzend QFU Mainboards in den Fingern gehabt. 90% ist CPU.
Ich kann dir beim Reflow helfen, falls gewünscht.

 

[netter_Mensch]

Philips 42PDL6907K/12 SDM Mode Blinkcode 53

Hallo Hermann,

danke, das ist ein nettes Angebot. Ich selber habe leider kein notwendiges high-End Equipment (bis auf eine Heißluft-Station). Wenn das erfolgversprechend ist - warum nicht?

Aus Neugier: Welche Komponente "löst" sich den "am liebsten" bei dem Board? eher die CPU? oder eher der Flash-Speicher?

Wenn ich es richtig gelesen habe, ist ja der Standby Prozessor Teil des Fusion Chips. Der Startup scheint ja zu gehen, sonst käme ja kein Blinkcode aus der Kiste raus. Kennst du da technische Details?

Ich habe halt vermutet, das die 10% (nicht-Reflowen) Rest-Schaden sich auf einen zerstrubbelten Flash-Inhalt zurückführen lässt. Da scheint mir ein erster Versuch mit einem neu-Flashen halt weniger aufwändig als die Platine "nachzulöten".

Ich hab jetzt noch mal nachgesehen wegen der Typenbezeichnung.
42PDL6907K/12
TFT-LCD LC420EUF-DEP(LGPH)B

Kennst du den Namen der neuesten (oder einer älteren) Firmware-Datei für den Philips mit dem Mainboard?

die Support-Seite von Philips beite da (knappe) Infos an
https://www.philips.de/c-p/42PDL690...-mit-ambilight-spectra-2-und-pixel-precise-hd

diese Webseite ist hingegen deutlich informativer:
https://toengel.net/philipsblog/firmware-archiv/

 

[HermannS]

Tatsächlich PDL. Die Innereien sind sicher identisch mit einem PFL. Die QFU2.1 Chassis haben alle die gleiche Software. Du bringst die Software aber nie auf das Board, wenn er sich nicht per Infrarot-Fernbedienung (nicht die Original-FB, die ist Funk) und mit dem OK-Tastentrick starten lässt.

Das Boot-SPI kann mal kaputt gehen, dann ist der Kasten aber komplett tot und blinkt nicht. Einen NAND Fehler hatte ich bisher nur einmal. Ob es das NAND ist, wirst du im Log sehen.

Ohne Log auslesen hast du keinen Ansatzpunkt. Das muss einfach sein bei den QFUs.

Die CPU ist wie gesagt in den meisten Fällen Schuld. Mit simpler Heißluft wird das nix. Ich habe grad vorher wieder so ein "K"-Fehler Board mit meiner BGA Station zum Leben erweckt.

 

[netter_Mensch]

Hallo Hermann,

danke für deine Unterstützung!

was ich noch beobachtet hatte (nachdem ich eine autorun.upg (Version_000.150.102.000) ins Wurzelverzeichnis eines USB-Stick drauf gebracht habe): Ab und an blinkt die LED am Stick kurz auf (Zugriffs-Signalisierung). Also irgendwer versucht irgendwas vom Stick abzugreifen - kann es sein das (so wird es im ServiceManual beschrieben) die Standby-Software versucht sich aufzuhübschen?

Ich komme wohl doch nicht umhin, am Wochenende mal das Teil seriell anzuzapfen.

 

[HermannS]

Interessant, dann scheint deiner ein Stück weit zu booten bzw. die Versorgungsspannungen auf dem Main springen an.

 

[netter_Mensch]

> deiner ein Stück weit zu booten bzw. die Versorgungsspannungen auf dem Main springen an

ja, das konnnte ich tatsächlich beobachten.

Beim ersten Antest (mit "abben" Kühlkörper, und Kältespray in der Nähe) konnte ich folgendes Verhalten beobachten:

nach ca. 3 Sekunden wurden die 12V vom/durch das Mainboard aktiviert. Nach ca. 25 Sekunden Bestromung wurde dem Fusion Chip zu warm (es war noch deutlich unter "verbrannte Finger" Temperatur), udn es wurde wieder ausgeschaltet. Nach weiteren 20 Sekunden war der Chip genügend abgekühlt, um die 12V wieder einzuschalten.

In der gegebenen Zeit hat es aber noch nicht gereicht, den "analogen" SDM Modus (Testpin an Masse) aufzubauen. Ich mag auch ungern solche Chips ohne Kühlung betreiben, selbst wenn die da ein Temperatur-Management drauf oder bei haben.

Nachdem ich dann den Kühlkörper wieder montiert hatte, klappte es mit der Temperatur (besser: mit der Wärmeabfuhr)
Ich kam dann auch in den SDM, und ein fröhliches "53" blinkte mich an.

Jetzt frag ich mich, was denn nun der Standbyprozessor (oder ist es schon die Haupt-Routine?) so auf dem USB-Stick sucht.

ich les da was im Service Manual von Backup IMage, oder neues Image, und Fernbedienung ok, runter usw.
Ich muss halt mal dringend nach seriell connecten, und schauen was mir die Kiste so mitteilen möchte.

 

[HermannS]

Ich wette auf den "K" Fehler Da wird die CPU auch warm und looped. Kommt halt leider nirgendwo hin.

 

[netter_Mensch]

so, das hat was gedauert, bis ich mal wieder Lust hatte an dem Philips rumzuspielen.

Er spricht zu mir!

setting:
Linux Laptop, CuteCom Software, PL2303 USB-Adapter, Kabel aus altem Kopfhörer zusammen gebastelt [*1]. 115200-8N1.

[*1] Danke, Hermann, für deinen wundervolle Beschreibung zum Kabel.

Schon seh ich was.. Das was ich sehe sieht mir aber aus wie ein zerstrubbeltes NAND Flash.

eine Firmware Version 000.150.102.000 habe ich mir runter gezogen, autorun.upg ins Stammverzeichnis eines USB-Sticks rein, Cursor down auf einer IR Philips Tastatur, aber das scheint nicht auszureichen oder der falsche Ablauf zu sein oder die falsche Datei (oder irgendwas anderes klemmt)

--> Wer hat einen Tip für mich?


mal schauen, was der U-bbot-loader so im detail macht, und wo er stolpert. Vielleicht mag er ja ein Bootimage vom USB-Stick lesen (wenn ich nur wüsste, welches Dateisystem er erwartet, und welchen Dateinamen...)

hier gehts sehr ins Eingemachte von "fixable bit-flip error". Da muss ich mich auch mal durchbeißen ...
https://www.spinics.net/lists/linux-mtd/msg01183.html


Die komplette Logdatei hab ich auch noch mal als Anhang beigefügt.
----------------
...
load end!
KKG0G1DDDDDDDDDDDDDDsecure
Load uboot


U-Boot 2009.01_Production-svn16462 (Sep 25 2012 - 18:33:16)

UªU
NAND: NAND, size:1024MB, Micron(ID:0x2c,0x3, block size:512KB
1024 MiB
Env: NAND @ 0x01800000
bootcmd1
BOOTREASON=coldboot
APP CPU==>1GHz
Found: /boot
Found: /bootenv
Found: /systemA
Found: /systemB
Found: /rwboot
Found: /rwdata
Found: /bbt
Found 7 partitions
Creating 1 MTD partitions on "NAND 1GMiB 3,3V 8-bit":
0x02e00000-0x0fd00000 : "mtd=2"
UBI: attaching mtd0 to ubi0
UBI: physical eraseblock size: 524288 bytes (512 KiB)
UBI: logical eraseblock size: 516096 bytes
UBI: smallest flash I/O unit: 4096
UBI: VID header offset: 4096 (aligned 4096)
UBI: data offset: 8192
UBI: fixable bit-flip detected at PEB 80
UBI: fixable bit-flip detected at PEB 101
UBI: fixable bit-flip detected at PEB 126
UBI: fixable bit-flip detected at PEB 145
UBI: fixable bit-flip detected at PEB 173
UBI: fixable bit-flip detected at PEB 208
UBI: fixable bit-flip detected at PEB 213
UBI: fixable bit-flip detected at PEB 253
UBI: fixable bit-flip detected at PEB 256
UBI: fixable bit-flip detected at PEB 299
UBI: fixable bit-flip detected at PEB 301
UBI: fixable bit-flip detected at PEB 303
UBI: fixable bit-flip detected at PEB 304
UBI: fixable bit-flip detected at PEB 411
UBI warning: ubi_eba_init_scan: cannot reserve enough PEBs for bad PEB handling, reserved 4, need 40
....
...

UBI: fixable bit-flip detected at PEB 143
UBI: schedule PEB 143 for scrubbing
suceeds
commandline passed to kernel is = mem=40m@72m mem=354m@2206m vecaddr=2m@70m loglevel=3 lpj=1949696 ipcfg_preopen_dly=0 ipcfg_postopen_dly=0 BOOTREASON=coldboot ip=172.21.1.2::172.21.1.1:255.255.0.0::vec0ff root=/dev/nfs rw nfsroot=172.21.1.1,udp,rsize=32768,wsize=32768,timeo=600,retrans=2,nfsvers=3 ph_debug=none ph_sys=A ph_def=A ph_alt=B
## 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
address of cmdlineparam = 80f34ba4
[ 0.320178] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(249,0)

-----------

 

[HermannS]

Bravo, deiner schafft das K

Diesen Fehler habe ich auch schon mal gesehen. Ein Auswechseln des NAND hat allerdings nichts geholfen. Ich hatte das NAND rausgeholt und ausgelesen. Es hat sich nicht dagegen gewehrt, also sollte es ok gewesen sein. Ein anderes NAND mit anderem Image hat dann dazu geführt, dass gar kein Log mehr kam. Das ist etwas, was mich vor ein totales Rätsel stellt weil schon mehr als einmal passiert.

In Linux-Kreisen, die nichts mit Philips zu tun haben, war die Rede davon, dass eine Partition voll gelaufen sein könnte, z.B. das /tmp. Das hilft mir leider nicht, weil ich das Image des NAND nicht aufräumen kann.

Meine Schlussfolgerung: Es war wieder die CPU schuld und das ist nur eine von vielen Aromen, mit der sie uns Fehler präsentiert. Nach einem Reflow war die Kiste leider ganz tot.

Die fixable bit flips seh ich auch öfters und ich konnte mir bisher keinen Reim drauf machen, ob das nun schlimm ist oder nicht.

 

[netter_Mensch]

Hermann, kannst du mir ein paar Namen von Bootimages nennen? Oder frisst der Philips alles, was sich auf einem FAT32 formatierten USB-Stick im Wurzelverzeichnis befindet und <irgendwas>.upg heisst?

Hast du schon mal mit der seriellen (V24) Konsole rumgespielt, d.h. mehr als nur Log-Ausgabe abgegriffen?
Hat/kann die serielle Verbindung überhaupt "input", oder muss eine Konsole über eine Sitzung via Ethernet Anschluss erfolgen?

Ich bekomme da momentan (via ser. Konsole) kein einziges U-Boot Kommando rein in den Philips

 

[HermannS]

Den Stick frisst er in diesem Zustand gar nicht. Da brauchst du ein Binary Image vom NAND und einen Brenner. Ich habe nur das UART Log gelesen bisher. Eine Shell haben bei den Dingern glaub ich noch nicht einmal die Russen aufgemacht

Ich hab die QFU wieder aufgegeben. Ich kenne jetzt drei Maßnahmen (SPI erneuern, NAND erneuern, CPU Reflow), die ich durchführen kann. Unmengen an Zeit sind in die Mistkisten schon reingeflossen. Mir reicht's

 

[netter_Mensch]

Hallo Hermann, hättest du denn für das QFU2.1E ein funktionsfähiges Image (und eine neues NAND), und könntest du es auf mein Board drauf bringen?



Ich sehe noch 3 Optionen, welche ich mir ansehen möchte:

1. U-Boot Konsole
beim Hochfahren könnte möglicherweise die U-Boot Konsole erreicht werden, wenn man zum passenden Zeitpunkt 'ESC' drückt. Vielleicht läst sich da was machen, sobald man in der Kosole ist.

2. nfs-boot
der Bootlog zeigt, das als erstes ein nfs-Boot von 172.21.1.1 versucht wird. Da werde ich mal einen Netzwerk Sniffer dranhalten, und schauen was er denn da so anfragt und erwartet.

3. Elkos?
Ich werde mal den Ripple an den Elkos messen, speziell die in der Nähe des NAND. Elkos gehen immer mal gerne kaput, mit spooky errors

 

[HermannS]

Ich hatte bis jetzt nie Erfolg mit NANDs, die mit einem fremden Image beschrieben waren. Letztlich waren es doch immer die CPUs. Weiß nicht auswendig, ob ich ein QFU2.1 Image habe. Schau ich später im Laborrechner nach. Jetzt geh ich erst mal Radfahren

 

[netter_Mensch]

> Ich hatte bis jetzt nie Erfolg mit NANDs, die mit einem fremden Image beschrieben waren.

Worin bestand der Misserfolg (was passierte) ?

Und was ist mit "eigenem" Image?

Ich vermute mal, dass das NAND "ausgenudelt" ist, und nicht (mehr) beschreibbar ist. Spekulativ kann das ja fast nur ein "falsch" konfigurierter Linux-Kernel sein, welcher zu häufig schreibende Zugriffe auf das NAND macht, bis dies schliesslich "durch" ist.

--> Wie ist es denn mit dem Auslesen eines scheinbar defekten NAND, und dann wieder zurück auf die Platine? Oder gar aus einer laufenden Platine das NAND duplizieren, und wieder auf die selbe Platine zurück bringen?

Dann sollte man ja feststellen können, ob der eigendliche Schreibvorgang (auf das neue NAND) erfolgreich war ...

 

[HermannS]

Interessante Diskussion. Immer gut wenn jemand mit frischen Ideen reinkommt.

Ich habe ein Image von einem 55PFL6007. Das ist qfu2.1.
Bei meinen NAND-Tauschs ging danach gar nichts mehr. Kein Log. Das verstehe ich bis heute nicht. Altes NAND wieder rein - log wie vorher. Ich weiß nicht, ob meine NANDs 100% kompatibel sind. Mein Brenner beschwert sich nicht, also gehe ich davon aus.

Beim letzten Fall bin ich von einer vollgelaufenen Partition ausgegangen. Also sah ich keinen Sinn darin, das originale Image in ein neues NAND zu verpflanzen. Das originale NAND ließ sich auch ohne Probleme auslesen. Das sah mir nicht kaputt aus. Es wir eben wieder die CPU dran schuld gewesen sein, wie praktisch immer. Das Erhitzen auf der Unterseite (bei QFU1.2), ganz in der Nähe der CPU scheint manchmal auch einen Effekt zu haben. Mir ist mal ein Board tot gegangen durch NAND-Zweifachtausch (alt raus, neu rein & raus, alt rein). Das ergibt keinen Sinn, es sei denn die CPU spinnt.

Das Problem ist auch, dass das Board nur eine begrenzte Anzahl von Versuchen zulässt, bevor die Leiterbahnen anfangen, sich abzulösen. Selbst bei schonender Behandlung mit Heißluft. Mit dem Lötkolben geht es sehr schnell kaputt. Ich stelle da sogar meinen Perfektionismus hinten an und lasse leicht schief sitzende NANDs zu, damit das Board geschont wird.

 

[netter_Mensch]

So, ich habe mittlerweile mal weider mit dem Philips rumgespielt. Ich bin der Lösung aber noch nicht näher gekommen. Was ich bisher ermittelt habe, ist:

Elkos:
am NAND Flash 7JA0 messe ich sehr regelmäßigen 40 mV Ripple mit 2.8 µs Dauer. Das sieht aus wie eine einbrechende Spannung.
--> Da werde ich noch mal einen Elko-Tausch machen.

An den Elkos der beiden RAM Bänke (7J01/7J02 und 7J03/7J04) sind "zappelige" 20mV Ripple zu messen, ohne Muster.
--> die werde ich erstmal ignorieren, bis ich den Elko am NAND Flash getauscht habe.

NAND-Flash:
EIn neues leeres MT29F8G08 gibts beim Chinesen für ca. 3 EUR:
https://de.aliexpress.com/item/MT29...l?spm=a2g0x.10010108.1000016.1.2c7e6bdb4DNccQ

Ein volles NAND Flash habe ich bei ebay für ca. 30 EUR entdeckt:
eBay-Artikelnummer: 273735093843

Vielleicht ist das NAND Flash ja wirklich taub und zerquält, und muss ersetzt werden.
@Hermann, hattest du als "neues" für deinen Versuch ein exakt typgleiches NAND verwendet (gleiche Kennung) ?

@Hermann, Deine Theorie einer voll laufenden Partition ... kann ich mir nicht ganz vorstellen. Ich gehe davon aus, das das ein Linux Cold boot ist, und da nichts auf Partitionen zurück geschrieben wird.

--> Das wäre ein möglicher Kandidat: erst mal 3 EUR in ein Flash investieren, und 1:1 das bestehende Flash-Image übertragen. Ansonsten das volle Flash einbauen.



Ethernet:
Ziel war es ja, ein NFS-Boot hin zu bekommen via LAN. So habe ich zumindest die Log-Meldung gedeutet.
Neben dem Philips war hier noch ein Toshiba Satellite L100, und ein dLAN 550 Powerlineadapter (mit 2 Ethernet-Ports) im Einsatz.
den Laptop habe ich auf 172.21.1.1/255.255.0.0 konfiguriert, und dort den WireShark laufen lassen.

1. Versuch: Laptop 1:1 an Philips
2. Versuch: Laptop und Philips mit zwischengeschalteten dLAN Adapter (jeweils mit 1:1 Kabeln verbunden)

Beide male konnte ich via WireShark nix auffangen auf dem Ethernet Interface.

Laut Datenblatt "kann" der im Philips verbaute Qualcomm AR8030 10/100 MBit , Auto-Negotiate. Ich nehme an, das bezieht sich auf Halb- und Full-Duplex auf den beiden Geschwindigkeiten, aber nicht zwingend auf ein Auto-RX-TX-swap. Ob die anderen Komponenten (Laptop bzw. dLAN) jeweils auto-RX-TX-Swap können (insbesondere der dLAN 550 Adapter, und dann auf den beiden Ports unterschiedlich) , hab ich nicht weiter recherchiert. Ich kenne LAN-Installationen, wo das ganze auto-Gedöns sich gegenseitig blockiert hat.

--> da scheint mir ein "je fester, desto besser" (also z.B. 100 MBIT full-duplex) eine mögliche noch nicht ausprobierte Option zu sein. Zumindest dann auch mal ein gekreuztes Direkt-Kabel zwischen Laptop und Philips. Ich muss mir mal mein gekreuztes Kabel aus dem Keller rauskramen.

Bootvorgang, Bootreason
der Bootvorgang selber dauert ja ca. 8 Sekunden (bis der Kernel Panic kommt), danach ca. 20 Sekunden Pause, und dann gehts wieder von vorne los. Das dürfte der "first stage bootloader" (=secondary programm loader, SPL) sein, der loopt.

Hier ist der Bootvorgang ganz nett beschrieben. Bezieht sich zwar auf ein BeagleBone Board, aber der Vorgang ist im wesentlichen immer identisch bei derartigen embedded Systemen (wie z.B. auch der Philips)

Wenn man ?irgendwann? die OK oder down oder right Taste an der Fernbedienung drückt, kommt bei der Abschlussmeldung (Übergabeparameter ins Kernel) im Log die Meldung bootreason=upgrade anstelle bootreason=coldboot. der SPL oder U-Boot wird wohl derjenige sein, welcher das

USB-Stick
FAT-32 formatiert (so soll es wohl laut Servicemanual), und autorun.upg im Root.

Leider wurde nichts vom Stick geladen.

Vielleicht ist der STick ja zu groß für den alten Philips: Der Stick hat brutto 8GB, und die Fat32 Partition 1.4 GB.

--> Da werde ich mal was kleineres nehmen (256 MB oder s

USB-Buchse
Beim Start des Bootvorgangs (einer jeden Boot-Loop) sehe ich kurz die LED am USB Stick aufblitzen. Ob das Initialisierung des SPL ist, oder tatsächlich ein (Lese) Zugriff des SPL oder vom U-Boot auf den Stick, habe ich noch nicht rausbekommen.

--> Ich habe irgendwo so ein "aktives" Kabel USB-> USB, das 2 Rechner koppeln kann, vielleicht kann ich das ja mit Wireshark sniffen.
--> Hat jemand sonst noch eine Idee, wie ich den USB-Port am Philips sniffen kann?

soweit das was ich bisher ermittelt habe, jetzt hab ich erst mal wieder ein paar Sachen die ich prüfen bzw. ausschließen kann/möchte

 

[HermannS]

Cool, dass du dich von der Softwareseite bzw. digitalen Ebene her näherst!
Mein Update Stick hat 4GB. Ob 8 auch funktionieren, kann ich mal ausprobieren - ich denke aber schon. Ein Philips läuft ja noch, neben den drei Leichen. Dass partitionierte Sticks laufen, glaub ich allerdings nicht!

40mV in der digitalen, quarzgetakteten Domäne sind aus meiner Sicht keine Katastrophe. Da misst man allen möglichen Schrott mit, weil die Masse selber auch nicht sauber ist. Eine saubere Spannung gibt es da nirgends. 2.8µS sind 357kHz. Das ist die Hälfte von den 700kHz des TPS54426 buck converter, der für die 3.3V zuständig ist. Zufall? Es gibt noch einen zweiten converter, den RT8293. Der rattert sogar mit 1.2MHz dahin. Welcher davon das NAND füttert, habe ich in erträglicher Zeit nicht rausgefunden.

Mein NAND habe ich auch aus China und der Typ entspricht exakt dem Original. Ich glaube auch nicht wirklich, dass es damit zusammenhängt.
Der "K"-Fehler hat was mit der CPU zu tun.