NAS200 ideas

Discussion in 'Cisco/Linksys Network Storage Devices' started by tajudd, Nov 10, 2010.

  1. tajudd

    tajudd Networkin' Nut Member

    This box is incredible (in both ways).. it's capabilities and it's disappointments. I've got some ideas and would like some kind of feedback. We all know it's a 8MB flash system which should include bootloader, kernel and rootfs (not necessarily in that order).

    - Advantages of RedBoot - brief remote access to the bootloader via TCP/IP (telnet). It is designed for embedded purposes.
    - Disadvantages of RedBoot - stock RedBoot is severely limited and frankly, not a hacker's best friend.

    - Advantages of the stock Linux kernel - knows it works.. what else?
    - Disadvantages of the stock Linux kernel - hacked heavily and difficult to fully grasp it's modifications

    - Advantages of the stock rootfs - knows it works, I like the web downloader utility.
    - Disadvantages of the stock rootfs - seems to pander Windows users. Doesn't offer any deeper useful utilities

    Just like NAS-cc firmware that was produced, I found buildroot, and latest Linux kernel 2.6.36 seems to include most if not all RDC 321x SoC components. I got a kernel to compile occupying 1.2MB disk space (with very few useful utils). I don't think ssh is always needed, most of us have this in a secured local network behind a firewall -- I think telnet server would work fine.

    I thought about using SSD disks instead of spinning platters to reduce heat on the so poor cooling subsystem. Spendy, yes - probably would work well. I'm concerned that because the stock firmware (including Jac's modified firmware based on the stock) does add a swap partition, I'm worried about the wear and tear on the swap partitions. For anyone who does have a closer to typical Linux userland, what memory consumption is typical for either the stock (not likely) or the firmware you're on now? Will a custom firmware that doesn't run with a swap partition (meaning, a "simpler" device) fit in the 32MB onboard ram?

    Can we find another bootloader that fits the same purpose as RedBoot? I see the references to APEX, but I haven't seen anyone mention Etherboot. Yes, Etherboot is primarily for network booting, but it does boot local disks too. Can we set Etherboot up to obtain or set a fixed IP on bootup, possibly getting a telnet-like server as part of it, so you can work the hardware remotely? Can we completely replace RedBoot if we want (say, GRUB or LiLO instead of Etherboot) and still have a working vanilla embedded Linux startup?

    If it isn't obvious already, I know enough Linux to get myself in trouble; but not a experienced one to understand their tools. I'm more familiar with BSD and would rather run BSD on the box if I had a chance.

    Can someone provide the following?

    - What is memory consumption on stock or jac4 firmware for the NAS200 (v34R79 or it's derivitives) - especially what is *currently* occupied in swap space?
    - Completely replacing the data on the flash with a more vanilla setup - possible?
    - Anyone running with SSD disks?
    - Anyone running with non-Linux (pet projects, BSD, Windows Embedded???)?

    I'm ready to torture this device. I'll put my files on a big, energy spender if I brick the NAS200 but I'm gonna get a JTAG (eventually) before I start any of this.

    Thanks for any insight...

    <NAS200 Linksys v34r79 firmware>
  2. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    Florian Fainelli of the project submitted a number of RDC patches to the Linux kernel people so the RDC has officially been supported since (I think) version 2.6.27. But some of the stuff that's in the kernel for the RDC appears to be very specific to the hardware that Florian was working on at the time, for example the GPIO pins that control the LEDs on the NAS200 are not going to work without patching the kernel further, and you will also run into problems with the real-time clock which seems to be connected to the parallel port via a bitbanged I2C interface (I may be wrong, I haven't taken a close enough look at the source code to completely understand what's going on there).

    A telnet server is easy, all you need is to enable TELNETD in the busybox configuration (the Busybox that's part of the stock firmware has a bug that causes a segfault but it's easy to fix). But it's just not enough for anything except playing around.

    SSH not only gives users the possibility to log in to the NAS over the Internet via a secure connection, it also lets them transfer files securely without the hassle of making an FTP server work behind a firewall (which is pretty much impossible unless your firewall is aware of the FTP server).

    This IMHO would be a complete waste of money unless you happen to have an unused SSD laying around and all your computers already have an array of SSD's installed. They are much too expensive to just put into a slow NAS, and you won't even get the speed advantage because the rest of the NAS200 hardware is so slow. I can't imagine anyone being interested in that idea.

    I doubt that the swap is used very much, and because of the low performance it might as well be off. The only time I've seen my swap in use is when I had an (updated) Twonky server looking for media, and it slowed my NAS down so much that I couldn't even log in to shut it down. I'm pretty sure the box will run at pretty much the same speed if the swap partitions are off.

    There's no point in doing that. The boot loader is used to load the Linux kernel into RAM and start it. Since the flash can only be burned in chunks of 128K, the boot loader might as well be 128K too. You might not see a lot of advantages of Redboot but it's incredibly useful: from the command prompt you can download a new kernel or even a new boot loader into RAM from the network, it not only speaks TFTP (which every network-aware bootloader can do probably) but also HTTP. And when it's not crippled the way it is in the NAS200 it can do all kinds of magic stuff with the Flash ROM. I can see that booting a kernel from disk would be marginally useful but you will probably want to keep a working kernel in the Flash so you can use it when you have a failing disk. That kernel might as well be the one you're booting with. You can always load and boot a different kernel once it's running, using kexec.

    That's not possible. Grub and Lilo and other boot loaders for the PC depend on the BIOS to do their work, and the NAS200 doesn't have a BIOS: it has ecos/Redboot instead. Yes there is a BIOS for the RDC proto board on the Internet somewhere but because there's no keyboard or video, it's not going to work (don't even try it, you WILL brick your NAS to the point of needing JTAG to resurrect it). Besides, what's the point? Look around the Internet and every embedded project you will see will tell you that the Boot loader should be left alone unless you REALLY know what you're doing and you have all your bases covered to make sure you can get yourself out of ANY corner that you paint yourself into. Inexperienced hackers need not apply :)

    In theory, it should be possible to load and run a BSD kernel using kexec (I've considered trying to get FreeNAS to run but I don't know enough about BSD so I haven't touched it). The kexec program is not present in my firmware, but kexec support is enabled in my kernel and I confirmed that it works. This is how I did some experiments with a kernel generated by OpenWRT.

    I usually see it using about 24MB to 27MB of RAM while it's not doing anything. Yes, there's not a lot of headroom on this machine and I think that's one of the major causes of performance problems.

    Possible yes. Easy? no. An easy way to start with what you call a vanilla setup is to build a root file system on the hard disk or on a USB stick (e.g. using Linux From Scratch or Debian or Gentoo or OpenWRT), and configuring my firmware to run it. As long as you're working on a USB stick, all you need to do if something goes wrong is unplug it so it's impossible to make your NAS unbootable.

    The next step would be to let my firmware load an alternative kernel by using an automatic startup script on a USB device that gets started from my /init script.

    Once you got it working you can either build your own firmware image and flash it, or you can use dd from the ssh/telnet command line to flash it. Remember the /dev/mtdblock* devices have the wrong node numbers (131 instead of 31) and you have to set the block size of the dd command to 128K.

    I managed to get Gentoo to boot on my NAS200 but I botched it because I forget to set the root password so I could never log in. I still have the root file system and I sometimes do a chroot into it just for gits and shiggles or to accomplish something that's impossible with the limited commands of the built-in Busybox. I think I just used the stock 2.6.19 kernel to run Gentoo, and I fed Redboot some Linux boot parameters so that the kernel would use the hard disk instead of the flash as root filesystem.

    I also worked on getting an updated kernel from OpenWRT to work on the NAS200 but I never finished it because I ran into problems with the network and the SATA controller. Also, the GPIO's for the LEDs didn't work and neither did the real time clock. I did get the kernel to load (up to the point where it would try to mount the root file system - I figured I would get to that once the kernel would run) but I just never got around to finishing the troubleshooting.

    I'm working on a big reorganization of my source code (I've basically been putting my source code into my own SVN and Perforce servers for the last few months; work is progressing very slowly because I have little time), and when I get that done, I'm probably going to release one more JacX release and then I'm going to dive into OpenWRT again. I'm thinking my next JacX release should make it easier to run a different kernel from USB and should also make it easier to update the libraries to run third-party software such as the latest Twonky, Jungle Disk or a remote USB server.

  3. alejandro_liu

    alejandro_liu Addicted to LI Member

    Depending on what you run on your system, memory consumption goes up and down. In my set-up I use NFS (nascc) and my memory consumption is usually low. However, I also use my NAS200 as web server running php scripts, so that can potentially use lots of memory so I have swap active.

    I don't think it is necessary to replace redboot. The source for it is included in some of the Linksys trees, so you could in principle hack it to do what you want.

    I myself feel like the NAS200's are at a dead end, since you can pick cheap/small Atom mini-desktops that provide the more functionality in a similar format.
  4. tajudd

    tajudd Networkin' Nut Member

    LOL, yes. The atom boards, mini-itx or smaller boards would provide a more convenient interface. My problem is that "spare" money is hard to come by, and for the equipment I already have, I don't mind safely hacking into it and trying new things. Burning jac4 firmware was the hardest decision to do. And I only did that because I lost *ALL* my contents of the nas disks trying to pull this info off. (RAID1 non-journaled with 430GB data tried to mount as xfs in software raid when I found out later, the same setup, is an ext2 fs. I corrupted it).

    I'm running jac4 now, but your firmware (nas-cc) is a very *VERY* high consideration. It's the firmware flashing that scares me (not being able to get away from it, if I ever need to). Plus your written directions that on how to bring back some original firmware, and never been done is making me real nervous.

    Currently, I'm making buildroot-2010.11 my new friend. The kernel boots and works correctly in a qemu environment (including a remote shell). I am fine-tuning the rootfs right now. Once the qemu is working, I will use redboot to boot the kernel with a laptop SATA disk with the rootfs to try to get it working. This is all done because I like to learn (I mean, torture myself) to understand this product.
  5. tajudd

    tajudd Networkin' Nut Member

    Good News!

    This website rocks. Nobody else has the kind of information this site has.

    I declare my first real attempt a success.
    Yes, I am running my own custom userland on the NAS200 with the jac4/stock kernel. Using a USB filesystem to grant the userland. I have remote shell, I have basic utilities to run. It's naked, but it is a blank slate for someone to create and work with.

    I am using buildroot 2010.11. I was trying to put the whole thing together including a kernel. But quickly realized with jac4 and the nas-cc firmwares that allow a custom userland, to give it a shot (I think the kernel would have worked too, but when I tried to juggle:
    • building a vanilla kernel
    • with dual support for qemu + nas200
    • and the root filesystem...
    Found it's just more headache at this instant). I need to update it for more applications and learning how to create software raid, I will have a system running that doesn't feel like it's bloated (hence the word naked above). This is coming from a guy who never gone so nitty-gritty with Linux.

    For anyone who wants to collaborate with me about options, feel free to send a private message. At this time, the boundary limits are with the included applications in buildroot.
  6. tajudd

    tajudd Networkin' Nut Member

    RubixLinux - host OS compiled for i486

    Guys, don't know if any of you have ever heard or seen this discontinued fork of Slackware/Arch Linux. Joshua (creator) took Slackware's hierarchy, stance on stability and merged it with Arch Linux' pacman package management tool to create RubixLinux. Pacman's a very thorough package management system for Arch Linux. I've enjoyed working with Arch Linux (that people are calling it bleeding edge; which it is, but the bleeding edge works).

    Since it's compiled for i486 (and tuned for i686), the NAS200 is a perfect candidate for this distribution. I'm currently hand-installing an environment and will try running on jac4 kernel.

    Please provide any flames or contribution you want, I'd like your input if you care to share.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice