cpukit: Convert files to README.md MarkDown

cpukit/dtc/libfdt/README.md

@@ -1,3 +1,5 @@
+TODO
+====
 - Tree traversal functions
 - Graft function
 - Complete libfdt.h documenting comments

cpukit/libi2c/README.md

@@ -1,13 +1,11 @@
-=====================
 Copyright and License
-=====================
+---------------------
 
 For Copyright and License of the source code, see the header in
 libi2c.c. 
 
-=========
 Overview
-========
+--------
 
 This directory contains a general I2C/SPI API library. It offers a
 standard API to I2C or SPI based device drivers, abstracting the low
@@ -19,23 +17,21 @@ In most cases throughout this document, i2c and spi devices are
 handled in a similar way. Therefore spi will not be explicitly named
 in every location.
 
-=========
+
 Features
-=========
+---------
 
   + supports multiple i2c and/or spi busses 
-
   + supports multiple devices connected to each i2c/spi bus
-
   + handles bus and device registration to the I/O manager
 
-=========
 Structure
-=========
+---------
 
 This library defines a layered API to i2c and spi devices. The
 layering is:
 
+```
   +----------------------------------------+
  6|            Application                 |
   +----------------------------------------+
@@ -52,6 +48,7 @@ layering is:
  1|      i2c controller driver             |
   |              (in BSP)                  |
   +----------------------------------------+
+```
 
 This document will describe the following interfaces in separate
 sections:
@@ -68,9 +65,9 @@ sections:
   + the interface between the libi2c low level abstraction layer and
   the i2c controller driver (2<->1)
 
-===================================
+
 Differences between i2c and spi bus
-===================================
+-----------------------------------
 SPI and I2C has many similarities, but also some differences:
 
 - I2C uses inband addressing (the first bits sent select, which slave
@@ -90,9 +87,8 @@ of serial data transmission, but care should be taken not to use
 features dedicated to the wrong type of serial bus.
 
 
-======================
 Library Initialization
-======================
+----------------------
 Before any libi2c API is used, the library must be initialized. This
 is achived with a call to function
 
@@ -127,9 +123,9 @@ For the time being, we must rely on the BSP (predriver_hook)
 to initialize the i2c system if it is used by other drivers
 (e.g., the RTC driver may have to use a i2c device).
 
-===================
+
 Bus Registration
-===================
+----------------
 Each i2c and/or spi bus available must be registerd with a call to
 
 int rtems_libi2c_register_bus (char *name, 
@@ -150,9 +146,9 @@ subsequent calls to register devices attached to this bus (see below).
 Typically the BSP startup code will perform this registration for each
 bus available on the board.
 
-==========================
+
 Device/Driver Registration
-==========================
+--------------------------
 Each device attached to an i2c or spi bus must be registered with a
 call to
 
@@ -181,9 +177,9 @@ Note: If you have multiple devices of the same type, you must register
 each of them through a separate call (with the same "drvtbl", but
 different name/bus/i2caddr).
 
-====================================================================
+
 (5<->4) RTEMS I/O Manager and the libi2c OS adaption layer IF
-====================================================================
+-------------------------------------------------------------
 
 The RTEMS I/O Manager regards the libi2c OS adaption layer as a normal
 RTEMS Device Driver with one unique major number and a set of minor
@@ -192,6 +188,7 @@ the busses.
 
 Therefore the libi2c OS adaption layer provides the standard calls:
 
+```c
 static rtems_driver_address_table libi2c_io_ops = {
   initialization_entry:  i2c_init,
   open_entry:            i2c_open,
@@ -200,6 +197,7 @@ static rtems_driver_address_table libi2c_io_ops = {
   write_entry:           i2c_write,
   control_entry:         i2c_ioctl
 };
+```
 
 These calls perform some parameter checking and then call the
 appropriate high level i2c device driver function, if available,
@@ -215,9 +213,8 @@ The main reason for the libi2c OS adaption layer is, that it
 dispatches the RTEMS I/O Manager calls to the proper device driver
 according to the minor number used.
 
-====================================================================
 libi2c OS adaption layer and the high level i2c device driver IF
-====================================================================
+----------------------------------------------------------------
 
 Each high level i2c device driver provides a set of functions in the
 rtems_libi2c_drv_t data structure passed the libi2c when the device is
@@ -227,12 +224,12 @@ the RTEMS I/O Mangers calls "open", "close", "read", "write",
 needed may be omited (and replaced by a NULL pointer in
 rtems_libi2c_drv_t).
 
-======================================================================
 high level i2c device driver and libi2c low level abstraction layer IF
-======================================================================
+----------------------------------------------------------------------
 libi2c provides a set of functions for the high level drivers. These
 functions are:
 
+```c
 rtems_libi2c_send_start();
 rtems_libi2c_send_stop();
 rtems_libi2c_send_addr();
@@ -241,6 +238,7 @@ rtems_libi2c_write_bytes();
 rtems_libi2c_start_read_bytes();
 rtems_libi2c_start_write_bytes();
 rtems_libi2c_ioctl();
+```
 
 Please look into libi2c.h for the proper parameters and return codes.
 
@@ -248,23 +246,28 @@ These functions perform the proper i2c operations when called.
 
 A typical access sequence for the I2C bus would be:
 
+```c
 rtems_libi2c_send_start();
 rtems_libi2c_send_addr();
 rtems_libi2c_write_bytes();
 rtems_libi2c_send_stop();
+```
 
 Alternatively, the rtems_libi2c_write_bytes() call could be relpaced
 with a 
-          rtems_libi2c_read_bytes() 
 
+```c
+          rtems_libi2c_read_bytes() 
+```
 call or a sequence of multiple calls.
 
 Note: rtems_libi2c_send_start() locks the i2c/spi bus used, so no other
 device can use this i2c/spi bus, until rtems_libi2c_send_stop() function
 is called for the same device.
 
+
 Special provisions for SPI devices:
-===================================
+-----------------------------------
 For SPI devices and their drivers, the libi2c interface is used
 slightly differently:
 
@@ -284,25 +287,32 @@ the bus.
 
 A typical access sequence for the SPI bus would be:
 
+```c
 rtems_libi2c_send_start();
 rtems_libi2c_ioctl(...,RTEMS_LIBI2C_IOCTL_SET_TFRMODE,...);
 rtems_libi2c_send_addr();
 rtems_libi2c_write_bytes();
 rtems_libi2c_send_stop();
+```
 
 Alternatively, the rtems_libi2c_write_bytes() call could be relpaced
 with a 
+```c
          rtems_libi2c_read_bytes() 
+```
 or a 
+```c
          rtems_libi2c_ioctl(...,RTEMS_LIBI2C_IOCTL_READ_WRITE,...)
+```
 call or a sequence of multiple calls.
 
-====================================================================
+
 libi2c low level abstraction layer and i2c controller driver IF
-====================================================================
+---------------------------------------------------------------
 Each low level i2c/spi driver must provide a set of bus_ops functions
 as defined in the rtems_libi2c_bus_ops_t structure.
 
+```c
 typedef struct rtems_libi2c_bus_ops_
 {
   /* Initialize the bus; might be called again to reset the bus driver */
@@ -326,14 +336,17 @@ typedef struct rtems_libi2c_bus_ops_
 		void *buffer;
 		);
 } rtems_libi2c_bus_ops_t;
+```
 
 Each of these functions performs the corresponding function to the i2c
 bus. 
 
+
 Special provisions for SPI devices:
-===================================
+-----------------------------------
 For SPI busses, special behaviour is required:
 
+```c
 (*send_start) (rtems_libi2c_bus_t * bushdl) 
 	      normally is an empty function.
 
@@ -350,9 +363,9 @@ For SPI busses, special behaviour is required:
 
 (*ioctl(...,RTEMS_LIBI2C_IOCTL_READ_WRITE,...) 
              will send and receive data at the same time.
+```
 
 Note: 
-
 - low-level I2C drivers normally are specific to the master
 device, but independent from the board hardware. So in many cases they
 can totally reside in libcpu or libchip.

cpukit/posix/src/README.md

@@ -1,6 +1,9 @@
+mqueue
+======
 This program should print out the default attribute settings for a 
 POSIX message queue.
 
+```c
 #include <mqueue.h>
 #include <stdio.h>
 
@@ -31,4 +34,4 @@ main()
   (void) mq_close( mqfd );
   exit( 0 );
 }
-
+```

cpukit/score/src/README.md

@@ -1,10 +1,11 @@
+Unlimited Local Node Objects
+============================
+
 This document explains how the unlimited objects support works.  This was
 written by Chris Johns <ccj@acm.org> of Objective Design Systems as a
 design document.  This was submitted as part of the patch which added
 this capability.  
 
-Unlimited Local Node Objects
-============================
 
 1. Why ?
 
@@ -356,5 +357,3 @@ o The Test
 
   A new sample test, unlimited is provided. It attempts to test this
   change.
-
-