Buildroot is a project that helps you create root file systems and toolchains that use uClibc and BusyBox, a small C Library, and basic set of root file system tools. Buildroot grew out of the BusyBox and uClibc projects, two of the most commonly used pieces of software for embedded projects. Because this tool integrated both of these projects, it serves as a great starting point for creating a Linux distribution for a project.
Like LTIB, Buildroot uses an interface that’s similar the tool used to configure the kernel. Although this is comforting for a system-level engineer, the tool can be confusing if you’re a new engineer. The primary problem with this tool is that you have to keep track of where you are; after you use the software for a few minutes, nearly every page looks the same, and picking the correct options becomes tedious. Buildroot configures an entire development environment—kernel, root file system, and toolchain— which means you need to configure the options for these complex projects before starting a build. There are literally hundreds of options to configure, and the sheer number of items makes the process mildly tedious. For some boards, default configuration files configure the build with the right settings. Unfortunately, there aren’t many of these default configuration files, so the chances of one matching the board you’re using are fairly low.
Buildroot uses tar files as its package system and uses a collection of make files to configure the software before building. This implementation is easy to understand if you’ve used make in the past for moderately complex projects. Each package has a .mk file containing the make rules necessary to download, configure, build, and clean the package and a Config.in that is used by the configuration tool.
Source of Information : Pro Linux Embedded Systems
Sunday, April 11, 2010
Saturday, April 10, 2010
Open Source Embedded Distributions - LTIB (http://www.bitshrine.org)
The Linux Target Image Builder (LTIB) user interface is much like the kernel configuration tool, which, although familiar to systems-level engineers, can be confusing if you’re new to Linux. LTIB is accommodating in that it does its best to verify the environment before starting a build and lets you know about corrective actions before starting a 3-hour build process.
One of the complaints about LTIB is that the first time it runs, it downloads the entire set of packages that it could use in a distribution. This is a mixed blessing in that after the packages are on the system, the host doesn’t need to be attached to the network in order to get a build running. Another advantage of the big download is that you can put the entire directory into a code librarian and check it out on a build machine for easy platform scripting.
The second complaint is that the software doesn’t build toolchains but downloads the binaries and installs them on the system. This is also somewhat advantageous in that building a toolchain requires at least an hour on a very fast computer and, due to the patches and configuration dependencies, is an operation that frequently fails. LTIB provides the sources for the toolchain it downloads; it just doesn’t build the toolchain during the build process running on the host machine.
One great advantage of LTIB is that it builds a JFFS2 image containing the root file system, ready to be burned on to a flash partition, as part of the build. Along with the self-contained nature of the project, LTIB is a great tool if you want or need to automate your platform build.
LTIB is an RPM-based system. This means it uses source RPM files to do the build, and integrating a package into LTIB means learning how to create RPM packages. Creating a source RPM build for an application isn’t difficult; but for some reason, it scares some users away from fully taking advantage of LTIB. Instead of having the software build your application from an RPM as part of the LTIB build, you can post-process the file system, adding the application and making any final changes.
Source of Information : Pro Linux Embedded Systems
One of the complaints about LTIB is that the first time it runs, it downloads the entire set of packages that it could use in a distribution. This is a mixed blessing in that after the packages are on the system, the host doesn’t need to be attached to the network in order to get a build running. Another advantage of the big download is that you can put the entire directory into a code librarian and check it out on a build machine for easy platform scripting.
The second complaint is that the software doesn’t build toolchains but downloads the binaries and installs them on the system. This is also somewhat advantageous in that building a toolchain requires at least an hour on a very fast computer and, due to the patches and configuration dependencies, is an operation that frequently fails. LTIB provides the sources for the toolchain it downloads; it just doesn’t build the toolchain during the build process running on the host machine.
One great advantage of LTIB is that it builds a JFFS2 image containing the root file system, ready to be burned on to a flash partition, as part of the build. Along with the self-contained nature of the project, LTIB is a great tool if you want or need to automate your platform build.
LTIB is an RPM-based system. This means it uses source RPM files to do the build, and integrating a package into LTIB means learning how to create RPM packages. Creating a source RPM build for an application isn’t difficult; but for some reason, it scares some users away from fully taking advantage of LTIB. Instead of having the software build your application from an RPM as part of the LTIB build, you can post-process the file system, adding the application and making any final changes.
Source of Information : Pro Linux Embedded Systems
Friday, April 9, 2010
MontaVista
MontaVista’s Linux operating system started as Hard Hat Linux that offered realtime performance. The company has branched out into serving the general embedded Linux market and has extended its product offerings through the addition of an IDE and other tools. MontaVista’s value proposition is around delivering a well-tested Linux distribution paired with support and tools. MontaVista has two targeted distributions: one for carrier grade for telecommunications applications, and the other Mobilinux for handsets. The company also markets a general-purpose Linux distribution, Professional Edition. Unlike Wind River, MontaVista’s focus is entirely on embedded Linux, and the company has embraced open source from its inception. The company regularly contributes to the Linux kernel (and, using number of changes contributed as a metric, is one of the top contributors to the Linux kernel project) and other open source initiatives, such as power management and special-purpose file systems. Although the software offered by MontaVista may lag behind that of the general Linux community by a year to 18 months so it can be tested and validated, the company has proven that it’s always working on the next version of Linux for its customers. A transaction with the company involves purchasing a subscription that gives you the right to a certain number of software updates, the use of tools, and support during the length of the engagement. During the sales process, it’s typical for MontaVista to sell services and training as well.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Why Embedded Linux Distribution Builders Exist
These distribution-building tools exist due to a catalyst such as supporting a particular usage scenario (for example, as small as possible or rescue disks) or a certain hardware platform (such as a cell phone). These aren’t mutually exclusive concepts, because cell phone Linux distributions are frequently small— resource consumption is very important for that hardware platform. The concept of a distribution builder isn’t limited to embedded Linux; the same concept exists for desktop Linux systems, the output being an ISO and collection of packages (think RPMs or debs) In the case of hardware platform–specific distribution builders, the vendor isn’t interested in selling the Linux distribution, but rather sees the Linux distribution as an enabler for hardware sales and also as a way to potentially harm the revenue stream of a competitor that sells a Linux distribution as an add-on product. Linux is a way to help sell hardware, plain and simple. As time progresses, the distributionbuilder project begins to support a larger variety of hardware, because adapting an existing code base makes for smart engineering. Several embedded distributions are package system based. The distributions are embedded in terms of the packages, target platform, and size that use an underlying packaging technology to achieve this aim. Although some projects use the same packaging system but have a focus on a particular technology or hardware, these projects are focused on the packaging system.
Source of Information : Pro Linux Embedded Systems
Source of Information : Pro Linux Embedded Systems
Thursday, April 8, 2010
Open Source Embedded Distributions
An ever-increasing number of projects build Linux distributions, to the point that building a Linux distribution is a rite of passage for engineers, like building a text editor was in years past. Linux distribution builders all work on the same basic principles: a kernel and group of packages are built according to a specification into a completed set of binaries suitable for deployment. Some distribution builders create a toolchain as part of the process, and others download a binary toolchain from a known location.
When you’re classifying these systems, the type of packaging system is a good first-order differentiator, because no matter how the system tries to shield you from the particulars, you eventually need to get familiar with this underlying technology. The most common packing system is a compressed tar file; that’s fortunate because this packaging technology is the lowest common denominator and is familiar to most engineers, Linux and otherwise.
Source of Information : Pro Linux Embedded Systems
When you’re classifying these systems, the type of packaging system is a good first-order differentiator, because no matter how the system tries to shield you from the particulars, you eventually need to get familiar with this underlying technology. The most common packing system is a compressed tar file; that’s fortunate because this packaging technology is the lowest common denominator and is familiar to most engineers, Linux and otherwise.
Source of Information : Pro Linux Embedded Systems
Wednesday, April 7, 2010
Obtaining Linux from the Board Vendor
Board vendors frequently include a Linux distribution with a board so that users can start up the board and see that it works, exercise critical peripherals, and otherwise make sure the board performs as expected. Embedded projects frequently start on a development board that’s a proxy for the production board that hardware designers are creating for the device. The completeness of a Linux distribution supplied with the board varies greatly from vendor to vendor and sometimes from board to board.
A development board contains every peripheral possible and has ports that make it easy to attach off-the-shelf components to the board when you’re doing development. The development board contains LEDs and sometimes a small LCD to report on the internal board state. During the hardware design process, another team creates a board that fits the industrial design of the device, with the connectors in the right places and the subset of peripherals for the device. This board operates just like the development board from a software perspective, but it doesn’t resemble the development board from a physical perspective.
Questions You Should Ask Your Board Vendor
The point of these questions is both to assess whether the product offered by the vendor is good enough for the project and to see how committed the vendor is to creating providing a complete solution that will be supported throughout the project:
• What devices does the kernel support? You’d think that the devices on the board would be supported, but that isn’t always the case! Make a checklist of the devices that will be on the production board so you don’t forget any when querying the board vendor. Some board vendors support the most commonly used devices, like network or serial ports, but don’t have proper support for a video-out port or audio device.
• Where are the source code and patches for the kernel? Open source means you’re entitled to the source code, any patches, and instructions explaining how to use those patches. Patches sometimes need to be applied in a certain order, because one patch makes changes on the assumption that some other patch has been applied first. The fact that patches are interrelated isn’t indicative of poor engineering, but rather that the company has been carefully tracking the changes it makes to the main kernel. If you’re aware of other patches that need to be applied, you should test to be sure they’re compatible with what the vendor has supplied. For example, the patches for a project like Linux-tiny1 may make changes throughout the kernel, and those changes may collide with other changes from the vendor. Not all of these issues can be identified or solved before purchasing, but you should address as many that are known.
• How compatible are patches with the current Linux kernel? This is important. In the Linux project, changes happen to the head of line (old-school speak for the version that will be released next) and are rarely back ported. That means if there’s a change to the kernel—say, to address a security issue—that change is made to the current kernel and not to the one included with the board, unless that kernel happens to be the head of line. The answer to this question is a function of how old the patches are in combination with how many other changes they contain. For some boards, the changes, although extensive, are limited to the parts of the kernel that deal specifically with the hardware and can be transferred easily to a newer version of the kernel if necessary. Even if patches can’t be applied to the newest kernel, you many never need to switch to a newer kernel, making this a moot point.
• What level of testing has been performed? One of the things a commercial vendor knows is the state of the software being delivered. Sometimes, the answer is that no testing has occurred. Depending on the project, that may or may not be sufficient. The internal testing done by your company may trump what ever testing the board vendor has or hasn’t done.
• Where’s the toolchain? Getting the sources with the binaries is part of the GPL. There’s no provision to ensure that the tools and software necessary to transform those sources into binaries are part of that equation. The toolchain supplied should be the same one used to build the kernel and the root file system (see the next item), and the supplier should include instructions on how to rebuild the toolchain as well. The GNU toolchain is a group of related projects: a compiler, libraries, linker, utilities, and a debugger. The vendor should understand this notion and be able to describe the version and patches applied to each. As a user, the chances of rebuilding the toolchain completely are fairly low, but you’re likely to need to add libraries or use a newer version of the debugger. Knowing how the toolchain is configured helps you determine compatibility with any additional or updated software. In addition, getting the answer to this question serves as a way to gauge the competency and level of engagement of the vendor with respect to their Linux efforts. Some board vendors put a great deal of care and effort into supplying a top-notch distribution, whereas others do the minimum to claim Linux support.
• What’s in the root file system? This is a deliberately broad question, mostly because it’s a broad topic. A root file system, as explained later in the book, is a complex project that involves several related projects coming together. A root file system can be anything from one file to the contents of an enterprise Linux server. The vendor should be able to describe the version for each software component used in the root file system. If you plan to use shared libraries, make sure the shared libraries in the root file system match those in the toolchain. This is a critical detail! When you’re crosscompiling applications that use shared libraries on the desktop, those binaries dynamically link to the shared libraries with the toolchain; however, when those same binaries are put in the root file system on the board, they attempt to link with those shared libraries. If there’s a mismatch between the libraries used for the compilation and those used for execution, the software may refuse to load or, even worse, may fail unpredictably. If you’re linking statically, the shared libraries aren't important, because the code that would reside in the shared library is included in the compiled binary.
• Do the devices supported on the board have their complementary userland supporting packages? This is another semi-trick question to gauge the level of care that went into creating the root file system. Devices have become more complex and, for lack of a better word, interactive. For example, supporting USB devices requires support in the kernel and complementary packages in the root file system. The Linux USB software stack includes programs in the root file system that are executed when a user plugs in or unplugs a USB device.
• Where are the root file system sources and patches, and how do I build it? Like the toolchain, the root file system is a confederation of packages that work together.
Packages included in the root file system are typically licensed under the GPL, so you’re due the source under that license agreement along with the build instructions. The build instructions need to explain how to apply any patches along with the information necessary for compilation. Because the root file system is a collection of packages, the vendor should explain how to assemble all the packages into something that you can use for booting the board. (This isn’t part of the GPL, but it’s knowledge you’re paying for as part of the purchase.)
• How often does the company plan to upgrade the kernel? The Linux project (both the kernel and the collection of projects that make up the root file system) doesn’t rest: changes are continually occurring, and that’s certainly a good thing. As a customer, understanding how the board vendor reacts to this change helps you understand how you’ll be kept up-to-date with the changes in the open source community. Will the software be updated as kernel and package updates occur? Is there a regular release cycle during which the vendor collects changes and validates and tests them before release? Or is the Linux distribution a snap-shot of the current state of the projects and never updated, leaving updates to you? All of these are valid approaches, and as the buyer, it’s important for you to know what the board vendor is supplying.
• What support do you provide? What sort of questions will you answer? The answer to these questions reveals the amount of in-house expertise the vendor has at its disposal; in general, the more resources the vendor has, the more they’re willing to share those resources with their customers. You should also ask yourself what level of support required. If this is the first embedded Linux project undertaken at your company, the type and level of support required will be different than if the company already has a high degree of Linux expertise. Some support agreements explicitly say that consulting services aren’t offered, where consulting means providing advice related to how to use the software. From the vendor’s perspective, the support contract exists to limit the support offered, so the vendor doesn’t make a commitment it can’t fulfill.
Source of Information : Pro Linux Embedded Systems
A development board contains every peripheral possible and has ports that make it easy to attach off-the-shelf components to the board when you’re doing development. The development board contains LEDs and sometimes a small LCD to report on the internal board state. During the hardware design process, another team creates a board that fits the industrial design of the device, with the connectors in the right places and the subset of peripherals for the device. This board operates just like the development board from a software perspective, but it doesn’t resemble the development board from a physical perspective.
Questions You Should Ask Your Board Vendor
The point of these questions is both to assess whether the product offered by the vendor is good enough for the project and to see how committed the vendor is to creating providing a complete solution that will be supported throughout the project:
• What devices does the kernel support? You’d think that the devices on the board would be supported, but that isn’t always the case! Make a checklist of the devices that will be on the production board so you don’t forget any when querying the board vendor. Some board vendors support the most commonly used devices, like network or serial ports, but don’t have proper support for a video-out port or audio device.
• Where are the source code and patches for the kernel? Open source means you’re entitled to the source code, any patches, and instructions explaining how to use those patches. Patches sometimes need to be applied in a certain order, because one patch makes changes on the assumption that some other patch has been applied first. The fact that patches are interrelated isn’t indicative of poor engineering, but rather that the company has been carefully tracking the changes it makes to the main kernel. If you’re aware of other patches that need to be applied, you should test to be sure they’re compatible with what the vendor has supplied. For example, the patches for a project like Linux-tiny1 may make changes throughout the kernel, and those changes may collide with other changes from the vendor. Not all of these issues can be identified or solved before purchasing, but you should address as many that are known.
• How compatible are patches with the current Linux kernel? This is important. In the Linux project, changes happen to the head of line (old-school speak for the version that will be released next) and are rarely back ported. That means if there’s a change to the kernel—say, to address a security issue—that change is made to the current kernel and not to the one included with the board, unless that kernel happens to be the head of line. The answer to this question is a function of how old the patches are in combination with how many other changes they contain. For some boards, the changes, although extensive, are limited to the parts of the kernel that deal specifically with the hardware and can be transferred easily to a newer version of the kernel if necessary. Even if patches can’t be applied to the newest kernel, you many never need to switch to a newer kernel, making this a moot point.
• What level of testing has been performed? One of the things a commercial vendor knows is the state of the software being delivered. Sometimes, the answer is that no testing has occurred. Depending on the project, that may or may not be sufficient. The internal testing done by your company may trump what ever testing the board vendor has or hasn’t done.
• Where’s the toolchain? Getting the sources with the binaries is part of the GPL. There’s no provision to ensure that the tools and software necessary to transform those sources into binaries are part of that equation. The toolchain supplied should be the same one used to build the kernel and the root file system (see the next item), and the supplier should include instructions on how to rebuild the toolchain as well. The GNU toolchain is a group of related projects: a compiler, libraries, linker, utilities, and a debugger. The vendor should understand this notion and be able to describe the version and patches applied to each. As a user, the chances of rebuilding the toolchain completely are fairly low, but you’re likely to need to add libraries or use a newer version of the debugger. Knowing how the toolchain is configured helps you determine compatibility with any additional or updated software. In addition, getting the answer to this question serves as a way to gauge the competency and level of engagement of the vendor with respect to their Linux efforts. Some board vendors put a great deal of care and effort into supplying a top-notch distribution, whereas others do the minimum to claim Linux support.
• What’s in the root file system? This is a deliberately broad question, mostly because it’s a broad topic. A root file system, as explained later in the book, is a complex project that involves several related projects coming together. A root file system can be anything from one file to the contents of an enterprise Linux server. The vendor should be able to describe the version for each software component used in the root file system. If you plan to use shared libraries, make sure the shared libraries in the root file system match those in the toolchain. This is a critical detail! When you’re crosscompiling applications that use shared libraries on the desktop, those binaries dynamically link to the shared libraries with the toolchain; however, when those same binaries are put in the root file system on the board, they attempt to link with those shared libraries. If there’s a mismatch between the libraries used for the compilation and those used for execution, the software may refuse to load or, even worse, may fail unpredictably. If you’re linking statically, the shared libraries aren't important, because the code that would reside in the shared library is included in the compiled binary.
• Do the devices supported on the board have their complementary userland supporting packages? This is another semi-trick question to gauge the level of care that went into creating the root file system. Devices have become more complex and, for lack of a better word, interactive. For example, supporting USB devices requires support in the kernel and complementary packages in the root file system. The Linux USB software stack includes programs in the root file system that are executed when a user plugs in or unplugs a USB device.
• Where are the root file system sources and patches, and how do I build it? Like the toolchain, the root file system is a confederation of packages that work together.
Packages included in the root file system are typically licensed under the GPL, so you’re due the source under that license agreement along with the build instructions. The build instructions need to explain how to apply any patches along with the information necessary for compilation. Because the root file system is a collection of packages, the vendor should explain how to assemble all the packages into something that you can use for booting the board. (This isn’t part of the GPL, but it’s knowledge you’re paying for as part of the purchase.)
• How often does the company plan to upgrade the kernel? The Linux project (both the kernel and the collection of projects that make up the root file system) doesn’t rest: changes are continually occurring, and that’s certainly a good thing. As a customer, understanding how the board vendor reacts to this change helps you understand how you’ll be kept up-to-date with the changes in the open source community. Will the software be updated as kernel and package updates occur? Is there a regular release cycle during which the vendor collects changes and validates and tests them before release? Or is the Linux distribution a snap-shot of the current state of the projects and never updated, leaving updates to you? All of these are valid approaches, and as the buyer, it’s important for you to know what the board vendor is supplying.
• What support do you provide? What sort of questions will you answer? The answer to these questions reveals the amount of in-house expertise the vendor has at its disposal; in general, the more resources the vendor has, the more they’re willing to share those resources with their customers. You should also ask yourself what level of support required. If this is the first embedded Linux project undertaken at your company, the type and level of support required will be different than if the company already has a high degree of Linux expertise. Some support agreements explicitly say that consulting services aren’t offered, where consulting means providing advice related to how to use the software. From the vendor’s perspective, the support contract exists to limit the support offered, so the vendor doesn’t make a commitment it can’t fulfill.
Source of Information : Pro Linux Embedded Systems
Subscribe to:
Posts (Atom)