LZO kernel compression

As Michael stated in his review of the interesting features in Linux 2.6.30, new compression options have been recently added to the kernel. We therefore decided to have a look at those compression methods, from a compression ratio and decompression speed point of view.

This comparison will be based on “self-extractible kernels”, that is, kernel images containing bootstrap code allowing them to extract a compressed image. As underlined in the previous article, this approach is not used on all architectures. Blackfin, notably, chose a different path and compresses the whole kernel image, without including bootstrap code. While this has the clear advantage of making compression much simpler with respect to kernel code, it forces decompression out to the bootloader code.

Each of those methods has its advantages. Indeed, the Blackfin approach relies on the bootloader to provide the necessary functions, so that may be a problem to do things like bypassing u-boot to reduce the boot time. On the other hand, implementing it only once in the bootloader (as architecture-independent code) makes it unnecessary to write the low-level bootstrap code for each architecture in the kernel, which is surely interesting on virtually all architectures, the notable exceptions being x86 and ARM.

Gzip (also known as Zlib or inflate) has been the traditional (and, as a matter of fact, only) method used to compress kernels. Consequently, we’ll use it as the reference in the following tests. Our test environment is as follows:

ARM9 AT91SAM9263 CPU, 200MHz, using the mainline arch/arm/configs/usb-a9263.config.

This comparison includes figures for LZO, a new kernel image compression method that I have contributed to the Linux sources, and which hopefully will make its way into the mainline kernel. LZO support in the kernel is only new for kernel decompression, as it is already used by JFFS2 and UBIFS. LZO is a stream-oriented algorithm, and although its compression ratio is lower than that of gzip, decompression is lightning-fast, as we will soon find out.

So, here are the figures, average on 20 boots with each compression method:

Uncompressed 3.24Mo 200%
LZO 1.76Mo 0.552s 70% 109%
Gzip 1.62Mo 0.775s 100% 100%
LZMA 1.22Mo 5.011s 646% 75%

Bzip2 has not been tested here: the low-level bootstrap file, head.S, only allocates 64Kb for use by malloc() on ARM. Some quick tests showed that the kernel would not extract with less than 3.5Mib of malloc() space. That would require to modify head.S so that malloc can use more memory, which we will not do here. However, given that enough memory is usable on the system, one could well use bzip2. All the other algorithms performed the extraction using the standard 64Kib malloc space.

From the results, we can clearly see that LZMA is nearly unsuitable for our system, and should be considered only if the space constraints for storing the kernel are so tight that we can’t afford to use more space that was is strictly necessary.

LZO looks like a good candidate when it comes to speeding up the boot process, at the expense of some (almost neglectable) extra space. Gzip is close to LZO when it comes to size, although extraction is not as fast. That means that unless you’re hitting corner cases, like only having enough space for a Gzip compressed image but not for one made with LZO, choosing the latter is probably a safe bet.

Besides, the LZO-compressed kernel size is about 54% the size of the uncompressed kernel. As the kernel load time varies linearly with its size, load time for an uncompressed kernel doubles. While 0.55s are won because there’s no need to run a decompression algorithm, you spend twice as much time loading the kernel. This time is not negligible at all compared to the decompression time. Indeed, loading the uncompressed image takes roughly 0.8s. That means that at the cost of slowing down the boot process by 0.15s (compared to an uncompressed kernel), one gets a kernel image which is roughly twice as small. Rather nice, isn’t it?

New jobs at Free Electrons

Penguin worksLooking for kernel and embedded Linux experts

Free Electrons is looking for experienced members of the Free Software community to satisfy increasing demand for development, consulting and training on embedded Linux and on the Linux kernel.

All the details can be found on our careers page.

Faster boot: starting Linux directly from AT91bootstrap

Reducing start-up time looks like one of the most discussed topics nowadays, for both embedded and desktop systems. Typically, the boot process consists of three steps: AT91SAM9263 CPU

  • First-stage bootloader
  • Second-stage bootloader
  • Linux kernel

The first-stage bootloader is often a tiny piece of code whose sole purpose is to bring the hardware in a state where it is able to execute more elaborate programs. On our testing board (CALAO TNY-A9260), it’s a piece of code the CPU stores in internal SRAM and its size is limited to 4Kib, which is a very small amount of space indeed. The second-stage bootloader often provides more advanced features, like downloading the kernel from the network, looking at the contents of the memory, and so on. On our board, this second-stage bootloader is the famous U-Boot.

One way of achieving a faster boot is to simply bypass the second-stage bootloader, and directly boot Linux from the first-stage bootloader. This first-stage bootloader here is AT91bootstrap, which is an open-source bootloader developed by Atmel for their AT91 ARM-based SoCs. While this approach is somewhat static, it’s suitable for production use when the needs are simple (like simply loading a kernel from NAND flash and booting it), and allows to effectively reduce the boot time by not loading U-Boot at all. On our testing board, that saves about 2s.

As we have the source, it’s rather easy to modify AT91bootstrap to suit our needs. To make things easier, we’ll boot using an existing U-Boot uImage. The only requirement is that it should be an uncompressed uImage, like the one automatically generated by make uImage when building the kernel (there’s not much point using such compressed uImage files on ARM anyway, as it is possible to build self-extractible compressed kernels on this platform).

Looking at the (shortened) main.c, the code that actually boots the kernel looks like this:

int main(void)
{
/* ================== 1st step: Hardware Initialization ================= */
/* Performs the hardware initialization */
hw_init();

/* Load from Nandflash in RAM */
load_nandflash(IMG_ADDRESS, IMG_SIZE, JUMP_ADDR);

/* Jump to the Image Address */
return JUMP_ADDR;
}

In the original source code, load_nandflash actually loads the second-stage bootloader, and then jumps directly to JUMP_ADDR (this value can be found in U-Boot as TEXT_BASE, in the board-specific file config.mk. This is the base address from which the program will be executed). Now, if we want to load the kernel directly instead of a second-level bootloader, we need to know a handful of values:

  • the kernel image address (we will reuse IMG_ADDRESS here, but one could
    imagine reading the actual image address from a fixed location in NAND)
  • the kernel size
  • the kernel load address
  • the kernel entry point

The last three values can be extracted from the uImage header. We will not hard-code the kernel size as it was previously the case (using IMG_SIZE), as this would lead to set a maximum size for the image and would force us to copy more data than necessary. All those values are stored as 32 bits bigendian in the header. Looking at the struct image_header declaration from image.h in the uboot-mkimage sources, we can see that the header structure is like this:

typedef struct image_header {
uint32_t    ih_magic;    /* Image Header Magic Number    */
uint32_t    ih_hcrc;    /* Image Header CRC Checksum    */
uint32_t    ih_time;    /* Image Creation Timestamp    */
uint32_t    ih_size;    /* Image Data Size        */
uint32_t    ih_load;    /* Data     Load  Address        */
uint32_t    ih_ep;        /* Entry Point Address        */
uint32_t    ih_dcrc;    /* Image Data CRC Checksum    */
uint8_t        ih_os;        /* Operating System        */
uint8_t        ih_arch;    /* CPU architecture        */
uint8_t        ih_type;    /* Image Type            */
uint8_t        ih_comp;    /* Compression Type        */
uint8_t        ih_name[IH_NMLEN];    /* Image Name        */
} image_header_t;

It’s quite easy to determine where the values we’re looking for actually are in the uImage header.

  • ih_size is the fourth member, hence we can find it at offset 12
  • ih_load and ih_ep are right after ih_size, and therefore can be found at offset 16 and 20.

A first call to load_nandflash is necessary to get those values. As the data we need are contained within the first 32 bytes, that’s all we need to load at first. However, some space is required in memory to actually store the data. The first-stage bootloader is running in internal SRAM, so we can pick any location we want in SDRAM. For the sake of simplicity, we’ll choose PHYS_SDRAM_BASEhere, which we define to the base address of the on-board SDRAM in the CPU address space. Then, a second call will be necessary to load the entire kernel image at the right load address.

Then all we need to do is:

#define be32_to_cpu(a) ((a)[0] << 24 | (a)[1] << 16 | (a)[2] << 8 | (a)[3])
#define PHYS_SDRAM_BASE 0x20000000

int main(void)
{
unsigned char *tmp;
unsigned long jump_addr;
unsigned long load_addr;
unsigned long size;

hw_init();

load_nandflash(IMG_ADDRESS, 0x20, PHYS_SDRAM_BASE);

/* Setup tmp so that we can read the kernel size */
tmp = PHYS_SDRAM_BASE + 12;
size = be32_to_cpu(tmp);

/* Now, load address */
tmp += 4;
load_addr = be32_to_cpu(tmp);

/* And finally, entry point */
tmp += 4;
jump_addr = be32_to_cpu(tmp);

/* Load the actual kernel */
load_nandflash(IMG_ADDRESS, size, load_addr - 0x40);

return jump_addr;
}

Note that the second call to load_nandflash could in theory be replaced by:

load_nandflash(IMG_ADDRESS + 0x40, size + 0x40, load_addr);

However, this will not work. What happens is that load_nandflash starts reading at an address aligned on a page boundary, so even when passing IMG_ADDRESS+0x40 as a first argument, reading will start at IMG_ADDRESS, leading to a failure (writes have to aligned on a page boundary, so it is safe to assume that IMG_ADDRESS is actually correctly aligned).

The above piece of code will silently fail if anything goes wrong, and does no checking at all – indeed, the binary size is very limited and we can’t afford to put more code than what is strictly necessary to boot the kernel.

Linux 2.6.30 – New features for embedded systems

Interesting features in Linux 2.6.30 for embedded system developers

Linux 2.6.30 has been released almost 1 month ago and it’s high time to write a little about it. Like every new kernel release, it contains interesting features for embedded system developers.

The first feature that stands out is support for fastboot. Today, most devices are initialized in a sequential way. As scanning and probing the hardware often requires waiting for the devices to be ready, a significant amount of cpu time is wasted in delay loops. The fastboot infrastructure allows to run device initialization routines in parallel, keeping the cpu fully busy and thus reducing boot time in a significant way. Fasboot can be enabled by passing the fastboot parameter in the kernel command line. However, unless your embedded system uses PC hardware, don’t be surprised if you don’t get any boot time reduction yet. If you look at the code, you will see that the async_schedule function is only used by 4 drivers so far, mainly for disk drives. You can see that board support code and most drivers still need to be converted to this new infrastructure. Let’s hope this will progress in future kernel releases, bringing significant boot time savings to everyone.

Tomoyo LinuxLinux 2.6.30 also features the inclusion of Tomoyo Linux, a lightweight Mandatory Access Control system developed by NTT. According to presentations I saw quite a long time ago, Tomoyo can be used as an alternative to SELinux, and it just consumes a very reasonable amount of RAM and storage space. It should interest people making embedded devices which are always connected to the network, and need strong security.

Another nice feature is support for kernel images compressed with bzip2 and lzma, and not just with zlib as it’s been the case of ages. The bzip2 and lzma compressors allow to reduce the size of a compressed kernel in a significant way. This should appeal to everyone interested in saving a few hundreds of kilobytes of storage space. Just beware that decompressing these formats requires more CPU resources, so there may be a price to pay in terms of boot time if you have a slow cpu, like in many embedded systems. On the other hand, if you have a fast cpu and rather slow I/O, like in a PC, you may also see a reduction in boot time. In this case, you would mainly save I/O time copying a smaller kernel to RAM, and with a fast cpu, the extra decompression cost wouldn’t be too high.

However, if you take a closer look at this new feature, you will find that it is only supported on x86 and blackfin. Alain Knaff, the author of the original patches, did summit a patch for the arm architecture, but it didn’t make it this time. Upon my request, Alain posted an update to this arm patch. Unfortunately, decompressing the kernel no longer works after applying this patch. There seems to be something wrong with the decompression code… Stay tuned on the LKML to follow up this issue. Note that the blackfin maintainers took another approach, apparently. They didn’t include any decompression code on this architecture. Instead, they relied on the bootloader to take care of decompression. While this is simpler, at least from the kernel code point of view, this is not a satisfactory solution. It would be best if the arm kernel bootstrap code took care of this task, which would then work with any board and any bootloader.

Another interesting feature is the inclusion of the Microblaze architecture, a soft core cpu on Xilinx FPGAs. This MMU-less core has been supported for quite a long time by uClinux, and it’s good news that it is now supported in the mainline kernel. This guarantees that this cpu will indeed be maintained for a long time, and could thus be a good choice in your designs.

Other noteworthy features are support for threaded interrupt handlers (which shows that work to merge the real-time preempt patches is progressing), ftrace support in 32 and 64 bit powerpc, new tracers, and of course, several new embedded boards and many new device drivers.

As usual, full details can be found on the Linux Kernel Newbies website.

Linux kernel 2.6.29 – New features for embedded users

Tuz Linux logoThe 2.6.29 version of the Linux kernel has just been released by Linus Torvalds. Like all kernel releases, this new version offers a number of interesting new features.

For embedded users, the most important new feature is certainly the inclusion of Squashfs, a read-only compressed filesystem. This filesystem is very well-suited to store the immutable parts of an embedded system (applications, libraries, static data, etc.), and replaces the old cramfs filesystem which had some strong limitations (file size, filesystem size and limited compression).

Squashfs is a block filesystem, but since it is read-only, you can also use it on flash partitions, through the mtdblock driver. It’s fine as you just write the filesystem image once. Don’t hesitate to try it to get the best performance out of your flash partitions. Ideally, you should even use it on top of UBI, which would transparently allow the read-only parts of your filesystem to participate to wear-leveling. See sections about filesystems in our embedded Linux training materials for details.

This new release also adds Fastboot support, at least for scsi probes and libata port scan. This is a step forward to reducing boot time, which is often critical in embedded systems.

2.6.29 also allows stripping of generated symbols under CONFIG_KALLSYMS_ALL, saving up to 200 KB for kernels built with this feature. This is nice for embedded systems with very little RAM, which still need this feature during development.

Another new feature of this kernel is the support for the Samsung S3C64XX CPUs. Of course, a lot of new boards and devices are supported, such as the framebuffer of the i.MX 31 CPU, or the SMSC LAN911x and LAN912x Ethernet controllers.

The other major features of this new kernel, not necessarily interesting for embedded systems are the inclusion of the btrfs filesystem, the inclusion of the kernel modesetting code, support for WiMAX, scalability improvements (support of 4096 CPUs!), filesystem freezing capability, filesystem improvements and many new drivers.

For more details on the 2.6.29 improvements, the best resource is certainly the human-readable changelog written by the KernelNewbies.org community.

Kernel and BSP development and mainlining

Offering free mainlining for Linux kernel, device driver and BSP development

Note: Due to the number of requests we get for mainlining work, we can no longer continue the offer described below.

Free Electrons is best known worldwide for its kernel and embedded Linux system training sessions and its free training materials, and also perhaps for sharing videos from technical conferences.

However, did you know that Free Electrons is not a training company?

We are actually embedded Linux system and kernel developers like the people we support, train and work for. This is essential to be good trainers, in addition to our passion for sharing what we learn. For example, have you ever had a look at the description of our engineering services?

In our training activity, we differentiate with other suppliers by offering custom sessions, being completely transparent with our training materials, costs and customer evaluations. Here’s how we can also make a difference in our development activity:

  • As in all our activities, by focusing only on the Linux kernel, device drivers, bootloaders, embedded and real-time system development.
  • By offering free mainlining to any customer who orders Linux board support packages or Linux device drivers from us. Having our code accepted in the official Linux and U-boot sources brings terrific benefits to our customers and can be a key contributor to the success of their products.
  • By working inside the Linux development community. Being part of it, we know this community very well: its people, its rules, its best practices and its best resources. This helps us to make the right decisions (if needed, collecting advice from the right people), and quickly obtain the expected results.

2008 contributions

Here are the contributions that we made to the user and developer community in 2008, thanks to the customers who ordered our engineering and training services.

As you can see, we do our best to have all our contributions merged into mainline sources. So, if you need a new feature in the Linux kernel (supporting your new boards, for example), in development tools and libraries (Buildroot, QEMU…), and want to enjoy this feature in all future updates and releases, don’t hesitate to ask us. We will be glad to work with the community and find a long lasting solution.

Linux kernel

  • [x86] use ELF section to list CPU vendor specific code (commit)
  • [MTD] fix minor typo in the MTD map driver for SHARP SL series (commit)
  • [x86] configurable DMI scanning code (commit)
  • [mm] directly use kmalloc() and kfree() in init/initramfs.c (commit)
  • [x86] consolidate the definition of the force_mwait variable (commit)
  • inflate: refactor inflate malloc code (commit)
  • fs/buffer.c: uninline __remove_assoc_queue() (commit)
  • [x86] make movsl_mask definition non-CPU specific (commit).
  • [x86] move cmpxchg fallbacks to a generic place (commit)
  • [x86] configuration options to compile out x86 CPU support code (commit)
  • Configure out file locking features (commit)
  • Fix comment in include/linux/mmc/host.h (commit)
  • Configure out AIO support (commit)
  • [PCI] allow quirks to be compiled out (commit)
  • [x86] remove PC speaker code (commit)
  • [Doc] improvement to Documentation/SubmittingPatches (commit)
  • Work on multicast and ethtool configurability. Not merged yet.
  • 65 e-mails sent to the kernel newbies mailing list to help new kernel developers.

Buildroot

Thomas Petazzoni became official committer in November 2008. In addition to contributions, patch review and integration of patches into the official Buildroot repository, and discussions on the mailing list.

  • Thumb support, not integrated yet (post)
  • Fixed URL for fakeroot sources, integrated (post)
  • Bumped libpng version, integrated (post)
  • Added the DirectFB examples package, integrated (post)
  • Bumped up libgtk2 version, integrated (post)
  • Work on external toolchain support, integrated. Several iterations, patches and discussions.
  • External toolchain support improvements, integrated (post)
  • More external toolchain fixes, integrated (post)
  • External toolchain C++ cross-compiler fix, integrated (post)
  • Kernel build fix related to external toolchain use, integrated (post)
  • Fixed external toolchain build, integrated, and replaced later with an improved version (post)
  • Fix Qtopia build issues, integrated and then replaced by an improved version (post)
  • Another external toolchain support solution, integrated (post)
  • Fixed TARGET_PATH for external toolchain builds, integrated (post)
  • Fixed strange problems in pango configure target, integrated (post)
  • Strip libgtk2 in the target, integrated (post)
  • Strip pango libraries on the target, integrated (post)
  • Strip gettext libraries on the target, integrated (post)
  • Fix matchbox build, integrated (post)
  • Create zlib installation directory in the staging dir, integrated (post)
  • Bump up lite version, integrated (post)
  • Added a parallel compilation fix for fontconfig, integrated (post)
  • Documentation fixes (post, post)

QEMU

  • Increased write buffer size in pflash emulation, integrated (post)
  • Reset wcycle after erase confirm, integrated (post)
  • Improved pflash cfi01 debug messages, integrated (post)
  • Added missing parenthesis in qemu_ram_alloc(), integrated (post)
  • Add Flash support to the Versatile PB platform (post)

Conferences

New training materials

All our training materials can now be found on our docs page. Some of them are not new, but have undergone substantial updates.

See our recent post for details.

Financial support

We support organizations promoting Free Software:

You may also count our subscriptions to the most useful LWN.net resource.

Miscellaneous

Kernel 2.6.28 is out with a few Free Electrons contributions

A few hours before Christmas, Linus Torvalds released the latest stable version of the Linux kernel, 2.6.28. Jake Edge from LWN sums up the major highlights of this new release: « Some of the highlights of this kernel are the addition of the GEM GPU memory manager, the ext4 filesystem is no longer “experimental”, scalability improvements in memory management via the reworked vmap() and pageout scalability patches, moving the -staging drivers into the mainline, and much more ». As usual, the Kernel Newbies website offers an excellent human-readable summary of the changes.

Of particular interest to embedded developers will be the new boot tracer facility, which allows to draw SVG graphs of the kernel initialization procedures execution time, in order to analyze the boot time and possibly reduce it. Of course, a lot of architecture-dependent improvements have also been made (for example OProfile support for ARMv7 CPUs but also new supported boards) and a lot of drivers have been merged or improved, as usual.

Free Electrons has contributed a few patches that have been merged and released in 2.6.28. While being a small contribution compared to the 9.000+ patches added to the kernel between 2.6.27 and 2.6.28, they still slightly improve the kernel for embedded users. Part of the Linux-Tiny efforts, these patches allow to reduce the size of the kernel by disabling features that may not be necessary on embedded systems. More specifically, these patches allow :

From the existing Linux Tiny patch ideas, the only one left in the feature removal area are the multicast support removal and ethtool removal. They have already been submitted a few months ago, but got rejected by the network maintainers. I will work on them again to fix the issues and try to re-submit them later.

Finally, Jonathan Corbet has published an analysis of the 2.6.28 developement cycle in terms of contributors and changes. An interesting reading.

New LXR website

I am pleased to announce that our http://lxr.free-electrons.com website is back on line.

As some of you probably noticed, our service had been down for several months. When it was working, it was based on LXR 0.9.5. This version had nice improvements over the stable release (0.3.1), like better display of the kernel sources, but on the other hand, it also had ugly drawbacks. In particular, it stored data in an SQL database. This made the server consume more CPU resources, and made it very long to index a new kernel version (about 10 hours instead of just a few minutes). Disk space was also multiplied by 3 or 4, if I recall correctly. Anyway, the major problem was that that version didn’t scale: the service was getting slower each time a new version was added. Apparently, the bigger the database, the slower the server got.

Eventually, that 0.9.5 based server just died. I didn’t change anything before this happened and everything looked all right. I checked configuration files and packages, but there seemed to be no way to make it run again. The only solution left was a brand new install from scratch.

I first evaluated the LXRng, a new fork of the software on the http://lxr.linux.no website. This new version looks nice. In particular, though it’s still using a database, this new branch seems to withstand a greater number of kernel source versions, as http://lxr.linux.no answers pretty fast now and indexes a pretty long list of versions. However, I found its interface confusing and not as convenient as it was in the original branch, especially for identifier search. It could be because this new version is not mature enough yet, or just because I was too familiar with the original interface. The best is to try by yourself!

I also tried to make a new installation of the latest CVS sources of the main branch. However, this didn’t work as expected, as I wanted to run the new service on a recent distro with long term support (Ubuntu Gutsy Gibbon). Gutsy Gibbon only supports MySQL 5.0, but LXR-CVS proved to be only compatible with MySQL 4.0. I did apply some patches, but still got SQL query errors with MySQL 5.0.

I eventually decided to go back to the good old 0.3.1 stable version, and I don’t regret it:

  • This version is extremely simple. You just need a web server with CGI scripts. No trouble with Apache2, no need to make modperl work. No need to install database software.
  • This version is extremely fast too. It just takes a few minutes to add a new version, and serving identifier searches is very fast. Just try with a widely used function, like outb. With LXR 0.9.5, it could take up to 1 minute to display all the files in which the symbol was found.
  • This version scales by design. Each supported source version has its own index files, and there is no central blob getting bigger and bigger. This simple design also makes it very easy to remove or to update source versions (like upgrading 2.6.28 sources to 2.6.28.1). With LXR 0.9.5, you had to make your own SQL queries to remove a version from the database!
  • This version lacks a few features (like direct links to C include files, or like file descriptions), but hey, the main features are there: source navigation and identifier search. The only significant feature that is kind of missing in our site is freetext search. Version 0.3.1 only supported a proprietary searching tool, so we decided to rely on Google’s search instead. This is not perfect as we won’t have version-specific search, but freetext search is a secondary feature for us anyway. We wanted to have this service back on line, with at least its main features.
  • Note that I had to make minor changes to make the website XHTML 1.0 Transitional compliant and pass the W3C Markup Validation Service checks I also fixed a bug in the diff markup script. Here is an archive of our install. Don’t hesitate to compare it with the original code and templates, and reuse our modified templates if you like them.

Thanks to this, the code hyperlinks in our kernel training slides work again at last! Every time we mention the name of a kernel source file or quote example code, you can click on the file name or on each function or structure type name, and you will be taken to the corresponding page on our LXR site!

Don’t forget that other valuable LXR websites exist for the Linux kernel. See our LXR websites list. Don’t hesitate to post a comment if you know other useful ones.

Conference videos and report

27 free videos from the ELC and FOSDEM 2008 conferences. Extensive technical report from ELC 2008.

After participating to the Embedded Linux Conference (ELC) in Mountain View, and to FOSDEM in Brussels, we are pleased to release the videos that we managed to shoot.

These videos should be useful to anyone interested in the multiple topics covered by these very interesting conferences, either to people who couldn’t join these conferences, or to single core participants who couldn’t attend more than one presentation at once. These videos are also interesting opportunities to see and hear key community members like Andrew Morton, Keith Packard, Henry Kingman, Tim Bird and many others!

While we’ve been releasing free technical videos for a few years now, ELC is the first conference for which we are also offering an extensive report, written by Thomas Petazzoni, one of our kernel and embedded system developers. This report is trying to sum up the most interesting things learned at this conference, at least from the presentations Thomas could attend. This way, you shouldn’t have to view all the videos to identify the most interesting talks.

Creative commons In agreement with the speakers, these videos and the report are released under the terms of the Creative Commons Attribution-ShareAlike 3.0 license.

We hope that sharing this knowledge will attract new contributors and users, and will bring our community one step closer to world domination…

Embedded Linux Conference, Mountain View, Apr. 2008

Don’t miss our detailed report on the below presentations!

  • Keynote: The Relationship Between kernel.org Development and the Use of Linux for Embedded Applications, by Andrew Morton (Google):
    video, slides (55 minutes, 240 MB)
  • UME – Ubuntu Mobile and Embedded, by David Mandala (Canonical):
    video, slides (30 minutes, 145 MB)
  • Appropriate Community Practices: Social and Technical Advice, by Deepak Saxena (MontaVista):
    video (thanks to Kevin Hilman, MontaVista)(44 minutes, 139 MB)
  • Adventures In Real-Time Performance Tuning, by Frank Rowand:
    video,slides (50 minutes, 251 MB)
  • Shifting Sands: Lessons Learned from Linux on an FPGA, by Grant Likely:
    video, slides (44 minutes, 262 MB)
  • Disko – An Application Framework for Digital Media Devices, by Guido Madaus:
    video (27 minutes, 190 MB)
  • Keynote: Tux in Lights, by Henry Kingman (LinuxDevices.com):
    video, slides (44 minutes, 139 MB)
  • Back-tracing in MIPS-based Linux Systems, by Jong-Sung Kim (LG Electronics):
    video, slides
    (54 minutes, 160 MB)
  • Making a Phone Call With Phase Change Memory, by Justin Treon (Numonyx):
    video, slides (28 minutes, 159 MB)
  • Building Blocks for Embedded Power Management, by Kevin Hilman (MontaVista):
    We couldn’t film his presentation, but we already shot a similar presentation he gave at Fosdem 2008: video ((56 minutes, 183 MB)
  • Using Real-Time Linux, by Klaas van Gend (MontaVista):
    video, slides (53 minutes, 263 MB)
  • Every Microamp is Sacred – A Dynamic Voltage and Current Control Interface for the Linux Kernel, by Liam Girdwood (Wolfson Microelectronics):
    video, slides (35 minutes, 71 MB)
  • Power Management Quality of Service and How You Could Use it in Your Embedded Application, by Mark Gross (Intel):
    video, slides (57 minutes, 401 MB)
  • OpenEmbedded for product development, by Matt Locke (Embedded Alley):
    video, slides (49 minutes, 141 MB)
  • Kernel Size Report, and Bloatwatch Update, by Matt Mackall (Selenic Consulting):
    video (49 minutes, 146 MB)
  • Leveraging Free and Open Source Software in a Product Development Environment, by Matt Porter (Embedded Alley):
    video, slides (45 minutes, 220 MB)
  • Using a JTAG for Linux Driver Debugging, by Mike Anderson (PTR Group):
    video, slides (113 minutes, 694 MB)
  • DirectFB Internals – Things You Need to Know to Write Your DirectFB gfxdriver, by Takanari Hayama ():
    video (43 minutes, 200 MB)
  • Linux Tiny – Penguin Weight Watchers, by Thomas Petazzoni (Free Electrons):
    video (thanks to Jean Pihet, MontaVista), slides (32 minutes, 140 MB)
  • Keynote: Status of Embedded Linux and CELF Plenary Meeting, by Tim Bird (Sony):
    video, slides (49 minutes, 112 MB)

Slides are collected on http://www.celinux.org/elc08_presentations/.

Fosdem, Brussels, Feb. 2008

  • Modest, email client for embedded systems, by Dirk-Jan Binnema (Nokia):
    video (34 minutes, 121 MB)
  • Design a Linux robot companion with 8 bits microcontrollers, by David Bourgeois:
    video (54 minutes, 211 MB)
  • Linux on the PS3, by Olivier Grisel:
    video (47 minutes, 272 MB)
  • Xen for Secure Isolation on ARM11, by Jean-Pihet (MontaVista):
    video (41 minutes, 207 MB)
  • Building blocks for Embedded Power Management, by Kevin Hilman (MontaVista):
    video (56 minutes, 183 MB)
  • Emdebian Update: Rootfs, GPE and tdebs, by Neil Williams:
    video (47 minutes, 226 MB)
  • pjsip: lightweight portable SIP stack, by Perry Ismangil:
    video (55 minutes, 194 MB)

Additional video

  • Roadmap to recovery – pain and redemption in X driver development, by Keith Packard:
    video (44 minutes, 168 MB)