Philips 42PD26907 SMD Mode Blinkcode 53

[netter_Mensch]

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

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]

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]

Das NAND Image ist hier: https://drive.google.com/open?id=1FC42Om5wpCSlt4k_Cp9umEm_JzVvRHn6

 

[netter_Mensch]

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]

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]

Wild!
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.