TkOS engineers have years of experience developing embedded Linux applications for medical devices, science education, WiFi routers and defense systems. The common elements in all of these applications are:
Most embedded Linux applications have flash device space constraints or boot time constraints that require minimizing the size of the Linux kernel. Minimizing the size of the kernel involves careful editing of the kernel .config file to exclude features that are not essential to your application. If there are drivers that you only use in particular run-time conditions or configurations, then you can reduce the kernel size by building those drivers as loadable kernel modules.
By carefully editing the device tree you can cause the kernel to initialize only those drivers that you actually need to run your application. That is, even if there are specific devices on your SoC or board such as a second Ethernet or USB connection, or UARTS or CAN buses that you do not use, by eliminating these from the reference board device tree you can save considerable time during the kernel boot phase.
The first decision that you make when configuring a filesystem is usually which C library to use, glibc, uClibc or a custom C library. The choice of C runtime library has a major impact on the flash space requirements and on your application program development. Even if you have adequate space on the flash, the total size of the root filesytems on the flash device can affect the boot time, so the choice of C library can also influence boot time. When you develop an application using uClibc your developers must have knowledge of the limitations of the uClibc API.
There are several options for partitioning the flash or "MTD" device into partitions for the bootloader, kernel, device tree and root filesystem. Since the commonly used bootloaders, U-Boot and Barebox require their own partitions, the minumum number of flash partitions that you can have is two. The most common partitioning schemes are:
The advantages of the 5 partition scheme are that the bootloader environment variables are accessible from the running Linux operating system, and the kernel, device tree and filesystem can be re-flashed separately without requiring the ability to mount a filesystem from the flash.
The advantages of the 3 partition scheme using a U-Boot image is that it saves flash space since the total space for the kernel, device tree and filesystem is managed as a single partition. This allows utilization of spare space at the end of the kernel and device tree partitions using the 5 partition scheme. The disadvantage of the 3 partition scheme is that you can't replace each component separately, you need to replace the entire U-Boot mkimage image file.
The advantage to the 3 partition scheme using kernel and device tree images in the root filesystem is that you can replace these images easily from the running Linux operating system (assuming that the root filesystem is mounted read/write from the flash itself) by simple file copy operations, and the kernel, device tree and root filesystem space is managed as a single pool.The disadvantage is that the bootloader must have the ability to mount the root filesystem and this operation can be slow, particularly for a large UBIFS NAND flash file system.
There are a number of ways to boot an embedded Linux system. Each boot method has its advantages.
You can boot the Linux kernel directly using a bootlet program or initial program loader. Most SoC vendors provide minimal bootloaders with their vendor BSPs that you can use for this boot strategy. The advantage is speed. Usually the Linux kernel and the bootlet are linked together as a single file that the SoC boot ROM software loads from flash and executes. The disadvantage is configurability, in particular, the ability to conditionally boot one image or another that a bootloader such as U-Boot provides.
The disadvantages of using bootlets or IPL bootloaders can be offset by SoC's that boot ROM software that can be configured to select a boot device depending on media presence and boot time. An example of such a device is the Freescale i.MX25 that can conditionally boot from a USB gadget if present, and otherwise boot from flash. Other SoC's require a fixed boot device configuration to be set before boot time.
U-Boot and Barebox are general, cross-platform bootloaders that have been ported to a very wide range of CPU architectures. The advantage of using one of these bootloaders is the functionality that they provide:
* optional command line shell
* conditional boot options
* scripting language
* flash technology awareness
* network boot capability
The disadvantages are that that these bootloaders can require up to four megabytes of flash space when using NAND flash, and by their sheer size they can increase the total boot time by more than a second.
This strategy is appropriate for applications, or stages of application development, that require editing or modification of files in the root filesystem and saving the modifications persistently. For example, if you need to manually change network configuration files on a running application and want the changes to be persistent over reboot operations, then this is an appropriate option. This option is not appropriate for applications that require a high level of security.
This strategy is appropriate when you do not want to allow persistent changes in the filesystem for reasons of security or reliability, but you also do not want to load the entire filesystem into RAM. You can achieve read/write capability by using a unionfs file system to transparently write modified files to a shadow files system in RAM. Any modifications that you make will only persist until the next reboot.
This strategy is appropriate when you have adequate RAM and you do not want to allow modification of the flash, except when updating the firmware. This strategy also allow you to perform a firmware upgrade on the flash from the operating system that is running from RAM. This strategy is commonly used in routers, set-top boxes and other networking applications.
This strategy is appropriate when you have adequate RAM. It differs from running from a RAMFS in that it runs from the buffr cache itself, without an underlying file system layer. This can provide run-time performance benefits
We invite you to discuss you embedded Linux application with a senior TkOS engineer. Please arrange an appointment with one of our engineers by contacting Alan Yaniger at <alan@tkos.co.il>.