Debian on Synology RS816 (Armada 385)

@rayknight provided a link to sourceforge which I have followed down to the armada38x branch. I will start making my way through and see what I can turn up. I have electrical work taking place tomorrow which will knock me off-line for most of the day.

https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/22259branch/armada38x-source/

Edit:
Quick search through and the following seems like a good starting point, it includes a make script for rs815 the rs816 predecessor which I believe was just a processor speed bump.

https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/22259branch/armada38x-source/u-boot-armada-2011.12.txz

Edited 1 time(s). Last edit at 04/28/2019 04:09AM by richjn.

Richard,

> https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/22259branch/armada38x-source/
>

We might find the kernel source and how it activate the other 2 SATAs in the above.

> https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/22259branch/armada38x-source/u-boot-armada-2011.12.txz
>

In stock u-boot, we might find other aspects like LEDs GPIOs. But as I recall from zifxify'post, stock u-boot does not activate all SATA ports.

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

Richard,

Please dump the stock DTB. Boot into Debian with DS116 DTB.

Make sure you see 2 MTDs

cat /proc/mtd

dev: size erasesize name 
mtd0: 00400000 00001000 "boot" 
mtd1: 00400000 00001000 "spi-rootfs"

And dump stock DTB

dd if=/dev/mtd0 of=synology-rs816-stock.dtb bs=1 count=65536 skip=917504

And post the file synology-rs816-stock.dtb as attachement here.

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

Hi
Sorry a bit slow I've been without power all day.

cat /proc/mtd

dev:    size   erasesize  name
mtd0: 00400000 00001000 "boot"
mtd1: 00400000 00001000 "spi-rootfs"

dd if=/dev/mtd0 of=synology-rs816-stock.dtb bs=1 count=65536 skip=917504

65536+0 records in
65536+0 records out
65536 bytes (66 kB, 64 KiB) copied, 1.39867 s, 46.9 kB/s

Edited 1 time(s). Last edit at 04/29/2019 07:54AM by richjn.

> We might find the kernel source and how it activate the other 2 SATAs in the above.

I have downloaded the kernel source and will take a look tomorrow.

> In stock u-boot, we might find other aspects like LEDs GPIOs. But as I recall from zifxify'post,
> stock u-boot does not activate all SATA ports.

I think you're correct I spent quite a bit of time looking at u-boot and there are a number of Synology LED customization's which might prove helpful later on but I couldn't find anything useful re: bringing up the extra sata ports.

Richard,

> Hi
> Sorry a bit slow I've been without power all day.

:) Take your time. I'm pretty busy too, so will take it slow on the SATA subject.

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

@bodhi

Just for something to try I booted with ds116.dtb then upgraded the kernel to your latest
uname -a

Linux debian 4.20.6-mvebu-tld-1 #2 SMP PREEMPT Tue Feb 5 16:14:01 PST 2019 armv7l GNU/Linux

I then rebooted back in again with ds116.dtb which worked but I apart from the kernel nothing changed sata wise.

Next I booted with synology-rs816-stock.dtb (the one I dumped) this got stuck at initramfs not finding the rootfs and dumped me to a [initramfs] prompt I didn't try to go further but I will next time. Just to note I did try this with the previous 4.12.4-mvebu-tld-1 kernel and it failed very early so this is an improvement.

Next I booted with armada-385-synology-rs816 (the last one you produced which got stuck early previously) and this booted all the way.

lsblk

NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda         8:0    1  1.8T  0 disk
|-sda1      8:1    1  2.4G  0 part
|-sda2      8:2    1    2G  0 part
`-sda3      8:3    1  1.8T  0 part
sdb         8:16   1  1.8T  0 disk
|-sdb1      8:17   1  2.4G  0 part
|-sdb2      8:18   1    2G  0 part
`-sdb3      8:19   1  1.8T  0 part
sdc         8:32   1  3.8G  0 disk
`-sdc1      8:33   1  3.8G  0 part /
mtdblock0  31:0    0    4M  0 disk
mtdblock1  31:1    0    4M  0 disk

So we have two sata ports now up from one with ds116.tdb I know zifxify got that far as well but I can't help feeling if we can merge the dumped dtb with your last modified version and using the later kernel this might fly. I will have a go myself, frankly I lack the knowledge but maybe I will get lucky!

I have found I can decode TDB's to DTS with dtc but when I try the other way round I get errors am I doing something wrong ?

dtc -O dtb -o test.dtb armada-385-synology-ds816.dts

Richard,

> Linux debian 4.20.6-mvebu-tld-1 #2 SMP PREEMPT Tue
> Feb 5 16:14:01 PST 2019 armv7l GNU/Linux
>

Good idea, it'd make it easier for us to have the same reference point.

> Next I booted with armada-385-synology-rs816 (the
> last one you produced which got stuck early
> previously) and this booted all the way.

This is interesting! it means there was some changes in mainline DTS/DTSI that "fixed" something such as clock source/rate.

> So we have two sata ports now up from one with
> ds116.tdb I know zifxify got that far as well but
> I can't help feeling if we can merge the dumped
> dtb with your last modified version and using the
> later kernel this might fly.

That's the idea! why I asked you to dump this DTB is so we can see if it actually activated the other SATA ports. If there is no node in this DTB that activate them, then stock kernel has hardcoded the activation.

>I will have a go
> myself, frankly I lack the knowledge but maybe I
> will get lucky!
>
> I have found I can decode TDB's to DTS with dtc

That's a good start.

> but when I try the other way round I get errors am
> I doing something wrong ?

I am not sure why.

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

@bodhi
Just a quick update.
I have exhausted all the options I can think of for modifying the DTB although I readily accept my knowledge is insufficient for that to be taken as a statement it can't be done.

I have moved onto the Synology GPL kernel source code and on a positive the source is at least the current dsm version at 3.10.105. To start I have simply taken the Synology provided config for armada38x and done a make menuconfig on it. Doing so I note Synology add a whole new menu structure under "Synology Enhancement Features" which touches just about every configuration category in the tree. Basically they appear to replace whole std line items with their own versions.

Of immediate interest it looks like there are mechanisms for controlling the marvel sata controllers and switches to enable / disable achi and so on.

This is probably going to take some time to weed out the bits we actually need and then the question becomes can we re-implement within the device tree or will we need to port the changes to your kernels.

Will report back when I think I have something you might be able to use to get these rs816's up on Debian

Richard,

I've also looked at the decompiled DTS. Basically saw what I expected. The DS116 DTB is running OK on this box, because in this stock DTB only sata@a8000 is activated (this is the SoC built-in SATA).

sata@a8000 {
                                compatible = "marvell,ahci-sata";
                                reg = <0xa8000 0x2000>;
                                interrupts = <0x0 0x1a 0x4>;
                                clocks = <0x5 0xf>;
                                status = "okay";
                        };

                        sata@e0000 {
                                compatible = "marvell,ahci-sata";
                                reg = <0xe0000 0x2000>;
                                interrupts = <0x0 0x1c 0x4>;
                                clocks = <0x5 0x1e>;
                                status = "disabled";
                        };

And it then activated only pcie2

pcie@2,0 {
                                device_type = "pci";
                                assigned-addresses = <0x82000800 0x0 0x40000 0x0 0x2000>;
                                reg = <0x1000 0x0 0x0 0x0 0x0>;
                                #address-cells = <0x3>;
                                #size-cells = <0x2>;
                                #interrupt-cells = <0x1>;
                                ranges = <0x82000000 0x0 0x0 0x82000000 0x2 0x0 0x1 0x0 0x81000000 0x0 0x0 0x81000000 0x2 0x0 0x1 0x0>;
                                interrupt-map-mask = <0x0 0x0 0x0 0x0>;
                                interrupt-map = <0x0 0x0 0x0 0x0 0x2 0x0 0x21 0x4>;
                                marvell,pcie-port = <0x1>;
                                marvell,pcie-lane = <0x0>;
                                clocks = <0x5 0x5>;
                                status = "okay";
                        };

So this is a big hint right here. I'll make another version for armada-385-synology-rs816.dtb.

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

@bodhi
I did try multiple variations of disabling and enabling the various "status" sections with no joy but I'm very happy to give your modified version a go :-)

EDIT
I should have added that I was making changes to the dumped synology-rs816-stock.dtb not the ds116 or the ds116 based armada-385-synology-rs816.dtb



Edited 2 time(s). Last edit at 05/01/2019 02:16AM by richjn.

Richard,

> I should have added that I was making changes to
> the dumped synology-rs816-stock.dtb not the ds116
> or the ds116 based armada-385-synology-rs816.dtb

Why you are at it, do this to the ds166 DTB. Especially, turn on the status to okay for pcie2.

The DTB basically inlcudes in all the "parent" DTSI nodes, so I think you'll find the pcie nodes in there, too.

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

@bodhi

Quote

The DTB basically inlcudes in all the "parent" DTSI nodes

The light has just been switched on!!!

Quote

> but when I try the other way round I get errors am
> I doing something wrong ?

I am not sure why.

Snip from your DTS amarda-385-synology-rs816.dts

// SPDX-License-Identifier: (GPL-2.0 OR MIT)
/*
 * Device Tree file for Synology RS816 NAS
 *
 * Copyright (C) 2019 <mibodhi@gmail.com>
 *
 * Based on Device Tree file for Synology DS116 NAS
 * Copyright (C) 2017 Willy Tarreau <w@1wt.eu>
 */

/dts-v1/;
#include "armada-385.dtsi"
#include <dt-bindings/gpio/gpio.h>

/ {

Snip from my DTS extracted from amarda-385-synology-rs816.dtb using dtc as follows.

dtc -O dts -o armada-385-rs816.dts -I dtb armada-385-rs816.dtb

/dts-v1/;

/ {

Basically dtc is stripping the #include'
The issue I had compiling DTB' with dtc was in how includes are written where with dtc its

\include\ "foo"

BUT because I then started working with dts's I had extracted from dtb's there were no #include (because they had been stripped by dcc) so I carried on in ignorance!

Any chance you can do another trial amarda-385-rs816.dtb with the pcie stuff included whilst I research how to overcome the issue so I can do more trials myself.



Edited 1 time(s). Last edit at 05/01/2019 05:55AM by richjn.

@bodhi
I was trying to do this from my main linux box but it appears I will just keep having a bad day if I use dtc and should instead do this direct whilst logged into your rootfs or maybe setup a VM

Can you let me know what commands you use to extract / compile please to save me falling into another hole.

I will re-run all of my trials again tomorrow, taking special notice that pcie is declared and enabled through all #includes, and see where we end up.

Richard,

I just use dtc command to decompile the DTB.

As for compiling new DTS, I do it inside my build environment. But you should be able to build it anywhere if the DTS does not include any DTSI.

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

@bodhi
I had read I was able to do it outside of the build environment and it was more convenient for me to do so but because my copy of dtc was stripping #includes I totally missed the DTSI chain of includes which have gpio.h and others within the chain... Duh. Basically I had been wasting my time.

I need to decide whether to just do this from within the usb rootfs = slow or take time out to build a VM. Probably boring additional info but I have been using Arch Linux since 2004 but when they switched to systemd circa 2012 I forked Arch Linux and now use runit as init and service supervision and dropped a load of Arch dependencies I didn't want / need. I maintain compatibility to Arch where I can but I will need to build qemu myself before I can set up a VM. Just need to decide if its worth the time out to do it.

@bodhi
I don't understand why but I get the same result with dtc whilst logged into Debian.

As a way forward can you decompile the synology-385-rs816-stock.dtb (re-attached here) I dumped and post the dts back.

You have already provided the others as dts and the dtsi are human readable anyway so by using the new #include format I can recompile any trial dtbs I produce and proceed with testing.

Richard,


> they switched to systemd circa 2012 I forked Arch
> Linux and now use runit as init and service
> supervision and dropped a load of Arch
> dependencies I didn't want / need.

Yes you will need to do it yourself not using systemd. So does runit have on going supports?

> I maintain
> compatibility to Arch where I can but I will need
> to build qemu myself before I can set up a VM.
> Just need to decide if its worth the time out to
> do it.

Why not using virtualbox? and then run Linux Mint or Ubuntu VM?

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



Edited 1 time(s). Last edit at 05/02/2019 12:39AM by bodhi.

@bodhi
I have already built qemu (with kvm accel) and installed debian-9.9.0 I just need to setup my cross-compile environment and I'm all set to go. I've never used virtualbox but I have heard good things about it.... maybe one day I will give it a try.

Void Linux use runit as well and they add the odd patch but basically no real devel work going on. Having said that its feature complete and stable. I note SysV is being actively maintained again so I might switch to that at some point. I originally went for runit due to the "patch hell" that SysV had become.

If you could extract synology-rs816-stock.dtb I would appreciate it, I'm interested to see what #includes are there. I've tried from my Debian VM with dtc and still get a stripped #includes output whilst trying examples I know have #includes from the dts's you have posted.

Richard,

I've attached in this post the DTB you've post above, and its decompiled DTS.

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

And in this post, I've attached my new DTS (based on DS116) and its DTB.

In this version only pcie2 turned on.

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

@bodhi
Thanks for decoding the synology-rs816.dtb the output is the same as I'm getting which means either there were no #includes or dtc is stripping them off for you too.
I have researched a little and it appears dtc has no way of resolving #includes and hands the job of to cpp and as you have already said yourself you need to be in the build tree for that to work. I wonder if the same is true on decode ?

I have tried with your latest DS116 based amarda-385-synology-rs816.dtb and see two drives again but now one is on the sata controller the other on the pcie controller.

Output of lsblk

NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda         8:0    1  1.8T  0 disk
|-sda1      8:1    1  2.4G  0 part
`-sda2      8:2    1    2G  0 part
sdb         8:16   1  1.8T  0 disk
|-sdb1      8:17   1  2.4G  0 part
`-sdb2      8:18   1    2G  0 part
sdc         8:32   1  3.8G  0 disk
`-sdc1      8:33   1  3.8G  0 part /
mtdblock0  31:0    0    4M  0 disk
mtdblock1  31:1    0    4M  0 disk

Output of ls /dev/disk/by-path

.
..
platform-f10a8000.sata-ata-1
platform-f10a8000.sata-ata-1-part1
platform-f10a8000.sata-ata-1-part2
platform-f10f8000.usb3-usb-0:1:1.0-scsi-0:0:0:0
platform-f10f8000.usb3-usb-0:1:1.0-scsi-0:0:0:0-part1
platform-soc:pcie-pci-0000:01:00.0-ata-2
platform-soc:pcie-pci-0000:01:00.0-ata-2-part1
platform-soc:pcie-pci-0000:01:00.0-ata-2-part2

Output of cat /proc/mtd

dev:    size   erasesize  name
mtd0: 00400000 00001000 "boot"
mtd1: 00400000 00001000 "spi-rootfs"

If you want the full boot dump or any other command let me know.

Just fyi I had dist-upgraded to buster sans the kernel of course just to see if a later udev / kmod might pick something up but no change notticed. If you think it better I revert I will do so.

@bodhi
Really sorry I was incorrect suggesting that previously both drives were on sata.
I just ran the old version again and its one on sata one on pcie as with the latest, however, the pcie one is on a different port.

Old armada-385-synology-rs816.dtb

platform-soc:pcie-pci-0000:02:00.0-ata-2

New armada-385-synology-rs816.dtb

platform-soc:pcie-pci-0000:01:00.0-ata-2

Richard,

> I have researched a little and it appears dtc has
> no way of resolving #includes and hands the job of
> to cpp and as you have already said yourself you
> need to be in the build tree for that to work. I
> wonder if the same is true on decode ?

When you run dtc to decompile the DTB, you don't need to be on the build tree.

As for when you compile the DTS using dtc, I don't see the need to be in the build tree. But you might need to have the build environment set up before hand (not just installing dtc).

I always compile it in the build tree because it is more convenient for me.

>
> I have tried with your latest DS116 based
> amarda-385-synology-rs816.dtb and see two drives
> again but now one is on the sata controller the
> other on the pcie controller.

That's interesting! it means that's how stock OS activate the 2 drives using the DTB. Now we want to know how does it activate the other 2? must be 2 additional pcie nodes. But it was not defined in the DTB, so either stock u-boot does that, or stock kernel patch.

> Just fyi I had dist-upgraded to buster sans the
> kernel of course just to see if a later udev /
> kmod might pick something up but no change
> notticed. If you think it better I revert I will
> do so.

I think it is OK, either stretch or buster does not make much different with this issue (it is not related to udev). We are still dealing with kernel detection of SATA ports.

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



Edited 1 time(s). Last edit at 05/02/2019 05:16AM by bodhi.

Richard,

> Really sorry I was incorrect suggesting that
> previously both drives were on sata.
> I just ran the old version again and its one on
> sata one on pcie as with the latest, however, the
> pcie one is on a different port.
>
> Old armada-385-synology-rs816.dtb
>

> platform-soc:pcie-pci-0000:02:00.0-ata-2
>

> New armada-385-synology-rs816.dtb
>

> platform-soc:pcie-pci-0000:01:00.0-ata-2
>

That's OK. I think we can see that both versions activated SATA 1 as SoC SATA. And stock DTB does that. The 2nd one is PCIe.

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

@bodhi
Last update as I'm giving up on this but thanks for your help along the way.
Although I have given up I'm still happy to test possible solutions anyone might come up with.

Having got my compile environment up and running modifying dts and compiling to dtb all worked fine and I was able to test every variable of "okay" in the modified DS116 file but no changes apart from which pcie / soc port a drive would turn up on changed i.e. it was like once one was enabled the other got disabled. I then moved onto looking at the synology-rs816-stock dts which dumped you to an initramfs prompt, the reason for this was because /dev/ had no disks not even usb and hence the rootfs could not be found. I merged the usb configuration from DS116 across and I could then boot but no other drives turned up at all regardless of any combination of "okay" and "disabled"

Having failed there I moved onto trying to compile the stock kernel actually on the nas itself. I set tmp and swap to one of the HDD's and also added a build directory. There were initially issues with some headers missing but I was unable to build the headers with.

make mrproper
make headers_check

so I just gathered up the headers from vanilla linux-headers-3.10.105 but afterwards make borked very early on with Synology custom mount modules missing dependencies, feels like maybe their GPL source tree is incomplete.

Anyway I'm all out of ideas for this project and will retire to lick my wounds.

Richard,

Quote

Having failed there I moved onto trying to compile the stock kernel actually on the nas itself. I set tmp and swap to one of the HDD's and also added a build directory. There were initially issues with some headers missing but I was unable to build the headers with.

Did you mean using the GPL Source linux-3.10.x-bsp.txz from their download website?

I have not found any patch in this tarball that could be for the RS816. Perhaps I have not found the keyword to do that!

Let's taking a step back and look at where we are here.

So far zifxify and you have been successfully running the ds116 DTB. And that gave you 2 SATAs. Everything else is working. LEDs is a minor issue that we can figure out in time easily.

So if you are OK with running Debian with 2 SATAs, then we can take our time to figure out how to activate the 3rd and 4th ports.

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

@bodhi
Yes, I meant the linux-3.10.x-bsp.txz GPL source.
My idea was to try and build Synology stock kernel and presuming it brought the 4 ports up then work back through the source code till I found which bit made it work but, like you I hadn't found anything with generic search queries and then when I failed to get it built anyway I gave up.

I can leave this RS816 available for testing for as long as it takes, there is no need to press it back into service. I'm even prepared to risk bricking it if you felt a more complete / up to date uboot might pay dividends. I'm happy to battle on and have no issue with this taking a long time. When giving up I was simply acknowledging I probably lacked the knowledge to get any further, however, if you are still up for it you can count me in.

@bodhi
Just as a follow up on my last post I was thinking the way I would probably like to proceed is to just forget about Synology altogether and do the following.

1) Decide if we want to upgrade uboot

2) Blow away the Synology mtd's and install vanilla Debian with /boot on the mtd and / on whatever disk Debian installer can see.

3) Work on getting the other ports up.

Apart from anything else this allows me to get the NAS off my desk and back in the rack :-)

Not sure how doable / advisable the above is ?

Richard,

> 1) Decide if we want to upgrade uboot

No, that's not possible right now.

> 2) Blow away the Synology mtd's and install
> vanilla Debian with /boot on the mtd and / on
> whatever disk Debian installer can see.

That's not the right way to approach this. You always need u-boot on mtd0.

And Debian rootfs should be on HDD or USB. The kernel files can be stored on one of the mtds so that you don't have to tftp.

And the rootfs should be Debian-4.12.4-mvebu-tld-1-rootfs-bodhi.tar.bz2. Don't use the Debian installer.

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