Debian support for eSATA SheevaPlug available

The eSATA SheevaPlug is supported by the Debian installer and by Debian now. I've updated the install guide accordingly.

If you're already running Debian on your eSATA SheevaPlug but you installed as a regular SheevaPlug to USB or SD and you'd like to use the eSATA, then make sure you're the latest kernel from Debian squeeze:

apt-get update
apt-get dist-upgrade
flash-kernel

Reboot and type this in u-boot:

setenv arcNumber 2678
saveenv
reset

Your machine will then be recognized as an eSATA SheevaPlug and eSATA will work.

Thanks to John Holland for working on SheevaPlug eSATA support.

Debian on QNAP TS-11x/TS-21x/TS-41x users: go make a backup

I recently discovered that there are two variants of the recovery mode used on QNAP TS-11x/TS-21x (and possible TS-41x) devices and that one has a different behaviour than what my documentation claims. While this issue should hopefully affect few users (but please take a moment and check if you're affected), it has implications to all Debian users on TS-11x/TS-21x. My install guide originally told users to create backup of some mtd partitions only but from now on you need a copy of all partitions in order to use the recovery mode. Therefore, please take a moment now to create a backup of the remaining partitions:

cat /dev/mtdblock0 > mtd0
cat /dev/mtdblock4 > mtd4
cat /dev/mtdblock5 > mtd5

(You should have copies of mtd1, mtd2 and mtd3 already if you following my guide.)

Make sure to copy the files to another machine and add them to your backup.

Debian stable installer for SheevaPlug, QNAP TS-11x/TS-21x and OpenRD

We added support for Marvell's Kirkwood platform to the Debian installer a few months ago and a lot of people have installed Debian testing (squeeze) on devices such as the SheevaPlug and QNAP TS-11x/TS-21x. While this works great, some people would prefer to run Debian stable (lenny). Until recently, I thought we wouldn't be able to support lenny in the installer since the kernel in stable doesn't have support for Kirkwood. However, some work by Frans Pop showed me that it would be quite trivial to change the installer so it would install Debian stable plus the kernel from an alternative repository.

So from now on, it's possible to install Debian stable (lenny) on the SheevaPlug, QNAP TS-11x/TS-21x and OpenRD. This installation mechanism uses the squeeze installer to install Debian lenny (stable) plus the kernel from a repository I maintain. This repository usually contains the kernel from Debian testing (although I sometimes add the kernel from unstable if it has some important features).

Since some users might be wondering which version to install, here is an overview of the benefits and downsides of each version.

Debian lenny (stable): it is the current stable version of Debian (version 5.0).

• lenny has security support (note that this does not apply to the kernel, which we take from squeeze).
• lenny is stable (i.e. it doesn't change, except for security and other important updates).
• The software in lenny is older (since lenny was released in February 2009).

Debian squeeze (testing): it is currently under development and will be the next stable version of Debian (version 6.0).

• squeeze changes every day, with new software coming in.
• squeeze has fairly new software.
• While there is some security support for testing (squeeze), the security support for stable is better.

Fixing your Debian NAS from within initramfs-tools

The following article was contributed by John Cass. Note that John's instructions will also work on other NAS machines running Debian, such as QNAP devices.

I had a problem upgrading my Debian kernel to 2.6.32 on the D-Link DNS-323. The upgrade looked like it worked but on reboot I had a hung machine. I tried taking the disk out, putting it in my main machine and remaking the links in /boot to the previous kernel and initrd.img but it turns out that on the DNS-323 both kernel and initrd are actually stored in flash memory (the /boot disk files are where they are built and a useful archive but are not used during the boot process).

So I was stuck, and had to make a serial cable in order to find out what was going on. The instructions here and here were very useful and the CA-42 clone cost me 4 GBP on eBay and arrived within a couple of days. A delicate bit of soldering (and installing ckermit on my main machine) and I had a serial connection - I could finally see what was was happening.

The upshot was, during the boot process the DNS-323 failed to mount my root partition. This was because the partition was formatted ext3 and the initrd.img had not included the ext3 module. It probably did this because I had deliberately forced mounting it as ext2 in the /etc/fstab (in an attempt to limit the write access to the disk, I want it to stay in standby for a long time but that's another post). (Remark by Martin: this is a known issue with initramfs-tools.)

Anyway, having seen this, Martin was able to guide me to getting it fixed:

• First of all, I issued modprobe ext2 to get the ext2 module loaded (luckily this was included in initrd.img).
• Then you can mount the root partition on /root: mount -t ext2 /dev/sda2 /root - it will complain a bit but will work fine.
• Then run /scripts/init-bottom/udev - this moves /dev to within the new root directory.
• chroot /root /bin/sh - shift the root around so we are working from the proper root disk
• mount -t proc none /proc - mount the proc tree
• mount -t sys none /sys - and the sys tree
• nano /etc/fstab - edit this to change ext2 back to ext3 for the root partition
• mount -t ext2 /dev/sda1 /boot - mount the boot partition if it's a different device (mine is)
• Edit /etc/initramfs-tools/modules and add both ext2 and ext3 - this will force their inclusion in the updated initrd.img
• run update-initramfs -u to regenerate the kernel and initrd.img - this will rebuild the files in /boot and it will use flash-kernel to put them into the flash memory
• umount /proc /sys /dev /boot - unmount filesystems
• exit - leave the chroot
• umount /root - unmount the root partition
• reboot

And it should all be working!

Using the installer to flash the kernel again

Every once in a while someone asks how they can use the Debian installer to access their system on disk to run commands, for example to write the kernel and ramdisk to flash again. This is particularly useful on headless NAS devices. So here's how to do it:

1. Start the Debian installer.
2. Remove the SSH key from ~/.known_hosts because the installer will always generate a new key.
3. Connect to the installer with SSH: ssh installer@...
4. Follow the installer until you reach the partitioner, then choose "go back".
5. Open a shell (look for Execute a shell towards the end of the menu).
6. Run the commands below (the example assumes that /boot is /dev/sda1 and / is /dev/sda2.

mkdir -p /target
mount /dev/sda2 /target
mount /dev/sda1 /target/boot
mount --bind /dev /target/dev
mount -t proc none /target/proc
mount -t sysfs none /target/sys
chroot /target /bin/sh
# the prompt will change
# make modifications to the system and regenerate the initramfs
update-initramfs -u
exit
# the prompt will change again as you're leaving the chroot
umount /target/sys
umount /target/proc
umount /target/dev
umount /target/boot
umount /target
reboot

Debian Installer 6.0 Alpha1 available

The Debian installer team today announced the alpha1 version of the installer for Debian squeeze (6.0). This release adds a lot of new features but I just wanted to highlight the ARM related enhancements. With this release, Marvell's Kirkwood platform is supported. Specifically, the installer supports the following devices: QNAP TS-110 and TS-119, QNAP TS-210, TS-219 and TS-219P, SheevaPlug and OpenRD. In addition to Kirkwood support, Wouter Verhelst added support for the Intel Storage System SS4000-E.

Project management lessons from the FreeDOS Project

A lot of people seem to think that open source is a magic solution to project management and that open source projects will automatically attract a large and healthy community of contributors and users who will improve the software. This, of course, is not the case. In fact, creating a successful open source project is a really major and difficult effort. You have to deliver an initial promise that people find interesting, attract other people, then facilitate and lead the community, etc. You just have to look at all the failed projects on SourceForge that never delivered any code to see that "open source" is not a guarantee for success.

Even though project management is a key element of every open source project, there are only few resources about this topic. That's why I always enjoy reading about the experience from open source project leaders. Jim Hall, the founder of the FreeDOS project, recently posted a series of four articles which I find particularly interesting.

Here are links to the articles along with a quick summary:

• Free and Open Source Software: the first article just describes what free software and open source are all about. It also looks at Raymond's model and compares the cathedral and the bazaar style of development.
• Starting Open Source Software: this article summarizes a number of key lessons learned: every project needs a clear purpose (i.e. you have to solve an actual problem); initial users of the software should be recruited as developers; releases are important; and every project needs an active coordinator or maintainer.
• Cultivating Open Source Software: you need a web site; making the source code availability in an easy way is important; documentation is often hard to write but is vital; you need a bug tracking system and responding to bug reports is important to attract good feedback.
• Transitions in an open source software project: finally, when you need to hand over the project, make sure to communicate openly, arrange for your replacement and stick around to ensure a successful hand over.

I really like these articles from Jim Hall since they contain a lot of great insights that apply to other projects, so I suggest you check them out!

(Originally published on FOSSBazaar)

Marvell publishes roadmap of its ARM series called Armada

For those who haven't seen it yet, LinuxDevices published an article recently looking at the roadmap of Marvell's ARM line. The new line is called Armada and for Debian the Armada 510 (known as Dove) is of particular interest. To me, it essentially looks like a Kirkwood (the current platform) but with ARMv6/v7 (instead of ARMv5), integrated VGA and some other features. According to the article, the Armada 510 is aimed at "high-end smartbooks and tablets".

I'm happy to see the integration of VGA because I'd like to see more ARM based smartbooks, tablets and thin clients. At the same time, I'm worried that the VGA will be some proprietary chip without proper open source drivers and I'm surprised that the new chip only offers 1.2 GHz. After all, the current Kirkwood chip clocks 1.2 GHz already, so I'd have expected an increase to 2.0 GHz for the next generation.

New devices from QNAP: TS-110, TS-210 and TS-410

When I visited Taiwan last week to talk about Debian at a conference on smartbooks, I used the opportunity to meet up with the folks from QNAP. It was really nice to meet many of my contacts at QNAP in person. We talked about their roadmap and existing products and I found out that they had just released a number of new devices that may be of interest to Debian users.

I really like the hardware from QNAP but one downside of their high quality is also that the devices are fairly expensive. Last week they introduced a number of lower cost alternatives: in addition to the TS-119 and TS-219, you now have the TS-110 and TS-210. They feature a 800 MHz CPU (instead of 1.2 GHz on the TS-119/TS-219), 256 MB (instead of 512 MB) and have a plastic case (as a result of which, the TS-110 now has a fan unlike the TS-119). Similarly, in addition to the TS-419 and TS-419U, you now have a TS-410 and TS-410U.

Since the TS-110/TS-210 and TS-119/TS-219 are compatible, the Debian installer will work out of the box.

New Debian on NSLU2 documentation available

I wrote several new guides about Debian on the Linksys NSLU2 this weekend. The new guides cover the following topics:

• Troubleshooting: common problems and their solutions
• Internals about the boot process of Debian on the NSLU2
• Modifying a NSLU2 firmware image
• Cloning a NSLU2
• Migration guide: how to move your Debian installation from your NSLU2 to a SheevaPlug.

You can find this documentation at my Debian on NSLU2 site.

Debian installer for SheevaPlug available

You can now use the Debian installer to install Debian on the Marvell SheevaPlug. This routine will install Debian testing (squeeze), which is currently under development. The installer itself is also under development, so there may be problems from time to time but it should generally work pretty well. The Debian installer doesn't support installations to flash, but you can use it to install to a USB stick or disk as well as to an SD card. Here are installation instructions.

Upgrading SheevaPlug's U-Boot to version 3.4.19

Marvell made a new version of U-Boot for the SheevaPlug available last month. This version, 3.4.19, integrates SD card support and improves support for FAT32 USB partitions (although USB support in general is still a bit flaky). This page describes how to install this new version of U-Boot on your SheevaPlug.

First of all, download the SheevaPlug U-Boot 3.4.19. Unpack the zip file and copy the file u-boot-3.4.19/u-boot-rd88f6281Sheevaplug_400db_nand.bin to your TFTP server. I suggest you call the file u-boot.bin.

Then start your SheevaPlug and type the following:

setenv serverip 192.168.1.2 # IP of your TFTP server
setenv ipaddr 192.168.1.200
bubt u-boot.bin

The upgrade process will ask whether you want to change the environment:

**Warning**
If U-Boot Endiannes is going to change (LE->BE or BE->LE),
Then Env parameters should be overridden..
Override Env parameters? (y/n) n

Make sure to answer "n" here.

We also need to make a small change to the u-boot configuration because this version of u-boot no longer accepts the console parameter we have been using. Thanks to Tom Rinehart for pointing this out. Instead of console, we'll therefore add a new bootargs_console and update bootcmd to make use of it:

setenv bootargs_console console=ttyS0,115200
printenv bootcmd

You'll see that bootcmd contains $(console). You have to set a new bootcmd and change the console parameter to $(bootargs_console). In my case, I'd type:

setenv bootcmd 'setenv bootargs $(bootargs_console); run bootcmd_usb; bootm 0x400000 0x0800000; reset'

Make sure you don't forget the quotes!

Finally, save the environment and restart your machine:

saveenv
reset

Debian installer for QNAP TS-119, TS-219 and TS-219P available

The Debian installer for QNAP TS-119, TS-219 and TS-219P devices (based on Marvell's 1.2 GHz Kirkwood chip) is now available, together with installation instructions. The installer is still under development and it will install Debian testing, which is also under development. However, I think it's working pretty well. If you try the installer, please send me feedback.

Fan control on the D-Link DNS-323

The kernel in Debian doesn't have support for the fan control chip on the D-Link DNS-323. Since some people said that their device runs quite hot after installing Debian, I've prepared a 2.6.29 based kernel that includes the fan driver.

If you want to install this kernel, edit the file /etc/apt/sources.list and add the following line:

deb http://people.debian.org/~tbm/orion lenny main

Now you can install the new kernel:

apt-get update
apt-get install linux-image-orion5x

After a reboot, you can control the fan this way:

echo   0 > /sys/class/hwmon/hwmon?/device/pwm1  # turn it off
echo 255 > /sys/class/hwmon/hwmon?/device/pwm1  # turn it to full speed

Any values between 0 and 255 will work.

According to Anselmo Luginbuhl, you should also be able to use the lm-sensors package to automatically control the fan:

"Execute pwmconfig, it will make some tests and generate the fancontrol config file. At the end of the procedure it will ask you to "Select fan output to configure, or other action:", just be sure to pass through choice "1" or it would not fill in the configuration file, save the configuration and start the daemon /etc/init.d/fancontrol.

Probably the only thing that needs some attention to get an optimal result is to choose the right parameters for max and min temperature at which the fan should start or stop to minimize the °C and the noise."

Finally, this kernel also includes some performance patches from Marvell, so you might see some performance increases too.

Corporate participation in open source communities

Someone recently asked me a few question about corporate participation in open source communities and I thought I'd share my thoughts on this topic here.

Are there differences between an open source project done for a corporation and one done for personal reasons?

There are many different ways to run an open source project, led by a corporation or by someone else. Some projects that are run by corporations have few outside contributors. This is often the case with projects that require copyright assignment (i.e. contributors have to assign their copyright to the corporation). These projects may not gain all the benefits of a true open source community, such as outside contributions or high levels of peer review. However, they may still be very successful projects and may have high levels of quality.

Projects done by a corporation may have better planning and may have more resources than other projects. When a corporation, especially a large one, starts or becomes involves in a project it can also give credibility to the project and attract a lot of interest to the project. This means that projects done by corporations may have a bigger impact and might also be more visible in terms of publicity.

How do corporations successfully utilize an open source community?

Corporations can benefit from an open source community in many ways. For example, they can often find people who will review their code or make code contributions. If people become excited about what the corporation does, they might also spread the word and create viral marketing for the corporation. Establishing a community around one's project is often also a good way to identify people to hire since you already have experience working with them and know their capabilities.

How do open source communities successfully utilize their corporate relationships?

Corporations can make several unique contributions. For example, large corporations can use their name to attract attention to a project and give it credibility. Furthermore, corporations have some capabilities that personal contributors often don't have access. They may have special testing equipment (such as servers with thousands of CPUs or hard drives) or access to a testing lab where a professional usability test can be done. Finally, corporations can sponsor developer conferences, which are typically very effective means for the community to come together and work on activities together.

It is important for projects to remember that corporations are not charities and that they will invest in an open source project for a reason. Therefore, they have to ensure that the corporation will get tangible outcomes from their involvement or sponsorship, otherwise they may not stay involved in the long run.

What are the risks for a corporation when working with an open source community?

One risk is that the code (or other form of contribution) is not accepted. However, this is a risk any contributor to a project faces. Before making any sort of contribution, it is therefore important to become familiar with the project and its culture. Every project has their own "do's" and "don'ts" that have to be followed.

Another risk is that a corporation will invest in a community project that later on is abandoned by the community. However, in this case, the corporation could take the lead and continue to maintain the project.

What are the risks for an open source community when working with a corporation?

One potential risk is that the corporation will assert too much control over the project. It's important for projects to ensure that the community as a whole has influence over the direction of a project rather than one particular player.

Are certain certifications needed in order for someone to participate in open source projects for a corporation?

Certifications are not needed to get involved in or start a project. However, it is important to become familiar with the open source community and the project one wants to contribute to. A good first step is to read the book Producing Open Source Software by Karl Fogel which is available online. As a next step, the community in which someone wants to get involved in should be studied, for example by reading the mailing list archives. This will help to become familiar with the culture of a project as well as the mechanisms to contribute to the project.

How do open source communities communicate and collaborate with corporations?

In the best case, employees from corporations would interact in the project like any other contributor. That is, they should use the existing communication channels, such as mailing lists, IRC or developer gatherings. Many companies are good at working "with the community" but the ideal scenario is for a company to be part of the community and to work "in the community", just like other contributors. This is the most effective way for them to make changes to the code and project.

Of course, not every corporation will get involved in a project directly. That's why it makes sense for projects to collaborate with corporations in other ways. For example, projects can talk directly to companies to get samples of their hardware in order to add support for them in their software. Projects can also work directly with corporations to find out how their project can better meet the needs of enterprise users.

Initial thoughts on the new QNAP TS-219P

QNAP has announced a new device earlier this month, the QNAP TS-219P. The specs are very similar to the TS-219 (1.2 GHz Kirkwood CPU, 512 MB RAM and 16 MB flash) but the device is smaller and has some other advantages.

What I like about the new TS-219P:

• The device is more compact and looks really nice.
• The fan is less noisy than the one in the TS-209 and TS-219.
• There are two eSATA ports.

What I don't like so much:

• The device only has one Ethernet. I'd really like to see two Ethernet ports.
• The serial connector cannot easily be accessed through the SATA slot, something that was possible with the TS-209.

Since the TS-219 and TS-219P are quite similar, Debian and the installer will work without any problems. I updated my QNAP page to document the QNAP TS-219P, including some pictures of the new device.

SheevaPlug lenny tar ball and SD cards

I updated my SheevaPlug installation instructions today to document how to boot from an SD card. The u-boot boot loader shipped with the SheevaPlug doesn't have SD/MMC card support, but PlugComputer forum user kwonsk created one that does (and which works pretty well, except for not working with some SD cards).

First successful installation on QNAP TS-219

I performed the first successful installation of Debian on the QNAP TS-219 using the Debian installer today. Everything is in place now but the Linux 2.6.29 kernel has to move to testing so installations will work.

Automatic power on QNAP Turbo Station devices

All ARM based QNAP machines can turn on automatically when power is applied if the device was not powered down correctly. This is helpful when your power goes down. Follow the instructions below if you want to turn automatic power on using Debian on a QNAP TS-109, TS-119, TS-209, TS-219, TS-409 or TS-409U.

Edit the file /etc/apt/sources.list and add the following line:

deb http://people.debian.org/~tbm/orion lenny main

Now install a new version of qcontrol:

apt-get update
apt-get install qcontrol

Finally, turn the automatic power feature on:

qcontrol -d &
qcontrol autopower on
kill %1
rm /var/run/qcontrol.sock

Update on QNAP TS-119/TS-219 kernel support

I mentioned a few weeks ago that initial kernel support for the QNAP TS-119 and TS-219 Turbo NAS got accepted for 2.6.30 but that there were some issues left. Here's an update:

• SATA: Kirkwood uses a different SATA PHY and the Orion settings weren't quite right, leading to the timeouts I saw. As it turns out, Saeed Bishara from Marvell had a patch for this already and it will be in 2.6.30-rc6.
• Flash: writing to flash is now possible thanks to a patch from Peter Horton that has been merged into 2.6.30-rc5.
• Parsing the MAC address: Thomas Reitmayr created a patch to parse the MAC address from flash but the kernel people thought this should be done in userspace. I haven't looked into this yet... maybe the best solution is to document that the MAC address will change.
• SATA lights: Thomas Reitmayr created a patch to fix this issue.

The SATA and flash fixes are already in our 2.6.29 kernel.