Skip to content

Latest commit

 

History

History
77 lines (53 loc) · 3.3 KB

31_basic_programming_model.md

File metadata and controls

77 lines (53 loc) · 3.3 KB

3.1 Basic programming model

Common questions about UEFI include:

  • How are programs in UEFI implemented?

  • What makes UEFI programming different from an operating system?

  • What makes UEFI different from other firmware environments?

  • In particular, what is the programming model for a UEFI Driver?

Key points about writing UEFI-conformant drivers are that:

  • UEFI Drivers are relocatable PE/COFF images whose format is defined by the Microsoft Portable Executable and Common Object File Format Specification.

  • UEFI Drivers may be compiled for any of the CPU architectures supported by the UEFI Specification.

  • UEFI Drivers run on a single CPU thread.

  • The driver support infrastructure does not extend beyond the boot processor.

  • Drivers sit above some interfaces (for example, bus abstractions) and below other interfaces: They are both consumers and producers. The UEFI Specification defines the interfaces and they are extensible.

  • Each driver is expected to cooperate with other drivers, other modules and the underlying core services.

  • The communicating modules bind together to create stacks of cooperating drivers to accomplish tasks.

  • Inter-module communication is enabled via interfaces known as protocols and via events.

  • Tables provided at invocation provide access to core services.

  • The operating environment is non-preemptive and polled. There are no tasks per se. Instead, modules execute sequentially.

  • There is only one interrupt: the timer. This means that data structures accessed by both in-line code and timer-driven code must take care to synchronize access to critical paths. This is accomplished via privilege levels.