Synology DS216j gone forever?

Dear Forum,

recently a lightning struck in my neighborhood and destroyed my router plus everything that was attached to it via cable. Fortunately my synology had only its ethernet fried and was doing quite well when I checked in via UART. So I followed the guide on https://wiki.debian.org/InstallingDebianOn/Synology to get a usb ethernet adapter loading and enjoyed a real debian system. Life was good. Thanks to everyone that made all this possible!

However when I shut down the system it stayed in a meta state (disk off, fan off, power led on), presumably because I did not install the kernel from this forum. That was scheduled for later. However that chance never came. Since that joyful boot the system does not respond anymore. Pressing the power button turns on the power led and activates the fan. That is it. UART stays quiet and obviously I don't see any traces of uboot booting. So far I tried:

- Unplugging all drives
- Changing the cables of UART connection
- Cursing, swearing

Any suggestions on what has happened and how to fix (if even possible) that? Blaming the lightning seems far fetched, as the system ran without problems (well useless without ethernet, but booted), but I do not see the stock debian kernel doing any harm, as I did several power cycles that day without issues.

Best regards
Max

Max,

Most likey you will be able to ubrick this Synology box by using UART booting.

The background post by davygravy:
https://forum.doozan.com/read.php?3,7852,7852

My example how:
https://forum.doozan.com/read.php?3,51739,51919#msg-51919

What you need is to find a backup dump of this box mtd0 (most likely SPI flash). mtd0 is where the u-boot image is stored. Or find this u-boot image at Synology website in the GPL section.

If you can find this u-boot image, run kwboot and post the boot log here.

If you can not find this u-boot image, come back later and I'll prepare my backup mtd0 file from a similar Synology box for you to try.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 07/09/2022 05:13PM by bodhi.

Hi bodhi,

thanks for your help. Interesting to learn, that even in that situation it should be able to recover using uboot. So I did some googling, waded through the gpl stuff from synology and finally settled to try an uboot image, that you compiled some time ago for a more or less similar board: https://forum.doozan.com/read.php?2,76314,85779#msg-85779 just to test kwboot.

However the kwboot procedure does not seem to work, it does not even get to the upload stage. Issuing

kwboot -t -B 115200 /dev/ttyUSB0 -b Downloads/u-boot-a38x-2015T1_p18_Thecus-tld-4-spi-uart.bin

Results in

kwboot version 2022.04+dfsg-2+b1
Sending boot message. Please reboot the target...--

Rebooting the target does not start the upload protocol. So it basically sits there forever. When switching to hex output (turning the device on always yields two symbols) shows no deterministic structure (sometimes 47 00 00 00 then 3f 00 00 00 ....).

What do you think?

Best regards
Max

Max,

Quote

presumably because I did not install the kernel from this forum

So are you running mainline ARMv7 Debian kernel, with my DTB? And booting from HDD raw sectors like in the Debian Wiki page describes?

> https://forum.doozan.com/read.php?2,76314,85779#msg-85779
> just to test kwboot.

True, this image is the wrong one. But we'd want to see kwboot transfer it.

> Rebooting the target does not start the upload
> protocol. So it basically sits there forever. When
> switching to hex output (turning the device on
> always yields two symbols) shows no deterministic
> structure (sometimes 47 00 00 00 then 3f 00 00 00
> ....).

I think the problem could be somewhere at the serial header and the wires. Make sure the wires are connected well, and away from the power jack and cable. Usually you would see some spurious output, when there is connection problems.

Quote

Pressing the power button turns on the power led and activates the fan.

Since this is the mainline kernel, if it did boot, I don't know the exact LEDs behavior. Did you try to listen to see if the HDD spinning? if the HDD is spinning, there is a chance that it might have booted somewhat further.

Also, try unplug power for a while to see if that would clear up some weird state.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 07/10/2022 03:45PM by bodhi.

Hi bodhi,

> So are you running mainline ARMv7 Debian kernel,
> with my DTB? And booting from HDD raw sectors like
> in the Debian Wiki page describes?

Exactly.

> True, this image is the wrong one. But we'd want
> to see kwboot transfer it.

Yup.

> I think the problem could be somewhere at the
> serial header and the wires. Make sure the wires
> are connected well, and away from the power jack
> and cable. Usually you would see some spurious
> output, when there is connection problems.

I changed them once but will change them again. If I disconnect Pin2 I get quite some random garbage on screen, but nothing enlightening. That is different to the time when uboot and debian worked. There was less interference when I unplugged Pin2 back then.

> Since this is the mainline kernel, if it did boot,
> I don't know the exact LEDs behavior. Did you try
> to listen to see if the HDD spinning? if the HDD
> is spinning, there is a chance that it might have
> booted somewhat further.

Yes, listened anxiously, but no hdd spin up.

> Also, try unplug power for a while to see if that
> would clear up some weird state.

Yes, I waited one day. Still no change. So I suspect, that the system is indeed stuck in some pre-boot limbo for whatever reason. It is super strange, that it does not react to kwboot commands. Maybe I fried my u-boot installation and the serial port? But how would that even be possible.

So I'll try with different cables once again and hope for the best.

Thanks again
Max

> So I'll try with different cables once again and
> hope for the best.

Nope, cable change did not improve the situation.

Max,

> Yes, I waited one day. Still no change.

Bummer!

Does this board has a RTC battery? I would remove it during this power draining period, too.

> So I suspect, that the system is indeed stuck in some
> pre-boot limbo for whatever reason. It is super
> strange, that it does not react to kwboot
> commands.

There is also another trick. Run kwboot in debugging mode. I see that you are running the 2022.04 version, was that built from u-boot mainline tree? that latest kwboot is quite good comparing to the old versions (I forgot to update it in the u-boot thread).

./kwboot -t -B 115200 /dev/ttyUSB0 -d

If you see any output, then the BootROM probably got stuck in debug mode. Hit <Enter> to see if you got the BootROM prompt. If there is no output, wait for 30 minutes to see the BootROM will time out from the debug mode waiting for command.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

> Does this board has a RTC battery? I would remove
> it during this power draining period, too.

Good idea, but did not help. Unplugged it for an hour. Still no signs of life.

> There is also another trick. Run kwboot in
> debugging mode. I see that you are running the
> 2022.04 version, was that built from u-boot
> mainline tree? that latest kwboot is quite good
> comparing to the old versions (I forgot to update
> it in the u-boot thread).
>
>

> ./kwboot -t -B 115200 /dev/ttyUSB0 -d
>

> If you see any output, then the BootROM probably
> got stuck in debug mode. Hit <Enter> to see if you
> got the BootROM prompt. If there is no output,
> wait for 30 minutes to see the BootROM will time
> out from the debug mode waiting for command.

No, nothing. No debug mode, no output after 40 minutes. I will try to find another serial converter, but I don't have high hopes, that this might be the case.

Best regards
Max