Firmware information

Testing on v1.08 on a C1 DNS-323

The 8MB flash chip is split into 8192 1K blocks, split into 5 sections and assigned to 21 devices.

There are 4 types of firmware devices:

• /dev/mtdX: Raw access
• /dev/mtdblockX: Block device, can be mounted (theoretically) and has random access
• /dev/mtdcharX: Character device, serial access only, read/write from beginning to end
• /dev/mtdrX: Presumed to be raw, read only access

The sections are as follows:

• 0 - 64K - Configuration
• 1 - 64K - Configuration
• 2 - 1,536K - Kernel image
• 3 - 6,336K - Compressed ramdisk image
• 4 - 192K - uboot bootloader image

Every block is represented as one of each of the above device types, EXCEPT /dev/mtdcharX. Details below.

These contain the more volatile configuration files of the firmware. 0 is represented in mtdchar0 and mtdchar1, while 1 is represented in mtdchar1 and mtdchar2.

The behaviour of the block devices is rather odd. One can read and write to them with no problems initially, however, on reboot, problems start to occur. If both blocks are mounted and a file is written to both, the data is not saved. If only one block is mounted, and a file written to it, the data is saved to both blocks. You also need to manually unmount to save the data. I haven't tested for deleting data, or in the case of power loss.

The easiest thing to do is to only deal with 0 as the de-facto configuration block. Never mount or modify 1, and always ensure to unmount after your modifications.

If you want to flash this block with a default.tar.gz file, you could do something like this:

mkdir /sys/default
mount /dev/mtdblock0 /sys/default
cd /sys
tar xzf /mnt/HD_a2/default.tar.gz
umount /dev/mtdblock0
reboot

BRICK WARNING: Using a bad rc.init.sh can brick the device, as this is non-volatile memory you are writing to.

This contains the kernel image that is loaded by the bootloader. It is a standard Linux kernel binary, compiled for ARM. The easiest way to flash the kernel is to do a direct copy from a file:

dd if=/mnt/HD_a2/kernel.bin of=/dev/mtdblock2
reboot

This shouldn't affect running processes, as the kernel is copied into memory on boot. Oh, and BRICK WARNING. You probably won't ever need to do this unless you want to update the core kernel. Drivers etc. can be loaded through .ko files and insmod. The kernel image is also represented in mtdchar4 and mtdchar5.

This is essentially a compressed gzip file called ramdisk_el with a 64-byte header at the beginning. On boot, it is copied to a ramdisk, /dev/ram0, and mounted to the root. It contains all the necessary binaries and libraries to run the system. To work in the device, ramdisk images need to be 6MB or less when compressed, and 10MB exactly when expanded. Note that the compression is not limited to gzip, that is simply the default option specified for D-Link's mkimage program, found in the GPL files. Also specified in mkimage are the processor architecture and OS type, hinting at the possibility for further modification.

To flash the ramdisk, we first need to get our ramdisk image on a computer:

gunzip ramdisk_el.gz
mount ramdisk_el /mnt/ramdisk -o loop
#do modifications now
read x
umount /mnt/ramdisk
gzip ramdisk_el
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00800000 -n Ramdisk -d ramdisk_el.gz uRamdisk

Then we copy the image to the NAS, and:

dd if=/mnt/HD_a2/uRamdisk of=/dev/mtdblock3
reboot

This will permanently modify the firmware image, so BRICK WARNING. For a softer modification, you could try this for the second step:

dd if=/mnt/HD_a2/uRamdisk of/mnt/HD_a2/ramdisk_el.gz skip=64 #This assumes gzip compression etc.
gunzip /mnt/HD_a2/ramdisk_el.gz
killall5
dd if=/mnt/HD_a2/ramdisk_el of=/dev/ram0
/bin/sh /etc/rc.sh

This will affect (i.e. kill) all running processes and effectively reset the system, and isn't a perfect solution, as the program memory is not reset, so environment variables will not be reset. However, if incorporated into a fun_plug, you can effectively run non-standard firmware while entirely removing the risk of bricking the device, as you can restore it by simply removing the drive.

This is usually a binary of u-Boot 1.1.1 compiled for ARM. BRICK WARNING! This is the absolute first thing to be run on pressing the power button, and is completely out of the picture as soon as the kernel is loaded, so don't even think about flashing it unless you have a serial cable handy and are ready to use it.

The main purpose of flashing this section is to modify the kernel options passed. You would do the flashing, quite simply, like this:

dd if=/mnt/HD_a2/u-boot.bin of=/dev/mtdblock4
reboot