Commercial versus Open Source
Embedded Linux developers have two main options when selecting a Linux OS: "free" versions that are available as downloadable object/source code and covered by open source licenses, and commercial distributions that are maintained and supported by companies as commercial products.

Most developers today use free distributions. A 2007 survey by market research firm VDC asked current Linux users which Linux OS they would use in their next project, and a whopping 71% of the embedded system engineers who responded said they would use Linux on a free distribution basis (Figure 1 below).

Figure 1. Linux Operating System planned for next project (Source: VDC, 2007)

As embedded developers choose the Linux distribution for their next design project, it is important that they recognize the limitations of free distributions.

These limitations include the lack of availability of rich Linux tools, a larger footprint than competing real-time operating systems, the challenge of optimizing Linux to address real-time requirements, and the fact that support and development tools for free distributions of Linux are limited at best. With all of these considerations, "free" may mean free to use, but it is not necessarily free of cost.

"Free" to Use, not "Free" Cost: the Debug Challenge
Beyond the decision of whether to choose a commercial or free distribution of Linux, developers must understand the capabilities and limitations of their debug/development tools.

Any meaningful design in the embedded SoC domain requires well-integrated software development tools targeted specifically at the embedded space. Open source tools—from compilers to applications—are expected to be production quality. And developers expect that tools will work together seamlessly with a small learning curve.

Leveraging free distributions of embedded Linux has become a widely accepted practice in the consumer product space. In these markets, product run rates are high, enhancements to the code are frequent, and cost of goods sold is critical; all of which make the open source model attractive.

But while the general expectation is for open source tools to be close to production-quality, "free" and "commercially available," are not synonymous. Tools that can integrate open source/freeware and also provide a seamless debug environment for a processor core require a deep understanding of the core and SoC component interaction. Expert knowledge is required to make today's open source tools work.

There are several "freeware" debug solutions available, and designers need to fully understand their limitations. For example, probably the most popular freeware debugger for the Linux kernel is KGDB.

The major drawback to KGDB is the requirement to recompile the kernel. This is not always possible for applications where the product is already deployed to the field. Patching the kernel can also introduce code changes that can affect system performance.

GDBServer is another popular freeware debugger for application debug. It too is severely limited. A major issue is the lack of support for simultaneously debugging a large number of threads/processes.

As the number of threads/processes being debugged goes up, the performance of GDBServer deteriorates rapidly to the point that response times are so slow that it can cause the target system to fail. Additional concerns include the inability to debug drivers and applications over the same target connection, debugging device drivers and debugging shared libraries.

The bottom line is that it's extremely important to understand the debug demands for your particular application, and choose your tools accordingly.