Bricked my Synology RS212 - seeking advice

Greetings all,
after much reading and note taking from this forum, I started on the journey of swapping out the stock Synology OS with Debian. At least, that was the goal. Along the way, it looks like I've bricked the poor thing.

It's a Kirdwood CPU, with 256MB RAM and some SPI flash. (Uncertain of size now)
I'm presuming that it's similar to the DS212, just in a 1ru chassis, rather than a desktop unit. (Is this a correct presumption?)

It was running u-boot 1.1.4 (stock) with a 2.6 kernel and initrd in SPI flash.

I got a tftp server up and running, got the kernel and Debian rootfs from bodhi and ran the 'tftpboot 0x808000 uImage' and 'tftpboot 0x???? uInitrd' commands. (I've lost the details of the memory addresses, since my serial terminal app has ungracefully exited, taking the logs with it).
Unfortunately both loaded the files and then said 'bad magic number'.
¯\_(ツ)_/¯ , I thought. I'll reset the CPU and try again.
uh… Nothing on the serial port. No messages, nothing.
Maybe the memory addresses are where the images are loaded from, not to, and I just overwrote the flash?
I didn't think that was possible - being memory protected. Did I get that hideously wrong?

At least there's kwboot (which I've used before when recovering my Helios64 device) to recover, right?
No. All I'm getting with that is xmodem protocol errors :/
I tried all the 2017.07 kwboot images and they all gave me xmodem protocol errors.

There's no uboot image in the current Synology OS archive to try with - argh.
The Synology RS212 is listed in both the linux kernel source and the u-boot source, so someone's done something with this device before, but I cannot find any discussions online to confirm other people's experiences with it.

That was yesterday.

I'm going to pull the RS212 out of my rack, drop it on my desk and see if having it separated from the VSphere cluster helps. (I dunno, maybe even sacrificing a goat?) and swap out the USB cable for a shorter one. (5m is convenient, but potentially error-creating)
If that doesn't work, then I'll have run out of things I can try on my own.

Can I ask for advice on how to build a uboot image that is appropriate for both kwboot and tftpboot?
I have a surfeit of functional hardware (x86, ARM & ARM64) so can easily put together a build environment.

That'll at least get the device alive again, after which I can map out the flash, maybe get an upgraded uboot image installed, and then boot the kernel and initrd from USB.



Edited 1 time(s). Last edit at 08/09/2021 11:09PM by renee.

Have attempted to start building Synology's custom u-boot (as from sourceforge) but the rs212.sh script creates a busted 'include/config.mk' file. (debian10)

::sigh::

renee,

> It's a Kirdwood CPU, with 256MB RAM and some SPI
> flash. (Uncertain of size now)
> I'm presuming that it's similar to the DS212, just
> in a 1ru chassis, rather than a desktop unit. (Is
> this a correct presumption?)

Most likely correct.


> Unfortunately both loaded the files and then said
> 'bad magic number'.

> uh… Nothing on the serial port. No messages,
> nothing.
> Maybe the memory addresses are where the images
> are loaded from, not to, and I just overwrote the
> flash?

No, not likey. You cannot overwrite the flash with tftp. However, each u-boot has some speifics to it. So it is depending on how the stock envs were defined. It could try to reflash itself when there is an unsuccessful boot. There is no way to tell, unless we can see the stock u-boot envs as listed in serial console.

> At least there's kwboot (which I've used before
> when recovering my Helios64 device) to recover,
> right?
> No. All I'm getting with that is xmodem protocol
> errors :/
> I tried all the 2017.07 kwboot images and they all
> gave me xmodem protocol errors.

That's actually a good sign! try kwboot with the NSA325 2017.07 u-boot.

And post you serial log (including the kwboot command, until the xmodem protocol error). Basically everything.

> Can I ask for advice on how to build a uboot image
> that is appropriate for both kwboot and tftpboot?
> I have a surfeit of functional hardware (x86, ARM
> & ARM64) so can easily put together a build
> environment.

Best if you can find either the RS212 or DS212 stock u-boot. They should have it somewhere in Synology website.

The NSA325 is the same SoC as the RS212/DS212, but RAM size is different. So it might not get you farther than a u-boot banner when it starts. You can also try the Pogo E02 2017.07 u-boot.

Back kwboot issue. Most of the time xmodem error is good, because there is some handshake occured (ie. this box can be booted wit UART using kwboot, some Kirwood boxes don't).

Whenever you see that error, just recall the kwboot command on the terminal and execute it right away. Repeat this as many times as you can.

And post the serial console log so I can see what's going on.

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

renee Wrote:
-------------------------------------------------------
or thing.
>
> It's a Kirdwood CPU, with 256MB RAM and some SPI
> flash. (Uncertain of size now)
> I'm presuming that it's similar to the DS212, just
> in a 1ru chassis, rather than a desktop unit. (Is
> this a correct presumption?)
>
Although the CPU used in the RS212 and DS212 is most likely the same as Synology lists both as 1.6GHz they do have significant differences. The RS212 has 2x SATA, 2x Gigabit Ethernet, 2x USB 2.0 and eSATA while the DS212 has 2x SATA, 1x Gigabit Ethernet, 2x USB 3.0, 1x USB 2.0, and 1x SDHC.

This is all I get :
(The NAS borks at the initial send of the boot file)

sysadmin@boot:~/uBoots$ while [[ $continue ]]; do date; kwboot -t -d -b uboot.2017.07-tld-1.nsa325.mtd0.kwb /dev/ttyUSB0 ; continue=$?; echo ... ; done
Sun 29 Aug 15:33:44 AEST 2021
Sending debug message. Please reboot the target...\
Sending boot image...
xmodem: Protocol error
...
Sun 29 Aug 15:33:48 AEST 2021
Sending debug message. Please reboot the target...-
Sending boot image...
xmodem: Protocol error
...
Sun 29 Aug 15:34:12 AEST 2021
Sending debug message. Please reboot the target.../

--- ad infinitum  ---

renee,

You've missed the -p option

kwboot -t -d -b uboot.2017.07-tld-1.nsa325.mtd0.kwb /dev/ttyUSB0 -p

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

Renee,

You should be able to get a RS212 specific U-Boot binary by downloading the latest DSM from Synology at https://www.synology.com/en-us/support/download/RS212#system. This should be the file DSM_RS212_*.pat (where * is the latest version). This is actually a POSIX tar archive so can be unpacked on linux using the command "tar xvf DSM_RS212_*.pat". The result will be the contents of the tar archive which should have a uboot_RS212.bin file if it follows the normal Synology pattern. This file can be used with kwboot.

Ray

I've struggled to get back to this and when I did get back once, I was still not able to make any progress.

Even with the -p option, none of the images booted.
The DSM blob from Synology does not contain a uboot image, so that option didn't work either.

Unless something magical happens somewhere, it's a very wide shaped brick.

1. If you keep getting xmodem protocol errors, perhaps look at how the serial wires are placed. Are they close to a power source, such as the box power barrel jack? Try route them as far from any power cord as possible. Or use something to shield them from EM interference.


2.

Quote

Have attempted to start building Synology's custom u-boot (as from sourceforge) but the rs212.sh script creates a busted 'include/config.mk' file. (debian10)

Sometime the u-boot source is too old and only built with older gcc.

Post the link to that SourceForge Synology u-boot source. I'll take a look and see if it can even built with Debian wheezy (i.e. gcc 4.9.x)

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