Embedded Linux Basics

12/07/13 - Marc LeemanCompany Confidential - 1

Basic Introduction to Embedded Linux

Barco Seminar11/07/2013Marc 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 BeautifulSpeed increase RAM reduction Power reduction Cost reduction

More speed CPU can run slower or staylonger in power saving mode

Slower, cheaperCPU

Less RAM Faster allocations Less swapping Sometimes less

cache flushing

Fewer / smaller RAM chips:less dynamic and standbypower.

CPU with less cache: less power

Fewer / cheaperRAM chips

CPU with lesscache: cheaper

Less space Faster applicationloading fromstorage and inRAM.

Sometimes,simpler, fastercode.

Less RAM usage Fewer / smaller storage chips:less power

Fewer / cheaperstorage

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 systemBest 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 machinesSize 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 uClibcPlain “hello world” 4.6 K 4.4 K 475 K 25 K

Busybox 245 K 231 K 843 K 311 K

http://www.gnu.org/software/libc/

http://www.uclibc.org/


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

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)

http://www.buildroot.org/download.html

http://neo.barco.com:3128/

http://sleipner.barco.com/downloads/


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.binprotect off fe000000 fe03ffffera fe000000 fe03ffffcp.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

http://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 xfslsmodsudo insmod /path/to/xfs.kosudo 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● Added in kernel by

● 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/..● Added in kernel by

● 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 dspcrw-rw-rw- 1 0 0 252, 4 Jul 20 2006 dspacrw-r----- 1 0 0 252, 0 Jul 20 2006 dspa0crw-r----- 1 0 0 252, 1 Jul 20 2006 dspa1crw-r----- 1 0 0 252, 2 Jul 20 2006 dspa2crw-r----- 1 0 0 252, 3 Jul 20 2006 dspa3# ls -l /dev |grep fpgacrw-r----- 1 0 0 253, 0 Jul 20 2006 fpgaacrw-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

http://www.busybox.net/


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:~# busyboxBusyBox v1.4.2 (2007-09-29 07:21:40 CEST) multi-call binaryCopyright (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 Unixutilities into a single executable. Most people will create alink to busybox for each function they wish to use and BusyBoxwill 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))

ftp://cypher.barco.com/nvslinux


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

ftp://cypher.barco.com/nvslinux/


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 Shellssh-keygen -t dsa -b 4096scp ~/.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

http://neo.barco.com/~mleeman/embedded_linux/

http://ccwiki/EmbeddedLinuxTraining

Embedded Linux Basics

Education

Transcript of Embedded Linux Basics