1 second Linux boot to Qt!

At the end of last year, to demonstrate my company’s swiftBoot service, I put together a rather impressive demo. Using a Renesas MS7724 development board I was able to achieve a one second cold Linux boot to a Qt application. Here’s the demo…

Many people see a demo like this and assume there are ‘smoke and mirrors’ or that we’ve implemented a suspend to disk solution. This is genuinely a cold boot including UBoot (2009-01), Linux kernel (2.6.31-rc7) and Qt Embedded Open Source 4.6.2. We’ve not applied any specific intellectual property but instead spent time analysing where boot delays are coming from and simply optimising them away. The majority of the modifications we make usually fall into the category of ‘removing things that aren’t required’, ‘optimising things that are required’, or ‘taking a new approach to solving problems’ and are tailored very precisely to the needs of the ‘product’.

If you’re interested in exactly what modification I made and a little more about the approach taken – you may be interested in these slides which I presented at ELC-E 2010 – I’m also expecting a video of this presentation to appear on Free Electrons in the near future.

You may also remember my last demo based on an OMAP3530 EVM. [© 2011 embedded-bits.co.uk]

Continue Reading →

Reverse GeoCache

My family and I have recently become interested in the ‘sport’ of GeoCaching – as it was coming up to Christmas I thought it would be a great idea to combine their interests with my need for a project to keep me busy. I therefore decided to build a ‘Reverse GeoCache’ as a Christmas present. As this was relatively successful I thought I’d share the details of my build.

GeoCaching is a bit like a treasure hunt – dotted across the globe are more than a million hidden containers (GeoCaches) waiting to be found by those who are aware of their GPS co-ordinates. A Reverse GeoCache however, is a box which will only open in one location. Therefore the (un)lucky recipient of such a device can only discover it’s contents if they are successful in taking the box to the correct location.

Typically with Reverse GeoCaches the location where the box will open is not known – instead the user is prompted to press a button to ‘attempt’ to open the device. If you’re not in the right place the box won’t open and instead the device will tell you how far away the secret location is. Using this method the user can use trial and error to get closer to the final destination. Whilst you can’t buy a Reverse GeoCache – the idea is not new and others have created such a device (see here, here, here and here). Though the fun is always in the making!

With this functionality in mind and the pressing schedule (it was already the first weekend of December) I came up with a rough design, ordered some components online (Maplin, SKPang, CoolComponents and ValueZone) and eventually produced the following:

Continue Reading →

Free Linux Training Material and Video Presentations

Dotted across the Internet is a wealth of free resources including papers, presentations, articles and blogs on various topics to do with Linux and programming. I thought I would share these as I come across them.

One particularly useful resource is that of Free Electrons, an organisation based in France committed to promoting and contributing to free software. They also provide Linux training and have made all their training material available on-line under the Creative Commons Attribution-ShareALike 3.0 License. The material absolutely everything you’d ever need to know to become an expert in embedded Linux development. They can be downloaded here:


They also have posted recording of presentations made at various conferences such as the Embedded Linux Conference and Fosdem.


And whilst we’re talking about ELC – you can find the archives and presentation materials here:


All worthwhile reading on a rainy day :). [© 2011 embedded-bits.co.uk]

Continue Reading →

PrintK Format Specifiers

As a kernel developer you’ll probably find yourself treating the ‘printk’ function as a drop-in replacement for the ‘printf’ function provided by any useful C library such as uclibc or glibc – After all, it’s usage is virtually the same. It was for this reason that I found my self naively surprised when reading the source for the kernel’s implementation – I was surprised because it offers many more features than the typical C libraries’ implementation. As I was unable to find any useful documentation on this – I thought I’d provide a brief overview.

Let’s start with the typical ‘%p’ type format specifier – we usually use it for printing the address of a pointer. However if you take a peek at the ‘pointer’ function in lib/vsprintf.c you’ll notice that you can further specify the pointer type to print additional information. We’ll look at some examples.

printk("%pf %pF\n", ptr, ptr) will print:
module_start module_start+0x0/0x62 [hello] 

Continue Reading →

< 1 Second Linux Boot Time

One of my most recent projects at work has been to achieve a ‘less than one second’ Linux boot time on an OMAP3530 EVM development board. The following video shows the outcome of this work.

The above video demonstrates Linux booting and then starting an application which captures video from an NTSC video camera (via composite) and renders it to the LCD display.

In fact the first user land init process is started in less than half a second (0.464 seconds) demonstrating just how easily Linux can be tuned to get to a state of functionality in a very short amount of time!

I will follow up this post later to provide a little more information.

[© 2011 embedded-bits.co.uk]

Continue Reading →

I2C in the 2.6.32 Linux Kernel

The other day I forward-ported an old and abandoned touch-screen driver to the shiny new 2.6.32 kernel. A small portion of the work was to bring the driver in-line with the latest I2C framework (notably due the removal of detach_client from struct i2c_driver since 2.6.31 in favour of the new device driver binding model). This post shares my new-found understanding of the I2C framework and provides a very brief guide to writing an I2C slave device driver.

In a nutshell I2C is a simple serial bus that is often used to communicate with devices such as EEPROMs and peripherals such as touchscreens – there is also SMBus which can sometimes be considered a subset of I2C. The kernel breaks down I2C into ‘Buses’ and ‘Devices’, and then further breaks down buses into ‘Algorithms‘ and ‘Adapters‘, and devices into ‘Drivers‘ and ‘Clients‘. We’ll take a look at these in a little more detail.

Continue Reading →

GCC Compiler Warnings

It’s often a good strategy when developing software to ensure that a number of compiler warnings are switched on. For example, the GCC compiler flag ‘-Wall‘ is often used to provide warnings about all ‘questionable constructions’ (things like omitting to include a return statement in a function that should return a non-void type). Enabling warnings such as this can speed up development as more time is spend debugging application logic rather than silly errors. However the downside is that the compiler may provide warnings about things that we know about and are happy with. This post revisits GCC attributes to see how we can supress such warnings.

Continue Reading →

Init Call Mechanism in the Linux Kernel

The Linux Kernel has for a long time (at least since v2.1.23) contained a clever and well optimised mechanism for calling initialisation code in drivers. It’s clever because its functionality is largely abstracted from the driver developer and well optimised because after initialisation, memory containing the initialisation code is released. This post explores how the mechanism works.

We’ll start by seeing how driver developers make use of this functionality; the following code has come from v2.6.27.6/drivers/net/smc911x.c and is the driver for a common Ethernet chipset.

2206: static int __init smc911xinit(void)
2207: {
2208: return platform_driver_register(&smc911x_driver);
2209: }
2216: module_init(smc911x_init);
Continue Reading →

Multiple Network Interface Gotcha in Linux

Ok here’s a recipe to try:

  • Get a development board or PC that has two or more network interfaces,
  • Assign each of them with a unique IP address,
  • Connect the interfaces to a common network,
  • Finally, ping one of the IP addresses from another machine.

Now, depending on which IP address you chose to ping, you may find that your pings will suddenly fail to respond and timeout when you disconnect the other interface (i.e. the interface you are not pinging). Bizarre, isn’t it?

However, as my colleague and I recently discovered whilst debugging a new Ethernet driver, this gotcha is actually correct behaviour for Linux – and in fact it is correct behaviour as defined by the relevant RFC’s. I thought I’d use this post to discover what is going on and why this is OK.

Continue Reading →

Privilege Escalation in uClinux

The main difference between Linux and uClinux is that the latter is designed to work with systems without an MMU (Memory Management Unit). The main benefit of an MMU is that systems that utilise them can provide each process with it’s own virtual address space – by doing so each process is prevented from causing disruption to others.

uClinux systems do not have an MMU, all processes share a common address space and so there is often – but not always (see comments at the end of this post), no protection from processes interfering with each other. The security implications of this are widely known and understood – the applications of uClinux systems are usually such that this isn’t of great concern. However I wanted to see this for myself – I wanted to put the theory in practice and see how easy it is to disrupt another process and to see if privilege escalation can be achieved.

Continue Reading →