ChorusOS 5.0 Board Support Package Developer's Guide

Overview of Creating a New Device/Bus Driver

This section contains a general overview of how to create a new device driver. A device driver is represented by a static variable that contains information on where the driver can be found, and what devices it supports, as well as its standard entry points for the driver framework. For more information on what is involved in the following steps see Chapter 10, Writing a New Device Driver and Chapter 11, Writing a New Bus Driver.

Creating a new Device/Bus Driver
  1. Create a new driver root directory within the ChorusOS DRV (source_dir/nucleus/bsp/src) component source tree (or in another location).

    Depending on whether the driver is generic or specific to a particular target family, you organize the new driver directory in the ddi/ or family/ddi directories.

  2. Create a driver actor whose main routine registers your device driver structure in the driver registry.

    This is implemented in the files my_drv.c and my_drvProp.h (for any constant values). For more information see "Driver Registry".

  3. Modify the Imakefile of the parent directory to include the new my_drv directory, and create a new Imakefile within the directory.

    For example:

    CSRCS = my_drv.c
    OBJS = $(CSRCS:.c=.o)
    BuiltinDriver(D_my_drv, $(OBJS), $(DRV_LIBS))
    DistProgram(D_my_drv, $(DRV_DIST_BIN)$(REL_DIR))
    Depend($(CSRCS))
  4. Modify the target.xml file of the board that you are adding driver support for.

    You need to add the definition and path of your driver to the Files folder, and the driver name to the file list in the System image folder. For some platforms the target.xml file is split into multiple files: drivers.xml, drvlist.xml, target.xml. In this situation you will find the File folder in the drivers.xml file, and the drivers to be included in the system image would be included in the drvlist.xml file.

    For example you would need to add the following sections to specify your new driver:

    <folder name='Files' configurable='yes'>
      <description> files...</description>
      ...
      <definition name='my_drv'>
        <type name='File' />
        <value field='path'>
          <vstring>${DRV_DIR}/bin/drv/<ddi>/my_drv/D_my_drv</vstring>
        </value>
        <value field='bank'><ref name='sys_bank' /></value>
        <value field='binary'><ref name='driver_model' /></value>
      </definition>
    ...
    <folder name='System image'> 
      ...
      <folder name='Files'>
        <description>system image files<description</description>
          <definition name='BSP files' configurable='yes'>
            <description>system image BSP file</description>
             <type name='File list' />
             ...
             <value index='size' ><ref name='my_drv' /></value>
             ...
          </definition>
      ...
  5. You may need to add a new device node to the ChorusOS device tree, that represents the new physical device.

    To do this you will need to modify the deviceTree.c file. Creating the device node statically in this way is only required if there is no automatic processing policy for this kind of device. Typically a PCI device may be dynamically discovered at runtime. It may also be required if specific configuration properties have to be attached to that device node (for example, properties that cannot be created by dynamic probing).

  6. Write the implementation of the standard driver routines that are exposed as entry points to the Driver Framework in the driver registry.

    These are drv_probe(), drv_init(), drv_bind(), drv_unload() in the driver source files.

  7. Build and boot the new ChorusOS system image with the new driver embedded in it.

    Your new driver is registered in the driver registry. Alternatively, you can build the driver and manually start it on an already running ChorusOS system.

    Assuming that the physical device is present on the target board, the driver entry points should be called by the framework and a driver instance started for the device.