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
No comments:
Post a Comment