1. Spring 2014 SILICON VALLEY UNIVERSITY CONFIDENTIAL 1 Introduction to Embedded Systems Dr. Jerry Shiao, Silicon Valley University

2. SILICON VALLEY UNIVERSITY CONFIDENTIAL Spring 2014 Section 3 Embedded Linux Toolchain o Target System TFTP Boot Switch Target System Ethernet Port 192.168.1.100192.168.1.101 2 RamDisk zImage Host System /tftpboot/ramdisk.gz RAMFlash Bootloader RamDisk zImage Bootloader Configuration load –r –v –b 0x800000 –h 192.168.1.100 ramdisk.gz fis load zImage

3. SILICON VALLEY UNIVERSITY CONFIDENTIAL 3 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 1: Build RamDisk (initrd) 1)Create ~/buildArmlinux. This directory will be used to download the source code for Linux, binutils, glibc Linux library. 2)Create ~/buildArmlinux/dissectRamdisk. This directory will be used as the working area to decompress the Ramdisk and build the new Ramdisk. 3)Create ~/buildArmlinux/dissectRamdisk/initrd and ~/buildArmlinux/dissectRamdisk/tmpinitrd. The initrd is the final Ramdisk, and tmpinitrd is temporary directory to create the initrd software. 4)In ~/buildArmlinux/dissectRamdisk/tmpinitrd directory, decompress the supplied Ramdisk. cd ~/buildArmlinux/dissectRamdisk/tmpinitrd gzip –xvf ramdisk.gz  ~/buildArmlinux/dissectRamdisk/tmpinitrd/ramdisk 5)In ~/buildArmlinux/dissectRamdisk, mount the temporary initrd directory as tmpinitrd. cd ~/buildArmlinux/dissectRamdisk mount –o loop tmpinrd/ramdisk tmpinitrd 6)In tmpinitrd, copy all the files into initrd. cd ~/buildArmlinux/dissectRamdisk/tmpinitrd cp –rf *../initrd 7)In ~/buildArmlinux/dissectRamdisk/initrd/home, create myApp directory. In myApp directory, create the readme.txt file with the following text: Name: Silicon Valley University Course: Embedded Linux Design and Programming Date:

4. SILICON VALLEY UNIVERSITY CONFIDENTIAL 4 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 1: Build RamDisk (initrd) 8)In ~/ buildArmlinux/dissectRamdisk/initrd/home/www, edit index.html file with the following text: EDB9392 … Please see the readme.txt included with the distribution for more details. Have fun! Name: Silicon Valley University: Embedded Linux Design & Programming Date … 9)In ~/buildArmlinux/dissectRamdisk, create ramdisk.gz from ~/buildArmlinux/dissectRamdisk/initrd. cd ~/buildArmlinux/dissectRamdisk/initrd su chown –R 0.0 * dd if=/dev/zero of=initrd.img bs=1k count=10240 /sbin/mke2fs –F –v –m0 initrd.img mkdir initrd.dir mount –o loop initrd.img initrd.dir (cd initrd; tar –cf -.) | (cd initrd.dir ; tar –xvf -) umount initrd.dir gzip –c -9 initrd.img > ramdisk.gz exit 10) In ~/buildArmlinux/dissectRamdisk, copy ramdisk.gz into /tftpboot/ramdisk.gz. cp ramdisk.gz /tftpboot/.

5. SILICON VALLEY UNIVERSITY CONFIDENTIAL 5 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 1: Build RamDisk (initrd) 11) Download ramdisk.gz onto the target board. Power cycle the microcontroller board and enter to interrupt the boot process when “+” spins. 12)Load ramdisk.gz from tftp server as raw data at location specified by “-b” from server at “-h”. RedBoot> load –r –v –b 0x800000 –h 192.168.1.100 ramdisk.gz 13Flash Image System transfer an image from flash image to RAM. The image is loaded in the address specified in the FIS directory. RedBoot> fis load zImage 14)Execute the Linux kernel specifying the address in memory of the “initrd”-style Ramdisk. RedBoot> exec –r 0x800000 –s 0x600000

6. SILICON VALLEY UNIVERSITY CONFIDENTIAL 6 Spring 2014 Section 3 Embedded Linux Tool Chain  Cross Development Environment Purpose: Tools required on host system to develop software for target platform.  Compiler  Assembler  Linker  Utilities Different architectures require their own toolchain (i.e. MIPS, Powerpc, X86, ARM).  Cirrus Logic EP9302 Microcontroller require ARM toolchain with math engine.  Applications compiled with cross-compiler can only run on the target architecture, not on host system. Host compiler must be used to compile first stage of gcc (minimal compiler features).  First stage gcc compiler used to compile full version of gcc, glibc, utilities and rest of the tool chain.  Directory structure when building tool chain has specific structure to maintain the source codes, header files, binaries, libraries.  Gcc compiler, binutils (assembler, linker), glibc (C library for applications), must be compatible.  NOTE: Not all versions will compile or work.

7. SILICON VALLEY UNIVERSITY CONFIDENTIAL 7 Spring 2014 Section 3 Embedded Linux Tool Chain  http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/ gcc-4.1.1 cgcc-3.3.6 glibc-2.3.2 binutils-2.16.1 linux-2.6.15.4 hdrs-2.6.12.0 gcc-4.1.1 cgcc-3.3.6 glibc-2.3.5 binutils-2.16.1 linux-2.6.15.4 hdrs-2.6.12.0 tls gcc-4.1.1 cgcc-3.3.6 glibc-2.3.6 binutils-2.16.1 linux-2.6.15.4 hdrs-2.6.12.0 gcc-4.1.1 cgcc-3.3.6 glibc-2.3.6 binutils-2.16.1 linux-2.6.15.4 hdrs-2.6.12.0 tls armOk gdb ok ICE gdb FAIL ICE gdb FAIL ICE gdb FAIL arm-xscaleOk gdb ok ICE gdb FAIL ICE gdb FAIL ICE gdb FAIL i686Ok gdb ok Ok gdb ok Ok gdb ok Ok gdb ok mipsFAIL gdb FAIL FAIL gdb FAIL FAIL gdb FAIL FAIL gdb FAIL powerpc-860Ok gdb ok Ok gdb ok Ok gdb ok Ok gdb ok X86-64Ok gdb ok Ok gdb ok Ok gdb ok Ok gdb ok

8. SILICON VALLEY UNIVERSITY CONFIDENTIAL 8 Spring 2014 Section 3 Embedded Linux Tool Chain Linux-2.6.29 -- -- arch ----------------------- -- include -- -- init -------- -- mm -- drivers -- ipc -- fs -- kernel ---- -- net -------- -- lib -- scripts -- arn -- mips -- powerpc -- x86 -- asm-arm -- linux --- -- kernel.h -- main.c -- Makefile -- sched.c -- sched_rt.c -- ipv4 -- ipv6 arch: All the architecture specific code. It has further subdirectories, one per supported architecture (i.e. arm, mips, powerpc, x86). include: Include files needed to build the Kernel. It has further subdirectories, one per supported architecture (i.e. asm-arm). Other header files are non-architecture specific. init: Initialization code for the kernel. init/main.c: The central connecting point of Linux. Function start_kernel is in init/main.c init/Makefile: Makefile to build Linux. mm: Memory management code. Virtual memory, memory mapping of files, management of page caches, memory allocation, swapper. drivers:Linux device drivers. Further subdirectories for classes of device drivers (i.e. block). ipc: Inter-process communications code. fs: Generic file system code (i.e. Virtual File System). Subdirectories for different filesystem (i.e. ext2, ext3, jfs, fat). kernel: Generic Kernel code. Architecture specific Kernel code is in the arc/*/kernel. net: High-level networking code. Low-level network drivers pass received packets up to and get packets to send from this level. lib: Kernel library code. Common string operations, and command line parsing code. Scripts: Scripts used to build the Kernel. /home/sau/buildArmLinux/KERNEL/

9. SILICON VALLEY UNIVERSITY CONFIDENTIAL 9 Spring 2014 Section 3 Embedded Linux Tool Chain BUILD -- -- binutils-2.16 -- binutils-2.16.build -- gcc-3.4.4 -- gcc-3.4.4.build-1 -- gcc-3.4.4.build-2 -- glibc-2.3.5 -- glibc-2.3.5.build -- toolchain -- -- arm-linux-as -- arm-linux-gcc -- arm-linux-ld -- include --- binutils-2.1.6: Binaries of the software development tools (i.e. Linker “ld”, Assember “as”) for the target system. Different targets compile need different flags. Binutils has code for different processors, need compile time flags and environment variables to select the correct code for target system. Binutils first binaries to compile. Binutils applications used to build target compiler, glibc (i.e. application C Library). NOTE: Open source toolchain made embedded Linux systems desirable (cost). toolchain/include: Include files needed to build the Kernel. It has further subdirectories, one per supported architecture (i.e. asm-arm). Kernel headers specific to the kernel. Kernel headers for the Linux kernel has C structures, constants, prototype system APIs (i.e. glibc library system calls) for application and system programming to support system calls. Toolchain Building Overview: -- Create cross development tool repository (i.e. ~/buildArmLinux) -- gcc compiler setup (i.e. download compatible compiler). -- binutils setup (i.e. download compatible version). -- Kernel headers setup (i.e. download compatible Linux Kernel version). -- Build bootstrap gcc compiler, full target gcc cross compiler. -- Build target binutils (required by glibc and gcc). -- Build target glibc. /home/sau/buildArmLinux/ -- linux

10. SILICON VALLEY UNIVERSITY CONFIDENTIAL 10 Spring 2014 Section 3 Embedded Linux Tool Chain  Cross Development Environment Purpose: Tools required on host system to develop software for target platform.  Compiler  Assembler  Linker  Utilities Different architectures require their own toolchain (i.e. MIPS, Powerpc, X86, ARM).  Cirrus Logic EP9302 Microcontroller require ARM toolchain with math engine.  Applications compiled with cross-compiler can only run on the target architecture, not on host system. Host compiler must be used to compile first stage of gcc (minimal compiler features).  First stage gcc compiler used to compile full version of gcc, glibc, utilities and rest of the tool chain.  Directory structure when building tool chain has specific structure to maintain the source codes, header files, binaries, libraries.  Gcc compiler, binutils (assembler, linker), glibc (C library for applications), must be compatible.  NOTE: Not all versions will compile or work.

11. SILICON VALLEY UNIVERSITY CONFIDENTIAL 11 Spring 2014 Section 3 Embedded Linux Tool Chain  Cross Development Environment Root File System (Busybox)  Memory-constrainted embedded systems.  glibc  uclibc  busybox  3.5 Mbytes  200KBytes  Single executable of many standard Linux utilities (i.e. cat, echo, grep, find, mount) results in smaller executable.  NOTE: Without Busybox, Linux utilities are separate processes.  Standard Linux utilities share many common elements (i.e. grep and find has common code to recursively search directories).  BusyBox executable has name of the program (i.e. cat …) in argv[0], the first argument (i.e. cat, echo, grep, find, telnet). Limited options.  Shell using symbolic link to make Busybox executable look like many executables. lrwxrwxrwx 1 sau users 7 2011-02-28 11:00 ash -> busybox -rwxr-xr-x 1 sau users 318164 2011-02-28 11:00 busybox lrwxrwxrwx 1 sau users 7 2011-02-28 11:00 cat -> busybox lrwxrwxrwx 1 sau users 7 2011-02-28 11:00 chmod -> busybox lrwxrwxrwx 1 sau users 7 2011-02-28 11:00 cp -> busybox lrwxrwxrwx 1 sau users 7 2011-02-28 11:00 date -> busybox lrwxrwxrwx 1 sau users 7 2011-02-28 11:00 dd -> busybox...

12. SILICON VALLEY UNIVERSITY CONFIDENTIAL 12 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 2: Build ARM Toolchain SRC: Tar files for the toolchain. BUILD: Decompressed tar files. Toolchain: Binary files for building target system (i.e. ARM). Initrd: The root file system that will be loaded on target system. File: envSetup.bash export TARGET=arm-linux export PRJROOT=‘pwd’ export PREFIX=${PRJROOT}/BUILD/toolchain export SYSROOT=${PREFIX}/${TARGET} export PATH=${PREFIX}/bin:$PATH export CPPFLAGS=“-D__MAVERICK__” unset LD_LIBRARY_PATH -- SRC -- buildArmlinux – -- BUILD – -- initrd ---- -- binutils-2.16.tar.bz2 -- gcc-3.4.4.tar.bz2 -- glibc-2.3.5.tar.bz1 -- binutils-2.16 -- gcc-3.4.4 -- gcclibc-2.3.5 -- toolchain -- -- bin -- -- arm-linux-as -- arm-linux-gcc-3.4.4 -- arm-linux-gcc-ld -- bin -- dev -- home -- lib -- proc

13. SILICON VALLEY UNIVERSITY CONFIDENTIAL 13 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 2: Build ARM Toolchain Source the setup script for the toolchain environment:  source envSetup.bash  NOTE: If execute the script, (i.e../envSetup.bash), a separate process is created and environment variables are local to that process.  To execute from user login shell, put in.bash_profile. To run.bashrc in.bash_profile: if [ -f ~/.bashrc ]; then source ~/.bashrc fi  To execute when terminal window is opened (i.e. interactive nonlogin shells), put in.bashrc.

14. SILICON VALLEY UNIVERSITY CONFIDENTIAL 14 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 2: Build ARM Toolchain Patches from Linux community available in GNU website. Bugs reported to www.kernel.org. Apply patches to current Linux code. Patch file created from “diff” command used in “patch” utility.  diff –Naur >> patchfile.patch  -N: Mismatched files treated as empty.  -a: Treat all files as text and compare line-by-line.  -u: Use unified output format.  -r: Recursively compare any subdirectories.  patch –p1 < patchfile.patch  -p1: Strip off first level in path designator in patch file. patchfile.patch: diff –Nru gcc-3.4.4.ori/gcc/config/arm/arm.c gcc- 3.4.4.patched/gcc/config/arm/arm.c --- gcc-3.4.4.ori/gcc/config/arm/arm.c 2005-02-01 16:07:02.000000000 +0100...

15. SILICON VALLEY UNIVERSITY CONFIDENTIAL 15 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 2: Build ARM Toolchain The configure shell script is a GNU configuration build methodology used with every feature build (i.e. binutils, gcc, glibc). ./configure --help  Used to specify correct values for various system-dependent variables used in compilation.  The configure shell script creates Makefile to compile the package in each directory. The GNU configuration methodology takes care of portability issues.  Hardware differences (i.e. endianness, data type sizes).  OS differences (i.e. device file naming conventions).  Library differences (i.e. version numbers, API arguments).  Compiler differences (i.e. compiler name, arguments). Other files generated during the builds are:  config.status contains the rules to recreate the current configuration.  config.h contains #define statement that control the compilation of the program.  Config.cache is a shell script that caches the results of configure test runs.  Config.log contains messages if configure makes mistakes.

16. SILICON VALLEY UNIVERSITY CONFIDENTIAL 16 Spring 2014 Section 3 Embedded Linux Tool Chain  Assignment 2: Build ARM Toolchain  The configure shell script for compiling glibc package: BUILD_CC=gcc CFLAGS="-O1" CC="$TARGET-gcc \ -mcpu=ep9312 -mfix-crunch-d1" \ AR=$TARGET-ar RANLIB=${TARGET}-ranlib \../glibc-2.3.5/configure \ --host=$TARGET \ --build=i686-pc-linux-gnu \ --prefix=${PREFIX} \ --enable-add-ons=linuxthreads \ --disable-debug \ --disable-profile \ --without-tls \ --without-gd \ --without-cvs \ --with-headers=${PREFIX}/include \ --with-__thread \ --with-binutils=${PREFIX}/bin make -j4 make install The Environment Variables: CFLAGS: Compiler flag for optimization level 1. Reduce size, while increasing performance. CC: gcc compiler for the target system. -mcpu=ep9312 –mfix-crunch-d1: Required for the microcontroller ARM9 processor. AR, RANLIB: Paths for creating libraries. The configure Script: --enable-add-ons: Use Linux Threads, which is older than nptl (reentrant) or pthreads. --with-headers: Location of system headers to use. --with-binutils: Specify location of binutils (as and ld).

17. SILICON VALLEY UNIVERSITY CONFIDENTIAL 17 Spring 2014 Section 4 Kernel and Linux File System  Building Kernel Sources ~/buildArmlinux/KERNEL/linux-2.6.29.  Has many levels of subdirectories containing source files, Makefiles, and files from configuration processing.  > 6 million lines of code.  Open source code is added or changed every month.  Configuation tools needed to manage the Kernel compilation. Hidden configuration file “.config” is the Linux Kernel configuration.  Selection of the processor, board, modules (i.e. drivers).  make config – starts a character based questions and answer session. Over 1400 questions and getting usable system unlikely.  make menuconfig – starts a terminal-oriented configuration tool (uses ncurses library) with menu user interface.  make xconfig – starts a X based configuration tool utility with graphical menus (uses ncurses library).  ncurses is a programming library for developing “GUI-like” application software using text user interfaces. Terminal independent, optimize screen changes to reduce latency for remote shells.  drivers and arch directory largest of the Linux Kernel source tree.  Open source (GNU license) required for drivers, device hardware.  arch directory written by equipment vendor.  System.map is the Linux Kernel symbol table.

18. SILICON VALLEY UNIVERSITY CONFIDENTIAL 18 Spring 2014 Section 4 Kernel and Linux File System  Building Kernel Sources make menuconfig.

19. SILICON VALLEY UNIVERSITY CONFIDENTIAL 19 Spring 2014 Section 4 Kernel and Linux File System  Building Kernel Sources Make xconfig

20. SILICON VALLEY UNIVERSITY CONFIDENTIAL 20 Spring 2014 Section 4 Kernel and Linux File System  Building Root File System Diskless embedded system need initial RAM Disk image (i.e. initrd) containing an ext2 file system. During bootup, init process reads inittab and mounts root file system. In.config is configured CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD to build initrd. Initrd contains software:  Programs and utilities to boot a system.  Scripts to initialize services.  Configuration files.  Load device drivers. / binbusybox boot vmlinux etc rcS init.d mount -> busybox buildArmlinux /boot – Linux bootup files (i.e. Linux Kernel, system map). /etc – Linux system configuration files. /bin – Linux system binaries (i.e. busybox and symbolic links). System Admin and Users. /home – Each users have own directory and only place normal users are allowed to write. /sbin – Essential to the system. System Admin, maintenance and hardware config programs (i.e. ifconfig). /sbin/init – First process to start during boot process. /usr/sbin – System Admin binaries. Not maintenance/repair. /lib – Shared libraries needed to link user application. /dev – Device files. sbin init libmodules sau busybox boot vmlinux etc rcS init.d mount -> busybox home dev ttyUSB0 usrsbin

21. SILICON VALLEY UNIVERSITY CONFIDENTIAL 21 Spring 2014 Section 4 Kernel and Linux File System Device Files  I/O devices treated as special files; same system calls as regular files.  Write() used to write data to regular file or to printer (/dev/lp0).  NOTE: Network cards are exception, hardware device not associated with device files.  Block type devices: transfer a data block (i.e. hard disks, floppy disks, CD-ROM, DVD).  Character type devices: typically not random address (i.e. sound card, printer, terminal).  Hardware device identifier:  Type of device. Block and character types has independent number.  Major number: Identifies the unique device in the system.  Minor number: Identifies specific device that share the same major number (i.e. group of disks managed by same disk controller).

22. SILICON VALLEY UNIVERSITY CONFIDENTIAL 22 Spring 2014 Section 4 Kernel and Linux File System Device Files NameTypeMajorMinorDescription /dev/fd0Block20Floppy disk. /dev/hdaBlock30First IDE disk. /dev/hda2Block32Second primary partition of first IDE disk. /dev/hdbBlock364Second IDE disk. /dev/hdb3Block367Third primary partition of second IDE disk. /dev/ttyp0Char30Terminal /dev/consoleChar51Console /dev/lp1Char61Parallel printer /dev/ttyS0Char464First serial port /dev/rtcChar10135Real-time clock /dev/nullChar13Null device

23. SILICON VALLEY UNIVERSITY CONFIDENTIAL 23 Spring 2014 Section 4 Kernel and Linux File System Device Files /dev  /dev directory had all type of hardware devices from hardware vendors. Had devices defined that are not used by the system. Major and minor numbers exhausted.  udev Device Manager  Linux 2.6 increased major/minor field to 12 bits.  udev during system initialization, scans /sys/class for all logical devices supported by kernel and creates device file in /dev.  udev dynamically creates device files “on demand”.  Hot-pluggable device (i.e. USB).  Assigns major/minor numbers for the device driver.  Releases major/minor numbers when device removed.  VFS hides difference between device files and regular files. File operation on device file is mapped to a device related function.

24. SILICON VALLEY UNIVERSITY CONFIDENTIAL 24 Spring 2014 Section 4 Kernel and Linux File System  Building Composite Kernel Image vmlinux ELF Object Kernel proper, in ELF format, including symbols, text, BSS, data sections, comments, debug info, arch components. objcopy image Binary Object Binary kernel module, stripped of symbols, notes, and comments. gzip piggy.gz File image compressed with gzip. asm head.omisc.o piggy.o Binary kernel image objcopy -O generates binary file -R strip notes, comments -S strip symbols gzip compresses image. Assembler inputs piggy.gz as data into piggy.o and linked with misc.o and head.o to create bootstrap loader. Bootstrap Loader: Misc.o decompress and relocate the kernel. Head.o enable processor instruction and data cache, disable interrrupts, turns on MMU, setup initial page table. Passes control to kernel (init). zImage: Final composite kernel image.

25. SILICON VALLEY UNIVERSITY CONFIDENTIAL 25 Spring 2014 Section 4 Kernel and Linux File System  History Linux File System derived from Minix File System (later Xia File System). Linux implemented Extended File System (ext and ext2). Virtual File System (VFS) provide level of abstraction between user and different file systems. Using a common set of API functions, a large variety of file systems can be supported on a large variety of storage devices.  Read function unaware of system types (i.e. ext2 or NFS) and unaware of storage medium file system is mounted. Max file system size Max file sizeMax file name size Minix File System64 MBytes 16 Bytes Extended File System 2 GBytes2GByte255 Bytes Second Extended File System 32 TBytes2 TBytes255 Bytes

26. SILICON VALLEY UNIVERSITY CONFIDENTIAL 26 Spring 2014 Section 4 Kernel and Linux File System  Virtual File System (VFS) User space has the applications and glibc (provides API file system calls: open, read, write, close). System call interface acts as a switch, funneling system calls from user space to the appropriate endpoints in kernel space. VFS exports APIs and abstracts them to individual file systems. Inode cache and Directory cache provides a pool of recently-used file system objects. Directory cache speeds up translation from file pathname to inode. Individual file systems exports APIs that is used by the VFS. Buffer cache buffers the requests between the file systems and the block devices that they manipulate (for faster access).

27. SILICON VALLEY UNIVERSITY CONFIDENTIAL 27 Spring 2014 Section 4 Kernel and Linux File System  Virtual File System (VFS) File Object: Stores info about interaction between open file and process. Dentry Object: Stores info about linking directory entry (file name) and file. Inode Object: Stores info about specific file (inode number identifies file). The file control block. Superblock Object: Stores info about mounted filesystem. The filesystem control block. Process 1 Process 2 File Object Dentry Object Dentry Object Dentry Cache Inode Object Superblock Object Inode Cache Process 1 Process 2 File Object Dentry Object Dentry Object Dentry Cache Inode Object Superblock Object Inode Cache Disk File

28. SILICON VALLEY UNIVERSITY CONFIDENTIAL 28 Spring 2014 Section 4 Kernel and Linux File System  Virtual File System (VFS) struct file_system_type links together currently- supported file systems (/proc/filesystems). struct vfsmount links together file systems currently mounted. Link to struct superblock. struct superblock represents a file system.  Manage inodes: alloc_inode, destroy_inode, read_inode, write_inode, sync_fs. struct inode represents an object (file or directory) in the file system with unique identifier. Metadata to manage objects in the file system  struct inode_operations: Operations that operate on inode.  struct file_operations: Methods related to files and directories (the standard system calls).

29. SILICON VALLEY UNIVERSITY CONFIDENTIAL 29 Spring 2014 Section 4 Kernel and Linux File System  Virtual File System (VFS) To achieve the abstraction (i.e. “black box operation) to the user, common API to the user through glibc library and common callback function signature to the I/O functions. Inode represents an object in the file system with a unique identifier (translating filename). struct file_operations abstractions (i.e. read/write/open ) allow all I/O operations to have common interface. The indirect calls (i.e. callback functions) are APIs specific to the file system.

30. SILICON VALLEY UNIVERSITY CONFIDENTIAL 30 Spring 2014 Section 4 Kernel and Linux File System  /proc File System Virtual file system only in memory.  /proc folder populated during kernel init.  Initial intent was inter-process communication. Serves as window into the kernel and its device drivers.  /proc/ A directory corresponds to process ID running on the system. Contains pseudo-files and directories.  /proc/devices – List of devices configured into current kernel.  /proc/mounts – List of devices mounted.  /proc/filesystems – List of supported file systems.  /proc/cpuinfo – List number of cores.  /proc/kallsym – List kernel exported functions/symbols. Allows:  Kernel and kernel modules to send info and communicate with processes.  User programs to access kernel info.

31. SILICON VALLEY UNIVERSITY CONFIDENTIAL 31 Spring 2014 Section 4 Kernel and Linux File System  /proc/kallsyms Holds the kernel exported symbol definitions (all exported variable and functions) used by the modules tools to dynamically link and bind loadable modules.  Used by kernel modules or drivers. Within module, use EXPORT_SYMBOL macro to make a variable or function available for kernel dynamic linking. Do not export current kernel symbols. In the kallsyms file, before the exported names are the addresses the symbols and functions are located on.  “t” means symbols are defined in the local text(code) section of compiled code.  “T” means symbols are global. /proc/kallsyms: c0400298 T _stext c0400298 t rest_init c0400298 T stext c04002b8 t run_init_process c04002f4 t init c0400588 t try_name c04006f8 T name_to_dev_t c0400930 T calibrate_delay …

32. SILICON VALLEY UNIVERSITY CONFIDENTIAL 32 Spring 2014 Section 4 Kernel and Linux File System  Assignment 3: Build Linux Kernel make mrproper: Returns the source tree to its former clean state without any generated artifacts (i.e. removes object files and.config file)  make clean: Removes generated artifacts, but may leave executable objects or generated reports and leaves.config file. Configuration editors (i.e. make menuconfig) has all possible configuration options for Kernel and generates the.config file for the kernel build.  Goal of embedded Linux is to remove all unnecessary configurations and only keep what the target platform supports and what the embedded kernel needs. Removing options are trial and error because of compile dependencies.  Kernel has monolithic structure. Define dynamically loadable modules to be linked into kernel at runtime.  Kconfig files: Menu structure in the configuration utility created by the Kconfig files in the kernel module (i.e. arch, crypto, drivers, fs, init, kernel, lib, mm, net, security, sound, usr) build directory. Edit Kconfig file to change the kernel module’s configuration options.  Each Kconfig “source” in another Kconfig until the configuration menu structure is built.  Responsibility of the engineer working on the hardware (i.e. Memory Technology Devices, SD cards) to put the Kconfig file together. Kernel module without kconfig file will not have any information when “make menuconfig” is executed.  Make utility interprets the kconfig text file starting at the top-level configuration definition at …/arch/arm/Kconfig.  Default configs for ARM at …/arch/arm/config (i.e. ep93xx_defconfig).

33. SILICON VALLEY UNIVERSITY CONFIDENTIAL 33 Spring 2014 Section 4 Kernel and Linux File System  Assignment 3: Build Linux Kernel …/KERNEL/linux-2.6.29/make menuconfig …/KERNEL/linux-2.6.29/init/Kconfig: menu “General setup” config EXPERIMENTAL bool “Prompt for development … … menuconfig MODULES bool “Enable loadable module support” help Kernel modules are small … … source “block/Kconfig” … …/KERNEL/linux-2.6.29/block/Kconfig: menuconfig “BLOCK” bool “Enable the block layer” … …

34. SILICON VALLEY UNIVERSITY CONFIDENTIAL 34 Spring 2014 Section 4 Kernel and Linux File System  Assignment 4: Build busybox Application Late 1990s, busybox application was developed (replace uclibc). Used in many embedded systems because it provided Linux utilities with small memory requirements. Busybox creates shell between the user and the kernel. Busybox has TinyLogin (suite of tiny Unix utilities) for authenticate, requiring login/password file. Create Root File System from scratch. Create skeleton directories.  Minimum directories (i.e. /home, /proc, /usr, /etc) needed to be created.  chmod 644 group (group account information)  chmod 644 inittab (processes started at bootup)  chmod 644 passwd (user password information)  chmod 640 gshadow (hashed password for group)  chmod 640 shadow (hashed user password)  chmod 644 profile (user information)  Compare with Monta Vista, very large RAM requirement for Linux. Must select “loadable modules”, otherwise system commands, insmod, modprobe, and rmmod will not be available.  Kernel configuration select internal module loading/unloading.