I’ll be present at the first Openmoko Workshop in Munich, gracefully organized by Dr. N. Schaller (Goldelico) hosted at the University of applied science in Munich. Topics will be developer-oriented, but beginners are also invited. There are only few seats left, so please contact Dr. Schaller via the freeyourphone.de forum, if you want to be on board.

I’ll be talking mainly about freesmartphone.org — the beginning (2002-2008, from handhelds.org to openmoko.org), the present (2009, how to program with FSO), the future (2010-, what the Vala rewrite will bring and how we get FSO to more hardware).

This is just a loose gathering to get started. If there is sufficient interest, we will consider turning this into a more formal (professional) training course in the future. Hope to see you there!

I’m currently involved in the Tracker project and our project will be presented by Ivan Frade at the Desktop Summit this Sunday.

We merged our experimental branch tracker-store to master. This means that our reachitecture plans for Tracker have mostly been implemented and are being pushed forward into the main development tree.

I will start with a comparison with Tracker’s 0.6.x series.

Tracker master:

• Uses SPARQL as query language
• Uses Nepomuk for its base ontologies
• Supports SPARQL Update
• Supports aggregates COUNT, AVG, SUM, MIN and MAX in SPARQL
• Operates for all its storage functionality as a separate binary
• Operates all its indexing, crawling and monitoring functionalities in a separately packagable binary

Tracker 0.6.9x:

• Uses RDFQuery as query language
• Has its own ontology
• Has very limited support for storing your own data
• Supports several aggregate functions in its query language
• Operates for all its storage functionality in the indexer
• Operates for all its query functionality in the permanent daemon
• Does file monitoring and crawling in the permanent daemon
• Operates all its indexing functionality in a separately packagable binary

Tracker master:

Architecture

The storage service uses the Nepomuk ontologies as schema. It allows you to both query and insert or delete data.

The fs-miner finds, crawls and monitors file resources. It also analyses those files and extracts the metadata. It instructs the storage service to store the metadata.

External applications and other such miners are allowed to both query and insert using the storage service. Priority is given to queries over stores.

Plugins that run in process of the application can push information into Tracker. We indeed don’t try to scan Evolution’s cache formats, we have a plugin that gets it out of Evolution and into Tracker.

Storage service’s API and IPC

The storage service gives priority to SELECT queries to ensure that apps in need of metadata get serviced quickly.

INSERT and DELETE calls get queued. SELECT ones get executed immediately. For apps that require consistency and/or insertion speed we provide a batch mode that has a commit barrier. When the commit calls back you know that everything that came before it, is in a consistent shape. We don’t support full transactions with rollback.

The standard API operates over DBus. This means while using it you are subject to DBus’s performance limitations. In SPARQL Update it is possible to group a lot of writes. Due to DBus’s latency overhead this is recommended when inserting larger sets of data. We’re experimenting with a custom IPC system, based on unix sockets, to get increased throughput for apps that want to put a lot of INSERTs onto our queue.

We provide a feature that signals on changes happening to certain types. You can see this as a poor man’s live search. Full live search for SPARQL is fairly complicated. Maybe in future we’ll implement something like that.

Ontology

We support the majority of the Nepomuk base ontologies and our so called filesystem miners will store found metadata using Nepomuk’s ontologies. We support static custom ontologies right now. This means that it’s impossible to dynamically add a new ontology unless you reset the entire database first.

We’re planning to support dynamically adding and removing ontologies. The ontology format that we use is Turtle.

Backup and import

Right now we support loading data into our database using either SPARQL Update, an experimental unix-socket based IPC, and by passing us a Turtle file.

We currently have no support for making a backup. Support for this is on priority planning. It will write a Turtle file (which can be loaded afterward).

Backup and import of ontology specific metadata

When we introduce support for custom ontologies it’ll be useful for apps that provided their own custom ontology to get a backup of just the data that has relevance to said ontology. We plan to provide a method to do that.

Volume support

Having a static custom ontology for volume support, volumes and their status is queryable over SPARQL. File resources also get linked to said volumes. This makes it possible to get the availability of a file resource. For example: return metadata about all photos that are located on a specific camera, although the camera isn’t connected to this device.

Volume support is a work in progress at this moment.

Years ago someone wrote IPKG in pure shell. It can be still found in some distributions. Then it was rewritten into C and this version we used in OpenEmbedded derived systems. It had some bugs, we patched some of them, from time to time there was even upstream development done for it.

Then Openmoko arrived and forked IPKG — new project got OPKG name. It was written by OpenedHand and Openmoko developers. Their main goals were:

• callbacks for GUI package managers
• GPG signed repositories
• fixing bugs

Many things got changed, OE patches got merged, new bugs was added. Those who use CLI version of opkg (so far the only usable client) lost some functionalities — for example there is no progress bar when packages are fetched.

For last few months OPKG is in unmaintained mode again and I think that this is some kind of curse on embedded market package managers.

Some time ago I discovered that when many (>50) packages needs to be upgraded then opkg segfaults during process and this is not a matter of going out of RAM as I have ~400MB free. Today it did not gave value of PATH for post install scripts… I wonder what else can be found ;(

What are other options? So far I know two — dpkg + apt or rpm + yum. First one costs few megabytes of space, second one require also Python so it is not acceptable for most of our targets. Both also require rebuilding of everything :(

Related posts:

1. Good bye ipkg, welcome opkg
2. How to install additional software into your OE generated rootfs
3. My Neo1973 has been sent

When checking the bike over I discovered the chain and sprockets are unlikely to last another trip out and one of the rear wheel bearings has play in it. I took some photos of the suffering of the bike:

A little bit of erosion

and plenty of scratches to the handguards.

A sick looking front sprocket

and a not much better looking rear

The front panel has finally been ripped from its mount on the radiator. This has been likely to happen for a while as it was already badly cracked. I haven’t decided how to fix this yet.

A standard bike footpeg

The footpeg I mostly rebuilt from bits of steel bar

The bike, showing signs of wear but not holding up badly considering.

• The Harvard Mark I - Picture Story - Tom's Hardware
  A Complete History Of Mainframe Computing

I went out on the bike on Saturday meeting up with three other local TRF people. The weather wasn’t too nice being think mist/drizzle in the Tyne valley and making riding with glasses + visor a pain. After going around Slaley forest we headed for the Wear valley and there was briefly sun for a while before the stop for lunch in Alston. Just before lunch the CRM developed a tendency to stall and refusal to start which turned out to be an oiled up plug – I had spares. Of note was the group leader falling into the Wear which makes a change from me falling off.

After lunch we headed back via some trails I’ve done before. On a downhill rocky section I picked up a bit of speed I had difficulty losing and ended up dropping the bike and sliding down the rocks with the bike on my leg. I was trapped under the bike for a while until I worked out how to lift the bike off without putting pressure on my leg. The bike boots did their job well and its just a bit bruised thankfully. The bike was fine after a little adjustment of the handguards.

Apart from the CRM stalling whilst holding another persons bike for a gate and refusing to restart, the rest of the trip was without incident. For this trip I had my new Garmin Oregon 300 in a pocket so I can now work out where I’ve been and start contributing to OpenStreetMap. I need to sort out a bikemount/batteries/charger for it but it seems to have kept a reasonable track of my position despite the horrible weather and being in a pocket.

As some of my readers already noticed there is WebOS SDK available for Palm Pre smartphone. Or rather “available” as it is leaked edition not normal release. I will not describe how to get it (using Google is enough) but rather how to get it run under Linux and a bit about what is inside.

The bad part is that SDK is (so far) available only as MS Windows binary. I did not tried it with WINE but used XP Pro installation on one of my machines to install it. There are two additional installations to be done first — VirtualBox 2.2.x is required by Palm SDK to be installed and Safari is required for “Palm Inspector” tool (which I did not got to work anyway).

After installation two important files: “palm_emulator_sdk_47.vmdk” and “palm_emulator_sdk_47.iso” can be found in “Documents and Settings/$USER/.VirtualBox/” subdirectories (they are also available in “Program Files/Palm/SDK/share/emulator/sdk47/” directory). There is also “Palm Emulator” icon on desktop which makes use of them.

So back to Linux. VirtualBox hard drive image and ISO needs to be copied to Linux machine and given for VirtualBox (configuration of virtual machine can be copied from MS Windows too). It is also possible to use QEMU to boot into SDK but it can be harder to find one with working mouse emulation. This is where their changes to QEMU or VirtualBox would be handy to get — adding 320×480px resolution to QEMU is few minutes work anyway (needs to change sources of vga bios and replace system one with tweaked copy).

What can be seen after boot? First error which I hope will be fixed in final release — “vga=864″ kernel parameter results in “unknown video mode” message. Anyway other modes are working and I suggest 640×480x16 as it has the same height as Palm Pre screen. There is a one problem due that — screen has wrong calibration so it is hard to use UI.

Some applications are coded in ugly style — seems to have 320×480px resolution hardcoded (Google Maps, Video player, Dialer). But there are also others which resize properly (Contacts, desktop). To play with them few key shortcuts are useful to know:

• TAB — runs launcher
• Escape — “minimize” application to a card

Looks like other keys launch search tool — I have to admit that I did not searched yet for documentation.

But what is inside of image and why it works? Image was built for “qemux86″ device by using OpenEmbedded build system — no new patches added. There is SSH daemon working in emulator so it is possible to login remotely and check what is in system. There are 697 packages installed (285 of them being kernel modules). Image looks like it was built on a same system as WebOS 1.0.3 image for Palm Pre (about which I already wrote few days ago).

Ah, I would forgot… There are few JavaScript examples in SDK if someone wants to know how to make “hello world” for WebOS.

Final thoughts — WebOS looks interesting and I would like to play more with it on real device. The bonus part is that it is even able to run classic PalmOS applications (but this is with 3rdparty application). Too bad that there is no GSM version yet.

Related posts:

1. Palm Pre and OpenEmbedded
2. Nokia N800 emulation
3. Building Poky Linux under commercial GNU/Linux distributions

From everywhere you hear the whining and complaints of local points of sale that the internet is taking away their business foundation. Whenever I buy a new device, I try to countervail this effect by going to my local shop to buy it there instead of doing the couch potato buying it over the internet. However 9 out of 10 times I get disappointed by them not having what I want in stock. If I wanted to order it to get it later, I had ordered it online in the first place

This morning I went to a local shop to buy a new communications device with a contract — these point of sales get quite a nice provision when people buy contracts. To my surprise, they had the device I wanted in stock and I felt growing excitement. Then I grabbed a piece of paper showing them a special employee rebate code I got from another employee and guess what… “oh, with these kinds of rebates devices can only be ordered at the support hotline”… WTF?

With this policy, points of sale will die — it’s inevitable. They are digging their own grave and I have no more symphathy.

Tinymail isn’t a sleeping project. I just stopped blogging about it. José Dapena Paz and Sergio Villar Senin are working very hard making it rock solid. Having worked together with Sergio a lot, I trust him. So a few months ago I made him Co maintainer of the project. He’ll probably perform the first release (or decide to do a few more pre-releases first). Being Modest’s technical maintainer Sergio has worked hard on and contributed a lot to Tinymail. Last few weeks José Dapena Paz is the guy who apparently is on fire, writing patches like a madman.

And it looks like there’s no stopping José! Maybe will GUADEC stop him for at least a few days? Maybe I should help Sergio a bit with reviewing all that stuff?

As far as I know will Modest be the default E-mail client on Maemo’s Fremantle device. It has been available for the N810 for some months of course, but for the Fremantle release I’m sure the guys have improved the user interface a lot. I, personally, have been working on Tracker and didn’t focus much on Tinymail. And of course I’m already thinking about how we can make E-mail part of that RDF platform. But that’s another story (and I think I wrote two articles on that already).

Anyway, just letting everybody know: people are still working on Tinymail. They just don’t blog about it as much as I used to do. No worries, though. They are doing great stuff.

Currently I am using Dell D400 laptop. It has few years and battery holds just for about 40 minutes. But it works still and is fast enough even to make OpenEmbedded builds.

During LinuxTag I played with different machines to check which things bother me most. As a result of that I created some kind of list of things which good laptop needs to have (order do not define priority):

• 1Gb ethernet card
• wifi which works ok with mainline driver
• hardware wifi switch handled by rfkill subsystem
• wifi status indicator
• bluetooth built-in
• hardware bt on/off switch
• bluetooth status indicator
• touchpoint (touchpad can even not be installed)
• comfortable keyboard layout (Fn not first key, cursors under right Shift key)
• WXGA resolution
• grapics chip with framebuffer in native resolution + working X11 driver
• backlight supported by mainline driver
• card reader (at least SD/MMC)
• 3 USB ports
• 4 hour on battery
• battery used also in few other models
• everything supported in mainline kernel

I can live without serial port because I have nicely working FTDI USB-serial dongle and most of time I do not use laptop to connect to developer boards. From the other side I do not like to waste precious port for Bluetooth dongle. FireWire, infrared, pcmcia, expresscard or smartcard are not required — I do not remember when last time I used any of those things. Integrated video camera and microphone are bonus but also do not required (but should work if present).

It can have any graphics as long it will provide me working framebuffer and X11 (at same time). But after fighting with my current one I would think twice before buying something with Intel chipset… I am afraid that they can forget about it existance like they did with 855GM which I use now (intelfb supports it but refuse to work with it). So it looks more like I need to check how situation looks like with ATI Radeon chipsets.

What to buy and when to buy is other thingy… Many people recommend Thinkpads, market will also be filled with ARM based netbooks soon which will rather do not cover most of requirements but should give much longer battery live. The choice will be hard but I have few months before my next conference trip.

Related posts:

1. Second is very long time
2. PowerTOP
3. It’s time to buy laptop…

Interested piece of information we just stumpled over is that the pulseaudio patch for the Palm Pre does contain a resampler module using the NEON support of the OMAP device. Strange to read, but should give them a good performance:

+#ifdef __ARM_NEON__
+
+#include 
+int16_t fir_simd(int16_t *x, int16_t *h, unsigned taps)
+{
+       int32_t sum;
+       int16x4_t h_vec, x_vec;
+       int32x4_t result_vec;
+   unsigned i;
+   
+   /* Clear the scalar and vector sums */
+    result_vec = vdupq_n_s32(0);
+
+    h_vec = vld1_s16(h);
+    x_vec = vld1_s16(x);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);
+      
+    h_vec = vld1_s16(h + 4);
+    x_vec = vld1_s16(x + 4);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+    h_vec = vld1_s16(h + 8);
+    x_vec = vld1_s16(x + 8);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+    h_vec = vld1_s16(h + 12);
+    x_vec = vld1_s16(x + 12);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+      
+    h_vec = vld1_s16(h + 16);
+    x_vec = vld1_s16(x + 16);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+    h_vec = vld1_s16(h + 20);
+    x_vec = vld1_s16(x + 20);
+    result_vec = vmlal_s16(result_vec, h_vec, x_vec);  
+
+   /* Reduction operation - add each vector lane result to the sum */
+    sum = vgetq_lane_s32(result_vec, 0);
+    sum += vgetq_lane_s32(result_vec, 1);
+    sum += vgetq_lane_s32(result_vec, 2);
+    sum += vgetq_lane_s32(result_vec, 3);
+      
+   /* consume the last few data using scalar operations */
+   if(i > 24) {
+       h += 24;
+       x += 24;
+       sum += *h++ * *x++;
+       sum += *h++ * *x++;
+       sum += *h++ * *x++;
+       sum += *h * *x;
+   }
.....

As in 2008 we (OpenEmbedded project) have a booth at LinuxTag conference in Berlin, Germany. And this time you do not have to go through whole event to meet us — we are at the start of first hall on mobile and embedded area which is sponsored by Tarent company.

This year most questions is about BeagleBoard (as usual) and FriendlyARM device (the one with WVGA screen). We have more devices available but there is a rotation of devices on a table to show something different each day. For example today we play the Big Buck Bunny movie in a loop using DLP projector.

We had some problems with USB on BeagleBoard B4 revision. Yesterday Texas Instruments (they have a booth in next hall — you can win BB there) gave us the C3 one and we got it working with our equipment.

This year I am staying in Avus Motel. This is the closest place to LinuxTag but also has some bad sides — yesterday I had long walk from WestKreuz station due to lack of S-Bahn which would take me to Messe Sud one.

Related posts:

1. TI: please fix your USB
2. Tosa USB experiences
3. FOSDEM 2007

I just did a test compile of the Palm Pre kernel using the released sources. Worked out fine. At least the patching and compiling, no real tests without the hardware.

I took the kernel package and patch from the Palm open source website and used a toolchain built by OpenEmbedded for the beagleboard. Using OMAP3 and armv7a should match here.

The 2.6.24 kernel package itself while renamed has the same MD5 and SHA1 sum as the original tarball from kernel.org (tar.gz, plain 2.6.24 no stable version).

The 9.5 MB patch applied fine and using the omapsirloin3430_defconfig as config let me compile a zImage without problems. Another developer seem to have tested a selfcompiled kernel, should match mine, already. Hopefully we can expect some updates here.

I’m on my way to LinuxTag 2009. Instead of a “real booth” like last year, we settled on a developer table in the hacking area — there we can present our Linux on mobile projects such as

• GPE
• FSO
• OpenEZX
• OpenMoko
• Gnufiish

in a more relaxed way — giving room to dive into some technical issues, when interested folks come around.

Find me there, if you’re interested in any of the aforementioned projects. I’ll be there until Friday afternoon.

Nearly month ago we got information that Palm company uses OpenEmbedded to build software for their Palm Pre smartphone. Two weeks later I read on Matthew Garret blog that there is root filesystem image available on one of Palm websites.

What is inside? Many interesting things — you can read about it on Matthew’s post so I will not repeat. If someone wants to look inside then please take a look at /usr/lib/ipkg/ directory. It contains packaging informations which shows which packages were installed, which files were used etc. It is clearly visible that they used OpenEmbedded with own overlay separated — OE was in /home/reviewdaemon/projects/nova/oe/foss and Palm overlay in oe/palm directory. The missing thing is IP address of “subversion.palm.com” server which is used to store additional sources (propertiary and free ones). What else we can find? Build information which says that rootfs was built at 2009.05.22 14:00:49. And according to audio setup files development started in September 2008 (if not earlier).

I wonder what kind of board they used as developer kit (they also used ARM Versatile emulation in QEMU).

UPDATE: Palm SDK uses “qemux86″ device from OpenEmbedded to run WebOS.

Related posts:

1. Palm SDK has leaked
2. My OpenEmbedded environment II
3. Packaged staging and what it gives

One of the biggest issues in mobile devices today is power management. On the one hand we expect that the device is always responsive, to user input and network events, on the other hand we want all subsystems to be powered (almost) off to save power.

read more

Occasionally I am asked how Embedded Linux compares with Windows CE.  I have spent the past 5 years doing mostly embedded Linux development, and the previous 5 years doing mostly WinCE development with a few exceptions, so my thoughts are no doubt a little biased toward what I understand best.  So take this with a grain of salt :-)  In my experience, the choice is often made largely on perception and culture, rather than concrete data.  And, making a choice based on concrete data is difficult when you consider the complexity of a modern OS, all the issues associated with porting it to custom hardware, and unknown future requirements.  Even from an application perspective, things change over the life of a project.  Requirements come and go.  You find yourself doing things you never thought you would, especially if they are possible.  The ubiquitous USB and network ports open a lot of possibilities — for example adding Cell modem support or printer support. Flash based storage makes in-field software updates the standard mode of operation.  And in the end, each solution has its strengths and weaknesses — there is no magic bullet that is the best in all cases.

When considering Embedded Linux development, I often use the iceberg analogy; what you see going into a project is the part above the water.  These are the pieces your application interacts with, drivers you need to customize, the part you understand.  The other 90% is under water, and herein lies a great deal of variability.  Quality issues with drivers or not being able to find a driver for something you may want to support in the future can easily swamp known parts of the project.  There are very few people who have a lot of experience with both WinCE and Linux solutions, hence the tendency to go with what is comfortable (or what managers are comfortable with), or what we have experience with.  Below are thoughts on a number of aspects to consider:

SYSTEM SOFTWARE DEVELOPMENT

Questions in this realm include CPU support, driver quality, in field software updates, filesystem support, driver availability, etc.  One of the changes that has happened in the past two years, is CPU vendors are now porting Linux to their new chips as the first OS.  Before, the OS porting was typically done by Linux software companies such as MontaVista, or community efforts.  As a result, the Linux kernel now supports most mainstream embedded cpus with few additional patches.  This is radically different than the situation 5 years ago.  Because many people are using the same source code, issues get fixed, and often are contributed back to the mainstream source.  With WinCE, the BSP/driver support tends to be more of a reference implementation, and then OEM/users take it, fix any issues, and that is where the fixes tend to stay.

From a system perspective, it is very important to consider flexibility for future needs.  Just because it is not a requirement now does not mean it will not be a requirement in the future.  Obtaining driver support for a peripheral may be nearly impossible, or be too large an effort to make it practical.

Most people give very little thought to the build system, or never look much beyond the thought that “if there is a nice gui wrapped around the tool, it must be easy”.  OpenEmbedded is very popular way to build embedded Linux products, and has recently been endorsed as the technology base of MontaVista’s Linux 6 product, and is generally considered “hard to use” by new users.  While WinCE build tools look simpler on the surface (the 10% above water), you still have the problem of what happens when I need to customize something, implement complex features such as software updates, etc.  To build a production system with production grade features, you still need someone on your team who understands the OS and can work at the detail level of both the operating system, and the build system.  With either WinCE or Embedded Linux, this generally means companies either need to have experienced developers in house, or hire experts to do portions of the system software development.  System software development is not the same as application development, and is generally not something you want to take on with no experience unless you have a lot of time.  It is quite common for companies to hire expert help for the first couple projects, and then do follow-on projects in-house.  Another feature to consider is parallel build support.  With quad core workstations becoming the standard, is it a big deal that a full build can be done in 1.2 hours versus 8?  How flexible is the build system at pulling and building source code from various sources such as diverse revision control systems, etc.

Embedded processors are becoming increasingly complex.  It is no longer good enough to just have the cpu running.  If you consider the OMAP3 cpu family from TI, then you have to ask the following questions: are there libraries available for the 3D acceleration engine, and can I even get them without committing to millions of units per year?  Is there support for the DSP bridge?  What is the cost of all this?  On a recent project I was involved in, a basic WinCE BSP for the Atmel AT91SAM9260 cost $7000.  In terms of developer time, this is not much, but you have to also consider the on-going costs of maintenance, upgrading to new versions of the operating system, etc.

APPLICATION DEVELOPMENT

Both Embedded Linux and WinCE support a range of application libraries and programming languages.  C and C++ are well supported.  Most business type applications are moving to C# in the WinCE world.  Linux has Mono, which provides extensive support for .NET technologies and runs very well in embedded Linux systems.  There are numerous Java development environments available for Embedded Linux.  One area where you do run into differences is graphics libraries.  Generally the Microsoft graphical APIs are not well supported on Linux, so if you have a large application team that are die-hard windows GUI programmers, then perhaps WinCE makes sense.  However, there are many options for GUI toolkits that run on both Windows PCs and Embedded Linux devices.  Some examples include GTK+, Qt, wxWidgets, etc.  The Gimp is an example of a GTK+ application that runs on windows, plus there are many others.  The are C# bindings to GTK+ and Qt.  Another feature that seems to be coming on strong in the WinCE space is the Windows Communication Foundation (WCF).  But again, there are projects to bring WCF to Mono, depending what portions you need.  Embedded Linux support for scripting languages like Python is very good, and Python runs very well on 200MHz ARM processors.

There is often the perception that WinCE is realtime, and Linux is not.  Linux realtime support is decent in the stock kernels with the CONFIG_PREEMPT option, and real-time support is excellent with the addition of a relatively small real-time patch.  You can easily attain sub millisecond timing with Linux.  This is something that has changed in the past couple years with the merging of real-time functionality into the stock kernel.

DEVELOPMENT FLOW

In a productive environment, most advanced embedded applications are developed and debugged on a PC, not the target hardware.  Even in setups where remote debugging on a target system works well, debugging an application on a workstation works better.  So the fact that one solution has nice on-target debugging, where the other does not is not really relevant.  For data centric systems, it is common to have simulation modes where the application can be tested without connection to real I/O.  With both Linux and WinCE applications, application programing for an embedded device is similar to programming for a PC.  Embedded Linux takes this a step further.  Because embedded Linux technology is the same as desktop, and server Linux technology, almost everything developed for desktop/server (including system software) is available for embedded for free.  This means very complete driver support (see USB cell modem and printer examples above), robust file system support, memory management, etc.  The breadth of options for Linux is astounding, but some may consider this a negative point, and would prefer a more integrated solution like Windows CE where everything comes from one place.  There is a loss of flexibility, but in some cases, the tradeoff might be worth it.  For an example of the number of packages that can be build for Embedded Linux systems using Openembedded, see http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes.

GUI TRENDS

It is important to consider trends for embedded devices with small displays being driven by Cell Phones (iPhone, Palm Pre, etc).  Standard GUI widgets that are common in desktop systems (dialog boxes, check boxes, pull down lists, etc) do not cut it for modern embedded systems.  So, it will be important to consider support for 3D effects, and widget libraries designed to be used by touch screen devices.  The Clutter library is an example of this.

REMOTE SUPPORT

Going back to the issue of debugging tools, most people stop at the scenario where the device is setting next to a workstation in the lab.  But what about when you need to troubleshoot a device that is being beta-tested half-way around the world?  That is where a command-line debugger like Gdb is an advantage, and not a disadvantage.  And how do you connect to the device if you don’t have support for cell modems in New Zealand, or an efficient connection mechanism like ssh for shell access and transferring files?

SUMMARY

Selecting any advanced technology is not a simple task, and is fairly difficult to do even with experience.  So it is important to be asking the right questions, and looking at the decision from many angles.  Hopefully this article can help in that.  For additional assistance, please do not hesitate to contact BEC Systems — we’re here to help.

For some people this post can be controversial. I added a category “controversial” to my blog for people who prefer to filter it.

We start a imaginary experiment where we start with a bottle filled up with food and room left for exactly two worms. We assume worms replicate at a doubling time of one minute. We observed in a previous experiment that the bottle is filled up in exactly one hour. They eat the food as they double themselves, etc (use your imagination).

At 11′O clock in the morning we place two worms in the bottle. At what time will the bottle be full (easy)? At what time will the bottle be half full? At what time is the bottle only 3% filled up?

Humans have a global population growth of about 1.2% per year. It’s about 1% in wealthy countries and about 2-3% in poor countries. If you want to calculate a doubling time you take 70 and you divide it with the growth percentage. Which means that at our current growth rate, we’ll double our total population in 60 years.

In 1950 we were with about 2.7 thousand million people, in 1990 we were with 5 thousand million people. In 2050 we will be with 10 thousand million people. Infinite growth isn’t possible with finite resources. In 2400 years, at current growth rate, the earth’s mass will in theory be roughly equal to the total amount of human flesh.

The main question is, how big is our bottle? Let’s go back to the worms. For the worms the bottle is about 3% filled up at 11:55. It’s half full at 11:59. It’s overpopulated at 12:00. When three new bottles are found and pipes are connected with the first, the three new bottles will be filled up at 12:02. After that will four new bottles be filled up at 12:03. After that you need eight new bottles to survive minute 12:04. In minute 12:05 it starts getting crazy proportions.

Even if our bottle is only 3% filled up now, then still at our retirement age we will inevitably be at 50% capacity. During those retirement years we’ll see the population grow at an enormous speed to maximum capacity within a few years.

I’m among the people who believe that we’re already at 70% capacity of our planet. I think we have about 30 years of finite resources left: doubling the population to 10 thousand million people, is impossible (not unreasonable to think). Moving to another bottle will take us at least several more centuries of top notch space science (so this solution is not applicable). And that’s assuming we can leverage the resources of another planet. Moving to another star is simply out of the question unless we invent technology that allows us to let a huge mass travel at the speed of light (again, the solution isn’t applicable).

A solution that I have in mind? Genetically modifying newborn humans to have an annual fertility frequency and having their fertility enabled at a mature age. Instead of based on the phase of the moon would women be fertile only once per year. And instead of at the average age of 12 would women start becoming fertile at the average age of, for example, 25.

Is genetic modification immoral? Being an atheist I don’t have any believe system that forbids me to tamper with species. It’s indeed still immoral because we don’t know what we are doing, yet. No, morality is not divinely injected by a God. Atheists are born with morals, too.

But if we have to choose between living with each other under the condition of having insufficient resources, or making a change to our species, I know which of the two I will prefer.

Now, if you do believe in a God, then you must also acknowledge that your God’s intention was for us to become intelligent enough to genetically modify our species. If not, why ain’t it stopping us? We, for example, have successfully been genetically selecting dogs for centuries. And we have started genetically modifying them (active modification: interfering with the egg and sperm cells).

Mankind will have to open this difficult discussion sooner or later.

Next week I will spent the better part of the week at the LinuxTag. I did not submit a talk this year and I will try to spent my time on hacking and relaxing. :)

There will be a table for linux on smartphone people in the dev center. People from various projects are planning to hang out there and do some hacking. I for my part will bring my phone collection and will hopefully spent most of these four days on getting something more working on them.

As the LinuxTag is an international event a thought jumped into my mind. I'm interested in the new Palm Pre. Especially in the hardware and the lower level parts. Anybody coming to the event who has such a device? If yes, please make sure you grab me and we can have a talk. I would like to see the device and maybe gather some informations on the device itself via a root shell. :)

Due to some money constraints I will not be able to buy one right now. (Yeah, I know it's CDMA and I'm not able to use it here in germany as a phone, still I believe that if we want to work with this device we should do so as early as possible and there is enough to do before the GSM version will get released). Anyway, LinuxTag may be an event where people with such a device are around. :)

Yesterday night I discovered that Palm had released the open source packages used in the WebOS for the current Palm Pre device. The table shows the used open source packages, a link to the original tarball and a tarball or compressed single patch with the changes Palm made, if any.

Most interesting for me was of course the changes to the kernel. (Being more interested in the actual device running linux already then in the WebOS software, even if I like a lot what I have seen and read so far.)

The kernel, version 2.6.24, is one of the packages where only one big patch is available against the original source package. Tiny 9.5 MB in size.

Next to the code they need for their hardware they also have things like KGDB and as it seems a big OMAP patchset from TI inside. Makes sense as the OMAP3 in .24 would have not been that good. It improved a lot over the last months, but I have no idea if Palm favours a kernel upgrade for newer WebOS releases.

The defconfig given in the patch matches the /proc/config.gz on the device. Only two variables for OE build tracking, CONFIGOEBUILDINFO and CONFIGOEBUILDINFOSTRING, are added on the device. The device was codenamed sirloin it seems. Defconfig is available as omapsirloin3430defconfig.

As the hardware is already known for the device I will not go into the details here. On thing I hoped for was that the MSM modem may be connected to a dual port ram so it matches the setup I have on the Samsung Omnia here. Sadly it turned out they use a combination of UART and USB.

• 45+ Essential WordPress Plugins for Pro Blogging

My friends just told me that you can get the sourcecode from this place. Or a direct link to their WebCore modifications and WebKit modifications.

I use Nokia E66 phone. It runs S60 3rd edition FP1 (aka Symbian 9.2). When I switched to it sending files over Bluetooth was easy: obexftp -b BD:AD:RR:EE:SS:00 -p FILE1 FILE2 and files landed as messages in phone Inbox. But for some time it is not working — all I got was “Sending FILE1…failed” like messages.

Hopefully obexftp tool has some options available so after some tests I got it working. And result is even better as files lands in file system instead of Inbox. The trick is to give path on phone to obexftp: obexftp -b BD:AD:RR:EE:SS:00 -c E:/folder/on/card -p FILE1 FILE2 and files will land there.

Simple, nice and the most important: working :D

Related posts:

1. New phone: Sony Ericsson K750i
2. Bluetooth + phone == remote control
3. MP3)"> MP3)">Converting ringtones (WMA -> MP3)

I just got my hands on a Android HTC Dream aka T-mobile G1. Originally I did not want to get any of those "unfree" Linux devices but a customer wanted me to buy and configure it for him so I thought that might be a good opportunity to play with it and accepted the deal. So here comes my report about it...

read more

I continue my work on different phones and phone platforms. Last monday I received a Samsung SGH-i900 Omnia device for some initial Linux hacking and especially trying to figure out how the modem interface is working.

It was an interesting adventure so far. :)

I updated Harald's initial findings with some new facts and corrections. In a nutshell the device looks like this:

• Application Processor: 624MHz Marvell PXA312, probably a PXA310 with NAND
• (256MB) + DDR (128MB) in one package
• GSM/UMTS Modem: Qualcomm MSM6281, interfaced via dual-ported RAM
• Wifi: Marvell 8686 (SDIO on mmc2)
• Bluetooth: CSR 41814
• 8/16 GB external SD flash (on mmc1)
• Audio Codec / Touchscreen: Wolfson WM9713
• Screen: 240x400 pixels, 3.2"
• 5MP Sony IMX034 camera with LED flash
• Bosch Sensortec BMA020 Accelerometer
• Ambient light sensor

We have linux mainline support for the PXA312, Marvell 8686 wifi, CSR bluetooth and the WM9713 audio codec and touchscreen combination. That's a nice start. Given the fact that the device seems to be pretty near to what the Marvell zylonite reference design is doing an initial linux port should be pretty straight forward. I gave it a shot and it really worked out pretty smooth for the initial bits. Patch for inclusion just sent. I can boot into a rootfs on the microSD card with this, including working framebuffer. :)

To get more informations about a windows mobile based system Haret is the tool of choice. Naturally I used it to gather some more informations about which GPIOs are connected to what, power up and down sequences of different chips, etc. On the other hand Haret had PXA support up to PXA27x so far. That works not that bad, but the IRQ and clock register have changed a lot. Thanks to Marvell the PXA3xx data-sheet are public available. Based on that I started some initial PXA3xx support for Haret. Not finished, but helped me already a bit on understanding the Omnia system.

I also started to investigate the modem interface, which is still the primary goal here. The MSM6xxx modem chips are used in other Samsung devices and the A (for CDMA) variant is also used in the new Palm Pre. Getting support for this modem into linux would help a lot on the open phone front.

The modem is connected to one side of a dual port ram chip. The other side interfaces to the PXA SoC. Next to this we have at least one GPIO connected for power up and down. I should have found that one with haret watching GPIO changes when powering the modem on and off in windows mobile. What I don't know yet is if there are other GPIOs for out of band signaling when the ram buffers are filed, etc. Future will tell.

What blocks my work on the modem is the non-functional USB device controller. Without is I can't get a shell on the device, which makes the testing and debugging pretty hard. Getting this blocker out of my way the next big item on my list. I may also get a connector that features JTAG and serial console for the device. That would of course also helps a lot.

We have just submitted Sid Player 1.2.49 to Apple. Highlights of changes in this revision include:

• Author Tab: In offline mode, only show authors for which songs are available,
• Underrun Detection: Relax threshold a bit, add setting to turn it off completely (for you jailbreakers…),
• Settings Tab: Enable switching between multiple SID models,
• Files Database: Files are no longer stored on your filesystem, but in a database. This fixes the incredibly annoying iTunes synchronization times. NOTE that we had to wipe all your data during the upgrade to make this happen.

and finally the first step towards the #1 wanted feature…

• Added four playlists: “Favorites”, “My Top 50 Played”, “Random 100″, “HVSC Top 100″.
• Enable reordering all playlists and adding/removing songs from/to the “Favorites” list directly from the Player screen.

Although we wanted to ship more smaller updates, this one has become a major update and took us a while. I hope it gets past the review pretty fast, so you can enjoy our latest work!

NB: The newest iPhone 3G[S] excited us a lot, especially since we already max out CPU power on the current models. We’re looking forward to enabling stereo and to add some nice post processing effects in a special Sid Player version once this model is out. Stay tuned!

NB2: Yes, we know that the HVSC team has released v50, however they have substituted a lot of PSID versions with RSID versions, which — although they might sound better — do no longer play given the limited CPU power of the iPhone and iPod Touch. I’m sorry, but until faster models appear, we can not ship the updated SIDs…

I have BeagleBoard in B7 revision. So the only USB port which is available is the OTG one. I use self made host cable which connects 4 port hub (with own power supply). This gives me keyboard, mouse and Ethernet.

Or rather should give… Current situation (2.6.29-angstrom) is that I do not have any USB devices available because kernel do not recognize them — at least not on each reboot. During last 10 reboots nothing was found…

So Texas Instruments engineers: do something about it please about your drivers.

And no, buying C3 revision is not an option — I will rather wait for version with non-USB Ethernet on board.

UPDATE: if you have U-boot 2009.01 then flash 2008.xx one or 2009.06 from Ångström. This will give you back standard behaviour of MUSB: ‘throw a dice, if you will get 5 then USB will rather work’.

Related posts:

1. BeagleBoard in a box
2. How many serial ports are enough?
3. New multi I/O card installed

People like photos, so here are some from the weekend on flickr:
Northumbria TRF Camping Weekend Photos

Thanks Tony!

Its been a while since I’ve been out on the CRM but this weekend was the local TRF’s bikes, bevvies and banter weekend, camping in a field near Hexham so I made the effort to go along.

Friday was intermittent rain but it was not raining as I arrived, got the bike out the van and put the tent up. It stayed dry through most of the evening and the campfires were great for keeping warm. There was also a projector, a screen made from bits of wood and an old marquee and some of Steve’s on bike camera footage on display when it got dark enough. When the rain did arrive it was time for bed. It was also rather cold overnight getting near freezing. It rained all night and was raining the next morning.

I was in a group of 5 bikes in the ‘oh look nice scenery’ group which was being led by the treasurer and the three others were southern foreigners. We left a bit late in the hope it would fair up as promised. The bike started first kick despite being in the rain all night which was a surprise. At the first gate I stopped for, it wouldn’t restart and I ended up bumping it but I just assumed it was cold.

The day’s destination was Alston covering several trails I’ve not been on before and some I’ve only done in deep snow. There was an interesting ford with steep hillside with switchbacks either side and a steep rocky climb I quite enjoyed but one of the guys came off on it (nothing serious). We passed through showers but there were also dry times too which wasn’t too bad.

Just before lunch, the bike died suddenly with what looked like loss of electrics. It wouldn’t kick back to life but did when I switched the fuel tap from main to reserve. It seemed fine so I continued on making a mental note to pull the tap apart and check what it was doing at some future date.

We went up to Hartside cafe for a change instead of the cafe in Alston and it was filled with cyclists who looked rather weather beaten. After lunch the bike needed choke to start and took a bit of getting going yet again.

We took a trail I quite enjoyed above a stream raging with white water, crossing through overflowing streams in a few places. We also passed a group of about 20 people (not walkers but people on some kind of tour?) who looked totally bemused that a set of bikes could travel over the ground they could barely stand up on . Getting back to the road from that trail saw me nearly getting stuck in a bog – I was trying to catch the group up, took a different line to everyone else and the bike nearly came to a stop and was sinking in a boggy bit. Leaping off the seat to the side, keeping the throttle open and pushing got it out thankfully though.

The next ford caused me some fun. There were two lines out, one nice looking and one with a steep rise up a large rock. Half way through the ford the bike went offline and I ended up going the rock route unexpectedly. If I’d applied enough power I’d have made it but I didn’t and the front wheel got up but I then stalled. This then meant reversing the bike back into the river and restarting it with the result of properly wet feet. It was kind of inevitable I guess. Nick then dropped his bike a couple of metres further up the slope to make me feel slightly better.

We were slowly winding around back to Hexham near Slaley when the bike totally died again with something suspiciously electrical looking. To rule it out I checked there was fuel to the carb. I also drained some fuel from the carb in case it was water related but it wasn’t. Messing around with various plugs suggested no spark. To conclusively prove this I ended up putting a finger into the plug cap and since I didn’t fly across the moorland when someone kicked the bike over, it was safe to say the electrics were dead. We tried bumping it and it did start but then nearly died, started and then died again.

A check of various connections didn’t show anything obvious so we decided to tow it remaining few miles back to camp although some members of the group were sceptical you could do this. I’ve never been towed on a bike before so this was an interesting learning experience. We did however make it off the trail back to tarmac and then back to the campsite with only one really hairy moment. At least this happened near the end of the day on the way back and near the site I guess. I was also very grateful for the tow back!

Back at camp I took it further to bits but didn’t find anything obvious despite a couple of false leads. It did however start and I did a couple of loops around the field however it was miss firing and not reving – I could hold it at full throttle with not much happening.

At this point I was offered lots of semi conflicting advice. The most convincing argument was stator coil failure, intermittent or otherwise. I was also told there were separate windings for the ignition coil power and the lights and that the pickup coils could have failed too.

I’ve since had the manual out and traced bits of the loom and can say for sure it only has one set of stator coils driving everything and these run through what I suspect is a rectifier only (not a reg/rect combo). It has 5 leads, 3 from the stator coils and the other two are +12V and ground. The +12V goes across a large condenser which is why I suspect its a rectifier only.

The stator wires have the same resistance between each pair of wires which suggests if a stator coil has failed its only under load/temperature. I stuck a diode tester on the rectifier leads and saw 0.7v drop between ground and two of the phases and between those two phases and the +12V consistent with a half wave rectifier setup. The third phase doesn’t give me a voltage drop reading. This suggests a couple of the diodes have failed or I’m wrong about it being a half wave rectifier or I’m just plain wrong .

Its also possible something like a magnetic pickup has failed but if that were the case it wouldn’t explain the total loss of electrical power I’d swear I saw as it was dieing. Its also been a hard to start since I’ve owned it which could possibly be consistent with it being a single diode down? Loss of the second diode (or maybe more at higher temperatures) has then finished things off?

Anyhow, regardless, there was no way I could use the bike today (Sunday). I stayed there last night for more bevvies, fires and horror movies on the big screen which was good fun. It was sad to see everyone riding off for more fun this morning and not being able to join them but there will be other opportunities. Thanks go to the local TRF group for a good time!

The bike has a full wave regulator + rectifier combined and the OE replacement part is expensive but Elextrex do a suitable cheaper aftermarket part. It arrived this morning so I fitted it tonight. The first thing you notice is the replacement is twice the size of the original and won’t fit the original location but it does have connectors that fit straight to the loom. Thankfully the bike has an aftermarket rear shock with no external reservoir so there is a space where that should go I could mount the reg/rect in.

As I removed the old unit, I found a hidden metal clip which had half sawn through the leads to it. Gah! This would explain the cut outs, the single dead phase and the other electrical gremlins. If I’d found that on Saturday night I could have repaired it and used the bike on Sunday plus saved the cost of a new unit assuming its undamaged from the shorts. Ah well.
After fitting the new unit, its noticeably easier to start, so far so good. The road test revealed a horrible misfire after higher rpms just like it did in the field. Much faffing with spark plugs ensued but that wasn’t the problem. Dismantling the CDI/ECU connections, applying copious WD40 and reassembling did fix it though.

So its ready to go playing in mud and I have an unusually strong urge to use it. Roll on the weekend (assuming I can find anyone to play with).

I encourage to read this article on how to design a office space for software teams (or any kind of engineer). There is scientific evidence showing the correlation between a good office space and productivity and his main points are:

1. Private offices with doors that close were absolutely required and not open to negotiation.


2. Programmers need lots of power outlets. They should be able to plug new gizmos in at desk height without crawling on the floor.


3. We need to be able to rewire any data lines (phone, LAN, cable TV, alarms, etc.) easily without opening any walls, ever.


4. It should be possible to do pair programming.


5. When you're working with a monitor all day, you need to rest your eyes by looking at something far away, so monitors should not be up against walls.


6. The office should be a hang out: a pleasant place to spend time. If you're meeting your friends for dinner after work you should want to meet at the office

a great read...

Matthew Garret is blogging about the Linux based Palm Pre system.

I like a lot what I read there. Linux Kernel, OpenEmbedded, dbus based IPC, OMAP SoC, root on SD and more. I would design it mostly the same way. Wait, I'm missing 300 develoeprs and 300 Millions vanture capital here. To bad.

Really waiting for the kernel sources. It is using a MSM6xxx based modem for CDMA and I would bet just the brother, perhaps MSM6281 like the Samsung Omnia, for the GSM variant. As I'm hacking on the Omnia right know I would of cours be interested in a kernel driver to drive the modem. On the Omnia it is connected via a dual port ram chip that interfaces to the PXA312 on the other side.

This also is kinda similar to the MSM7k SoC's that are used in the available Android phones. Just that AP, ram and BP are in the same chip here.

And the driver for the CDMA modem should also be pretty similar to the GSM variant. That gives me a little hope that maybe a driver for such a dual port ram setup will be in the Palm Pre kernel sources. Let me know if you have details here.

Where did all my memory go? Who is allocating it, how much is being allocated? From where were theses QImages allocated? valgrind provides an accurate leak checker, but for a running application you might want to know about allocations and browse through them and don't take the performance hit of valgrind (e.g with massif).

There is an easy way to answer these questions, use memprof. memprof used to be a GNOME application, it was unmaintained, the website was gone from the net, but this tool is just way too good to just drop out of the net. After trying to reach the maintainer twice I decided to adopt the orphaned thing.

Check the application out, it is great, it helps me to get an overview of memory allocations for WebKit/GTK+...

During my work on Epiphany I was debugging a problem with the "woohoo" bar. It took me not less than three days to understand the issue, write a test case, and a patch and put everything in this bug. Matthias Clasen was kind enough to review and commit the patch and it can be found here. Sadly the --author tag of git was not used and the commit does not carry my name, so ohloh will not list my contribution to Gtk+.

The main issue with debugging was finding signal connections, e.g. which function is connected to that signal and which objects, and figuring out what was called during the signal activation. My approach was the usual printf method in many places and adding _backtrace() to function calls using the glibc builtin backtracing functionality. I would like to have SystemTap at a state I could use it for tracing, or be able to script gdb (it has python plugin support now) to automatically execute a trigger when certain parts of the code got executed.

Anyway, I'm happy to have fixed a Gtk+ bug and being a contributor now.

• Essential Guide To Regular Expressions: Tools and Tutorials | Developer's Toolbox | Smashing Magazine
  Regular expressions are something that you’ll come across at least once in your development cycle, whether you’re just trying to modify an .htaccess file to make clean URLs, or something much more advanced like filtering RSS feeds or other data. Here are some resources to get you well on your way to mastering regex.

During my recent OpenEmbedded related work I merged gcc patchset from Martin Guy to add support for Maverick Crunch FP unit present in Cirrus Logic EP93xx ARM cpus. This makes floating point operations faster then it was before.

But does using it has a sense for whole system? Is it possible at all? The answers are No and Yes. I have root filesystem for EDB9301 created with Maverick optimisations but I also have plain armv4t one for same board. They both work but I do not recommend using Crunch optimized one — there are strange errors. For example “HZ=5.33381e-315″ is given instead of “HZ=100″ in openssl speed test (problem is somewhere in glibc).

Let me quote Martin’s mail:

My current recommendation is to enable crunch only in the floating point intensive libraries and applications that your application system uses, because having more than one crunch-enabled process running in the system makes the context switches slower because the kernel has to save and restore 19 64-bit registers at every context switch. It doesn’t bother doing this if only one process is using the FPU thanks to some clever Buytenhek laziness). I don’t have figures for how much of a difference this makes, but I guess one could calculate it from the context switching rate shown in the output of “vmstat 5″ and the instruction times.

I switched “ep93xx” machine in OE back to armv4t optimisations. Also I am working on adding some more EP93xx related patches from Hasjim Williams (he made first set of patches for OpenEmbedded and Martin Guy improved them and moved to newer GCC).

One note for end of story — I am not interested in doing more ep93xx toolchain work. If your device/company need such help then contact Martin Guy for consulting offer.

Related posts:

1. Self hosted Ångström build
2. 3 years of OpenEmbedded and me
3. Job change

• Brad Abrams : Uninstalling the Clickonce Support for Firefox

Link for planets

The LiMo foundation just announced their new version R2 of their platform specification, though they are not yet available for public consumption from their technical documents download page.

read more

Most people working with BUG device use R1.4 as their operating system. But I am not one of them.

Why? I am working on system which one day be R1.5 and to get it I need to have a way to boot different systems on BUG. But how to do that?

Few things are required:

1. U-Boot (which is required for R1.5 and optional for R1.4)
2. microSD card (which is required anyway)
3. images of different operating systems
4. card reader
5. some time

First of all we need to split microSD card to few partitions. I use default 2GB one so split it to 4 equal parts -- each for other version of BUG Linux. There are lot of applications which can be used so choose preferred one. Now we need to install misc systems to our card.

On first partition I put Ångström image which I built with org.openembedded.dev branch of OpenEmbedded. This is what I use for testing any of required tweaks. This image do not contains Java stuff - just bare console system. Adding X11 is in progress.

On 2nd partition I installed from official image. This one is to check how things were working in R1.4 and also to check do everything works like it should.

3rd partition keeps R1.5 built with stable/2009 branch of OpenEmbedded. This is what will be used as R1.5 sooner or later. It contains Java stuff as I use it with meta-but and meta-jalimo directories.

Not decided yet what will end on last partition ;)

 

OK, but how to boot selected system? It is easy with U-Boot as we have u-boot-utils package which allows to manipulate bootloader configuration from working system. So all I have to change is "bootargs" variable and reboot.

What left to fix? Kernel location because currently I use one uImage for all systems. Fix should be easy anyway :D

• Homepage of Jari Sukanen
  SISInfo is a tool for inspecting the contents of Symbian SIS installation packages. Supported SIS file format is the one introduced in Symbian 9.1 and S60 3rd edition. File format specification can be found here

There is a new set of rumours on websites about next Nokia tablet. Name it N900 (speculation name) or Rover (which is internal name) or famous N00 which probably is on prototypes (Nokia uses N00 on proto phones and tablets).

As Jamie Bennett wrote on his blog it will be hard to sell this tablet. He compares it to netbooks but I see other device to buy instead — Touchbook which has similar internals but higher resolution (1024×600 instead of 800×480) on bigger screen (8.9″ instead of 3.5″). OK, it will not have GSM like N900 but I do not care about it — my current phone is good enough.

And then goes other problem — Maemo. I used Maemo 2005/6/7/8 on Nokia 770 and N810 and ok, it is fine and working system but… It is niche system — small amount of applications available and no other environments then Hildon one (chroot with KDE which runs in window under Hildon does not count).

And question is how open will it be for other operating systems/distributions — I hope that Nokia will not follow 770/n8×0 way.

Related posts:

1. First days with Nokia N810
2. Maemo mapper
3. Feel the power of USB with Nokia tablet