Ich habe meinem Sohn einen gebrauchten Fantec 3DS4600 Mediaplayer
geschenkt. Er steht total auf Retro-Zeugs und will den nutzen um alte,
digitalisierte VHS-Kassetten über einen Röhrenfernseher anzuschauen.
Leider zeigt das Teil, obwohl es pfuschneu daher kam, beim Anschluß der
Betriebsspannung nur das "Fantec" Logo auf dem Fernseher (FBAS wie HDMI
out).
Nach einigem Rätselraten habe ich dann mal im Netz gesucht und es gibt
hier und da einen Hinweis das dies wohl ein bekanntes Problem sei. Ggf.
muss man nur die Firmware neu aufspielen, evtl. ist aber auch der
interne Flash-Speicher kaputt.
Habe das Teil dann gleich mal geöffnet um nachzusehen ob da schonmal
jemand dran war, sieht aber nicht so aus. Dann habe ich den Kühlkörper
der CPU entlötet, so kommt man an den Flash-Speicher ran. Würde mal
versuchen dafür Ersatz zu finden, ist ein Hynix H27UBG8T2BTR-BC (32 GBIT
NAND). Leider schwer zu bekommen, möglicherweise gibt es aber
kompatiblen Ersatz dafür?
Ich hätte einen Flash-Reader, aber eleganter wäre es wohl per JTAG o.ä.
drauf zuzugreifen. Auf dem Board sehe ich aber keine der üblichen
Schnittstellen, nur eine unbestückte SPI (vermutlich).
Auch finde ich auf der www.fantec.de nicht mal mehr das Produkt im
Archiv, geschweige denn eine Firmware zum Download dafür.
Vielleicht habe ich ja Glück und es gibt hier im Forum jemand der sowas
zur Hand hat?
Möglicherweise liegt das Problem aber auch noch woanders. Da ist ja auch
noch ein EEPROM drauf...
Bin für jeden Tipp dankbar der mir hilft das Teil wieder an laufen zu
bekommen! :-)
So, die aktuellste Firmware konnte ich dank eines hilfsbereiten Menschen
auf ebay-kleinanzeigen inzwischen herunterladen. Fantec hat die selbst
nicht mehr und ihn auf einen Downloadlink auf einem Mediafire Server
verwiesen. Das Archiv ist 550MB groß, die Firmware selbst darin
("install.img") jedoch nur 200MB. Das IMG-File ist innen drin ein TAR
(genau gesagt ein USTAR Format) und lässt sich z.B. mit 7zip problemlos
auspacken.
In dem Archiv ist auch der Quellcode der genutzten OpenSource
Komponenten enthalten, ebenfalls als USTAR.
Laut Anleitung legt man das install.img auf einen USB-Stick, steckt
diesen ins Gerät, drückt den Einschaltknopf und hält diesen 10 Sekunden
gedrückt damit das Update automatisch startet. In Wahrheit muss man das
Gerät erst einschalten, also einmal drücken und loslassen, dann einfach
warten und das Update startet von ganz allein. Danach macht der Fantec
kurz einen Reboot und man sollte den Stick dann wieder rausziehen, sonst
beginnt das ganze Spiel von vorn.
Leider ändert es nichts an dem Problem. Das Gerät bootet nicht
vollständig, bleibt im Fantec-Logo einfach stehen.
Ich würde mal vermuten das wenn der Flash defekt wäre, das Update sich
nicht einspielen ließe, denn der Updater wird wohl hoffentlich eine
Prüfung enthalten.
Daher wäre meine Vermutung nun das es eine Startverhinderung gibt. Mal
schauen ob man durch den Inhalt von install.img oder dem Quelltext TAR
heraus bekommen kann was dem fehlt oder wie man z.B. einen Debug-Port
öffnet um mitlesen zu können was dem fehlt...
Für alle die mitknobeln können und wollen, hier habe ich das Zip mal
über mein Wiki bereitgestellt:
https://e-wiki.denkdose.de/_media/fantec_3ds4600/fantec_3ds4600_firmware_20140526-v10.1.11_r11498.zip
Olli Z. schrieb:> oder wie man z.B. einen Debug-Port> öffnet um mitlesen zu können was dem fehlt...>
Über dem SATA-Port ist doch der UART-Header. Darüber lässt sich doch
bestimmt was während des Bootens herauslesen.
Thomas
Ah, ich hatte nicht genau genug gelesen und einige Zeilen sind durch
falsch interpretierte Newlines nicht umbrochen worden (der Anfang
arbeitet mit Linux-Returns, also nur \n und später wird auf
Windows-Returns \r\n umgeschaltet)
1
REALTEK ROM Monitor, Revision ICIE.0402.1067.
2
Copyright (c) Realtek Semiconductor Corp. - All Rights Reserved.
3
For a list of available commands, type 'help'.
4
Compilation time /version= Feb 19 2014 10:14:08 /ICIE.0402.1067
5
MAC address = 00.11.22.33.44.55
6
Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x00
7
Processor ID/revision = 0x93 / 0x85
8
Endianness = Little
9
Flash memory size = 4 GByte
10
SDRAM size = 512 MByte
11
First free SDRAM address = 0x800c4000
12
Press 'ESC' to Monitor mode____________________
13
14
Set ethernet register: 00000044
Hier folgt dann das eigentliche Problem und dann entscheidet sich das
System das Rettungssystem zu starten:
Der Rest danach ist also garnicht mehr interessant. Es ist die falsche
Signatur vom Flash Chip. Also könnte der doch ne Macke haben. Ich werde
den mal auslöten und schauen ob ich ihn mit meinem Flash-Programmer
lesen kann. Die Frage wäre welche Signatur hier erwartet würde? Eine vom
Hersteller irgendwo hinterlegte?
In der Datei /package5/bootloader/boot_target.bin (Inhalt von
"install.img" findet sich dieser String und direkt davor ein String
"VERONA__". Ich glaube das ist die Signatur die hier gesucht wird.
Hallo,
mein 3DS4600 fing nach Jahren letztens auch an zu spinnen, bpptete nur
selten, stürzte ab.
Ich hatte dann bei ebay eine gebrauchten gefunden, der lief.
Der hatte aber die letzte Firmwareversion, die kein DivX mehr konnte.
Also umflashen...
Wichtig: möglichst einen kleinen USB-Stick auftreiben, hier liegt dafür
ein alter 256MB-Stick rum, FAT32 formatiert.
install.img auf den Stick kopieren.
Stick in die USB2.0 Buchse hinten (die untere).
Das Starten des Flashmodes per Einschalttaster klappt oft erst nach
mehreren Versuchen, evtl. auch mal die anderen USB-Ports versuchen.
Ich habe dann auch nach etlichen versuchen meinen zickenden 3DS4600
nochmal neu geflasht, der ist seitdem wieder in Benutzung und läuft.
Vermutlich ist der Flash hier nicht defekt, nur vergeßlich...
Firmware habe ich die
v10.1.11_r10846 - hier in Benutzung
v10.1.11_r11334
v10.1.11_r11498
noch verfügbar.
Gruß aus Berlin
Michael
Danke für die Infos und Hilfe Michael!
Das Update führt mein Mediaplayer ja klaglos durch, der
Fortschrittsanzeiger kommt und am Ende macht er einen Reset. Wenn ich
den Stick dann aber nicht rausziehe fängt er wieder von vorn an. Will
sagen, er braucht keinen speziellen Tastendruck oder sowas, einfach
Stick mit der Firmware (nur der install.img drauf) rein, Gerät vorn oder
über die Fernbedienung einschalten und los gehts.
In dem Konsolenfenster sieht man dann auch die gesamte Updateprozedur
durchlaufen. Ich hänge mal den kompletten Output davon hier an.
Ich bin gerade noch dabei das ganze zu sortieren. Durch den Zugang zur
Konsole habe ich einen großen Schritt gemacht um mit zu bekommen was da
im Hintergrund so passiert. Auch das auspacken des "install.img" in
seine Bestandteile hilft sicher beim Verständnis.
Das Board selbst ist keine Eigenentwicklung von Fantec sondern ein
"Realtek RT-1186G15". Das beinhaltet eine MIPS-CPU, 512 MB SDRAM, 4 GB
NAND Flash und div. Peripheriebausteine für das IO:
- 1x IR-Empfänger
- 2x LED (rot und blau)
- 1x Taster
- 3x USB Port (2x USB 2.0 und 1x USB 3.0)
- 1x Composite-Out und Audio-Out
- 1x HDMI-Out
- 1x LAN (1GBit)
- 1x Optical-Out
- 1x sATA (eSATA)
- 1x UART (für Konsole)
Es sind noch zahlreiche Stellen unbestückt, also gibt es dieses Board
auch noch in einer besseren Ausführung und vermutlich wird es so auch in
zahlreichen anderen Geräten als HW-Plattform eingesetzt.
So wie ich das bislang erkennen kann sind auf dem Flash mehrere
startbare Partitionen hinterlegt:
1. Bootloader
2. Media-Player OS
3. Rescue-Linux
Der Anfang beim Start nach "hello.world" ist etwas "matsche", warum ist
mir noch nicht ganz klar, evtl. steht hier die Baudrate noch nicht fest?
Danach sieht man auch einige Fehler, keine Ahnung ob die bei einem
laufenden Gerät auch so kämen:
1
Orginal init value: 202072BE
2
cde
3
profile->manufacturer_id (first 4B):DA94D7AD
4
profile->data_per_page:2000
5
profile->page_per_block:100
6
7
blk 79 starts from page 700
8
read page 728 error
9
Tparam now: 20267CC4
10
X
11
Tparam now: 001D6BB6
12
Y
13
14
restored
Was kann dieser "read page 728 error" wohl sein?
Und ist das darunter ein Default-Wert oder Reparaturversuch?
Dann kommt wieder kurz Matsche und der Hinweis auf den NAND-Chip:
1
klmnopqrstu5280 wait5280 wait4K&Detect H27UBG8T2B and enable read-retrial mode...
2
Enable Read-retrial mode...
Ein "Retail mode" ist doch sowas wie ein Demo-Modus für den Verkauf?
Warum meint mein Gerät einen solchen aufrufen zu wollen?
Dann lädt er Umgebungsparameter aus dem Flash:
1
load bbt...load env to (addr 0xa0010000, size 64KB)...
2
page_start=0xf00 page_end=0x1900
Mit "bbt" ist hier wohl der Flash gemeint. Die Flash Addresse 0xA001
0000
und Länge 0xFFFF übersetzt dann ein Tool wohl in eine Flash-Page 0xF00
- 0x1900. Rechnerisch passt das für mich noch garnicht zusammen (0xA00
pages = 2560 Pages. Das wären massiv viel mehr als er bräuchte für
64KB).
In jedem Fall ist er unzufrieden mit dem was er dort findet, geht aber
nicht näher drauf ein:
1
get ENV fail!!
Dann spielt er Ping-Pong? ;-) Muckiert sich aber wieder das er ein
TAR-End nicht findet:
1
load factory to (addr 0x80100000)...
2
load bbt...ping_no =0xff
3
pong_no =0xff
4
there is no data in ping ,pong buffer
5
current_factory_start=0x1900
6
current_factory_start + 0x400=0x1d00
7
tar end,not found
8
tar end,not found
Trotzdem scheint er einige Grundeinstellungen einzunehmen:
1
default_tv_system=
2
new default_tv_system=PAL
3
EPHY: 8211E
4
check_val=0x0
5
[HDMI]: Set I2C Speed = 50 kHz
6
[HDMI]: Chk_HotPlug() TV is not connected.
7
[HDMI]: Read_EDID abort, HDMI cable plug off.
8
[HDMI]: TV is not connected.
9
2nd for PAL
10
PAL logo
So und nun wirds interessant, denn jetzt startet der eigentliche
Bootloader:
1
REALTEK ROM Monitor, Revision ICIE.0402.1067.
2
Copyright (c) Realtek Semiconductor Corp. - All Rights Reserved.
3
4
For a list of available commands, type 'help'.
5
6
Compilation time /version= Feb 19 2014 10:14:08 /ICIE.0402.1067
7
MAC address = 00.11.22.33.44.55
8
Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x00
9
Processor ID/revision = 0x93 / 0x85
10
Endianness = Little
11
Flash memory size = 4 GByte
12
SDRAM size = 512 MByte
13
First free SDRAM address = 0x800c4000
14
15
Press 'ESC' to Monitor mode
Hier würde ich ja gern mal "ESC" drücken wollen... oder "help" eingeben
was der so kann.
Dann folgt erstmal kurz sowas, was man ggf. als Wartezeichen
interpretieren könnte
1
____________________
Dann versucht er wohl das Default-Image zu laden und zu starten und
stellt fest das an der angegebenen Position im Flash nicht die richtige
Signatur liegt und startet stattdessen das "rescue linux":
1
Set ethernet register: 00000044
2
▒r▒▒H) error! Entering rescue linux...
Wartet man den Resuce start ab und gibt in der Konsole mal einfach ein
ENTER, dann sieht man das man in einer Busybox Shell gelandet ist!
Hier könnte man nun versuchen auf das Flash zuzugreifen um z.B. die
fehlende Signatur nach zu programmieren. In einigen Skripten wird das
ganz einfach mit "dd" und dem Device /dev/mtdblock0 gemacht. Ich würde
erstmal versuchen das gesamte Flash auf einen USB-Stick zu kopieren um
für den Notfall ein Backup zu haben.
Dann müsste ich wissen wo genau (offset,länge) das Magic gesucht wird?
Ich glaube das es "VERONA__" ist und 8 Zeichen lang.
Olli Z. schrieb:> Dann kommt wieder kurz Matsche und der Hinweis auf den> NAND-Chip:klmnopqrstu5280 wait5280 wait4K&Detect H27UBG8T2B and enable> read-retrial mode...> Enable Read-retrial mode...> Ein "Retail mode" ist doch sowas wie ein Demo-Modus für den Verkauf?> Warum meint mein Gerät einen solchen aufrufen zu wollen?
Da steht retrial, nicht "retail".
Retrial ist ein erneuter Versuch, hier wohl ein erneuter Versuch, das
Flash-ROM zu lesen.
Mir sieht das so aus, als ob auch das Firmwareupdate fehlschlägt.
Das sieht doch aus als wäre dieser "read-retrial mode" eine bewusste
Einstellung, vermutlich damit bei einem Lesefehler nochmal probiert
wird?
Hier sieht es mir so aus als würde der Treiber versuchen einen
bestimmten Chip (mit der ID 0xadd794da) zu finden, was wohl auch
gelingt:
[rtk_nand_scan_bbt] have created bbt B1, just loads it !!
5
[dump_BBT] Nand BBT Content
6
[0] (0, 27, 0, 2047)
7
RTK: using the whole nand as a partitoin
8
[rtk_nand_init]Randomized enabled
9
[rtk_nand_init]Ecc bit select 24
10
Realtek Nand Flash Driver is successfully installing.
Er hat also den richtigen 4GB großen NAND-Flash. Page-Size 8kb. Dieses
"dump_BBT" erschließt sich mir noch nicht ganz.
Nun kommt das NOR-Flash MX25L1605 (Serielles EEPROM) welches auf der
Platinenunterseite montiert ist (heißt hier "Venus", Realtek hat es wohl
mit Planetennamen):
Venus SFC: using single partition Venus SFC: (for SST/SPANSION/MXIC SPI Flash)
20
this Jupiter eth RX_OFFSET = 0x0
Was er bis hier hin macht ist einfach das booten in das "Realtek Rescue
Linux fpr PhotoViewer". Danach wird der eingesteckte USB-Stick gemounted
und darauf nach einem Update-File gesucht:
1
Hotplug: mount -t vfat -o ro,shortname=winnt,iocharset=utf8,umask=0 /dev/sda1 /var/lock/hotplug/mount_tmp/.sda1 ret: 0
Nachdem er eine qualifizierte Updatedatei (über den Dateinamen) gefunden
hat, versucht er die darin enthaltene Datei "install_a" ins root-FS zu
kopieren:
1
tar: UI: not found in archive
2
command: tar -xOf /mnt/usbmounts/sda1/install.img install_a > /install_a
und anschließend zu starten (install_a ist eine ausführbare ELF-kodierte
Datei):
Hier sind wieder die beiden Bereiche vermutlich für das OS und das
Rescue-Linux zu finden.
Nun entpackt er aus dem TAR noch weitere Dateien:
- arial.ttf
- configuration.xml
- flash_erase
- /image Verzeichnis (enthält die Grafiken die beim Update angezeigt
werden)
- mkfs.jjs2
- install_a
- mkyaffs2image
- nandwrite
- /package5 Verzeichnis
Dem folgen viele weitere Flash-Blöcke, immer nach dem gleichen Schema:
Erst wird mit "nand_erase" ein Bereich gelöscht und dann mit
"nand_write" beschrieben, wie hier am Beispiel des Root-Filesystems:
1
Burning RootFS efwtype(5) image with mem_offset(0x00000000) ...
In Summe finde ich da keine Fehler die darauf hindeuten würden das das
alles nicht geklappt hat. Einzig finde ich aber auch kein Kommando was
besagte "VERONA__" Magic im Flash ablegt.
Dateien, egal wie sie heißen bzw. welches Suffix sie auch haben mögen,
bei denen die ersten 4 Bytes diese Folge haben "68 73 71 73" sind LZMA
gepackte Archive. Das Magic ist eigentlich "0x73687371", da MIPS jedoch
eine 16-Bit Little-Endian Architectur aufweist ist es 2-Byte weise
verdreht.
Die Datei "/package5/squashfs1.img" ist so ein Archiv. Sie lässt sich
problemlos mit 7zip auspacken.
Für mich wirkt es aktuell so als würde der Bootloader den Kernel nicht
finden/laden/ausführen. Dieser müsste ja, wie bei jedem Linux-Boot
Vorgang, als erstes geladen werden. Davon sieht man nach dem
Bootloader-Menü jedoch garnichts, stattdessen die Fehlermeldung und dann
ds Rescue-Linux.
Über eine Websuche kann man andere entsprechende Logs finden die da
zeigen:
1
Linux Kernel:
2
3
FW Image from 0xa2020000, to 0x80100000, size=0x413085
4
5
Audio FW:
6
7
FW Image from 0xa2440000, to 0x81b00000, size=0x1b3bc0
8
9
Video FW:
10
11
FW Image from 0xa2600000, to 0x81d80000, size=0x211578
Christian B. schrieb:> Olli Z. schrieb:>> Hartnäckigkeit zahlt sich doch aus, der Player läuft wieder! :-)> Als Du Hilfe gesucht hast warst du wortreicher!
Ich schon, Du nicht!
Du bist offensichtlich daran interessiert, aber warum gab es keinerlei
Unterstützung von Dir bei der Fehleranalyse und Suche?
Michael U. schrieb:> ja und was war es denn nun?
Im Kern waren es wohl Bad-Blocks im Flash.
Ich muss das noch ordentlich aufarbeiten bevor ich das alles hier
einstelle, aber soweit ich das bislang analysieren konnte verwendet die
Firmware nur das MTD Interface um auf den NAND-Flash zuzugreifen. Dieses
bietet jedoch keinerlei Fehlertoleranz. Ein als BAD erkannter Block kann
somit nicht übergangen werden, es muss durch "andere Mittel" geheilt
werden.
Es gäbe durchaus Treiber die eine solche Selbstreparatur böten, die
kommen aber in der Fantec Firmware leider nicht zum Einsatz.
Das wird auch der Grund sein warum die Appliance beim booten einfach
hängen blieb. Das ganze ist mir selbst aufgefallen als ich versucht habe
Stück für Stück den Flash über TFTP auf meinen PC TFTP-Server zu
übertragen. Da gab es Bereiche bei denen der Fantec im Shell-Fenster
einfach einfror und der TFTP-Server einen Connection-Timeout-Drop
meldete.
Im Log-File war dies auch dokumentiert. Unterhalb vom "[dump_BBT]"
erkennt man die Bad-Block Tabelle:
[rtk_nand_scan_bbt] have created bbt B1, just loads it !!
4
[dump_BBT] Nand BBT Content
5
[0] (0, 27, 0, 2047)
6
RTK: using the whole nand as a partitoin
7
[rtk_nand_init]Randomized enabled
8
[rtk_nand_init]Ecc bit select 24
9
Realtek Nand Flash Driver is successfully installing.
10
VenusSFC MTD init...
Im (russischen?) Forum https://www.moservices.org/forum/ welches sich
allgemein mit den Realtek-Chipsätzen beschäftigt und dafür auch
Custom-Firmware anbietet, gab es ein Reparatur-Tool welches den NAND
nach Bad-Blocks gescannt und diesen auch gelöscht hat (siehe
https://moservices.org/forum/viewtopic.php?f=14&t=3746) . Möglicherweise
wäre das mit "erase -m" im Recovery-Mode auch gegangen, kann ich jetzt
natürlich nicht mehr sagen...
Nach dieser Aktion zeigte das Log an der gleichen Stelle wie oben:
Thread beobachten
Seitenaufteilung abschalten