Agnostic Device Drivers  ( ADD ) Concept, Design, and Implementation of a Slimline  Boot Firmware for Linux on Power Archi...
Contents <ul><li>Open Firmware Standard </li></ul><ul><li>Existing Hardware Abstraction Concepts </li></ul><ul><li>Agnosti...
Is Hardware Abstraction necessary?
Open Firmware  Standard <ul><li>IEEE Standard IEEE Std. 1275-1994 Standard for Boot (Initialization Configuration) Firmwar...
Existing Hardware Abstraction Concepts (based on Open Firmware) Common Hardware Reference Platform: Apple:
Comparison - - High-Level Language Facilities: -- - Packaging: +/- - Flexibility: ++ - Performance: Platform Expert RTAS
Agnostic Device Drivers (ADD) – Concept and Basics
Agnostic Device Drivers (ADD) – Packaging Options <ul><li>1: ADD byte-code program taken from Device-Tree </li></ul><ul><u...
Agnostic Device Drivers (ADD) – Virtual Machine <ul><li>Front-End: Loads Byte-Code (from different sources) </li></ul><ul>...
Agnostic Device Drivers (ADD) – Functionality <ul><li>Small footprint virtual machine </li></ul><ul><li>Controlling of low...
Agnostic Device Drivers (ADD) – Summary ++ ++ ++ ++ Agnostic Device Drivers - - High-Level Language Facilities: -- - Packa...
<ul><li>Questions ??? </li></ul>
Further Opportunities <ul><li>Real-Time / Performance </li></ul><ul><ul><li>ADD is an asynchronous interface / hardware ab...
Agnostic Device Drivers (ADD) – Example: Byte Code
Agnostic Device Drivers (ADD) – Example: Linux Kernel I2C Interface <ul><li>I2C algorithm driver used by the I2C bus drive...
Overview of available Options  – CHRP (Common Hardware Reference Platform) <ul><li>Based on Open Firmware </li></ul><ul><l...
Overview of available Options  – RPA (RISC Platform Architecture) <ul><li>Based on CHRP </li></ul><ul><li>Hypervisor </li>...
LinuxBIOS
OpenBIOS <ul><li>Maintainer Stefan Reinauer and Patrick Mauritz </li></ul><ul><li>Main Goal To get a 100% compliant Open F...
Complete Boot Process - Phase 1
Complete Boot Process  - Phase 2
Complete Boot Process  -  Phase 3
Upcoming SlideShare
Loading in...5
×

Agnostic Device Drivers

818

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
818
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • To replace the title / subtitle with your own: Click on the title block -&gt; select all the text by pressing Ctrl+A -&gt; press Delete key -&gt; type your own text
  • Device-Tree: The set of devices attached to the system, including permanently installed devices and plug-in devices, is described by an Open Firmware data structure known as device tree.
  • RPA: - implements a Hypervisor - can run several Operating Systems - implements RTAS Apple: - doesn’t implement RTAS and a Hypervisor - has Platform Expert (Hardware and Operating System “Platform Expert” Code, which is copied from the firmware to the kernel of the Operating System, where it is executed)
  • Agnostic Device Drivers (ADD) Concept and Basics (1): During the boot phases of the operating system, the Device-Tree (including ADD Byte-Code) is fetched over the client interface of Open Firmware. Device-Tree, with the Byte-Code included, is stored by the operating system and is available after lifetime of Open Firmware. (2): ADD Interpreter loads Byte-Code from the stored Device-Tree. (3): ADD Interpreter executes Byte-Code asynchronous.
  • Control Structures: - Finite loop incrementing by 1 - Finite loop incrementing by &lt;n&gt; - Indefinite loop terminating when &lt;f&gt; is &apos;true‘ - Indefinite loop terminating when &lt;f&gt; is &apos;false‘ - Infinite loop - Two-branch conditional Defining Words: - Variables - Constants - Colon Definitions (Sub-Routines)
  • Agnostic Device Drivers

    1. 1. Agnostic Device Drivers ( ADD ) Concept, Design, and Implementation of a Slimline Boot Firmware for Linux on Power Architecture IBM Deutschland Entwicklung GmbH Schoenaicherstr. 220 71032 Boeblingen
    2. 2. Contents <ul><li>Open Firmware Standard </li></ul><ul><li>Existing Hardware Abstraction Concepts </li></ul><ul><li>Agnostic Device Drivers (ADD) </li></ul><ul><li>Further Opportunities </li></ul>
    3. 3. Is Hardware Abstraction necessary?
    4. 4. Open Firmware Standard <ul><li>IEEE Standard IEEE Std. 1275-1994 Standard for Boot (Initialization Configuration) Firmware </li></ul><ul><ul><li>Device Interface </li></ul></ul><ul><ul><li>User Interface </li></ul></ul><ul><ul><li>Client Interface </li></ul></ul><ul><ul><li>Device-Tree </li></ul></ul>
    5. 5. Existing Hardware Abstraction Concepts (based on Open Firmware) Common Hardware Reference Platform: Apple:
    6. 6. Comparison - - High-Level Language Facilities: -- - Packaging: +/- - Flexibility: ++ - Performance: Platform Expert RTAS
    7. 7. Agnostic Device Drivers (ADD) – Concept and Basics
    8. 8. Agnostic Device Drivers (ADD) – Packaging Options <ul><li>1: ADD byte-code program taken from Device-Tree </li></ul><ul><ul><li>Packaged with the Firmware Code. </li></ul></ul><ul><ul><li>Additional Device-Tree properties can include control or execution information. </li></ul></ul><ul><li>2: ADD byte-code program inserted during run-time (via user transaction) </li></ul><ul><ul><li>Fast development of ADD byte-code programs. </li></ul></ul><ul><ul><li>Flexible packaging. </li></ul></ul>
    9. 9. Agnostic Device Drivers (ADD) – Virtual Machine <ul><li>Front-End: Loads Byte-Code (from different sources) </li></ul><ul><li>Virtual Machine: Executes ADD Byte-Code </li></ul><ul><li>Back-End: Implements I2C and GPIO Binding to the Operating System </li></ul>
    10. 10. Agnostic Device Drivers (ADD) – Functionality <ul><li>Small footprint virtual machine </li></ul><ul><li>Controlling of low-bandwidth devices (e.g. I2C or GPIO) is possible </li></ul><ul><li>Controlling of the policy and the logic of a device is possible </li></ul><ul><ul><li>Control Structures </li></ul></ul><ul><ul><li>Defining Words </li></ul></ul><ul><li>Extended Debug Facilities </li></ul><ul><ul><li>Virtual Machine runs in hosted mode </li></ul></ul><ul><ul><li>Virtual Machine runs as kernel thread (root user can interrupt it) </li></ul></ul><ul><ul><li>I2C Drivers can debugged via I2C Emulation Host Adapter </li></ul></ul><ul><ul><li>Rebooting during development is not necessary </li></ul></ul><ul><ul><li>Single execution is not difficult to implement </li></ul></ul>
    11. 11. Agnostic Device Drivers (ADD) – Summary ++ ++ ++ ++ Agnostic Device Drivers - - High-Level Language Facilities: -- - Packaging: - - Flexibility: ++ - Performance: Platform Expert RTAS
    12. 12. <ul><li>Questions ??? </li></ul>
    13. 13. Further Opportunities <ul><li>Real-Time / Performance </li></ul><ul><ul><li>ADD is an asynchronous interface / hardware abstraction. </li></ul></ul><ul><ul><li>Functionality can implemented as primitive (for real-time applications). </li></ul></ul><ul><li>Scheduling </li></ul><ul><ul><li>Scheduling (once, every 5 sec., etc.) can controlled via a Device-Tree property. </li></ul></ul><ul><ul><li>Thread Support is not difficult to implement (instruction pointer and token-table pointer must saved). </li></ul></ul><ul><li>Multi-OS </li></ul><ul><ul><li>Only vendor token-table entries changed. </li></ul></ul><ul><li>ADD Virtual Machine can integrated into the firmware </li></ul><ul><ul><li>ADD driver could then used in the firmware and the operating system. </li></ul></ul><ul><li>Extended Debug Facilities </li></ul><ul><ul><li>Realizes fast program development and debugging. </li></ul></ul>
    14. 14. Agnostic Device Drivers (ADD) – Example: Byte Code
    15. 15. Agnostic Device Drivers (ADD) – Example: Linux Kernel I2C Interface <ul><li>I2C algorithm driver used by the I2C bus driver to talk to the I2C bus. </li></ul><ul><li>I2C chip driver controls the process of talking to an individual I2C device that lives on an I2C bus. </li></ul>
    16. 16. Overview of available Options – CHRP (Common Hardware Reference Platform) <ul><li>Based on Open Firmware </li></ul><ul><li>RTAS (Run-Time Abstraction Service) Hides machine dependent operations behind a machine independent interface, which the operating system can call synchronous. </li></ul><ul><li>System Firmware = LLFW + Open Firmware + RTAS </li></ul>
    17. 17. Overview of available Options – RPA (RISC Platform Architecture) <ul><li>Based on CHRP </li></ul><ul><li>Hypervisor </li></ul><ul><ul><li>partitions machine resources </li></ul></ul><ul><ul><li>enables multiple operating systems </li></ul></ul><ul><ul><li>space for hardware dependent patches </li></ul></ul><ul><ul><li>only one Hypervisor instance exits for all operating systems </li></ul></ul><ul><li>Partition Firmware = Open Firmware + RTAS </li></ul>
    18. 18. LinuxBIOS
    19. 19. OpenBIOS <ul><li>Maintainer Stefan Reinauer and Patrick Mauritz </li></ul><ul><li>Main Goal To get a 100% compliant Open Firmware boot firmware. </li></ul><ul><li>Current Function OpenBIOS could be executed under a boot manager or LinuxBIOS. </li></ul><ul><li>File System Support Support adopted from Grub and libhfs. </li></ul><ul><li>PPC Support Rudimentary available from the Mac-On-Linux project. </li></ul>
    20. 20. Complete Boot Process - Phase 1
    21. 21. Complete Boot Process - Phase 2
    22. 22. Complete Boot Process - Phase 3
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×