Synology DS215+ Reparatur

[Sascha K. (kuschelganxta)]

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:

SF: Detected MX25U6435F with page size 256 Bytes, erase size 64 KiB, total 8 MiB
*** Warning - bad CRC, using default environment
...
SF: Detected MX25U6435F with page size 256 Bytes, erase size 64 KiB, total 8 MiB
SF: 3014656 bytes @ 0x90000 Read: OK
SF: 4587520 bytes @ 0x370000 Read: OK
## Booting kernel from Legacy Image at 08000000 ...
   Image Name:   Linux-3.10.102
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2410000 Bytes = 2.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
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

[derwildearmin (Gast)]

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

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Lukey (Gast)]

https://www.conetix.com.au/blog/synology-nas-bootrom-recovery

[bastel_ (Gast)]

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.

[Sascha K. (kuschelganxta)]

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:

ALPINE_DB> flash_contents_toc_print
#  | OBJ ID                    | Instance | Name     | Device  | Offset   | Max Size
------------------------------------------------------------------------------------
 0 | 000004 (            STG3) |        0 |     stg3 | Current | 00001000 | 0001f000
 1 | 000001 (            STG2) |        0 |     stg2 | Current | 00020000 | 00002000
 2 | 000003 (          STG2_5) |        0 |   stg2.5 | Current | 00022000 | 00005000
 3 | 000005 (           UBOOT) |        0 |    uboot | Current | 00027000 | 00062000
 4 | 000002 (              DT) |        0 |       dt | Current | 00089000 | 00007000
 5 | 000009 (          KERNEL) |        0 |   kernel | Current | 00090000 | 002e0000
 6 | 00000a (         ROOT_FS) |        0 |   rootfs | Current | 00370000 | 00460000
 7 | 001000 (             N/A) |        0 |   vendor | Current | 007d0000 | 00010000
 8 | 000007 (       UBOOT_ENV) |        0 | uboot-en | Current | 007e0000 | 00010000
 9 | 001001 (             N/A) |        0 |      fis | Current | 007f0000 | 00010000

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

ALPINE_DB> bootm $loadaddr_kernel $loadaddr_rootfs $fdtaddr;
## Booting kernel from Legacy Image at 08000000 ...
   Image Name:   Linux-3.10.105
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2438144 Bytes = 2.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 07500000 ...
   Image Name:   synology_alpine4k_ds215+ 23824
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    3741631 Bytes = 3.6 MiB
   Load Address: 08000000
   Entry Point:  08000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 03b84008
   Booting using the fdt blob at 0x3b84008
   Loading Kernel Image ... OK
   reserving fdt memory region: addr=0 size=100000
   Loading Ramdisk to 037f1000, end 03b827bf ... OK
   Loading Device Tree to 037ea000, end 037f0f8e ... OK
ft_board_setup_clock: setting /soc/clocks/refclk.clock-frequency to 100000000 Hz
ft_board_setup_clock: setting /soc/clocks/sbclk.clock-frequency to 375000000 Hz
ft_board_setup_clock: setting /soc/clocks/nbclk.clock-frequency to 800000000 Hz
ft_board_setup_clock: setting /soc/arch-timer.clock-frequency to 50000000 Hz
ft_board_setup_clock: setting /cpus/[e-mail]-frequency to 1400000000 Hz
ft_board_setup_clock: setting /cpus/[e-mail]-frequency to 1400000000 Hz
ft_board_setup_clock: setting /cpus/[e-mail]-frequency to 1400000000 Hz
ft_board_setup_clock: setting /cpus/[e-mail]-frequency to 1400000000 Hz
ft_board_setup_clock: setting /soc/clocks/cpuclk.clock-frequency to 1400000000 Hz
ft_board_setup_clock: setting /soc/uart0.clock-frequency to 375000000 Hz
ft_board_setup_clock: setting /soc/uart1.clock-frequency to 375000000 Hz
ft_board_setup_clock: setting /soc/uart2.clock-frequency to 375000000 Hz
ft_board_setup_clock: setting /soc/uart3.clock-frequency to 375000000 Hz
ft_board_setup_feature_disable: setting /soc/pcie-external1.status to disabled
ft_board_setup_feature_disable: setting /soc/pcie-external2.status to disabled
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I/O CC forced to 1!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ft_board_setup_prop_u32_set: setting /soc/ccu.io_coherency to 1

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.10.105 (root@build1) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #23824 SMP Fri Oct 26 18:32:13 CST 2018
[    0.000000] CPU: ARMv7 Processor [412fc0f4] revision 4 (ARMv7), cr=30c73c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] Machine: AnnapurnaLabs Alpine (Device Tree), model: Annapurna Labs Alpine Dev Board
[    0.000000] vmalloc area too small, limiting to 16MB

Und die Arbeit wird belohnt mit:

============ Date ============
Sat Jan  8 18:04:35 UTC 2000
==
Sat Jan  8 18:04:36 2000


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:

setenv tftpfile zImage
mw.b $loadaddr 0xFF $spi_pt_size_kernel
tftpboot $loadaddr $tftpfile

sf probe
sf erase $spi_pt_addr_kernel $spi_pt_size_kernel
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!

[Brain2.0 (Gast)]

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.

[Sascha K. (kuschelganxta)]

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

# Clean SPI FLASH
mw.b $loadaddr 0xFF $spi_pt_size_kernel; sf write $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel

# Write new Kernel
mw.b $loadaddr 0xFF $spi_pt_size_kernel; tftpboot $loadaddr zImage 
sf erase $spi_pt_addr_kernel $spi_pt_size_kernel; sf write $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel

# Dump to zImage.flash
mw.b $loadaddr 0x7F $spi_pt_size_kernel;sf read $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel;tftpput $loadaddr $spi_pt_size_kernel Image.flash

# Dump all objects known to environment to tftp
mw.b $loadaddr 0x7F $spi_pt_size_al_boot;sf read $loadaddr $spi_pt_addr_al_boot $spi_pt_size_al_boot;tftpput $loadaddr $spi_pt_size_al_boot al_boot
mw.b $loadaddr 0x7F $spi_pt_size_dt;sf read $loadaddr $spi_pt_addr_dt $spi_pt_size_dt;tftpput $loadaddr $spi_pt_size_dt dt
mw.b $loadaddr 0x7F $spi_pt_size_env;sf read $loadaddr $spi_pt_addr_env $spi_pt_size_env;tftpput $loadaddr $spi_pt_size_env env
mw.b $loadaddr 0x7F $spi_pt_size_fs;sf read $loadaddr $spi_pt_addr_fs $spi_pt_size_fs;tftpput $loadaddr $spi_pt_size_fs fs
mw.b $loadaddr 0x7F $spi_pt_size_kernel;sf read $loadaddr $spi_pt_addr_kernel $spi_pt_size_kernel;tftpput $loadaddr $spi_pt_size_kernel 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.