Guten Abend zusammen,
in Fortsetzung meines Threads
Beitrag "Synology DS714-SATA-BP reversing" (hier ging es um die
Storage Backplane) habe ich nun ein defektes DS215+ Mainboard hier
liegen, welches ich zu schade finde zum Wegwerfen und reparieren möchte.
Ich möchte hier das Vorgehen (und hoffentlich den Erfolg) für andere
festhalten.
Symptom:
Nach Anschluß von Strom beginnt die blaue Power-LED zu blinken. Es
ertönt kein Ton. Ob LAN an- oder abgeklemmt ist, ist egal. Auch, ob die
Extension-Card (Reset-Knopf, USB) vorhanden ist.
Vorgehen:
Anschluß JP3 (Pinheader, 1,27mm Raster) gesucht und bei den LEDs
gefunden. USB-Serial-Wandler angeschlossen: GND Pin 2, RX Pin 4, TX Pin
6. Terminal mit 115200 8N1 geöffnet, Bootlog im Anhang.
Diagnose:
Probleme beim Lesen des Kernels:
1
SF: Detected MX25U6435F with page size 256 Bytes, erase size 64 KiB, total 8 MiB
2
*** Warning - bad CRC, using default environment
3
...
4
SF: Detected MX25U6435F with page size 256 Bytes, erase size 64 KiB, total 8 MiB
5
SF: 3014656 bytes @ 0x90000 Read: OK
6
SF: 4587520 bytes @ 0x370000 Read: OK
7
## Booting kernel from Legacy Image at 08000000 ...
8
Image Name: Linux-3.10.102
9
Image Type: ARM Linux Kernel Image (uncompressed)
10
Data Size: 2410000 Bytes = 2.3 MiB
11
Load Address: 00008000
12
Entry Point: 00008000
13
Verifying Checksum ... Bad Data CRC
14
ERROR: can't get kernel image!
15
ALPINE_DB>
Vermutungen:
(1) Corruption
Falls ja, betrifft es nur den Kernel, da die Prüflesungen passen (SF:
3014656 bytes @ 0x90000 Read: OK
SF: 4587520 bytes @ 0x370000 Read: OK)
(2) defekter Flash
Vorerst unwahrscheinlich.
(3) Platinenschaden
Da gelesen werden kann auch unwahrscheinlich.
Nächster Schritt:
Boot über TFTP oder neuflashen des Kernels auf dem Flash (hoffentlich
ohne Löten).
Grüße
Sascha
Hallo,
Sascha K. schrieb:> (2) defekter Flash> Vorerst unwahrscheinlich.
Wir können ne Wette abschliessen, das halte ich für sehr
wahrscheinlich ;-)
Ich habe selber noch nie so etwas gesehen, ohne dass ein Hardwaredefekt
vorliegt.
Am besten den alten Baustein versuchen zu kopieren (selbst wenn er
defekt ist), sofern mit vertretbarem Aufwand möglich. Der Bootloader
scheint ja woanders untergebracht zu sein, da er ja den Flashbaustein
erkennt.
Grüsse
U-Boot sollte dir erlauben, ein neues Image aufzuspielen, wenn du sowas
hast oder aus dem anderen Synology rausziehen kannst.
Da steht was von 'Ctrl-C innerhalb von 3 Sekunden drücken'. U-Boot
sollte dann mit einem kleinen Menü antworten, wo man einige Funktionen
aufrufen kann.
Könnte ein misslungener Firmware Update gewesen sein oder tatsächlich
defekter Flash. Aber das stellt sich dann heraus.
Defekte Hardware halte ich für unwahrscheinlich, da auch U-Boot dann
Probleme hätte, zu starten.
Im UBoot per tftp das kernel image neu flashen, dabei aber nicht das
ganze flash löschen und beschreiben, das geht leicht in die Hose.
Der Chip muss nicht defekt sein, die ollen Dockstars hatten so chips wo
die Bits immer mal gekippt sind, war nur doof, wenn es im Bootloader
passiert ist. Wenn es geht kann man auch direkt von Hdd booten, ohne das
Romimage, aber da braucht man halt schon eine fertige Installation.
Es beschleicht mich, dass der Flash doch einen weg hat, aber für
initiale Boots ausreichend sein sollte - auch wenn es Crasht ist es ein
Fortschritt.
Ich habe per tftpput 0 800000 spi einen Dump gezogen. Interessant ist,
dass der Flash 8MiB groß ist (=8,388,608 x 8bits), der tftpput
allerdings viiel weiter (habe bei 512M aufgehört) Daten liefert.
Das Flash Layout ist lesbar:
1
ALPINE_DB> flash_contents_toc_print
2
# | OBJ ID | Instance | Name | Device | Offset | Max Size
Zum Fortschritt:
Das Board lädt einen Kernel, der Stromverbrauch sinkt.
Steps:
[0. Hardware vorbereiten, Console anschließen]
1. Von https://archive.synology.com/download/DSM/release/6.2.1/23824/
DSM_DS215+_23824.pat laden. Archiv entpacken.
2. TFTP-Server starten. Ich habe Tftpd64 by Ph. Jounin verwandt.
2a. Root-Verzeichnis zum entpackten Archiv zeigen lassen
3. Auf dem Bootpromt
3a. IP von server und eigene IP setzen
env set serverip XXX.XXX.XXX.XXX
env set ipaddr YYY.YYY.YYY.YYY
3b. Das Kernel-Image in den RAM laden:
tftpboot zImage
3c. Die Init-RD in den RAM laden:
tftpboot $loadaddr_rootfs rd.bin
[ 0.000000] vmalloc area too small, limiting to 16MB
Und die Arbeit wird belohnt mit:
1
============ Date ============
2
Sat Jan 8 18:04:35 UTC 2000
3
==
4
Sat Jan 8 18:04:36 2000
5
6
7
DiskStation login:
Vielleicht hilft es auch anderen u-boot-suchenden. Wichtig ist, finde
ich, der Dump mit tftpput zu Beginn. Bis hier ist noch kein Flash
geschrieben worden (per u-boot).
Um das Image in den Flash zu schreiben:
1
setenv tftpfile zImage
2
mw.b $loadaddr 0xFF $spi_pt_size_kernel
3
tftpboot $loadaddr $tftpfile
4
5
sf probe
6
sf erase $spi_pt_addr_kernel $spi_pt_size_kernel
7
sf write $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel
... und hier hat sich gezeigt: Auch mit dem gut bootenden Image aus dem
RAM kommt beim nächsten Boot "Bad Data CRC". Also doch Flash ;-) Danke
@derwildeadmin!
Evtl hilft es das Layout des Flashs leicht zu aendern,
in der Hoffnung das das phoese Bit dann nicht mehr stoert.
Bei meiner Dockstar hat es blos das "Environment" erwischt.
Das stoert mich aber nicht weiter.
Brain2.0 schrieb:> Evtl hilft es das Layout des Flashs leicht zu aendern,> in der Hoffnung das das phoese Bit dann nicht mehr stoert.
Danke für die Idee, aber im Flash sind mittendrin ganze Seiten kaputt.
Hier einige nützliche Befehle
1
# Clean SPI FLASH
2
mw.b $loadaddr 0xFF $spi_pt_size_kernel; sf write $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel
Ich habe jetzt einen neuen Flash bestellt. Da ich meinem Flashdump nicht
wirklich vertraue, werde ich den Flash nach dem Entlöten einmal auslesen
und so auf den neuen brennen.
