1 / 25

Embedded Firmware

Embedded Firmware. 王善杰 R91943103 Graduate Institute of Electrical Engineering National Taiwan University June 8, 2004. Outline. Basic concepts of firmware. Case study. Conclusions. Define “Firmware”. Firmware is a piece of software stored on “non-volatile” memory.

mattox
Download Presentation

Embedded Firmware

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Embedded Firmware 王善杰 R91943103 Graduate Institute of Electrical Engineering National Taiwan University June 8, 2004

  2. Outline • Basic concepts of firmware. • Case study. • Conclusions.

  3. Define “Firmware” • Firmware is a piece of software stored on “non-volatile” memory. • Typical functions of a firmware: • Booting and running a system (a board or a chip) • Providing basic I/O services • Providing debugging services • Providing backdoor for system recovery/maintenance

  4. Board-level vs. Chip-level Firmware • Typical examples: • Board-level: BIOS, bootloader, debugger, etc. • Chip-level: microcontroller codes for a MPEG codec chip,USB controller chip, etc. • Board-level firmware size ranges from several KB to several MB. Chip-level firmware size has to be small to reduce cost • Typically, board-level firmware are full of debug code and are less efficient • Even for chip-level firmware, the design cycle starts on a development board

  5. Board-level Firmware and OS • There is a lot of similarity between board-level firmware and an operating system (OS) • Provides I/O interfaces for (application) program • Loads and executes program images • Helps program development • In the good old days, the whole OS of a computer can be a firmware (e.g. Apple II) • In the future, more and more devices will have a firmware OS (mobile phone, PDAs)

  6. Operating Systems Components • Process Management • Who gets to use the CPU? • Memory Management • Who gets to use the runtime memory? • File System • How to retrieve/store data? • I/O (Sub)-system • How to talk to the peripherals? • Can be part of the File System (e.g. Unix)

  7. Typical Architecture of an OS

  8. Can we get away from OS? • For small systems (e.g. appliances, peripherals) full-scale OS is not really necessary – on the other hand, software company tries to tell you differently (e.g. Microsoft XP Embedded) • Two types of tasks a small system runs: • Background operations: • Handling routine (synchronous) tasks • Usually called task level • Foreground operations: • Handling asynchronous events • Usually called interrupt level

  9. Foreground/Background Systems

  10. F/B System vs. Full OS • Why do we need an OS for, say, handsets? • Reduced development cost for a family of product • Easy extensibility (add new hardware, firmware) • Support for third party applications • Have someone to blame if things don’t work … (e.g. Microsoft) • If cost is the top concern, a firmware-based F/B system should be good enough for most embedded devices • In many cases, a full scale OS runs on top of firmware

  11. Porting Issues and AFS • Firmware should be custom-designed for each embedded development board, however, many firmware codes can be recycled for different applications • The ARM Firmware Suite (AFS) is a collection of tools and utilities designed as an aid to developing applications and operating systems on ARM-based systems

  12. ARM Firmware Suite (1/3) • µHAL libraries: µHAL is the ARM Hardware Abstraction Layer that is the basis of AFS • Flash library and utilities: The flash library provides an API for programming and reading flash memory. The API provides access to individual blocks or words in flash, and access to images and files

  13. ARM Firmware Suite (2/3) • Development environment: Reusable code is provided to help develop applications and product architectures on a wide range of ARM and third-party development platforms. AFS supports use of the Angel debug monitor, Multi-ICE, and third-party debug monitors • Additional components: Additional components provided with AFS include a boot monitor, generic applications, and board-specific applications

  14. ARM Firmware Suite (3/3) • Additional libraries: AFS supplies libraries for specialized hardware or exception handling: • The PCI library supports the PCI bus on the Integrator board • A public-domain library for compression, zlib, is included • The Chaining library provides support for exception chaining required, for example, by RealMonitor • The VFP library provides support for soft vector floating point routines • Angel: a version of Angel that has been implemented using µHAL • µC/OS-II: µC/OS-II is a multitasking kernel that is comparable in performance to many commercially available kernels. AFS includes a port of µC/OS for the ARM architecture using the µHAL API.

  15. Logical Organization of AFS • AFS is designed to be development-board and operating-system neutral

  16. µHAL • The µHAL libraries in AFS mask hardware differences between platforms by providing a standard layer of board-dependent functions. • Board and processor-independence for applications is achieved by a set of low-level functions that: • identify and initialize the system processor or multiple processors • identify and initialize the system memory • identify and initialize the system buses, for example PCI • identify and initialize system devices, for example serial interfaces • initialize and handle interrupts • access code or data stored in flash memory

  17. Example of µHAL Functions • System initialization • Serial ports • Generic timers • Generic LEDs • Interrupt control • Memory management (cache and MMU)

  18. AFS Operation Mode • You can write µHAL applications to operate in one of two modes: • Standalone: A standalone application is one that has complete control of the system from boot time onwards • Semihosted: A semihosted application is one for which an application or debug agent, such as Angel or Multi-ICE, provides or simulates facilities that do not exist on the target system

  19. AFS Flash Library & Utilities • Library functions: access flash from your own application • ARM Flash Utility (AFU): load applications into the flash or RAM memory • ARM Boot Flash Utility (BootFU): program the boot and FPGA areas of flash memory • Boot switcher: select and run an image in application flash. You can store one or more code images in flash memory and use the boot switcher to start the image at reset • Boot monitor: load an image from the serial port and select it to run when the development board is reset. The boot monitor also provides a simple command-line interface that provides system debug and self-test functions

  20. Flash Storage (1/2) • Flash memory is a key non-volatile storage medium in embedded devices • Two types of flash memory • NOR flash – traditional flash, directly accessible • NAND flash – cheaper, addressable thru a single 8-bit bus for both data and addresses • “Clean” flash memory contains “logical one” bits only, a write operation set a bit to zero

  21. Flash Storage (2/2) • Resetting bits from zero to one cannot be done individually, but only by resetting a complete block • Typical lifetime: 100,000 erases per block • A buffer on the flash device is used for efficient write operations and reduce erase wear

  22. Flash File System • It is nice to let a flash device emulate a block device with standard 512-byte sectors, such as a hard drive • However, direct 1:1 mapping between the flash chips and the OS file system sectors via “cache” is bad. • Inefficient and unreliable • No “wear leveling” – a flash file system must ensure that erase cycle are evenly distributed • To provide wear leveling and reliable operation, sectors of the emulated block device are stored in a varying locations on the physical medium. A translation layer is used to keep track of the current location of each sector

  23. Flash Images • The flash memory on development boards is logically divided into two areas: • Application Flash: holds data and user applications; you normally load your own programs into the application flash • Boot Flash: holds the boot monitor and boot switcher utilities used for loading and debugging applications

  24. Flash Image Structure • The images stored in flash memory have three to five parts: • Code and data: the actual code and data for the image • Header: not all images have a header. • Image information block: holds additional information about the image such as image name and start address • Empty: if the image does not completely fill the flash block, there is an area of empty flash before the footer • Footer: the owner of the image, a checksum, and the image number are stored in the footer

  25. Conclusion • In the future, more and more devices will have a firmware OS (mobile phone, PDAs) • Firmware should be custom-designed for each embedded development board, however, many firmware codes can be recycled for different applications

More Related