NedHAL - an overview a modular, architecture-independent, multiprocessing-capable Hardware Abstraction Layer

by Niall Douglas

Project Goals

• To design and implement the ultimate Hardware Abstraction Layer (HAL) for the ARM architecture

• The main considerations:
  • excellent documentation
  • small & fast (low overheads)
  • flexible & scalable
  • easy to use
  • rich in features
  • can be executed from ROM

Use of HAL

• As a tiny OS
  • for embedded systems
  • for initial testing of prototype hardware

• As an OS bootstrapper
  • e.g.; ARMLinux is bootstrapped by �HAL

• Within an OS to aid portability
  • e.g.; Jean Labrosse�s U/COS II RTOS which requires a HAL to be used or written for each port

Origin of project

• Digital applied Alpha techniques to ARM to create StrongARM (now the Intel StrongARM)

• DEC StrongARM team wrote �HAL to test and demonstrate StrongARM

• ARM bought �HAL from Intel intending to deploy on upcoming Integrator hardware

• �HAL was best then available, but had a number of shortcomings ...

Main Problems to be solved (1/2)

• Lack of inter-ARM portability
  • different internal control ops between processor architectures (v3 vs. v4)

• Lack of generic hardware interface
  • changing hardware meant changing lots of code
  • sometimes driver�s code conflicted
  • no standard provision for centralised redirectable debug output

• Lack of support for exceptional ARM implementations e.g.; ɜKb DRAM systems

Main Problems to be solved (2/2)

• Lack of well-defined structure
  • allows bad programmers to really screw up other people�s code
  • bugs creep in
  • hard to insert and remove code easily
  • hard to extend capabilities uniformly
  • substantial additions overtax the structure, allowing potential future dumping of everything and complete recoding from scratch

Solutions Adopted (1/2)

• Modularisation
  • reduced conflicts between code
  • scalability & ease of extension

• Object orientation
  • ease of use
  • multiple instantiation (e.g.; for UART drivers)
  • interchangeability (e.g.; for ARM v3 vs. v4)
  • code remains procedural where speed or size requires it

Solutions Adopted (2/2)

• Structuring of modules into:
  • fully portable
  • board specific
    • hardware drivers (usually portable)
    • architecture specific
      • processor specific

• Use of a conceptual �zero page� of memory
  • separates HAL from OS
  • allows use on extremely small memory systems (less than 4Kb)

Conclusions (1/2)

• End-product met design goals
  • excellent intelligent HTML-based documentation
  • low overheads
  • flexible & scalable
  • easy to use and extend

• Fixes all major problems of �HAL
  • easy to change processor
  • easy to change and reconfigure for hardware
  • easy to route debug I/o through any hardware device

Conclusions (2/2)

• Surpasses �HAL in many areas
  • superior core features
  • implements an abstract serial API enabling easy UART driver interchanging
  • allows run-time reuse of code through multiple instantiation
  • allows easy build-time code reuse through modularisation
  • exposed API�s are layered, helping client code to be more portable

End of Presentation

Thank you for listening!