Yesterday we've had a launch of public beta in Ravello Systems. So, now I can openly talk about what I've been doing for the last year and a half :)

Launchpad Bug 571663

Several month ago OMAP3 SoCs were added to the list of ARM platforms supported by Lucid Lynx. And it was really disappointing to see that the only OMAP platform that’s not included in the Ubuntu kernel is the one I maintain...

So, I've opened a bug in the Launchpad and after three months of silence the bug is resolved as "Won't fix". Really annoying...

drivers

It's very entertaining to hear people talking about Linux device drivers for particular platform. For example, "we have developed drivers for our chip for omap3evm". Or "our driver perfectly works on Mainstone therefore porting it to your PXA platfrom should be realy easy". And the best one "How much time would it take to make the driver we used with PXA270 work on PXA300?".
I admit I was not there in the VxWorks days. More than that, I almost was not there in 2.4 and early 2.6 kernel days. But making such statements now when driver model exists in Linux kernel for several years sounds real nonsense. In Linux either you have a device driver or not. It cannot be a driver that works on platform A and fails on platform B. If an SPI network chip has driver for a single development platform, or even worse, lot of

#ifdef PLATFORM_A
  ... some code ...
#elif defined(PLATFORM_B)
  ... some other code ...
#endif

fragments in the driver, it means that this chip has no Linux device driver.

LPC

I had a really busy time last month. Being ten days off at the end of October made very backlogged at work and it was not that easy to catch up.

So, at the end of October I was at LinuxCon and LinuxPlumbers. The first one was mostly about marketing of desktop Linux and business acievements in the server market. So, most of the talks were in the business spirit and somehow seemed bored to me, modest developer. Except, perhaps, the Kernel Roundtable, that was really entertaining.

The Plumbers conference, on the contrary, aimed the developers and most presentations and sessions were "development driven". Although most of the speakers were less proficient in presentations than Mark Shuttleworth or Jim Zemlin, it was much more interesting for me to attend Plumbers talks than LinuxCon ones.

Some concluding notes from the conferences:
- ARM chip vendors are pushing towards ARM net-top/net-book. Ubuntu Karmic Koala supports Freescale iMX.51 and Marvell Dove, and according to Canonical insiders Freescale and Marvel are behind it :)
- Intel tries hard to increse Atom MID devices market share and even enter cell phone market with x86 architecture. And, according to H. Peter Anvin, "New Intel low-power chip is not a PC".
- V4L will undergo large rework to target capture controllers found in modern SoCs
- People say that the best connection point between Europe and US is Frankfurt

Ubuntu ARM

These days I've checked how Ubuntu can run on ARM machine. TI claims that OMAP3 gives "Laptop-like performance at handheld power levels in a single chip". And there's no way you cannot run Ubuntu on a laptop.

Once one of our hardware designers said: "You cannot do hardware verification with Windows CE. You never know if it's hardware defect, Windows CE generic bug, or our BSP missing some initializations"

Choices are difficult

 Free software gives us a lot of choices. But sometimes the amount of alternatives is overwhelming. Well, probably, not that much overwhelming, but even if you have, say, three options, the choice is still may be really difficult.
 I'm to develop a BSP for new computer-on-module. It means I have to add the proper board support to the kernel and pack a sufficient userspace demo that emphyzes superiority of our hardware :)
 For the kernel part I have to choose between the mainline, the CPU vendor BSP kernel, and, say, Angstrom linux-xxx recipy.
 Using the mainline kernel has the benifit if relatively easy mainlining of my own patches. On the other side, BSP kernel has way better support for the CPU features. And, finally Angstrom linux-xxx recipy allows smooth integration of my platform into the creation of entire distro.
 And the kernel to rebase on is really simple choice. The big question is what would be the userspace.
 The most simple option is to take the CPU vendor BSP "as is, without warranty, or techical support". This way I have to do almost nothing to wrap up the demo image. However, the very fist customer who'd use it will complain about lack of package X and application Y. Worse than that, the first customer who'd use such demo would fail to install or cross-compile that package X and application Y.
 Another possibility is, for instance, Debian, or even Ubuntu. You can easily install the full-featured distro in virtual machine, pack it to UBIFS adn you're done. But! It's far from being optimized, it would include things that noone will ever use, and, at least with Debian, you'll end up with very old packages.
 What's left? Of course OpenEmbedded. Here you've got exactly what you want (well, mostly), you have binaries tuned for your architecture, you do not have such crap as manuals in your images and so on, etc. Unfotrunately, using OpenEmbedded for BSP creation implies that your customer has to learn OpenEmbedded. Which is tough. It's quite possible that your customer will get stuck on building cross-toolchain because his Linux installation has only desktop and multimedia components and OpenEmbedded may depend on somthing not included in "apt-get build-essential". And, that one is really annoying, several weeks after you've branched off org.openembedded.dev you get 404 from source repository mirrors.

So, the choices are difficult...