If anyone is interested in getting a Seagate DockStar to run an OpenWRT firmware, hurry up and order it from Buy for $24.99 + Free S/H. A Seagate DockStar is a Sheeva Plug computer with an ARM CPU clocked @1.2GHz with a built-in of 128/256 MB RAM/Flash, 4 USB2 ports, and an RJ45 10/100/1000 port. With plenty of Flash/RAM and USB2 ports, the device is an excellent candidate as a Linux embedded system/server to host any PBX system, i.e. Asterisk, FreeSwitch, etc.

Currently, I have my Seagate DockStar device run an OpenWRT off an external USB partition using step-by-step instructions as outlined here. The only problem is I still can't get it to run asterisk-1.6.x, yet. Asterisk complains with a Serious Network Trouble error messages as shown on my post here. If you are a programmer/developer and would like to help, then this is the time to act now while supply lasts.

I just got one of these. I've attached a serial cable and played around with u-boot, and am ready to try getting openwrt onto it.

Will the pre-built kirkwood images on backfire.openwrt.org work for the dockstar, or did you need to compile a different variant?  If so, can you please share your config?

Also, I ordered one of these USB adapters to make better use of the connector on top.

I'm curious about this as well.  I bought a few of these from woot last week and have been tinkering with them for the last couple days. As luck would have it, one of them came with a corrupt uImage partition and won't boot. In my fruitless attempt to copy the kernel from another I discovered the following:

From the original bootloader the pre-built images seem to hang immediately after the CRC passes.  I'm going to assume this is something the stock bootloader is doing to thwart attempts to tamper with the kernel.  But if I chainload the usb-enabled bootloader from plugapps.com the backfire ramdisk image will boot up to the point where the RTC is found missing (the dockstars are devoid of a RTC).

I would caution against attempting to overwrite the kernel or rootfs in NAND until a reliable backup can be made or someone with more knowledge can dissect one of these.  I followed the instructions at http://ahsoftware.de/dockstar/ to backup the original NAND partitions using dd and then attempted to tftp boot the resultant kernel, which failed complaining about a CRC mismatch. So I used the u-boot cmp function to diff the backup kernel from tftp and the one copied from NAND and they had numerous discrepancies.

Edit:

One other thing to note - I grokked the install script from the instructions at

http://www.plugapps.com/index.php5?titl … ug_Setboot

and it appears that no steps are taken to restore the dockstar's original ethaddr in the custom u-boot.  This could cause weird ethernet issues for anyone attempting to use more than one of these on the same network.  setenv ethaddr [unique_hw_addr]; saveenv should fix this...

(Last edited by phat_bastard on 4 Jul 2010, 21:40)

I tried to let my DockStart device to boot off of an OpenWRT BackFire on an external USB partition to no avail. I have not looked into this through a serial-console; however, I believe BackFire has the USB Storage and SCSI Storage built as modules. Unless one can extract the modules and copies to the external USB partition for the Linux kernel to load, a DockStar device may not boot an OpenWRT BackFire. In this case, one needs to build his/her own OpenWRT SVN firmware for his/her DockStar device.

Excellent point. Thank you.

I can confirm mazilo's point about needing compiled-in USB.  I have a serial line connected to my Dockstar, and the stock kernel from backfire can't be used with a USB-mounted root for that reason.

I want to try flashing an openwrt kernel and rootfs onto my device now, but I'm still pretty new to building openwrt images.  I tried adding jffs2 and squashfs image options to my build, but the resulting files are *larger* than the rootfs tarball, which doesn't seem right.  What am I doing wrong?

Here's what got produced:

$ ls -lh bin/kirkwood/
total 13M
-rw-r--r-- 1 ecc ecc  253 Jul  5 23:51 md5sums
-rw-r--r-- 1 ecc ecc 5.5M Jul  5 23:51 openwrt-kirkwood-jffs2-128k.img
-rw-r--r-- 1 ecc ecc 1.2M Jul  5 23:51 openwrt-kirkwood-rootfs.tar.gz
-rw-r--r-- 1 ecc ecc 5.0M Jul  5 23:51 openwrt-kirkwood-squashfs.img
-rw-r--r-- 1 ecc ecc 958K Jul  5 23:51 openwrt-kirkwood-uImage
drwxr-xr-x 2 ecc ecc 4.0K Jul  5 23:51 packages/

Depending on what you put into the firmware through a make menuconfig, The tarball file varies from size to size. On my OpenWRT tarball file, it is about 100MB in size because I included asterisk-1.6.2 and freeswitch-1.0.6 along with their IVR sound files.

BTW, have you formatted your external USB partition with a supported filesystem, i.e. ext3, ext4, etc.?

It looks like the squashfs and jffs2 images are combined kernel + rootfs.  Is there a way to generate just the rootfs image in squashfs or jffs2 format?  (I can do it "by hand" from the root tarball, I guess.)

Yes, I'm using an ext2-formated USB drive and passing root=/dev/sda1 in bootargs.  That's working fine now.

I am not sure what you meant, but is this the option (CONFIG_TARGET_ROOTFS_SQUASHFS) you are looking for on .config file?

So, now your DockStar device can boot off of an external USB partition that has an OpenWRT BackFire OS?

That's what I've specified, but the resulting file seems to be some sort of combined image:

$ file openwrt-kirkwood-squashfs.img 
openwrt-kirkwood-squashfs.img: u-boot legacy uImage, Linux-2.6.30.10, Linux/ARM, OS Kernel Image (Not compressed), 980728 bytes, Mon Jul  5 23:51:40 2010, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0x4CFB1E43, Data CRC: 0x1B28F232

It's not just a filesystem image that I can mount via loopback.

Yes, but I'm doing it "by hand" via u-boot and the serial console. And the image was built from trunk, not backfire, but I don't think that matters much.

Am I understanding that you're loading the kernel from usb via the PlugApps bootloader?  Or are you booting the uImage via netboot / tftp?

I was using tftpboot (in u-boot) to load the usb-enabled openwrt kernel, then booting that with "root=/dev/sda1 rootfstype=ext2" in the bootargs.

I've now flashed the mtd1 partition with this kernel, and that boots fine with the rootfs on USB. But I can't yet boot with rootfs also in flash -- it isn't finding it in mtd2 for some reason.

Using the factory bootloader, or a usb-patched version?

What's the MTD system seeing for partitions? When I was netbooting the default backfire image over the weekend I noticed MTD wasn't seeing the correct layout for the dockstar.

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
Creating 3 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000010000000 : "rootfs"

I played around with the usb-patched one from pogoplug, but I didn't need it for this -- the factory one supports tftpboot (and nand erase/write/etc.), which is all I needed.

Right, I noticed the same thing.  So I recompiled the kernel with CONFIG_MTD_CMDLINE_PARTS=y, and am now passing the following in bootargs:

 
mtdparts=orion_nand:1m(u-boot),4m@1m(uImage),32m@5m(rootfs),219m@37m(rootfs_data)

That improved things a bit:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 8-bit)
Scanning device for bad blocks
4 cmdlinepart partitions found on MTD device orion_nand
Creating 4 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000002500000 : "rootfs"
0x000002500000-0x000010000000 : "rootfs_data"

But I still get this failure:

VFS: Cannot open root device "mtd2block" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0 (driver?)
1f01            4096 mtdblock1 (driver?)
1f02           32768 mtdblock2 (driver?)
1f03          224256 mtdblock3 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Just a guess, but you might try appending:

rootfstype=squashfs,yaffs,jffs2

to your bootargs.  Also, what's your root= look like?  I ask because I believe MTD uses the convention /dev/mtdblock[n], not /dev/mtd[n]block as VFS is barking about.

Thanks for confirmation on the bootloader.  I guess the kernels I tried booting all had serial console disabled.

I am not sure what did you mean. I use the openwrt-kirkwood-rootfs.tar.gz file and extract it to an external USB partition that has been formatted with an ext3 filesystem.

That was a typo, but even when it's correct (mtdblock2), I'm still getting this:

 
SQUASHFS error: squashfs_read_data failed to read block 0x0
SQUASHFS error: unable to read squashfs_super_block

Something's not right with my squashfs image, because I get the same error when I boot from USB and then try to mount /dev/mtdblock2 from the command line. I'm now rebuilding a kernel with debugging turned on in the squashfs module and will hack on it some more tomorrow.

You also need to pass console=ttyS0,115200 in bootargs. This is done automatically with the factory u-boot environment via

 setenv bootargs $(console) $(bootargs_root)

embedded in the value of bootcmd.

It turns out I was using a squashfs image that was padded to a 64k boundary, not a 128k boundary.  I fixed that and now it is booting correctly.

Next step is to make the firstboot process set up the rootfs_data and mini_fo stuff correctly.

I had the serial console defined - I think what fixed this for me was specifying 'noinitrd' in the bootargs.  But this goes away when I boot a proper ramdisk image or specify a rootfs.

I built several different configs last night, and think I figured a few things out.  I believe the correct method for preparing the jffs root partition is to build a ramdisk image and boot it, then from the openwrt shell erase the partition(s) and mount them.  Something like:

> mtd erase <mtd_partition_name (i.e. 'rootfs' or 'rootfs_data')>
mount -t jffs2 /dev/mtdblock3 /mnt

Then grab the rootfs tarball with wget and untar it onto the newly formatted jffs2 partition.

I think the only mod needed in the config file is CONFIG_MTD_CMDLINE_PARTS=y, but only if you want to make backups of the MTD partitions before erasing them.  I think it's possible to use the default MTD geometry also, combining the rootfs and rootfs_data partitions into one large one, but this is all theoretical.

Unfortunately after using the mtd erase / mount / tar extraction process above it still ended up with a panic halt on the VFS error, but I'm also seeing nand write errors on the one I tested this on so I'll report back after further testing.

(Last edited by phat_bastard on 7 Jul 2010, 15:46)

I haven't done this yet. However, if a DockStar boots off of an OpenWRT firmware off a RAMDISK, will it see the original contents on its NAND drive partitions? I have my DockStar device boots off of an external USB partition and I can't seem to find the MTD partitions from its NAND drive.

Can you make sure your OpenWRT BackFire has the SCSI drive, USB Storage, and ext2/ext3 filesystems modules included?

It will if you set CONFIG_MTD_CMDLINE_PARTS=y and use the mtdparts bootargs that ECC outlined previously.  You will also need to mount them manually i.e.

mount -t jffs2 /dev/mtdblock2 /mnt

I had the dockstar rootfs mounted last night, but no USB to back anything up to.

They are compiled modularly.  I'm building now statically because I have no USB whatsoever.

Success!  I now have my Dockstar booting OpenWrt entirely from the internal NAND flash partitions.

BusyBox v1.16.2 (2010-07-04 20:52:22 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 KAMIKAZE (bleeding edge, r22061) ------------------
  * 10 oz Vodka       Shake well with ice and strain
  * 10 oz Triple sec  mixture into 10 shot glasses.
  * 10 oz lime juice  Salute!
 ---------------------------------------------------
root@OpenWrt:/# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /dev type tmpfs (rw,relatime,size=512k)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock3 on /overlay type jffs2 (rw,relatime)
mini_fo:/overlay on / type mini_fo (rw,relatime)
none on /proc/bus/usb type usbfs (rw,relatime)
root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.0M      1.0M         0 100% /rom
tmpfs                    62.2M     28.0K     62.1M   0% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock3          219.0M      4.9M    214.1M   2% /overlay
mini_fo:/overlay          1.0M      1.0M         0 100% /
root@OpenWrt:/#

I think all the steps I went through are in this thread somewhere, but I'll write up a howto. (The final piece was to make sure mtd3 was zeroed, so that the firstboot process would correctly create the jffs2 filesystem there for the overlay.)

I think I see how to do this without cracking the case and attaching a serial cable, just using the pogoplug system itself.  That's next :-)

Where would I find CONFIG_MTD_CMDLINE_PARTS variable? I searched this CONFIG_MTD_CMDLINE_PARTS variable through the .config and the config-default files on my OpenWRT SVN trunk and target/linux/kirkwood, respectively, but didn't find such a variable.

Congratulation! I will be awaiting for your HOWTO.

You will have to create the entry, not sure if it makes a difference where.

I finally got USB working and had the same failed result trying to backup the original kernel and rootfs image with DD from openwrt backfire (ramdisk), so I dropped back to punt.  I'm continuing on with formatting the rootfs partition and extracting the filesystem from the ramdisk.  Will report back if successful.  Though it sounds like ECC might have a faster / better method documented shortly.

(Last edited by phat_bastard on 7 Jul 2010, 18:34)