Ad
More Related Content
Similar to Lect 1_Embedded Linux Embedded RTOS ppt (20)
More from Varsha506533 (20)
Ad
Recently uploaded (20)
Ad
Lect 1_Embedded Linux Embedded RTOS ppt
- 2. Linux Features UNIX-like operating system. Features: Preemptive multitasking. Virtual memory (protected memory, paging). Shared libraries. Demand loading, dynamic kernel modules. Shared copy-on-write executables. TCP/IP networking. SMP support. Open source.
- 3. What’s a Kernel? AKA: executive, system monitor. Controls and mediates access to hardware. Implements and supports fundamental abstractions: Processes, files, devices etc. Schedules / allocates system resources: Memory, CPU, disk, descriptors, etc. Enforces security and protection. Responds to user requests for service (system calls). Etc…etc…
- 4. Kernel Design Goals Performance: efficiency, speed. Utilize resources to capacity with low overhead. Stability: robustness, resilience. Uptime, graceful degradation. Capability: features, flexibility, compatibility. Security, protection. Protect users from each other & system from bad users. Portability. Extensibility.
- 5. Kernel Architecture Applications System Libraries (libc) System Call Interface Hardware Architecture-Dependent Code I/O Related Process Related Scheduler Memory Management IPC File Systems Networking Device Drivers Modules
- 7. Linux Source Tree Layout /usr/src/linux Documentation arch fs init kernel include ipc drivers net mm lib scripts alpha arm i386 ia64 m68k mips mips64 ppc s390 sh sparc sparc64 acorn atm block cdrom char dio fc4 i2c i2o ide ieee1394 isdn macintosh misc net … adfs affs autofs autofs4 bfs code cramfs devfs devpts efs ext2 fat hfs hpfs … asm-alpha asm-arm asm-generic asm-i386 asm-ia64 asm-m68k asm-mips asm-mips64 linux math-emu net pcmcia scsi video … adfs affs autofs autofs4 bfs code cramfs devfs devpts efs ext2 fat hfs hpfs … 802 appletalk atm ax25 bridge core decnet econet ethernet ipv4 ipv6 ipx irda khttpd lapb …
- 8. linux/arch Subdirectories for each current port. Each contains kernel, lib, mm, boot and other directories whose contents override code stubs in architecture independent code. lib contains highly-optimized common utility routines such as memcpy, checksums, etc. arch as of 2.4: alpha, arm, i386, ia64, m68k, mips, mips64. ppc, s390, sh, sparc, sparc64.
- 9. linux/drivers Largest amount of code in the kernel tree (~1.5M). device, bus, platform and general directories. drivers/char – n_tty.c is the default line discipline. drivers/block – elevator.c, genhd.c, linear.c, ll_rw_blk.c, raidN.c. drivers/net –specific drivers and general routines Space.c and net_init.c. drivers/scsi – scsi_*.c files are generic; sd.c (disk), sr.c (CD-ROM), st.c (tape), sg.c (generic). General: cdrom, ide, isdn, parport, pcmcia, pnp, sound, telephony, video. Buses – fc4, i2c, nubus, pci, sbus, tc, usb. Platforms – acorn, macintosh, s390, sgi.
- 10. linux/fs Contains: virtual filesystem (VFS) framework. subdirectories for actual filesystems. vfs-related files: exec.c, binfmt_*.c - files for mapping new process images. devices.c, blk_dev.c – device registration, block device support. super.c, filesystems.c. inode.c, dcache.c, namei.c, buffer.c, file_table.c. open.c, read_write.c, select.c, pipe.c, fifo.c. fcntl.c, ioctl.c, locks.c, dquot.c, stat.c.
- 11. linux/include include/asm-*: Architecture-dependent include subdirectories. include/linux: Header info needed both by the kernel and user apps. Usually linked to /usr/include/linux. Kernel-only portions guarded by #ifdefs #ifdef __KERNEL__ /* kernel stuff */ #endif Other directories: math-emu, net, pcmcia, scsi, video.
- 12. linux/init Just two files: version.c, main.c. version.c – contains the version banner that prints at boot. main.c – architecture-independent boot code. start_kernel is the primary entry point.
- 13. linux/ipc System V IPC facilities. If disabled at compile-time, util.c exports stubs that simply return –ENOSYS. One file for each facility: sem.c – semaphores. shm.c – shared memory. msg.c – message queues.
- 14. linux/kernel The core kernel code. sched.c – “the main kernel file”: scheduler, wait queues, timers, alarms, task queues. Process control: fork.c, exec.c, signal.c, exit.c etc… Kernel module support: kmod.c, ksyms.c, module.c. Other operations: time.c, resource.c, dma.c, softirq.c, itimer.c. printk.c, info.c, panic.c, sysctl.c, sys.c.
- 15. linux/lib kernel code cannot call standard C library routines. Files: brlock.c – “Big Reader” spinlocks. cmdline.c – kernel command line parsing routines. errno.c – global definition of errno. inflate.c – “gunzip” part of gzip.c used during boot. string.c – portable string code. Usually replaced by optimized, architecture-dependent routines. vsprintf.c – libc replacement.
- 16. linux/mm Paging and swapping: swap.c, swapfile.c (paging devices), swap_state.c (cache). vmscan.c – paging policies, kswapd. page_io.c – low-level page transfer. Allocation and deallocation: slab.c – slab allocator. page_alloc.c – page-based allocator. vmalloc.c – kernel virtual-memory allocator. Memory mapping: memory.c – paging, fault-handling, page table code. filemap.c – file mapping. mmap.c, mremap.c, mlock.c, mprotect.c.
- 17. linux/scripts Scripts for: Menu-based kernel configuration. Kernel patching. Generating kernel documentation.
- 18. Embedded Linux
- 19. What are embedded systems? • Embedded systems are self contained intelligent electronic control systems. • They contain a microcontroller / microprocessor and peripherals interfaced to perform a particular series of tasks. • Embedded systems today run almost every electronic device imaginable from TV’s to washing machine. • Embedded systems also can be used for self-contained intelligent automated systems.
- 20. Simple Embedded Example • An AVR microcontroller. Atmega328. • Contains all hardware necessary to perform computational tasks onboard provided power is given to it. • Communicates with the outside world via gpio pins. • Can be used to read data from a sensor connected to it and analyze that. (e.g.: IR • Can be interfaces to motors and set to control the movement of the motors depending on the sensor input. • Then, the microcontroller can be put on-board a bot and be asked to perform line following!
- 21. Programming simple MC’s • Microcontrollers are defined by their architecture and bus bit width. • The atmega is an 8 bit AVR series microcontroller. • To program the atmega we need • A Compiler to compile C code for the atmega328 • A Flash/EPROM burning device • The cross compiler convers our code from C to the hex op code that can be placed in the atmega’s internal memory. • The atmega executes each instruction sequentially!
- 22. Hardware available • Hardware manufactures keep increasing complexity and system performance. • The higher processing power comes with the price of too much registers with individual internal controlling methodology • Hardware manufacturers needed to abstract their hardware to be able to support easier development. • Software developers needed a generalized framework where they cab build their applications without worrying about their hardware.
- 23. Hardware v/s software • Objective : Getting your code to sense / control external devices. • The more complex your hardware is, the more requirements it will have in respect to code to write control mechanism. • If a stand-alone application is required to be developed • Multiple (internal / external) devices have to be managed in the background • I/O of different devices must be managed and processed as per demand. • Interrupts / clocks / power must be managed to keep the microcontroller running. • This calls for increased debugging / non portability and results in increased development time / bugs in the system. • If hardware is as complicated and powerful as a computer (SBC) then we need code comparable to that of an Operating System (DOS) to be able to run it!!
- 24. Line between HW/ SW • Very few processors can be programmed by flash burning with ICSP. (e.g: ARM5) • Modern communication standards are replacing “legacy” RS- 232 with USB, I2C ,Ethernet etc. • The software control of these protocols in the Atmega register level way is too complex. • Harware manufacturers release “Drivers” or libraries for controlling their hardware to software developers which allows for more efficient usage of the underlying hardware.
- 26. Embedded Linux Hardware • Processor • RAM • GPIO • Clocks • UART • I2C Kernel • Kernel developers work on hardware control of the devices. Userland • This is where user level application programs are written.
- 27. Embedded Linux • In 1990s, an underground software movement consisting of the worlds leading developers and programmers wrote a completely free Operating System! • As more people used it with the FOSS philosophy, improvements, fixes and support for multiple processors creeped in! • This resulted in Linux (the very same kernel ) to run on many processors and provide a similar level of functionality. • A Global collaborative effort for improvements and upgrades make linux so popular with hardware developers • Most of the time, linux gets fixes and support for new hardware as soon as they are available!
- 28. Linux -> Embedded Linux • Linux for x86 and amd64 (desktop architectures) require almost 100 - 500mb. • Embedded Devices have more strict requirements in terms of memory and processing power. • Embedded Linux kernels can go as low of 11Mb when placed in RAM. • A non distribtion based linux – with only kernel and a minimal filesystem for a “dos” – like usage is usually run. • Any custom linux libraries for hardware / software can be installed to help with application development.
- 29. Starting the Hardware • When the hardware is switched on, the OS is present in some onboard memory peripheral. • First there is code called a bootloader that initializes all the required hardware on the board. • Bootloaders are small programs (4 – 16K) written for and compiled for specific hardware to be executed immediately after start. • The bootloader starts the board and loads the kernel from where-ever it is into RAM. • Once the Kernel starts executing from RAM, it takes over and starts a linux session!
- 30. Types of Bootloaders • Intel Motherboard : PHOENIX BIOS : • This bootloader is present on most intel based laptops. • It starts the laptop hardware and loads “NTLDR” the windows bootmanager. • This code is hardwired into the mother board. • Embedded Hardware • Bootloader is usually places in a NAND Flash memory. • Bootloaders are very small. • They load, uncompress the linux kernel and relenquish control..
- 31. Kerne l• Designed as a Finnish UG (B.tech eq) student’s hobby project. • First was made as a UNIC port for a motorola 64Kb machine that made Linux designed for Portability. • The groundwork and FOSS nature allowed the kernel to be ported to (and thus support) almost every hardware platform on/off the market. • The base for extending the kernel through “Device Drivers” have hardware manufactures / driver developers to release support for any hardware available. • Kernel is just a runtime HAL! It just has instructions for running the hardware – something has to give it instructions -> RootFS..
- 32. Linux system Design DevelopmentLayers
- 33. Filesystem (UserLand) • Filesystem : Collection of directories • These directories follow a tree heirarchy and contain • Executable files or programs that the kernel loads into memory • Libraries for application to link to at run-time • User Application that can be simply installed onto it • Setting files that control the Linux OS’s behaviour. • Hardware devices are also linked as special file nodes in the filesystem to connect them to the Kernel’s HAL. • USB drives / HDDs / SD cards are mounted onto the filesystem and can be browsed as usual.
- 35. Cross Compilers and Toolchains • Different Hardware – Same Source code? • Cross Compilers are called the translators to machine language for different architectures. • Hardware manufactures and developers develop a toolchain for their architectures. • The toolchain contain all the utilities required to compile, debug code and link for the processor. • There is a GNU toolchain for AVR and ARM architectures. • The same source code when used with different cross compilers allow for targeting different platforms. • The changes in code required for a particular hardware is managed with localised “patches”.
- 36. Application s • Headless units : Devices without the need for a graphical display • Routers • Set Top Box • GUI based Applications • Touch Smartphones • GPS car navigation multimedia systems. • Application developers have: • System level functionality if required • Shared libraries for efficient management of resources • Linux kernel provided complete HAL • Same code workable of various devices • Android is a Linux Kernel and FS example! • Android will run on any phone that linux can work in. • Phone developers have a unified Free OS to work with. • Cheaper and more wide variety of applications!
- 37. Driver s • Run time modules attached to the linux kernel to manage hardware peripherals • USB Wifi • Camera • GPS • Unified driver API that makes it easy to write Driver Code that integrated to the main Kernel. • Hardware that is accepted to the main repository (upstream) means that everybody has access to the driver for that hardware! • Linux drivers need not be released as source – which means hardware manufactures can release their driver in binary format. (becomes proprietary)
- 38. Librarie s • C library • Provides an interface to the kenel functions via calls from userland. • Stripped down minimal C libraries are there for use in embedded devices. • GlibC (Full Featured) • uCibC (Minimal Variant) • POSIX support • Allows for communication job sceduling, multiprocessing and IPC in a unified framework. • ALSA • Advanced Linux Sound Architecture for Hardware DSP support
- 39. Custom Applications • Compiled with appropriate cross-compiler as UNIX / POSIX Compliant applications • BusyBox • Provides an embedded shell functionality in embedded devices • cd ls mkdir echo cat and all standard linux commands all work • I/O can be managed over a serial line • Can be thought of as a terminal equivalent • Commands allow for direct control of the kernel • Helps navigate the filesystem • Qt GUI applications can also be built if LCD is present.
- 40. Run Time Linux • Serial Console • Apps that can be autostarted • Daemons or “services” that provide background application functionality • Kernel Threads for Real-Time interrupt management • RTOS supprt in RT-Linux Project.
- 41. Memory Considerations • Linux works primarily on processors with a hardware MMU. (memory management unit) • MMU enforces copy and access violation protection in RAM between kernel, hardware and user application to make sure system can be kept stable at all times. • Virtual Memory allows for run-time linking and delinking of un responsive kernel modules / application to keep the system functioning even in the event of a crash.
- 42. Try for yourself • devmem2 • Memory inspector • ps • Running processors • cat files in /proc • Gives you current system information
- 43. Open source Licenses • Basic funda • Us at your own Risk • No guarantee • We’ll help if we CAN. We don’t need to. • GPLv2 • GNU Public Licence • Source must accompany binary • Linkng to non GPL software not possible. • LGPL • Link to non GPL software possible • To provide for non open source driver development • LGPL source must be provided • Modified Free-BSD • No source delivery required • For proprietary kernels • Broken and non FOSS supported Forks
Editor's Notes
- #5: Stephen Tweedie claims “All kernel code executes in a process context (except during startup)”. He also says that it is possible for an interrupt to occur during a context switch. So it is uncommon for there to be no user process mapped. The real problem is not knowing what process is mapped. Kernel mode, system context activities occurs asynchronously and may be entirely unrelated to the current process.