Das Elektronik-Portal
 

Philips 42PD26907 SMD Mode Blinkcode 53

  • 1
  • 2
  • Seite 2 von 2
HermannS
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 52
Beiträge: 1489
Dabei seit: 10 / 2016
Karma: 45
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 31.03.2019 - 13:47 Uhr  ·  #16
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
Benutzer
Avatar
Geschlecht:
Herkunft: Köln
Beiträge: 131
Dabei seit: 05 / 2012
Karma: 2
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 31.03.2019 - 18:26 Uhr  ·  #17
> 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
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 52
Beiträge: 1489
Dabei seit: 10 / 2016
Karma: 45
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 31.03.2019 - 20:05 Uhr  ·  #18
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
Benutzer
Avatar
Geschlecht:
Herkunft: Köln
Beiträge: 131
Dabei seit: 05 / 2012
Karma: 2
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 05.04.2019 - 20:33 Uhr  ·  #19
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…6bdb4DNccQ

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.

https://www.youtube.com/watch?v=DV5S_ZSdK0s
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 so)

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
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 52
Beiträge: 1489
Dabei seit: 10 / 2016
Karma: 45
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 05.04.2019 - 23:26 Uhr  ·  #20
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.
netter_Mensch
Benutzer
Avatar
Geschlecht:
Herkunft: Köln
Beiträge: 131
Dabei seit: 05 / 2012
Karma: 2
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 14.04.2019 - 20:28 Uhr  ·  #21
so, mal wieder ein Update der Aktivitäten (aber noch kein Erfolg)

das USB-"Sniffing" hab ich noch nicht ausprobiert (Anlass war ja der kurze Zugriff auf den USB-Stick während des hochfahrens bzw. der Boot-Schleife). Ich vermute aber mal, das das eher eine Hardware-Initialisierung der USB-Schnittstelle ist, und kein direkter Zugriff auf Objekte, welche auf dem USB-Stick liegen.
--
Wenn ich das bootlog (direkt beim versuchten Start des Linux Kernel) richtig deute ("... BOOTREASON=update"), wird ein mögliches update vom USB-Stick sowieso erst nach Start des Linux Kernel durchgeführt. Da der Kernel jedoch crasht bzw. nicht startet, kommts gar nicht so weit.
--
Ich hatte versuchsweise auch mal ein nicht partitionierten 4 GB Stick verwendet, "erwartungsgemäß" aufgrund meiner zuvor getroffenen Annahme passiert da halt auch nix anderes wie mit dem partitionierten 8GB Stick.
--
Das Auslesen der Speicher (zumindest des NAND Flash) mittels JTAG interface steht bei mir immer noch aus (als Forschungs-Aufgabe). Das wird zwar elend lange dauern, aber erspart mir das aus- und Einlöten (ich müsste mir dann eh noch einen Brenner organisieren, damit ich die extrahierten Chips auslesen könnte)
--

NFS Boot klappt auch noch nicht. Das Log sagt ja:

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::vec0:off
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

Als Schnittstelle vermute ich weiterhin die Ethernet Schnittstelle. Nachdem ich ein gekreutztes Kabel verwendet habe, habe ich auf Laptop Seite die Ethernet Schnittstelle fix auf 100 mbit full duplex ohne Auto-Negiation "fest geklemmt"
sudo ethtools -s enp9s2 speed 100 duplex full autoneg off
Die Schnittstelle wurde dann auf die vermutete IP-Adresse fest geklemmt
sudo ifconfig enp9s2 172.21.1.1 netmask 255.255.0.0
und Prüfung zeigte mir, das dann auch ein Link vorlag.
ifconfig enp9s2

Irgendwelche NFS-Server hatte ich nicht auf dem Laptop aktiv, nur den wireshark. Es tat sich aber nix auf der genannten IP_Adresse 172.21.1.1
Möglicherweise gibt es irgendwelche zu setzenden "Hardware" bits, oder irgendwelche Steuerbefehle welche per serielle Schnittstelle reinkommen müssten, und die zu nutzende Boot-device zu bestimmen. Meine Annahme, das der SDM Pin aktiv sein muss (ein möglicher Hardware pin) um das zu erzwingen, war leider nicht erfolgreich - ich hab aber da nur eine "Pinzetten" Brücke zu Masse hergestellt, möglicherweise war das zu wackelig).
--
Philips hatte ich auch mal angeschrieben, sie erwähnen ja explizit das man sie kontaktieren soll wegen Opensource etc. Leider wollen sie nix an Sorucen rausrücken "da der Fernseher aus 2012 ist". Ich kann das Argument nicht nachvollziehen. Vielleicht liest ja jemand mit, der schon mal Sourcen erfolgreich angefordert hat, und knan mir diese zur Verfügung stellen.

@Hermann:
Du vermutest ja intensiv, das es sich um ein CPU-Fehler handelt. Ich bin der Meinung, dass (zumindest bei meinem Board) eher ein Flash Problem vorliegt: Der UBoot Loader liegt in einem Bereich, auf dem ausschließlich lesend zugegriffen wird. Der Loader wird anscheinend auch ohne Probleme geladen. Die CPU kann den NAND-Speicher auslesen, und zur Ausführung bringen. Ich schließe somit Decodierfehler (falsche Adresse) und Datenfehler (Datensalat) aus. Die CPU macht anscheinend das was sie kann und soll, und kommt an einer bestimmten Stelle ins straucheln - nämlich dann wenn sie das root-Filesystem mounten will. Das liegt auch auf dem Flash, ist (so meine Deutung) zerquält, und demzufolge crasht der Kernel.

@Hermann: Wie war deine "Methodik" beim duplizieren des NAND: Hattest du mal einen chksum-Test des originalen bzw. des nachgebrannten NAND durchgeführt? Könntest du mir mal das NAND-Image vom QFU2.1 zusenden?
HermannS
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 52
Beiträge: 1489
Dabei seit: 10 / 2016
Karma: 45
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 15.04.2019 - 15:52 Uhr  ·  #22
Der Kasten hat drei nichtflüchtige RAMs: das Boot SPI, das NAND und noch eins für die Einstellungen. Letzteres hat beim frühen Boot noch nichts zu schaffen (Vermutung). Es bleibt also nur das NAND selber oder der dumme Prozessor übrig. Wenn er losrennt, ist das SPI auf jeden Fall ok. Sonst würde er unkontrolliert crashen.

Das Image kann ich mal auf Google Drive legen. Zum Zuschicken ist es zu groß.
Mein NAND Brenner macht nach dem Brennen ein Verify. Also gehe ich davon aus, dass das neue NAND ok war.
HermannS
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 52
Beiträge: 1489
Dabei seit: 10 / 2016
Karma: 45
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 15.04.2019 - 23:29 Uhr  ·  #23
netter_Mensch
Benutzer
Avatar
Geschlecht:
Herkunft: Köln
Beiträge: 131
Dabei seit: 05 / 2012
Karma: 2
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 15.04.2019 - 23:36 Uhr  ·  #24
Hallo Hermann,

Danke für die Datei. da werde ich mal drauf schauen. Ich komme da aber erst am Wochenende dazu, das auseinander zu nehmen.

Was mir schon mal direkt aufgefallen ist:

Ich hätte bei einem 1GB Image eine "bündige" Dateigröße erwartet (0x40000000). Die Datei enthält jedoch 0x43800000 Bytes. seltsam ...

---

Philips hat mir übrigens mittlerweile auch das (ein) Zip-File zur Verfügung gestellt, welches angeblich den vollständigen Source des opensource-Anteil enthalten soll, welcher auf den (meinem) Philips TV drauf ist. Es sind unkomprimiert ca. 1 GB an "Zeugs". Ich versuche mich grade durch den uboot-loader etc. durchzuarbeiten
netter_Mensch
Benutzer
Avatar
Geschlecht:
Herkunft: Köln
Beiträge: 131
Dabei seit: 05 / 2012
Karma: 2
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 22.04.2019 - 18:09 Uhr  ·  #25
mal wieder ein Oster-Update.

Viel getan, nix erreicht bisher.

bei ebay gibt es einen Anbieter, welcher für die QFU2.1 NAND gebrannte Flashes anbietet. Ich habe mir eins besorgt, und gegen das vorhandene ausgetauscht [*1]. Laut Versions-Mitteilung ist es exakt die selbe Version vom U-Boot Loader und einem aufgerufenen U-Boot Script wie das ursprüngliche bei mir verbaute.

Der einzige Unterschied: der UBI-Treiber hat beim neune Flash deutlich weniger "fixable bit-flip" Fehler angezeigt. Auch mit dem neuen Flash kommt alles "soweit hoch", das (wie zuvor) der Linux Kernel anstartet, aber dann den bekannten Kernel Panic erzeugt.

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

Ich sehe ja sogar in den Sourcen, WO das ist: im init\do_mounts.c, Funktionsaufruf von mount_block_root()

--- C:\Install\Philips\TV\QF2EU\310433709901_OpenSourceFile_QF2EU_0.173.53.0\linux kernel v2.6.35.13\src\linux-2.6.35.13.tar\linux-2.6.35.13\linux-2.6.35.13\init\do_mounts.c
-- Zeile 274: panic("VFS: Unable to mount root fs on %s", b);
-- Zeile 286: panic("VFS: Unable to mount root fs on %s", b);

void __init mount_block_root(char *name, int flags)
{
char *fs_names = __getname_gfp(GFP_KERNEL
| __GFP_NOTRACK_FALSE_POSITIVE);
char *p;
#ifdef CONFIG_BLOCK
char b[BDEVNAME_SIZE];
#else
const char *b = name;
#endif

get_fs_names(fs_names);
retry:
for (p = fs_names; *p; p += strlen(p)+1) {
int err = do_mount_root(name, p, flags, root_mount_data);
switch (err) {
case 0:
goto out;
case -EACCES:
flags |= MS_RDONLY;
goto retry;
case -EINVAL:
continue;
}
/*
* Allow the user to distinguish between failed sys_open
* and bad superblock on root device.
* and give them a list of the available devices
*/
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
printk("VFS: Cannot open root device \"%s\" or %s\n",
root_device_name, b);
printk("Please append a correct \"root=\" boot option; here are the available partitions:\n");

printk_all_partitions();
#ifdef CONFIG_DEBUG_BLOCK_EXT_DEVT
printk("DEBUG_BLOCK_EXT_DEVT is enabled, you need to specify "
"explicit textual name for \"root=\" boot option.\n");
#endif
panic("VFS: Unable to mount root fs on %s", b);
}

printk("List of all partitions:\n");
printk_all_partitions();
printk("No filesystem could mount root, tried: ");
for (p = fs_names; *p; p += strlen(p)+1)
printk(" %s", p);
printk("\n");
#ifdef CONFIG_BLOCK
__bdevname(ROOT_DEV, b);
#endif
panic("VFS: Unable to mount root fs on %s", b);
out:
putname(fs_names);
}

#ifdef CONFIG_ROOT_NFS
static int __init mount_nfs_root(void)
{
void *data = nfs_root_data();

create_dev("/dev/root", ROOT_DEV);
if (data &&
do_mount_root("/dev/root", "nfs", root_mountflags, data) == 0)
return 1;
return 0;
}
#endif



mount_block_root() wird aufgerufen von do_mounts_initrd.c in dieser Funktion:

static void __init handle_initrd(void)
{
int error;
int pid;

real_root_dev = new_encode_dev(ROOT_DEV);
create_dev("/dev/root.old", Root_RAM0);
/* mount initrd on rootfs' /root */
mount_block_root("/dev/root.old", root_mountflags & ~MS_RDONLY);
sys_mkdir("/old", 0700);
root_fd = sys_open("/", 0, 0);
old_fd = sys_open("/old", 0, 0);
/* move initrd over / and chdir/chroot in initrd root */
sys_chdir("/root");
sys_mount(".", "/", NULL, MS_MOVE, NULL);
sys_chroot(".");


das heißt doch für mich, dass block-device 249 im RAM liegt: create_dev("/dev/root.old", Root_RAM0);

im root_dev.h sind die einzelnen root devices aufgelistet:

enum {
Root_NFS = MKDEV(UNNAMED_MAJOR, 255),
Root_RAM0 = MKDEV(RAMDISK_MAJOR, 0),
Root_RAM1 = MKDEV(RAMDISK_MAJOR, 1),
Root_FD0 = MKDEV(FLOPPY_MAJOR, 0),
Root_HDA1 = MKDEV(IDE0_MAJOR, 1),
Root_HDA2 = MKDEV(IDE0_MAJOR, 2),
Root_SDA1 = MKDEV(SCSI_DISK0_MAJOR, 1),
Root_SDA2 = MKDEV(SCSI_DISK0_MAJOR, 2),
Root_HDC1 = MKDEV(IDE1_MAJOR, 1),
Root_SR0 = MKDEV(SCSI_CDROM_MAJOR, 0),
};


Leider habe ich es bis jetzt noch nicht egschafft, aus den vorliegenden Infos etc. ein komplettes Mapping aller Speicherkomponenten aufzustellen (auch halt wo RAMDISK_MAJOR liegt)

--> da wird die Theorie, das und der RAM (oder die Erreichbarkeit des RAM) das Problem ist, und durch CPU Reflow gefixt werden könnte, wieder etwas wahrscheinlicher ....

meine nächste Stöber-Ecke wird also brd.c sein ( Ram backed block device driver.)

--

[*1] Der Austausch war ganz old-scool, Ohne Heißluft: einfache temperatur-geregelte Lötstation, neue Spitze rein, 350° Löt-Temperatur, Flux auf die Beine des Flash, gut mit bleihaltigem Zin-Lot vollgemacht. Dann ein bischen hin und her schubbeln, spizte Pinzette unterm Flash, und schwups war das Kerlchen draußen. Dann mit Lötsauglitze alles überflüssige aufgenommen, schon war der Platz wieder aufgeräumt. Der Einbau ging genau so einfach: Flux, Lötzinn, Sauglitze, ...
HermannS
Benutzer
Avatar
Geschlecht:
Herkunft: München
Alter: 52
Beiträge: 1489
Dabei seit: 10 / 2016
Karma: 45
Wissensstand: Bastler mit Reparaturerfahrung
Betreff:

Re: Philips 42PD26907 SMD Mode Blinkcode 53

 · 
Gepostet: 22.04.2019 - 21:43 Uhr  ·  #26
Wild! :happy:
Das Board macht das nicht oft mit, leider, egal wie zart oder "pragmatisch" man das NAND auslötet. Mit großen Lötbatzen fliegt halt gern mal was davon weg und platsch, auf das Vogelfutter ringsherum.

Mein Verdacht, dass die bit flips meistens nichts zur Sache tun, wird wieder etwas größer. In diesen Logs gibt es viele Fährten, die am Ende nichts aussagen.
Gewählte Zitate für Mehrfachzitierung:   0

Tags für dieses Thema

Philips, 42PD26907, SMD, Mode, Blinkcode