Art
Computing
Contact info
CV
Electronics
Geek culture
Home brewing
Math
Music
Physics
Rants
Ψ/Φ
Style
Teaching
Theatre
WHAT'S UP
On 2010-10-04 I received this updated version of my old Linkstation, once again bought via Huuto.net. It is basically the same system with a faster CPU and more RAM, so I expected I could simply copy the OS, including the kernel. It turned out that the kernel needed some tweaking, and I also made thorough backups of the original firmware. On the next evening the machine was finally up and running Gentoo with a custom kernel.
[2018-12-02] I've been updating this again after 3 years of downtime. I had to start afresh with a Stage3, but updating the kernel config etc. has been extremely smooth. For instance, the old kernel build script still works for the latest Linux.
From my previous experience, the best way to backup and install these systems is on a separate, faster machine with a cross compiler, necessitating the opening.
The case is a lot smaller and sleeker compared to the old one. Unfortunately, this means a more plasticky feel, held together by breakage-prone tabs and only one screw. This also signals a move from a hacker-friendly system to single-use consumerism; the single screw is provided for fan replacement, as if that were the only part you would like to replace in a computer. While the old Linkstation's case is somewhat plasticky and rattle-prone too, it has a far more professional feel.
While a smaller footprint in general is nice, it comes with a typical drawback: a small and whiny fan. This could probably be replaced, though the connector is a little non-standard. Another casing, either a more open one, or a metallic heat-conducting one, could probably run without a fan. It is mainly needed for the hard drive, which should be able to survive on its own. With a smaller motherboard and and external power brick, this system is not much different from an external HD, and those generally come without fans.
Instructions for the disassembly are available. There are almost unnoticeable pinholes for loosening the tabs on the top and back, and more obvious tab-holes on the bottom under the stickers.
As before, the kernel must be placed as uImage.buffalo in the first
partition, and the root filesystem must be on the second
partition. The old kernel failed to boot, and some patching was in
order.
[2012-11-01] Linux 3.6.5 (config) is now up and running with udev-195. I use a build script adapted from Fjen's notes.
There is no guarantee of stability, but I have now been running for a full night and day with heavy compilation work, and things seem to be fine. The old notes for 2.6 kernels are still provided here for completeness.
[2013-02-19] Linux 3.8 seems to have the DTBs in a different directory, so the script has been updated accordingly.
[2013-03-04] 3.8.2 has some trouble, it boots fine, and the network goes up for a while, but then goes blank. Back to 3.7 series then. Could be just a compiler issue though, as I had just switched... 3.9.4 works again (config).
[2014-11-19] Attempted reboot to 3.17.3 failed, but 3.16.* works (config)....
[2014-12-07] 3.17.5 just needed some new config.
[2014-12-13] 3.18.0 up.
[2018-12-02] 4.19.6 :-jI used kernel-2.6.31-lsxhl.patch from a Japanese site. Starting with the vanilla Linux kernel 2.6.35.7, the patch works only partially, but this is not a problem. One of the "failed" parts is already in the vanilla kernel.
The remaining part can be patched manually. In the file arch/arm/mach-kirkwood/Makefile, add the line
obj-$(CONFIG_MACH_LSXHL) += lsxhl-setup.o
2.6.36 does not seem to work with the above patch. While the patching process looks similar, there are some incomplete variable definitions when compiling. 2.6.35.8 and .9 are working upgrades for now. In fact, 2.6.35 is now a long-term release series aimed at embedded systems. 2.6.35.10 does not seem to compile with the patch, but .11 to .14 work again.
In menuconfig, the machine type is Marvell Kirkwood, and the implementation is LS-XHL. For a good starting .config on these machines,
or use my 2.6.35.14 config.make kirkwood_defconfig
Then the essential part of kernel compilation is
or use my complete script. The numbers in the devio command depend on the exact machine type, but otherwise this should work for all Linkstations.(emerge devio u-boot-tools) make zImage modules_install devio > foo 'wl 0xe3a01c0a,4' 'wl 0xe3811067,4' # LS-XHL cat foo arch/arm/boot/zImage > zImage.new mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'linux' -d zImage.new uImage.new rm foo zImage.new
This module provides /proc filesystem access for some hardware controls (GPIO), such as fan and switches/buttons. The device drivers should be in the kernel already, but they are not visible without this one. (Not even in sysfs, if you choose that option for GPIO.)
From the above site you can find sim_buffalo.tgz. It contains the source for a kernel module that can be compiled separately:
In my case the module was installed in a wrong place, with the kernel version number omitted from the usual /lib/modules path. It can be moved manually, and after a depmod it should be modprobable.cd sim_buffalo make kernel-mod make install
Only the fan and switches are available via this module. It is not necessary for controlling LEDs (see below).
There are various scripts such as blstools for using these controls in automated fashion. Some of these are outright dangerous, shutting the machine down in case of an error. I am mainly interested in a temperature-sensitive fan control, for which I have written a simple script.
However, the system is actually cooler and quieter without the case and the fan. Currently (2010-11-01) it stays between 33 and 35 °C, while inside the case it easily gets up to at least 45, thus requiring a fan.
At the front there is a single push-button named "function", and at the back panel a slide switch with the positions "off", "on", and "auto". Both of these are exposed via sim_buffalo.
In other words, the machine has a locking power switch that, in fact, acts as a soft power switch. This can be a little weird in practice: if you shut it down from the command line, it will reboot as the switch stays in the "on" position. In the stock firmware, switching to "off" will trigger a software shutdown, and you could do this in any distro with a suitable script.
This will turn off the blue front LED. It is particularly annoying when running without a case.
The equivalent for 3.6 kernels isecho 0 > /sys/class/leds/power/brightness
and for 3.7echo 0 > /sys/class/leds/lschlv2\:blue\:power/brightness
The backside LEDs for power and Ethernet can be likewise annoying, but they are not available via /sys/class/leds at the moment.echo 0 > /sys/class/leds/lsxl\:blue\:power/brightness
After building the first kernel for this machine, I seemed to have several unsuccesful boot attempts. However, logs showed that the system had booted up fine, I was simply unable to ssh in. The following two lines were particularly revealing:
Jan 1 02:00:13 vars kernel: eth0: link up, 10 Mb/s, half duplex, flow control disabled Jan 1 02:00:46 vars kernel: eth1: link up, 1000 Mb/s, full duplex, flow control disabled
So the machine had two Ethernet ports in some sense. The machine only has one network socket, supposedly gigabit, which I had connected to my network. Plus I had only configured eth0 up, since it is usually the first/only adapter. Naturally, the next thing to try was configuring eth1 as well, and it turned out working great.
In fact, the motherboard has a place for another Ethernet socket, but a circuit between it and the SoC seems to be missing. My amateurish guess is that there is a MII on the SoC, and the separate chip would be a PHY. The lack of a PHY confuses the MII in this case.
[2013-07-31] This has gotten interesting with Linux 3.10 where the PHY driver is separated from the Ethernet driver. Networking hangs entirely, because eth0 has no PHY:
Jan 1 02:01:20 kasj kernel: libphy: PHY orion-mdio-mii:00 not foundThis might be fixable with module parameters...
[2013-11-07] With recent kernels, it turned out that the kernel only names working ports, so what was eth1 is now eth0. 3.12.0 runs fine when taking this into accounts.
[2014-11-19] Recent version of OpenSSH have failed with a "Packet corrupt" message upon large transfers. Apparently, this is due to faulty HW checksumming in the NIC, and the known workaround works for me:
ethtool -K eth0 rx off tx off
In menuconfig, you may notice two interesting pieces of hardware with Linux drivers:
[2018-04-19] From the CPU specs:
The machine type is armv5tel, instead of armv5tejl as was the case with the Linkstation Live. Binaries with the J work fine here, since gcc does not use the Java part anyway. But for the sake of completeness, I am in the process of changing the chost. This also helps avoid a bug in portage. (You need to patch /usr/portage/eclass/toolchain.eclass to build gcc on armv5tejl.)
[2011-07-16] After the instructions at NAS-Central and a little soldering, my LS-XHL now has a serial port. I am mainly interested in one due to its usefulness in hacking other devices, such as WLAN routers and FPGAs. It might also be a nice backup for a login console. It is a TTL level (3.3 V) port, thus directly compatible with most of these "diagnostic" ports, and general I/O pins in FPGAs.
My primary motivation for the upgrade was the amount of RAM. The old Linkstation seemed to swap a lot when doing anything substantial, and I wanted something more than a simple file server. Besides the doubled RAM, the overall system speed is much better than expected. CPU power seems to scale almost linearly with the frequency, likely thanks to the L2 cache. For example, glibc compiles in about two hours, without using distcc, ccache or ramdisk.
Unfortunately, small file performance is still lacking. Using the Portage tree in Gentoo is slow, whether locally or as shared via NFS. A faster machine does this a lot better, even when the HD itself is slower.