Unbrick Synology DS411Slim

[master6464]

Goedemiddag,

Ik ben in het bezit van een synology DS411Slim zonder garantie (natuurlijk) die de geest heeft gegeven.
In mijn poging deze te repareren loop ik nu eigenlijk een beetje vast.

Wat ik al heb gedaan:
-De CPU vervangen -> de Synology is nu weer via een serielle verbinding te benaderen
-Een tftp server opgezet (en getest of deze werkt)
-Geprobeerd of ik de image terug kon zetten op de NAS volgens deze handleiding: http://www.huubmons.nl/mu...e/75-nas-synology-unbrick
(en ook andere handleiding die op hetzelfde neerkomen)

En hier loop ik dus vast.

Ik krijg bij het zoeken naar het bestand alleen time-outs:

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** LOADER **
 ** MARVELL BOARD: Synology Disk Station LE

U-Boot 1.1.4 (Aug  9 2010 - 19:58:12) Marvell version: 3.5.3

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 0068B3D4

Soc: MV88F6282 Rev 1CPU running @ 1600Mhz L2 running @ 533Mhz
SysClock = 533Mhz , TClock = 200Mhz

DRAM (DDR3) CAS Latency = 7 tRP = 7 tRAS = 20 tRCD=7
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
Using default environment

[4096kB@f8000000] Flash:  4 MB

CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
PEX 1: interface detected no Link.

Synology Model: DS411slim
Fan Status: Good

Net:   egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
## Booting image at f8080000 ...
Bad Magic Number
Marvell>> setenv serverip 192.168.1.26
Marvell>> tftpboot 0x800000 zImage
Using egiga0 device
TFTP from server 192.168.1.26; our IP address is 192.168.1.154
Filename 'zImage'.
Load address: 0x800000
Loading: T T T T T T T T T T
Retry count exceeded; starting again

Als ik Wireshark er vervolgens bij pak zie ik dat er wel ARP-requests door de synology worden verstuurd maar dat er niet wordt geantwoord of dat er een andere vorm van communicatie plaatsvind van en naar de synology.

De synology hangt nu nog aan mijn gewone netwerk maar om uit te sluiten dat dit het probleem is heb ik deze ook al aangesloten aan een switch samen met de tftp server (die ik ook een statisch adres heb gegeven). Ik kreeg echter dezelfde output

Mijn volgende stap zou zijn de Marvel 88e1116r gigabit ethernet transceiver te vervangen. Omdat dit echter een moeilijk te krijgen onderdeel is wil ik zeker weten dat dit het probleem is.

Doe ik iets fout of is het inderdaad de ethernet transceiver?

[ Voor 1% gewijzigd door master6464 op 10-12-2017 13:05 . Reden: vraag toevoegen ]

[Mijzelf]

master6464 schreef op zondag 10 december 2017 @ 13:04:
Als ik Wireshark er vervolgens bij pak zie ik dat er wel ARP-requests door de synology worden verstuurd maar dat er niet wordt geantwoord

Schrijf je hier nou echt wat je bedoelt? In dat geval is natuurlijk niet de Synology het probleem, maar je TFTP server. Die moet wel antwoord geven op de ARP request.

/Edit: De CPU vervangen? Petje af!

[ Voor 4% gewijzigd door Mijzelf op 10-12-2017 14:57 ]

[master6464]

Mijzelf schreef op zondag 10 december 2017 @ 13:48:
[...]

Schrijf je hier nou echt wat je bedoelt? In dat geval is natuurlijk niet de Synology het probleem, maar je TFTP server. Die moet wel antwoord geven op de ARP request.

/Edit: De CPU vervangen? Petje af!

Mmmm... dan ga ik nog even verder spelen met de TFTP server...
Bedankt! Als ik verder kom dan laat ik het weten.

[rikadoo]

Heb je ook het ip adres van de ds vastgezet? met commando setenv ipaddr xx.xx.xx.xx, want die zie ik nergens?

[master6464]

rikadoo schreef op zondag 10 december 2017 @ 17:36:
Heb je ook het ip adres van de ds vastgezet? met commando setenv ipaddr xx.xx.xx.xx, want die zie ik nergens?

dat ip adres staat standaard op 192.168.1.154 en ik heb inderdaad ook andere adressen geprobeerd met dat commando

[Mijzelf]

Nog even over Wireshark. Draait die op hetzelfde systeem als de TFTP server?

De ARP request is een broadcast, maar het antwoord gaat specifiek naar de Synology. Dus als Wireshark op een ander systeem draait, zou je dat antwoord wel eens kunnen missen.

[master6464]

Mijzelf schreef op zondag 10 december 2017 @ 18:08:
Nog even over Wireshark. Draait die op hetzelfde systeem als de TFTP server?

De ARP request is een broadcast, maar het antwoord gaat specifiek naar de Synology. Dus als Wireshark op een ander systeem draait, zou je dat antwoord wel eens kunnen missen.

Die draait inderdaad op hetzelfde systeem als de TFTP server

[master6464]

kleine update:
Ik heb ff een crossover kabel in elkaar geflanst om er zeker van te zijn dat de tussenliggende apparaten geen probleem vormen en ik krijg nu de volgende output:

Dus er wordt wel netjes een ARP reactie verstuurd maar er wordt niks mee gedaan..

Iemand een idee wat mijn volgende stap moet zijn of moet ik de ethernet ic vervangen?

Groet,

Rick

[Mijzelf]

Als je nu een 8 draads kabel gebruikt, zou je eens een 4 draads kunnen proberen, om hem naar 100Mbit te forceren. Je wwet maar nooit.

Overigens kun je mogelijk met xmodem ook een zImage uploaden. Dat gaat met het commando loady. Kun je in testen of hij verder normaal boot, voor je moeilijke dingen gaat doen.

[Starke]

Om maar even een dwarsstraat te noemen met betrekking tot TFTP heb je ook geprobeerd met een TFTPClient een test bestand naar je TFTP server te uploaden (gewoon om te kijken of de TFTP server in je netwerk gezien word)?

In mijn ervaring wil Windows Firewall namelijk wel eens wat roet in het eten gooien met het opzetten van de verbinding naar je machine waar je de TFTP server draait.

[master6464]

Mijzelf schreef op maandag 11 december 2017 @ 20:26:
Als je nu een 8 draads kabel gebruikt, zou je eens een 4 draads kunnen proberen, om hem naar 100Mbit te forceren. Je weet maar nooit.

Overigens kun je mogelijk met xmodem ook een zImage uploaden. Dat gaat met het commando loady. Kun je in testen of hij verder normaal boot, voor je moeilijke dingen gaat doen.

Die 4-draads zal ik eens proberen.
normaal booten gaat niet want dan krijg ik de volgende foutmelding:

## Booting image at f8080000 ...
Bad Magic Number

Aangezien de CPU volgens mij de firmware bevat en ik een nieuwe CPU geplaatst heb zal ik eerst die image moeten uploaden. (correct me if i'm wrong)

loady behoort helaas niet tot de opties
Dit zijn de commando's die ik tot mijn beschikking heb:

?       - alias for 'help'
WOLTest - Wake On Lan u-boot testing
base    - print or set address offset
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
bubt    - Burn an image on the Boot Flash.
cmp     - memory compare
cp      - memory copy
cpumap - Display CPU memory mapping settings.
crc32   - checksum calculation
echo    - echo args to console
erase   - erase FLASH memory
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print online help
icrc32  - checksum calculation
iloop   - infinite loop on address range
imd     - i2c memory display
imm[.b, .s, .w, .l]     - i2c memory modify (auto-incrementing)
imw     - memory write (fill)
inm     - memory modify (constant address)
iprobe  - probe to discover valid I2C chip addresses
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nm      - memory modify (constant address)
pci     - list and access PCI Configuration Space
phyRead - Read Phy register
phyWrite        - Write Phy register
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
resetenv        - Return all environment variable to default.
setenv  - set environment variables
sflash  - read, write or erase the external SPI Flash.
sg      - scanning the PHYs status
tftpboot- boot image via network using TFTP protocol
version - print monitor version

Starke schreef op maandag 11 december 2017 @ 20:33:
Om maar even een dwarsstraat te noemen met betrekking tot TFTP heb je ook geprobeerd met een TFTPClient een test bestand naar je TFTP server te uploaden (gewoon om te kijken of de TFTP server in je netwerk gezien word)?

In mijn ervaring wil Windows Firewall namelijk wel eens wat roet in het eten gooien met het opzetten van de verbinding naar je machine waar je de TFTP server draait.

Ik heb wel getest of ik met een andere TFTP client iets van deze server kon downloaden en dat werkte gewoon. Is het dan alsnog verstandig om dit de andere kant op te testen?

[Mijzelf]

master6464 schreef op maandag 11 december 2017 @ 20:42:
Aangezien de CPU volgens mij de firmware bevat en ik een nieuwe CPU geplaatst heb zal ik eerst die image moeten uploaden. (correct me if i'm wrong)

You're wrong.
Een Kirkwood heeft geen flash aan boord (behalve een inimini pre-bootloader), dus Linux zit in een aparte flash chip (4MB, volgens jouw u-boot log). Daar zit overigens ook u-boot zelf in, dus de flash chip is niet dood.

loady behoort helaas niet tot de opties
Dit zijn de commando's die ik tot mijn beschikking heb:
[cmd]? - alias for 'help'
WOLTest - Wake On Lan u-boot testing

WOLTest is ook een aardige. Ik weet niet precies wie WOL implementeert, maar *als* je met WOL de box aan kan zetten, lijkt het me dat het ontvangstgedeelte van Ethernet wel snor zit.

Overigens kan die commando lijst niet volledig zijn. Ik mis de commando's om een uImage uit flash te laden. Ik bedenk net dat u-boot vaak ook images van USB stick of harddisk kan laden. Dat is ook nog een mogelijk pad.

Als laatste heb je nog kw-boot, een mogelijkheid om een nieuwe u-boot serieel te uploaden, een u-boot die dan wel loady en fatload ondersteund.

[master6464]

Mijzelf schreef op dinsdag 12 december 2017 @ 09:53:
[...]
You're wrong.
Een Kirkwood heeft geen flash aan boord (behalve een inimini pre-bootloader), dus Linux zit in een aparte flash chip (4MB, volgens jouw u-boot log). Daar zit overigens ook u-boot zelf in, dus de flash chip is niet dood.

Dan neem ik dit gewoon van je aan

[...]
WOLTest is ook een aardige. Ik weet niet precies wie WOL implementeert, maar *als* je met WOL de box aan kan zetten, lijkt het me dat het ontvangstgedeelte van Ethernet wel snor zit.

geprobeerd en krijg het volgende:

Your phy chip 0x2
Your phy not support WOL

Overigens kan die commando lijst niet volledig zijn. Ik mis de commando's om een uImage uit flash te laden. Ik bedenk net dat u-boot vaak ook images van USB stick of harddisk kan laden. Dat is ook nog een mogelijk pad.

Is het niet zo dat dit afhankelijk is van welke build er is gebruikt? (misschien heeft Synology ruimte willen besparen)

Als laatste heb je nog kw-boot, een mogelijkheid om een nieuwe u-boot serieel te uploaden, een u-boot die dan wel loady en fatload ondersteund.

Ik zal me hier eens in gaan verdiepen want ik geloof dat ik niet veel opties meer over heb.

[Mijzelf]

master6464 schreef op woensdag 13 december 2017 @ 20:03:
Is het niet zo dat dit afhankelijk is van welke build er is gebruikt? (misschien heeft Synology ruimte willen besparen)

u-boot kan inderdaad gebouwd worden met meer of minder mogelijkheden, maar de functie om uImage uit flash te laden moet er toch zijn, anders kan die box zowiezo niet booten. En ik zie hem niet in het lijstje.

Met het command printenv kun je zien hoe de NAS normaal gesproken boot. De commando's achter 'bootcmd' worden uitgevoerd bij een normale boot. Ik verwacht iets als

load.e 0x40000 0xwhatever 0x100000; bootm 0x40000

of

nand read 0x400000 0xwhatever 0x100000; bootm 0x40000

Dat laadt vanaf adres 0xwhatever in flash 1MiB naar ram geheugen 0x40000, en boot dat vervolgens.
Noch load noch nand staan in jouw lijstje, en ik zie niets staan waarmee je iets uit flash in het geheugen zou kunnen laden. Behalve misschien sflash.

[master6464]

De 4-aderige kabel bied ook geen oplossing.

Mijzelf schreef op woensdag 13 december 2017 @ 21:10:
[...]

u-boot kan inderdaad gebouwd worden met meer of minder mogelijkheden, maar de functie om uImage uit flash te laden moet er toch zijn, anders kan die box zowiezo niet booten. En ik zie hem niet in het lijstje.

Met het command printenv kun je zien hoe de NAS normaal gesproken boot. De commando's achter 'bootcmd' worden uitgevoerd bij een normale boot. Ik verwacht iets als

load.e 0x40000 0xwhatever 0x100000; bootm 0x40000

of

nand read 0x400000 0xwhatever 0x100000; bootm 0x40000

Dat laadt vanaf adres 0xwhatever in flash 1MiB naar ram geheugen 0x40000, en boot dat vervolgens.
Noch load noch nand staan in jouw lijstje, en ik zie niets staan waarmee je iets uit flash in het geheugen zou kunnen laden. Behalve misschien sflash.

mijn env:

bootcmd=bootm F8080000 F8280000
baudrate=115200
loads_echo=0
ipaddr=192.168.1.154
serverip=192.168.1.155
rootpath=/mnt/ARM_FS/
netmask=255.255.254.0
run_diag=yes
stdin=serial
stdout=serial
stderr=serial
console=console=ttyS0,115200 mtdparts=spi_flash:0x80000@0(uboot)ro,0x300000@0x100000(root)
mainlineLinux=no
CASset=min
enaMonExt=no
enaCpuStream=no
enaWrAllo=no
pexMode=RC
disL2Cache=no
setL2CacheWT=yes
disL2Prefetch=yes
enaICPref=yes
enaDCPref=yes
sata_dma_mode=yes
MALLOC_len=1
ethprime=egiga0
netbsd_en=no
vxworks_en=no
bootargs_root=root=/dev/nfs rw
bootargs_end=:::DB88FXX81:eth0:none
image_name=uImage
standalone=fsload 0x2000000 $(image_name);setenv bootargs $(console) root=/dev/mtdblock0 rw ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvPhoneConfig); bootm 0x2000000;
lcd0_enable=0
lcd0_params=640x480-16@60
lcd0_bootargs=video-dovefb:lcd0:$(lcd0_params) clcd.lcd0_enable=$(lcd0_enable)
bootdelay=3
disaMvPnp=no
ethaddr=00:50:43:3c:3b:5d
ethmtu=1500
mvPhoneConfig=mv_phone_config=dev[0]:fxs,dev[1]:fxo
mvNetConfig=mv_net_config=(00:11:88:0f:62:81,0:1:2:3),mtu=1500
usb0Mode=host
pcieTune=no
bootargs=console=ttyS0,115200 ip=off initrd=0x00800040,4M root=/dev/md0 rw syno_hw_version=DS411slimv10 ihd_num=0 netif_num=1
ethact=egiga0

Environment size: 1241/4092 bytes

wat ik achter bootcmd heb staan is ongeveer hetzelfde als wat ik bij veel andere synology nas'en zie op internet.