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.
This section outlines what you need to know to decide about the usefulness of the distribution bundled with the board. In many cases, engineers use the Linux included with the board out of a combination of complacency and fear: complacency because the software works, and fear that getting some other Linux kernel or distribution working would be a waste of time and effort. With that in mind, let’s jump in.
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:
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.
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.)
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.
Now That You’re a Customer…
After signing the check and taking delivery of a Linux distribution included with the board, it’s important to assess what was delivered. Plan to spend at least a working week to do the following:
The first three tasks on the list should be done with the tools and advice offered by the vendor. The goal of this exercise is to immediately perform the tasks that will eventually happen in the project, to validate the quality of the delivered software. Even though the distribution includes a kernel that’s ready to boot for the board, rebuilding a kernel or re-creating the root file system shouldn’t be tasks you approach with trepidation, but rather as a natural part of the project.
At a minimum, if the binaries (kernel and root file system) delivered by the vendor can’t be reproduced, the distribution is defective and should be returned for a refund. Likewise, if you can’t build and debug a small application, the vendor hasn’t supplied you with a set of tools adequate for a project.
Linux Embedded systems Related Tutorials
Linux Embedded systems Related Interview Questions
|Linux Embedded systems Interview Questions||Red Hat Linux Essentials Interview Questions|
|Red Hat Linux System Administration Interview Questions||Ubuntu Certified Professional Interview Questions|
|IBM AIX Interview Questions||Solaris Interview Questions|
|HP-ux 11iv3 system administration Interview Questions||Red Hat cluster Interview Questions|
|Embedded C Interview Questions||Unix/Linux Interview Questions|
|Unix Shell Scripting Interview Questions||Solaris Administrator Interview Questions|
Linux Embedded systems Related Practice Tests
|Linux Embedded systems Practice Tests||Red Hat Linux Essentials Practice Tests|
|Red Hat Linux System Administration Practice Tests||Ubuntu Certified Professional Practice Tests|
|IBM AIX Practice Tests||Solaris Practice Tests|
|HP-ux 11iv3 system administration Practice Tests|
Linux Embedded Systems Tutorial
About Embedded Linux
Configuring The Software Environment
Target Emulation And Virtual Machines
Starting Your Project
Getting Linux For Your Board
Creating A Linux Distribution From Scratch
Booting The Board
Configuring The Application Development Environment
Kernel Configuration And Development
Using Open Source Software Projects
Handling Field Updates
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.