OpenWrt Forum Archive

Topic: Steps to complete Seagate DockStar support

The content of this topic has been archived on 1 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi folks,
I bought the SeagateDockStar earlier this year and played around with it since April. I started with Gentoo on USB Stick (http://ahsoftware.de/dockstar) and gave other distributions a shot (FreeBSD,Debian,pogoplug). None of them fit into the onboard flash memory - or did not behave like I expected from a small embedded distribution. So I started using the original buildroot. I have a pretty good running rootfs which I test over NFS mount (I will put my patches online via gitorious or something else). Unfortunatly I get stuck at the point where I have to configure every package on my own (samba,cups,bittorrent,automount and much more). Since I have not that much time, I looked for alternatives and figured out, that Eric did similar work for OpenWRT's buildroot. I checked it out and felt very comfortable with the environment because I know the general principles from the original buildroot. All the "distributional" work was already done and in most cases well tested by a lot of OpenWRT users.... great!

During my tests, I discovered the following issues which should be solved in trunk:
- jffs2-image does not pad to 128k, but the name implies that (change L30 in image/Makefile: bs=128k)
- padding squashfs to 128k and separate it from the uImage (currently a combined u-boot-uImage-block is generated)
- if someone likes to have uImage combined with u-boot, the image name should reflect this
- u-boot:
   - I strongly prefere the 2nd stage bootloader, so one is always able to fall back to factory default
   - the generated u-boot image has a different ethaddr set - I didn't find an option in image-menu to set my own ethaddr
   - the rootfs type points to jffs2 only - I like the overlay solution and gave squashfs a try - I was forced to change the parameter from jffs2 to squashfs manually (not a problem for me, but could be changed...)
   - this leds to next manual configuration issue - the 5th mtdpart with no 4 was not configured to the name rootfs_data - so the overlay was not automagically created by the initskript - I changed the name from data to rootfs_data in 2nd stage bootloader and it did work :-)
- https://dev.openwrt.org/ticket/7293 -> hotplug2 seems to be a valid replacement

suggestions:
- clean squashfs image (default)
- try jffs2 and squashfs as rootfstype (default)
- provide an option for setting ethaddr ( menuconfig ? )
- provide an overlay option (menuconfig?) or the profile default should be overlay if squashfs is generated (-> rename mtdpart name)

I'm willing to test and implement that, but since I have not much time, I need help from other experienced OpenWRT developers/users.
Gerrit, Eric, Lars, AllDockstarTrainees? Are you still working on this?

Please let me know, if my help/offer is appreciated or not (and if ther eis any chance to continue work on the Dockstar).

Regards,
Ossy

ossy wrote:

During my tests, I discovered the following issues which should be solved in trunk:
- jffs2-image does not pad to 128k, but the name implies that (change L30 in image/Makefile: bs=128k)
- padding squashfs to 128k and separate it from the uImage (currently a combined u-boot-uImage-block is generated)
- if someone likes to have uImage combined with u-boot, the image name should reflect this
- u-boot:
   - I strongly prefere the 2nd stage bootloader, so one is always able to fall back to factory default
   - the generated u-boot image has a different ethaddr set - I didn't find an option in image-menu to set my own ethaddr
   - the rootfs type points to jffs2 only - I like the overlay solution and gave squashfs a try - I was forced to change the parameter from jffs2 to squashfs manually (not a problem for me, but could be changed...)
   - this leds to next manual configuration issue - the 5th mtdpart with no 4 was not configured to the name rootfs_data - so the overlay was not automagically created by the initskript - I changed the name from data to rootfs_data in 2nd stage bootloader and it did work :-)
- https://dev.openwrt.org/ticket/7293 -> hotplug2 seems to be a valid replacement

Just curious. R U referring the above problems to the latest OpenWRT from SVN Development trunk?

Also, if you read posts in this discussion thread, you will notice DogFace05 mentioned that the mtd0 bootloader is actually a secondary bootloader. So, when you said that you strongly prefere the 2nd stage bootloader, so one is always able to fall back to factory default, did you mean the 2nd bootloader on mtd0 partition with a factory default u-boot code?

the second u-boot shows a bogus macaddr, the correct one is actually used. This is due to u-boot #2 not knowing about the params stored in u-boot #1. u-boot #1 actually sets it into the hw. I'll also state that you shouldn't be changing mac addresses.

The wiki for openwrt on Dockstar uses jffs2. You are always welcome to provide a patch to add squasfs and also add to the same wiki page. For most of us jffs2 works fine. It also appears to be padded correctly for the instructions on the wiki page.

The openwrt wiki approach retains the original u-boot in mtd0. This reduces your chances of bricking the device although you might need a serial cable to recover. At least you avoid jtag!

Gerrit

(Last edited by z80yyz on 23 Oct 2010, 05:22)

I'm preparing to compile and install the latest code onto a new DockStar

Do you guys just use the latest revision that's on svn://svn.openwrt.org/openwrt/trunk


Or, am I only allowed to use that snapshot from http://downloads.openwrt.org/snapshots/trunk/kirkwood?

mazilo wrote:

Just curious. R U referring the above problems to the latest OpenWRT from SVN Development trunk?

Yes, I do. I do not use the snapshots - images were built on my own.

mazilo wrote:

Also, if you read posts in this discussion thread, you will notice DogFace05 mentioned that the mtd0 bootloader is actually a secondary bootloader. So, when you said that you strongly prefere the 2nd stage bootloader, so one is always able to fall back to factory default, did you mean the 2nd bootloader on mtd0 partition with a factory default u-boot code?

I spoke of 1st and 2nd stage bootloader in the meaning I found in this forum. Just to clarify things. I prefere to leave the original u-boot in mtd0 and use a 2nd u-boot in mtd1 (current behaviour of svn-trunk). I won't have a problem with upgrading u-boot in mtd0 (e.g. the one of  Jeff ), BUT OpenWrt should be usable by a wide range of users and one should be able to remove OpenWrt from it's device and try other software with minimal effort. OpenWrt project would have full control about a 2nd u-boot in designated mtd1 and can do everything. So ideally, the user has less configuration work and the device can be recovered easily. An additional mtdpart is a low price for easier configuration and less administrative work.

I hope, I explained my point of view intelligible to all.

Regards,
Ossy

z80yyz wrote:

the second u-boot shows a bogus macaddr, the correct one is actually used. This is due to u-boot #2 not knowing about the params stored in u-boot #1. u-boot #1 actually sets it into the hw. I'll also state that you shouldn't be changing mac addresses.

Thanks for confirming that. I was wondering why ifconfig shows my original hwaddr, even if openwrt-u-boot has a different one. This point should be mentioned somewhere. So it is in fact important to leave the original u-boot in place. Knowing that, you are absolutly right, not to touch the ethaddr.

z80yyz wrote:

The wiki for openwrt on Dockstar uses jffs2. You are always welcome to provide a patch to add squasfs and also add to the same wiki page. For most of us jffs2 works fine. It also appears to be padded correctly for the instructions on the wiki page.

I will do so. I updated the wiki page with some details already. Currently, I'm testing my patches in my working area.

z80yyz wrote:

The openwrt wiki approach retains the original u-boot in mtd0. This reduces your chances of bricking the device although you might need a serial cable to recover. At least you avoid jtag!

I noted that and I support this approach.

EmbeddEd wrote:

I'm preparing to compile and install the latest code onto a new DockStar
Do you guys just use the latest revision that's on svn://svn.openwrt.org/openwrt/trunk
Or, am I only allowed to use that snapshot from http://downloads.openwrt.org/snapshots/trunk/kirkwood?

Hi Ed, At least me, I compile the images out of the current svn-trunk of OpenWRT. I didn't find a jffs2 or squashfs image in the snapshots directory. Maybe you can achieve this with the imagebuilder there, but I do not know much about this process. The compilation on my debian squeeze works out of the box after an "svn co" (if you use the defaults).

are the builds still working? I'm not seeing openwrt-kirkwood-Dockstar-jffs2-128k.img in that directory? My apologies if I'm missing something obvious.

I managed to build this and it /seemed/ like everything was perfect, I had my usb wifi adapter working and was getting ready to have usbip up, but it turns out that it doesn't look like usb2 is working, (even though I had enabled it in the make config) kmod-usb2 doesn't show up in installed liskt on the dockstar or the snapshot package folder, it shows up here http://downloads.openwrt.org/backfire/1 … /packages/ but when I try to install I get this error (Install 'kmod-usb2': Error (OPKG error code 255))

Is there anyway that I can get usb2 working on this? Is it just broken in this build since it doesn't seem to build into the package list?

Excuse my question, but why do you want OpenWrt-support, if you do not use OpenWrt? What exactly is you goal?

Have you already published code or configs? Do you plan to? Why not help the OpenWrt developers getting OpenWrt-Version for Dockstar done, first?

Make it work on both targets:  http://wiki.openwrt.org/toh/seagate/doc … l.location  (if it does work, we are only missing some (very basic) howto) Whether 1-stage or 2-stage bootloader should not matter, this is only about installing OpenWrt on some target. And you can test the hell of it.

I am searching for Pros and Cons of the different distris actually running on the dockstar:  http://wiki.openwrt.org/toh/seagate/doc … ternatives  you may want to chip in some content, you definitely know the reasons. Good content won't be deleted, even if it is not OpenWrt specific.

I am using Squeeze on a USB hard disc, and it's working alright. Thought about installing OpenWrt on a USB-Stick or on a different partition, renaming that partition to sda1, and trying it out, but how to install OpenWrt on a stick. I do not want extroot. And no 2-stage bootloader, either. My 1-stage already boots from usb if available. I simply lack a howto. And some facts: Debian Squeeze vs. Gentoo vs. OpenWrt. vs. HomeBrew. Nobody?

Excuse my question, but why do you want OpenWrt-support, if you do not use OpenWrt? What exactly is you goal?

Have you already published code or configs? Do you plan to? Why not help the OpenWrt developers getting OpenWrt-Version for Dockstar done, first?

Make it work on both targets:  http://wiki.openwrt.org/toh/seagate/doc … l.location  (if it does work, we are only missing some (very basic) howto) Whether 1-stage or 2-stage bootloader should not matter, this is only about installing OpenWrt on some target. And you can test the hell of it.

I am searching for Pros and Cons of the different distris actually running on the dockstar:  http://wiki.openwrt.org/toh/seagate/doc … ternatives  you may want to chip in some content, you definitely know the reasons. Good content won't be deleted, even if it is not OpenWrt specific.

I am using Squeeze on a USB hard disc, and it's working alright. Thought about installing OpenWrt on a USB-Stick or on a different partition, renaming that partition to sda1, and trying it out, but how to install OpenWrt on a stick. I do not want extroot. And no 2-stage bootloader, either. My 1-stage already boots from usb if available. I simply lack a howto. And some facts: Debian Squeeze vs. Gentoo vs. OpenWrt. vs. HomeBrew. Nobody?

Orca wrote:

I am using Squeeze on a USB hard disc, and it's working alright. Thought about installing OpenWrt on a USB-Stick or on a different partition, renaming that partition to sda1, and trying it out, but how to install OpenWrt on a stick.

Can you try to install Squeeze on a USB memory stick and see if that will work?

mazilo wrote:
Orca wrote:

I am using Squeeze on a USB hard disc, and it's working alright. Thought about installing OpenWrt on a USB-Stick or on a different partition, renaming that partition to sda1, and trying it out, but how to install OpenWrt on a stick.

Can you try to install Squeeze on a USB memory stick and see if that will work?

WTF? Why? I did, and it worked. Took about 35minutes (slower then disc because of low write speeds) But I want harddisc. Consumes more current, but offers benefits. Had one lying around anyway.

You install Debian with debootstrap. http://www.rudiswiki.de/wiki/DockStarDebian This could not be more easy or straight forward. But, sometimes the installation is intrerupted, because some packages have wrong md5 or something like that. I had to try this about 6 or 7 times, until it worked. Besides that, there is not default config for your network, I think. So configure it, before rebooting (use static!). Done.

But how do you install OpenWrt? And is it stable (like Squeeze)?


PS: I am not against OpenWrt on the Dockstar, I am simply searching for Pros and Cons. And I would like to have freedom of choice! One pro is definitely murmur vs umurmur. And only because umurmur is not yet in the Debian repos. I could of course crosscompile it for debian (or maybe simply copy from ARM-Openwrt-repos). Haven't actually tried this. Debian is a bit more complicated. But with some howtos this isn't really a reason. Never tried Gentoo.

delirium wrote:

I managed to build this and it /seemed/ like everything was perfect, I had my usb wifi adapter working and was getting ready to have usbip up, but it turns out that it doesn't look like usb2 is working, (even though I had enabled it in the make config) kmod-usb2 doesn't show up in installed liskt on the dockstar or the snapshot package folder, it shows up here http://downloads.openwrt.org/backfire/1 … /packages/ but when I try to install I get this error (Install 'kmod-usb2': Error (OPKG error code 255))

Is there anyway that I can get usb2 working on this? Is it just broken in this build since it doesn't seem to build into the package list?

Orca, thank you for completely changing the topic of this thread, I AM using openwrt, I compiled it and installed it! My question was explicitly about an openwrt package (kmod-usb2) I was having trouble installing since there didn't seem to be a built version that worked with the newest openwrt snapshot, I'd really appreciate some help with it other than thread jacking and accusing me of not using openwrt....

(Last edited by delirium on 18 Feb 2011, 19:46)

The discussion might have continued from here.