Category Archives: Gentoo

Linux 2.6.13

2.6.13 is here and will soon be in Portage (as testing) for Gentoo users. One thing that will almost certainly cause disruption is that devfs has finally been removed from the kernel, so you pretty much must use udev. If you don’t have udev installed, it will be installed as a dependency of the 2.6.13 kernels, so hopefully the problems should be minimized and udev will just work when you reboot.

Some more of the notable changes I’ve been following since 2.6.12:

  • inotify is now included, which is a mechanism where the kernel tells user-space when a file or directory changes. Very useful for those situations where applications need to watch for a file or directory change, which is common.
  • kexec – optional fast reboots which don’t need to fully reboot and go through all the BIOS initialization again, another kernel is booted directly from the old one.
  • skge is now included, a driver for SysKonnect Yukon network adapters which actually works (a driver for Yukon-II adapters, sky2, will hopefully be included in 2.6.14)
  • it8212 is finally included, a driver for a popular IDE RAID adapter found on many motherboards
  • HZ (frequency of timer interrupt) now defaults to 250 (ticks per second) and is configurable, which might increase battery life on laptops, but this change is still under debate
  • Lots of bug fixes, new hardware support, more drivers, and other stuff which I have missed

AFFS Annual Conference

Gentoo UK were invited to attend the AFFS Annual Conference at short notice. Myself, George (cokehabit), Rob (tigger), Stuart, and Tim (plasmaroo) attended, and Tim did a nice talk titled ‘Introduction to Gentoo’. There were also talks on software patents, Hula, and Debian.

There weren’t many people there – the event didn’t seem very well publicized, yet we met a few happy users and met with AFFS for the first time. Look out for more info in the next Gentoo newsletter.

Fuji DPC-R1 is an Alauda!

I have been making some fast progress with the Alauda driver project.

I discovered that the Fuji DPC-R1 is also an Alauda device, so my driver should result in this device being supported by Linux, as well as the Olympus MAUSB-10 which I have in my posession.

I’ve gone over several logs of sniffed data and documented what I think it’s doing on the new sourceforge project page: control commands and bulk commands.

The first thing I want to achieve is the reading of my XD media cards. The Alauda only provides raw access to the media, so I basically have to interpret XD in software. This is made difficult because XD is closed-spec and it doesn’t look like anybody has done it in software before (well, not open-source!), but fortunately it is similar to SmartMedia (the SDDR09 Linux driver handles “raw SM” in software, and this is proving useful to look at). I’ve published what I think might be something vaguely like the XD Media specification.

Once I’ve figured out a few more details about XD media, I should be able to get reading working relatively easily. I’ve got the driver foundations in place already.

I’m hoping that I’ll hear from some other MAUSB-10/DPC-R1 users soon to get additional testing when I actually have some code which does something useful.

Reverse Engineering

I recieved two emails in response to my last post, both from people owning slightly obscure hardware wondering how they might be able to reverse engineer it and possibly get Linux driver production underway.

The first step is to spy on the device during normal usage. In the case of the Alauda, this means monitoring all USB port traffic while using the device under Windows using the vendor-supplied driver.

Fortunately this is relatively easy to do with USB, you can use software such as USBSnoop on windows which will log all the traffic to a file. Other hardware is not so easy, sometimes you have to resort to expensive “middle-man” hardware devices which monitor and record the traffic for you.

After logging a few sessions, you then have the daunting task of analysing the logs. They are cryptic and hard to understand at first. Here is a small part of a USBSnoop log right after plugging in the MAUSB-10:

[93 ms]  >>>  URB 6 going down  >>> 
-- URB_FUNCTION_VENDOR_DEVICE:
  TransferFlags          = 00000001 (USBD_TRANSFER_DIRECTION_IN, ~USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000002
  TransferBuffer       = f6a77d3c
  TransferBufferMDL    = 00000000
  UrbLink                 = 00000000
  RequestTypeReservedBits = 00000000
  Request                 = 00000008
  Value                   = 00000000
  Index                   = 00000001
IRQL=2
[94 ms]  < <<  URB 6 coming back  <<< 
-- URB_FUNCTION_CONTROL_TRANSFER:
  PipeHandle           = 81b72c20
  TransferFlags        = 0000000b (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000002
  TransferBuffer       = f6a77d3c
  TransferBufferMDL    = 81c029e0
    00000000: 80 01
  UrbLink              = 00000000
  SetupPacket          =
    00000000: c0 08 00 00 01 00 02 00

This starts to make more sense after reading the USB specs – the host computer is sending a command to the device and gets 2 bytes of data back (0x80 0x01) in return. I think that this particular command is querying the device status, and 80 01 means not ready yet. After 10 or so of these commands have been sent, the final one returns a new value of “0x14 0x01”, and after that, all kinds of crazy stuff starts happening, so 14 01 somehow indicates that the device is ready for action.

Once you have an idea about which command does what, and how to interpret the responses, you can then start writing code to mimick what the windows driver does. I’ve archived a good HOWTO (slightly out of date) which provides an introduction to this: Reverse engineering Windows USB device drivers for the purpose of creating compatible device drivers for Linux.

Obviously the process will be different for non-USB devices, but I hope this shows that while it’s an interesting experience, reverse engineering is pretty damn hard, especially you have so little to go on. It’s much easier if you can get a copy of the manufacturers technical documents, which is sometimes possible.

Alauda MAUSB-10

Got my hands on an Olympus MAUSB-10:

It’s a USB media card reader (2 slots, SmartMedia and XD-Media). It uses a vendor-specific interface and protocol, and is currently unsupported by Linux.

I’m going to be slowly developing a driver for this device. The Windows driver shows that the driver is actually for an “Alauda Enumerator” chip, maybe manufactured by RATOC? I’m going to be a copycat and call my driver Alauda.

I’ve fired off an email to Olympus requesting technical documentation for the device, but I’m doubtful that I’ll get anything – I’ll probably have to reverse engineer it from scratch.

Some techy info, the device seems to use a combined Control/Bulk transport, where bulk is used for data transfer and control is used for everything else (get media status, etc). Commands seem to be transmitted via bulk (after control setup) and hopefully they are something standardised e.g. SCSI/ATA, but I haven’t had time to investigate this just yet.

If anyone else owns one of these and would be interested in development/testing, please email me.

I will upload sniffed logs from the Windows driver and an initial protocol analysis sometime soon.

GWN Kernel Feedback

In this week’s Gentoo newsletter we included a request for feedback on possibly stopping development of gentoo-sources-2.4 and removing it from the tree.

John M has already written about the new plan of action in response to this feedback, but as we have recieved a fair quantity of interesting feedback, I thought it might be worth sharing some of it.

Most of the mails are from people who apparently misread the article, thinking that we are dropping Linux 2.4 completely. People were very keen to remind us of certain software and hardware which doesn’t work on 2.6.

One user thought he was doomed to 2.4 simply because his hardware is unsupported in any kernel, however Promise do provide 2.4-only drivers on their websites. Fortunately, all that is needed is a small patch to get this working on recent 2.6 kernels, so Linux should support Promise TX4200 SATA controllers very soon.

Some users reported that they are stuck to 2.4 because of their wireless cards – support is not available in 2.6, and the vendors insist on producing drivers for 2.4 only.

We suspect that the other alien hardware incompatibilities that were reported to us are already supported in 2.6, but we have yet to recieve the information to confirm this.

A few users reminded us that our OpenAFS ebuilds are so outdated that they don’t run on 2.6 at all. Fortunately, Seemant assures us that he’s been fuelling his production line and a new OpenAFS package maintainer should be ready for public consumption sometime soon.

We recieved a couple of more interesting mails, for example this guy, who ‘gets’ how Gentoo works:

I migrated our desktops and servers from 2.4 to 2.6 a number of months ago, so I encourage discontinuation of 2.4. The more people on 2.6 the easier it will be to maintain.

Notice in the above email he referred to “our desktops“. Many of the emails were written in this tone – from a corporate environment. People saying “we use”, “we migrated”, “…a big concern for us”, etc. Doesn’t anyone use Gentoo just because its fun anymore? :)

Another user pointed out that Gentoo rocks because it’s very easy to still be using a 2.4 kernel without also having to run packages that are a year out of date.

Thats about all so far. Thanks for all the feedback, we’ll probably get something in next weeks newsletter to conclude.

Extended Attribute Mono bindings, now for FreeBSD and Linux

Back in April I contributed Extended Attribute (xattr) bindings to Mono, for use on Linux systems.

I’ve just committed a new version of these, creating a transparent layer, so that these bindings work exactly the same on FreeBSD as they do on Linux. On FreeBSD systems, this will make use of FreeBSD’s extattr API – effectively making the use of extended attributes somewhat portable. The interface which Mono exposes is still the Linux xattr API, but the slight differences between xattr/extattr are handled accordingly by the mono runtime. Thanks to Stephen Bennett (spb from Gentoo) for letting me test things on his FreeBSD install.

Extended attributes are metadata (key/value pairs) that you can apply to files, directories, and symlinks. For example, a program could store the mime-type of a file in an attribute to prevent the need to look it up in future. Extended attributes are nice, because they are stored in/near the file inode, making them cheap to use if you are going to be using the file anyway. Beagle uses them internally and suffers quite a bit when it has to resort to using a traditional database instead.

I’ve also been working on improving the unicode handling in the System.Uri class, which is pretty nasty.

Linux 2.6.12

Since there’s the usual chorus of “whats new?” I thought it might be worth posting some things which I’ve observed since 2.6.11:

  • My driver is finally included!
  • Intel HD audio driver
  • ALSA now uses dmix (software mixing) by default even if you have not configured it
  • ALPS touchpad (included on many laptops) driver rework
  • Multipath device mapper
  • Improved SATA support
  • The firewire subsystem finally saw some action
  • Plenty of new hardware support, lots of things that I missed
  • Lots of bug fixes and internal improvements

The first gentoo-sources-2.6.12 release has been added to the tree and features the new inotify (0.23-13) as well as the new fbsplash (0.9.2-r3). Since we moved our patches into Gentoo’s shiny new Subversion server the website generation is broken but this will be updated soon. Also note that your custom udev rules might be broken until you upgrade to udev-058.