The last couple of weeks have again been so busy that I didn't find the time to update this blog. After returning from the Taipei trip, as usual, there were tons of things to be done for OpenMoko. Later I spent about one week on a business trip to Bangalore, from which I've returned monday afternoon.
Now I'm only home until thursday next week. Next friday, I'll once again depart for Taipei to speed up and coordinate OpenMoko/FIC development.
Some time ago, Jeremy Kerr wrote patchwork, a tool to semi-automatically keep track of patches submitted to mailinglists.
So far, it was mainly being used for the linuxppc and netfilter project with mixed results. I guess in both projects, in the end, nobody raelly maintained the patch status and stuff just ended up to get stale.
Now I've started an patchwork installation for OpenMoko, at least for the most common public mailinglists. So why do I think patchwork will be used more productively and receive better maintenance? Well, firstly, the number of patches on those lists is still quite small. Secondly, the number of people looking into reviewing those patches, within their primary paid-for working time, is relatively large.
I really believe that patchwork can provide an enormous benefit to a project. Let's hope we manage to use it correctly :)
Just returning from one of the probably busiest weeks in my life. The entire week was spent with meeting lots of FIC staff. Finally I'm able to connect faces to the members of the hardware and production testing team located in Taipei.
Significant time was spent talking to vendors of WiFi chipsets over the last week. The choice seems to have boiled down to designs around Atheros AR6K or Marvell 8686. The AR6K driver code is completely public for quite some time, even though it (and the mvista SDIO code it depends on) might need a bit of cleanup. From Marvell we yet have to find/receive the GPL licensed driver source code - at least from our [high level official] marvel contacts we have received positive confirmation. So actually, for now, only AR6K is a 'known possible' choice, whereas Marvell might become a choice, once we see the source :)
The other big task was sitting down with Werner Almesberger and doing the system level design for the next major hardware revision, and discussing this design with the hardware team. A lot of things are still in flux. But at least the potential of it is _really_ promising. Details are to be revealed at their appropriate time.
I've also had the chance to briefly meet with senior management such as the head of the mobile communications business unit, as well as the CEO and the chairman of the board of FIC. Everybody seems to be really excited and looking forward to the time ahead, now that we have identified many of the problems in the hardware design, production quality and internal processes and are heading to a much brighter future.
Another interesting opportunity was to present at Taiwan NTU University on the 'correct' way of doing Linux development, both technically and from the GPL / policy point of view. Let's hope we now have a couple of more software developers who will know these things before entering the industry :)
In retrospective, I should have done this trip way earlier on. But then, many things have changed over the last nine months, and it might have been an entirely different experience.
Taiwan/Taipei really seems to be an incredibly interesting place. A world of never-ending possibilities in the field of computer hardware. An industry that can produce about any device of your dream - but doesn't since it seems to be locked too much into either the master/slave role of traditional OEM/ODM business - or into producing the same things like all of their competitors, without really trying too much new/exceptional things.
So it seems, after all, my good intentions about travelling less in 2007 seem to be vaporizing sooner than I would have liked. I guess the productivity gain of me being in Taipei at least from time to time is worth it...
On my China Airways flight from Frankfurt to Taipeh, I have continued my tradition of watching the [usually] only Bollywood movie that the in-flight entertainment system offers. In this particular case, it was Dor
I had not yet heared/read anything about that movie, and not even the name sounded familiar. So I was a bit skeptically if this was one of those cheap superficial "B-class" movies that I try to avoid.
To the contrary. What seems like a low-budget production without any major actors [that I would recognize], is actually a masterpiece. Very unlike the cliche Bollyowood, it is not "overdone". Nothing is exaggerrated into self-irony. Everything feels real, down-to-earth. No princess-like costumes, no palaces and no super-rich Indians in their mega-cities. This impression is further substantiated by the somewhat simplistic editing. Scenes end abruptly, and the audio track does not spawn such 'hard cuts' smoothly either.
Dor is a sincere and honest movie about two women who have nothing in common, and come from completely different cultural backgrounds of Indias diversity. However, both of their husbands go abroad to work in Saudi Arabia very soon after marriage. A terrible accident involving those two Indian workers sets the stage for the remainder of the plot.
The whole movie is shot at various locations on the country side. The only remnescent of modern india is a cell phone with SIM card, and the mainstream bollywood songs that are sometimes playing on some squeaky radio.
It seems like this is the next DVD on my 'to-buy' list. Let's see if I manage to pick it up during my trip to Bangalore in early April.
On rather short notice I am now on my way to Taipeh, Taiwan. As the interested reader of this journal will have noticed, OpenMoko and the Neo1973 are the seemingly endless story of delays and mishaps throughout the last nine months.
So the purpose of this trip is to discuss various options on how to make sure that we all learn the neccessary lessons out of this past experience, and ensure that OpenMoko eventually can at least keep up to some of its schedule promises.
So this will be a week full of meetings and discussions mostly with various managers and particularly the hardware team at FIC, our generous sponsor.
What is at least equally exciting are the planned meetings with various WiFi chipset vendors to discuss our requirements of a mobile-phone compatible low-size, low-power WiFi chipset with a fully GPL licensed Linux kernel driver.
The downside of all this is that I'm once again held back from writing some of the most important infrastructure code that OpenMoko still needs. Anyway, this compromise has to be made - after all, of what use is software without a high-quality, reliable, performant and available handset hardware :)
Since Werner doesn't have a blog, old-fashioned as he is, let me mention that he'll be there for the whole week, too. I think it's a 34-hour trip for him to get from Buenos Aires to Taipeh. I wonder how well he'll survive that...
I just received SPAM from apple: "Mit dem Mac ist Codieren immer und überall möglich." and further down "Codieren. Kompilieren. Berechnen."
Seems like a multi-billion multi-national company cannot even afford some native speaker to proof-read their advertisements. Quite embarrassing.
Last night, I was once again annoyed by the slow build time of our dual AMD64 2.4GHz build server, and I wanted to use my Apple G5 quad again as a build/compile system.
So I pressed the power button, and immediately in that instance there was an extremely loud BANG!. No smoke, no smell, just that bang. Standby/trickle power was still there, the LED's kept shining.
I quickly opened the case, too off the covers, etc. There is no visible component that has suffered any damage. No leaked/exploded capacitors, no residue from some electrical spark, nothing.
And then I found out: The machine arrived on February the 2nd, and now it's exactly one month after the 1 year warranty has expired. I wonder how they can time their system failures that well :(
A little bit later I found out about the Apple Power Mac G5 Repair Extension Program for Power Supply Issues. It seems like this is a common bug, especially when you see things like this lengthy list of people who report a similar effect.
Seems like I'll have to call some local Apple dealers the first thing Monday morning....
Whenever you think something is bad, it will come worse. We've had another hardware outage of one of our buildhosts during the creation of the images that were to be prepared for the "Phase 0" devices. Luckily, the build system is easy to set up on various machines, and we actually now have the build system on four hosts :)
It was a lot of stress to resolve the most important issues just before flashing those 50 phones. All kinds of last-minute problems showed up, such as a certain kernel module missing in the rootfs, etc.
Anyway, we managed to finalize it early Friday morning, and Friday + Saturday engineers in Taiwan used Werners fabulous devirginator to install u-boot, environment, splash screen, kernel and rootfs.
Unfortunately, due to all the delays we have been suffering, all those initial
recipients will receive is a very basic Linux distribution:
We have hardware support for all the components in the boot loader and kernel. The device now has a
boot menu that
allows you to switch to serial or USB=tty console. It will happily boot into
Linux, where it starts the X11 (kdrive) server and starts matchbox and looks
like a pretty standard GPE desktop.
Suspend/Resume is now working from the software side, i.e. you can suspend the Linus system into RAM and get back from it, all drivers are coming back into operation nicely. You can access back light brightness, battery charger state, Bluetooth, etc. The easiest way to work on the device is currently by using USB Ethernet emulation and then ssh'ing into dropbear that gets started during bootup.
So you might think ok, I'll get a fully open source Linux PDA with super-bright
display. But I wanted a phone!
We still have lots of stability issues with our native OpenMoko applications
currently, so there will not be a working/stable "dialer" application yet.
Instead, if you really want to try it, you can either manually use GSM,
or use to
So yes, we are delayed. Still, we have decided to ship those units to allow more people to hack on it as early as possible. The foundation is there, and it so far appears to be quite stable, too.
Also, software can always be updated, especially now that we have USB DFU support.
And now, finally, after a long time, I am looking forward to touch the GSM code again. Let's hope there are not too many urgent issues interrupting me next week. After all, we want SMS and GPRS support rather sooner than later :)
It wasn't sufficient enough that our main build server had memory corruption yesterday (in which case no RAID1 will help, because the buffer cache data is corrupt and gets written to both disks corrupt).
Today, I had the pleasant experience of finding something like three more or less independent severe hardware design bugs in the Neo1973. I know this is really sad news for those of you who are eagerly waiting for their "Phase 0" devices. But firstly, you have to understand how sad _we_ are about all this. Even more so, specifically, how sad I am, personally... [now working 14hours straight on this issue].
I was not involved in the early hardware design of the Neo1973, and was hired as a pure systems level software guy. Over the progress of this project, I've been involved more and more in hardware fixes / reviews / redesign. And it's been only now that I've had a more detailed look at the suspend/resume/wakeup related bits. Given the previous series of hardware bugs I should have probably been more cautious and thoroughly review the whole design from the beginning, but then: It is complex, time consuming, and I'm no hardware engineer either, just joe random hacker.
The good news is that we are able to fix all this in the next version (GTA01Bv4), and that there are likely-to-be-working hot-fixes for the already-produced Phase-0 devices.
Originally USB DFU support for u-boot was supposed to be finished yesterday. Now with those two days full of most serious hardware problems (server, prototype), I wonder what's going to prevent me from working on DFU tomorrow.
Despite the much-feared genirq and workqueue changes, it turned out to be way easier to merge our patches to 2.6.20 maintain than reviewing and back-porting all the relevant bug fixes from 2.6.20 down to our old 2.6.17.14 based system.
We probably wouldn't have been able to do this if Phase-0 wasn't held back due to Bluetooth hardware problems. So everything seems to have its positive side, too :)
Ben Dooks (S3C2410 Kernel Port Maintainer) has already picked some of our patches and is merging them, which is good. He also fixed a s3c2410fb bug in vanilla 2.6.20 which I discovered [and just worked around by porting s3c2410fb from 2.6.17.14. into 2.6.20, lazy as I am]
Today, I spent much time on restructuring our u-boot patches (getting them ready for submission) and actually submitting the first nine patches to the u-boot-users mailing list.
I also spent some time on proprietary software, after a _long_ time. I'm trying to get TI's GSM Modem Firmware updater ported from Windows to Linux. Eventually I want to be able to re-flash the GSM firmware from the S3C2410 side, not involving any PC and especially not any proprietary operating system ;)
I would love to see the firmware updater going public, too - but given the nature of the GSM business, that chance is close to zero. Which is ridiculous, since it doesn't reveal anything important at all. The GSM Modem will verify the cryptographic signature of the firmware image anyway, no matter what the downloader does. But well, we have different problems to solve than to engage in endless discussions anyway...
Today, We have added public access to
For the last seven hours I've been trying to organize the openmoko.org server setup into providing more efficiency / performance. It was really amazing. We were not on slashdot, not on any of the major news sites, but we were already having something like 40MBps aggregate outbound traffic peaks on our servers.
The two major performance bottlenecks were ViewCVS and Mediawiki. Quickly I installed memcached on one of our more idle boxes, and put two squid instances on two separate machines in front of the mediawiki, which then seemed to do mostly fine.
The ViewCVS apparently cannot be helped at all. What I found on the web is that it's apparently just very inefficient code, and there's little one can do without rewriting the code. I don't know whether that's still the current situation, but when the next peak comes, I'll probably just disable ViewCVS to save some CPU cycles.
In case you're interested: Our setup is currently running on four physical boxes, running a total of ten OpenVZinstances. One of the machines is dedicated to the GForge installation on projects.openmoko.org, the other one a (at least intended to be) dedicated buildhost where we do our OE builds.
While this obviously has been quite enough for the last half year, we now have different performance requirements. For Phase-0 this installation is probably still quite sufficient, since this first-couple-of-days peak is bound to cease at some point.
However, When Phase-1 starts (public availability of phones to developers by means of direct order), we will definitely need a more sophisticated infrastructure for our downloads.openmoko.org site, from where we will make available the full source code that our OE builds need, plus the full source and object code of every binary release we make. The idea is to have a round-robin DNS setup of geographically distributed machines.
So as of now, we're soliciting mirrors with large disk capacity. If you want to help us by providing a mirror (expected capacity requirement for 2007: something like 300GB) and bandwidth, please contact me at laforge@openmoko.org. We're particularly interested in the US and Asia regions.
Apart from that, a couple of secondary DNS servers would also help improving our availability. If you already have a bind installation somewhere and want to become a secondary DNS for openmoko.{org,com,net}, please contact me, too.
Finally, the good news is: We're down to 2..4MBps for now. Until the news appears on major news sites, I guess.
After having discovered that mailman doesn't use templates for its listinfo_overview page (the one you get when calling /mailman/listinfo without a list name), I quickly hard-coded our openmoko header into the python code. If somebody feels motivated to add proper templating support to all mailman pages (such as the 'options password prompt' and the before-mentioned listinfo_overview), you could help us out even with something like that.
Now I'll finally turn back to actual moko code. We have frame buffer support in u-boot since two days ago (splash screens are important for marketing), I'll now look into getting the CPU clock to 266MHz (we've had some issues with this) and finally, after all, TS07.10 multiplex and gsmd infrastructure, for which I consistently haven't found time until now.
As you can read in this announcement, there will be another [slight] delay in the release schedule for OpenMoko and the Neo1973 phone.
I'm really sad and sorry about this, since the core team has been working _very_ hard for the last couple of months to get this project somewhere. However, a combination of Murphy's law, our high demands on quality at every level, communication problems and a lack of FOSS-experienced developers have made progress quite a bit slower than expected. I won't even tell you how far we are behind the original internal schedule [It's an internal schedule, after all].
For somebody like me, who has primarily worked with and in the FOSS community, even in his day by day professional career for the last decade, there have been many cultural problems in this project.
I've originally been hired to take care of the low-level aspects of the system, i.e. boot loader+kernel porting, driver development, and last but not least the GSM communication infrastructure, as well as general consulting with regard to FOSS matters.
In the end (up to now) I have been doing tons of more things. I've been doing hardware related debugging, hot-fixing and consulting, providing lots of support for our internal development team, doing all the system administration, configuration and maintenance of our four physical and about 15 virtual machines (wiki, lists, gforge, svn, build server, etc.). Today I even spent a lot of time on web related issues [hey, I haven't done much web stuff since HTML4 and CSS1 came out], since we have committed to go public with our web sites public at some point.
We've had to teach people how to use request tracker, bugzilla, subversion, mailing lists, IRC. Those basic means of communication, natural for everyone ever involved in a FOSS project are all things that we had to bootstrap here.
Many of the things that are a complete given for me (and even us, the rest of the core team consisting of Sean, Werner, Mickey and myself) are not at all known, valued and/or respected [yet] by the various people and entities we had to relate in this project.
To give you a short outline about some of the issues we have been fighting to create our vision of a truly open device, targeted by developers for developers:
So e.g. for web designers, it's hard to cope with the demand that web pages should fully scale, not have any fixed-pixel width graphics/style, not contain flash, only make careful use of javascript, and should always pass XHTML / CSS validation. We don't want 'hacks', but clean themes/styles/templates in the native drop-in format that the respective applications (mediawiki, mailman, bugzilla, gforge, etc.) support.
For source code, people who have always worked in closed-source environment, and even with a concentration on embedded 'one time throw away' devices, it is a cultural change that the source code has to be maintainable, that it has to follow coding style rules, and that it has to be "pretty", since people will read it, and it will make a bad impression if the code quality sucks.
Our code is not OK if it builds once on some system, but the applications need to use autotools or similar mechanisms, be packaged for OE use, the package description needs to be verified and debugged, and the resulting builds need to be reproducible one everyone's system.
We do not use a vendor-supplied toolchain, but rather build our own. And yes, that toolchain also needs to be built 100% from scratch, and that process has to be solid and reproducible, just like the packaging.
For the hardware, we have to provide the interfaces that usually nobody wants to give people access to (serial console, JTAG, ..). We have to make it easy for people to update their firmware, rather than hard. We have to have safeguards in hardware, since we can't prevent people to reconfigure the battery charger algorithm in software. The battery should still survive this, no matter what happens.
Preferably using hardware components with open documentation (versus "the cheapest available that does the job") is a design criteria that almost nobody in the industry will be used to.
Also, whenever we use hardware with specs under NDA (which we tried to avoid in all place, the source code has), we have to submit that code to the vendor, and ask whether it is fine to release it.
All in all, this is a quite exciting thing. Making people think different, trying to get the values of Free Software into their mind set, even if only for this project. Most of the people (as in numbers of people) involved in the development so far have not had any relation to FOSS before. They might have done Linux based development, but only because somebody asked them to get something done, cheap and quickly. But that's now what we're after.
But this process takes time, and a lot of strength. And it's hard to scale if you only have three to four people who actually have a clue about all those things. So on the one hand, we have to learn how to scale better. We have to involve more people from the community, with the FOSS/hacker background, both as paid developers and the excited volunteers. So far Sean, Werner, Mickey, and myself have been powerful but 'lonesome' fighters in the corporate world with whom we had to interact.
I'd like to express my deepest thanks to FIC for funding this endeavor that must appear like strange little experiment to them. I'd like to thank for all the support we have received from the FIC hardware and software development teams. I know we've been always very critical, and probably still seem unsatisfied with many things. But it's nonetheless a unique chance to be able to do this at all.
I've suffered a lot during the last seven months, and I've never worked as hard in my entire life, spending at least 80 hours per week on this. Despite that, if you look at the actual results, both in software and hardware (in the upcoming days), you will probably see way more things that need to be done rather than have been done. You will probably think: What, you haven't written more code in that entire time frame? All I can do is ask you to read this mail to get a grasp about what has been going on.
From now on, I hope we can lead this project more into the community. Make it like any other FOSS project. Work will be way more fun. More creative people. More cool hacks. More freedom.
Please consider this as the beginning, not the end. We're just bootstrapping the world of as-open-as-possible mobile devices. There will be much cooler devices, and there will be much cooler software. I'm honoured to be given the chance to take a leading role in this.
The last two days I was adding support for USB serial (cdc_acm compatible) to u-boot for the Neo1973 phone. This is definitely a nice way to give developers access to the boot loader prompt, without having to have any special cables, the debug board, hackers lunch box or else.
Obviously, it's not the same as a real serial port. But given that you have a working u-boot in flash, and given you don't want to do boot loader development and rather concentrate on kernel/user space issues, then this definitely is a nice option.
The basic cdc_acm patch came from the handhelds.org SX1 project, so I mainly had to add a s3c2410 USB device controller driver for u-boot. Usually this is not that much of a challenge. The lack of documentation by Samsung is compensated by the handhelds.org s3c2410_udc.c kernel driver, of which by now I know every single line.
However, this one was really hard. I couldn't even get the control pipe to do all the tasks to enumerate properly on the bus. And that after having implemented the control pipe handling for a different device (OpenPCD) only half a year ago, so I basically still knew quite detailed what had to be done.
I read, and re-read, and re-read the code. Looked and verified the assembler output. At some point, I was convinced the logic of my code is correct. It must be some auxiliary issue. PLL configured wrongly, GPIO settings not right, whatever. I still couldn't find it.
After two days (one of which had 16 hours straight) it turned out that the problem wasn't actually the logic of the code, but it was pure timing. The u-boot usbdcore.c EP0 implementation had done a memcpy of 18 bytes in a code-path that turned out to be extremely time critical. Just not copying the device descriptor (which is only done for on-the-fly patching the correct EP0 packet size) everything immediately worked.
What a relief. I can finally get back to work on GSM related stuff.
Since sending hardware to Werner Almesberger in Argentina using DHL seems to be suboptimal, I decided to give FedEx a try. So I went to their web-site, and tried to register for a customer account / number.
What struck me first, is that they require you to enter both land-line AND mobile phone number. As if everyone had both these days. I know a lot of people who either only have land-line, or mobile. And obviously there are people like myself, who would never want FedEx to contact them via mobile at all.
Anyway. What I then got back was an automatic email (in German) indicating that the respective employee is "Out of Office till 21st of February", and that "e-mails to this address will not be processed during this time".
Whew, I thought. What kind of express. It takes only three weeks to get a customer number. Maybe I should resort to UPS next. *sigh*
Today [depending on the timezone maybe even yesterday], we started to inform those developers whom we have selected for the 'Phase 0', i.e. those who will receive a Neo1973 free of cost (including shipping). Those phones are scheduled to leave Taiwan on Feb. 11.
So this heads-up mail two weeks in advance is mainly to obtain shipping address, and ask whether there are any special customs related issues that need to be taken care of.
Yes, it is somewhat elitist to hand-pick people and then send them free hardware. But I don't really see a viable alternative approach for a start. Those recipients are people who are really known to contribute to the FOSS world, and of whom we think they would really like to contribute to this project.
Now some FOSS critics (or people critical of businesses engaging with FOSS) might say: Yeah, now you think the rest of your phone is developed for free. This is completely wrong.
This project is ran by people who believe in Free Software. It is from the community for the community. It is an important chance for Free Software and user freedom in this otherwise completely controlled mobile phone market.
Basically we have a hardware vendor (FIC) providing us with phone hardware, for which they
Now you might still think: "In the end, they will make the profit". This is only true to a certain degree. First of all, everything we develop is Free software. Everything but the hardware specific bits could easily be run on any other piece of hardware. So anyone who wants to either contribute code or hire capable developers could theoretically port the whole thing on different hardware.
Also, while we ourselves think that this product will rock, this is really a nice market. It's interesting for geeks, hackers and certain power users. Not unlike OpenWRT in the field of wireless routers - but with active support by the hardware manufacturer.
So I personally cannot believe any of those "they just want to get development for free" arguments and want to strongly encourage the interested community to join this effort and help us make Free Software a viable alternative in the mobile phone market.
The date and location for the 2007 Chaos Communication Camp have been announced, which is really good news.
As the interested reader might have noticed, a couple of days ago, the OpenMoko project has officially announced a schedule for the upcoming months.
Behind the scenes, everybody is giving his best to be able to fulfill that schedule. Anybody who has been involved in a project of this size inevitably knows that there are many problems and bugs to be resolved.
Today, for example, I was happy to be able to play back MP3 (and politically correct: Ogg/Vorbis) files for the first time on the Neo1973 phone. Those speakers can really scream loud, I can tell you!
In my part of the project, the boot loader / kernel area, there are also many bugs to be fixed. The bugzilla indicates 11 blocker bugs and five major bugs in that key area of the project that need to be resolved. The quantity might seem low, but some of them are quite generic, such as some important mechanism not working yet.
By now, we've also come up with a quite complete list of names for the 'phase 0', i.e. those guys whom we will ship a free Neo1973 device on February 11 (actually 12, since 11th is a Sunday. Hey, we're working on Sundays, only the shipping company isn't *g*).
Oh, and yes. The planet.openmoko.org is finally public. Even though there's not a lot of activity yet, expect way more in the next weeks, especially after mid-february, when we've put 50 phones into the wild :)
I've been gone for long enough. Even though neither my RFID projects nor OpenMoko are anywhere close to be finished, I'm determined to get back into netfilter work again.
Started to catch up with mailing lists. There has been amazing progress, most notably the implementation of NAT for nf_conntrack, which finally should get us rid of the old ip_conntrack code in one of the upcoming kernel releases. No more support of two versions in parallel. And the ability to do IPv4 NAT and IPv6 connection tracking on the same machine. Isn't that all that we wanted? Not quite...
So for now, I'm participating in the discussions again, and I'm now also working on getting IPv6 interpreter plug-ins into ulogd2. The nfnetlink_log mechanism can happily send IPv6 packets to user space, it's just that ulogd2 doesn't yet know what to do with them. That needs to be changed.
Just a short ping, I have been way too busy to do even the most important things of life, let aside writing blog entries.
I am not going to write about progress of any projects, because I absolutely don't even feel like talking about my work anymore. The workload is just too high, with no real end in sight. Things keep falling apart as fast as they come together...
I'm currently at the 23rd annual Chaos Communication Congress in my home town Berlin, Germany.
After having dropped out of my usual volunteer work in the Audio/Video recording team, I thought that this year would be slightly more relaxing. Then came the Sputnik system, which suddenly started to eat some of my time weeks and months before the congress, as well as the last couple days before the congress, during the build-up. In fact, given my many other projects, I was close to going crazy and thus dropped out of the project and disappeared completely from the congress for about one day. Sorry about that, but I just needed to relax and calm down.
After a very stressful 26th of December, the team actually managed to set the whole back-end and middleware system up on the first day of the event, and the 3D visualization was running by 4am of the second day.
Now I'm back to normal mode, present at the event almost all day, which I intend to do for the next two days, too.
Only two months after the involuntary absence of bugzilla.netfilter.org (due to database corruption while doing a gentoo mysql update), I have finally found some time (and a way) to fix the problem. Therefore, as of today, bugzilla.netfilter.org is now up and running again.
This was possible due to the fact that the bugzilla tables were still present in myISAM format. The mysql tables of patchwork.netfilter.org were not that lucky. They were stored in exactly that InnoDB file that got corrupted. However, the loss of archived (and lots of unmaintained) information on patches that had been submitted on netfilter-devel is not really all that important anyway.
However, let this be a lesson: Do daily dumps of all mysql tables in a cronjob before doing backups ;)
As I have just discovered today, the SMC WSKP100 is actually running a 2.6.9 Linux kernel (from the H3 sources made available by TI) running on a TI OMAP1701.
I managed to sniff the serial console and thus obtain a boot log. It runs u-boot, linux-2.6.9 and busybox. This basically makes this the ideal target device for a Linux-based open WiFi phone. Who the hell is interested in all this proprietary skype? I want a WiFi phone that is open. One that can run clients for SIP, or even H.323. Oh and by the way, it should support WPA-EAP as well as transport-level encryption of the actual voice data...
Due to the 1.8V nature of the serial port, I could only receive but not transmit (my transmitter outputs some 3V and is therefore not suitable. Which brings me to another point: Could somebody please design an universal serial adaptor, with a comparator at the input, where the user can adjust the voltage level for low/high distinction? And with a small DAC or variable voltage source for the Tx side?
As I've indicated before, the OpenPCD team is working on a free 13.56MHz RFID emulator, mainly for ISO 14443 A+B, but also ISO 15693. This project has been dragged on for quite a lot of time, both because of its complexity, and of my unavailability due to my involvement in OpenMoko and other projects.
Anyway, our latest generation of prototypes has now arrived, and we're proceeding nicely (but slowly) again. With some luck, the ISO 14443A anti-collision could work at the end of this day :)
By accident, I've discovered RFIDiot, a RFID exploration library and tool written in python. There is quite a bit of overlap with what librfid tries to achieve, from a functional point of view (written in C, of course).
So on the one hand, there's a lot of functional overlap on the high-level like mifare reading/writing, ePassport reading, ... - but on the other hand, all the lower levels seem to be missing in RFIDiot. I guess that's the price you have to pay for vendor-lock-in with a proprietary serial protocol like the ACG readers.
Once I find some time again (next year, feb/march), I'd definitely like to see whether there can be some kind of integration/cooperation between RFIDiot and librfid/libmrtd.