Embedded Linux Basics

12/07/13 - Marc Leeman
Company Confidential - 1
Basic Introduction to
Embedded Linux
Barco Seminar
11/07/2013
Marc Leeman

Patches Accepted
● 11th time we do this training
● 5th time based on SheevaPlug
● Bear with us
● Developed over time
● Inconsistencies in course text/slides(?)
● Feedback welcome!

Goals
● Huge topic, so only introduction
● Hands on, examples, share experience
● Become acquainted with typical small
footprint embedded Linux
● Where to look for setting up or obtaining
a cross compile toolchain environment
● Get to know the typical bootloaders
● Lots-of-examples

Hardware
● SheevaPlug
● Marvell Arm Kirkwood processor
● 1.2 GHz
● 512 MB RAM
● U-Boot bootloader
● 512 MB NAND Flash
● Gb Ethernet, Serial, SD Card, USB, ...

SheevaPlug

Contents
● The GNU/Linux System
● System Overview
● System Design
● Cross Compilation Toolchain
● The Linux Boot Process
● Boot Loaders
● The Linux Kernel
● File Systems
● Userspace

The GNU/Linux System

● Computer operating system and its
kernel -> GNU/Linux, GNU+Linux, ...
● The GNU Project (1983)
● Hurd kernel 1990
● Linux kernel: 1991
● Estimated cost typical linux distribution is
10.8 billion; the kernel alone an extra 1.4
billion (2008, Fedora 9)
● All the underlying source code is
available
Linux

Applications
● LAMP
● Linux, Apache, MySQL, Perl/PHP/Python
● Gaming (PS3)
● Embedded
● Set top boxes, mobile phones, routers &
switches, dreambox, TiVo, …
● Handhelds
● Supercomputers
● 34 fastest running Linux, 92% of top 500

Linux & Super computing

Usability
● KDE/Gnome
● Office, Calenders, ...
● plethora of programs/utilities
● Eye candy: 3D Desktop accelleration
● usability in par with commercial OSes.

Installation
● Easy installation
● Powerful development environment
● Wide architecture support
● Live-CDs, Dual Boot, ...

System Overview

System on Chip
● Hardware varies a lot
● Linux kernel and OS abstracts HW from software
● CPU
● PowerPC (was?) popular in Barco
● ARM seems to be picking up
● Focus on ARM, but techniques can be applied
to other archs.
● X86 systems

System on Chip
● RAM
● Storage
● Used to be typically NOR flash, sometimes
NAND
● Currently NAND due to cost (eMMC)
● I/O
● Lot of variation
● Serial and Ethernet

Embedded Linux Components
● Bootloader
● Linux kernel
● 1 (or more) file systems with userspace
● Kernel sometimes inside rootfs as well

Layering
● Boot loader only active during powerup
● Only kernel talks to hardware
● Same for ALL Linux systems

System Design

Considerations
● Redundancy
● Hardware (network interfaces)
● Software (factory/upgrade)
● Configuration (redundant flash with CRC)
● Predictability
● Uncertainty => fall back to factory settings
● Stability
● Linux :-)
● Monitoring
● Quis custodiet ipsos custodes

Basic choice
● Small and minimalistic
● Focus on minimal footprint
● Reduce component cost (large volumes)
● Minimal functionality
● Often one indivisible deliverable
● Platform approach
● Focus on software design
● Reduce software development cost (a lot of
low volume platforms)
● Pluggable functionality
● Easy functionality extension and system
configuration.
● Trend seems is to focus on software

Small is Beautiful
Speed increase RAM reduction Power reduction Cost reduction
More speed CPU can run slower or stay
longer in power saving mode
Slower, cheaper
CPU
Less RAM Faster allocations
Less swapping
Sometimes less
cache flushing
Fewer / smaller RAM chips:
less dynamic and standby
power.
CPU with less cache: less power
Fewer / cheaper
RAM chips
CPU with less
cache: cheaper
Less space Faster application
loading from
storage and in
RAM.
Sometimes,
simpler, faster
code.
Less RAM usage Fewer / smaller storage chips:
less power
Fewer / cheaper
storage
Less power Cheaper batteries
or cheaper
AC/DC converter
●No black and white choice
●Storage is cheap
●Small does have a cost:
● Focus on software that adds value

Components
● File systems
● Rw: Jffs2, ubifs
● Ro: cramfs, squashfs
● Ext2, FAT
● Glibc or uclibc
● Glibc: localisation (l10n), internationalisation support
(I18n), threading
● Uclibc: replace (configurable) parts of libc allows
optimisation for size
● Scales up to 33% wrt original libc reference
● System utils or busybox
● all-in-one, GNU utils optimised for size

The bootloader
● Das U-Boot
● Extracts kernel image to RAM and sets
Program Counter
● But is much more!
● executes scripts
● can get kernel over network
● can be used to upgrade the flash sections
● debugging over network
● ...

The Linux Kernel
● Basic hardware detection and
initialisation
● In the kernel image is needed:
● minimal configuration to allow recognition of root
FS
● hardware access for root partition
● SCSI, IDE, LIBATA, FLASH, MAC/PHY, ...
● File system
● ext2, ext3, jfs, ubifs, xfs, nfs, reiserfs, ...
● What is not needed:
● Firewall (iptables), keyboard, mouse, ...
(peripherals)
● Can be postponed to the final stages of booting
● Good Practice
● only include needed functionality

Static or Dynamic Linking (1)
Static linking
● All shared library code duplicated in the
executables
● Allows not to copy the C library in the file
system.
Simpler and smaller when very few
executables (busybox)
● Library code duplication: bad for systems with
more executables (code size and RAM)
Best for small systems (< 1-2 MB) with few
executables!
Not used that much anymore

Static or Dynamic Linking (2)
Dynamic linking
● Shared library code not duplicated in
the executables
● Makes much smaller executables
● Saves space in RAM (bigger executable
take more RAM)
● Requires the library to the copied to the
file system
Best for medium to big systems (> 500 KB
- 1 MB)

Libc
● glibc (GNU C library):
http://www.gnu.org/software/libc/
Found on most computer type GNU/Linux machines
Size on arm: approx 1.7 MB
● uClibc: http://www.uclibc.org/
Found in more and more embedded Linux systems!
Size on arm: approx 400 KB (you save 1.2 MB!)
C program Compiled with shared libraries Compiled statically
glibc uClibc glibc uClibc
Plain “hello world” 4.6 K 4.4 K 475 K 25 K
Busybox 245 K 231 K 843 K 311 K

Stripping
● Compiled executables contain extra information which
can be used to investigate problems in a debugger.
● This was useful for the tool developer, but not for the
final user.
● To remove debugging information, use the strip
command.
This can save a very significant amount of space!
gcc o hello hello.c (output size: 4635 bytes)
strip hello (output size: 2852 bytes, -38.5%)

Setting up our Cross
Compilation Toolchain

Terminology
● build platform: where the code is
compiled
● host platform: where the compiled code
will be executed
● target platform: for compilers,
represents what type of object code the
package itself will produce
● preferred compiler for code that runs on
different archs

Terminology (2)
● gcc: GNU Compiler Collection
● 1987...
● glibc: GNU C standard library
● Unix98, POSIX, C99, +extensions
● x86, m68k, Alpha, PPC, ARM, CRIS, MIPS,
s390, SPARC
● Linux +Hurd kernels, also FreeBSD and
NetBSD
● glibc 2 = libc6; (older glibc -> libc5)
● uclibc
● cf. Supra

Top Down Approach
Top-down approach to building an embedded system
● Starting from a complete desktop GNU/Linux
distribution (Debian, Fedora...) and removing
unneeded stuff.
● Very tedious job: need to go through a huge number
of files and packages. Need to understand what each
file and package is about before removing it.
● Keeping unnecessarily complex scripts and
configuration files.
● The end result is still quite big, as standard desktop
tool sets and libraries are used. Lots of shared
libraries still needed too.

Bottom Up Approach
Bottom-up approach to building embedded systems
● Starting with an empty or minimalistic root file
system, adding only things that you need.
● Much easier to do! You just spend time on things you
need.
● Much easier to control and maintain: you build an
understanding about the tools you use.
● You only need very simple configuration scripts.
● The end result can be extremely small, all the more
as you use lightweight tool sets instead.

Toolchain
● gcc:
● cross-compiling: compile for a target
configuration other than the build host.
● $(arch)-$(os){-$(lib)}-gcc
● powerpc-linux-uclibc-gcc,
arm-linux-newlib-gcc
● typical gcc toolchain links against libc
● When uclibc is used, a compiler is needed
that matches that exact uclibc configuration
● automated with buildroot

Toolchain selection
● Depends on your environment
● Native build (x86, emulation, arm, ...)
● Cross compilation build
● Glibc cross compilations toolchains are often
available
● Native complation toolchains are ALWAYS
available (e.g. qemu)
● With uClibc, a exactly matched toolchain is
required

Native and emulation
● The target hardware is very performant
● Target instruction set is emulated
● Both use a 'native' compiler
● Typical easier to use for complex
software environments

Buildroot
● Classic cross compilation
● Set of Makefiles and patches
● Generates:
● cross-compilation toolchain
● gcc, binutils, gdb, ...
● (root filesystem for target, kernel,
bootloader, ..)

Buildroot configuration
● Kconfig interface
● make menuconfig
● Select compiler, binutils and gdb
version.
● http://buildroot.net

Exercise
● Retrieve buildroot 2012.08 from
● http://www.buildroot.org/download.html
● $ make sheevaplug_defconfig
● $ make
●
● Note: you will need to set your http_proxy environment variable
to http://neo.barco.com:3128/ and/or use
http://sleipner.barco.com/downloads/ as primary download site
(Build Options → Mirrors and Download locations)

The Linux Boot Process

High Level View

System startup
● CPU executes code at a predefined
address (e.g. CS0, address 0x100)
● for a PC: BIOS in flash on motherboard
● embedded e.g. U-Boot, Redboot or similar
● PC:
● if valid boot device is found, the 1st
stage
bootloader is loaded

Stage 1 Bootloader (x86)
● <512 bytes, fits in 1 sector
● binary itself < 446 bytes
● 64 byte partition table
● 2 byte signature
● loaded from MBR boot device
● Task is to load second stage bootloader

Boot device signature

Stage 2 bootloader
● LILO/GRUB
● load and select kernel
● optionally selects initrd
● pass control to the kernel

Kernel
● zImage (zlib, lzo or lzma compressed)
● without initrd, kernel should contain just
the functionality to detect & mount root
filesystem

Kernel startup

kernel startup (2)
● Assembly, arch specific
● head.S
● hardware initialisation and setup basic
environment
● decompress kernel in memory
● Uncompressing Linux... Ok, booting the kernel
● startup_32:
● initialise page tables and enable memory
paging
● CPU detection

kernel startup (3)
● C, non arch specific
● start_kernel in init/main.c
● init interrupts
● (init ramdisk)
● initial root fs in memory/detect hardware
● embedded: can be final root filesystem
● memory initialisation
● thread_kernel starts /sbin/init
● first user-level application
● Can be modified to another application

init
● First user-level application
● compiled/linked with libc
● uses /etc/inittab
● Spawn services
● sshd, apache, ...
● /bin/sh can also be used to start a
single shell instead of init

Runlevels (sysv)
● startup behaviour of init is divided in
“runlevels”
● 0: Halt
● 1: Single User Mode
● 2: Basic Multi-User mode without NFS
● 3: Full Multi-User mode
● 4: Not used
● 5: Full Multi User Mode with X11 Login
● 6: Reboot
● Not so fixed, some distros use fewer
levels (e.g. Slackware, Debian, ...)

init scripts
● Most start scripts can be found in
● /etc/init.d/
● /etc/rcX.d contains symbolic links to the
scripts
● X: 1,2,3,4,5,6,S
● K20autofs
● S: start
● K: stop
● number for ordering: e.g. start network
daemons after network devices.

inittab entry
● 1:2345:respawn/sbin/getty 38400 tty1
● id
● runlevels
● action
● process to be executed
● id:3:initdefault:
● default runlevel
● /etc/init.d/networking
● {start|stop|restart|force-reload}

Boot Loaders

Overview
● First thing to run after power on
● Tasks:
● Initialize (some of) hardware
● Load a kernel
● Execute it
● Boot loaders often have extra
functionality:
● Access memory and registers
● Program flash
● ..

Boot Loaders
● Lots of Linux compatible boot loaders
● LILO & GRUB well known
● PC specific
● Often platform specific
● Portable:
● RedBoot
● Das U-Boot

Das U-Boot
● The universal boot loader
● Probably most feature full, flexible and
most actively developed boot loader
● Very much focused on Linux
● Started as PPCBoot, but now portable
● Licensed under the GPL
● Has a alternative implementation
barebox (u-boot-v2).

U-Boot Features
● Flash support
● NOR, NAND, Dataflash, ..
● Compression
● GZIP, BZIP2
● Interactive command line interface
● Boot scripting
● TCP/IP stack with BOOTP and DHCP,
TFTP and NFS
● LOTS of drivers:
● Often ported from Linux
● IDE, SCSI, MMC, PCMCIA, USB, LCD, I2C,
SPI, ..

U-Boot Features (2)
● x86 emulation
● Graphics card POST on non-x86
● File Systems
● JFFS2, Cramfs, squashfs EXT2, FAT,
Reiserfs, ..
● Boot splash images
● FPGA configuration
● ...

Exercise
● Bootup SheevaPlug in U-Boot and
explore commands (type help) and
environment variables (type printenv)

U-Boot operation
● Once a working U-Boot (flash) is installed,
upgrading can be done with
serial/tftp/u-boot
tftp 100000 /home/services/tftpboot/u-boot.bin
protect off fe000000 fe03ffff
era fe000000 fe03ffff
cp.b 100000 fe000000 ${filesize}
protect on fe000000 fe03ffff
● scripting helps :-)
run burnfact

Exercise
● Download u-boot 2010.06 and build for
SheevaPlug. Update through JTAG or
TFTP
● Check section 4.6 in manual
● Needed .deb's at
http//neo.barco.com/~mleeman/downloads/SheevaPlugCourse

The Linux Kernel

History
● 1991: post in comp.os.minix
● Linux 0.1
● 1994: Linux 1.0.0
● 1996: Linux 2.0.0
● 1999: Linux 2.2.0
● 2001: Linux 2.4.0
● 2003: Linux 2.6.0
● 2011: Linux 3.0
● 2012: Linux 3.5

Architecture
● monolithic kernel
● drivers run in ring 0
● X11 is in userspace
● contrary to Windows
● Supports
● preemption
● virtual memory
● memory management
● threading
● TCP/IP
● ...
● Mostly in C (97%), 3% ASM

Modules
● kernel code that can access hardware
directly
● modules can be loaded/unloaded and
re-configured at run-time
● e.g.
sudo modprobe xfs
lsmod
sudo insmod /path/to/xfs.ko
sudo modprobe module param=1
● Also in configuration file
/etc/modprobe.d/module.conf

Source Tree
● BIG! (~525 MB, 10M lines)
● A lot is drivers
● Core kernel ~5MB

Source Tree (2)
Kernel 2.6.36
● 216M drivers
● 114M arch
● 32M fs
● 21M sound
● 19M include
● 19M net
● 17M Documentation
● 4.6M kernel
● 2.2M scripts
● 2.2M mm
● 1.7M crypto
● 1.4M lib
● 1.4M security
● 544K block
● 244K ipc
● 144K init
● 108K samples
● 56K usr

Architecture Specific code
● arch/<cpu>
● arch/<cpu>/include/asm
● A few MB per arch
● Depending on no. supported boards

Release Schedule
● New release every 2-3 months
● 2.6.39 19/05/2011
● 3.0 22/07/2011
● 3.1 24/10/2011
● 3.2 05/01/2012
● 3.3 22/03/2012
● 3.4 21/05/2012
● 3.5 21/07/2012
● 3.6 01/10/2012
● 3.7 11/12/2012
● 3.8 19/02/2013
● 3.9 29/04/2013
● 3.10 30/06/2013

Release Schedule (2)
● Tree is open for 2 weeks after release
● LOTS of activity – rc1 diff ~1M lines
● After that only bugfixes
● New -rcX release every 1-2 weeks
● 3.x.y stable releases for serious bugs
found after release

Tracking Development
● Linux kernel mailing list (2-300 mails/day)
● lwn.net Kernel - http://lwn.net/Kernel
● http://www.kernelnewbies.org/LinuxChan
ges
● kernel.org gitweb:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary

Device Tree
● Introduced in the PowerPC processor
ports, moving to other archs (ARM,
Microblaze)
● The Device Tree describes the
hardware to the kernel
● Includes e.g. Flash map, PCI
addresses, MAC addresses, ...
● U-Boot has support for modifying the
dts/dtb

User Space Interface
● Basically 3 types of interfaces:
● Character Devices
● Block Devices
● Network Devices
● (procfs, sysfs, netlink)
● Rarely needs to be implemented
directly
● Kernel provides frameworks

Character Devices
● Most common type
● Anything that can be viewed as a stream of
bytes (serial ports, input devices,
framebuffers, sound devices, ..)
● Accessed like normal files
● open/close/read/write/lseek/..
● Additional settings through ioctl
● Added in kernel by
● Registering a cdev and implement
file_operations

Block Devices
● For Storage Devices
● Harddisks, MMC, USB keys, ..
● Accessed like Character Devices
● Kernel Interface More Complicated
● Registering a gendisk and implement
block_device_operations

Network Devices
● For Network Devices
● Ethernet, Wireless, PPP, ..
● Accessed using socket API
● socket/accept/listen/recv/send/..
● Configuration typically through
programs/scripts
● ip/ifconfig/vconfig/ethtool/..
● Registering a net_device and implement
net_device_ops

Hardware Access
● Memory mapped registers
● Linux uses virtual memory (MMU)
● ioremap(physical address)
logical
● read{b,w,l}(logical)
● write{b,w,l}(value, logical)
● iounmap(logical)

Device Model
● Object Oriented, Tree Structured
● Busses (struct bus_type)
● Devices (struct device)
● Drivers (struct driver)
● Visible in sysfs
● Take a look on your PC!
● Saves code, Tree hierarchy important
for E.G. power management

Busses
● Devices connect to CPU through
busses
● USB, PCI, I2C, SPI, Platform, ..
● Each corresponds to a specific bus_type
● Bus-specific interface for drivers
● Tree Based
● E.G. a USB controller on a PCI bus

Devices and Drivers
● Object Oriented
● Drivers (Classes)
● Devices (Instances)
● Common interface
● Probe (Constructor)
● Remove (Destructor)
● Bus connects (binds) both together

Platform Bus
● “Dummy” bus for simple memory
mapped devices on SoCs
● Plug-n-play binding emulated through
string matching (driver/device name
member)

Platform Bus Binding
struct platform_device {
const char * name;
…
};
struct platform_driver {
struct device_driver driver {
const char *name;
};
...
};
● Platform_device in platform code
● Platform_driver in device driver

Resources
static struct resource smc911x_resources[] = {
[0] = {
.start = 0x8e000000,
.end = 0x8e0000ff,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 4,
.end = 4,
.flags = IORESOURCE_IRQ,
},
};
● Generic way of providing platform
details such as base address and IRQ:
●Platform data pointer for special stuff

PCI Bus
● Device/Driver binding using PCI
Vendor/Product ID (PnP)
● lspci
● USB is very similar
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
Gigabit Ethernet Controller (rev 22)
02:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless
Network Adapter (rev 01)
03:03.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 61)
..

Character Interface
● Make communication available to
userspace via device files
# ls -l /dev |grep dsp
crw-rw-rw- 1 0 0 252, 4 Jul 20 2006 dspa
crw-r----- 1 0 0 252, 0 Jul 20 2006 dspa0
crw-r----- 1 0 0 252, 1 Jul 20 2006 dspa1
crw-r----- 1 0 0 252, 2 Jul 20 2006 dspa2
crw-r----- 1 0 0 252, 3 Jul 20 2006 dspa3
# ls -l /dev |grep fpga
crw-r----- 1 0 0 253, 0 Jul 20 2006 fpgaa
crw-r----- 1 0 0 251, 0 Jul 20 2006 nwwfpgaa

read/write
● read/write on file handles
● copy data from the kernel to application
code
● copy_to_user(...)
● copy data from application code to the
kernel
● copy_from_user(...)
● If user reads
● kernel writes from userspace
● If user writes
● kernel reads from userspace

Device Files
● ioctl is often used in code to send
commands and data to the kernel/device
● For register access, read/write/lseek is
better.
● bad example:
static inline uint32_t ppc2dsp_getregister(const DSP
*dsphandle,uint32_t address){
TSBarcoMemEntry entry;
entry.addr = address;
ioctl(*dsphandle,PPC2DSP_GET_REG,&entry);
return entry.value;
}
dsp = open ("/dev/dspa", O_RDWR);

ioctl
● fine tuned and often specialised
hardware control
● allows to pass arbitrary data from user
to kernel and vice versa
● int(*ioctl)(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
● switch(cmd)
● number 0..N cmd X-(

Interrupts
● Kernel needs to act on a “hardware
event”
● polling?
● slow and CPU intensive!
● An interrupt is a signal that the
hardware can send when it wants the
processor's attention.

Flash Map
● Add partitions to the flash
● different functionality
● select between
● kernels
● root filesystems
● redundant configuration spaces
● file systems (jffs2, squashfs, ...)
● Create one logical area from multiple
flash chips

LED Class
● Kernel already has a framework for this
● See:
● drivers/leds
● Documentation/leds-class.txt
● /sys/class/leds
● gpio_led driver makes this very easy
● Various led-triggers can be hooked up

File Systems

Introduction
● More than 50 file systems supported
● More than any other OS
● What to choose?

File System Types
● Disk based
● Flash based
● Network file systems
● “Virtual” file systems

Disk Based
● Biggest group
● Native
● Supports all POSIX features
● EXT2/3/4, Reiserfs3/4, XFS, JFS, Btrfs, ..
● Recommended
● Compatibility
● Might not support all POSIX features
● Less performance
● FAT, NTFS, HPFS, BEFS, AFFS, ISO9660,
UDF, ..

Disk Based (2)
● Disks are not common in embedded
systems
● PC-Like
● Flash with disk interface (USB, CF, MMC,..)
● Limit writes for flash!
● No journalling file systems
● noatime mount option
● EXT2 or FAT

Flash Based
● Disk based can be used
● Kernel MTD layer can emulate block device
● Only realistic for read only
● Optimized for flash
● Cramfs (old)
● Squashfs
● Journalling file system 2 (JFFS2) (old)
● UBIFS

Cramfs / Squashfs
● Read only
● Compression
● Squashfs finally in mainline
● Squashfs newer
● More features, better compression, faster
● Can also be used on disks
● Often combined with RAM disk for /tmp
● OpenWRT uses squashfs-lmza
● Squashfs + better compression
● Complex to implement: lmza non standard

JFFS2
● Read/write
● Compression, but less effective
● Journalling, so no fsck
● Long mount time on big partitions
● Complex
● Consider raw flash partition or
EEPROM if data limited

UBIFS
● Similar to JFFS2 but newer
● Uses UBI (Unsorted Block Images)
● More Scalable, faster mount time
● Better fit for (big) NAND flash

Network File Systems
● NFS, SMBFS/CIFS
● AFS, CODA, 9FS, ..
● Not commonly used in production
● NFS very handy for development
● Kernel can boot on NFS
● NFS supports normal POSIX features

“Virtual” File Systems
● No underlying media to store data
● Sysfs, procfs: Interface to kernel
● TMPFS: Dynamic RAM disks
● Devtmpfs: Dynamic /dev

Conclusion
● Lots to choose from
● Most systems use more than one

Userspace

busybox
http://www.busybox.net/
● Most Unix command line utilities within a
single executable!
● includes a web server!
● Sizes less than 1 MB (statically compiled
with glibc)
less than 500 KB (statically compiled with
uClibc)
● Easy to configure
● The best choice for
● Initrds with complex scripts

busybox
● combine unix utilities in one single small
executable
● share startup code
● configurable commands
● configurable functionality of the
commands
● applets easy to add

● Best way to describe:
root@OpenWrt:~# busybox
BusyBox v1.4.2 (2007-09-29 07:21:40 CEST) multi-call binary
Copyright (C) 1998-2006 Erik Andersen, Rob Landley, and others.
Licensed under GPLv2. See source distribution for full notice.
Usage: busybox [function] [arguments]...
or: [function] [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as!
Currently defined functions:
[, [[, arping, ash, awk, awx, basename, bunzip2, bzcat, cat, chgrp, chmod, chown, chroot,
clear,
cp, crond, crontab, cut, date, dd, df, dirname, dmesg, du, echo, egrep, env, expr, false,
fgrep,
find, free, grep, gunzip, gzip, halt, head, hexdump, hostid, httpd, id, ifconfig, init,
insmod,
ipkg, kill, killall, killall5, klogd, length, less, ln, lock, logger, logread, ls, lsmod,
md5sum,
mesg, mkdir, mkfifo, mknod, mktemp, mount, mv, nc, netmsg, netstat, nslookup, passwd, pidof,
ping, ping6, pivot_root, poweroff, printf, ps, pwd, rdate, reboot, reset, rm, rmdir, rmmod,
route, sed, seq, sh, sleep, sort, strings, switch_root, sync, sysctl, syslogd, tail, tar,
tee,
telnet, telnetd, test, time, top, touch, tr, traceroute, true, udhcpc, umount, uname, uniq,
uptime, vconfig, vi, watchdog, wc, wget, which, xargs, yes, zcat

Configuration
● Again, Kconfig based

CGI
`

dropbear
● replaces telnetd
● obsolete since mid '90s
● secure communication
● no need for
● telnetd, ftpd, samba, ...
● tunnelling :-)
● Typical W32 clients
● PuTTy, WinSSH
● jcterm, mindterm
● GNU/Linux
● default

Buildroot
● Not just for toolchains
● Can build entire Linux systems
● Make files, downloads over net
● No root permissions required
● Used in D&A and Medical
● Used in several Open Source projects:
● OpenWrt, Gumstix, ...

Full blown Distributions
● Interesting option
● If disk(-like) storage available
● Little difference between SoC target and
desktop/server
● Functionality is can easily be expanded
● Debugging tools
● Verification
● GNU/Debian supports 11 archs
● Lots of precompiled packages
● ~20.000
● No need to cross compile

First stage bootstrap
● Nice for development together with NFS
● Debootstrap –verbose –variant=minbase
–keyring=/home/me/pubring.gpg –include=apt
–arch=armhf –foreign vclub /home/me/chroot2013
ftp://cypher.barco.com/nvslinux
/usr/share/debootstrap/scripts/wheezy
● Result is a armhf target on an x86-64
machine
● Installation requires a 'second-stage'
installation
● Does not run natively (<==> x86 (i386))

Second Stage bootstrap
● Qemu is needed
● QEMU can launch Linux processes compiled for one CPU on
another CPU
● Fully system emulation
● Copy /usr/bin/qemu-static into
$TARGET/usr/bin/qemu-static
● Why 'static'?
● Debootstrap /home/me/chroot2013/
/debootstrap/debootstrap –secondstage

Qemu
● Spot the difference
● marc@drd1812:~/Development$ uname a
● Linux drd1812 3.9.4 #1 SMP PREEMPT Thu May 30 12:53:13 CEST 2013 x86_64 GNU/Linux
● marc@drd1812:~/Development$ sudo chroot dolphindevenv20130311/
● root@drd1812:/ dolphindev$ uname a
● Linux drd1812 3.9.4 #1 SMP PREEMPT Thu May 30 12:53:13 CEST 2013 armv7l GNU/Linux

Packages
● a “package” refers to a compressed file
archive containing all of the files that
come with a particular application.
● Typical binary in nature
● Can install new functionality
● Can expand current functionality
● Can modify existing functionality
● Most common forms
● Debian package: file.deb
● Debian, Ubuntu, ...
● Redhat package: file.rpm
● Redhat, SuSE, Fedora, …

Packages
● Selective upgrade
● Once deployed, typical bugfixes, security
fixes

Packages 101
● Concept of a 'repo'
● Can be networked, on disk, on CD, USB, …
● deb
● debsrc
● Can be networked, on disk, on CD, USB, …
● In /etc/apt/sources.list.d/file.list
● deb ftp://cypher.barco.com/nvslinux/ vclub
main contrib nonfree
● File, cdrom, http, ftp, copy, rsh, ssh, …
● Lots of command line, console and GUI
front-ends

Packages 101
● Update the package descriptions
● $ sudo aptget update
● Install a single package
● $ sudo dpkg barcomna240_1231.deb
● Install a single package with
dependencies from the network
● $ sudo aptget install barcomna240
● $ sudo aptget remove barcomna280
● $ sudo aptget purge barcomna280
● Upgrade the system without installing
extra packages
● $ sudo aptget upgrade

Packages 101
● Upgrade the system
● $ sudo aptget distupgrade
● Search the package descriptions
● $ sudo aptget search barco
● Show detailed package description
● $ sudo aptget show barcoc12
● Housekeeping
● Clear package cache
● $ sudo aptget cache clear
● Remove unused packages
● $ sudo aptget autoremove

Privilege separation
● Services run as a separate
(unprivileged) user: e.g. webserver, ftp,
ssh, …
● Security concerns

Setting up a Server

General
● Platform of choice: GNU/Debian
● the developers' platform
● powerful, handy package management
● Check with IT:
● we will need DHCP (conflicts with corporate)
● Alternate: 2 network cards, external (Barco),
internal (my.net.local).

Needed & (Useful)
● NFS
● mount root filesystem without re-burning it
to flash: much faster
● use larger filesystem than can be stored on
flash for development
● DHCP/BOOTP
● cf. supra
● kernel send BOOTP package to get
kernel/filesystem location over the network

Needed & (Useful)
● atftpd
● Trivial ftp protocol
● used by U-Boot to obtain files over the
network
● used by BDI2000 to get files over the
network
● (bind)
● DNS server
● e.g. bdi02.smd.localnet is handier than 10.2.0.17

Needed & (Useful)
● SSH
● Secure Shell
ssh-keygen -t dsa -b 4096
scp ~/.ssh/id_dsa.pub me@remote:
ssh me@remote 'mkdir -p ~/.ssh'
ssh me@remote 'cat id_dsa.pub > ~/.ssh/authorized_keys'
● (Samba)
● Windows Share access
● (LDAP)
● Centralised account and rights and service
management
● sudo & fakeroot
● selective super user root rights assignment

Conclusions
● improvements to upstream sources
● communicate upstream
● e.g. Das U-Boot
● e.g. buildroot
● Kernel changes
● minimise them ASAP
● reduces maintenance to a minimum
● focus on the important code
● Montavista, MetroWerx

References
● Update version of the examples, course text and slides:
● http://neo.barco.com/~mleeman/embedded_linux/
● D&A info:
● http://ccwiki/EmbeddedLinuxTraining

Embedded Linux Basics

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Embedded Linux Basics (20)

Recently uploaded (20)

Embedded Linux Basics