Recent Linux on the D-Link DNS-313
(Last boot 2019-07-14 on kernel v4.19.57 with OpenWRT as rootfs)

D-Link DNS-313

D-Link DNS-313

I have moved the basic use and set-up of the device to the corresponding OpenWrt DNS-313 device page where it is properly maintained by the community. This page is just my own musings and tricks, and a bit of history.

Please use the OpenWrt community releases if you just want to use the DNS-313 with a recent firmware, OpenWrt has excellent support for the device, maintained by me and others.

I highly recommend using the OpenWRT images on this page over any legacy firmware for security reasons and AFAIK the performance is also better in all ways. As it is using OpenWRT, it is very hackable.

Some reference bootlogs:

Pre-cooked harddisk images

There are daily snapshots from OpenWRT available, but these does not currently include a .tar.gz version of the root filesystem which is necessary for the DNS-313.

Rebuilding OpenWrt from source

Follow the generic OpenWrt clone and build procedure:

Compiling the kernel

To compile the kernel you first need a ARMv4 toolchain to build it with, then you need to configure and compile the kernel, and possibly also attach an initramfs.

I use a special gemini.mak makefile that I put in the root of the kernel directory, edit the makefile to select the right DTB then I type:

  make -f gemini.mak config && make -f gemini.mak build
And this will build the whole kernel, attaching an initramfs and a DTB file, and put the resulting zImage in $HOME as well as in /var/lib/tftpboot if it is writeable. You will need the rootfs-gemini.cpio rootfs for this to succeed.

Pre-built kernel images with rootfs

Analyzing the vendor code

Some information could be obtained by plowing through the (messy) vendor code. In drivers/char/g751.c we find:

#define GPIO_SET             2
#define SMBCLK_PIN           16
#define SMBDATA_PIN          15

So it is clear that the G751 temperature sensor is sitting on an emulated SMB (I2C) bus on GPIO lines 15 and 16. But this mocky chardev is actually used for all LED and fan control as well:

#define FAN_SPEED_LOW_PIN    11
#define FAN_SPEED_HIGH_PIN   12

So GPIO lines 11, 12, 13 are used for controlling the fan.

The boot loader code gives other hints. This can be found at dns-313_gpl_v2.01/source/Image/src/sl-boot-64M/src/sys/sys_main.c in the source release:

  #ifdef USB_DEV_MO
  vbus = REG32(SL2312_GPIO_BASE + 0x04)&BIT(17)  ; //read GPIO0[17]->data in 0x04
  vbus = REG32(SL2312_GPIO_BASE + 0x04)&BIT(18)  ; //read GPIO0[17]->data in 0x04
  }       //printf("vbus : %x\n",vbus);
  vbus = 1;

This is a hint that GPIO 17 and 18 is used for VBUS detection.

Further digging in the emac driver gives that GPIO lines 22 and 21 are used for MDIO to the PHY, and the PHY is on address 1 on the MDIO bus. This seems to be the case with almost all SL3512-based NAS things so no big surprise there.

In the initrd.tgz provided with the sources I found a file named /sbin/fan.script which provides the info that the fan should turn on at low speed at 43 degrees celsius and high speed at 47 degrees celsius.

Analyzing the flash contents

This device does not use the flash for the operating system or the root filesystem: it is just 512KiB and way too small to even fit a Linux kernel. Instead, there is a partition with a RedBoot-derived boot loader, and two partitions just named "MTD1" and "MTD2", each containing a (very small) file system.

The RedBoot image contains the MAC address used, at offset 0x1D2F4 thru 0x1D2F9. To be sure we found the right thing, we can check for the string "dns-313" at offset 0x1D204. I came up with this little script for setting the ethernet MAC from the ROM:


if [ -b /dev/mtdblock0 ] ; then
    DEVID=`dd if=/dev/mtdblock0 bs=1 skip=119508 count=7 2>/dev/null`
    MACADDR=`dd if=/dev/mtdblock0 bs=1 skip=119540 count=6 2>/dev/null | hexdump -n6 -e '/1 ":%02X"' | sed s/^://g`
    if [ "x$DEVID" = "xdns-313" ] ; then
         echo "$DEVID ethernet address: $MACADDR"
         ifconfig eth0 hw ether $MACADDR 2>/dev/null
         echo "Unknown firmware revision - can't extract MAC address"
    echo "No MTD device"

The MTD1 and MTD2 partitions turn out to be two copies of the same file system of minix type with the following content:

  # ls -al
  totalt 44
  drwxr-xr-x. 2 root root 1184  2 jan  2000 .
  drwxr-xr-x. 1 root root   28 16 jan 14.16 ..
  -rwxr--r--. 1 root root 1525  4 dec  2008 cacert.pem
  -rwxr--r--. 1 root root 1751  4 dec  2008 cakey.pem
  -rwxr-xr-x. 1 root root   36  4 dec  2008
  -rwxr-xr-x. 1 root root  126  1 jan  1970 ddns.conf
  -rwxr-xr-x. 1 root root  136  1 jan  1970 email.conf
  -rwxr-xr-x. 1 root root   47  1 jan  1970 group
  -rwxr-xr-x. 1 root root   72  3 sep  2007 hosts
  -rwxr-xr-x. 1 root root   15  1 jan  1970 language.conf
  -rwxr-xr-x. 1 root root   25  1 jan  1970 log.conf
  -rwxr-xr-x. 1 root root  242 20 mar  2009 mt-daapd.conf
  -rwxr-xr-x. 1 root root  249  1 jan  1970 mt-daapd.playlist
  -rwxr-xr-x. 1 root root   15  1 jan  1970 mtdversion
  -rw-r--r--. 1 root root    0  1 jan  1970 newftp
  -rwxr-xr-x. 1 root root  146  1 jan  1970 passwd
  -rwxr-xr-x. 1 root root  172  3 sep  2007 pf_param.conf
  -rwxr-xr-x. 1 root root  185 30 sep  2007 pure-ftpd.conf
  -rwxr-xr-x. 1 root root   26  1 jan  1970 quota
  -rwxr-xr-x. 1 root root  302  9 aug  2007
  -rwxr-xr-x. 1 root root   12  1 jan  1970 resolv.conf
  -rwxr-xr-x. 1 root root    2  1 jan  1970 rtc.conf
  -rwxr--r--. 1 root root 3204  4 dec  2008 server.pem
  -rwxrwxrwx. 1 root root  109 26 jul  2007 shadow
  -rwxr-xr-x. 1 root root 1148  6 jul  2008 sib2.conf
  -rwxr-xr-x. 1 root root  760  1 jan  1970 sib_ap.conf
  -rwxr-xr-x. 1 root root 1148 12 jan  2009 sib.conf
  -rw-------. 1 root root  464 27 maj  2009 smb.default
  -rwxr-xr-x. 1 root root    1  1 jan  1970 smbpasswd
  -rwxr-xr-x. 1 root root   89  1 jan  1970 tr069.conf
  -rwxr-xr-x. 1 root root 1320  1 jan  1970 udhcpd.conf
  -rwxr-xr-x. 1 root root 1296  1 jan  1970 udhcpd.conf.def
  -rwxrwxrwx. 1 root root   23 10 feb  2009 upnpav.conf
  -rwxr-xr-x. 1 root root  143 11 mar  2009 upnpscript
  -rwxr-xr-x. 1 root root    0  1 jan  1970 v2.8
  -rw-r--r--. 1 root root    8 30 jul  2009 version2.txt
  -rw-r--r--. 1 root root   37 30 jul  2009 version.txt

Apparently there are just copies of random configuration files in the flash. Other D-Link NAS products seem to have more or less identical configuration files. None of them have very much relevance for running your own OpenWRT instance on the system, it might be that the OpenWRT /etc/config directory should simply be mounted here, so the configuration persists over a reinstall.

As sideband information we see that the product was configured 2007-2008 and someone made the last changes to the configuration in may 2009, which fits nicely with the device being released in 2010.

OLD (more manual) installation procedure:

Kernel TODO