So far, I’ve discussed the software components that are on the board. A cross-compiler is part of the development environment and, in the most basic terms, produces code that runs on a different processor or operating system than where the compiler ran. For example, a compiler that runs on a Linux x86 host that produces code to execute on an ARM9 target is a cross-compiler. Another example is a compiler running on Windows that produces code that runs on a x86 Linux host. In both cases, the compiler doesn’t produce binaries that can be executed on the machine where the compiler ran.
In Linux, the cross-compiler is frequently referred to as a tool chain because it’s a confederation of tools that work together to produce an executable: the compiler, assembler, and linker. The debugger is a separate software component. The book later describes how to obtain or create a tool chain for your target processor based on the GNU Compiler Collection (GCC) project.
Linux is GNU licensed software, and subsequently users who receive a Linux kernel must have the ability to get the source code for the binaries they receive. Having the source code is just one part of what’s necessary to rebuild the software for the board. Without the cross-compiler, you can’t transform that source into something that can run on the remote target.
The de facto compiler for Linux is GCC, but this need not always be the case. Several chip vendors market compilers that produce highly optimized code for their processors. The Linux operating system, although written in C and assembler, requires GCC for compilation. However, you can compile programs to be run on the system with a different compiler.
For a certain segment of embedded boards, a cross-compiler isn’t necessary. Many PowerPC boards are as powerful as your desktop system; and some embedded systems are, for all intents and purposes, PCs in a different case. In these cases, development can happen right on the board. The compiler runs on the board, which produces code that runs in the same environment; the development cycle is much like that of a regular software project.
Source of Information : Pro Linux Embedded Systems (December 2009)
Wednesday, March 3, 2010
Tuesday, March 2, 2010
Anatomy of an Embedded Linux System - Root File System
A file system is a way of representing a hierarchical collection of directories, where each directory can contain either more directories or files. For computer science types, this hierarchy is a tree structure in which the files are always leaf nodes and directories are internal nodes when they contain something and leaf nodes otherwise. The point of making this trip down data-structure memory lane is that the top node in a tree structure is the root node and that, in Linux, the file system mounted at the top node is aptly called the root file system.
On your desktop Linux system, you can see what’s mounted as the root file system by doing the following:
gene@imac-2:~$ mount | head -1
/dev/hda3 on / type ext3 (rw,errors=remount-ro)
Just typing mount shows all the file systems mounted. Most Linux systems have several file systems mounted, but all the file systems are mounted relative to the root file system.
When the Linux kernel boots, it must be able to mount a root file system. During the boot process, the root file system can be replaced with another, but only one root file system can be mounted at a time. Failure to mount a root file system means that the system can’t find something to run, because a file system is a container for your program and the kernel panics and halts.
Depending on the board’s hardware and application requirements, you’re free to select any number of root file system types. A completed device contains a single file system mounted at root but likely uses several different file systems mounted at other directories within the root file system. Only one file system can be mounted at the root (/ directory), but Linux allows for an arbitrary number of file systems to be mounted at other locations in the root file system. For example, a system that uses flash memory for storage mounts a RAM-based file system for temporary storage because it’s faster, and flash memory has a much smaller duty cycle than RAM. In the chapters that follow, this book covers how to select a root file system type and how to build one from the ground up.
Source of Information : Pro Linux Embedded Systems (December 2009)
On your desktop Linux system, you can see what’s mounted as the root file system by doing the following:
gene@imac-2:~$ mount | head -1
/dev/hda3 on / type ext3 (rw,errors=remount-ro)
Just typing mount shows all the file systems mounted. Most Linux systems have several file systems mounted, but all the file systems are mounted relative to the root file system.
When the Linux kernel boots, it must be able to mount a root file system. During the boot process, the root file system can be replaced with another, but only one root file system can be mounted at a time. Failure to mount a root file system means that the system can’t find something to run, because a file system is a container for your program and the kernel panics and halts.
Depending on the board’s hardware and application requirements, you’re free to select any number of root file system types. A completed device contains a single file system mounted at root but likely uses several different file systems mounted at other directories within the root file system. Only one file system can be mounted at the root (/ directory), but Linux allows for an arbitrary number of file systems to be mounted at other locations in the root file system. For example, a system that uses flash memory for storage mounts a RAM-based file system for temporary storage because it’s faster, and flash memory has a much smaller duty cycle than RAM. In the chapters that follow, this book covers how to select a root file system type and how to build one from the ground up.
Source of Information : Pro Linux Embedded Systems (December 2009)
Monday, March 1, 2010
Anatomy of an Embedded Linux System - Kernel
As discussed earlier, the Linux kernel was created by a Finnish computer science student as a hobby project and was first released in August 1991. The operating system originally ran only on x86 hosts and was modeled on a teaching aid operating system, MINIX. The Linux kernel was first ported to the Motorola 68KB processor, a painful process resulting in Linus Torvalds designing the kernel for portability. By doing the right thing, he laid the groundwork for Linux being ported to nearly every major processor over the following decade.
Due to the maturity and wide device support of Linux, engineers spend less time doing kernel development work such as creating device drivers (for example, to drive an LCD) and more time and effort creating applications the user values (like displaying the current weather conditions). Some effort may go into customizing the kernel by removing unneeded components or making other tweaks to increase booting time, but generally you don’t need to do the low-level programming necessary to get the Linux kernel running in the first place.
Although it’s an essential and vital component, the kernel has a symbiotic3 relationship with the software it runs. The point isn’t to give the Linux kernel short shrift or minimize its importance! The point is to make clear how the kernel fits into the overall functioning of a Linux system. Without something to run, the kernel stops executing and panics. That’s where the root file system and your application come into play.
Source of Information : Pro Linux Embedded Systems (December 2009)
Due to the maturity and wide device support of Linux, engineers spend less time doing kernel development work such as creating device drivers (for example, to drive an LCD) and more time and effort creating applications the user values (like displaying the current weather conditions). Some effort may go into customizing the kernel by removing unneeded components or making other tweaks to increase booting time, but generally you don’t need to do the low-level programming necessary to get the Linux kernel running in the first place.
Although it’s an essential and vital component, the kernel has a symbiotic3 relationship with the software it runs. The point isn’t to give the Linux kernel short shrift or minimize its importance! The point is to make clear how the kernel fits into the overall functioning of a Linux system. Without something to run, the kernel stops executing and panics. That’s where the root file system and your application come into play.
Source of Information : Pro Linux Embedded Systems (December 2009)
Sunday, February 28, 2010
Anatomy of an Embedded Linux System - Boot Loader
Boot loaders can be laden with features, but their primary responsibility is to get the processor initialized and ready to run the operating system. Later in the book, I go through the boot-up process from beginning to end; but for practical purposes, this is the software that’s first run on the system.
In most modern embedded Linux systems, the kernel is stored in a partition in flash memory. The boot loader copies that flash partition into a certain location in RAM, sets the instruction pointer to that memory location, and tells the processor to start executing at the instruction pointer’s current location. After that, the program that’s running unceremoniously writes over the boot loader. The important thing to note is that the boot loader is agnostic with respect to what is being loaded and run. It can be a Linux kernel or another operating system or a program written to run without an operating system. The boot loader doesn’t care; it performs the same basic actions in all these use scenarios.
As boot loaders have matured, they’ve become more like operating systems with network, video, and increasing support for flash storage devices. Later in this book, I look at the popular boot loaders you may encounter when working with Linux.
One more important note: boot loaders are now ubiquitous. Rarely as an embedded Linux developer do you need to port a boot loader for your board. You may want to recompile the boot loader (I’ll cover that, too) to remove functionality to conserve space and increase boot time, but the low-level engineering is done by the board vendor. Users of Intel-based systems that use the Phoenix BIOS boot loader have no opportunity to change this code, because it’s baked into the board design.
If you’re familiar with Linux systems running on PC-type hardware, you’re no doubt familiar with Grub and LILO. If you’re not, hit the reset button and wait. You see one or the other as the computer starts. Technically, these aren’t boot loaders, but loaders for Linux. Old-school Linux users remember running a similar program, loadlin, from the DOS prompt in order to begin running Linux after the PC first booted DOS or Windows; in this case, MS-DOS acted as the boot loader for Linux. The boot loader contained in the BIOS of the machine read these programs from a certain sector of a disk and begins running them.
Source of Information : Pro Linux Embedded Systems (December 2009)
In most modern embedded Linux systems, the kernel is stored in a partition in flash memory. The boot loader copies that flash partition into a certain location in RAM, sets the instruction pointer to that memory location, and tells the processor to start executing at the instruction pointer’s current location. After that, the program that’s running unceremoniously writes over the boot loader. The important thing to note is that the boot loader is agnostic with respect to what is being loaded and run. It can be a Linux kernel or another operating system or a program written to run without an operating system. The boot loader doesn’t care; it performs the same basic actions in all these use scenarios.
As boot loaders have matured, they’ve become more like operating systems with network, video, and increasing support for flash storage devices. Later in this book, I look at the popular boot loaders you may encounter when working with Linux.
One more important note: boot loaders are now ubiquitous. Rarely as an embedded Linux developer do you need to port a boot loader for your board. You may want to recompile the boot loader (I’ll cover that, too) to remove functionality to conserve space and increase boot time, but the low-level engineering is done by the board vendor. Users of Intel-based systems that use the Phoenix BIOS boot loader have no opportunity to change this code, because it’s baked into the board design.
If you’re familiar with Linux systems running on PC-type hardware, you’re no doubt familiar with Grub and LILO. If you’re not, hit the reset button and wait. You see one or the other as the computer starts. Technically, these aren’t boot loaders, but loaders for Linux. Old-school Linux users remember running a similar program, loadlin, from the DOS prompt in order to begin running Linux after the PC first booted DOS or Windows; in this case, MS-DOS acted as the boot loader for Linux. The boot loader contained in the BIOS of the machine read these programs from a certain sector of a disk and begins running them.
Source of Information : Pro Linux Embedded Systems (December 2009)
Saturday, February 27, 2010
Anatomy of an Embedded Linux System
At runtime, an embedded Linux system contains the following software components:
• Boot loader: What gets the operating system loaded and running on the board.
• Kernel: The software that manages the hardware and the processes.
• Root file system: Everything under the / directory, containing the programs run by the kernel. Every Linux system has a root file system. Embedded systems have a great amount of flexibility in this respect: the root file system can reside in flash, can be bundled with the kernel, or can reside on another computer on the network.
• Application: The program that runs on the board. The application can be a single file or a collection of hundreds of executables.
All these components are interrelated and thus depend on each other to create a running system. Working on an embedded Linux system requires interaction with all of these, even if your focus is only on the application.
If you’re new to Linux but have used other commercial embedded solutions, the notion of a distinct kernel and root file system can be disorienting. With a traditional embedded solution, the application code is linked into a binary image with the rest of the embedded OS. After initialization, the operating system calls a function that is the entry point into your code and starts running.
Source of Information : Pro Linux Embedded Systems (December 2009)
• Boot loader: What gets the operating system loaded and running on the board.
• Kernel: The software that manages the hardware and the processes.
• Root file system: Everything under the / directory, containing the programs run by the kernel. Every Linux system has a root file system. Embedded systems have a great amount of flexibility in this respect: the root file system can reside in flash, can be bundled with the kernel, or can reside on another computer on the network.
• Application: The program that runs on the board. The application can be a single file or a collection of hundreds of executables.
All these components are interrelated and thus depend on each other to create a running system. Working on an embedded Linux system requires interaction with all of these, even if your focus is only on the application.
If you’re new to Linux but have used other commercial embedded solutions, the notion of a distinct kernel and root file system can be disorienting. With a traditional embedded solution, the application code is linked into a binary image with the rest of the embedded OS. After initialization, the operating system calls a function that is the entry point into your code and starts running.
Source of Information : Pro Linux Embedded Systems (December 2009)
Friday, February 26, 2010
10,000-Foot Embedded Linux Development Flyover
This section contains a quick and dirty explanation of the embedded Linux development process. Embedded Linux is a topic with many interdependencies; this section lays out the big points and purposely lacks detail so you can see the big picture without getting distracted by the fine details. The heft of this book should indicate that more details are forthcoming.
Target Hardware
Nearly every project involves selecting the processor to be used. A processor is just a chip and not much more until it’s soldered on a board with some peripherals and connectors. Processor vendors frequently create development boards containing their chip and a collection of peripherals and connectors. Some companies have optimized this process to the point that a board with connectors and peripherals is connected to a small daughter board containing the processor itself, allowing the base board to be shared across several different processor daughter boards.
Development boards are large, bulky, and designed to be easily handled. Every connector is supported by the processor because the vendor wants to create only one board to ship, inventory, and support. The development kit for a cell phone occupies as much space as a large laptop computer. In a majority of products, the development board isn’t used in the final product. An electrical engineer lays out a new board that fits in the product’s case and contains only the leads for the peripherals used in the final application, and he probably sneaks in a place to connect a serial or JTAG port for debugging.
Obtaining Linux
Linux is nearly always included with a development board and has support for the peripherals supported by the chip or the development board. Chances are, the board was tested with Linux to ensure that the processor and connectors work as expected. Early in the history of embedded Linux, there were porting efforts to get Linux running on a board; today, this would be an anomaly. If the board is an Intel IA-32 (frequently called x86) architecture, you can boot it (under most circumstances) with any desktop distribution of Linux. In order to differentiate their IA-32 boards, vendors frequently include a Linux distribution suitable for an embedded project.
Just as the development board has every known connector, the Linux included with the board is suited for development and not for final deployment. Part of using Linux is customizing the kernel and the distribution so they’re correct for the application.
Booting Linux
Because most board vendors supply a Linux distribution with a board, getting Linux booted is about configuring the software services Linux needs to boot and ensuring the cabling is proper and attached. At this point, you probably need a null modem serial cable, a null modem Ethernet cable (or a few cables and an Ethernet concentrator or switch), and maybe a USB cable. Unlike a desktop system with a monitor, the user interface for an embedded target may be just a few lights or a one-line LCD display. In order for these boards to be useful in development, you connect to the board and start a session in a terminal emulator to get access to a command prompt similar to a console window on a desktop Linux system.
Some (enlightened) vendors put Linux on a Flash partition so the board runs Linux at power up. In other cases, the board requires you to attach it to a Linux host that has a terminal emulator, file-transfer software, and a way to make a portion of your Linux system’s hard drive remotely accessible. In the rare cases where the board doesn’t include Linux (or the board in question hails from before you welcomed the embedded Linux overlords), the process requires you to locate a kernel and create a minimal root file system.
Development Environment
Much of the activity around embedded development occurs on a desktop. Although embedded processors have become vastly more powerful, they still pale in comparison to the dual core multigigabyte machine found on your desk. You run the editor, tools, and compiler on a desktop system and produce binaries for execution on the target. When the binary is ready, you place it on the target board and run it. This activity is called cross-compilation because the output produced by the compiler isn’t suitable for execution on your machine.
You use the same set of software tools and configuration to boot the board and to put the newly compiled programs on the board. When the development environment is complete, work on the application proper can begin.
System Design
The Linux distribution used to boot the board isn’t the one shipped in the final product. The requirements for the device and application largely dictate what happens in this area. Your application may need a web server or drivers for a USB device. If the project doesn’t have a serial port, network connection, or screen, those drivers are removed. On the other hand, if marketing says a touch-screen UI is a must-have, then a suitable UI library must be located. In order for the distribution to fit in the amount of memory specified, other changes are also necessary.
Even though this is the last step, most engineers dig in here first after getting Linux to boot. When you’re working with limited resources, this can seem like a reasonable approach; but it suffers from the fact that you don’t have complete information about requirements and the person doing the experimentation isn’t aware of what can be done to meet the requirements.
Source of Information : Pro Linux Embedded Systems (December 2009)
Target Hardware
Nearly every project involves selecting the processor to be used. A processor is just a chip and not much more until it’s soldered on a board with some peripherals and connectors. Processor vendors frequently create development boards containing their chip and a collection of peripherals and connectors. Some companies have optimized this process to the point that a board with connectors and peripherals is connected to a small daughter board containing the processor itself, allowing the base board to be shared across several different processor daughter boards.
Development boards are large, bulky, and designed to be easily handled. Every connector is supported by the processor because the vendor wants to create only one board to ship, inventory, and support. The development kit for a cell phone occupies as much space as a large laptop computer. In a majority of products, the development board isn’t used in the final product. An electrical engineer lays out a new board that fits in the product’s case and contains only the leads for the peripherals used in the final application, and he probably sneaks in a place to connect a serial or JTAG port for debugging.
Obtaining Linux
Linux is nearly always included with a development board and has support for the peripherals supported by the chip or the development board. Chances are, the board was tested with Linux to ensure that the processor and connectors work as expected. Early in the history of embedded Linux, there were porting efforts to get Linux running on a board; today, this would be an anomaly. If the board is an Intel IA-32 (frequently called x86) architecture, you can boot it (under most circumstances) with any desktop distribution of Linux. In order to differentiate their IA-32 boards, vendors frequently include a Linux distribution suitable for an embedded project.
Just as the development board has every known connector, the Linux included with the board is suited for development and not for final deployment. Part of using Linux is customizing the kernel and the distribution so they’re correct for the application.
Booting Linux
Because most board vendors supply a Linux distribution with a board, getting Linux booted is about configuring the software services Linux needs to boot and ensuring the cabling is proper and attached. At this point, you probably need a null modem serial cable, a null modem Ethernet cable (or a few cables and an Ethernet concentrator or switch), and maybe a USB cable. Unlike a desktop system with a monitor, the user interface for an embedded target may be just a few lights or a one-line LCD display. In order for these boards to be useful in development, you connect to the board and start a session in a terminal emulator to get access to a command prompt similar to a console window on a desktop Linux system.
Some (enlightened) vendors put Linux on a Flash partition so the board runs Linux at power up. In other cases, the board requires you to attach it to a Linux host that has a terminal emulator, file-transfer software, and a way to make a portion of your Linux system’s hard drive remotely accessible. In the rare cases where the board doesn’t include Linux (or the board in question hails from before you welcomed the embedded Linux overlords), the process requires you to locate a kernel and create a minimal root file system.
Development Environment
Much of the activity around embedded development occurs on a desktop. Although embedded processors have become vastly more powerful, they still pale in comparison to the dual core multigigabyte machine found on your desk. You run the editor, tools, and compiler on a desktop system and produce binaries for execution on the target. When the binary is ready, you place it on the target board and run it. This activity is called cross-compilation because the output produced by the compiler isn’t suitable for execution on your machine.
You use the same set of software tools and configuration to boot the board and to put the newly compiled programs on the board. When the development environment is complete, work on the application proper can begin.
System Design
The Linux distribution used to boot the board isn’t the one shipped in the final product. The requirements for the device and application largely dictate what happens in this area. Your application may need a web server or drivers for a USB device. If the project doesn’t have a serial port, network connection, or screen, those drivers are removed. On the other hand, if marketing says a touch-screen UI is a must-have, then a suitable UI library must be located. In order for the distribution to fit in the amount of memory specified, other changes are also necessary.
Even though this is the last step, most engineers dig in here first after getting Linux to boot. When you’re working with limited resources, this can seem like a reasonable approach; but it suffers from the fact that you don’t have complete information about requirements and the person doing the experimentation isn’t aware of what can be done to meet the requirements.
Source of Information : Pro Linux Embedded Systems (December 2009)
Subscribe to:
Posts (Atom)