TODO list for Debian on D-Link DNS-323

Someone asked me the other day what it would take to add Debian support for the D-Link DNS-323. Since we support a number of Orion based devices in debian-installer already, adding support for another device is typically fairly easy. I don't have a D-Link DNS-323 myself, but I looked around the useful DNS-323 wiki and this is what I came up. I'm sharing this list in the hope that other people are interested in working on DNS-323 support.

• The Orion kernel in Debian has support for the D-Link DNS-323 but it needs testing. Also, some patches, such as support for the fan speed chip, are not included in the mainline kernel yet.
• flash-kernel (which writes the kernel and ramdisk to flash) needs support for the DNS-323. I actually implemented this in the meantime but it's completely untested.
• oldsys-preseed reads the network configuration from your existing firmware and uses it to configure the network for debian-installer. This also needs support for the DNS-323.
• Some tools to generate proper firmware images need to be packaged for Debian.
• The debian-installer needs to generate a boot image for the DNS-323 (easy once the tools are packaged).
• Apparently the MAC address is not set automatically in u-boot and you have to run a tool called mac_read to set it. This is problematic because at the moment there's no code to set the MAC address in d-i and to make sure the newly installed system will automatically set the MAC address. This needs some work.

2.6.26 ARM and MIPS udebs on the way...

Otavio has updated kernel-wedge in SVN to 2.6.26, so I updated ARM and MIPS today. The udebs built after minor modifications and I can also build installer images after having fixed some bugs in the build process. I tested a 2.6.26 based image on the QNAP TS-409 (armel) as well as in QEMU (mipsel).

2.6.26 will bring major improvements on ARM. Orion support is much better and our 2.6.26 has a number of patches from Marvell that help with performance on Orion. Our 2.6.26 also has Riku Voipio's LED driver for Thecus N2100 which has been accepted for the 2.6.27 mainline kernel.

I haven't actually uploaded the udebs yet because I'm waiting for the go-ahead as well as for the new version of the 2.6.26 kernel package to build. But at least we're getting closer to having 2.6.26 as the kernel for lenny.

Debian on HP mv2120 web site

I've created a web site with information for running Debian on the HP mv2120. The HP mv2120 is a NAS device based on Marvell's Orion platform and has a 500 MHz ARM CPU, 128 MB RAM and two SATA slots.

All components needed to support Debian on the HP mv2120 have been integrated into Debian and Debian installer. However, a new release of the Debian installer is required so installations of Debian testing are actually possible.

Daily installer image available for QNAP TS-109, TS-209 and TS-409

Daily installer images are now available for the QNAP TS-109, TS-209 and TS-409. This means that complete installations of Debian testing are possible now.

You can consider the daily image as a beta release of RC1 of the debian-installer for Debian lenny. It should only be used by experienced users and only if you can make a serial console in case something goes wrong. As the name suggests, the daily images change on a daily basis and they install Debian testing which also changes on a daily basis (although testing should be fairly stable since we're close to the freeze of testing in preparation for the release of Debian lenny).

If you install Debian with these installer images, please send an installation report to debian-boot send an email to me so I can let you know in case there are any important news you should be aware of.

There is a web site now with complete installation instructions and other information about Debian on QNAP Turbo Station. If you have any questions or suggestions, please let me know.

New behaviour for oldsys-preseed regarding default settings

I've just changed the behaviour of oldsys-preseed in the case when a static IP address is set in the configuration of the device that is the default setting from the vendor. In the past, oldsys-preseed would try to be smart in this case and do DHCP in the assumption that the users never configured the static IP address themselves and might not want to have that setting. However, Mike (mwester) convinced me that doing DHCP when the configuration clearly says to use a static IP is a bad idea. Apparently quite a few users got confused by the old behaviour of oldsys-preseed. The new behaviour exists as of version 2.0 of oldsys-preseed which will be in rc1 of debian-installer for lenny. This change affects the Linksys NSLU2 and Thecus N2100.

Debian support for HP mv2120: putting everything together

I managed to get my hands on a HP Media Vault mv2120, a nice ARM based NAS device, a few months ago with the intentions of porting Debian to it. Unfortunately, I have been really busy lately and most of my time was spent on adding support for the QNAP TS-109/TS-209 and TS-409 (which required a lot of generic work to get Marvell Orion support into Debian, a new SoC used in many NAS devices, including the QNAP TS-x09 and HP mv2120).

There were a number of things that had to be worked out before Debian would run on the mv2120. The good news is that Marc Singer and Eugene San have done all of the heavy lifting in the last few weeks in figuring out how the mv2120 works and that now it's just a matter of putting everything together for Debian to work.

Here are the issues that had to be worked out:

• Figure out how the rescue mode works and how to construct a rescue image that the device can boot: I knew that the mv2120 had a rescue mode that can be activated by keeping the the power and reset buttons pressed when starting that would request a rescue image via the network. This rescue mode can be used to start the Debian installer. Eugene San figured out how to construct a rescue image that the mv2120 would accept. Marc Singer has also written a tool, uphpmvault, to serve such rescue images from Linux.
• Figure out the best way to make one image that contains the kernel and ramdisk: the mv2120 only loads a kernel and no ramdisk, but a ramdisk is needed to start Debian. I discussed some really ugly hacks with Marc Singer to get the mv2120 to accept an image consisting of kernel and ramdisk but Marc wanted to try something else first. u-boot, the boot loader used on the mv2120, can accept something called a multipart image which can consist of a kernel and a ramdisk. When Eugene San heard that we were trying to load a multipart image, he went ahead and figured out how to construct an image that the mv2120 would boot.

Now that these two issues are resolved, I simply need to put everything together and add support for the mv2120 to a number of debian-installer components. We already have Orion kernel images in unstable that support the HP mv2120 (along with a number of other Orion based NAS devices) and the rest shouldn't take too long.

NSLU2 Debian installer for lenny beta 2

The Debian installer team has published the second beta release of the installer for lenny (what will become Debian 5.0). I repacked the image for the Linksys NSLU2 with the proprietary IXP4xx microcode so Ethernet will work.

The installer is now available in two flavours for the ARM architecture: arm is the old ARM port whereas armel is the new ARM port using the EABI which offers better support for floating point and other features. Both the arm and armel architectures will be supported for lenny but the old arm port will be dropped after the release of lenny. At this point, I therefore recommend that people use armel for new installations.

The beta 2 installer image for NSLU2 can be found on my site: armel image (recommended) and arm image.

The NSLU2 causing trouble recently...

We've had two serious bugs on the NSLU2 recently that both caused the system not too boot anymore. The first one was related to initramfs-tools. Kevin Price reported that after upgrading to initramfs-tools 0.92 the system would hang during boot waiting for the root filesystem. When I booted my NSLU2 and looked at the output, I noticed that no root device was set. When I mentioned this to maks, the maintainer of the initramfs-tools package, he immediately knew what was wrong and uploaded a fix. On the NSLU2, the boot loader doesn't pass a root device to the kernel so we set one in the initramfs itself. The code that loads this config variable is not used by many devices so nobody noticed that this got broken in 0.92 until the package moved to testing.

The second problem, reported on Saturday by Paul Collins and diagnosed today with some help from Kevin Price is also related to the strange way the NSLU2 boots. The NSLU2 has 6 MB available for the ramdisk but due to a bug in APEX (the second stage loader used on the NSLU2 by Debian) only 4 MB are actually used. When you write a ramdisk that is larger than 4 MB but smaller than 6 MB, flash-kernel will happily write the full image, but APEX will only tell the kernel about the first 4 MB. As it turns out, everything works fine on arm with 2.6.25, but on armel some additional SCSI modules are enabled that result in the ramdisk becoming too large. The short term solution is to disable these modules, but really APEX should finally be fixed (patches have been available for quite a while thanks to Gordon Farquharson). Fortunately 2.6.25 hasn't moved to testing yet and this problem only occurs on armel, so few people were impacted.

The nice thing about the NSLU2 is that you can write a new flash image via the network, so you can flash a good image in case your machine no longer boots. Nevertheless, we have to make sure such serious bugs don't occur in the future or that they are at least caught very early. Special thanks go to testers like Kevin Price.

QNAP TS-109/TS-209 and TS-409 experimental developer release

Yesterday I completed the first successful installation of Debian on a QNAP TS-209 using a custom debian-installer image with 2.6.25 from unstable. I made the installer image for QNAP TS-109 and TS-209 available as an experimental developer release and today I also uploaded images for the TS-409. More on my plans to support the QNAP TS-109/TS-209 and TS-409 in the upcoming release of Debian (starting with beta3 of debian-installer) soon.

Installer finally working again on Linksys NSLU2

The release release team of Debian released 4.0r2 today which fixes the bug that kept the installer from working on ARM based systems, such as the Linksys NSLU2. This means that installations are finally possible again. I've updated my installation instructions accordingly.

I've also updated the tar ball used for the manual installation to 4.0r2 but I doubt many people are interested in this method now that the installer is working again.

N2100 network troubles due to r8169 bug

Daniel Smolik reported problems with NFS on a Thecus N2100 a few days ago. I confirmed the bug with 2.6.18 and 2.6.22 but found that the problem didn't occur with 2.6.23. I started a git bisect and a few hours later located a fix that Francois Romieu, the maintainer of the r8169 driver, had put in. Apparently the driver had some confusion regarding hardware and IP header alignment. The good news is that the patch is very small and can easily be backported to our 2.6.18 kernel in stable. Also, packages of 2.6.23 were uploaded today and should be in the archive soon.

Tips on reducing memory and running Linux on a flash device

David Härdeman has contributed two really valuable guides to my Debian on NSLU2 site that will be of great interest to many NSLU2 users:

• The first guide is for people running Linux on a flash device, such as a USB flash stick. Since flash only supports a limited number of writes, it is important to reduce the wear and tear on the underlying flash device. David's guide gives some practical advice of how to achieve this.
• The second guide gives a few tips and tricks that can be used to reduce the amount of RAM a system uses. This is particularly interesting to NSLU2 users since 32 MB of RAM is not a lot.

These guides mention Debian but most of the advice applies to other NSLU2 firmware flavours and to Linux in general.

NSLU2 tar ball for Debian 4.0r1

I updated the tar ball for the manual Debian/NSLU2 installation to Debian 4.0r1 (including the new 2.6.18-5 kernel) today. The proprietary NPE microcode from Intel is now included in the tar ball since the code no longer has a click-through license.

debian-installer rc2 for NSLU2 available

Frans Pop uploaded debian-installer a few days ago in preparation for RC2. RC2 will be released in a few days after some more testing and the creation of CD images. Since the NSLU2 doesn't need CD images and I've tested the installer already, I've made NSLU2 images of RC2 available.

Special thanks go to Gordon Farquharson who has done tremendous amounts of testing in the last few weeks and months. Since RC1, the following changes have been implemented:

• The kernel now uses the Ethernet driver developed by Christian Hohnstaedt. This driver is aimed for inclusion in the mainline kernel, even though it still needs quite a bit of work to get there.
• The kernel has been upgraded to 2.6.18. This version adds LED support for the NSLU2 and fixes real time clock support. The NSLU2 is pretty much fully supported with this kernel.
• The installer now has the ability to set the time zone during installation.
• Joey Hess has substantially updated the nslu2-utils package. Among other things, it has proper support for the LEDs now. I have added LABEL and UUID support for /etc/fstab and made the parsing code more robust, making it unlikely that a kernel upgrade will make your device unbootable.

Installation instructions are available.

Lemote's Fulong Miniature Computer

Yesterday I received a Fulong Miniature Computer from China. This device is produced by Lemote and is based on the Loongson chip, a MIPS-like CPU developed in China and previously known as the Godson. The Fulong mini-PC has a Loongson 2E CPU running at 666 Mhz, 256 MB RAM and a 2.5" 40 GB hard drive. There are the usual I/O ports, such as USB, PS/2, Ethernet, audio, VGA and TV out. The Fulong mini-PC ships with a customized version of Debian.

I'm really excited about the Loongson because it promises to make MIPS available on the desktop. In fact, the folks at Lemote already have a laptop based on the same motherboard used in the Fulong mini-PC. Lemote is also trying to establish a community around the Loongson. They have given 400 devices to partners and 600 to Loongson fans and developers in China. It seems that the community is quite active, but it's hard to tell because I don't read Chinese. Fortunately, there is a blog where regular updates about Loongson are posted.

For now, I have taken some pictures of the Fulong, but in the coming months I look forward to integrating Loongson support into Debian.

Debian QA meeting in Extremadura

The last few days I attended a Debian QA meeting in Badajoz in the Spanish region of Extremadura. I worked on a number of QA tasks, like cleaning out bug reports for removed packages and tidying up some WNPP bugs. I also started another compilation run of the archive using GCC 4.2. In general, I worked on a number of TODO items I had, such as updating my Debian on Cobalt pages for etch, and responded to some email. My inbox is actually empty right now and there are few specific things I need to do, even though there's a lot in general, just like always.

Tomorrow I'll head back to Madrid to meet up with some friends. Apparently we'll go bowling. On Monday I'll briefly visit the Universidad Rey Juan Carlos where I stayed for three months earlier this year before catching a flight to Austria where I'll spend New Year.

debian-installer rc1 for NSLU2 available

RC1 of debian-installer has support for the Linksys NSLU2 again. This version almost fully supports the NSLU2: there is RTC and beeper support and a kernel will automatically be written to flash during the installation (and after each kernel upgrade).

NSLU2 specific changes since the last officially supported version (beta 2):

• We switched the kernel from 2.6.15 to 2.6.17: This kernels has most modules enabled that users requested, and now also has RTC and beeper support.
• We now use APEX as a 2nd stage boot loader, i.e. RedBoot loads APEX which then loads the Linux kernel. This allows us to work around the NSLU2's limitation of 1 MB for the kernel. This in turn has allowed us to switch from the nslu2 specific kernel to a generic ixp4xx kernel. (Implemented by Marc Singer, Rod Whitby and me). Because of this change, people who installed Debian using debian-installer beta 2 (released in March) need to upgrade manually.
• Kernels are now automatically written to flash memory. This makes automatic upgrades to newer kernels now possible. (Initially implemented by Joey Hess and since improved by me)

Plans for the future:

• 2.6.18-4 and higher feature the new GPL Ethernet driver written by Christian Hohnstaedt. (Integrated by Michael-Luke Jones for NSLU2-Linux and tested for Debian by Gordon Farquharson and me)
• 2.6.18-4 and higher have LED support.
• nslu2-utils has been substantially updated in unstable (thanks, Joey Hess).

In summary:

• If you want to install Debian on a fresh NSLU2, please follow installation instructions.
• If you want to upgrade your Debian system installed with beta 2 (released in March) to a modern kernel, please follow the upgrade instructions to upgrade to 2.6.17 and the new flash layout.

Testing GCC 4.2 on ARM

On Friday, a branch for GCC 4.2 finally got created, which means that we will hopefully see a release in a few months. The branch should have been created ages ago but the number of regressions just wouldn't go under 100 until recently. During that time, basically since I completed my tests with GCC 4.1, I've been busy testing snapshots of 4.2. I've mainly been testing on em64t (amd64), powerpc and ia64, but I also did some runs on alpha, mips, mipsel, s390 and sparc. Recently, I started testing it on ARM.

Being an embedded architecture, ARM isn't terribly fast compared to some other architectures. However, Intel's IOP line is quite interesting and is used in a number of NAS devices. They typically include SATA and often have expandable memory. The device some ARM people are currently working with is the Thecus N2100. A port of debian-installer is underway but more on that later.

Since my N2100 is not permanently connected to the Internet, Riku Voipio kindly gave me access to his to do some GCC tests. I started several weeks ago using gcc-snapshot 20060922-1 and it has been compiling happily since. I sort packages by their age, starting with old packages, so while there has been quite a bit of progress since I started, lately it has been going quite slowly.

With about 2000 packages compiled in 3.5 weeks, I reckon that GCC 4.2 will be released before I've compiled the full archive. I've therefore been thinking of using distcc to speed the process up. The idea is to run the build process natively on the ARM box but use distcc to perform the actual compilation on another box, namely on a fast machine that has an ARM cross compiler. Unfortunately, I don't have access to such a setup right now. However, I strongly believe that this is a good alternative to test GCC on slower systems and in fact Bill Allombert is currently testing whether it could be used for the m68k port. Finally, Intel's new IOP 34x CPUs are also interesting for this kind of work given that they feature a cache and go up to 1.2 GHz with two cores.

P.S. If someone is interested in fixing bugs, I have tagged package bugs related to GCC 4.2.

Status update of Debian on Linksys NSLU2

Beta 3 of debian-installer has been released recently and some people are wondering about the status of Debian on Linksys NSLU2. This ARM based device includes an Ethernet chip for which Intel provides a driver (based on some code which only recently became free software and which still requires some microcode which is only distributable together with a click-through license).

During the beta 3 development process, I tested the installation on NSLU2 with my USB Ethernet gadget to make sure it works. When beta 3 came out, I wanted to integrate Intel's module and make unofficial images available. Marcus Better did some great work in the last few weeks putting the sources into a Debian packages from which the modules can easily be created. Unfortunately, they don't seem to work. My kernel oopses immediately when I insert them. I spent more than a day compiling the modules myself, trying various things, but to no avail. I have now given up and sent a call for help.

What this means is that the unofficial images with the Ethernet driver are unsupported right now, even though Debian on NSLU2 works fine if you have a USB Ethernet adapter. In the long run, I hope to be able to support Ethernet using a driver which is currently being developed. The author has made good progress already and is aiming for mainline inclusion. I hope it will be usable on the NSLU2 in the next few weeks but it's hard to tell.

There has also been some development that users may not directly see but which is important maintenance work. The firmware of the NSLU2 has a 1 MB limit for the kernel. So far, we have provided a special kernel for the NSLU2 but it would be better if we could use one generic kernel for all IXP4xx based devices. Together with Marc Singer, the author of APEX, we're now integrating his boot loader as a 2nd stage loader to work around this limit.

In summary, NSLU2 development work is still being done, even though the in-built Ethernet is currently not supported. This problem will be addressed in the long run with a proper, mainline driver which will hopfully be usable in the next few weeks. Help with NSLU2 support is welcome because even though I'm still working on it, I now have a number of more interesting devices I'm currently working on (more on this later).

Compiling the whole Debian archive on MIPS with GCC 4.1

Over the last 2.5 weeks I have built the complete Debian archive on a quad-core MIPS machine donated by Broadcom using the recently released version 4.1 of GCC. In parallel, I have done the same on an EM64T box donated to Debian by Intel. The purpose of this exercise was three-fold:

• Find out about compiler problems in GCC 4.1 itself as well as in packages that may fail with the new version before GCC 4.1 is uploaded to unstable. GCC, in particular G++, is becoming stricter regarding adherence to standards and packages may fail to build with 4.1 due to invalid code that was accepted previously.
• Find out about MIPS specific problems in GCC 4.1 and to answer Matthias Klose's question as to which platforms can move to GCC 4.1 as the default compiler once it is uploaded to unstable.
• Find MIPS specific assembler warnings and create a list of all users of xgot (a MIPS specific toolchain problem).

Executive summary

GCC 4.1 itself appears to be very stable, both on MIPS and AMD64. There are, however, a large number of packages using code (especially C++) which GCC 4.1 treats as errors. Fortunately, most of them are trivial to fix. By compiling about 6200 packages, over 500 new bugs have been discovered and submitted, 280 of which are specific to the increased strictness of GCC 4.1. Patches for 2/3 of those GCC 4.1 specific bugs have been submitted.

Based on my findings, Ben Hutchings has prepared a summary of the most common C++ syntax errors (that weren't treated as errors before G++ 4.1).

Most common programming errors

Basically, it all boils down to broken C++ code. There were a few bugs in C code, but the majority was in C++. The most common errors I found are:

• extra qualification
• reliance on friend injection
• wrong escape characters (e.g. "\.", most commonly seen in regular expressions)
• iterator problems (such as assigning 0 or NULL to an iterator)
• template specialisation in wrong namespace
• template reliance on a function declared later
• use of template's base class members, unqualified, where the base class is dependent
• use of assert without #include <cassert>
• dereferencing type-punned pointer will break strict-aliasing rules (a warning) combined with -Werror

I've posted a detailed report to debian-devel.

Acknowledgements (abridged)

• Broadcom for supporting our MIPS port through the donation of hardware to the project and developers. Without Broadcom, our little and big endian MIPS ports would have a hard time meeting the release criteria regarding autobuilders.
• Google for supporting my PhD, thereby allowing me to spend two weeks compiling the archive with GCC 4.1 and sorting out failures.
• Intel for supporting some PhD work which led to this experiment.
• Ben Hutchings for explaining many of the C++ bugs I found to me. I've learned more about C++ in these two weeks than I ever wanted to know. ;-)