Indigo Lego Train

This one was powered by three 1.2V AA rechargeable batteries – perfect for some startup aid for this old machine. After applying power I was able to boot into IRIX 6.2 installed on this historic piece of hardware (100MHz MIPS R4000 CPU, 192MB of RAM, 2GB SCSI hard disk, ELAN graphics). I have to admit I somehow enjoyed the “time travel” experience playing around with such an old system for a while. Someone here still remembers the Netscape browser? Or Electropaint? One really scary experience was the network setup: IRIX 6.2 has the ability to configure a static IP through the GUI but obviously you have to edit the network startup script in order to set a default route on boot.

A lot more of information about these machines can be found here.

I ran into the issue that activating Bluetooth in the settings application resulted in a crash of the whole GUI. It seems that only ARMv5 core based devices are affected so that only a few people ran into this so far. (Not that it would be correct on more common cores used for Android devices such as ARMv7A, but it does not seem to cause the same effect.) The solution I found in the Android 4 commit log is quite simple for a problem causing that much of hassle:

--- a/core/jni/android_server_BluetoothEventLoop.cpp
+++ b/core/jni/android_server_BluetoothEventLoop.cpp
@@ -311,7 +311,7 @@ static int register_agent(native_data_t *nat,
{
DBusMessage *msg, *reply;
DBusError err;
- bool oob = TRUE;
+ dbus_bool_t oob = TRUE;


Quadcopter Nightflight

Camp at Night

Antonov AN-2

This nice machine was parked next to our caravan… it’s a little bit larger than you might guess from the photo. I have placed some more photos here.

Mini6410 running an OpenEmbedded built GPE Image

The image pretty much illustrates what we are up to do now – but lets take a look at the software shipped with the board first. Compared to the older Mini2440 the devices official support DVD offers several more options: We have pre-compiled images based on Android, XUbuntu and Qtopia and an advanced U-Boot which comes with a kind of menu for the basic tasks.  One major problem is that currently the documentation is available in Chinese only which makes it a little bit hard to handle. But translating single paragraphs of the more than 300 pages long PDF manual using Google Translator worked pretty well. The DVD contains important sources for Android, U-Boot and Linux. The Kernel is based on 2.6.28 for the SMDK 6410 reference design and heavily patched. Some parts are quite far from mainline Linux and should be updated to latest standards – apart from the fact the whole Linux support might want some rebase on 2.6.35.

Now we have a big pile eh… DVD with stuff that runs on the board already – what does OpenEmbedded help us with here? Well all the binary stuff serves some purpose but nothing is perfect – OE helps us with to become more flexible and consistent at the same time. XUbuntu is great with its large package repository to try out things – but it has quite some requirements about flash storage, RAM and screen size. With OE you have the choice to create a full featured desktop image or to build something that fits your particular need.

So lets take a brief look into OE setup for the Mini6410 and how to install an image built with OE.

If you are new to this topic you should get familiar with OpenEmbedded first. The official getting started document is a good thing to read first. The following section assumes you have your OE set up and cares about the Mini6410 specific bits only. Make sure to use a recent org.openembedded.dev or testing branch.

First set up your local.conf to build for the Mini6410 – if you are using multiple configuration files then make sure to distribute these bits over the files correctly:

MACHINE = "mini6410"
DISTRO = "angstrom-2008.1"
LIBC = "eglibc"
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 de_DE.UTF-8 fr_FR.UTF-8 en_US.UTF-8"

This will select the Mini6410 as a target device, Ångström distribution and eglibc – this is the combination I tested. The last line defines a limited set of libc locales to be generated.

Now let’s build a filesystem image. I built a simple GPE based filesystem image first:

bitbake x11-gpe-image

If everything is configured correctly, your harddisk is large enough and your Internet connection ok you should get filesystem and kernel image in $TMPDIR/deploy/eglibc/images/mini6410. For the impatient of you or the ones who get bored during a build (no I don not suffer from this) I have uploaded my results here.

Finally lets go ahead an install these files into the internal NAND flash. I’m using U-Boot on the boards – we want to stay open and do not rely on propitiatory software. Keep this in mind if you intend to make a product: Any component you are not able to influence has potential to cause trouble and in most cases it will do this – sooner or later.

There are several ways to install files and to configure U-Boot. Here we use a quite generic solution using TFTP to transfer the images and fixed addresses. Not the best solution but the simplest. First if you do not have a DHCP server you have to configure networking:

setenv ipaddr <some IP for the board>
setenv serverip <your server's IP>

If you have a DHCP server you can skip this step and write “dhcp” instead of “tftp” in the commands below. These will download the files and install them into the internal NAND flash:

tftp 0xc0008000 uImage-mini6410.ubi
nand erase 0x80000 0x500000
nand write 0xc0008000 0x80000 0x500000

tftp 0xc0008000 x11-gpe-image-mini6410.ubi
nand erase 0x580000
nand write 0xc0008000 0x580000 ${filesize}

Finally we configure the boot parameters to match the installed kernel + filesystem and save these:

setenv bootargs console=ttySAC0,115200 ubi.mtd=2
   root=ubi0:rootfs-mini6410 rootfstype=ubifs
saveenv

(note that the first command needs to be entered in a single line)

We do not have to pass information about the MTD partition layout to the kernel since we follow the kernel’s built-in default in this configuration. Just reset your board and check if it boots into your shiny new filesystem. If something is wrong then please drop me a mail providing information (e.g. bootlog, screenshot, configuration files…). This could help to improve this little text and OpenEmbedded support for the Mini6410.

What now?

Try more useful targets with OpenEmbedded. If you like to build an installable cross toolchain matching your filesystem you could build the meta-toolchain-gpe target for example.

Enjoy!

Sim.One (OpenEmbedded booth at LinuxTag)

OE has support for the Sim.One already and I just added the parameters to build jffs2 filesystems for the internal NOR flash. In order to build jffs2 images for the Sim.One use the current org.openembedded.dev branch.

OpenEmbedded Setup
I just want to introduce the basic ideas and useful settings for these images. More generic information about how to get started with OE can be found here. For my tests I used the minimal distribution definintion in OE and built a very small image. The relevant settings for your build configuration (local.conf) are as follows:

MACHINE = "simone"
DISTRO = "minimal"
LIBC = "eglibc"
IMAGE_FSTYPES = "tar.gz jffs2"

The minimal-image is a good starting point for the internal flash. The image does not include much of functionality but leaves some free space for additional software. OE does not build the filesystem only, it builds the kernel for us as well so that we can start with a consistent set of files. Let’s give it a try and install the built results – I assume you have a U-Boot shell and network+tftp server configured already.

Install Kernel

erase 0x60080000 0x6027ffff
tftp  0x60080000 uImage-simone.bin

Install Filesystem

erase 0x602c0000 0x60800000
tftp 0x602c0000 simone.jffs2

We need to tell the kernel where to find the patitions. The actual layout we are going to use is as follows:

Device    size        name
mtd0:     000c0000 "Firmware"
mtd1: 00200000     "Kernel"
mtd2: 00540000    "Root-FS"

I have set up the configuration of U-Boot in order to minimize te effort booting from some other medium.
setenv bootargs console=ttyAM0 root=/dev/mtdblock2 rootfstype=jffs2 video=ep93xxfb
setenv bootcmd_nor 'setenv bootargs ${bootargs} ${mtdparts} ; bootm 60080000'
setenv bootcmd run bootcmd_nor
setenv mtdparts mtdparts=physmap-flash.0:768k@0(Firmware),
2048k@0xc0000(Kernel),-@0x2c0000(Root-FS)

It works… what can I do now?
Make the filesystem functional: Add useful things to the filesystem – a good candidate might be busybox httpd. Another useful target in OE is meta-toolchain which creates a cross compilation SDK for your device.

Now that you have read the whole text: If you do not want to build yourself you can take a look at my build results.

Enjoy!

Way more interesting than technical details is to look at the landscape of mobile device software stacks and to place MeeGo in it. So how does this landscape look like now?

• There is Apple with the iPhone – pretty much closed but many developers and sexy hardware but quite limited amount of devices and only one manufacturer.
• Symbian – well established with a large community but it feels like it hits its limits with modern smartphones.
• Samsung just launched Bada which looks quite interesting but does not yet seem to have a large community of developers and users.
• Microsoft Windows Mobile is available for many years now but seems to have lost attraction over the years.
• Palm WebOS is interesting from both developer and user point of view but I think it will be hard for it to compete with all the major players in this area.
• Google developed Android which enjoys a fast growing user- and developer base. It’s easy to get started with Android and there is a wide range of interesting devices available already. It is quite portable since most of the lowlevel components are open source.

Among these the most likely candidate to play the dominating role in the mobile handset market might be Android. At least this is how things look like right now… we all know this market changes pretty fast and you never know what happens next. I think Nils asked the question quite a few of us asked themselves: Will MeeGo become a kind of “Android killer”?

No way I will comment on this but in order to become a more generic platform MeeGo needs to focus on different things Maemo did so far. So far Maemo was focused on supporting a very few devices and contained quite some specialized bits that only worked for the Maemo specific devices and its distribution. I still remember that getting basic support for building the Maemo software stack with OpenEmbedded caused some headaches and sleepless nights. (I was mentor of a GSoC project working on this – just take a look at Kirtika’s blog to find out some details.)  It is good to see that it is quite obvious that MeeGo folks understand that these things will have to change. A good example is the process how to get some hardware supported. For someone like me supporting various device makers the really interesting part will follow: How will the device makers adopt MeeGo and how many of them will ‘jump onto the MeeGo boat’? Having more hardware vendors supporting MeeGo means more users and meant to make the platform more interesting for developers. And gaining interest from developers and users is absolutely vital for any software platform that is going to play a major role in future.

In my opinion there is a lot of potential in MeeGo – the most important one is the fact that the key components are going to be open and portable. The project joins two (comparably small) developer and user communities and combines this new community with the support by two very successful companies. I can imagine that this base is able to attract quite some more valuable contributors like smaller device makers, software companies and open source projects.

I’m pretty sure that ‘The Big Merge’ is going to cause quite some movement in the mobile device landscape…

So what does this mean for developers and device manufacturers? One thing is for sure: The new platform will become the “grown up” version of Maemo and Moblin. Especially for the Maemo part this means that the focus will change from targeting a very few devices and a quite well-defined software stack to a more generic way to support multiple hard- and software environments. And this is good – only a portable and easy to support platform is attractive for the device makers while the availability of multiple devices is important for its attractively among software developers.

It looks like we have interesting times ahead…

Visitors at the OE booth

Some things I noticed during my time at the booth is that we have to improve the presentation of the project a little bit. For many visitors even on a developer event like FOSDEM OpenEmbedded is a quite uncommon project and hard to present. We showed a set of different devices at FOSDEM but we always need to explain that these devices are just samples for possible OE target devices. It’s not really obvious how to communicate this… One improvement could be to add sheets with OE information to the devices we show. We should list things like this:

• Name
• CPU Architecture
• Useful OE targets

Another thing I miss is a kind of poster or info sheet that summarizes OE achievements in some lists and numbers. But anyway I think we are getting better and become more and more popular.

Device collection

We have to thank all the project members who helped with our booth – most notably Alessandro, Robert, Marcin and Henning for spending a lot of time at the booth. Special thanks should go to Ulf (from Atmel) and Vladimir (from Archos) who made it possible to have some more interesting devices to show. I think this is the first time we didn’t have a single Zaurus at the booth… :-)

One more project / booth I think is worth to mention is Rep Rap / Makerbot. The bots for turning 3D models into real things you can touch and use gained quite some attraction.

Bots at the booth

Bot detail

Did you notice? You can even use these bots make parts for another one… I think it is worth following these projects. They might become quite important to us in near future.

A working Makerbot - just finished a job

I would have some more things to write about – there were a lot of interesting things going on at FOSDEM but like always time is lacking. More as soon as I manage to write some more lines…

One project is the Linux port to the Höft & Wessel skeye.pos mobile – I really like the press release because it mentions the fact the supplied devices are running Linux and what the devices are used for. The filesystem on these devices is built with OpenEmbedded and is based on an older Angström release.

The other big project is closely related to both my job for kernel concepts and OpenEmbedded which is one of my favourite open source projects. The µCross distribution will support chip- and device vendors who are going to ship Linux-based solutions. The main idea is to combine the power OpenEmbedded and its large community with a good portion simplicity and a few additions. I do not want to mention too many boring details here so I will just introduce the basic concept: The idea is to offer customers binary packages matching their target architecture, matching toolchains and tools for assembling and configuring filesystem images for their devices.

There is not really an offical announcement yet but one of our business partners just announced a nice SBC module which will come with a µCross-based SDK. The TK71 is a QSeven format module powered by a Marvell 88F6281 SoC (Sheeva core based).

A third project that gained some love is the updated Linux port to the Toshiba Topas910 and TopasA900 boards. I am trying to maintain an upstream compatible and up to date Linux port to these devices here – for the people who do not want to use several year old kernels or this strange Aura stuff.  The latest achievement is that I got some patches to make NAND flash work which is vital for the TopasA900 because its small NOR flash can’t keep a decent filesystem image with GUI.

Ok now I’m done with showing off and I should return to do something useful… such as writing a short report about FOSDEM!