Wireless NIC

Wired NIC

Doesn't work, no driver in the feeds. You'll need to install a couple of patches to get the via-velocity driver to work in big-endian mode, actually. One patch set patches the driver, the other exports a symbol in the kernel that's needed in order to load the via-velocity driver as a module. Once both are added, you'll need to edit the defconfig file to specify that you want the velocity driver built as a module. Build a new kernel, flash the new kernel (the kernel build and flash are only required once, in order to ensure that the kernel is exporting the symbol that the module needs). Then install the kernel-module you built. Note that there are a couple of parameters you might like to pass into the via-velocity module (I use the "options" statement in the /etc/modprobe.d/eth0 file). The first choice is a compromise between taking a hit for 7 unaligned accesses per IP frame received, versus a memory copy of each IP frame to align it. I've opted to align it, add the flag "IP_byte_align=1". The other is an annoyance. If the interrupt handler gets too many frames stacked up, it complains by logging a message to the console. Adding the flag "int_works=64" minimizes the chatter. I've only seen it do this when under extreme load -- NFS copy to and and NFS copy from happening simultaneously. And despite the complaints printed to the console, the NFS transfers completed without error.

1. Wow. Almost there. We need to tell the system how to boot up. This is done with the fconfig command. You'll have to check on how to execute this command yourself -- the author didn't take good notes when he performed this step. But here's what the boot script looks like: fis load kernel -b 0x00600000, and the next line is exec -c "root=/dev/mtdblock2 rootfstype=jffs2 rtc-pcf8563.probe=0,0x51 noirqdebug console=ttyS0,115200n8 init=/linuxrc" (that last line may wrap on your display, but the entire "exec" line is a single command line). NOTE: if you want to test it, but don't care to change the boot script just now, you can just type those commands into Redboot. Go ahead...

• OpenSlug 3.10 and the DSM-G600 RevA only

NOTE: The currently-selling model is the RevB -- this more recent model is based on the MIPS chip. This article is specific to the RevA device.

The DSM-G600 RevA device is an ARM-based device, similar to the NSLU-2 -- except that it has double the flash, double the RAM, a gigabit network interface, a wireless network card, and an internal IDE port. When I stumbled across one of the older RevA units on a recent business trip (in Detroit, of all places), I snapped one up -- for $130 USD, how could one go wrong?

1. Obtain serial access. Inside the unit is a spot for a 10-pin (2-row) header; the pinout is the same as that for the old PC XT style serial ports. See the links on DSMG600.HomePage to figure out where you need to solder...
2. Save a copy of your flash. See the info on the DS101.HomePage for a technique that should work on the DSM-G600 as well. Hint: if at this step, you have the urge to burn a copy of the saved flash to CD, and lock the CD away in a bank safe-deposit box, then perhaps you shouldn't be doing this at all. The author has never attempted to put the original flash data back in place, for all he knows, this step may be a total waste of time!

LEDs and Buttons

They don't work. You'll need to install some patches, and build a new kernel. As of this writing, the patches provide support for the POWER and WLAN LEDs only, the RESET button works as it does on the slug (meaning instant power-off), and there is experimental support for the POWER button (hold it depressed for 2 - 3 seconds to trigger a controlled shutdown and power-off). You'll have to build a new kernel, and reflash the kernel as you did originally (no root filesystem changes to enable the LEDs and buttons, so you don't need to reflash that.

Installing OpenSlug 3.10 on the DSM-G600

This article pertains to:

• OpenSlug 3.10 and the DSM-G600 RevA? only

(:table border=0 width=100% bgcolor=#ffdddd:) (:cell:) This article is intended for advanced users! If you are not willing to risk "bricking" your DSM-G600, then DO NOT attempt this. Do this at your own risk.

(:tableend:)

NOTE: The currently-selling model is the RevB? -- this more recent model is based on the MIPS chip. This article is specific to the RevA? device.

The DSM-G600 RevA? device is an ARM-based device, similar to the NSLU-2 -- except that it has double the flash, double the RAM, a gigabit network interface, a wireless network card, and an internal IDE port. When I stumbled across one of the old RevA? units on a recent business trip (in Detroit, of all places), I snapped one up -- for $130 USD, how could one go wrong?

Once you start working with the device, you'll discover that it has some quirks. First and foremost -- you can't do anything without a serial port. It lacks the Redboot upgrade mode that we love so much on the NSLU2 -- and even worse than that, Redboot on the device cannot drive either the wireless NIC or the built-in NIC! So, firmware needs to be loaded via the "xmodem" protocol on the console.

1. Obtain serial access. Inside the unit is a spot for a 10-pin (2-row) header; the pinout is the same as that for the old PC XT style serial ports. See the links on http://www.nslu2-linux.org/wiki/DSMG600/HomePage to figure out where you need to solder...
2. Save a copy of your flash. See the info on the http://www.nslu2-linux.org/wiki/DS101/HomePage for a technique that should work on the DSM-G600 as well. Hint: if at this step, you have the urge to burn a copy of the saved flash to CD, and lock the CD away in a bank safe-deposit box, then perhaps you shouldn't be doing this at all. The author has never attempted to put the original flash data back in place, for all he knows, this step may be a total waste of time!
3. Build yourself a kernel. Fetch the source image for OpenSlug 3.10, and set up the build tree. Type "make openslug-image", and go have dinner, watch some TV, read email, or whatever -- until it's done. Inside the "deploy/images" directory, you'll find a bunch of files. You'll need the "zImage-dsmg600be" file (the kernel) and the "openslug-nslu2-*.rootfs.jffs2" file (the jffs flash filesystem).
4. Do a trial boot of the kernel. Restart the DSM-G600, and hit <ctrl-c> as soon as Redboot starts. At the Redboot prompt, enter load -m xmodem -r -b 0x00600000 -- then fire up the xmodem send on your terminal emulator (<ctrl-A><S> on minicom) and upload the "zImage-dsmg600be" file.
5. After it's loaded, you need to boot it. Enter exec -c "root=/dev/mtdblock2 rootfstype=jffs2 rtc-pcf8563.probe=0,0x51 \ noirqdebug console=ttyS0,115200n8 init=/linuxrc"
6. It should begin booting -- it'll lock up because it has no root filesystem, but take a look at the boot output, and verify that it looks pretty reasonable. Because at this point, we've reached the point of no return: we start reflashing the device.
7. Flash the kernel. WARNING WARNING WARNING! This is like walking a footbridge with no handrails -- one mistake - just one digit wrong - and you can render your DSM-G600 useless! Flash over part of Redboot, and the game's up - it's time to figure out how to make JTAG work on the DSM-G600! Now -- are you SURE that you wouldn't rather install the latest D-Link firmware, and use it that way? Ok, if you are really set to do this: Go back to Redboot, and load in the kernel with xmodem as you did earlier. But instead of executing it, write it to the flash: fis write -f 0x50040000 -b 0x00600000 -l 1029080 NOTE: Replace the value "1029080" with the actual size of your kernel image; in most cases Redboot will automatically round up to the 1.0 MB size, but the DSM-G600 has flash space for up to 2MB of kernel image. It's best not to assume that your kernel will always be 1MB in size.
8. Ok, great. Now we're still in the same place we were earlier -- we can boot the new kernel, but we don't have a filesystem to boot from. Let's add one, using xmodem again (note the different address): load -m xmodem -r -b 0x00b00000 and fire up your xmodem send mechanism, and send the "openslug-nslu2-*.rootfs.jffs2" file. That'll take a while.
9. You could just flash the filesystem, but the jffs2 driver expects the filesystem flash not actually containing data to be erased -- so we need to erase that area of the flash, and then we can flash the filesystem. It is also important that we know the exact size of the jffs image, and flash only that size. So armed with that information: fis erase -f 0x50240000 -l 0x00600000 followed by fix write -f 0x50240000 -b 0x00b00000 -l 5111808 Again, replace the value "5111808" with the actual decimal size in bytes of the "openslug-nslu2-*.rootfs.jffs2" file.
10. Wow. Almost there. We need to tell the system how to boot up. This is done with the fcconfig command. You'll have to check on how to execute this command yourself -- the author didn't take good notes when he performed this step. But here's what the boot script looks like: fis load kernel -b 0x00600000, and the next line is exec -c "root=/dev/mtdblock2 rootfstype=jffs2 rtc-pcf8563.probe=0,0x51 noirqdebug console=ttyS0,115200n8 init=/linuxrc" (that last line may wrap on your display, but the entire "exec" line is a single command line). NOTE: if you want to test it, but don't care to change the boot script just now, you can just type those commands into Redboot. Go ahead...
11. Reboot. Just type "reset" at the Redboot prompt, and watch it boot. It should boot up to a login prompt (it has no NSLU2 sysconf data, so it'll call itself "brokenslug"). Congratulations. You're running OpenSlug on the DSM-G600.

LEDs? and Buttons

They don't work. You'll need to install some patches, and build a new kernel. As of this writing, the patches provide support for the POWER and WLAN LEDs? only, the RESET button works as it does on the slug (meaning instant power-off), and there is experimental support for the POWER button (hold it depressed for 2 - 3 seconds to trigger a controlled shutdown and power-off). You'll have to build a new kernel, and reflash the kernel as you did originally (no root filesystem changes to enable the LEDs? and buttons, so you don't need to reflash that.

Wireless NIC support

Install the madwifi-ng package. The dependency list is incomplete, so don't forget to manually install the wireless-tools package. This should get the wireless NIC working, at least in no security or WEP mode. I've not tested with any stronger security.

Wired NIC support

Doesn't work, no driver in the feeds. You'll need to install a couple of patches to get the via-velocity driver to work in big-endian mode, actually. One patch set patches the driver, the other exports a symbol in the kernel that's needed in order to load the via-velocity driver as a module. Once both are added, you'll need to edit the defconfig file to specify that you want the velocity driver built as a module. Build a new kernel, flash the new kernel. Then install the kernel-module you built. Note that there are a couple of parameters you might like to pass into the via-velocity module (I use the "options" statement in the /etc/modprobe.d/eth0 file). The first choice is a compromise between taking a hit for 7 unaligned accesses per IP frame received, versus a memory copy of each IP frame to align it. I've opted to align it, add the flag "IP_byte_align=1". The other is an annoyance. If the interrupt handler gets too many frames stacked up, it complains by logging a message to the console. Adding the flag "int_works=64" minimizes the chatter. I've only seen it do this when under extreme load -- NFS copy to and and NFS copy from happening simultaneously. And despite the complaints printed to the console, the NFS transfers completed without error.

Have fun!