Hardware access

The minidriver program most likely requires hardware access, meaning it needs to read and write hardware registers. In order to help you access hardware registers, the startup library provides function calls to map and unmap physical memory. At different times in the boot process, some calls may or may not be available:

• When the minidriver handler is called with MDRIVER_INIT, these functions are available:
  • startup_io_map()
  • startup_io_unmap()
  • startup_memory_map()
  • startup_memory_unmap()
• After the minidriver handler is called with MDRIVER_STARTUP_PREPARE, the above functions are no longer available, and your driver must use these instead:
  • callout_io_map()
  • callout_memory_map()

For more information, see the Customizing Image Startup Programs chapter of Building Embedded Systems.

Here's a summary of what you need to do at each state if your minidriver needs to access hardware:

MDRIVER_INIT

• Initialize the hardware, if necessary.
• Call startup_io_map() or startup_memory_map() to gain hardware access.
• Store this pointer (which we'll call ptr1) in the minidriver data area and use it to access hardware.

MDRIVER_STARTUP

Use ptr1 to do all hardware access. No memory map calls are needed.

MDRIVER_STARTUP_PREPARE

At this point, The minidriver should call callout_io_map() or callout_memory_map(), Store the returned pointer (which we'll call ptr2) in the minidriver data area or in a static variable, separate from the previously stored value. Don't use ptr2 yet; continue to use ptr1 to do all hardware access.

MDRIVER_STARTUP_FINI

This is the last call to your handler from within startup, so it's the last state in which you'll use ptr1 to do all hardware access. After this state, you'll use ptr2 instead.

MDRIVER_KERNEL, MDRIVER_PROCESS, MDRIVER_INTR_ATTACH

In these states, use ptr2 to do all hardware access.

For an example, see the Hardware Interaction Within the Minidriver appendix.