The work after the course: the next goals.

Although the course has finished, the work on the device driver continues. We’ve learnt a lot so far but there is more to do. The activity has decreased and I took two weeks to rest and catch up withy my every-day work :). However, now I’m beginning again and the objective is to depurate the driver, port it to the latest kernel version and being able to navigate with a browser without errors. I hope all the group is still willing to contribute because it was a great group with smart people.

Ping with the new device driver for vt6656

Finally, today I was able to execute a ping with the new device driver on our 802.11/USB vt6656. This with 802.11b.
There is much work to do yet but now that we can send and receive we will be able to progress steadily.
I think we are arriving at a point where we are going to need the registers specifications from VIA Technologies, so that our work is not that hard. The main problem we had to transmit, is that it took us much time to find out the registers to configure.
Now we can associate to an AP and ping another IP address. This is great progress.

¿Quién escribe Linux?

Hace pocos días la Linux Foundation lanzó:

Linux Kernel Development How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It: An August 2009 Update
Greg Kroah-Hartman, SuSE Labs / Novell Inc.
Jonathan Corbet, LWN.net
Amanda McPherson, The Linux Foundation

Dentro del documento se puede ver porqué todo está funcionando sobre rieles en nuestro curso :)

¡Le podemos conectar una antena externa!

Cuando mostré las fotos de la placa desnuda, noté que parecía haber “un trimmer de función desconocida” entre la radio y la antena. Poco después, alguien llamado “ExoUY” (los uruguayos suelen tener nombres raros, ¡pero esto ya es exagerado!) me corrigió, señalando que eso no es un trimmer, sino un conector para antena externa. Eso está mucho mejor que un trimmer, porque quiere decir que podemos conectar una antena de alta ganancia y, una vez que esté funcionando el modo AP, construir nodos inalámbricos de largo alcance.

Disculpas por mi despiste al sugerir que eso era un trimmer. Las excusas que se me ocurren son una más vergonzosa que la otra:

NMI and ehci-hcd died in Lenovo Thinkpad T60

While developing my device driver, I stumbled on a problem that was very difficult to solve. When I plugged the USB 802.11 card, in my notebook, the EHCI HCD died and I got the following debug message:

[ 351.781090] Uhhuh. NMI received for unknown reason b1 on CPU 0.
[ 351.781090] You have some hardware problem, likely on the PCI bus.
[ 351.781090] Dazed and confused, but trying to continue
[ 351.781165] ehci_hcd 0000:00:1d.7: fatal error
[ 351.785054] ehci_hcd 0000:00:1d.7: HC died; cleaning up
[ 351.785108] usb 1-2: MESSAGE_REQUEST_BBREG failed, error -108.
[ 351.785139] vt6656: probe of 1-2:1.0 failed with error -108
[ 351.785158] usb 1-2: USB disconnect, address 4
[ 352.096076] usb 2-2: new full speed USB device using uhci_hcd and address 2
[ 352.295147] usb 2-2: not running at top speed; connect to a high speed hub
[ 352.326289] usb 2-2: configuration #1 chosen from 1 choice
[ 352.331143] usb 2-2: current firmware found.
[ 352.331204] uhci_hcd 0000:00:1d.0: host system error, PCI problems?
[ 352.331211] uhci_hcd 0000:00:1d.0: host controller halted, very bad!
[ 352.331236] uhci_hcd 0000:00:1d.0: HC died; cleaning up
[ 352.832036] usb 2-2: MESSAGE_REQUEST_BBREG failed, error -110.
[ 352.832071] vt6656: probe of 2-2:1.0 failed with error -110
[ 352.832380] usb 2-2: USB disconnect, address 2

I was the only one in the class having this problem with exactly the same device driver code and the same kernel.

I spent the long weekend looking for the root cause of the problem.
On Monday at 4am after having traced the whole kernel’s USB communication stack and having read chapter 13 of the book Linux Device Drivers for the 3rd time, I found the root cause of the problem.

Tercer encuentro

Una vez que ya tenemos funcionando la lógica y la infraestructura para que el kernel sepa que nuestro driver es el que se ocupa de este dispositivo cada vez que alguien lo enchufa al bus USB, ahora nos toca cumplir la promesa, y efectivamente ocuparnos de él.

Durante este encuentro, nos dedicamos esencialmente a cargar el firmware en la placa, de modo que pueda efectivamente funcionar. Para eso, Christoph nos provee del archivo vt6656.fw, un montón de código binario que no sabemos qué hace (¡GRRR!), pero que debemos enviar al dongle en sucesivos mensajes de control. Para que request_firmware() pueda proveernos este firmware cuando inicializamos el driver, tenemos que poner el archivo en el directorio /lib/firmware.

Una vez que cargamos el firmware con éxito en la tarjeta, por fin podemos bootearla con otro mensaje de control, y tenemos ya una placa de red funcional. Ahora podemos preguntarle cosas como la versión de firmware, o la dirección MAC, o el contenido de la memoria EEPROM del dispositivo (en la que guarda datos persistentes) ¡y nos contesta! De hecho, podemos incluso escribir en la memoria EEPROM, y de esa manera cambiar la dirección MAC de la tarjeta de forma permanente.

Todavía nos falta inicializarla correctamente, configurarla y aprender a enviar y recibir datos antes de que podamos conectarnos a la red, y para que todo eso funcione tenemos que construir las estructuras de datos necesarias para poder pasar información de ida vuelta entre la pila mac80211 y el protocolo USB del firmware.

Una gran oportunidad! A great opportunity!

Participating in this group is an incredible experience. This is a great opportunity we can’t let go. I began digging into Linux Kernel, alone, nine years ago in order to learn the low level details of the TCP/IP stack implementation. Then from 2002 to 2005 I worked solving bugs in an open source MIPv6 (Mobile IPv6) stack called LIVSIX, developed by Motorola Labs and I ported it to uClinux in Coldfire processors with big-endian architecture. I did some tweaks in Wind River Linux Kernel’s the sockets API for specific projects. However, I’ve never had an opportunity like this in which we can develop, in Argentina, an 802.11 Linux device driver from scratch and being led by somebody (Christoph) experienced in contributing to the kernel tree. The group is amazing: eager to learn and produce a high-quality product. We are progressing really fast and I’m confident by the end of the month we will be able to connect to an AP and send/receive data. Organizing this course was a great idea! Good for us and good for the technology in our country. Thanks to Federico, Nicolas, and Daniel. And to Christoph, of course.
—– Español —–
Participar en este grupo es una experiencia increíble. Es una oportunidad que no podemos dejar pasar. Empecé a meterme en el kernel de Linux, solo, nueve años atrás para aprender los detalles de bajo nivel de la implementación del stack TCP/IP. Desde 2002 a 2005 trabajé resolviendo bugs en un stack de MIPv6 (Mobile IPv6) llamado LIVSIX y desarrollado por Motorola Labs. También porté el stack a uClinux sobre procesadores Coldfire con arquitectura big-endian. También hice tweaks en la API de sockets de kernel de Wind River para proyectos específicos. Sin embargo, nunca tuve la oportunidad de desarrollar, en Argentina, un device driver para 802.11 desde cero y ser guiado por alguien como Christoph, con experiencia contribuyendo al kernel tree. El grupo es asombroso: todos ansiosos por aprender y sacar un producto de alta calidad. Estamos progresando muy rápido y seguramente a fin de mes vamos a poder conectarnos a un AP y comunicarnos. Organizar este curso fue una gran idea. Buena para nosotros y buena para el progreso de la tecnología en nuestro país. Gracias a Federico, Nicolás y Daniel. Y a Christoph, of course.

No sólo de código vive el hacker

El desafío técnico de participar en un proyecto de software libre es importante, y eso es parte de lo que lo hace tan divertido. Pero no basta con ser un gran programador: además de saber escribir código, hace falta saber interactuar con la comunidad de ese proyecto. Esto puede ser todo un desafío en sí: en un proyecto grande, con decenas de desarrolladores que no se conocen personalmente, y que interactúan esencialmente a través de listas de correo electrónico, la comunicación debe respetar ciertas reglas, porque de lo contrario sería muy difícil encauzar toda esa actividad de modo que sea productiva.

A menudo, una de esas reglas es que la comunicación debe ser en Inglés. Independientemente de que nos guste o no, el Inglés es la lingua franca de la informática, así como el Francés lo es de las ciencias sociales. De hecho, la comunicación entre el docente y los estudiantes de este taller sería imposible sin capacidad de entender Inglés, y al menos expresarse rudimentariamente en ese idioma. Así, teniendo en cuenta que nuestro objetivo es lograr que el módulo sea incorporado en un proyecto en el que contribuyen cientos de programadores de todo el mundo, parte del contenido del curso es aprender a comportarse como un buen desarrollador en una lista de correo electrónico.

Electropornografía

Viendo que el gabinete de plástico en el que contiene el dongle se mantiene cerrado con dos tornillos en miniatura, no pudimos resistirnos a “desvestirlo” para poder admirar la electrónica en toda su gloria.

En la cara que queda para arriba cuando se enchufa el dongle en una máquina pueden verse el VT6656 y la antena. El aparato de radio está, pero no se ve porque está debajo del blindaje. Entre el blindaje y la antena hay un trimmer de función desconocida.

La cara “de arriba” de la placa

En la cara que queda abajo podemos distinguir un cristal, un chip EEPROM serial ATMEL AT24C02B y varios componentes pasivos

La cara “de abajo” de la placa

Segundo encuentro

Ubicación de nuestro driver en el kernel

En el segundo encuentro comenzamos a hacer algo de código específico para nuestro proyecto.

Estamos programando un driver para un dispositivo USB, de modo que usaremos la pila USB del kernel para comunicarnos con el dongle. Como además se trata de un dispositivo de red, la función esencial de nuestro driver será proveer los servicios necesarios para que la pila mac80211 del kernel, que se encarga de implementar el protocolo 802.11 independientemente del hardware, pueda utiliza el dongle como interfaz de red.

Pero todavía estamos muy lejos de poder ofrecer tanto: hoy nos damos por contentos con bastante menos: queremos que el kernel se dé cuenta, cuando alguien enchufe uno de nuestros dongles, de que nuestro driver es el que se ocupa de ese dispositivo, y lo invoque para inicializarlo. También queremos que invoque a nuestro driver para eliminar el dispositivo cuando el usuario lo quita del bus USB, y durante el tiempo al medio estaría bueno si pudiéramos al menos leer algo (un parámetro, cualquier cosa) desde el dongle. En otras palabras: el trabajo durante el encuentro se concentra en la interfaz entre nuestro driver y la pila USB.