Seagate Dockstar - Accessible serial and JTAG port

Even though usually the Dockstar is accessible via ssh or web interface with OpenWRT, sometimes the onboard pin header comes handy either for using the serial console or for resurrecting a bricked device with JTAG. Therefore it is useful to have the pin header accessible even when the casing is closed. This is not an easy task to make in a nice way due to the clean and elegant look of the device. Previously this has been done by others with connecting only the serial port pins above one USB port, but I managed with all of the 10 pins as shown below. Be sure to have some 2 row 2.0 mm pitch receptors and headers before beginning this hack!

Also note that the warranty for the device will be void after such modification, therefore only do it if you 100% sure what you are doing!

First, I soldered a 10-wire ribbon cable between a 2x5 and a 2x7 receptor (both 2 mm pitch). The latter is important to be 2x7, as it will hold itself mechanically with the first and last unoccupied row (see picture on the right). The wire should not be longer than 8 cm, and should be connected in 90 degree to the 2x5 receptor. The point is that by connecting all the corresponding pins, all pins will be accessible from outside with the same wiring scheme as on the onboard header! It is also a good idea to have pin#1 marked with some paint (I used silver marker here).

As there are some openings on the upper casing, one of them has to be made a little bit bigger, so that the connector will fit in. In my opinion, these holes are merely for design and are not necessary for proper ventilation. Therefore it is appropriate to have them used for our purposes, as this will make virtually no damage on the elegant look of the device. 

First the upper casing has to be removed, as shown in my earlier post. Then the metal shielding has to be cut and removed to some extent as shown in the photo on the left. As it is apparent, I chose the side with the reset button, where there is enough space for an additional connector. The unnecessary plastic can easily be removed with a small rasp. First, remove the plastic between the two ventilation holes. Then an additional 3 mm has to be removed from the top as well in order to have the connector fitted above the PCB. It should be checked with both the connector and PCB in place if they indeed fit and if the casing can be closed. If so, then the glue the connector to its place. For this purpose I used a two component epoxy, but other glues that are strong enough can be used as well. 

Be extremely careful however as the glue can go into the holes of the receptor rendering it unusable afterwards! Here the additional two rows of the connector (one at the top and one at the bottom) provides additional strength so that it will not break out. Then the only thing remains is to attach the other end to the PCB, carefully close the casing and test the serial or JTAG connection!

Kernel BUG at kernel/timer.c:681 and broken ext4

I just ran into a mysterious issue with a Virtualbox virtual machine running linux kernel 2.6.37-rc1 (although this might not be kernel specific). After a power outage, reboot always ended with a kernel panic with the following message (among a rather long screen dump):

Clocksource tsc unstable (delta = 784015673 ns)

---[ end trace a732f57055898f20 ]---

Switching to clocksource acpi_pm

Kernel panic - not syncing: Attempted to kill init!

[...]

kernel BUG at kernel/timer.c:681!

invalid opcode: 0000 [#1]

last sysfs file:

CPU0

Modules linked in:

[...]

First, I found many forum posts stating that tsc clocksource has to be replaced with acpi_pm (or something else) already in GRUB, but this didn't help. Then I figured that in recovery mode, having fsck to repair the root filesystem, puts it back to normal. So: even though it does not seem to be related, a broken filesystem can cause the kernel panic above!

Invisible mouse pointer in Debian Squeeze (Debian 6) - Resolved!

Previously, I wrote about a rather serious bug in Debian 6, which prevented the mouse pointer to appear in any X session. However, upon a sleep or hibernation and recovery the pointer came back. As now I wanted to use the laptop which was affected by this issue, I had to look into the solution as well, as there is nothing on how to resolve this on the bugtracker page. Luckily enough I found a rather good point on another page. The main point is that according to the bugtracker, the Intel video driver is already fixed in the proposed update 2.6.32-32 but it cannot be moved to the mainline. For x86, however, it works just fine so that we can install it. To do so, add two lines to the end of the /etc/apt/sources.list file:

deb http://ftp.us.debian.org/debian squeeze-proposed-updates main contrib non-free

deb-src http://ftp.us.debian.org/debian squeeze-proposed-updates main contrib non-free

The domain name can be replaced to match the earlier entries in sources.list. Then as root, simply issue:

root@gxa01:~# apt-get update

root@gxa01:~# apt-get upgrade

The upgradable packages will be shown and most likely some additional packages such as libc, and apt itself will be upgraded. Then reboot, and enjoy your system with a mouse :)

Invisible mouse pointer in Debian Squeeze (Debian 6)

I just updated Debian 6 on my computer and have no mouse pointer since then. Apparently the latest kernel update to 2.6.32.5 reintroduces a bug that has already been resolved. Many Intel VGA chips are affected, mostly on Centrino and Core platform including the i855GM that my laptop have.

root@gxa01:~# uname -a
Linux gxa01 2.6.32-5-686 #1 SMP Tue Mar 8 21:36:00 UTC 2011 i686 GNU/Linux

root@gxa01:~# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

Temporary resolution is to put the system into suspend/hibernation after which the pointer reappears. One can also upgrade/downgrade the system, as other kernel versions are reported to work. Anyway the best would be the Debian guys to fix the mainline kernel ;)

Update: Solution is here.

Seagate Dockstar - Regain ssh access

In my previous post I mentioned that a newly purchased Dockstar tends to "phone home" and by making automated firmware upgrade, forbids ssh login with the default credentials root/stxadmin. In order no to make this happen, one can dedicate a separated subnet or even a distinguished switch to the Dockstar which is of course cumbersome in home environments where spare switches do not lay around everywhere.

In this post I first show how to regain ssh access without registering to the Pogoplug web service. Then we will permanently switch off the cloud service responsible for the nasty behavior (I should have done this in the first place). The first part requires some soldering as right now we only have the serial interface. This means that if you just bought the Dockstar, you better jump to the second part of this post and ensure the ssh access. This comes handy as well if you plan to change the factory default firmware afterward.

Serial console

As embedded boards do not necessary have any video output, a serial connection almost always exists mainly for debugging. Such basic access might come handy if all hell gets loose, and e. g. network connection becomes broken. On the Dockstar we find a 2x5 pin header on which we find the JTAG and serial connection. Here, the important pins are 8 (RxD), 9 (TxD) and 10 (GND).  If you are not familiar with this naming scheme, I suggest reading this Wikipedia article.

Important: the Dockstar serial port voltage levels are 0 to 3.3V, while RS-232 uses -12V to 12V which most likely will damage the board. Therefore never hook the Dockstar serial out to a PC RS-232 port! It is more versatile (and with the extinction of hardware RS-232 ports eventually necessary) to use a USB-serial converter. I used a FTDI FT232RL based board, however it is easier to use the data cable of some cell phones. There have been success reports with Siemens C55 and Nokia cables. The later is easier to develop, as most the USB-serial converter is already designed, but as I had the FTDI board, I stuck with that one. As for design considerations, there is an interesting concept in the second part of this post to close the upper cover of the Dockstar with the serial port remaining accessible. It would also be interesting to build the USB-serial electronics inside and connect it the top mini USB plug.

Now, we can either directly solder the corresponding lines or make a converter cable. It is important to hook up the lines in a crossed fashion: Dockstar RxD -- converter TxD and vice versa. GND is GND as always.

Now it is time to test the connection: open you favorite serial console program, such as putty, or Windows's built-in HyperTerminal. The serial port settings are 115200 baud, 8 data bits, no parity, 1 stop bit. If everything goes well, you will see Dockstar booting on the console after a power on. If this is not the case, check the connection, and the USB-serial converter settings.

Restarting ssh service

Dockstar uses Dropbear as ssh server, which is a lightweight server and client combined application. For further understanding it is important to know, that startup scripts are located in /etc/init.d. More specifically, rcS is being executed each time the device boots up. The other scripts in this directory are responsible for the services running on Dockstar. We are particularly interested in hbmgr.sh and dropbear.sh. The following lines can be executed via the serial console:

-sh-3.2# cd /etc/init.d

-sh-3.2# ls -1

db

dropbear.sh

hbmgr.sh

rcS

udhcpc_ra0.sh

hbmgr.sh is the cloud service startup script causing all the pain while dropbear.sh is the ssh startup script. Now we need to alter rcS to contain the later while removing the first one. In order to make this possible, we have to remount the root filesystem:

-sh-3.2# mount -o rw,remount /

And then editing rcS with a text editor such as vi. For vi, there are many good manuals on the internet,  here I only want to add that the vi on Dockstar starts up in command mode, therefore first we need to press 'i' in order to actually type in the file.

-sh-3.2# vi rcS

#! /bin/sh

mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
mount -t tmpfs none /tmp
mount -t usbfs none /proc/bus/usb
mkdir /tmp/var

echo "/tmp/core_%e_%t" > /proc/sys/kernel/core_pattern

hostname Pogoplug

ifconfig lo 127.0.0.1
ifconfig eth0 169.254.37.133
udhcpc -b `hostname`

#telnetd
/etc/init.d/db
ntpd -g
#comment out the following line

#/etc/init.d/hbmgr.sh start
#add the following line
/etc/init.d/dropbear.sh start

#/bin/mount -a

When finished, press ESC and then save with typing ":wq". 

Now it is time to reboot:

-sh-3.2# /sbin/reboot

and now Dockstar can be reached via ssh with the default root/stxadmin login which I suggest to change with the passwd command. As the cloud service engine was switched off, this will remain the case, so it is now safe to leave the Dockstar plugged on the network. An interesting side effect of the above procedure is that the LED will remain yellow even though the LAN link is up. 

Further investigation of hbmgr.sh reveals interesting pieces of information such as lines like "modprobe rt3070sta". I have no idea why this Ralink wireless chipset is included here...

Seagate Dockstar - Teardown

I ordered a Seagate Dockstar on ebay as a playground for some experimenting with OpenWrt. This device is particularly well-equipped compared to similar ARM-based NAS/routers with its 128MB DDR2 SDRAM and 256MB Flash. Sadly though, the original purpose of the Dockstar seems badly established: your local NAS can only be managed through a web interface on dockstar.pogoplug.com, with local management support completely missing. I am not really happy with this option as I do not believe that it is safe at all.

Nevertheless the hardware is a state-of-the-art ARM-based board equipped with 4 USB 2.0 ports and gigabit Ethernet interface and strong enough to even support standard linux distributions. Debian and Gentoo have already been successfully installed. 

The box itself is nicely designed, the board is in a modern-look minimalistic box. The miniUSB port on the fits in some Seagate's external harddrives, however some third party boxes can be used, too, it takes only a ruler to figure it out.

Important!

Before going any further: NEVER ever connect the Dockstar to a network with public internet access. According to many reports it tends to "phone home", that is making automated software updates. This is a problem because the ssh access gets disabled and only serial console remains. This actually happened to me so consider this issue confirmed! Preventive measures include either a separate switch or subnet dedicated to the device or manually disabling routing to Dockstar on the gateway.
Update: I managed to resolve the problem, ssh access is regained. For details, jump here.

An inside look

Anyway, let's look inside! The top part of the casing holds with eight claws (two each side). After popping it off, the connector of the top mini USB port has to be removed, and the entire PCB becomes accessible. Below there are the main circuits on the two sides of the PCB that I pinpointed and figured out their purpose. For everyone who likes to visualize things, I have  also spotted them on the high-res PCB photos.

Top layer:

• Marvell Kirkwood 88F6281 ARM926 compatible SoC;
• Nanya NT5TU64M16DG-AC 128MB DDR2 SDRAM;
• Two Marvell dual switching power supply circuits.

On this layer we also find the dual LED, the reset button and the UART/JTAG service header. The supply input is a standard single pin connector with the center pin positive and the shield negative. The factory provided external power supply brick outputs 12V 2A. The serial/JTAG header pitch is 2.0mm, a rarely used standard, however available at most distributors.

Bottom layer:

• Marvell Alaska 88E1116R Gigabit Ethernet PHY;
• Micron 29F2G08AAD 256MB Flash;
• Genesys GL850G 4way USB 2.0 hub;
• Atmel AT24C02B I2C EEPROM;
• Monolithic MP8708 switching power supply;
• Marvell 88PG8227 dual switching power supply.

Vintage hard drives - Seagate ST-251

As the storage capacity of the hard disk drives emerges with no apparent limit (all hail Moore's law), old disks get obsolete no matter how ground-breaking they were a couple of years ago. I decided to collect some of the old hard disk drives here so that at least their memory would be conserved. The only selection rule for showing an old HDD I had is that I have to have that one somewhere at home :) so my choices will not be equalized in any sense, including technology, manufacturer and so on.

The first one I found is a Seagate ST-251 from 1994. Using MFM coding, this device was capable of a fantastic 40MB storage space using 6 heads on 3 plates. The maximum transfer rate is 625KB/s with its ST-412 MFM controller. It is an interesting fact that Seagate keeps a good record of its old products, even such an old device is on their webpage here.

These 5.25" units with their massive metallic case indeed represent some sort of everlasting elegance :)

Even though the electronics of the hard drive was restricted to the most basic functionality (and the rest was done by the control card) it seems quite complex: many application-specific ICs and lots of miscellaneous circuit elements can be spotted.

The PCB connector itself is a long time extinct part: on the left, the 34 pol connector is allocated for the MFM control signals, whereas the 20 pol on the right is for the MFM data R/W signals. The jumpers in the middle are dedicated to set the address of the drive, making it possible to chain up to 4 drives in a computer. Note that the power connector is already the standard PATA 4 pin connector supplying 5V/12V. An interesting consequence of the separate control card is that the bad sectors found during factory testing are printed on the case of the drive with the corresponding C/H/S values. Nowadays such maps are stored by the HDD electronics.

After removing the PCB, we get a good sight to the two motors. The one in the middle spins the plates at 3600 rpm and is most likely a brushless 3 phase motor. The other one in the corner is a stepper motor and moves the R/W heads above the plates. While steppers have eventually been replaced by more compact and lightweight solutions, the plate spinner motors are essentially the same even nowadays (they might be a bit smaller though).

These old and robust devices did not really follow today's trend of being low-power and silent. According to the data sheet, it consumes up to 12W and has a characteristic head-bang noise when starting up which is a result of the head calibration process in order to find track0. As a conclusion watch the video I made with the clean area cover removed so that we can see what is going on.

MRTG lang=C why and howto

In my previous post on MRTG, I showed how to plot various sensor and network traffic readings so that they can be easily visualized. In modern systems one can however run into another problem: in UTF-8 enviroments, MRTG starts to complain: 

~#:echo $LANG 

en_us.UTF-8 

~#:mrtg 

ERROR: Mrtg will most likely not work propperly when the environment
variable LANG is set to UTF-8. Please run mrtg in an environment
where this is not the case:

env LANG=C /usr/bin/mrtg

So we shall use the command line given above. However, simply setting LANG=C turns out not be enough, and we get further error messages with previously working mrtg.cfg file such as follows: 

~#:env LANG=C /bin/mrtg /etc/mrtg/mrtg.cfg --logging /var/log/mrtg.log 

...

2010-11-26 16:05:22 -- SNMPGET Problem for hrSystemUptime.0 sysName on public@localhost
 at /bin/mrtg line 658
2010-11-26 16:05:22 -- 2010-11-26 16:05:12: ERROR: Target[localhost.cpu0][_IN_] ' $target->[1]{$mode} ' did not eval into defined data
2010-11-26 16:05:22 -- 2010-11-26 16:05:12: ERROR: Target[localhost.cpu0][_OUT_] ' $target->[1]{$mode} ' did not eval into defined data
2010-11-26 16:05:32 -- SNMP Error: 

no response received

The problem turns out to be that the textual SNMP targets do not work anymore, and the numeric OIDs such as .1.3.6.1.2.1.25.3.3.1.2.768 have to be put in mrtg.cfg. Not only this is inconvenient, the proper numeric values have to be found as well. In order to do so, the snmptranslate tool can be used:

~#: snmptranslate HOST-RESOURCES-MIB::hrProcessorLoad.768 -On

.1.3.6.1.2.1.25.3.3.1.2.768

Here the main point is the -On switch, which translates the name of the OID to the corresponding numerical value. All textual targets in mrtg.cfg must be replaced using the output of this tool. This includes the previously discussed lm-sensors outputs as well. Here is an example for CPU usage:

# commented old one

#Target[localhost.cpu0]: hrProcessorLoad.768&hrProcessorLoad.768:public@localhost
#new one follows

Target[localhost.cpu0]:.1.3.6.1.2.1.25.3.3.1.2.768&.1.3.6.1.2.1.25.3.3.1.2.768:public@localhost 

and then MRTG works again!