Philips 42PD26907 SMD Mode Blinkcode 53

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

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

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?

Das NAND Image ist hier: https://drive.google.com/open?…m_JzVvRHn6

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, ...