diff options
Diffstat (limited to 'doc/develenv')
| -rw-r--r-- | doc/develenv/Makefile.am | 37 | ||||
| -rw-r--r-- | doc/develenv/develenv.texi | 105 | ||||
| -rw-r--r-- | doc/develenv/direct.t | 689 | ||||
| -rw-r--r-- | doc/develenv/intro.texi | 53 | ||||
| -rw-r--r-- | doc/develenv/sample.t | 464 | ||||
| -rw-r--r-- | doc/develenv/stamp-vti | 4 | ||||
| -rw-r--r-- | doc/develenv/utils.t | 182 | ||||
| -rw-r--r-- | doc/develenv/version.texi | 4 |
8 files changed, 0 insertions, 1538 deletions
diff --git a/doc/develenv/Makefile.am b/doc/develenv/Makefile.am deleted file mode 100644 index 041818507b..0000000000 --- a/doc/develenv/Makefile.am +++ /dev/null @@ -1,37 +0,0 @@ -# -# COPYRIGHT (c) 1988-2002. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. - -PROJECT = develenv - -include $(top_srcdir)/project.am -include $(top_srcdir)/main.am - -FILES = direct.texi intro.texi sample.texi utils.texi - -GENERATED_FILES = direct.texi sample.texi utils.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi - -info_TEXINFOS = develenv.texi -develenv_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -direct.texi: direct.t - $(BMENU2) -p "Introduction" \ - -u "Top" \ - -n "Sample Applications" < $< > $@ - -sample.texi: sample.t - $(BMENU2) -p "Directory Structure Documentation Directory" \ - -u "Top" \ - -n "RTEMS Specific Utilities" < $< > $@ - -utils.texi: utils.t - $(BMENU2) -p "Sample Applications Network Loopback Test" \ - -u "Top" \ - -n "Command and Variable Index" < $< > $@ - -CLEANFILES += develenv.info - -EXTRA_DIST = direct.t sample.t utils.t diff --git a/doc/develenv/develenv.texi b/doc/develenv/develenv.texi deleted file mode 100644 index c6d5cdb664..0000000000 --- a/doc/develenv/develenv.texi +++ /dev/null @@ -1,105 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename develenv.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1989-2013. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@c -@c Master file -@c - -@c Joel's Questions -@c -@c 1. Why does paragraphindent only impact makeinfo? -@c 2. Why does paragraphindent show up in HTML? -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS On-Line Manual -@direntry -* RTEMS Development Environment Guide: (develenv). -@end direntry -@end ifset - - -@c variable substitution info: -@c -@c @set LANGUAGE C -@c the language is @value{LANGUAGE} -@c NOTE: don't use underscore in the name -@c - -@c -@c Title Page Stuff -@c - -@c -@c I don't really like having a short title page. --joel -@c -@c @shorttitlepage RTEMS Development Environment Guide - -@setchapternewpage odd -@settitle RTEMS Development Environment Guide -@titlepage -@finalout - -@title RTEMS Development Environment Guide -@subtitle Edition @value{EDITION}, for RTEMS @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@contents - -@ifnottex -@node Top, Introduction, (dir), (dir) -@top RTEMS Development Environment Guide - -@menu -* Introduction:: -* Directory Structure:: -* Sample Applications:: -* RTEMS Specific Utilities:: -* Command and Variable Index:: -* Concept Index:: -@end menu -@end ifnottex - -@include intro.texi -@include direct.texi -@include sample.texi -@include utils.texi - -@node Command and Variable Index, Concept Index, RTEMS Specific Utilities unhex - Convert Hexadecimal File into Binary Equivalent, Top -@unnumbered Command and Variable Index - -There are currently no Command and Variable Index entries. - -@c @printindex fn - -@node Concept Index, , Command and Variable Index, Top -@unnumbered Concept Index - -There are currently no Concept Index entries. -@c @printindex cp - -@bye - diff --git a/doc/develenv/direct.t b/doc/develenv/direct.t deleted file mode 100644 index 9950b69274..0000000000 --- a/doc/develenv/direct.t +++ /dev/null @@ -1,689 +0,0 @@ -@c -@c COPYRIGHT (c) 1989-2010. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Directory Structure - -The RTEMS directory structure is designed to meet -the following requirements: - -@itemize @bullet -@item encourage development of modular components. - -@item isolate processor and target dependent code, while -allowing as much common source code as possible to be shared -across multiple processors and target boards. - -@item allow multiple RTEMS users to perform simultaneous -compilation of RTEMS and its support facilities for different -processors and targets. -@end itemize - -The resulting directory structure has processor and -board dependent source files isolated from generic files. When -RTEMS is configured and built, object directories and -an install point will be automatically created based upon -the target CPU family and BSP selected. - -The placement of object files based upon the selected BSP name -ensures that object files are not mixed across CPUs or targets. -This in combination with the makefiles allows the specific -compilation options to be tailored for a particular target -board. For example, the efficiency of the memory subsystem for -a particular target board may be sensitive to the alignment of -data structures, while on another target board with the same -processor memory may be very limited. For the first target, the -options could specify very strict alignment requirements, while -on the second the data structures could be @i{packed} to conserve -memory. It is impossible to achieve this degree of flexibility -without providing source code. - -The RTEMS source tree is organized based on the following variables: - -@itemize @bullet - -@item functionality, -@item target processor family, -@item target processor model, -@item peripherals, and -@item target board. - -@end itemize - -Each of the following sections will describe the -contents of the directories in the RTEMS source -tree. The top of the tree will be referenced -as @code{$@{RTEMS_ROOT@}} in this discussion. - -@c -@c Top Level Tree -@c - -@c @ifset use-ascii -@example -@group - rtems-VERSION - | - +--------+----+----+----+--+-----+---+-------+--------+ - | | | | | | | | | -aclocal automake c contrib cpukit doc make testsuites tools -@end group -@end example -@c @end ifset - -@ifset use-tex -@end ifset - -@ifset use-html -@html -@end html -@end ifset - -@table @code -@item $@{RTEMS_ROOT@}/aclocal/ -This directory contains the custom M4 macros which are available to -the various GNU autoconf @code{configure.ac} scripts throughout -the RTEMS source tree. GNU autoconf interprets @code{configure.ac} -files to produce the @code{configure} files used to tailor -RTEMS build for a particular host and target environment. The -contents of this directory will not be discussed further in this -document. - -@item $@{RTEMS_ROOT@}/automake/ -This directory contains the custom GNU automake fragments -which are used to support the various @code{Makefile.am} -files throughout the RTEMS source tree. The -contents of this directory will not be discussed -further in this document. - -@item $@{RTEMS_ROOT@}/c/ -This directory is the root of the portions of the RTEMS source -tree which must be built tailored for a particular CPU model -or BSP. The contents of this directory will be discussed -in the @ref{Directory Structure c/ Directory} section. - -@item $@{RTEMS_ROOT@}/contrib/ -This directory contains contributed support software. Currently -this directory contains the RPM specifications for cross-compilers -hosted on GNU/Linux that target various operating systems -including MinGW, Cygwin, FreeBSD, and Solaris. The -cross-compilers produced using these specifications are then -used in a Canadian cross build procedure to produce the various -RTEMS toolsets on a GNU/Linux host. - -This directory also contains RPM specifications for the -prebuilt cross-compilation toolsets provided by the -RTEMS project. There are separate subdirectories -for each of the components in the RTEMS Cross Compilation -Environment unde the @code{contrib/crossrpms/} directory. -This directory is configured, built, and installed separately -from the RTEMS executive and tests. This directory will not -be discussed further in this document. - - -@item $@{RTEMS_ROOT@}/cpukit/ -This directory is the root for all of the "multilib'able" -portions of RTEMS. This is a GNU way of saying the -contents of this directory can be compiled like the -C Library (@code{libc.a}) and the functionality is -neither CPU model nor BSP specific. The source code -for most RTEMS services reside under this directory. -The contents of this directory will be discussed -in the @ref{Directory Structure CPU Kit Directory} section. - -@item $@{RTEMS_ROOT@}/doc/ -This directory is the root for all RTEMS documentation. -The source for RTEMS is written in GNU TeXinfo and -used to produce HTML, PDF, and "info" files. -The RTEMS documentation is configured, built, -and installed separately from the RTEMS executive and tests. -The contents of this directory will be discussed -in the @ref{Directory Structure Documentation Directory} section. - -@item $@{RTEMS_ROOT@}/make/ -This directory contains files which support the -RTEMS Makefile's. From a user's perspective, the -most important parts are found in the @code{custom/} -subdirectory. Each ".cfg" file in this directory -is associated with a specific BSP and describes -the CPU model, compiler flags, and procedure to -produce an executable for the target board. -These files are described in detail in the -@b{RTEMS BSP and Device Driver Development Guide} -and will not be discussed further in this document. - -@item $@{RTEMS_ROOT@}/testsuites/ -This directory contains the test suites for the -various RTEMS APIs and support libraries. The -contents of this directory are discussed in the -@ref{Directory Structure testsuites/ Test Suites} section. - -@item $@{RTEMS_ROOT@}/tools/ -This directory contains RTEMS specific support utilities which -execute on the development host. These utilities are divided -into subdirectories based upon whether they are used in the process -of building RTEMS and applications, are CPU specific, or are -used to assist in updating the RTEMS source tree and applications. -The support utilities used in the process of building RTEMS are -described in @ref{RTEMS Specific Utilities}. These are the -only components of this subtree that will be discussed in this -document. - -@end table - - - -@c -@c c/ Directions -@c -@section c/ Directory - -The @code{$@{RTEMS_ROOT@}/c/} directory was formerly -the root directory of all RTEMS source code. At this time, it contains -the root directory for only those RTEMS components -which must be compiled or linked in a way that is specific to a -particular CPU model or board. This directory contains the -following subdirectories: - -@table @code -@item $@{RTEMS_ROOT@}/c/src/ -This directory is logically the root for the RTEMS components -which are CPU model or board dependent. Thus this directory -is the root for the BSPs and the Ada Test Suites as well -as CPU model and BSP dependent libraries. The contents of -this directory are discussed in the -@ref{Directory Structure c/src/ Directory} section. -@end table - -@c -@c c/src/ Directory -@c -@subsection c/src/ Directory - -As mentioned previously, this directory is logically -the root for the RTEMS components -which are CPU model or board dependent. The -following is a list of the subdirectories in this -directory and a description of each. - -@table @code -@item $@{RTEMS_ROOT@}/c/src/aclocal/ -This directory contains the custom M4 macros which are available to -the various GNU autoconf @code{configure.ac} scripts throughout -this portion of the RTEMS source tree. GNU autoconf interprets -@code{configure.ac} files to produce the @code{configure} files used -to tailor RTEMS build for a particular host and target environment. The -contents of this directory will not be discussed further in this -document. - -@item $@{RTEMS_ROOT@}/c/src/ada/ -This directory contains the Ada95 language bindings to the -RTEMS Classic API. - -@item $@{RTEMS_ROOT@}/c/src/ada-tests/ -This directory contains the test suite for the Ada -language bindings to the Classic API. - -@item $@{RTEMS_ROOT@}/c/src/automake/ -This directory contains files which are "Makefile fragments." -They are included as required by the various @code{Makefile.am} -files throughout this portion of the RTEMS source tree. - -@item $@{RTEMS_ROOT@}/c/src/lib/ -This directory contains the directories @code{libbsp/} -and @code{libcpu/} which contain the source code for -the Board Support Packages (BSPs) and CPU Model -specific source code for RTEMS. - -The @code{libbsp/} is organized based upon the CPU -family and boards BSPs. The contents of @code{libbsp/} -are discussed briefly in -@ref{Directory Structure c/src/lib/libbsp BSP Directory} -and presented in detail in the -@b{RTEMS BSP and Device Driver Development Guide}. - -The @code{libcpu/} directory is also organized by -CPU family with further divisions based upon CPU -model and features that are shared across CPU models -such as caching and DMA. - -@item $@{RTEMS_ROOT@}/c/src/libchip/ -This directory contains device drivers for various -peripheral chips which are designed to be CPU and -board dependent. This directory contains a variety -of drivers for serial devices, network interface -controllers, shared memory and real-time clocks. - -@item $@{RTEMS_ROOT@}/c/src/librtems++/ -This directory contains C++ classes which map to the RTEMS -Classic API. - -@item $@{RTEMS_ROOT@}/c/src/make/ -This directory is used to generate the bulk of the supporting -rules files which are installed as part of the Application Makefiles. -This file contains settings for various Makefile variables to -tailor them to the particular CPU model and BSP configured. - -@item $@{RTEMS_ROOT@}/c/src/nfsclient/ -This directory contains a Network File System (NFS) client -for RTEMS. With this file system, a user's application can -access files on a remote computer. - -@item $@{RTEMS_ROOT@}/c/src/optman/ -This directory contains stubs for the RTEMS Classic API -Managers which are considered optional and whose use -may be explicitly forbidden by an application. All of the -directive implementations in this Optional Managers -return @code{E_NOTCONFIGURED}. - -@item $@{RTEMS_ROOT@}/c/src/support/ -This directory exists solely to generate the RTEMS -version string which includes the RTEMS version, -CPU architecture, CPU model, and BSP name. - -@item $@{RTEMS_ROOT@}/c/src/wrapup/ -This directory is responsible for taking the individual -libraries and objects built in each of the components -in the RTEMS source tree and bundling them together to form -the single RTEMS library @code{librtemsbsp.a}. This -library contains all BSP and CPU model specific software. - -@end table - -@c -@c c/src/lib/libbsp BSP Directory -@c - -@subsubsection c/src/lib/libbsp BSP Directory - -The "libbsp" directory contains a directory for each CPU family supported -by RTEMS. Beneath each CPU directory is a directory for each BSP for that -processor family. - -@c -@c Tree 7 - C BSP Library -@c - -The "libbsp" directory provides all the BSPs provided with this -release of the RTEMS executive. The subdirectories are -divided, as discussed previously, based on specific processor -family, then further broken down into specific target board -environments. The "no_cpu" subdirectory provides a starting point -template BSP which can be used to develop a specific BSP for an -unsupported target board. The files in this subdirectory may aid -in preliminary testing of the RTEMS development environment that has -been built for no particular target in mind. - -Below each CPU dependent directory is a directory for each target BSP -supported in this release. - -Each BSP provides the modules which comprise an RTEMS BSP. The -modules are separated into the subdirectories "clock", "console", -"include", "shmsupp", "startup", and "timer" as shown in the following -figure: - -@c -@c Tree 8 - Each BSP -@c - -@c @ifset use-ascii -@example -@group - Each BSP - | - +-----------+----------+-----+-----+----------+----------+ - | | | | | | -clock console include shmsupp startup timer -@end group -@end example -@c @end ifset - -@c -@c CPU Kit Directory -@c -@section CPU Kit Directory - -@c The @code{cpukit/} directory structure is as follows: - -@c -@c CPU Kit Tree -@c - -@c @ifset use-ascii -@c @example -@c @group -@c cpukit -@c | -@c +-----------+----------+-----------+----------+ -@c | | | | | -@c posix rtems sapi score wrapup -@c @end group -@c @end example -@c @end ifset - -The @code{cpukit/} directory contains a set of subdirectories which -contains the source files comprising the executive portion of -the RTEMS development environment as well as portable support -libraries such as support for the C Library and filesystems. -The API specific and "SuperCore" (e.g. @code{score/} directory) -source code files are separated into distinct directory trees. - -The following is a description of each of the subdirectories -under @code{cpukit/}: - -@table @code - -@item $@{RTEMS_ROOT@}/cpukit/aclocal/ -This directory contains the custom M4 macros which are available to -the various GNU autoconf @code{configure.ac} scripts throughout -the CPU Kit portion of the RTEMS source tree. -GNU autoconf interprets @code{configure.ac} -files to produce the @code{configure} files used to tailor -RTEMS build for a particular host and target environment. The -contents of this directory will not be discussed further in this -document. - -@item $@{RTEMS_ROOT@}/cpukit/automake/ -This directory contains files which are "Makefile fragments." -They are included as required by the various @code{Makefile.am} -files throughout the CPU Kit portion of the RTEMS source tree. - -@item $@{RTEMS_ROOT@}/cpukit/ftpd/ -This directory contains the RTEMS ftpd server. - -@item $@{RTEMS_ROOT@}/cpukit/httpd/ -This directory contains the port of the GoAhead -web server to RTEMS. - -@item $@{RTEMS_ROOT@}/cpukit/include/ -This directory contains header files which are private to -RTEMS and not considered to be owned by any other component -in the CPU Kit. - -@item $@{RTEMS_ROOT@}/cpukit/libblock/ -This directory contains support code for using -Block Devices such as hard drives, floppies, and -CD-ROMs. It includes the generic IO primitives -for block device drivers, disk caching support, -and a RAM disk block device driver. - -@item $@{RTEMS_ROOT@}/cpukit/libcsupport/ -This directory contains the RTEMS specific support routines -for the Newlib C Library. This includes what are referred -to as system calls and found in section 2 of the traditional -UNIX manual. In addition, it contains a thread-safe -implementation of the Malloc family of routines as well -as BSD and POSIX services not found in Newlib. - -@item $@{RTEMS_ROOT@}/cpukit/libfs/ -This directory contains the various non-networked -filesystem implementations for RTEMS. It includes -the In-Memory FileSystem (IMFS), the mini-IMFS, -and FAT filesystems. - -@item $@{RTEMS_ROOT@}/cpukit/libi2c/ -This directory contains the RTEMS I2C framework. - -@item $@{RTEMS_ROOT@}/cpukit/libmd/ -This directory contains a port of the standard MD5 -checksum code. - -@item $@{RTEMS_ROOT@}/c/src/libmisc/ -This directory contains support facilities which -are RTEMS specific but otherwise unclassified. In -general, they do not adhere to a standard API. -Among the support facilities in this directory are -a @code{/dev/null} device driver, the Stack -Overflow Checker, a mini-shell, the CPU and -rate monotonic period usage monitoring libraries, -and a utility to "dump a buffer" in a nicely -formatted way similar to many ROM monitors. - -@item $@{RTEMS_ROOT@}/cpukit/libnetworking/ -This directory contains the port of the FreeBSD -TCP/IP stack to RTEMS. - -@item $@{RTEMS_ROOT@}/cpukit/librpc/ -This directory contains the port of the FreeBSD -RPC/XDR source to RTEMS. - -@item $@{RTEMS_ROOT@}/cpukit/libpci/ -This directory contains RTEMS PCI Library. - -@item $@{RTEMS_ROOT@}/cpukit/posix/ -This directory contains the RTEMS implementation -of the threading portions of the POSIX API. - -@item $@{RTEMS_ROOT@}/cpukit/pppd/ -This directory contains a port of the free implementation -of the PPPD network protocol. - -@item $@{RTEMS_ROOT@}/cpukit/rtems/ -This directory contains the implementation of the -Classic API. - -@item $@{RTEMS_ROOT@}/cpukit/sapi/ -This directory contains the implementation of RTEMS -services which are required but beyond the realm -of any standardization efforts. It includes -initialization, shutdown, and IO services. - -@item $@{RTEMS_ROOT@}/cpukit/score/ -This directory contains the "SuperCore" of RTEMS. -All APIs are implemented in terms of SuperCore services. -For example, Classic API tasks and POSIX threads -are all implemented in terms of SuperCore threads. -This provides a common infrastructure and a high degree -of interoperability between the APIs. For example, -services from all APIs may be used by any task/thread -independent of the API used to create it. - -Within the @code{score/} directory the CPU dependent modules are found. -The @code{score/cpu/} subdirectory contains a subdirectory for each -target CPU supported by this release of the RTEMS -executive. Each processor directory contains the CPU dependent -code necessary to host RTEMS. The @code{no_cpu} directory provides a -starting point for developing a new port to an unsupported -processor. The files contained within the @code{no_cpu} directory -may also be used as a reference for the other ports to specific -processors. - -@item $@{RTEMS_ROOT@}/cpukit/shttpd/ -This directory contains the port of the Simple HTTPD -web server to RTEMS. - -@item $@{RTEMS_ROOT@}/cpukit/telnetd/ -This directory contains the RTEMS telnetd server. - -@item $@{RTEMS_ROOT@}/cpukit/wrapup/ -This directory is responsible for taking the individual -libraries and objects built in each of the components -in the RTEMS CPU Kit source tree and bundling them -together to form the single RTEMS library @code{librtemscpu.a}. This -library contains all BSP and CPU model specific software. - -@item $@{RTEMS_ROOT@}/cpukit/zlib/ -This directory contains a port of the GNU Zlib compression -library to RTEMS. - -@end table - -@c -@c testsuites/ Test Suites -@c -@section testsuites/ Test Suites - -This directory provides all of the RTEMS Test Suite -except those for the Classic API Ada95 binding -This includes the single processor tests, multiprocessor tests, -timing tests, library tests, and sample tests. Additionally, -subdirectories for support functions and test related header -files are provided. The following table lists the test suites -currently included with the RTEMS and the directory in which -they may be located: - -@table @code - -@item $@{RTEMS_ROOT@}/testsuites/libtests/ -This directory contains the test suite for the -various RTEMS support components. - -@item $@{RTEMS_ROOT@}/testsuites/mptests/ -This directory contains the test suite for the -multiprocessor support in the Classic API. -The tests provided address two node configurations -and provide coverage for the multiprocessor code found -in RTEMS. - -@item $@{RTEMS_ROOT@}/testsuites/psxtests/ -This directory contains the test suite for the -RTEMS POSIX API. - -@item $@{RTEMS_ROOT@}/testsuites/samples/ -This directory provides sample application tests -which aid in the testing a newly built RTEMS environment, a new -BSP, or as starting points for the development of an application -using the RTEMS executive. They are discussed in -@ref{Sample Applications}. - -@item $@{RTEMS_ROOT@}/testsuites/sptests/ -This directory contains the test suite for the RTEMS -Classic API when executing on a single processor. -The tests were originally designed to provide -near complete test coverage for the entire -executive code. With the addition of multiple APIs, -this is no longer the case as some SuperCore functionality -is not available through the Classic API. Thus -some functionality in the SuperCore is only covered -by tests in the POSIX API Test Suites. - -@item $@{RTEMS_ROOT@}/testsuites/support/ -This directory contains support software and header files -for the various test suites. - -@item $@{RTEMS_ROOT@}/testsuites/tmtests/ -This directory contains the timing test suite for -the RTEMS Classic API. This include tests that -benchmark each directive in the Classic API -as well as a set of critical SuperCore functions. -These tests are important for helping to verify -that RTEMS performs as expected on your target hardware. -It is not uncommon to discover mistakes in board -initialization such as caching being disabled as -a side-effect of analyzing the results of these tests. - -@item $@{RTEMS_ROOT@}/testsuites/tools/ -This directory contains tools which execute on -the development host and aid in executing and -evaluating the results of the test suite. The -tools @code{difftest} compares the output of one -or more tests with the expected output. If you -place the output of all the @code{tmtests/} in -a single file, then the utility @code{sorttimes} -will be able to produce a report organizing the -execution times by manager. - -@end table - - -@c -@c Documentation Directory -@c -@section Documentation Directory - -This directory contains the source code for all RTEMS documentation -in @code{TexInfo} format as well as utilities used in the generation -of the RTEMS documentation set. This source code is used to produce -the RTEMS documentation in various formats including PDF, HTML, -and PostScript. - -@table @code - -@item $@{RTEMS_ROOT@}/doc/ada_user/ -This directory contains the source code for the @cite{RTEMS -Applications Ada User's Guide} which documents the Ada95 -binding to the Classic API. This manual is produced from -from the same source base as the @cite{RTEMS Application -C User's Guide}. - -@item $@{RTEMS_ROOT@}/doc/bsp_howto/ -This directory contains the source code for the -@cite{RTEMS BSP and Device Driver Development Guide}. - -@item $@{RTEMS_ROOT@}/doc/common/ -This directory contains the source code for the files which -are shared across multiple manuals in the RTEMS Documentation Set. -This includes the copyright page as well as the timing -tables which can be filled in on a per BSP basis in the -CPU supplements. - -@item $@{RTEMS_ROOT@}/doc/cpu_supplement/ -This directory contains the source code for the -RTEMS CPU Supplement. - -@item $@{RTEMS_ROOT@}/doc/develenv/ -This directory contains the source code for the -@cite{RTEMS Development Environment Guide}. This is -the document you are currently reading. - -@item $@{RTEMS_ROOT@}/doc/filesystem/ -This directory contains the source code for the -@cite{RTEMS Filesystem Design Guide}. This manual -is a continuous work in process as it attempts to -capture the design of the interface between system -calls and filesystem implementations as well as the -information required by those implementing filesystems. - -@item $@{RTEMS_ROOT@}/doc/images/ -This directory contains the source code for the graphics -used in the HTML version of the RTEMS Documentation. - -@item $@{RTEMS_ROOT@}/doc/networking/ -This directory contains the source code for the -@cite{RTEMS Network Supplement}. - -@item $@{RTEMS_ROOT@}/doc/new_chapters/ -This directory contains the source code for the new documentation -components which have not yet been collected into a new manual or -merged into an existing document. Currently, this primarily -contains draft documentation for some portions of -the facilities implemented in @code{$@{RTEMS_ROOT@}/c/src/libmisc/}. - -@item $@{RTEMS_ROOT@}/doc/porting/ -This directory contains the source code for the -@cite{RTEMS Porting Guide}. - -@item $@{RTEMS_ROOT@}/doc/posix1003.1/ -This directory contains the source code for the -@cite{RTEMS POSIX 1003.1 Compliance Guide}. - -@item $@{RTEMS_ROOT@}/doc/posix_users/ -This directory contains the source code for the -@cite{RTEMS POSIX API User's Guide}. It is important to -note that RTEMS' support for POSIX is a combination of -functionality provided by RTEMS and the Newlib C Library -so some functionality is documented by Newlib. - -@item $@{RTEMS_ROOT@}/doc/relnotes/ -This directory contains the source code for a formally -release notes document. This has not been used for -recent RTEMS releases. - -@item $@{RTEMS_ROOT@}/doc/started/ -This directory contains the source code for the -@cite{Getting Started with RTEMS for C/C++ Users} manual. - -@item $@{RTEMS_ROOT@}/doc/tools/ -This directory contains the source code for the tools -used on the development host to assist in producing the -RTEMS Documentation. The most important of these tools -is @code{bmenu} which generates the hierarchical node -linking commands based upon chapter, section, and -subsection organization. - -@item $@{RTEMS_ROOT@}/doc/user/ -This directory contains the source code for the @cite{RTEMS -Applications C User's Guide} which documents the Classic API. - -@end table diff --git a/doc/develenv/intro.texi b/doc/develenv/intro.texi deleted file mode 100644 index 695b37108e..0000000000 --- a/doc/develenv/intro.texi +++ /dev/null @@ -1,53 +0,0 @@ -@c -@c COPYRIGHT (c) 1989-2011. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@node Introduction, Directory Structure, Top, Top -@chapter Introduction - -This document describes the RTEMS development -environment. Discussions are provided for the following topics: - -@itemize @bullet -@item the directory structure used by RTEMS, - -@item usage of the GNU Make utility within the RTEMS -development environment, - -@item sample applications, and - -@item the RTEMS specific utilities. -@end itemize - -RTEMS was designed as a reusable software component. -Highly reusable software such as RTEMS is typically distributed -in the form of source code without providing any support tools. -RTEMS is the foundation for a complex family of facilities -including board support packages, device drivers, and support -libraries. The RTEMS Development Environment is not a CASE -tool. It is a collection of tools designed to reduce the -complexity of using and enhancing the RTEMS family. Tools are -provided which aid in the management of the development, -maintenance, and usage of RTEMS, its run-time support -facilities, and applications which utilize the executive. - -A key component of the RTEMS development environment -is the GNU family of free tools. This is robust set of -development and POSIX compatible tools for which source code is -freely available. The primary compilers, assemblers, linkers, -and make utility used by the RTEMS development team are the GNU -tools. They are highly portable supporting a wide variety of -host computers and, in the case of the development tools, a wide -variety of target processors. - -It is recommended that the RTEMS developer become -familiar with the RTEMS Development Environment before -proceeding with any modifications to the executive source tree. -The source code for the executive is very modular and source -code is divided amongst directories based upon functionality as -well as dependencies on CPU and target board. This organization -is aimed at isolating and minimizing non-portable code. This -has the immediate result that adding support for a new CPU or -target board requires very little "wandering" around the source -tree. diff --git a/doc/develenv/sample.t b/doc/develenv/sample.t deleted file mode 100644 index 68a3de285b..0000000000 --- a/doc/develenv/sample.t +++ /dev/null @@ -1,464 +0,0 @@ -@c -@c COPYRIGHT (c) 1989-2007. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Sample Applications - -@section Introduction - -The RTEMS source distribution includes a set of sample applications -that are located in the @code{$@{RTEMS_ROOT@}/testsuites/samples/} -directory. These applications are intended to illustrate the -basic format of RTEMS single and multiple processor -applications and the use of some features. In addition, these -relatively simple applications can be used to test locally -developed board support packages and device drivers as they -exercise a critical subset of RTEMS functionality that is often -broken in new BSPs. - -Some of the following sample applications will be covered in -more detail in subsequent sections: - -@table @b -@item Hello World -The RTEMS Hello World test is provided in -the subdirectory @code{$@{RTEMS_ROOT@}/testsuites/samples/hello/}. -This test is helpful when testing new RTEMS development environment. - -@item Clock Tick -The @code{$@{RTEMS_ROOT@}/testsuites/samples/ticker/} -subdirectory provides a test for verification of clock chip -device drivers of BSPs. - -@item Base Single Processor -A simple single processor test similar to those in the -single processor test suite is provided in -@code{$@{RTEMS_ROOT@}/testsuites/samples/base_sp/}. - -@item Base Multiple Processor -A simple two node multiprocessor test capable of testing an newly -developed MPCI layer is provided in -@code{$@{RTEMS_ROOT@}/testsuites/samples/base_mp/}. - -@item Capture -The RTEMS Capture test is provided in -the subdirectory @code{$@{RTEMS_ROOT@}/testsuites/samples/capture/}. -This is an interactive test which demonstrates the capabilities -of the RTEMS Capture Engine. It includes a few test threads -which generate interesting execution patterns. Look at the -file @code{$@{RTEMS_ROOT@}/testsuites/samples/capture/capture.scn} -for a sample session. - -@item Constructor/Destructor C++ Test -The @code{$@{RTEMS_ROOT@}/testsuites/samples/cdtest/} -subdirectory provides a simple C++ application using -constructors and destructors. It is only built when -C++ is enabled and its primary purpose is to demonstrate -that global constructors and destructors work. Since this -requires that the linker script for your BSP be correct, this is -an important test. - -@item File IO -The RTEMS File IO test is provided in -the subdirectory @code{$@{RTEMS_ROOT@}/testsuites/samples/fileio/}. -This is an interactive test which allows the user to interact with -an ATA/IDE device. It will read the partition table and allow the -user to dynamically mount one of the FAT32 partitions it finds. -Commands are also provided to write and read files on the disk. - -@item IO Stream -The RTEMS IO Stream test is provided in -the subdirectory @code{$@{RTEMS_ROOT@}/testsuites/samples/iostream/}. -This test is a simple C++ application which demonstrates that -C++ iostreams are functional. This requires that the RTEMS C++ -run-time support is functioning properly. This test is only -build when C++ is enabled. - -@item Network Loopback Test -The @code{$@{RTEMS_ROOT@}/testsuites/samples/loopback/} -directory contains a sample test that demonstrates the use of -sockets and the loopback network device. It does not require -the presence of network hardware in order to run. -It is only built if RTEMS was configured with networking enabled. - -@item Minimum Size Test -The directory -@code{$@{RTEMS_ROOT@}/testsuites/samples/minimum/} -contains a simple RTEMS program that results in a non-functional -executable. It is intended to show the size of a minimum footprint -application based upon the current RTEMS configuration. - -@item Nanoseconds -The RTEMS Nanoseconds test is provided in -the subdirectory @code{$@{RTEMS_ROOT@}/testsuites/samples/nsecs/}. -This test demonstrates that the BSP has support for nanosecond -timestamp granularity. It prints the time of day and uptime multiple -times as quickly as possible. It should be possible from the output -to determine if your BSP has nanosecond accurate clock support -and it is functional. - -@item Paranoia Floating Point Test -The directory @code{$@{RTEMS_ROOT@}/testsuites/samples/paranoia/} -contains the public domain floating point and math library test. - -@item Point-to-Point Protocol Daemon -The RTEMS Point-to-Point Protocol Daemon test is provided in -the subdirectory @code{$@{RTEMS_ROOT@}/testsuites/samples/pppd/}. -This test primarily serves as the baseline for a user application -using the PPP protocol. - -@item Unlimited Object Allocation -The @code{$@{RTEMS_ROOT@}/testsuites/samples/unlimited/} -directory contains a sample test that demonstrates the use of the -@i{unlimited} object allocation configuration option to RTEMS. - -@end table - -The sample tests are written using the Classic API so the reader -should be familiar with the terms used and -material presented in the @b{RTEMS Applications Users Guide}. - -@c -@c -@c -@section Hello World - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/hello/ -@end example - -It provides a rudimentary test of the BSP start up -code and the console output routine. The C version of this -sample application uses the printf function from the RTEMS -Standard C Library to output messages. The Ada version of this -sample uses the TEXT_IO package to output the hello messages. -The following messages are printed: - -@example -@group -*** HELLO WORLD TEST *** -Hello World -*** END OF HELLO WORLD TEST *** -@end group -@end example - -These messages are printed from the application's -single initialization task. If the above messages are not -printed correctly, then either the BSP start up code or the -console output routine is not operating properly. - -@c -@c -@c -@section Clock Tick - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/ticker/ -@end example - -This application is designed as a simple test of the -clock tick device driver. In addition, this application also -tests the printf function from the RTEMS Standard C Library by -using it to output the following messages: - -@example -@group -*** CLOCK TICK TEST *** -TA1 - tm_get - 09:00:00 12/31/1988 -TA2 - tm_get - 09:00:00 12/31/1988 -TA3 - tm_get - 09:00:00 12/31/1988 -TA1 - tm_get - 09:00:05 12/31/1988 -TA1 - tm_get - 09:00:10 12/31/1988 -TA2 - tm_get - 09:00:10 12/31/1988 -TA1 - tm_get - 09:00:15 12/31/1988 -TA3 - tm_get - 09:00:15 12/31/1988 -TA1 - tm_get - 09:00:20 12/31/1988 -TA2 - tm_get - 09:00:20 12/31/1988 -TA1 - tm_get - 09:00:25 12/31/1988 -TA1 - tm_get - 09:00:30 12/31/1988 -TA2 - tm_get - 09:00:30 12/31/1988 -TA3 - tm_get - 09:00:30 12/31/1988 -*** END OF CLOCK TICK TEST *** -@end group -@end example - -The clock tick sample application utilizes a single -initialization task and three copies of the single application -task. The initialization task prints the test herald, sets the -time and date, and creates and starts the three application -tasks before deleting itself. The three application tasks -generate the rest of the output. Every five seconds, one or -more of the tasks will print the current time obtained via the -tm_get directive. The first task, TA1, executes every five -seconds, the second task, TA2, every ten seconds, and the third -task, TA3, every fifteen seconds. If the time printed does not -match the above output, then the clock device driver is not -operating properly. - -@c -@c -@c -@section Base Single Processor Application - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/base_sp/ -@end example - -It provides a framework from which a single processor -RTEMS application can be developed. The use of the task argument -is illustrated. This sample application uses the printf -function from the RTEMS Standard C Library or TEXT_IO functions -when using the Ada version to output the following messages: - -@example -@group -*** SAMPLE SINGLE PROCESSOR APPLICATION *** -Creating and starting an application task -Application task was invoked with argument (0) and has id of 0x10002 -*** END OF SAMPLE SINGLE PROCESSOR APPLICATION *** -@end group -@end example - -The first two messages are printed from the -application's single initialization task. The final messages -are printed from the single application task. - -@c -@c -@c -@section Base Multiple Processor Application - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/base_mp/ -@end example - -It provides a framework from which a multiprocessor -RTEMS application can be developed. This directory has a -subdirectory for each node in the multiprocessor system. The -task argument is used to distinguish the node on which the -application task is executed. The first node will print the -following messages: - -@example -@group -*** SAMPLE MULTIPROCESSOR APPLICATION *** -Creating and starting an application task -This task was invoked with the node argument (1) -This task has the id of 0x10002 -*** END OF SAMPLE MULTIPROCESSOR APPLICATION *** -@end group -@end example - -The second node will print the following messages: - -@example -@group -*** SAMPLE MULTIPROCESSOR APPLICATION *** -Creating and starting an application task -This task was invoked with the node argument (2) -This task has the id of 0x20002 -*** END OF SAMPLE MULTIPROCESSOR APPLICATION *** -@end group -@end example - -The herald is printed from the application's single -initialization task on each node. The final messages are -printed from the single application task on each node. - -In this sample application, all source code is shared -between the nodes except for the node dependent configuration -files. These files contains the definition of the node number -used in the initialization of the RTEMS Multiprocessor -Configuration Table. This file is not shared because the node -number field in the RTEMS Multiprocessor Configuration Table -must be unique on each node. - -@c -@c -@c -@section Constructor/Destructor C++ Application - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/cdtest/ -@end example - -This sample application demonstrates that RTEMS is -compatible with C++ applications. It uses constructors, -destructor, and I/O stream output in testing these various -capabilities. The board support package responsible for this -application must support a C++ environment. - -This sample application uses the printf function from -the RTEMS Standard C Library to output the following messages: - -@example -@group -Hey I'M in base class constructor number 1 for 0x400010cc. -Hey I'M in base class constructor number 2 for 0x400010d4. -Hey I'M in derived class constructor number 3 for 0x400010d4. -*** CONSTRUCTOR/DESTRUCTOR TEST *** -Hey I'M in base class constructor number 4 for 0x4009ee08. -Hey I'M in base class constructor number 5 for 0x4009ee10. -Hey I'M in base class constructor number 6 for 0x4009ee18. -Hey I'M in base class constructor number 7 for 0x4009ee20. -Hey I'M in derived class constructor number 8 for 0x4009ee20. -Testing a C++ I/O stream -Hey I'M in derived class constructor number 8 for 0x4009ee20. -Derived class - Instantiation order 8 -Hey I'M in base class constructor number 7 for 0x4009ee20. -Instantiation order 8 -Hey I'M in base class constructor number 6 for 0x4009ee18. -Instantiation order 6 -Hey I'M in base class constructor number 5 for 0x4009ee10. -Instantiation order 5 -Hey I'M in base class constructor number 4 for 0x4009ee08. -Instantiation order 5 -*** END OF CONSTRUCTOR/DESTRUCTOR TEST *** -Hey I'M in base class constructor number 3 for 0x400010d4. -Hey I'M in base class constructor number 2 for 0x400010d4. -Hey I'M in base class constructor number 1 for 0x400010cc. -@end group -@end example - -@c -@c -@c -@section Minimum Size Test - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/minimum/ -@end example - -This sample application is designed to produce the -minimum code space required for any RTEMS application -based upon the current RTEMS configuration and -BSP. In many situations, the bulk of this executable -consists of hardware and RTEMS initialization, basic -infrastructure such as malloc(), and RTEMS and -hardware shutdown support. - -@c -@c -@c -@section Nanosecond Granularity Application - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/nsecs/ -@end example - -This sample application exercises the Clock Driver -for this BSP and demonstrates its ability to generate -accurate timestamps. This application does this by -exercising the time subsystem in three ways: - -@itemize @bullet -@item Obtain Time of Day Twice Back to Back -@item Obtain System Up Time Twice Back to Back -@item Use System Up Time to Measure Loops -@end itemize - -The following is an example of what the output of this -test may appear like: - -@example -*** NANOSECOND CLOCK TEST *** -10 iterations of getting TOD -Start: Sat Mar 24 11:15:00 2007:540000 -Stop : Sat Mar 24 11:15:00 2007:549000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:3974000 -Stop : Sat Mar 24 11:15:00 2007:3983000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:7510000 -Stop : Sat Mar 24 11:15:00 2007:7519000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:11054000 -Stop : Sat Mar 24 11:15:00 2007:11063000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:14638000 -Stop : Sat Mar 24 11:15:00 2007:14647000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:18301000 -Stop : Sat Mar 24 11:15:00 2007:18310000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:21901000 -Stop : Sat Mar 24 11:15:00 2007:21910000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:25526000 -Stop : Sat Mar 24 11:15:00 2007:25535000 --> 0:9000 -Start: Sat Mar 24 11:15:00 2007:29196000 -Stop : Sat Mar 24 11:15:00 2007:29206000 --> 0:10000 -Start: Sat Mar 24 11:15:00 2007:32826000 -Stop : Sat Mar 24 11:15:00 2007:32835000 --> 0:9000 - -10 iterations of getting Uptime -0:38977000 0:38986000 --> 0:9000 -0:40324000 0:40332000 --> 0:8000 -0:41636000 0:41645000 --> 0:9000 -0:42949000 0:42958000 --> 0:9000 -0:44295000 0:44304000 --> 0:9000 -0:45608000 0:45617000 --> 0:9000 -0:46921000 0:46930000 --> 0:9000 -0:48282000 0:48291000 --> 0:9000 -0:49595000 0:49603000 --> 0:8000 -0:50908000 0:50917000 --> 0:9000 - -10 iterations of getting Uptime with different loop values -loop of 10000 0:119488000 0:119704000 --> 0:216000 -loop of 20000 0:124028000 0:124463000 --> 0:435000 -loop of 30000 0:128567000 0:129220000 --> 0:653000 -loop of 40000 0:133097000 0:133964000 --> 0:867000 -loop of 50000 0:137643000 0:138728000 --> 0:1085000 -loop of 60000 0:142265000 0:143572000 --> 0:1307000 -loop of 70000 0:146894000 0:148416000 --> 0:1522000 -loop of 80000 0:151519000 0:153260000 --> 0:1741000 -loop of 90000 0:156145000 0:158099000 --> 0:1954000 -loop of 100000 0:160770000 0:162942000 --> 0:2172000 -*** END OF NANOSECOND CLOCK TEST *** -@end example - -@c -@c -@c -@section Paranoia Floating Point Application - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/paranoia/ -@end example - -This sample application uses a public domain floating -point and math library test to verify these capabilities of the -RTEMS executive. Deviations between actual and expected results -are reported to the screen. This is a very extensive test which -tests all mathematical and number conversion functions. -Paranoia is also very large and requires a long period of time -to run. Problems which commonly prevent this test from -executing to completion include stack overflow and FPU exception -handlers not installed. - -@c -@c -@c -@section Network Loopback Test - -This sample application is in the following directory: - -@example -$@{RTEMS_ROOT@}/testsuites/samples/loopback/ -@end example - -This sample application uses the network loopback device to -demonstrate the use of the RTEMS TCP/IP stack. This sample -test illustrates the basic configuration and initialization -of the TCP/IP stack as well as simple socket usage. - diff --git a/doc/develenv/stamp-vti b/doc/develenv/stamp-vti deleted file mode 100644 index 5634951ec8..0000000000 --- a/doc/develenv/stamp-vti +++ /dev/null @@ -1,4 +0,0 @@ -@set UPDATED 24 February 2013 -@set UPDATED-MONTH February 2013 -@set EDITION 4.10.99.0 -@set VERSION 4.10.99.0 diff --git a/doc/develenv/utils.t b/doc/develenv/utils.t deleted file mode 100644 index af50172230..0000000000 --- a/doc/develenv/utils.t +++ /dev/null @@ -1,182 +0,0 @@ -@c -@c COPYRIGHT (c) 1989-2007. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter RTEMS Specific Utilities - -This section describes the additional commands -available within the @b{RTEMS Development Environment}. Although -some of these commands are of general use, most are included to -provide some capability necessary to perform a required function -in the development of the RTEMS executive, one of its support -components, or an RTEMS based application. - -Some of the commands are implemented as C programs. -However, most commands are implemented as Bourne shell scripts. -Even if the current user has selected a different shell, the -scripts will automatically invoke the Bourne shell during their -execution lifetime. - -The commands are presented in UNIX manual page style -for compatibility and convenience. A standard set of paragraph -headers were used for all of the command descriptions. If a -section contained no data, the paragraph header was omitted to -conserve space. Each of the permissible paragraph headers and -their contents are described below: - -@table @code -@item SYNOPSIS -describes the command syntax - -@item DESCRIPTION -a full description of the command - -@item OPTIONS -describes each of the permissible options for the command - -@item NOTES -lists any special noteworthy comments about the command - -@item ENVIRONMENT -describes all environment variables utilized by the command - -@item EXAMPLES -illustrates the use of the command with specific examples - -@item FILES -provides a list of major files that the command references - -@item SEE ALSO -lists any relevant commands which can be consulted -@end table - -Most environment variables referenced by the commands -are defined for the RTEMS Development Environment during the -login procedure. During login, the user selects a default RTEMS -environment through the use of the Modules package. This tool -effectively sets the environment variables to provide a -consistent development environment for a specific user. -Additional environment variables within the RTEMS environment -were set by the system administrator during installation. When -specifying paths, a command description makes use of these -environment variables. - -When referencing other commands in the SEE ALSO -paragraph, the following notation is used: command(code). -Where command is the name of a related command, and code is a -section number. Valid section numbers are as follows: - -@table @code -@item 1 -Section 1 of the standard UNIX documentation - -@item 1G -Section 1 of the GNU documentation - -@item 1R -a manual page from this document, the RTEMS Development Environment Guide -@end table - -For example, ls(1) means see the standard ls command -in section 1 of the UNIX documentation. gcc020(1G) means see -the description of gcc020 in section 1 of the GNU documentation. - -@c -@c packhex -@c -@section packhex - Compress Hexadecimal File - -@subheading SYNOPSIS - -@example -packhex <source >destination -@end example - -@subheading DESCRIPTION - -packhex accepts Intel Hexadecimal or Motorola Srecord -on its standard input and attempts to pack as many contiguous -bytes as possible into a single hexadecimal record. Many -programs output hexadecimal records which are less than 80 bytes -long (for human viewing). The overhead required by each -unnecessary record is significant and packhex can often reduce -the size of the download image by 20%. packhex attempts to -output records which are as long as the hexadecimal format -allows. - -@subheading OPTIONS - -This command has no options. - -@subheading EXAMPLES - -Assume the current directory contains the Motorola -Srecord file download.sr. Then executing the command: - -@example -packhex <download.sr >packed.sr -@end example - -will generate the file packed.sr which is usually -smaller than download.sr. - -@subheading CREDITS - -The source for packhex first appeared in the May 1993 -issue of Embedded Systems magazine. The code was downloaded -from their BBS. Unfortunately, the author's name was not -provided in the listing. - -@c -@c unhex -@c -@section unhex - Convert Hexadecimal File into Binary Equivalent - -@subheading SYNOPSIS - -@example -unhex [-valF] [-o file] [file [file ...] ] -@end example - -@subheading DESCRIPTION - -unhex accepts Intel Hexadecimal, Motorola Srecord, or -TI 'B' records and converts them to their binary equivalent. -The output may sent to standout or may be placed in a specified -file with the -o option. The designated output file may not be -an input file. Multiple input files may be specified with their -outputs logically concatenated into the output file. - -@subheading OPTIONS - -This command has the following options: - -@table @code -@item v -Verbose - -@item a base -First byte of output corresponds with base -address - -@item l -Linear Output - -@item o file -Output File - -@item F k_bits -Fill holes in input with 0xFFs up to k_bits * 1024 bits -@end table - -@subheading EXAMPLES - -The following command will create a binary equivalent -file for the two Motorola S record files in the specified output -file binary.bin: - -@example -unhex -o binary.bin downloadA.sr downloadB.sr -@end example - diff --git a/doc/develenv/version.texi b/doc/develenv/version.texi deleted file mode 100644 index c0e4bbb7b6..0000000000 --- a/doc/develenv/version.texi +++ /dev/null @@ -1,4 +0,0 @@ -@set UPDATED 17 July 2015 -@set UPDATED-MONTH July 2015 -@set EDITION 4.10.99.0 -@set VERSION 4.10.99.0 |