Running debian on a nas dongle [updated]

I used a nas dongle from ARP for a while to share an USB harddisk, and I always wondered about what’s inside. It’s a nifty little device that works reasonably well. It needed a reboot from time to time, and it had some issues with the filesystem. Because of the FAT filesystem it couldn’t store large files, but what I missed most was ssh. Not ssh itself, but scp, sftp and rsync. I knew that without further information it would be impossible to add these. But so far I couldn’t find out anything on the internet. Then somehow I found a blog post with a device that looked similar from the outside but was sold more like a hacker device. So I went to figure out if it’s the same. It looked similar from the inside as well. So, it is probably really a bifferboard. The pins for the serial console matched, which was even more proof…

The boot messages with the stock firmware look like this:  $ minicom -b 115200 -D /dev/ttyUSB0

-=========================================-

Boot Loader [LOADER32 1.15]
Press <ESC> to enter extra mode
-=========================================-
SB PCI reg 0x48 = 00078006
Active to LAN Disk.
CPU ID: 0x32
Default MAC: 00:0B:B4:00:00:01
Initialize MAC & PHY…ETH: RJ45 not found!
OK.
Default IP: 169.254.0.1

Boot the kernel from 0x00F51000 …

==========================================
CodeTek R32XX [NET Disk] R3282-1.34c
Hardware Version : 1007 Speed 150MHz
==========================================
System running!….
HTTPS_Task(): HTTPS Initial done, port 80.
Line print server listening at port 515…
SEARCH_Task(): SEARCH Initial done.
Wait IDE device ready…
<UPNP> UPNPAV is UP.
CMD>ITUNES_Task: Initial done.
SOAP_Task(): SOAP Initial done.
device C:PUBLIC not found!
<FTPS> create C:PUBLIC folder fail! -1021
SMB_Task(): SMB Initial done.
DHCPC: discovery 3 times, Enter AUTO IP Mode.
DHCPS_Start: Enable DHCP Server!

Setting up the rootfs was straight forward, but it turns out, that flashing the kernel is not as easy as described here. For that to work, it would need to have the biffboot loader on it. Looks like the bootloaded can only be changed with a jtag cable, which unfortunately I don’t have. Looks like this guy had the same problem. Trying to modify bb_upload.py to make use of the “extra mode” of the default boot loader didn’t work out.

Browsing the pages I found a description on how to use i2c on a bifferboard using debian. So, an upcoming project might be to hook up one of my barometric pressure sensors to the board.

But first, I have to get my hands on a jtag cable… At least, now I know what’s under the hood.

Update Oct 4 2011:

First I ordered one of the few JTAG cables that I found in Switzerland, which was an Altera Byte Blaster. After discovering how easy the work with ICSP cables ist just lately, I assumed it would be the same with JTAG.I tried and tried to flash the biffboot loader onto my device but it didn’t work. I didn’t know that most chips have different protocols, and that the jtag program has to have a description file for each of them. For the chip in question, I didn’t find such a driver on the internet.

Biff explained to me that it took him ages to reverse engineer that protocol, and that’s why he sells his biffjtag program instead of opensourcing it. His program only works with parallel port jtag cables connected to a physical parallel port (not connected through USB) as he writes directly to the default hardware address. So, I ordered a cable from the UK.

The most difficult part was to find a computer which still has a parallel port. A co-worker switched his computer and before he disposed the old one, I could quickly grab it to flash my boot loader during the lunch break. Back home, I flashed the debian kernel with the serial cable and running the python script with the tftp server. The prepared rootfs on the USB stick worked flawlessly. But upgrading it from lenny to squeeze took a long long time on a device with 150 MHz and 32MB RAM

Next, I wanted to connect an RFID reader with serial TTL output to the uart pins of the bifferboard. More on why in a subsequent post. I thought I could just ssh into the bifferboard and run “minicom -b 9600 -D /dev/ttyS0” to see something from the RFID reader. But minicom stays quiet. Also, this doesn’t look too promising :
bifferboard:~# dmesg | grep tty
bifferboard:~# ls /dev/ttyS*
/dev/ttyS0  /dev/ttyS1    /dev/ttyS2  /dev/ttyS3

I started guessing, and changed the kernel commandline in the bootloader to the following:
console=no root=/dev/sda1 rootwait

Now, the kernel output didn’t come to the serial terminal anymore, but the login prompt still appeared. The following looks a bit more promising, but the link still didn’t work the way I want:
bifferboard:~# dmesg | grep tty
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

So I went ahead and edited /etc/inittab , commenting out the bottom line that reads:
T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100

With this change, also the logon prompt no longer appeard on the serial console. And now, I saw the data coming from the RFID reader.