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...

Several days ago I've came across very good article "Embedded Linux versus Windows CE". The article itself gives pretty comprehensive and objective (to my biased view :) ) comparison of Windows CE and Linux. However I can refrain from adding my 2 cents. As far as I can tell, Windows CE allows to dive into application development really fast. You don't have to read a lot of manuals, search the web and build yourself really good background to became embedded Linux developer. You just open the wizard, several clicks and you have your Windows CE application ready. I'm not sarcastic. It's true. But, IMHO, this is true only for application development and simple tasks in BSP development.

Things are getting more and more complicated as you move on with your BSP project. And things get even more complicated when you need to integrate a device that is not supported by existing reference BSPs. In the best case you have a driver the chip vendor sent you. The driver does not necessary works on your architecture. Moreover, it does not necessary compile there. Windows CE still follows the ideology that each board should have it s very own driver for every device. It means that you have two boards with the same CPU and the same, say ethernet chip, you'll need two drivers for that ethernet chip.

My impression that Linux allows you much faster board bring up and hardware enabling. But, the application development is still easier for Windows CE.

Although I cannot understand how a programer can live without grep....

I thought about starting a technical blog for a long time. But there always were much more important things to do than post some random thoughts nobody will read anyhow...
After all the desire to have a place where I can share my thouhgts and experience at least with myself has won :)