Linkstation 400

Summary
In December 2014 I purchased some Buffalo Linkstation 421DE's. They were pretty inexpensive ($90 on sale at NewEgg) and look like they had decent performance. Being a Linux enthusiast I wanted to see if I could do a little more with the unit, ideally ending up with Debian running on the thing. What follows is what I've done (so far) with my LS421DE's.

Initial Setup
Being the diskless model, the unit doesn't come with 'firmware' on it. In reality, the 'firmware' (which isn't exacty 'firm' in the traditional firmware sense) is stored on the hard drive(s), of which there are none to start. This is a really frustrating part of the Out of Box experience, but understandable, especially for the low price of this unit. So, to get things up and runnning, you'll need to put at least 1 drive in and do a firmware update. At the time of this writing, I updated my 421DE to v1.33. And to get it to work with new or already used drives I had to edit the LSUpdater.ini file, changing the NoFormatting value from 1 to 0:

[Flags] VersionCheck = 1 NoFormatting = 0

Then run LSUpdater.exe, and it should find the unit and you'll be asked if you want to format the drive(s). Make sure you don't have any data on them that you care about before you say yes!

SSH Access
Well, I didn't use the ACP_Commander method. Instead I just removed the single drive I had in the unit (after power down) and modified the root filesystem with another Linux host. It took a few tries, but I enabled the ssh daemon, primarily by editing /etc/init.d/rcS to start sshd.sh and changing the /etc/init.d/sshd to start regardless of the presence of sshd and the SFTP option. I also edited /etc/sshd_options as described. In the end I did end up with SSH access as other have achieved. Yay!

After 'formatting' using the LSUpdater.exe software (or at the factory), the first hard drive is partitioned like so:

~# parted /dev/sdf print Model: ATA ST4000DM000-1F21 (scsi) Disk /dev/sdf: 4001GB Sector size (logical/physical): 512B/4096B Partition Table: gpt

Number Start   End     Size    File system  Name     Flags 1     17.4kB  1024MB  1024MB  ext3         primary 2     1024MB  6144MB  5119MB               primary 3     6144MB  6144MB  394kB                primary  bios_grub 4     6144MB  6144MB  512B                 primary 5     6144MB  7168MB  1024MB               primary 6     7168MB  3992GB  3985GB               primary

This is for a 4TB drive BTW and I have it on a USB dock on a nearby Linux box. To get at the filesystems you'll do something like this (as root, or add sudo in front):

mdadm: /dev/md11 has been started with 1 drive (out of 2). total 200048 -rw-r--r-- 1 root root    35766 Dec 25 08:17 conf_save.tgz drwxr-xr-x 2 root root     4096 Oct 31  2007 grub/ -rw-r--r-- 1 root root 188966282 Oct 7 05:28 hddrootfs.buffalo.updated.done -rw-r--r-- 1 root root 11966319 Oct  7 03:58 initrd.buffalo -rw-r--r-- 1 root root    24629 Dec 25 08:17 log.tgz -rw-rw-rw- 1 root root   725924 Sep 13  2013 u-boot.buffalo -rw-r--r-- 1 root root  2894368 Oct  7 03:57 uImage.buffalo
 * 1) mdadm --assemble --run /dev/md11 /dev/sdf1
 * 1) mount /dev/md11 /mnt
 * 2) ls -l /mnt
 * 1) umount /mnt
 * 2) mdadm --stop /dev/md11

Clearly based on the above, the first partition holds some boot files. This is what is mounted at /boot on the running Linux system, and is indeed what the u-Boot bootloader loads from (kernel is uImage.buffalo and initrd is initrd.buffalo). The 2nd partition is the one we're after, so do the same as the above, but for partition 2:

mdadm: /dev/md12 has been started with 1 drive (out of 2).
 * 1) mdadm --assemble --run /dev/md12 /dev/sdf2
 * 1) mount /dev/md12 /mnt

Then, to enable SSH, edit /mnt/etc/init.d/sshd.sh, commenting out the following lines as shown:


 * 1) if [ "${SUPPORT_SFTP}" = "0" ] ; then
 * 2)        echo "Not support sftp on this model." > /dev/console
 * 3)        exit 0
 * fi

The SUPPORT_SFTP variable comes from /etc/nas_feature, so you'd think you could just set that variable to 1, but the stock initrd image will overwrite this on boot. You can certainly edit the initrd image to fix/change this, which I'll add in a bit, but for initial SSH access, commenting out the lines above seems the most straightforward (to me). Anyways, now the SSH server can start, but won't yet, until you add it in /mnt/etc/init.d/rcS. Somewhere near the end of that file, you can launch sshd. I added it to the list as shown below:

echo "** step final(after bootcomplete) **" for cmd in sshd.sh diskmon.sh hdd_late_check.sh check_initialization.sh usb_late_check.sh daemonwatch.sh do       exec_sh ${cmd} done

So, ssh will start, but it's not configured correctly yet. Edit /mnt/etc/sshd_config and uncomment the lines:

Port 22 PermitRootLogin yes

And if you want to login, you probably need to know the root password. Perhaps it's one of the known Buffalo passwords, but you'll likely want to change it to something you could type yourself. So edit the password field in /mnt/etc/shadow, perhaps as a copy of the password on your Linux box/VM, or use the following line to set the password to 'password':

root:$6$D91gn.N4$1h0cLNX4AUuFRm1oMy8ZxdYfisKXa/8nwzI3xP7f8ILxYLQCHTyst5syKbqKPYGeL7SzjRFm1F4PH3HvTlaD4/:10933:0:99999:7:::

Obviously, once you log in via ssh, you'll want to change this!

I think we're ready now, so


 * 1) umount /mnt
 * 2) mdadm --stop /dev/md12

Put the drive back into the NAS, boot up, wait a bit, and hopefully you can ssh in!

Problems
I did the above steps on the 1st of 2 drives. I had to add the '--run' to force the assembly of the partition so that I could mount them. On the next boot (with the 2nd drive still in place) it wiped out most of my changes (all except for /etc/sshd_config). Booting without the 2nd drive seems to solve this, but I'm not sure what happens when put the 2nd drive back in (testing now..) Okay, so it still works after adding the 2nd drive (after booting once without it). However:

[root@LS421DE515 ~]# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md10 : active raid0 sda6[0] sdb6[1] 7782874112 blocks super 1.2 512k chunks

md0 : active raid1 sdb1[1] 999872 blocks [2/1] [_U]

md1 : active raid1 sda2[0] 4995008 blocks super 1.2 [2/1] [U_]

md2 : active raid1 sdb5[1] 999424 blocks super 1.2 [2/1] [_U]

unused devices:

So the /boot, /, and swap which are raid 1's on both drives are only half there. md1 is using the drive in bay 1 (the one I modified), md0 and md2 are on the bay 2 drive. These need to be re-built and re-assembled, which I'd think the Buffalo firmware would handle when replacing a drive. The following fixed mine up:

mdadm --manage --add /dev/md0 /dev/sda1 mdadm --manage --add /dev/md1 /dev/sdb2 mdadm --manage --add /dev/md2 /dev/sda5

Clearly, the better approach is to make these changes to the firmware updater's root fs image instead. Then the raid will be in sync from the beginning, you don't need to swap drives in/out and if it's already done for you, and you don't even need a running Linux system to make the changes (although I'm not sure if there are license issues with publishing these images.) The ACP commander approach also avoids these issues since it's done on a live system.

New Problem: SSHD get's killed! When doing certain operations in the web UI, the ssh server get's killed. It sometimes get's restarted, sometimes not. In particular, when I insert a USB drive, the SSH server goes away until the USB drive is removed or unmounted. I'm still digging into this one...

Debian Wheezy
So, now that I had SSH access, I wanted to install stuff, Debian in particular. So I did a debootstrap install for the armhf, roughly as described here. After that I now have a Debian Wheezy install running in a chroot area (on a USB flash drive) and can install just about whatever I want without messing up the stock 'firmware'.

Serial Console
I did some digging around on the hardware and figured out where the serial console lines are. Based on the data sheet, UART0 must be on either of 2 pins near the marked corner of the Marvel 370. Some traces come out that way towards R265 and R106, and sure enough, there appeared to be some 115200 UART signaling on the R106 pad during bootup. Following the traces around, it looked like these signals get routed over to two 4-pin connectors (not populated) on the edge of the board (J11 and J12). But the signals didn't actually show up. First, the are two resistors by J11 that need to be populated (0 ohm I'd assume) to connect the lines. But even that isn't enough. Here's the bit I don't understand: the lines run under U6/U7 (not sure why it's labelled twice), which is the serial flash just up and back from the 370 as the unit normally sits. The signals are good before they run under the chip and not present after, with no vias in the PCB in that areas. So.. I de-soldered the serial flash and lo and behold, there are 2 0402 footprints underneath the flash chip that are obviously not populated. The cleanest solution to this I had was to jumper from the R265 and R106 resistors right to one of the 4-pin connectors. I then put a .100" header in the other 4-pin connector and connected a 3.3V FTDI USB TTL cable to it (GND, TX, and RX to the proper pins) and I've got U-Boot console access!

BootROM 1.08 Booting from SPI flash DDR3 Training Sequence - Ver 2.3.5 DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED

=
============

=
============

** LOADER **

U-Boot 2009.08 ( 8月 28 2013 - 21:36:20)Marvell version: 1.1.3 NQ U-Boot Addressing: Code:           00600000:006AFFF0 BSS:            006F8360 Stack:          0x5fff70 PageTable:      0x8e0000 Heap address:   0x900000:0xe00000 BUFFALO_BOOTVER=0.13 Board: Buffalo LS-M 88f6710 SoC:  MV6710 A1 CPU:   Marvell PJ4B v7 UP (Rev 1) LE       CPU @ 1200Mhz, L2 @ 600Mhz DDR @ 600Mhz, TClock @ 200Mhz DDR 16Bit Width, FastPath Memory Access PEX 0: Root Complex Interface, Detected Link X1 PEX 1: Detected No Link. DRAM: 512 MB       CS 0: base 0x00000000 size 512 MB       Addresses 14M - 0M are saved for the U-Boot usage. SF: Detected MX25L8006E with page size 256, total 1048576 bytes NAND: 512 MiB u-boot envinit tval=e4b4c857 FPU not initialized USB 0: Host Mode USB 1: Host Mode Shutting down unused interfaces: AUDIO TDM Modules/Interfaces Detected: SDIO RGMII0 Phy RGMII1 Phy PEX0 (Lane 0) PEX1 (Lane 1) SATA0 (Lane 2) SATA1 (Lane 3)

Marvell Serial ATA Adapter Integrated Sata device found

MAC Address : 10:6F:3F:xx:xx:xx MMC:  MRVL_MMC: 0 Net:  egiga0, egiga1 [PRIME] hit any key to switch tftp boot. Hit any key to stop autoboot: 0 switched to TFTP boot. Hit any key to stop autoboot: 0 BUFFALO>> Note: the above is with no hard drive connected. If drives are present, you see HDDx Power ON and a scan of the drive before the 'MAC Address :' line... BUFFALO>> printenv sn=xxxxxxxxxxxxxxxxxxx eth1addr=10:6F:3F:xx:xx:xx serverip=192.168.11.1 ipaddr=192.168.11.150 deviceid=_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SerialNo=xxxxxxxxxxxxxx stdin=serial stdout=serial stderr=serial console=console=ttyS0,115200 enaMonExt=no pexMode=RC setL2CacheWT=no sata_dma_mode=yes sata_delay_reset=0 enaExtDisk=no MALLOC_len=5 ethprime=egiga1 netbsd_en=no vxworks_en=no bootargs_root=root=/dev/sda2 rw initrd=0x2600040 panic=5 bootargs_end=:10.4.50.254:255.255.255.0:KW40:eth0:none image_name=uImage load_addr=0x02000000 buffalo_ver=BOOTVER=0.13 uboot_date=UBOOT_DATE="2013/08/28" kernel=uImage.buffalo initrd=initrd.buffalo autoload=n bootcommon=setenv bootargs $console $bootargs_root $bootargs_func $buffalo_ver $uboot_date $mtdparts $bootsystem; ;sf protect off; bootm 0x1200000 0x2600000 bootcommon-u=setenv bootargs $console $bootargs_func $buffalo_ver $uboot_date $mtdparts $bootsystem; ;sf protect off; bootm 0x1200000 tftpbootcmd=tftp 0x1200000 $kernel; tftp 0x2600000 $initrd; setenv bootsystem tftpboot=yes; run bootcommon idebootcmd=ext2load ide 0:1 0x1200000 /$kernel; ext2load ide 0:1 0x2600000 /$initrd; setenv bootsystem hddboot=yes; run bootcommon usb1bootcmd=setenv usbActive 0;usb start;fatload usb 0 0x1200000 /boot/uImage370;sf protect off;run bootcommon-u usb2bootcmd=fatload usb 0 0x1200000 /boot/uImage.buffalo;fatload usb 0 0x2600000 /boot/initrd.buffalo;setenv bootsystem usbboot=yes;run bootcommon mtdids=nand0=armada-nand mtdparts=mtdparts=armada-nand:0x2000000(boot),0x1e000000(rootfs) nandbootcmd=fsload 0x1200000 /$kernel; fsload 0x2600000 /$initrd; setenv bootsystem nandboot=yes; run bootcommon failbootcmd=bootfail bootcmd=for i in $bootorder; do run ${i}bootcmd; done standalone=fsload $load_addr $image_name;setenv bootargs $console $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm $load_addr; disaMvPnp=no bootdelay=3 ethaddr=00:50:43:b4:57:c8 ethmtu=1500 eth1mtu=1500 mvNetConfig=mv_net_config1=1,(00:50:43:11:11:11,0:1:2:3:4),mtu=1500 usb0Mode=host usb1Mode=host usbActive=0 yuk_ethaddr=00:00:00:EE:51:81 nandEcc=1bit netretry=no rcvrip=169.254.100.100 loadaddr=0x02000000 enaAutoRecovery=yes eeeEnable=no pcieTune=no hdddelay=7 bootorder=nand fail tftp ethact=egiga1

Environment size: 2239/65532 bytes

SD Card
While messing around with the PCB, I also put on an SD card socket and put a card in--hoping that it would show up in Linux. No dice so far. The kernel reports an mmc device, but it doesn't detect the card, so no /dev/mmcblk0 or /dev/mmcblk0p1 to speak of.

TODO
I'm hoping to flesh this page out some more with pictures and more detail over the next few weeks.

I plan to boot to a stock Debian Wheezy (or maybe even Jessie) soon, bypassing the buffalo firmware. If/when I get that done, I'd be happy to post some files and instructions needed to do this without any case opening/electrical hacking (if possible.)

I'd also like to run a more recent vanilla kernel instead of the buffalo provided one. This may be useful for getting the SD card slot to work, but I'm unsure of all the support needed for the mapped LEDs, the power switch, fan control, etc, so we'll have to see.

Maybe the Mini PCIe connector could be populated as well, but that looks like it'd involve adding the associated caps/resistors, and I'd have to figure out the values. Perhaps not worthwhile...

--Imlizking (talk) 01:49, 19 December 2014 (UTC)