DSM-G600, DNS-3xx and NSA-220 Hack Forum

I tried to reload D-Link's linux-2.6.6 (i.e. the original sources, compiled myself). I was thinking about trying a vanilla 2.6.20.3, but I have no idea what to chose as "ARM System Type"... Any ideas?

sala wrote:

But for now, maybe you can use D-Link compiled kernel. To do so you must extract kernel from firmware image or from flash, then cut out u-boot part and finally gunzip compressed kernel image.

Nice idea. One could try to reboot the original kernel from ROM, but with a different initrd.

Very nice
Now you can boot operation system (debian) from hard disk.

fonz wrote:

I wonder, how much interest there actually is in replacing the whole D-Link software?

I am VERY interested in replacing the whole D-Link software, I think it is the only way we can realize the full potential of the DNS-323.  I think the DNS-323 is really good hardware, but the D-Link provide software doesn't give the features I would expect, even for it's designed use case as a Network-Attached-Storage device.

IMHO here a a few of the poorly implemented features in the D-Link firmware (v1.02b USA)
- does not keep accurate time or accurate time zone rules
- does not have a journaling file system
- does not identify/report hard disk problems
- does not have capability for UPS power protection (more critical feature given no journaling)
- does no use the latest version of samba

I think all these problem can be overcome with better software.  The chroot-debian is a possible solution; however, I think there are still problems in the D-Link kernel that would not be fixed by chroot. 
For example the #cat /proc/uptime has some very large values, and #cat /proc/stats | grep btime gives an unusually small value
I think this is an indication that something is fundamentally wrong with the the code in the time functions in the D-Link provided kernel, a chroot-debian still gives bad information for uptime because it uses the /proc/... entries from the D-Link kernel.

I am VERY excited about the reloader.ko module you have produced.  This give us a way to boot to a different kernel without having to re-flash the firmware (and risk bricking the unit) .

I have a Kurobox (www.kurobox.com) which uses this same "rebooter" technique.  Buffalo Technologies (the manufacture) shipped a 2.4 monte-vista kernel and I can "reboot" a 2.6 Fedora Core 4 kernel.  There were a lot of very talented people on the kurobox forum who did all the "heavy lifting" to develop this technique and I was able to follow their guidance and compile my own kernel modules for features I wanted.  The current Kurobox has a PPC processor so binary sharing is not possible; however, a new Kurobox-Pro is being released and it uses an ARM processor, so there may be some sharing when development starts for that Kurobox-Pro model.

From my understanding, one of the fundamental differences between how Buffalo Technologies and D-Link implement their NAS design is D-Link keeps the root file system in RAM and Buffalo-Tech has the root file system on disk.  With the root fs in ram a busybox / uclibc  (KISS) solution seems the right choice.  I you are willing to use some of the hard drive(s) for root [/dev/sda1 for root (3GB) and /dev/sda2 for swap (256MB) and /dev/sda3 for /mnt/HD_a2) then a [ Debian | Gentoo | Fedora_Core] / glibc solution could be viable.

I'm in the process of building a serial cable, and plan to try your 'reloader' module after the cable project is complete.

// Mig

fonz wrote:

I also agree that trying some full-blown Linux distro is worth a try. But still, 64MB RAM is not that much, and performance will degrade badly once the box starts swapping.

It's not that bad at all. Look nlsu2 and dsm-g600 with 32mb of ram. Both working quite fine with gentoo (uclibc) and debian. Of course it is not a good idea to run many memory dependent processes like python, apache, php, perl, samba-3 eg.

Here is booted Gentoo on DSM-G600: http://dns323.kood.org/forum/p1523-2007 … html#p1523
As you can see 32mb device still has 25148kb free memory left after plain (kernel+init+network+shell) boot.

someguy wrote:

I came across Embedded Debian (EmDebian) - looks interesting:
http://wiki.debian.org/Embedded_Debian
http://www.emdebian.org/

did you try it or are you going to try it?

I'm currently testing embedded cross linux from scratch (so far i have compiled the basic stuff for armv5te architecture and 926ej-s cpu using the latest gcc).

I've uploaded an updated dns323-reloaded package. This version does better memory allocation, making it much more robust and reliable when memory is low (and it's always low on my box). Sources are available at: www.inreto.de/dns323/reloaded

Note that reloaded modules are included in bobclfs, so this is for those who want to experiment with their own kernels and root file systems. Have fun.

OE and buildroot have useful patches, I'm using them for quite a while now. I'm not using their toolchains, though, but CLFS-E.
I also think that pivot_root is the wrong approach for booting - having your system on disk prevents spin-down. I'm booting into an initramfs with pkgsrc/optware-style extras on disk. That way background tasks can run without disk access.

Nobody was brave enough to reflash yet, which is not a problem, since the kernel loader works fine and pretty reliable.

Compiling packages is not the problem - providing the device-specific bits is more work...

Paul wrote:

I've downloaded the reloaded fsck Package (http://www.inreto.de/dns323/fsck/), and when I'm executing the reload.sh it all works. It's running the 2.6.12.6-arm1_huge Kernel...

Good.

Paul wrote:

So I've compiled the original linux kernel without any modifications, copied the zImage over and executed the reload.sh with my own kernel (same initramfs!). And there was no response from the dlink... not even the network was configured ?!

Do you have a serial connection? First thing would be to check if the kernel boots at all and prints messages on the serial link. But I guess it's doing so.

More likely is that your kernel config is not compatible with the s-initramfs. I was lazy and instead of configuring the network myself, I used the kernel's autoconfig feature.
The reload.sh script extracts the IP config from ifconfig output and creates a command line parameter for the new kernel (look for IP_CMDLINE in reload.sh). The kernel will configure the network interface using that information only if it has IP autoconfiguration enabled (and the DHCP autoconfig option disabled!).

Alternatively, you can change the ramdisk image (extract, edit etc/rc.d/rc.sysinit, repack).

Or even simpler: use the "opt" feature :-) - which is quite similar to the "fun_plug" feature of the original firmware. The ramdisk will look for /mnt/HD_a2/linux/opt and mount it as /opt (if it exists). Then, if there's a opt/etc/rc.d/rc.optinit script, it will be run. Have a look at /etc/rc.d/rc.sysinit for the details (inside the s-initramfs).