I'll be travelling to Barcelona for the 3rd international GPL conference. As usual, I'd like to take pictures of historical and/or otherwise interesting cemeteries.
For the first time, I'd actually like to use this blog/journal to ask for suggestions. So if you can recommend any particularly beautiful cemeteries in Barcelona, do let me know.
Since people have already seen me using my motorbike again and almost complaining about my blog still stating that I have problems repairing it: It's all fixed now. Seems like indeed it only was the anker of the starter engine plus the battery. must have been one hell of a short-circuit to first fry the magnet wire and then the battery.
During my repairs I misplaced a washer which led to the blocking of one axis (which in turn prevented the starter engine to do its job). Luckily somebody else did the same mistake before and documented it in some F650 related web forum.
As it seems, the anker of the starter motor was not the only thing that is broken with my F650ST. The battery is OK, the starter motor running fine if it's running freely, the engine can be started by towing the bike. At least while the generator cover is removed, I can also manually put the gearwheels and all other parts in motion without too much effort.
So what am I missing? No, the brushes and the case of the starter engine don't have a short-circuit, and yes I already bridged the starter relay to make sure it's not faulty.
Now the only idea left I have is that something is mechanically blocking the starter engine, once all parts are mounted together. Will give it a (risky!) try to run it with open generator case.
Due to lots of other "real life" and "real work" constraints, I'm not able to work on OpenEZX for at least another week :(
I've just returned from the 2006 incarnation of Wave-Gotik-Treffen, the worlds largest festival on all styles of dark music.
I was very happy with the music, and in fact discovered a number of very interesting projects, such as Dark Sanctuary, Protagonist, Maschinenkrieger KR52 vs. Disraptor, S.K.E.T., and last but not least Omnia.
The weather though was an embarrassment. We had something like six degrees centigrade during the night at the camp site, definitely much colder than anybody would expect from June in Germany. Seems like the climate changes really become visible :((
As many of you will be asking: Did you take pictures? No, I was forbidden to. It seems this year they were only allowing non-SLR cameras for people who are not accredited press. This usually only was the case at concert stages, but now they extended this to all of the festival area. Since I don't own any non-SLR (either chemical or digital), I didn't take pictures. Need to check whether I can get accredited next year (*sigh*).
I've always had a BMW F650ST ever since turning 18. It never let me down so far, apart from one minor problem two years ago, when the carburetor was stuck and the bike was leaking fuel.
Yesterday, the starter motor apparently broke. Waiting for the replacement parts right now. Let's hope this is a one-time defect and not an indication that I should get rid of the bike before a long series of "bike is getting old" repairs.
Since Motorola has finally released the source code for the mux_cli.o and gprsv.o modules of their 2.4.17 kernel on opensource.motorola.com, I've started to clean them up and port them to 2.6.x.
Due to the questionable coding style of that original source code, and the many interface changes in the TTY layer between 2.4.x and 2.6.x, this turns out to be a bigger task than expected. With some luck, I'll find some time tomorrow at ph-neutral to finish the initial port.
Once that code works on 2.6.x, I already have a quite long list of TODO's. First of all, the lower-layer interface needs to be cleaned up. Ideally, the whole TS 07.10 implementation is a TTY line discipline that can be stacked on top of any UART, together with a virtual/fake UART that makes use of the Motorola specific TS07.10 USB transport.
Today I fixed a number of long-standing bugs in librfid, resulting mainly from the conversion to autoconf/automake. Now, finally, users can actually use the native CCID driver again, rather than using OpenCT.
Also updated the README, added a udev rules file and started to make the librfid-tool program (formerly OpenCT-escape) a bit more flexible and user-accessible. It's my sincere hope that some other users (i.e. from the CCC) will write the missing user interface stuff and fix some remaining bugs...
As of today, the OpenEZX project has a working touch screen driver. I've been testing this with the Kdrive X11 server of OpenEmbedded, and it seems to work nicely on my A780 after calibrating with ts_calibrate.
This is such a major step forward, since the touch-screen driver requires a functional PCAP2 driver, which in turn comprises working SPI support, as well as some tricky SPI-during-hardirq for interrupt chaining.
If you're interested in giving it a try, there's the the -ezx6 quilt patchset including all this work.
Also, thanks to the work by Michael 'mickey' Lauer, I've managed to set up an OpenEmbedded environment to build a distribution for OpenEZX. You can find the first bunch of packages as well as a root filesystem that you can put on TransFlash on my OpenEZX developer pages.
The availability of a OE based root filesystem, a kernel with keypad, touch-screen, usbnet and framebuffer support actually means that all the [G]UI people can now start to work on making their favourite UI system work on OpenEZX. Given the amount of interest I've seen in this area, I'm confident that I still don't (yet) need to dive into UI development myself but can stay with the more technical low-level stuff.
Speaking of which, I've also hacked a nice tool called gpiotool, using which you can read/write GPIO configuration as well as individual GPIO pins from userspace. If I had written this earlier on, it would have saved a lot of time and hassle. But then, it's always hard pushing yourself to develop code that _just_ aids development and doesn't really add any functionality itself.
Using this tool I'm now investigating the AP/BP interaction (handshake). Let's hope that we can actually use the phone as a phone really soon.
Motorola seems to be making some progress internally. Today they've announced the availability of opensource.motorola.com, a web site dedicated to free and open source software used and developed in/by Motorola. This is apparently also the portal where they are starting to publicize the source code for their Linux based Smartphones.
While the source code there is not complete in any way [yet], it actually includes the kernel sources for the A1200 phone, too. After a quick read through it, it seems to be very similar to the A780 code (because of a very similar hardware architecture).
Some of the differences are:
Those of you who know me a bit better will know that my now ex-{fiance,girlfriend} is studying indian philology and indian cultural history at Freie Universitaet Berlin. Now when you think about philology, you will probably think of old people wading through books and paper.
To the contrary. I've always been amazed how much software development they actually do (or have made) there. Some years back, I learned about Sanskritreader, an OCR (optical character recognition) software package for devanagari script.
Now their latest software is IndoSkript, a Palaeograpy software. It comes with a ~600MB database of scans of anciend Indic handwritings, where evey glyph in those scripts has been individually separated, and the scripts are annotated, etc.
Using that software (it's mainly a database software) you can for example check how a particular glyph was written in a certain timeframe in a specific dynasty in the Mysore area. Or you can draw [or import a scan?] a glyph and have it do pattern-matching, giving you a probabilistic analysis of which already-known glyphs match your new one the most.
As of now, it ships with a database of Brahmi, consisting more than 700 scriptures of more than 170,000 glyphs total.
It's great that they develop these tools, and it's even better that they are published as public domain software. What would be even better, is if they made their software Free Software and publicized the source code. This way other people could contribute and e.g. add a much-needed non-German localization, a precondition for any kind of international (e.g. Indian) use of it.
Maybe I can find a minute (and a minute of their time) to explain to them the marvels of Free Software.
I've had the chance to watch Swades at the home cinema of a friend. Swades is a quite impressive film, and definitely [for me] one of the best recent Bollywood films.
I think the most interesting aspect is the way how they display the transformation process of an initially extremely alienated NRI (officially "Non Resident Indian", in the movie jokingly referred-to as "Non Returning Indian") back ti a "true Indian".
Today wasn't exactly the most efficient day of development I ever had. Basically, the amount of progress made after 13 hours of hacking in the area of EZX device drivers is extremely slow. It didn't even help to not eat, not cook, and not get out of the bed for the whole day. Basically I started with "let's fix this quickly before breakfast", but it wasn't fixed even when I stopped working at 11pm.
My new SPI driver seems to be working fine, but I have massive problems with all the PCAP drivers. This is mainly touch-screen, but also ADC for reading battery voltage, etc. Somehow I cannot get it to produce any IRQ's.
In order to get other developers going quickly, I have now provided a Debian sarge (arm) root filesystem and a corresponding kernel plus instructions.
Anyone who wants to see a stock Debian installation boot on his EZX phone, have a look at the files published here.
I've finally found the time to configure the OpenEZX virtual host. This means that I now have absolutely no problems to hand out developer accounts on openezx.org. I've also moved the EZX related subversion repository from gnumonks.org to this machine.
If you're working on free software for Motorola EZX smartphones, and are interested in getting some account where you can host your project(s) in svn / git, dump some code on http/ftp or just want a openezx.org email address, please let me know.
I've been working a bit on getting Bluetooth and GPRS/GSM support into my 2.6.x based kernel for the A780. Both are quite a bit challenging, even more than I initially thought so.
As for Bluetooth: In theory there is a bcm2035 chip, compatible to the Bluetooth HCI specification, attached to ttyS1 (BTUART) of the PXA270. However, there are some power management related additional signals hooked up to GPIO signals. I think I'm configuring them right, though. Also, there is some indication that the bcm2035 actually requires a bit of firmware loaded into it. Without a vendor data sheet and with only some stripped proprietary Motorola dload program this will require quite a bit more of investigation.
My initial 'demand' for Bluetooth would have been the possibility to use my Apple BT keyboard with the framebuffer console, providing a local console in case telnet dies for some reason.
On the GSM/GPRS front (yes, we actually want to use the phone as a phone sometimes), I've been wading through disassembled gprsv.o and mux_cli.o code. Both re-implementations are progressing slowly, but steadily.
The easier part seems to be mux_cli.o. I've now started to write some libusb based userspace code to test a ts07.10 implementation in userspace via the USB endpoints to the BP. Once the userspace code seems to be working, I can work on a kernel level implementation. The good thing about this is that there are actually quite a few GSM phones that support this multiplex on their serial port. So the resulting mux/demux driver will actually be useful for more people, not just Motorola Linux smartphone owners.
Together with Milosch from bitmanufaktur.de, I've spent a couple of days and nights working on building our own 2.4GHz active RFID system. The parameters are: Battery powered, small transponders based on the Nordic Semiconductor nRF24L01 and a ultra-low-power PIC micro-controller. Base-stations have the same nRF chip, plus an Ethernet-enabled micro-controller. Operational range is ~10 meters, we even made it through two walls in our preliminary tests.
So what's the point of all this? The goal is to have that system in operation at the HOPE Nr.6, and to give a practical demonstration on how feasible it is to track people, make protocols on who has spent how much time in which lecture hall, etc.
I'm not involved with HOPE at all, but was only involved in writing firmware and higher-level code for the two embedded systems involved, as well as some testing.
I'm looking forward to learn how the system will perform with several hundreds/thousands of transponders at its first real-world test at HOPE. With some luck, we can have the same system at 23C3 in December this year in Berlin.
Until then I'm certainly going to try to implement my idea for peer-to-peer time slot synchronization of the transponders. I had that idea as a solution to avoid collisions between transponders while working on the project. Unfortunately, the current transponder hardware doesn't have a low-power timing source that is precise enough for such a protocol. Adding a 32.768kHz low-power quartz should do the trick - but will inevitably also make the transponder more costly.
Kudos to bitmanufaktur. I wouldn't even dare to try to design a PCB for 2.4GHz RF...
Yes, I survived. Now I need to address that backlog of real world issues and emails...
The last two days I had a rental car. First I visited "Vila Velha"
Vila Velha really is both beatufil and impressive. Took lots of pictures of those unique rock formations dating back from the ice age.
On the next day (after some OpenEZX hacking) I first drove to Santa Felicidade to visit the cemetery there. Took a couple of pictures, since it is quite unique in that it is a very urban cemetery. Multiple storeys (!) and all concrete floors. Obviously, people can only put urns there, no dead bodies...
Next I drove to the Graciosa road, which I still remembered from my trip to Morretes five years ago. The Graciosa road is the old connection between Curitiba and the harbour. It leads through the few 3% of remaining "mata atlantica", south Brazils version of the rain forest. It's a small, extremely curvy road with lots of viewpoints to the surrounding mountains. Also did a short walk into the forest, tried to take a couple of pictures of an amazing ant trail which must have been multiple hundreds of meter long.
So apparently there is no obvious reason for Motorola's driver using bit-banging rather than the controllers inside the PXA270. I now have a modified Motorola driver on 2.6.16.5 running that uses the SPI controller for the bus to PCAP2. Getting my own driver running should therefore be quite fast now.
I've also hacked a bit on the keyboard side, although it's not working yet.
One of the fundamental interfaces on the Motorola EZX phones is SPI, which interconnects (among others) the PCAP2 peripheral with the PXA270. Motorola ships their 2.4.20 kernel with some ugly piece of spaghetti code driver for it. Apparently they've had difficulties driving the PXA27x SPI controller, and in the end decided to just 'bit-bang' the signals over GPIO. Obviously that's inefficient and CPU-intensive. I hope there is no real hardware problem preventing the use of the embedded SPI controllers.
First I started writing a driver against arch/arm/mach-pxa/ssp.c, only to discover later that this code actually predates (and therefore doesn't use) the generic drivers/spi/ interface. Since I'm a fan of generic interfaces, I chose to write a PXA generic driver for the drivers/spi interface, plus some EZX specific glue code for it.
One of the interesting bits is that the PCAP2 can interrupt the PXA, and it then acts as an external interrupt controller, whose registers you can access over SPI. So a PCAP2 interrupt can mean that some touch-screen event happened, that the headphone, USB or microphone jack state has changed, etc. All those various real interrupt sources need to be fed to individual distinct drivers (audio, touch-screen, USB). The Motorola kernel uses an ugly kludge of callback functions that those drivers can register with the SSP/SPI driver.
So in my new driver, I choose to actually model that bit of PCAP2 functionality as an external interrupt controller. This way the actual sound/touch-screen driver can just do request_interrupt() like they usually do. However, this means that I need to access SPI from within hardirq context, which again doesn't mix well with the architecture of the drivers/spi code (which is asynchronous and queues requests). So I need to implement a couple of synchronous SPI functions in addition to that.
This is now a lot of code, and I'm about to test and debug it, which is expected to be time-consuming and boring. I'll post a status update as soon as there's more information.
Tomorrow I'll be on a 11 hour bus ride from Porto Alegre to Curitiba. I'm voluntarily using the bus rather than the plane. Since everybody thinks I must be crazy for doing so: First, I don't really have any idea how the landscape/countryside in that area looks like. Second, I haven't really spent all too much time outside of the big Brazilian cities yet. Third, I have the time to do it (and two laptop batteries). Fourth, it's more friendly to the environment... my intercontinental flights consume way too much kerosine anyway.
One of the things that I've always missed the most, ever since leaving Brasil in 2001: "pizza doce" (sweet pizza). You can have it with chocolate, coconut, banana/cinnamon, caramel, ice cream, etc.
Yesterday I just had to make use of the opportunity and have lots of it in one of the nice all-you-can-eat pizza places that are common in Brazil. There also was the opportunity to introduce some of the other foreign speakers to this Brazilian interpretation of Italian food :)
After lots of hacking at FISL 7.0 in Porto Alegre, I've managed to get the PXA27x USB device controller to work in USB Ethernet emulation to work. I can now actually ping and telnet to the 2.6.16.5-running E680, using a debootstrapped Debian/ARM on SD-Card.
I'll publish the patches in one or two days, when everything has stabilized a bit, and the debugging code has been removed.
Also, at the event here, I've managed to convince quite a number of Free Software people that those Linux smartphones are actually quite interesting toys. Most notably, Keith Packard of Xorg fame has indicated he would probably be getting one and working on a lightweight UI. This motivates me even more to have a stable and fully working kernel environment finished soon.
So finally it's happening: I'm currently sitting in an airplane, already deep into .br airspace. Ever since I left Conectiva/Curitiba/Brazil in quite a hurry in late summer of 2001, I intended to come back. My original plan then was to take Elisabeth with me and show her what I've experienced in those six months of Brazil. Also, due to my way-earlier-than-planned departure from this fascinating country, I missed many of the things I had planned originally - such as travelling to the northeast and the amazon region.
But just like that never worked out the way it was planned, I now find myself in an accidental symmetry: I left Brazil to live with Elisabeth - and just after that has ended now, I get back to Brazil. No, not moving back - but at least two weeks of visiting ex-colleagues, (ex-?)friends and places I have known and loved.
At a time of such fundamental change in my life, I feel excited about any kind of new adventures, possibilities, etc.
Due to time restrictions, this is unfortunately not the time when I will be doing all the travel that I originally intended. I'm really too much involved with my many non-profit projects, and besides that I somehow have to earn a bit of money, too ;)
But I'm quite sure that at some point I'll come back. Talvez um pouco mais preparado, depois de ter aulas de portugues. Acho que e muito dificil no Brasil sem falar a lingua nativa.