______________________________________________________________________________________________

Insight

| Developers

The Salient Features of the

Consumer Electronics Linux Forum Specifications

Part 2

Last month we discussed boot-up time reduction and power management in the CELF specifications. In this article, we will explore real-time characteristics and size reduction aspects.

any embedded devices need to have real-time responses. DVD players, music players and LCD televisions are all real-time devices. Real-time is determinism (being able to respond to an event before a deadline) with the given system load conditions. It doesn't necessarily mean a fast response time. Specific real-time application deadlines determine how short the maximum response time must be, in order to deliver real-time behaviour. These deadlines could range from 100 milli-seconds to one second. Let's look at some of the real-time capabilities of the Linux kernel that make it a good choice for use in embedded devices.

mechanisms. We will look at each of these features in turn.

Pre-emptible kernel

The pre-emptible kernel option makes kernel code pre-emptiblethis ensures the system is more responsive even if it is under load [1]. As a result of this feature, the system throughput will be slightly lower than if it is disabled. Figure 1 shows the option to enable the preemptible kernel feature.

O (1) scheduler

Kernel real-time capabilities

The Linux kernel has several real-time capabilitiespre-emptible kernel code, O(1) scheduler, interrupt threads, POSIX timers, and POSIX IPC (Inter-Process Communication)

The O (1) scheduler selects the next task to run in constant time, irrespective of the number of tasks to be scheduled. This is similar to fetching an entry from a hash table if the table is uniformly hashed. This means that whether there are 100 tasks or just five tasks to be scheduled, the time required to schedule a particular task will be a constant. This feature brings about deterministic behaviour for scheduling real-time tasks.
www.LinuxForU.com | LINUXForYoU | APrIL2010 | 71

Developers |

Insight

_____________________________________________________________________________________________________

Table 1: Differences between SysV and POSIX IPC

IPC
Message Q

System V
Message-based information Can retrieve specific message Sending and retrieving is huge overhead Retrieved message is lost Fastest among Sys V IPC Append is not possible race condition during concurrent modification Complex implementation semid refers a semaphore set Binary and counting Supports only process synchronization No thread synchronization support No Support

POSIX
No FIFO message receive Priority-based message receive Message notification Timeout send and receive File based Append is possible Lock facility to avoid swapping Simple implementation Single semaphore creation Binary and counting Supports process synchronization Supports thread synchronization Priority inheritance; priority protection, complex deadlock detection; real-time support (priority-based waiter Q) Persistence in the file system level Lightweightless kernel overhead Highly recommended by CGL & CELF Portable to all POSIX-supported systems Supports a lot of real-time features

Shared Memory Semaphore

fusyn

Design Aspects

Persistence in the kernel level Heavy weightkernel overhead Desktop, server applications Portable to all UNIX flavors No real-time support

Interrupt threads

Interrupt threads are those where the interrupt handler is just a high-priority thread, which runs with interrupts enabled, and also will block on mutex. This greatly simplifies locking in the kernel. Also, an interrupt thread may be pre-empted by a higherpriority thread. Real-time applications require that you allow pre-emption even when in an interrupt handler ([2] and [3]). When the interrupt is in the context of a thread, you can change the priority using sys_sched_setscheduler(). You can create an interrupt priority scheme, and set CPU affinity masks to limit thread migration to optimise the use of processor caches. An RT patch is required to use this feature.

Figure 2 shows the option to enable high-resolution timers. Table 1 shows the differences between System V and POSIX IPCs, which justifies why POSIX IPC is highly recommended on CE devices.

Size reduction

POSIX Real-Time APIs

The POSIX specification is generally accepted, and includes many time-related APIs that provide a strong basis to build software that need these services. POSIX message queues have prioritised message delivery, whereas System V message queues do not have this feature. POSIX timer functions have micro-second and nanosecond resolutions, and hence are suitable for real-time applications. The list of functions includes: clock_gettime(), clock_settime(), and clock_getres() timer_create(), timer_delete(), timer_settime(), timer_ gettime(), timer_getoverrun() nanosleep(), clock_nanosleep()
72 | APrIL2010 | LINUXForYoU | www.LinuxForU.com

Size reduction is crucial when using Linux in embedded and real-time systems. The system will boot up fast with a small image. A smaller kernel is also easier to maintain [4]. Linus Torvalds says that reducing the size could result in slightly better performance in terms of cycles per instruction [5]. UNIX founder Ken Thompson has said, One of my most productive days at work is throwing away 1000 lines of code. Michael Opdenacker, the founder of Free Electrons, says, We should stop size growth because we don't want to force people to use old kernels and old software. What are the vital areas for size reduction? Reducing the Linux kernel size can be categorised in two areas: 1. Application size reduction 2. Kernel size reduction

Application size reduction

The Linux kernel is the core of the operating system, with system files, executables, debugging utilities, compression utilities, etc, available in the next layer. Third-party applications are written on top of this layer.

_____________________________________________________________________________________________________

Insight

| Developers

Figure 1: The pre-emptible kernel option

Figure 3: Screen shot showing the directories and files in initrd

Figure 2: How to enable High Resolution Timers

Figure 4: Screen shot showing option to enable initramfs

Application size reduction devolves into the following: 1. Initrd 2. Initramfs 3. JFFS2 4. Busybox 5. Squashfs Let us look at each one of them in greater detail. Initrd (initial ram disk) is a kernel featurea compressed root file system image in the RAM disk. This image can be stored in ROM or flash memory the compression reduces the size in storage by 50 to 65 per cent. The kernel decompresses the initrd image into RAM (that means that the RAM consumed is equal to the original size of the file system). The kernel then uses the decompressed image as its root filesystem for the initial part of the boot process, so it can gain access to the binaries, scripts and utilities necessary for the boot process. Figure 3 is a screen shot showing the directories and files in initrd. In a generic boot process, the actual root filesystem on mass storage is mounted later, and a pivot_root operation makes it the active root file system. The kernel should support initrd and gunzip (for decompression) to use initrds. As a side effect of decompression, boot-up time is increased by around 15 per cent. IBM's

DeveloperWorks library has a nice Linux Initial RAM Disk Overview [6] if you would like to read more about this. Compared to initrd, the relatively new initramfs feature can increase boot-time flexibility, memory efficiency and simplicity. Developers working on embedded Linux will appreciate that it is relatively simple, and core embedded systems can use initramfs as their sole filesystem. See Figure 4 for the option to enable initramfs. JFFS2 is a compressed file system for flash memory. It reduces ROM/Flash usage. To use this filesystem, the kernel should have support for journalled filesystems and flash memory devices. Enabling JFFS2 causes the kernel's size in ROM and RAM to increase by about 5 per cent. However, the FS ROM size decreases by about 40 to 50 per cent, making this an efficient trade-off. JFFS2 can be used as a read/write file system [3]. Busybox is a utility that replaces the full-fledged independent binaries common to the GNU tool chain, with a single static binary containing the stripped-down functionality of those tools. The functionality is invoked based on the name by which the Busybox binary is invoked symbolic links called ls, grep, etc, when invoked via those names, provide the required functionality. Busybox' size is relatively small,
www.LinuxForU.com | LINUXForYoU | APrIL2010 | 73

Developers |

Insight

_____________________________________________________________________________________________________

Figure 5: Screen shot showing Busybox configuration settings

Figure 7: Option to configure standard kernel features for small systems

Figure 6: Screen shot showing the working of strip and Super Strip

Figure 8: Option to enable optimisation of size

around 500 KB. It is well-suited for use in small-footprint systems, and because of its power, has been called the Swiss Army Knife for small-footprint systems. Figure 5 shows the Busybox settings screen [7]. SquashFS is a compressed, read-only filesystem for Linux. It is aimed at general read-only filesystems, and for devices with embedded systems. This is suitable in devices where only low overhead is allowed. The filesystem is now stable, and has been tested on Power PC, i586, Sun Sparc and ARM architectures [3].

Kernel size reduction

When considering a specific embedded device, a decision has to be taken whether ROM space or RAM space needs to be saved then the corresponding compression technique or feature can be chosen. By default, the kernel image is stored in the device's persistent storage area or ROM in compressed form, and is copied into RAM and then uncompressed. It is possible to reduce the utilisation of ROM or RAM, depending on where we store the image, and which compression utility or feature we choose to use on Linux. Let us examine some of the compression utilities and kernel features available for Linux.
74 | APrIL2010 | LINUXForYoU | www.LinuxForU.com

Strip: Libraries and executables can contain extra information (debugging symbols) which can be used to debug the code units. This is useful during the development/ testing phases, but not useful to the end user. You can use the Linux strip command to remove this debugging information this can save significant space for executables and libraries. Super Strip (Sstrip): Super Strip goes beyond the strip utility, and can strip out a few more bytes that strip leaves behind, which are not used by Linux to start an executable. This can be used on libraries too. The disadvantage of Super Strip is that the processed libraries can no longer be used to compile new executables. Figure 6 shows strip and Super Strip being run in succession on a simple Hello World executable, and the respective space savings achieved. XIP: As we discussed in the 'Boot-up time reduction' section of Part I, XIP saves RAM space, but consumes more ROM space, since the kernel image must be stored uncompressed. (As mentioned there, a compressed kernel image would have to be decompressed in RAM.) For this inefficiency (ROM usage for the kernel image is approximately doubled), compared to a typical boot, RAM usage decreases more than 80 per cent. Another

_____________________________________________________________________________________________________

Insight

| Developers

positive effect is that the boot-up time is 30 per cent faster. Side-effects include a reduction in execution speed, and limitations on kernel debugging [2] and [3]. Embedded_config (kernel configuration): This option allows certain base kernel features to be removed from the build. This is suitable for very specific and special environments that can tolerate a non-standard kernel, and when we are very confident of the hardware platform and the device. Figures 7 and 8 show options to configure/optimise the kernel for small systems. From an electronic tooth brush to a high-tech fighter jet, embedded systems are at the core of it all. Bjarne Stroustrup, founder of C++, said, "Our civilisation runs on software." In fact, our civilisation runs with embedded systems on which software is prevalent. If these embedded devices are powered by Linux, then those devices will not only reach a larger section of people due to affordable pricing, but will also open the flood gates for developers to create their own popular applications on these devices [8] and [9]. From here, you can dive in to each of the specifications and explore them in greater detail. You can also look at Linux distributions such as MontaVista, and different frameworks available with chip vendors such as Texas Instruments, to learn how they support each of the specifications listed in CELF.
Acknowledgements
The authors would like to sincerely acknowledge the creators, authors, developers and engineers of the CELF community.

References
1. 2. 3. 4. 5. 6. 7. 8. 9. Simple facts on Consumer Electronics Linux Forum (CELF) Specifications http://tree.celinuxforum.org/docs/ CELF_Specification_V_1_0_R2.pdf ELC Embedded Linux Conference presentations http:// www.embeddedlinuxconference.com/elc_2009/sessions.html Useful repository of Embedded Linux Presentations http://www.free-electrons.com/ Journal of the Linux Community http://www.linuxjournal.com/ Linux Torvalds post on Size Reduction http://groups.google.com/group/linux.kernel/msg/ e1f9f579a946333e?hl=en& Linux Initial RAM Disk Overview by M.Tim Jones http:// www.ibm.com/developerworks/linux/library/l-initrd.html Busybox home page http://www.busybox.net/ Power-efficient chipset supports Linux by Jonathan Angel on 12-10-2009 http://www.linuxfordevices.com/c/a/ News/Via-VN1000-and-VT8251/?kc=LNXDEVNL121609 A few Linux-based boxes can be found at http://www.deviceguru.com

By: Gururajan Narasimhan E and Dr B. Thangaraju.

Gururajan currently works with Wipro Technologies as a lead consultant in the wireless and embedded domain. He has 16 years of core technology experience after a masters degree in engineering and has worked with various multinational companies in the USA, Germany and India. His specialisation is in wireless communication, algorithms and data structures, and Linux systems programming. Dr Thangaraju received a PhD in physics and worked as a research associate in IISc from 1996-2001. From 2001, he has been working in Wipro Technologies as a senior consultant and his core expertise is the Linux kernel, with expertise in embedded and real-time Linux.

Email: info@efyindia.com, Website: eb.efyindia.com

www.LinuxForU.com | LINUXForYoU | APrIL2010 | 75