Components of Embedded Linux (Part 1)

Components of Embedded Linux (Part 1)

We know that Linux runs everywhere from supercomputers, servers, desktops (laptops), phones (androids)… to home appliances.

When using a personal computer, the server can easily “touch” Linux components such as processes, shell..etc.
Most popular distributions do everything related to hardware, operating system kernels, and drivers for us. We are usually only interested in the application running on it.

But in another array of applications of Linux, where we usually run only 1 application, it is very difficult to see the internal components, almost immutable… how is Linux, it is similar to the distributions Will we still meet?

Then also, from a “coder’s point of view”, how does one develop such a device running Linux.

This article only talks about the components that one has to think about when developing an application on a new piece of hardware. Of course, most of us will develop apps, with little touch on those parts. But having an overview would be interesting.

1. Toolchain – compiler, linker, sysroot…
Why care about toolchain in the first place, and what is a toolchain?

As we all know, to run any C (any other language) code, no matter how simple, we have to compile it into binary code that the computer understands. That compilation requires a piece of software called Compiler.

If that C uses other libraries, for example the standard library for input and output, it most likely also needs the header files, the library’s binary codes.

To link those things together and create a executable binary file, a Linker is needed.

Then from C code, not only one step is turned into machine code, it has to convert to Assembly code and then use it to convert from Assembly code to machine code. That at least requires 1 more Compiler for Assembly.

Since humans no longer write binary code directly for computers, any software from bootloader, kernel, ls command, copy command, etc must be compiled into binary code to be inserted into the running computer. Okay.

Therefore, if it is not possible to generate binary code for the platform, then we still only have 1 “hardware” in its truest sense.

So what is the general Linux Toolchain?

It includes at least the following components:
– binutils (processing tools related to coding): GNU Assembler, Linker, etc.
– gcc: GNU C Compiler
C library (libc): includes header files and binary files that allow the application to communicate with the operating system.
– gdb: Debugger

There are 2 types of Toolchain, Native and Cross, divided according to the relationship between the environment it runs in and the environment it generates binaries for:

Native : ie run on any machine, generate binary code to run for that machine
For example, the distributions we still use are also called using the Native Toolchain
Cross: ie run on one machine, but generate binary code for another machine.
When developing Embedded Linux, most of us will use Cross Toolchain.
Because devices run often low speed, low memory, so it is not suitable to build source on it.

C Library

Or the glibc we still see on distros, often accompanied by GCC for the respective Platform

There are 3 options of this library:
– GNU glibc: full functionality of glibc, but large in size and expensive to run
– GNU eglib: still glibc, but easier to configure, easier to use on Embedded systems
– uClibc: small, do not update thread-related libraries and other POSIX functions

Criteria for choosing a Toolchain
– Is your platform well supported: eg which ARM architecture is supported, …is it soft-float or hardfloat.
– Is there a C library that matches the project requirements?
– Is there an update?
– Is there good support (from community or commercial)?
– Are the included tools delicious?

Many companies build Toolchain themselves, but I guess they are usually based on an existing Open-source Toolchain. Below are some very commonly used Toolchains.
Problems using the library

There are many Toolchains that only provide the correct C Standard library.

What if I want to use another library?
You might be lucky if you find a build of that library for your platform already provided by the author or someone else.

In the worst case, you have to get the source to build yourself. If the library is well written, it doesn’t matter, otherwise it may not be possible to build or it is very laborious.

Therefore, it is better to choose Toolchain which is supported by many libraries.

  • Share


Leave a Reply

Your email address will not be published.