forked from Imagelibrary/rtems
cpukit: Convert cpukit/*/README to MarkDown
There are a lot of README files this is just a cursory glance to convert but will render fine online. If they don't we can make changes.
This commit is contained in:
Amar Takhar
@@ -1,4 +1,5 @@
|
||||
XZ Emebdded
|
||||
===========
|
||||
|
||||
Chris Johns <chrisj@rtems.org> 2016
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
ZLIB DATA COMPRESSION LIBRARY
|
||||
=============================
|
||||
|
||||
zlib 1.2.13 is a general purpose data compression library. All the code is
|
||||
thread safe. The data format used by the zlib library is described by RFCs
|
||||
@@ -1,3 +1,6 @@
|
||||
DTC
|
||||
===
|
||||
|
||||
The source tree contains the Device Tree Compiler (dtc) toolchain for
|
||||
working with device tree source and binary files and also libfdt, a
|
||||
utility library for reading and manipulating the binary format.
|
||||
@@ -1,3 +1,6 @@
|
||||
libblock
|
||||
========
|
||||
|
||||
This directory contains the block device (HDD, CDROMs, etc) support code.
|
||||
It includes:
|
||||
- block device driver interface
|
||||
@@ -1,4 +1,5 @@
|
||||
--
|
||||
libcsupport
|
||||
===========
|
||||
|
||||
Overview of newlib support (newlib is from CYGNUS)
|
||||
Each task can have its own libc state including:
|
||||
@@ -1,3 +1,6 @@
|
||||
libfs
|
||||
=====
|
||||
|
||||
This directory contains for the "file system" library. All supported
|
||||
file systems live under this tree.
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
libmisc
|
||||
=======
|
||||
|
||||
This directory contains for the "miscellaneous" library. Currently
|
||||
this library contains a number of useful support libraries:
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
libmisc
|
||||
=======
|
||||
|
||||
RTEMS Performance Monitoring and Measurement Framework
|
||||
|
||||
Copyright 2002-2007 Chris Johns (chrisj@rtems.org)
|
||||
@@ -30,11 +33,13 @@ This is a target interface that provides a number of user commands via the
|
||||
RTEMS monitor. To use you need to provide the following in your
|
||||
application initialisation:
|
||||
|
||||
```c
|
||||
#include <rtems/monitor.h>
|
||||
#include <rtems/capture-cli.h>
|
||||
|
||||
rtems_monitor_init (0);
|
||||
rtems_capture_cli_init (0);
|
||||
```
|
||||
|
||||
Check the file capture-cli.h for documentation of the interface. The parameter
|
||||
is a pointer to your board support package's time stamp handler. The time stamp
|
||||
@@ -1,3 +1,6 @@
|
||||
cpuuse
|
||||
======
|
||||
|
||||
This directory contains code to report and reset per-task CPU usage.
|
||||
If the BSP supports nanosecond timestamp granularity, this this information
|
||||
is very accurate. Otherwise, it is dependendent on the tick granularity.
|
||||
@@ -1,9 +1,7 @@
|
||||
#
|
||||
#
|
||||
# fsmount information
|
||||
#
|
||||
# Author: Thomas Doerfler 02/07/2003
|
||||
#
|
||||
fsmount
|
||||
=======
|
||||
|
||||
Author: Thomas Doerfler 02/07/2003
|
||||
|
||||
fsmount.c contains the function fsmount. It processes the
|
||||
fs table given as an parameter to create the listed mount points
|
||||
@@ -18,5 +16,3 @@ The field "abort_reasons" specifies, what results of the mount point
|
||||
creation/mount operations should abort the function. Do not set the
|
||||
"abort_reasons" bit, unless you want to stop the processing of the
|
||||
fsmount table after the first successful mount.
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
monitor task
|
||||
Monitor task
|
||||
============
|
||||
|
||||
The monitor task is an optional task that knows about RTEMS
|
||||
data structures and can print out information about them.
|
||||
@@ -12,11 +13,13 @@ greater than 1.
|
||||
To use the monitor:
|
||||
-------------------
|
||||
|
||||
```c
|
||||
#include <rtems/monitor.h>
|
||||
|
||||
...
|
||||
|
||||
rtems_monitor_init(0);
|
||||
```
|
||||
|
||||
The parameter to rtems_monitor_init() tells the monitor whether
|
||||
to suspend itself on startup. A value of 0 causes the monitor
|
||||
@@ -39,6 +42,7 @@ Monitor commands
|
||||
|
||||
Commands (may be abbreviated)
|
||||
|
||||
```
|
||||
help -- get this message or command specific help
|
||||
task -- show task information
|
||||
queue -- show message queue information
|
||||
@@ -69,11 +73,13 @@ Monitor commands
|
||||
continue
|
||||
put the monitor to sleep waiting for an explicit wakeup from the
|
||||
program running.
|
||||
```
|
||||
|
||||
|
||||
Sample output from 'task' command
|
||||
---------------------------------
|
||||
|
||||
```
|
||||
rtems> task
|
||||
ID NAME PRIO STAT MODES EVENTS WAITID WAITARG NOTES
|
||||
------------------------------------------------------------------------
|
||||
@@ -89,4 +95,4 @@ Sample output from 'task' command
|
||||
|
||||
It has no events.
|
||||
(this is the libc thread state)
|
||||
|
||||
```
|
||||
@@ -1,3 +1,6 @@
|
||||
Mouse
|
||||
=====
|
||||
|
||||
SOURCE: http://www.kryslix.com/nsfaq/Q.12.html
|
||||
|
||||
Subject: What protocol do mice use?
|
||||
@@ -16,6 +19,7 @@ can discriminate motion up to 50.8 inches/second while a 400 CPI mouse
|
||||
can only discriminate motion up to 12.7 inches/second.
|
||||
Pinout
|
||||
|
||||
```
|
||||
9 pin 25 pin Line Comments
|
||||
shell 1 GND
|
||||
3 2 TD Serial data from host to mouse (only for power)
|
||||
@@ -25,6 +29,7 @@ shell 1 GND
|
||||
6 6 DSR
|
||||
5 7 SGND
|
||||
4 20 DTR Positive voltage to mouse and reset/detection
|
||||
```
|
||||
|
||||
RTS = Request to Send CTS = Clear to Send
|
||||
DSR = Data Set Ready DTR = Data Terminal Ready
|
||||
@@ -45,11 +50,13 @@ Data packet format:
|
||||
Data is sent in 3 byte packets for each event (a button is pressed or
|
||||
released or the mouse moves):
|
||||
|
||||
```
|
||||
D7 D6 D5 D4 D3 D2 D1 D0
|
||||
|
||||
Byte 1 X 1 LB RB Y7 Y6 X7 X6
|
||||
Byte 2 X 0 X5 X4 X3 X2 X1 X0
|
||||
Byte 3 X 0 Y5 Y4 Y3 Y2 Y1 Y0
|
||||
```
|
||||
|
||||
LB is the state of the left button (1 means down)
|
||||
RB is the state of the right button (1 means down)
|
||||
@@ -60,6 +67,7 @@ The high order bit of each byte (D7) is ignored. Bit D6 indicates the start of a
|
||||
|
||||
Graphical representation of a packet
|
||||
|
||||
```
|
||||
1st byte 2nd byte 3rd byte
|
||||
================ =============== ================
|
||||
- 1 ? ? Y Y X X - 0 X X X X X X - 0 Y Y Y Y Y Y
|
||||
@@ -73,6 +81,7 @@ Graphical representation of a packet
|
||||
| | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
|
||||
Left Button --/ | ================ =================
|
||||
Right Button ----/ X increment Y increment
|
||||
```
|
||||
|
||||
3 Button Logitech extension
|
||||
|
||||
@@ -82,14 +91,16 @@ packet after it is released). If a 4th byte is encountered (i.e., an
|
||||
extra byte with D6 set to 0) then D5 of that byte (0x20) indicates the
|
||||
status of the middle mouse button.
|
||||
|
||||
|
||||
Mouse systems mouse
|
||||
-------------------
|
||||
|
||||
Serial data parameters:
|
||||
|
||||
1200bps, 8 databits, 1 stop-bit
|
||||
|
||||
5 byte Mouse Systems packet
|
||||
|
||||
```
|
||||
D7 D6 D5 D4 D3 D2 D1 D0
|
||||
|
||||
Byte 1 1 0 0 0 0 LB CB RB
|
||||
@@ -97,6 +108,7 @@ Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
|
||||
Byte 3 Y7 Y6 Y5 Y4 Y3 Y4 Y1 Y0
|
||||
Byte 4 X7' X6' X5' X4' X3' X2' X1' X0'
|
||||
Byte 5 Y7' Y6' Y5' Y4' Y3' Y4' Y1' Y0'
|
||||
```
|
||||
|
||||
LB is left button state (0=pressed, 1=released)
|
||||
CB is center button state (0=pressed, 1=released)
|
||||
@@ -124,8 +136,10 @@ inch. The maximum tracking rate for PS/2 mouse is 40 reports/second *
|
||||
discriminate motion up to 102 inches per second while a 400 CPI mouse
|
||||
could discriminate motion up to 25.2 inches per second.
|
||||
|
||||
Connector pinout
|
||||
|
||||
Connector pinout
|
||||
----------------
|
||||
```
|
||||
Pin Wire Name
|
||||
1 DATA
|
||||
2 Reserved
|
||||
@@ -134,9 +148,11 @@ Pin Wire Name
|
||||
5 CLK
|
||||
6 Reserved
|
||||
Shield Chassis
|
||||
```
|
||||
|
||||
Packet Format
|
||||
|
||||
-------------
|
||||
```
|
||||
D7 D6 D5 D4 D3 D2 D1 D0
|
||||
Byte 1 XV XV YS XS 1 M R L
|
||||
Byte 2 X7 X6 X5 X4 X3 X2 X1 X0
|
||||
@@ -149,12 +165,15 @@ X0-X7 Movement in X direction
|
||||
Y0-Y7 Movement in Y direction
|
||||
XS,YS Movement data sign bits (1 = negative)
|
||||
XV,YV Movement data overflow bits (1 = overflow has occured)
|
||||
```
|
||||
|
||||
Physical connector
|
||||
------------------
|
||||
|
||||
The PS/2 mouse connector has the following pinout when looking at the
|
||||
connector on the back of the computer:
|
||||
|
||||
```
|
||||
4 u 6
|
||||
1 . 2
|
||||
3 5
|
||||
@@ -165,6 +184,7 @@ connector on the back of the computer:
|
||||
4. CLOCK
|
||||
5. Not used
|
||||
6. Not used
|
||||
```
|
||||
|
||||
Bi-directional transmission is controlled by the CLK and DATA lines. Both
|
||||
are fed by an open collector device which lets either host or mouse force
|
||||
@@ -1,3 +1,6 @@
|
||||
Shell
|
||||
=====
|
||||
|
||||
This directory contains a shell user extension
|
||||
primary features:
|
||||
|
||||
@@ -1,10 +1,7 @@
|
||||
#
|
||||
#
|
||||
# untar information
|
||||
#
|
||||
# Author: Jake Janovetz 7.6.1999
|
||||
#
|
||||
untar
|
||||
=====
|
||||
|
||||
Author: Jake Janovetz 7.6.1999
|
||||
untar.c contains two procedures for extracting files from a UNIX
|
||||
tar file:
|
||||
|
||||
@@ -21,4 +18,3 @@ file. The fully qualified filename is passed through char *tar_name.
|
||||
|
||||
|
||||
BUGS: Please email janovetz@uiuc.edu
|
||||
-----
|
||||
@@ -1,4 +1,5 @@
|
||||
|
||||
utf8proc
|
||||
========
|
||||
Please read the LICENSE file, which is shipping with this software.
|
||||
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
uuid
|
||||
====
|
||||
|
||||
uuid - DCE compatible Universally Unique Identifier library
|
||||
|
||||
The UUID library is used to generate unique identifiers for objects that may be
|
||||
@@ -1,4 +1,5 @@
|
||||
PCI Library
|
||||
===========
|
||||
|
||||
LIBPCI is documented in the ../../doc directory, see ../../doc/README how
|
||||
to build documentation.
|
||||
@@ -1,3 +1,6 @@
|
||||
SPARC
|
||||
=====
|
||||
|
||||
This file discusses SPARC specific issues which are important to
|
||||
this port. The primary topics in this file are:
|
||||
|
||||
@@ -7,7 +10,7 @@ this port. The primary topics in this file are:
|
||||
|
||||
|
||||
Global Register Usage
|
||||
=====================
|
||||
---------------------
|
||||
|
||||
This information on register usage is based heavily on a comment in the
|
||||
file gcc-2.7.0/config/sparc/sparc.h in the the gcc 2.7.0 source.
|
||||
@@ -36,13 +39,13 @@ operating system, RTEMS does not assume any special use for them.
|
||||
|
||||
|
||||
Stack Frame
|
||||
===========
|
||||
-----------
|
||||
|
||||
The stack grows downward (i.e. to lower addresses) on the SPARC architecture.
|
||||
|
||||
The following is the organization of the stack frame:
|
||||
|
||||
|
||||
```
|
||||
|
||||
| ............... |
|
||||
fp | |
|
||||
@@ -74,7 +77,7 @@ The following is the organization of the stack frame:
|
||||
| input register set | * 32 bytes
|
||||
| | *
|
||||
sp +-------------------------------+ *
|
||||
|
||||
```
|
||||
|
||||
* = minimal stack frame
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
SPARC64
|
||||
=======
|
||||
|
||||
A lot of explanation needed, will do when known.
|
||||
|
||||
The score/cpu/sparc64 contains only code that can execute without accessing
|
||||
@@ -1,3 +1,6 @@
|
||||
telnetd
|
||||
=======
|
||||
|
||||
Author: Fernando Ruiz Casas <fruizcasas@gmail.com>
|
||||
|
||||
This directory contains a telnetd server with the primary features:
|
||||
Reference in New Issue
Block a user