I would like to replace Synology's DSM with Debian on a DS718+ for various reasons. Not much can be found in the internet concerning this topic for this special model (Intel apollolake, x86_64) so I am trying to find a way my myself.

First thing we need is a UART connection to the serial console of the device. When turning down the box so that power button and leds are on the lower sider, on the right side near the opening (near the RAM module) there is a 6 pin header:

back:  4   5   6

front: 1   2   3

The pins on the front side must be connected this way:

1: Rx -> connect to Tx of TTL Adapter
2: Tx -> connect to Rx of TTL Adapter
3: GND: GND of TTL Adapter can be attached to screw of the bottom cover instead of this pin

Pins 4, 5 and 6 are not needed.

When the serial connection is established (e.g. screen /dev/ttyUSB0 115200), power on the device, press ESC immediately and continue up to one minute until the EFI bootmanager opens. There is the possibility to enter BIOS but I did not change anything there. BIOS seems configured fine but highly and hard customized by Synology.

The bootmanager lets you select a different boot device but only USB devices are accepted. The device boots by default from a USB DOM but a USB stick plugged into the front usb port is recognized as well and is selectable. Elsewhere in the internet I found informations that these custom USB sticks must have the very same vendor and product id as the default USB DOM (both f400) but I cannot confirm that. I am using an ADATA C802 without modification of vendorid/productid.

So now we have a serial connection and a recognized USB stick. Next thing to mention is that the usual Debian installer iso images installed on this USB stick are not accepted by the bootloader. There must be an EFI partition containing grub, kernel image and initrd. So next problem is to install grub on the stick. Create an EFI partition and install grub there from a compatible x86_64 computer. I found a script with the important steps here.

Now it is important to rename on this EFI boot partition

mv /EFI/BOOT/grubx64.efi /EFI/BOOT/SynoBootLoader.efi

Otherwise grub is not found. The boot entries are as usual in /EFI/BOOT/grub.cfg

A sample entry in grub.cfg could be (templates can be found on Synology's USB DOM device):

#if set "serial --pci=[bus],[device],[function]", use mmio to implement console uart.
serial --pci=0,24,2 --speed=115200
terminal_input serial
terminal_output serial
set default='1'
set timeout='3'
set fallback='0'

menuentry 'My Debian installer' {
    insmod part_gpt
    insmod ext2
    linux /bzImage root=/dev/md0 earlyprintk=apl console=ttyS2,115200n8 ihd_num=2 netif_num=2 HddHotplug=1 SataPortMap=21 syno_hw_version=DS718+ vender_format_version=2 syno_hdd_detect=18,179,176,175 syno_hdd_enable=21,20,19,9 syno_usb_vbus_gpio="13@0000:00:15.0@3"
    initrd /initrd.gz
}

So now I want to start the debian installer from USB stick. Debian offers a kernel and initrd for the installer as download thought for running the installer from hard disk. This initrd can be used as a base but kernel modules which must be selfcompiled later must be added. The kernel cannot be used at all (at least this was my experience).

So the next big problem is to compile a customized kernel and modules. Synology has toolchains and source code ready for download but the kernel config ("4.4.59+") must be modified. The original version configures a lot of Synology proprietary steps mainly for signing kernel modules and initrd. These parameters must be removed and a kernel recompiled (attached my working kernel config). I found also that the Synology toolchain is really necessary. I've got a running kernel only when compiled with their toolchain. The gcc from a usual debian installation did not produce a runnable kernel.

At this point I have an initrd from the debian installer (enriched by kernel modules from the previous build) and a selfcompiled modified kernel and can configure grub to start the debian installer. When selecting my USB stick as boot device, the grub menu starts and I can select the debian installer. The installer starts fine, I can pass all dialogs and then the base system should get installed. But during this step at a certain point the installation fails with an error. From the installation log files I can see that the problem is that the installer cannot mount the target file system (-> attached syslog file from installer).

I have tried other solutions but until now without success:

• installation of debian with debootstrap (exit from debian installer into terminal and continue with this method)
• recompile util-linux (containing mount, libmount ..) with Synology's toolchain
• finally created my own toolchain using crosstool-ng (Synology used this for creating their toolchain as well)

No way out. Always the step when mounting the target filesystem from initrd fails with one or another error concerning missing mount permissions. Especially bind, slave and move mounts fail ("Are you root?", "Permission denied", ...). Instead mounting the target filesystem onto the initrd file system works as expected. Below the errors when booting debian installed manually with debootstrap and an initrd created there with mkinitrd:

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: M[    9.346825] usb 1-3: new high-speed USB device number 2 using xhci_hcd
ounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 
/dev/sda2: clean, 31847/4890624 files, 628870/19531264 blocks
[    9.447121] random: nonblocking pool is initialized
done.
[    9.483270] EXT4-fs (sda2): barriers disabled
[    9.492247] usb-storage 1-3:1.0: USB Mass Storage device detected
done.
[    9.493852] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    9.508513] scsi host3: usb-storage 1-3:1.0
[    9.513333] usbcore: registered new interface driver usb-storagele
[    9.612832] usb 1-4: new high-speed USB device number 3 using xhci_hcd
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... mount: Operation not permitted
mount: invalid option --
done.
mount: Operation not permitted
mount: Operation not permitted
[    9.744014] EXT4-fs (sda2):  ext4_find_entry:1465: inode #3407873: comm run-init: checksumming directory block 0
[    9.744014] 
[    9.757334] usb-storage 1-4:1.0: USB Mass Storage device detected
[    9.764291] scsi host4: usb-storage 1-4:1.0
[    9.814884] EXT4-fs (sda2):  ext4_find_entry:1465: inode #4456451: comm run-init: checksumming directory block 0
[    9.814884] 
mount: Operation not permitted
mount: Operation not permitted
run-init: overmounting root: Operation not permitted
[    9.997939] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

Currently out of ideas how to resolve this problem.

Any hint what could be the problem? Could it be the kernel where something is still misconfigured? The kernel is in fact the same for all these attempts.



Edited 4 time(s). Last edit at 08/14/2021 10:40AM by debi-718.

debi-718,

> an initrd created there with mkinitrd:

> Any hint what could be the problem? Could it be
> the kernel where something is still misconfigured?
> The kernel is in fact the same for all these
> attempts.

The above could be the problem. You ran debootstrap and now have a rootfs. When you install the kernel, should just let dpkg create the initrd for you. That way all the hooks are set up properly without you doing any thing extra. For example, running dpkg -i to install my Kirkwood kernel release will result in these 2 files (among others):

Quote

vmlinuz-5.13.6-kirkwood-tld-1
initrd.img-5.13.6-kirkwood-tld-1

To make this happens automatically, the kernel build must produce a Linux image the vmlinuz and the initrd packages in it. And to have such kernel package, the kernel must be configured to have those options.

So yes, I think probably the kernel configuration is not yet complete as you would want to.

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

> So yes, I think probably the kernel configuration
> is not yet complete as you would want to.

Or you missed a step somewhere. Perhaps this:

After creating the rootfs with debootstrap, chroot in and install kernel.

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

Thank you very much for your help, bodhi.

I have tried once again to install debian with debootstrap and used vmlinuz and initrd from this installation. The problem is that none of these default debian kernels run on the DS718+. The only usable kernel I've got so far comes from Syno's 4.4.59+ kernel sources compiled with their toolchain. I agree that the problems with my current setup derive most probably from incompatible versions of kernel, initrd and/or binaries inside of initrd. This suggests that I must compile everything inside the initrd with this toolchain as well. And so far I could not find documentation how to do this for debian.

Years ago I compiled everything with gentoo from scratch, but such a distribution is very difficult and time consuming to manage in the long run and not the best choice for a nas.



Edited 1 time(s). Last edit at 08/15/2021 08:13AM by debi-718.

debi-718,

What makes this difficult is this kernel is quite old. Even it is 4.4.59+, it does not use device tree.

So to do it right, the board files in this kernel need to be converted to device tree DTS. And then you can use it with a Debian mainline kernel for x86_64.

Perhaps you can find some works in progress for this box's device tree at Synology website?

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

Synology recently released DSM 7. The sources are not yet published and I didn't try this new version. Other people say that Synology never upgrade the kernel for a specific model. It remains the same for the whole lifetime of the model. No upgrade, no security patches. This is another important reason to leave DSM.

So far I could not find anything regarding device tree files for Synology models. I think it is pretty difficult to setup a dts from scratch. Up to now I have used such files provided by others for arm devices.

I have not yet made up my mind how to proceed. This stuff is rather time consuming.

Today I checked out DSM 7 for DS718+. The kernel remains in the long-term line 4.4 and was upgraded from 4.4.59 (26-Mar-2017) to 4.4.180 (16-May-2019).

The most recent published kernel for this line is however 4.4.282 from 27-Aug-2021.

Perhaps I find a bit more time to work on this problem in September.

@debi-718 did you give it another shot? It would be awesome if we could get a mainline kernel to boot on synology x86_64 devices.

No, I gave up. Writing device tree files from scratch is very complicated and time consuming for me.

Sorry I have basically no knowledge of embedded systems so please forgive me if I mixup things, I'm just trying to understand.

I was reading a bit into device trees and I don't get why we need to write our own. I though on x86 machines with a Bios that initialises the RAM we could just scan the busses, and discover things like storage and network that are connected via USB / PCI-E.
I always thought that this is what a generic x86_64 installer does, scanning/probing busses. So we would only miss stuff like fan controllers, LED's, buttons, and other GPIO, I2C and SPI stuff.
What is so different between the Synology x86 Hardware and a normal x86 PC?

Looks like a generic target that you can build a Debian kernel.

./arch/x86/configs/x86_64_defconfig

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

Hello,

I currently have a DS415+ laying around (x86_64, Intel Atom C2538) and was asking myself the same question. Would be quite useful running debian on it and adding functionality, to use it for example as a "better" backup server (and mainly for full disk encryption, which is not yet supported by DSM).

Is the missing device tree still a reason for the project to be abandoned or are there other things that could be tried? I'd be willing to test thing around and get serial logs if needed (But I too have only few knowledge in the field of embedded systems)

Radm,

I think for x86_64 it is generally not needed ot have device tree. You could just boot the kernel. But I'm not familiar with the x86 kernel, so will let others chime in.

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

debi-718 Wrote:
-------------------------------------------------------
> When the serial connection is established (e.g.
> screen /dev/ttyUSB0 115200), power on the device,
> press ESC immediately and continue up to one
> minute until the EFI bootmanager opens.

I finally took the time to attach the DS415+ to UART (3 pins) serial myself, but the farthest I came was interrupting to some GRUB bootlader with ctrl+c. No thing like a bios or uefi ever showed up, also pressing ESC did nothing. Is there anything else to consider or that I can do? (Or maybe the boot process differs from 415+ to 718+?)

Normal boot log:

Press Ctrl-C to enter the menu


Booting SYNOLOGY_2 in 2 seconds...
Booting SYNOLOGY_2 in 1 seconds...

  Booting 'SYNOLOGY_2'

root (hd0,1)
 Filesystem type is fat, partition type 0x83
cksum /grub_cksum.syno

   [/zimage] ck��m success.
   [/rd.gz] cksum uccess.
vender /vender show
            MAC1: xxx
            MAC2: xxx
            MAC3: Empty or Invalid checksum (Random: 0000000c0008)
            MAC4: Empty or Invalid checksum (Random: 0000000c0009)
          Serial: xxx
   Custom Serial: Empty or Invalid checksum
kernel /zImage root=/dev/md0 ihd_num=4 netif_num=2 HddHotplug=1 pwrctl_pin=N075
4 SataPortMap=422 DiskIdxMap=020006 syno_hw_version=DS415+
Trying to allocate 723 pages for VMLINUZ
Got pages at 0x7820b000
[Linux-EFI, setup=0x10cc, size=0x2d2520]
initrd /rd.gz
   [Initrd, addr=0x7e15a000, size=0x5c3794]

[    0.000000] Initializing cgroup sub��s cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.105 (root@build3) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #25556 SMP Thu Mar 18 12:57:43 CST 2021
[    0.000000] Command line: root=/dev/md0 ihd_num=4 netif_num=2 HddHotplug=1 pwrctl_pin=N0754 SataPortMap=422 DiskIdxMap=020006 syno_hw_version=DS415+ 
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000] e820: BIOS-provided physical RAM map:
...
...

When interrupted:

    GNU GRUB  version 0.97  (540K lower / 2074236K upper memory)

 +-------------------------------------------------------------------------+
 | SYNOLOGY_1                                                |
 | SYNOLOGY_2                                                |
 |                                                                         |
 |                                                                         |
 |                                                                         |
                                                                           |
 |                                                                         |
                                                                           |
 |                                                                         |
 |                                                                         |
                                                                           |
 |                                                                         |  
 +-------------------------------------------------------------------------+
      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the
      commands before booting, 'a' to modify the kernel arguments
      before booting, or 'c' for a command-line.

Edited 3 time(s). Last edit at 02/07/2023 07:22AM by Radm.

For me the screen with the Synology boot entries looks fine. Probably your device has a different mainboard and a different bios which respond to a different key sequence for EFI bootmanager. Have you tried others like F2, F8, F12 e.g. when ESC is not working? Does the serial console display any hint during the early startup?

Second point, have you prepared a USB stick which can be selected from the bootmanager as an alternative?

I had a quick look at the DS718+ on the web and it is just an x86 machine that boots the operating system from a Disk On Module (DOM) which is just a sort of internal USB drive.

https://www.techpowerup.com/review/synology-ds718plus/5.html

This is quite similar how QNAP has setup their x86 NAS boxes. The DOM is in general only a few hundred MB and not big enough to hold a full Debian installation. I've installed OpenWRT on a couple QNAP nas boxes by overwriting the DOM however this does mean that there is no easy way to go back to stock firmware.

One thing you could try is to remove the DOM and see if it will boot from a normal USB drive. That way you can see if you can get Debian to work from the normal USB drive and always have the option to go back to stock firmware by plugging the DOM module back into the motherboard.

It took a long time to find time, energy and new ideas to start another attempt to run Debian on Synology DS718+. But now I was successful and Debian 11.6 is running.

This is what I have done the last days:

1. mount problems during initial booting resolved
bind- and move-mounts are disabled somewhere in Synology's 4.4.59+ kernel. They are used for mounting the target filesystem on the initramfs.

Solution: build a 4.4.60+ kernel without modifications from Synology

2. Update the toolchain for building the kernel
This was not really necessary as it turns out that the old toolchain is not the big problem. However for future activities (e.g. update the kernel to a modern version) this might be helpful. I have built and used crosstool-ng 1.20 with the following libs:

• glibc 2.25
• binutils 2.25
• gcc 4.9.1 (unchanged)

3. Improved the installation of Debian as proposed by bodhi here in this thread

• base system installed using debootstrap
• build deb-packages of kernel and intrd for automatic installation
• used vmlinuz and intrd from this step in grub

Many thanks for help.

Currently Debian 11.6 with kernel 4.4.60+ is running. But there is still a lot to do (optimize kernel-config, shrink kernel and initrd, sata drives not recognized (only USB drives), LEDs, fan control ...). I will share configs and binaries as soon as they are presentable.

Thanks to all here for help and motivation to continue.



Edited 2 time(s). Last edit at 02/18/2023 11:39PM by debi-718.

debi-718,

> It took a long time to find time, energy and new
> ideas to start another attempt to run Debian on
> Synology DS718+. But now I was successful and
> Debian 11.6 is running.

Congrats!

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

The really good news is that it is possible to build and run the latest 5.10 Debian kernel on DS718+ using latest gcc and binutils. No toolchain is required. I discovered this possibility only by chance when I started my last created kernel on the diskstation and noticed the first line of the terminal output similar to

[    0.000000] Linux version 5.10.158-rt77 (xxxx@naiad) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #3 SMP Tue Feb 21 13:22:28 CET 2023

This kernel was built with latest build environment from my workstation, not with my special toolchain. What I wanted to do was to build the latest Debian kernel with this toolchain from crosstool-ng but I had misconfigured environment variables so that this toolchain was not used at all. Instead the usual gcc and all the other tools from my local Debian bullseye installation were used and I built successfully the latest Debian kernel with kernel config from their download sites. This manually built kernel is runnable on DS718+.

So the situation is this: it is still not possible to start the pristine debian installer (5.10) on the diskstation. But you can

• build the latest kernel on amd64 by hand
• install the Debian kernel packages into a bullseye installation (debootstrap)
• prepare a USB stick with grub and vmlinuz / initrd
• a second USB stick (or partition) containing bullseye installation
• run kernel and this installation successfully on DS718+

I haven't understood the technical difference between my own kernel and those from the official Debian sites but I am really happy that things are running this way :-)

What you get for now is

chopin login: root
Password: 
Linux chopin 5.10.158-rt77 #3 SMP Tue Feb 21 13:22:28 CET 2023 x86_64

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Feb 21 15:25:44 CET 2023 on ttyS2
root@chopin:~# uname -a
Linux chopin 5.10.158-rt77 #3 SMP Tue Feb 21 13:22:28 CET 2023 x86_64 GNU/Linux
root@chopin:~# cat /etc/debian_version 
11.6
root@chopin:~# dmidecode -t 2
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0002, DMI type 2, 17 bytes
Base Board Information
        Manufacturer: Synology
        Product Name: DS718+
        Version: 1.0
        Serial Number: 123456789
        Asset Tag: Type2 - Board Asset Tag
        Features:
                Board is a hosting board
                Board is replaceable
        Location In Chassis: Type2 - Board Chassis Location
        Chassis Handle: 0x0003
        Type: Motherboard
        Contained Object Handles: 0

What is currently not available are SATA disks. For me the problem is as follows: SATA disks remain powered off when the device is switched on. There is no sound from spinning disks. In BIOS I could not find a setting to switch them on. In fact they remain unknown in BIOS. The Synology kernel powers them on during boot and makes them as devices available. This feature is currently not available in Debian's kernel code, it seems to be done in Synology's kernel enhancements (4.4.59+) because their grub.cfg contains kernel parameters like 'syno_hdd_enable'. If you remove this one, the diskstation remains without SATA drives as well. Probably we need some kernel code as a patch to kernel.org sources.

> But now I was successful and Debian 11.6 is running.

That's some good news, congrats!


I'm unfortunately still stuck on getting it to boot something else

>Have you tried others like F2, F8, F12 e.g. when ESC is not working? Does the serial console display any hint during the early startup? Does the serial console display any hint during the early startup? Second point, have you prepared a USB stick which can be selected from the bootmanager as an alternative?

The first thing I ever see on the DS415+ is the boot log as posted before, nothing before the "Press Ctrl-C to enter the menu" line - no matter what I press. I didn't manage to build a custom boot partition yet, like with the mkbuild script you mentioned, but this might be different now with your recent findings.

Any other idea maybe regarding bios/uefi?

> I had a quick look at the DS718+ on the web and it is just an x86 machine that boots the operating system from a Disk On Module (DOM) which is just a sort of internal USB drive.

After disconnecting it, there is no output at all when powering on. The console clears and the DS just keeps blinking. But the DOM is interesting - since it looks like a generic USB storage device (ps2251-69 chip) I'm wondering, is it possible to just connect the pins to a USB 2.0 header and read out the content? The pin connector is slightly smaller than the one on an usual mainboard and I couldn't find any pinout description. But that probably won't help out much with the BIOS issue.

In the attachments you find a picture of the DOM and connector
Ps. like you mentioned OpenWRT - that was also something I wanted to try out somewhen

Two points I have for you.

For reading the content of the USB-DOM it is not necessary to attach it to another box. You can start the Synology-OS and can usually find two devices under /dev/synoboot 1 and 2 which provide access to the dom partitions. Then dd these devices to a file, copy them to another box and mount them. Then you can see the content.

But I think the most important step for you is to find the EFI bootloader. If testing the usual break keys doesn't work, try to find on the Synology OS level any hint, what kind of BIOS is used. Perhaps you can install tools like lspci or lshw which can help to find information regarding BIOS. The DS718+ uses some InsydeH2O BIOS and I could find a good matching documentation where the break key is mentioned. Without access to the EFI bootloader there will be no possibility to change something.



Edited 1 time(s). Last edit at 02/23/2023 02:19PM by debi-718.

And yes, removing the DOM should put focus on another usb boot device. If you prepare a usb stick - don't use the above mentioned scripts, it's much more easy with grub-install - this one should get selected. Usually the front port is enabled for booting, the ports on the back side not.

I checked today on my DS718+, you can find BIOS informations with this commands

# cat /sys/class/dmi/id/bios_version 
M.231
# cat /sys/class/dmi/id/bios_vendor 
INSYDE Corp.

Also /var/log/messages can contain informations regarding BIOS.

Thank you for the hints

The bios seems to be an older version of the same type

# cat /sys/class/dmi/id/bios_version 
M.012
# cat /sys/class/dmi/id/bios_vendor 
INSYDE Corp.

Also the efivars at

/sys/firmware/efi/vars/

seem to look normal and indicate to be able to boot from USB, DVD or Network. But I can't interpret all the data values correcty.


I was also able to dump the DOM as you mentioned and I tested something: Dumped /dev/synoboot to an image and restored it to an USB stick with dd.

dd if=/dev/synoboot of=/synoboot.img
dd if=/synoboot.img of=/dev/sdg

Then I removed the DOM and tried booting only with the USB stick attached - which should contain the same partitions now. But still, no output and no boot, only blinking blue light. Strange.
Tried the USB ports on the back and an Ubuntu installer stick, but still with the same result.


Now I've tried editing a file on the synoboot1 partition and might have broken something since it doesn't boot there either, but I've backed up the image before.

The stick should have a GPT partition table and an EFI partition containg the files. It's better not to modify the DOM files because they are using checksums.

@Radm, please open a separate thread for posts regarding DS415+. We must avoid confusion and help others to better find their information.

Concerning the DS718+ I have got SATA drives recognized now for kernel 5.10.158. It turns out that the administration of these disks is partially controlled by Synology enhancements, power-on, standby, power-off ... The task is to port the code from kernel 4.4.59+ to the new kernel (in my case 5.10.158+). A couple of files are involved and the main task is to control GPIOs properly.

I am not sure if we should walk this way because at the end we must port all Synology enhancements for all requested devices manually to the new kernel base. This has to be done each time a new kernel is requested. And furthermore we must discuss if all their code is covered by a license which permits to publish the results.

The second possibility is to go on with kernel 4.4.59+ and use a modern Debian OS. This seems possible. Finally I have found the code in kernel 4.4.59+ which disables the above discussed mounts. Here is the simple and small fix for the problem which blocked me so long.

--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2391,18 +2391,10 @@ long do_mount(const char *dev_name, const char __user *dir_name,
        if (flags & MS_REMOUNT)
                retval = do_remount(&path, flags & ~MS_REMOUNT, mnt_flags,
                                    data_page);
-#ifdef MY_ABC_HERE
-       else if ((flags & MS_BIND) && ramdisk_check_failed)
-               retval = -EPERM;
-#endif  
        else if (flags & MS_BIND)
                retval = do_loopback(&path, dev_name, flags & MS_REC);
        else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
                retval = do_change_type(&path, flags);
-#ifdef MY_ABC_HERE
-       else if ((flags & MS_MOVE) && ramdisk_check_failed)
-               retval = -EPERM;
-#endif  
        else if (flags & MS_MOVE)
                retval = do_move_mount(&path, dev_name);
        else

Behind the scenes they checked if initrd was signed by Synology and if not - as in my case - an error is returned for move- and bind-mounts.

So the present situation with kernel 4.4.59+ is that a Debian 11.6 installation is started. There are some minor problems which I expect to resolve soon. At the end good hardware support should result and a modern Debian system with an older kernel.

Oh wow great progress! Congrats @debi-718

Quote
Concerning the DS718+ I have got SATA drives recognized now for kernel 5.10.158. It turns out that the administration of these disks is partially controlled by Synology enhancements, power-on, standby, power-off ... The task is to port the code from kernel 4.4.59+ to the new kernel (in my case 5.10.158+). A couple of files are involved and the main task is to control GPIOs properly.

I am not sure if we should walk this way because at the end we must port all Synology enhancements for all requested devices manually to the new kernel base. This has to be done each time a new kernel is requested. And furthermore we must discuss if all their code is covered by a license which permits to publish the results.

I used (abused) Github Actions to build custom OpenWRT Kernels and used GitHub Pages as opkg repo, you could do the same for apt. As already said checking the licence would be important.
This way we could just provide a apt repo with the patched Kernel.

So I decided not to stay with Synology's 4.4.59+ but porting the important changes from there to (in my case) 5.10.158+. There is no advantage in sticking with the old kernel. Much of the hardware support from Synology for 4.4.59+ (LED, Fan) is hidden inside a device called "synobios" which is closed source. So we won't get these information from their published sources. There is 10 year old code available from times when this synobios was still opensource and I found there some commands which can still be used for DS718+.

Checkout this cool page:
synobios and ttyS1

# make power led blinking
printf  "\\x35" > /dev/ttyS1
# switch power led on
printf  "\\x34" > /dev/ttyS1
# switch power led off
printf  "\\x36" > /dev/ttyS1

# make status led blinking
printf  "\\x39" > /dev/ttyS1
# make status led "breathing"
printf  "\\x3D" > /dev/ttyS1
# switch status led on
printf  "\\x38" > /dev/ttyS1
# switch status led off
printf  "\\x37" > /dev/ttyS1

# set fan speed "25" (allowed values V00 - V99)
printf "V25" > /dev/ttyS1

These are working commands I have found so far. It is possible now to setup a basic fan control to regulate the temperature inside the box. I have not found a command yet to read the fan speed and perhaps it is not available for this device.

The CPU temperature comes from lm-sensors

sensors
acpitz-acpi-0
Adapter: ACPI interface
temp1:        +32.0°C  (crit = +125.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +32.0°C  (high = +105.0°C, crit = +105.0°C)
Core 0:        +30.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:        +30.0°C  (high = +105.0°C, crit = +105.0°C)
Core 2:        +32.0°C  (high = +105.0°C, crit = +105.0°C)
Core 3:        +32.0°C  (high = +105.0°C, crit = +105.0°C)

and disk temperature from smartmontools:

smartctl -d sat -T permissive -l scttempsts /dev/sda | grep Current
Current Temperature:                    28 Celsius
smartctl -d sat -T permissive -l scttempsts /dev/sdb | grep Current
Current Temperature:                    29 Celsius

So the very important next step for me is to write a simple temperature regulator which reads this values and adjusts the fan speed accordingly. Otherwise hardware is not protected.

My device is running now with the above mentiones 5.10.158+ and Debian 11.6. What is needed to make this working?

• Synology code for SATA control
• Synology kernel config parameters (used to compile Synology's enhancements)
• sources from kernel.org
• a standard linux build environment (i.e. no proprietary toolchain)
• a rootfs created with debootstrap (-> initrd)
• an USB stick with grub bootloader (see posts at the beginning of this thread)
• serial console connection to the device

It should be mentioned that all this information is valid only for DS718+. Steps for any other Synology device my be different.

The question still to answer is: Can we publish code from Synology here which has to be included in patches for SATA support? I have to delve deeper into this. Then I can make available more resources. So far here the boot log.



Edited 1 time(s). Last edit at 03/19/2023 05:16AM by debi-718.

debi-718 Wrote:
-------------------------------------------------------

> The question still to answer is: Can we publish
> code from Synology here which has to be included
> in patches for SATA support? I have to delve
> deeper into this. Then I can make available more
> resources. So far here the boot log.

Hi, may you send me a DM to valentijn.venus [at] gmail.com

cheers