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

You don't have to use arch linux kernel at all. And most likely you can't because it does not contain necessary patches to support NSA-220. You need to use zyxel kernel from firmware GPL tarball.

Ingram wrote:

Good point. But does this mean I need to use the exact same kernel version as firmware or can I patch a newer one up? I was unable to chroot arch from debian because of the kernel being too old.

Sure you can but its not all that easy. You can use DNS-323 example target which is already supported in vanilla kernel.
You can also try to downgrade coreutils (and possibly some other packages too) so that chroot would work.

But seriously, it would be easier to use just gentoo or debian linux for whatever you are tring to accomplish with arch

Very nice! Can the ancient bootloader simply boot a 3.17 kernel?

Also if anyone wonders, why I am such a fan of Arch Linux, then it's basically the best of Gentoo and Debian worlds - you get awesome up to date software and for most of the part you don't have to compile it yourself.

Between the time I did this and the time writing, the kernel package has been already updated to [nope]3.17.6[/nope] 3.18 :-)

Alright, as promised, a small walkthrough.

I used the latest Ubuntu - 14.10 to cross compile the kernel first.

Arch Linux has nifty shell scripts which are used to make packages in a standard manner. Since I didn't need a package, just a kernel then I snatched the kernel config file from https://github.com/archlinuxarm/PKGBUIL … inux-armv5

I downloaded the sources from http://www.kernel.org/pub/linux/kernel/ … 7.4.tar.xz and extracted them. The patches seemed to fix stuff that did not concern me, so I did not apply any.

Now we need a cross-compiler. I used a tutorial for RPi for information on cross-compiling. In short

sudo apt-get install gcc-arm-linux-gnueabi make ncurses-dev

export CCPREFIX=arm-linux-gnueabi-

Then I renamed config file to .config and ran

make ARCH=arm CROSS_COMPILE=${CCPREFIX} menuconfig

Then I selected some stuff from there orion5x related, bad memory. For that I post my own config - http://pastebin.com/M30muGf6 - you can diff it against the arch linux one from the repo to see what's different.

Finally to build the stuff needed

make -j5 ARCH=arm CROSS_COMPILE=${CCPREFIX} zImage modules dtbs

Then export the modules somewhere else

mkdir ~/modules
make ARCH=arm CROSS_COMPILE=${CCPREFIX} INSTALL_MOD_PATH=~/modules modules_install

Simple kernel building till now, right? Now it is going to get interesting.

Since the kernel has booting support using dtb files (read these slides), but the bootloader doesn't actually support it, we have to append dtb files to zImage. One for each board for which the dtb was built. One of the config options had to be set for that as well.

cat arch/arm/boot/zImage arch/arm/boot/dts/orion5x-lacie-d2-network.dtb > zImage-orion5x-lacie-d2-network
cat arch/arm/boot/zImage arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dtb > zImage-orion5x-lacie-ethernet-disk-mini-v2
cat arch/arm/boot/zImage arch/arm/boot/dts/orion5x-maxtor-shared-storage-2.dtb > zImage-orion5x-maxtor-shared-storage-2
cat arch/arm/boot/zImage arch/arm/boot/dts/orion5x-rd88f5182-nas.dtb > zImage-orion5x-rd88f5182-nas

Then I snatched the scripts and boot folder from lenny_for_nsa220.zip and placed it on my usb, which was formatted as ext3. I placed the zImages to the boot folder and linked one of them at a time as zImage. The last one, orion reference design seemed to be the only one that did not boot, maxtor shared storage 2 seemed to work the best (explained later).

While we are at it, let's hardcode the root device in boot/reload.sh and change USBDEVICE=$1 to USBDEVICE=/dev/sda1 so that it would be the first hard disk and not the usb.

This should be everything from the USB side.

Finally we have to prepare the hard disk. I formatted the disk as one-partition ext3 and extracted arch linux rootfs on it from http://archlinuxarm.org/developers/downloads

I used http://archlinuxarm.org/os/ArchLinuxARM … est.tar.gz

Once that was on the disk, I added the modules from ~/modules to /usr/lib/modules, but this seemed to have little to no effect as lsmod was pretty much empty after booting.

But now there is nothing other left than just stick the usb and disk to the nsa220 and let it boot.

When I tried, mss2 zImage had one usb working (left one), or at least it detected the thumb drive after init, others with the exception of reference design just booted and detected the hard disk. No networking.

username and pw are root/root.

During the 2 and half years of studying computer science at university, I've learned that there is nothing more fun than blinking LED-s on computers, so we're going to do that next.

echo 17 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
echo 0 > /sys/class/gpio/gpio17/value

This should toggle between the green COPY LED.


If you do not want to compile your own kernel, then 3.17.4 zImages and modules can be found at https://www.dropbox.com/s/fyy1zh8i1j0p8 … ar.gz?dl=0

During booting there are messages of the debian initrd being discarded - might the zImage be too large?

Also after looking the kernel source, I still see board support that is implemented without dtb files, last time I tried any of those, I failed miserably.

Last edited by Ingram (2014-12-08 16:06:03)

Ingram wrote:

I guess this is because of using reloaded.ko as the old driver from 2.6.18 leaves the unit in an unknown state and this might not be reset properly in the newer sources.

Have you seen that the original Lenny stick always booted twice? On the first (cold) boot the stick called reboot, and on the second boot it used reloaded.ko. That was because something didn't work on cold boot, but I can't remember what.

I tried loading the kernel via tftp and then straight booting it. Ethernet is still not quite working (pretty much the same as via reloaded.ko) and the fan won't start spinning. Everything else seems to be the same.