Linux:实际成本滚自己的平台

The following is an edited extract from a white paper from Wind River entitled ” The Real Costs of Roll-Your-Own Linux.” Download a copy of this paper from the Control Engineering ’s Resource Center at www.globalelove.com .

Linux is the operating system of choice for a growing number of new device software projects. The most obvious advantages of Linux are easy availability of its source code from thousands of Websites, freedom from licensing and redistribution costs, the vast amount of system software, middleware, and application software freely available for Linux, and the power and flexibility that a true multitasking operating system brings to device software.

Unfortunately, power, flexibility, and easy availability do not mean that manually creating and maintaining a device-specific Linux platform, commonly known as “rolling your own” (RYO) Linux platform. is a trivial task. As many roll-your-own developers come to realize, RYO Linux can unwittingly put project teams on a path that distracts them from what really matters: device differentiation.

Any Linux platform consists of three basic elements: Linux kernel, Root file system, and a Toolchain to produce application software that runs on the target hardware). Rolling your own Linux platform means that you must obtain, build, and support each of these components yourself.

The version of the Linux kernel that you decide to use usually depends on the level of support for your target architecture and processor in the latest version of the mainline Linux kernel (available from www.kernel.org ), as well as the versions of the kernel against which any patches you want to apply were created.

The biggest hurdle in any roll-your-own Linux platform development project is getting the necessary tools to build system software, application software, and the Linux kernel for your target embedded device.

Most Linux platforms use a set of tools based on the GNU Compiler Collection , an open-source collection of compilers that includes the world’s most popular C compiler, GCC. Using GCC also requires that you build or obtain two other software packages: a C library used by the compiler; and a set of tools required to create executable programs and associated libraries for your target device. The sum of all these parts is a toolchain.

Producing binaries for an embedded target presents an interesting bootstrapping problem. Because you do not have Linux running on your target hardware platform yet, you don’t have anywhere to run a native version of GCC. Similarly, many device software platforms don’t have sufficient resources to store and run a native compiler. For these reasons, Linux platform development is typically done on a desktop machine using a special toolchain known as a cross-compiler, which runs on a host system, yet produces binaries that will run on a different target system.

Once all your source code is ready, you must then build the components of the cross-compilation environment in the right order. If your target platform is a standard one, open-source tools such as Dan Kegel’s crosstool script and Erik Anderson’s buildroot package can help with the toolchain build process. If you are building a toolchain for a less common embedded system, you may need to manually create your own configuration.

Your final consideration when building a toolchain is that multiple C libraries are available for use on device software platforms. The standard GNU C library, glibc, can be quite large and may produce binaries that are too large to run or deploy on your target system. Integrating another C library into a toolchain may be complex and requires expertise beyond that required for building a standard cross-compilation toolchain.

After many cycles of compiling the kernel, seeing a compilation problem, fixing that problem, and recompiling, you will eventually have a kernel that compiles cleanly and may run on your target hardware. The next step in a roll-your-own Linux project is to download the kernel to the board and test it.

你可能需要遍历多个内核部ild cycles to resolve problems for the kernel to initialize your hardware correctly and display kernel status messages. Seeing a message stating that the kernel couldn’t find its root file system is a significant milestone in any roll-your own Linux project.

The process of creating a root file system is essentially the same regardless of whether you will be deploying an in-memory or physical file system. The first step is to identify the software packages you want to have in your file system to initialize the system correctly, start up mandatory services, and support the applications that your embedded platform will run when deployed.

Once your roll-your-own Linux system boots and correctly executes applications from your root file system, you can begin writing any custom device drivers for hardware specific to your embedded device. If you are using off-the-shelf hardware, these device drivers may be provided in any patches available from the semiconductor or board manufacturer. Otherwise, you will have to write your own drivers and either integrate them directly into the kernel or cross-compile them as loadable kernel modules that the kernel will load from its root file system.

Developing the applications that make your embedded device unique and provide the capabilities that its users require is obviously specific to the target market for your device. However, your application may require additional services that are unavailable in the root file system you have created up to this point. For example, network-oriented devices often require software packages that enable your system to obtain an IP address dynamically.

Once a package cross-compiles cleanly, you can then install it in your working root file system, rebuild that file system if necessary, recompile the kernel if required, and then redeploy and test the updated root file system and/or kernel.

Assuming you have the required expertise, rolling your own embedded Linux platform can be cost-efficient, due to the free availability of everything up to any proprietary device drivers and applications that you develop and deploy. However, basing the success and stability of the Linux platform that hosts those drivers and applications on completely free software and a potentially customized kernel can be a frightening business prospect.

While test code is a part of any good internal software development project, system test software for an operating system and related utilities outside your control is a different issue. After scripting local and remote test scenarios for the software and drivers you have written for your device software platform, a popular solution for testing a Linux system itself is the open-source test software developed as part of the Linux Test Project (LTP).

In addition to the LTP tests, other open-source test suites, such as the Linux Standard Base test suite (LSB), are also available. Depending on which industry you target, compliance requirements for platforms that claim adherence to standards may mandate that your platform pass tests like the LSB tests.

Many businesses have successfully rolled their own Linux platforms and deployed products based on them. Developing and installing a device software platform on a single desktop system is a manageable, although complex, process.

Beyond the immediate personnel costs of developing, packaging, and deploying a roll-your-own Linux platform, long-term personnel resources and the conceptual costs of staying current with the kernel and all the packages in your root file system are important considerations. In general, supporting, maintaining, and updating a cross-compilation environment, Linux kernel, root file system, and your applications requires a wide range of expertise. Similarly, monitoring a variety of packages and the Linux kernel in the open-source community, watching for security, performance, or other essential features in those packages or the kernel, integrating those patches, and deploying embedded system updates are complex, time-consuming tasks, especially in terms of updating drivers and kernel subsystems. This may require dedicated support personnel and developers who work outside your traditional domain of business expertise, but who must be available whenever that expertise is needed.

Read the full

white paper from Wind River: The Real Costs of Roll-Your-Own Linux

” (registration to Control Enginering Resource Center required).

Read other “open source” articles from Control Engineering

.

Edited by C.G. Masi, senior editor, Control Engineering Machine Control eNewsletter charlie.masi@reedbusiness.com

For more information about using Linux for embedded systems, visit Wind River at windriver.com .

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Clickhereto start this process.