mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2026-11-08 00:40:21 +08:00
2006-08-23 Joel Sherrill <joel@OARcorp.com>
* Makefile.am, configure.ac, index.html.in: FAQ should now be completely in the Wiki. * FAQ/.cvsignore, FAQ/FAQ.texi, FAQ/Makefile.am, FAQ/basic.t, FAQ/bsp.t, FAQ/build45.t, FAQ/concepts.t, FAQ/debug.t, FAQ/endoftime.t, FAQ/entry, FAQ/freesw.t, FAQ/hwdebugaids.t, FAQ/projects.t, FAQ/stamp-vti, FAQ/tools.t, FAQ/version.texi, common/timemac.texi, common/timetbl.t, common/timing.t: Removed.
This commit is contained in:
Joel Sherrill committed
1 parent
83fb86f32b
commit
d8f0aa16bc
23 files changed
+26
-3569
No files matched your search
@@ -1,3 +1,13 @@
|
||||
2006-08-23 Joel Sherrill <joel@OARcorp.com>
|
||||
|
||||
* Makefile.am, configure.ac, index.html.in: FAQ should now be
|
||||
completely in the Wiki.
|
||||
* FAQ/.cvsignore, FAQ/FAQ.texi, FAQ/Makefile.am, FAQ/basic.t,
|
||||
FAQ/bsp.t, FAQ/build45.t, FAQ/concepts.t, FAQ/debug.t,
|
||||
FAQ/endoftime.t, FAQ/entry, FAQ/freesw.t, FAQ/hwdebugaids.t,
|
||||
FAQ/projects.t, FAQ/stamp-vti, FAQ/tools.t, FAQ/version.texi,
|
||||
common/timemac.texi, common/timetbl.t, common/timing.t: Removed.
|
||||
|
||||
2006-08-23 Joel Sherrill <joel@OARcorp.com>
|
||||
|
||||
* Makefile.am, configure.ac, FAQ/stamp-vti, FAQ/version.texi,
|
||||
|
||||
@@ -1,23 +0,0 @@
|
||||
embeddedinfo.texi
|
||||
FAQ
|
||||
FAQ.aux
|
||||
FAQ.cp
|
||||
FAQ.dvi
|
||||
FAQ.fn
|
||||
FAQ*.html
|
||||
FAQ.ky
|
||||
FAQ.log
|
||||
FAQ.pdf
|
||||
FAQ.pg
|
||||
FAQ.ps
|
||||
FAQ.toc
|
||||
FAQ.tp
|
||||
FAQ.vr
|
||||
index.html
|
||||
Makefile
|
||||
Makefile.in
|
||||
mdate-sh
|
||||
rtems_footer.html
|
||||
rtems_header.html
|
||||
stamp-vti
|
||||
version.texi
|
||||
@@ -1,117 +0,0 @@
|
||||
\input texinfo @c -*-texinfo-*-
|
||||
@c %**start of header
|
||||
@setfilename FAQ.info
|
||||
@setcontentsaftertitlepage
|
||||
@syncodeindex vr fn
|
||||
@synindex ky cp
|
||||
@paragraphindent 0
|
||||
@c %**end of header
|
||||
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@c
|
||||
@c Master file for the RTEMS FAQ
|
||||
@c
|
||||
|
||||
@include version.texi
|
||||
@include common/setup.texi
|
||||
@include common/rtems.texi
|
||||
|
||||
@ifset use-ascii
|
||||
@dircategory RTEMS On-Line Manual
|
||||
@direntry
|
||||
* RTEMS FAQ: (FAQ). Frequently Asked Questions.
|
||||
@end direntry
|
||||
@end ifset
|
||||
|
||||
@c
|
||||
@c Title Page Stuff
|
||||
@c
|
||||
|
||||
@c
|
||||
@c I don't really like having a short title page. --joel
|
||||
@c
|
||||
@c @shorttitlepage RTEMS Frequently Asked Questions
|
||||
|
||||
@setchapternewpage odd
|
||||
@settitle RTEMS Frequently Asked Questions
|
||||
@titlepage
|
||||
@finalout
|
||||
|
||||
@title RTEMS Frequently Asked Questions
|
||||
@subtitle Edition @value{EDITION}, for @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.
|
||||
|
||||
@include basic.texi
|
||||
@include tools.texi
|
||||
@include concepts.texi
|
||||
@include build45.texi
|
||||
@include bsp.texi
|
||||
@include debug.texi
|
||||
@include freesw.texi
|
||||
@include hwdebugaids.texi
|
||||
@include projects.texi
|
||||
@include endoftime.texi
|
||||
|
||||
@ifinfo
|
||||
@node Top, Basic Information, (dir), (dir)
|
||||
@top FAQ
|
||||
|
||||
This document is the RTEMS FAQ. FAQ is an acronym for Frequently
|
||||
Asked Questions and we sincerely hope that this contains the answers
|
||||
to some of the questions most frequently asked about RTEMS.
|
||||
|
||||
Common questions have been divided into the following categories.
|
||||
|
||||
|
||||
@menu
|
||||
* Basic Information::
|
||||
* General Development Tool Hints::
|
||||
* RTEMS Concepts::
|
||||
* Building RTEMS::
|
||||
* BSP Questions::
|
||||
* Debugging Hints::
|
||||
* Free Software that Works with RTEMS::
|
||||
* Hardware to Ease Debugging::
|
||||
* RTEMS Projects::
|
||||
* Date/Time Issues in Systems Using RTEMS::
|
||||
@end menu
|
||||
|
||||
@c * Command and Variable Index::
|
||||
@c * Concept Index::
|
||||
@end ifinfo
|
||||
@c
|
||||
@c
|
||||
@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here
|
||||
@c
|
||||
|
||||
@c @node Command and Variable Index, Concept Index, Installing GCC AND NEWLIB, Top
|
||||
@c @unnumbered Command and Variable Index
|
||||
|
||||
@c There are currently no Command and Variable Index entries.
|
||||
|
||||
@c @printindex fn
|
||||
|
||||
@c @node Concept Index, , Command and Variable Index, Top
|
||||
@c @unnumbered Concept Index
|
||||
|
||||
@c There are currently no Concept Index entries.
|
||||
@c @printindex cp
|
||||
|
||||
@contents
|
||||
@bye
|
||||
|
||||
@@ -1,82 +0,0 @@
|
||||
#
|
||||
# COPYRIGHT (c) 1988-2002.
|
||||
# On-Line Applications Research Corporation (OAR).
|
||||
# All rights reserved.
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
PROJECT = FAQ
|
||||
EDITION = 1
|
||||
|
||||
include $(top_srcdir)/project.am
|
||||
include $(top_srcdir)/main.am
|
||||
|
||||
GENERATED_FILES = basic.texi tools.texi concepts.texi build45.texi bsp.texi \
|
||||
debug.texi freesw.texi hwdebugaids.texi projects.texi endoftime.texi
|
||||
|
||||
COMMON_FILES += $(top_srcdir)/common/cpright.texi
|
||||
|
||||
FILES =
|
||||
|
||||
info_TEXINFOS = FAQ.texi
|
||||
FAQ_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES)
|
||||
|
||||
#
|
||||
# Process Automatically Generated Files
|
||||
#
|
||||
|
||||
basic.texi: basic.t
|
||||
$(BMENU2) -c -p "Top" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
tools.texi: tools.t
|
||||
$(BMENU2) -c -p "Top" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
concepts.texi: concepts.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
build45.texi: build45.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
bsp.texi: bsp.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
debug.texi: debug.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
freesw.texi: freesw.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
hwdebugaids.texi: hwdebugaids.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
projects.texi: projects.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
endoftime.texi: endoftime.t
|
||||
$(BMENU2) -c -p "" \
|
||||
-u "Top" \
|
||||
-n "" < $< > $@
|
||||
|
||||
CLEANFILES += FAQ.info FAQ.info-?
|
||||
|
||||
EXTRA_DIST = entry basic.t bsp.t build45.t concepts.t debug.t endoftime.t \
|
||||
freesw.t hwdebugaids.t projects.t tools.t
|
||||
-196
@@ -1,196 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Basic Information
|
||||
|
||||
The questions in this category are basic questions about RTEMS. Where
|
||||
did it come from, why is it, what is it, when should you use it, etc.?
|
||||
|
||||
@section What does RTEMS stand for?
|
||||
|
||||
RTEMS is an an acronym for the Real-Time Executive for Multiprocessor
|
||||
Systems.
|
||||
|
||||
Initially RTEMS stood for the Real-Time Executive for Missile Systems
|
||||
but as it became clear that the application domains that could use
|
||||
RTEMS extended far beyond missiles, the "M" changed to mean Military.
|
||||
At one point, there were both Ada and C implementations of RTEMS. The
|
||||
C version changed the "M" to mean Multiprocessor while the Ada version
|
||||
remained with the "M" meaning Military.
|
||||
|
||||
@section What is RTEMS?
|
||||
|
||||
RTEMS is a real-time executive which provides a high performance
|
||||
environment for embedded military applications including many
|
||||
features. The following is just a short list of the features
|
||||
available in RTEMS. If you are interested in something that
|
||||
is not on this list, please contact the RTEMS Team. Features
|
||||
are being added continuously.
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item Standards Compliant
|
||||
@itemize @bullet
|
||||
@item POSIX 1003.1b API including threads
|
||||
@item RTEID/ORKID based Classic API
|
||||
@end itemize
|
||||
|
||||
@item TCP/IP Stack
|
||||
@itemize @bullet
|
||||
@item high performance port of FreeBSD TCP/IP stack
|
||||
@item UDP, TCP
|
||||
@item ICMP, DHCP, RARP
|
||||
@item TFTP
|
||||
@item RPC
|
||||
@item FTPD
|
||||
@item HTTPD
|
||||
@item CORBA
|
||||
@end itemize
|
||||
|
||||
@item Debugging
|
||||
@itemize @bullet
|
||||
@item GNU debugger (gdb)
|
||||
@item DDD GUI interface to GDB
|
||||
@item thread aware
|
||||
@item debug over Ethernet
|
||||
@item debug over Serial Port
|
||||
@end itemize
|
||||
|
||||
@item Filesystem Support
|
||||
@itemize @bullet
|
||||
@item In-Memory Filesystem (IMFS)
|
||||
@item TFTP Client Filesystem
|
||||
@end itemize
|
||||
|
||||
@item Basic Kernel Features
|
||||
@itemize @bullet
|
||||
@item multitasking capabilities
|
||||
@item homogeneous and heterogeneous multiprocessor systems
|
||||
@item event-driven, priority-based, preemptive scheduling
|
||||
@item optional rate monotonic scheduling
|
||||
@item intertask communication and synchronization
|
||||
@item priority inheritance
|
||||
@item responsive interrupt management
|
||||
@item dynamic memory allocation
|
||||
@item high level of user configurability
|
||||
@end itemize
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@section What standards does RTEMS support?
|
||||
|
||||
The original "Classic" RTEMS API is based on the Real-Time Executive
|
||||
Interface Definition (RTEID) and the Open Real-Time Kernel Interface
|
||||
Definition (ORKID). RTEMS also includes support for POSIX threads
|
||||
and real-time extensions.
|
||||
|
||||
With the addition of file system infrastructure, RTEMS supports
|
||||
about 70% of the POSIX 1003.1b-1996 standard. This standard
|
||||
defines the programming interfaces of standard UNIX. This means
|
||||
that much source code that works on UNIX, also works on RTEMS.
|
||||
|
||||
@section What processors is RTEMS available for?
|
||||
|
||||
RTEMS is available for the following processor families:
|
||||
|
||||
@itemize @bullet
|
||||
@item Motorola MC68xxx
|
||||
@item Motorola MC683xx
|
||||
@item Motorola ColdFire
|
||||
@item ARM
|
||||
@item Hitachi H8/300
|
||||
@item Hitachi SH
|
||||
@item Intel i386
|
||||
@item MIPS
|
||||
@item PowerPC
|
||||
@item SPARC
|
||||
@item Texas Instruments C3x/C4x
|
||||
@item OpenCores OR32
|
||||
@end itemize
|
||||
|
||||
In addition, there is a port to UNIX which can be used as a prototyping
|
||||
and simulation environment.
|
||||
|
||||
@section Executive vs. Kernel vs. Operating System (RTOS)
|
||||
|
||||
The developers of RTEMS developers use the terms executive and kernel
|
||||
interchangeably. In the embedded system community, the terms executive
|
||||
or kernel are generally used to refer to small operating systems.
|
||||
So we consider it proper to refer to RTEMS as an executive, a kernel,
|
||||
or an operating system.
|
||||
|
||||
@section Where/why was it developed?
|
||||
|
||||
RTEMS was developed by On-Line Applications Research Corporation (OAR)
|
||||
for the U.S. Army Missile Command prior to that organizations merger
|
||||
with the Aviation Command that resulted in the new command, U. S. Army
|
||||
Aviation and Missile command (AMCOM). The original goal of RTEMS was
|
||||
to provide a portable, standards-based real-time executive for which
|
||||
source code was available and royalties were paid.
|
||||
|
||||
In other words, RTEMS was open source before open source was cool.
|
||||
|
||||
Since the initial release to the world, the RTEMS Community has
|
||||
grown enormously and contributed significantly to RTEMS. Important
|
||||
additions such as the TCP/IP stack, FAT filesystem, multiple ports,
|
||||
device drivers, and most BSPs have come from users like yourself.
|
||||
|
||||
@section Are there no similar commercial products?
|
||||
|
||||
Yes, but not all are based on standards and the open source philosophy.
|
||||
|
||||
@section How can I get RTEMS?
|
||||
|
||||
RTEMS is distributed from @uref{@value{RTEMSHTTPURL},@value{RTEMSHTTPURL}}.
|
||||
This is a server dedicated to the RTEMS Project which was donated by and
|
||||
hosted by @uref{http://www.oarcorp.com,OAR Corporation} to provide
|
||||
a focal point for all RTEMS activities. Point your
|
||||
favorite browser at the following URL and following the link:
|
||||
|
||||
@uref{@value{RTEMSHTTPURL},@value{RTEMSHTTPURL}}
|
||||
|
||||
But if you are already reading this, you probably already found it. :)
|
||||
|
||||
@section What about support?
|
||||
|
||||
RTEMS development and support services are available from a number
|
||||
of firms. See
|
||||
@uref{@value{RTEMSHTTPURL}/support.html,@value{RTEMSHTTPURL}/support.html}
|
||||
for the current list of RTEMS service providers.
|
||||
|
||||
Remember that RTEMS maintenance is funded by users. If you are
|
||||
using RTEMS on a commercial project, please get support.
|
||||
|
||||
@section Are there any mailing lists?
|
||||
|
||||
The primary RTEMS mailing list is @code{@value{RTEMSUSERS}}. This
|
||||
list is for general RTEMS discussions, questions, design help, advice,
|
||||
etc.. Subscribe by sending an empty mail
|
||||
message to @code{@value{RTEMSUSERSSUBSCRIBE}}. This
|
||||
mailing list is archived at:
|
||||
|
||||
@example
|
||||
http://www.rtems.com/ml/rtems-users
|
||||
@end example
|
||||
|
||||
@section Are there any license restrictions?
|
||||
|
||||
RTEMS is licensed under a modified version of the GNU General Public License
|
||||
(GPL). The modification places no restrictions on the applications which
|
||||
use RTEMS but protects the interests of those who work on RTEMS.
|
||||
|
||||
The TCP/IP network stack included with RTEMS is a port of the FreeBSD
|
||||
network stack and is licensed under different terms that also do not
|
||||
place restrictions on the application.
|
||||
|
||||
@section Are there any export restrictions?
|
||||
|
||||
No.
|
||||
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter BSP Questions
|
||||
|
||||
The items in this category provide answers to questions
|
||||
commonly asked about BSPs.
|
||||
|
||||
@section What is a BSP?
|
||||
|
||||
BSP is an acronym for Board Support Package.
|
||||
|
||||
A BSP is a collection of device drivers, startup code, linker scripts,
|
||||
and compiler support files (specs files) that tailor RTEMS for a
|
||||
particular target hardware environment.
|
||||
|
||||
@section What has to be in a BSP?
|
||||
|
||||
The basic set of items is the linker script, bsp_specs, and startup code.
|
||||
If you want standard IO, then you need a console driver. This is needed
|
||||
to run any of the RTEMS tests. If you want to measure passage of time,
|
||||
you need a clock tick driver. This driver is needed for all RTEMS tests
|
||||
EXCEPT hello world and the timing tests. The timer driver is a benchmark
|
||||
timer and is needed for the tmtests (timing tests). Sometimes you will
|
||||
see a shmsupp directory which is for shared memory multiprocessing
|
||||
systems. The network driver and real-time clock drivers are optional
|
||||
and not required by any RTEMS tests.
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -1,19 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter RTEMS Concepts
|
||||
|
||||
The questions in this category are hints that help basic understanding.
|
||||
|
||||
@section RTEMS Workspace versus Program Heap
|
||||
|
||||
The RTEMS Workspace is used to allocate space for objects created
|
||||
by RTEMS such as tasks, semaphores, message queues, etc.. It is
|
||||
primarily used during system initialization although task stacks
|
||||
and message buffer areas are also allocated from here.
|
||||
@ref{How do I determine how much memory is left?}.
|
||||
-158
@@ -1,158 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Debugging Hints
|
||||
|
||||
The questions in this category are hints that can ease debugging.
|
||||
|
||||
@section Executable Size
|
||||
|
||||
@subsection Why is my executable so big?
|
||||
|
||||
There are two primary causes for this. The most common is that
|
||||
you are doing an @code{ls -l} and looking at the actual file
|
||||
size -- not the size of the code in the target image. This
|
||||
file could be in an object format such as ELF or COFF and
|
||||
contain debug information. If this is the case, it could
|
||||
be an order of magnitude larger than the required code space.
|
||||
Use the strip command in your cross toolset to remove debugging
|
||||
information.
|
||||
|
||||
The following example was done using the i386-rtems cross toolset
|
||||
and the pc386 BSP. Notice that with symbolic information included
|
||||
the file @code{hello.exe} is almost a megabyte and would barely fit
|
||||
on a boot floppy. But there is actually only about 93K of code
|
||||
and initialized data. The other 800K is symbolic information
|
||||
which is not required to execute the application.
|
||||
|
||||
@example
|
||||
$ ls -l hello.exe
|
||||
-rwxrwxr-x 1 joel users 930515 May 2 09:50 hello.exe
|
||||
$ i386-rtems-size hello.exe
|
||||
text data bss dec hex filename
|
||||
88605 3591 11980 104176 196f0 hello.exe
|
||||
$ i386-rtems-strip hello.exe
|
||||
$ ls -l hello.exe
|
||||
-rwxrwxr-x 1 joel users 106732 May 2 10:02 hello.exe
|
||||
$ i386-rtems-size hello.exe
|
||||
text data bss dec hex filename
|
||||
88605 3591 11980 104176 196f0 hello.exe
|
||||
@end example
|
||||
|
||||
Another alternative is that the executable file is in an ASCII
|
||||
format such as Motorola Srecords. In this case, there is
|
||||
no debug information in the file but each byte in the target
|
||||
image requires two bytes to represent. On top of that, there
|
||||
is some overhead required to specify the addresses where the image
|
||||
is to be placed in target memory as well as checksum information.
|
||||
In this case, it is not uncommon to see executable files
|
||||
that are between two and three times larger than the actual
|
||||
space required in target memory.
|
||||
|
||||
Remember, the debugging information is required to do symbolic
|
||||
debugging with gdb. Normally gdb obtains its symbolic information
|
||||
from the same file that it gets the executable image from. However,
|
||||
gdb does not require that the executable image and symbolic
|
||||
information be obtained from the same file. So you might
|
||||
want to create a @code{hello_with_symbols.exe}, copy that
|
||||
file to @code{hello_without_symbols.exe}, and strip
|
||||
@code{hello_without_symbols.exe}. Then gdb would have to
|
||||
be told to read symbol information from @code{hello_with_symbols.exe}.
|
||||
The gdb command line option @code{-symbols} or command
|
||||
@code{symbol-file} may be used to specify the file read
|
||||
for symbolic information.
|
||||
|
||||
|
||||
@section Malloc
|
||||
|
||||
@subsection Is malloc reentrant?
|
||||
|
||||
Yes. The RTEMS Malloc implementation is reentrant. It is
|
||||
implemented as calls to the Region Manager in the Classic API.
|
||||
|
||||
@subsection When is malloc initialized?
|
||||
|
||||
During BSP initialization, the @code{bsp_libc_init} routine
|
||||
is called. This routine initializes the heap as well as
|
||||
the RTEMS system call layer (open, read, write, etc.) and
|
||||
the RTEMS reentrancy support for the Cygnus newlib Standard C
|
||||
Library.
|
||||
|
||||
The @code{bsp_libc_init} routine is passed the size and starting
|
||||
address of the memory area to be used for the program heap as well
|
||||
as the amount of memory to ask @code{sbrk} for when the heap is
|
||||
exhausted. For most BSPs, all memory available is placed in the
|
||||
program heap thus it can not be extended dynamically by calls to
|
||||
@code{sbrk}.
|
||||
|
||||
@section How do I determine how much memory is left?
|
||||
|
||||
First there are two types of memory: RTEMS Workspace and Program Heap.
|
||||
The RTEMS Workspace is the memory used by RTEMS to allocate control
|
||||
structures for system objects like tasks and semaphores, task
|
||||
stacks, and some system data structures like the ready chains.
|
||||
The Program Heap is where "malloc'ed" memory comes from.
|
||||
|
||||
Both are essentially managed as heaps based on the Heap Manager
|
||||
in the RTEMS SuperCore. The RTEMS Workspace uses the Heap Manager
|
||||
directly while the Program Heap is actually based on an RTEMS Region
|
||||
from the Classic API. RTEMS Regions are in turn based on the Heap
|
||||
Manager in the SuperCore.
|
||||
|
||||
@subsection How much memory is left in the RTEMS Workspace?
|
||||
|
||||
An executive workspace overage can be fairly easily spotted with a
|
||||
debugger. Look at _Workspace_Area. If first == last, then there is only
|
||||
one free block of memory in the workspace (very likely if no task
|
||||
deletions). Then do this:
|
||||
|
||||
(gdb) p *(Heap_Block *)_Workspace_Area->first
|
||||
$3 = @{back_flag = 1, front_flag = 68552, next = 0x1e260, previous = 0x1e25c@}
|
||||
|
||||
In this case, I had 68552 bytes left in the workspace.
|
||||
|
||||
@subsection How much memory is left in the Heap?
|
||||
|
||||
The C heap is a region so this should work:
|
||||
|
||||
(gdb) p *((Region_Control *)_Region_Information->local_table[1])->Memory->first
|
||||
$9 = @{back_flag = 1, front_flag = 8058280, next = 0x7ea5b4,
|
||||
previous = 0x7ea5b0@}
|
||||
|
||||
In this case, the first block on the C Heap has 8,058,280 bytes left.
|
||||
|
||||
@section How do I convert an executable to IEEE-695?
|
||||
|
||||
This section is based on an email from Andrew Bythell
|
||||
<abythell@@nortelnetworks.com> in July 1999.
|
||||
|
||||
Using Objcopy to convert m68k-coff to IEEE did not work. The new IEEE
|
||||
object could not be read by tools like the XRay BDM Debugger.
|
||||
|
||||
The exact nature of this problem is beyond me, but I did narrow it down to a
|
||||
problem with objcopy in binutils 2-9.1. To no surprise, others have
|
||||
discovered this problem as well, as it has been fixed in later releases.
|
||||
|
||||
I compiled a snapshot of the development sources from 07/26/99 and
|
||||
everything now works as it should. The development sources are at
|
||||
@uref{http://sourceware.cygnus.com/binutils} (thanks Ian!)
|
||||
|
||||
Additional notes on converting an m68k-coff object for use with XRay (and
|
||||
others):
|
||||
|
||||
@enumerate
|
||||
|
||||
|
||||
@item The m68k-coff object must be built with the -gstabs+ flag. The -g flag
|
||||
alone didn't work for me.
|
||||
|
||||
@item Run Objcopy with the --debugging flag to copy debugging information.
|
||||
|
||||
@end enumerate
|
||||
|
||||
|
||||
@@ -1,111 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Date/Time Issues in Systems Using RTEMS
|
||||
|
||||
This section provides technical information regarding
|
||||
date/time representation issues and RTEMS. The Y2K problem has
|
||||
lead numerous people to ask these questions. The answer to
|
||||
these questions are actually more complicated than most
|
||||
people asking the question expect. RTEMS supports multiple
|
||||
standards and each of these standards has its own epoch and
|
||||
time representation. These standards include both programming
|
||||
API and programming language standards.
|
||||
|
||||
In addition to the issues inside RTEMS
|
||||
itself, there is the complicating factor that the Board
|
||||
Support Package or application itself may interface with hardware
|
||||
or software that has its own set of date/time representation
|
||||
issues.
|
||||
|
||||
In conclusion, viewing date/time representation as "the Y2K problem"
|
||||
is very short-sighted. Date/time representation should be viewed as
|
||||
a systems level issue for the system you are building. Each software
|
||||
and hardware component in the system as well as the systems being
|
||||
connected to is a factor in the equation.
|
||||
|
||||
@section Hardware Issues
|
||||
|
||||
Numerous Real-Time Clock (RTC) controllers provide only a two-digit
|
||||
Binary Coded Decimal (BCD) representation for the current year. Without
|
||||
software correction, these chips are a classic example of the Y2K problem.
|
||||
When the RTC rolls the year register over from 99 to 00, the device
|
||||
has no idea whether the year is 1900 or 2000. It is the responsibility
|
||||
of the device driver to recognize this condition and correct for it.
|
||||
The most common technique used is to assume that all years prior
|
||||
to either the existence of the board or RTEMS are past 2000. The
|
||||
starting year (epoch) for RTEMS is 1988. Thus,
|
||||
|
||||
@itemize @bullet
|
||||
@item Chip year values 88-99 are interpreted as years 1988-2002.
|
||||
@item Chip year values 00-87 are interpreted as years 2000-2087.
|
||||
@end itemize
|
||||
|
||||
Using this technique, a RTC using a
|
||||
two-digit BCD representation of the current year will overflow on
|
||||
January 1, 2088.
|
||||
|
||||
@section RTEMS Specific Issues
|
||||
|
||||
Internally, RTEMS uses an unsigned thirty-two bit integer to represent the
|
||||
number of seconds since midnight January 1, 1988. This counter will
|
||||
overflow on February 5, 2124.
|
||||
|
||||
The time/date services in the Classic API will overflow when the
|
||||
RTEMS internal date/time representation overflows.
|
||||
|
||||
The POSIX API uses the type @i{time_t} to represent the number of
|
||||
seconds since January 1, 1970. Many traditional UNIX systems as
|
||||
well as RTEMS define @i{time_t} as a signed thirty-two bit integer.
|
||||
This representation overflows on January 18, 2038. The solution
|
||||
usually proposed is to define @i{time_t} as a sixty-four bit
|
||||
integer. This solution is appropriate for for UNIX workstations
|
||||
as many of them already support sixty-four bit integers natively.
|
||||
At this time, this imposes a burden on embedded systems which are
|
||||
still primarily using processors with native integers of thirty-two
|
||||
bits or less.
|
||||
|
||||
@section Language Specific Issues
|
||||
|
||||
The Ada95 Language Reference Manual requires that the @i{Ada.Calendar}
|
||||
package support years through the year 2099. However, just as the
|
||||
hardware is layered on top of hardware and may inherit its limits,
|
||||
the Ada tasking and run-time support is layered on top of an operating
|
||||
system. Thus, if the operating system or underlying hardware fail
|
||||
to correctly report dates after 2099, then it is possible for the
|
||||
@i{Ada.Calendar} package to fail prior to 2099.
|
||||
|
||||
@section Date/Time Conclusion
|
||||
|
||||
Each embedded system could be impacted by a variety of date/time
|
||||
representation issues. Even whether a particular date/time
|
||||
representation issue impacts a system is questionable. A system
|
||||
using only the RTEMS Classic API is not impacted by the
|
||||
date/time representation issues in POSIX. A system not using
|
||||
date/time at all is not impacted by any of these issues. Also
|
||||
the planned end of life for a system may make these issues
|
||||
moot.
|
||||
|
||||
The following is a timeline of the date/time representation
|
||||
issues presented in this section:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item 2000 - Two BCD Digit Real-Time Clock Rollover
|
||||
|
||||
@item 2038 - POSIX @i{time_t} Rollover
|
||||
|
||||
@item 2088 - Correction for Two BCD Digit Real-Time Clock Rollover
|
||||
|
||||
@item 2099 - Ada95 @i{Ada.Calendar} Rollover
|
||||
|
||||
@item 2124 - RTEMS Internal Seconds Counter Rollover
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -1,60 +0,0 @@
|
||||
#
|
||||
# $Id$
|
||||
#
|
||||
|
||||
This is the RTEMS entry in the Crossgcc FAQ at @uref{http://www.objsw.com}.
|
||||
As of 8/19/99, it has been submitted twice and the FAQ not updated.
|
||||
|
||||
RTEMS is a freely available, royalty free real-time executive with
|
||||
multiprocessor capabilities. RTEMS' design provides performance and
|
||||
capabilities are comparable to those of the best commercial executives.
|
||||
The directive execution times and other critical performance measures such
|
||||
as interrupt latency are best of class. RTEMS was developed by On-Line
|
||||
Applications Research Corporation (OAR) under contract to the U.S. Army
|
||||
Missile Command.
|
||||
|
||||
|
||||
RTEMS includes support for multiple APIs. Currently RTEMS supports a
|
||||
POSIX threads API, and an RTEID based API which is similar to pSOS+.
|
||||
RTEMS includes a number of advanced real-time features including optional
|
||||
rate monotonic scheduling support, binary semapahores with priority
|
||||
inheritance, and watchdog timer functions.
|
||||
|
||||
RTEMS includes a port of the FreeBSD TCP/IP stack that has high
|
||||
performance on very modest hardware. A remote debug server is supported
|
||||
on some targets that allows debugging across the network.
|
||||
|
||||
RTEMS provides a rich run-time environment with a reentrant C library,
|
||||
POSIX 1003.1b support, and file system support. It also includes optional
|
||||
debug aids like stack overflow and heap integrity checking.
|
||||
|
||||
RTEMS is built using GNU autoconf and can be built on any host supporting
|
||||
the GNU tools including GNU/Linux, FreeBSD, NetBSD, Solaris, and MS-Windows
|
||||
to name but a few. The current RTEMS release supports the following CPU
|
||||
families:
|
||||
|
||||
Motorola m680x0, m683xx, and ColdFire
|
||||
Motorola and IBM PowerPC (4xx, 5xx, 6xx, 7xx, 8xx, and 84xx)
|
||||
Hitachi SH-1, SH-2, SH-4
|
||||
Hitachi H8
|
||||
ARM
|
||||
Intel i386, i486, and Pentium
|
||||
SPARC
|
||||
MIPS
|
||||
Texas Instruments C3x/C4x
|
||||
OpenCores OR32
|
||||
|
||||
There are over 35 Board Support Packages included with RTEMS including
|
||||
BSPs for a standard PC as well as the SPARC, MIPS, PowerPC simulators
|
||||
included with gdb. There are numerous BSPs for CPUs targetting the
|
||||
embedded market such as the Motorola m683xx, ppc4xx, and mpc8xx series
|
||||
which support the on-CPU peripherals.
|
||||
|
||||
WWW:
|
||||
|
||||
@uref{http://www.rtems.com}
|
||||
|
||||
E-mail:
|
||||
|
||||
@code{rtems-info@@OARcorp.com}
|
||||
|
||||
@@ -1,169 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Free Software that Works with RTEMS
|
||||
|
||||
This section describes other free software packages that are known to work
|
||||
with RTEMS.
|
||||
|
||||
@section Development Tools
|
||||
|
||||
@subsection Basic Development Environment
|
||||
|
||||
The standard RTEMS development environment consists of the following GNU
|
||||
components:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item gcc
|
||||
@item binutils
|
||||
@item gdb
|
||||
|
||||
@end itemize
|
||||
|
||||
Although not from the Free Software Foundation, the Cygnus newlib C
|
||||
library integrates well with the GNU tools and is a standard part of the
|
||||
RTEMS development environment.
|
||||
|
||||
@subsection GNU Ada
|
||||
|
||||
For those interested in using the Ada95 programming language, the GNU Ada
|
||||
compiler (GNAT) is available and has excellent support for RTEMS.
|
||||
|
||||
@subsection DDD - Data Display Debugger
|
||||
|
||||
By far the easiest way to use DDD if you are on a Redhat or SuSE Linux system
|
||||
is to retrieve the RPM package for your OS version. In general, it is
|
||||
easier to install a static binary since doing so avoids all problems
|
||||
with dynamic library versions.
|
||||
|
||||
Some versions of DDD have had trouble with Lesstif. If you
|
||||
are using Lesstif, you will need version 0.88 or newer. It
|
||||
is also available as an RPM at the popular sites. Another Motif
|
||||
clone is Motive and versions 1.2 and newer known to work with DDD
|
||||
on popular distributions of Linux including RedHat and Slackware.
|
||||
|
||||
Installed as RPMs, DDD in conjunction with either Lesstif or Motive
|
||||
should work out-of-the-box.
|
||||
|
||||
User comments indicate that both Lesstif and DDD can be built
|
||||
from scratch without any problems. Instructions on installing DDD
|
||||
are at @uref{http://www.cs.tu-bs.de/softech/ddd/}. They
|
||||
indicate that
|
||||
|
||||
@itemize @bullet
|
||||
LessTif should be used in (default) Motif 1.2 compatibility mode.
|
||||
|
||||
The Motif 2.0 compatibility mode of LessTif is still incomplete.
|
||||
@end itemize
|
||||
|
||||
So configure lesstif with --enable-default-12.
|
||||
|
||||
The configure script is broken (see www.lesstif.org --> known problems)
|
||||
for 0.88.1. I didn't fix the script as they show, so I just have links
|
||||
in /usr/local/lib (also shown).
|
||||
|
||||
Watch out: Lesstif installs its libraries in /usr/local/Lesstif. You
|
||||
will need to update /etc/ld.so.conf and regenerate the cache of shared
|
||||
library paths to point to the Motif 1.2 library.
|
||||
|
||||
The following notes are from an RTEMS user who uses DDD in conjunction
|
||||
with Lesstif. Configure DDD "--with-motif-libraries=/usr/local/lib
|
||||
--with-motif-includes=/usr/local/include" DDD needs gnuplot 3.7.
|
||||
@uref{ftp://ftp.dartmouth.edu/pub/gnuplot/gnuplot-3.7.tar.gz}. Build and
|
||||
install from scratch.
|
||||
|
||||
DDD can be started from a script that specifies the cross debugger.
|
||||
This simplifies the invocation. The following example shows what
|
||||
a script doing this looks like.
|
||||
|
||||
@example
|
||||
#!/bin/bash
|
||||
ddd --debugger m68k-elf-gdb $1
|
||||
@end example
|
||||
|
||||
Under many flavors of UNIX, you will likely have to relax permissions.
|
||||
|
||||
On Linux, to get gdb to use the serial ports while running as a
|
||||
normal user, edit /etc/security/console.perms, and create a <serial>
|
||||
class (call it whatever you want).
|
||||
|
||||
@example
|
||||
<serial>=/dev/ttyS* /dev/cua*
|
||||
@end example
|
||||
|
||||
Now enable the change of ownership of these devices when users log in
|
||||
from the console:
|
||||
|
||||
@example
|
||||
<console> 0600 <serial> 0600 root
|
||||
@end example
|
||||
|
||||
Users report using minicom to communicate with the target to initiate a TFTP
|
||||
download. They then suspend minicom, launch DDD, and begin debugging.
|
||||
|
||||
The procedure should be the same on other platforms, modulo the choice
|
||||
of terminal emulator program and the scheme used to access the serial
|
||||
ports. From problem reports on the cygwin mailing list, it appears that
|
||||
GDB has some problems communicating over serial lines on that platform.
|
||||
|
||||
NOTE: GDB does not like getting lots of input from the program under test
|
||||
over the serial line. Actually, it does not care, but it looses
|
||||
characters. It would appear that flow control is not re-enabled when it
|
||||
resumes program execution. At times, it looked like the test were
|
||||
failing, but everything was OK. We modified the MVME167 serial driver to
|
||||
send test output to another serial port. Using two serial ports is
|
||||
usually the easiest way to get test output while retaining a reliable debug
|
||||
connection regardless of the debugger/target combination.
|
||||
|
||||
NOTE: Enabling gdb's remote cache might prevent this (Observed with SH1
|
||||
boards, but may also be valid for targets):
|
||||
@example
|
||||
gdb > set remotecache
|
||||
@end example
|
||||
|
||||
Information provided by Charles-Antoine Gauthier (charles.gauthier@@iit.nrc.ca)
|
||||
Jiri Gaisler (jgais@@ws.estec.esa.nl) and Ralf Cors@'epius
|
||||
(corsepiu@@faw.uni-ulm.de)
|
||||
|
||||
|
||||
@section omniORB
|
||||
|
||||
omniORB is a GPL'ed CORBA which has been ported to RTEMS. It is
|
||||
available from
|
||||
(@uref{http://www.uk.research.att.com/omniORB/omniORB.html,http://www.uk.research.att.com/omniORB/omniORB.html})
|
||||
.
|
||||
|
||||
For information on the RTEMS port of omniORB to RTEMS, see the following
|
||||
URL
|
||||
(@uref{http://www.connecttel.com/corba/rtems_omni.html,http://www.connecttel.com/corba/rtems_omni.html}).
|
||||
|
||||
C++ exceptions must work properly on your target for omniORB to work.
|
||||
|
||||
The port of omniORB to RTEMS was done by Rosimildo DaSilva
|
||||
<rdasilva@@connecttel.com>.
|
||||
|
||||
@section TCL
|
||||
|
||||
Tool Command Language.
|
||||
|
||||
ditto
|
||||
|
||||
@section ncurses
|
||||
|
||||
Free version of curses.
|
||||
|
||||
ditto
|
||||
|
||||
|
||||
@section zlib
|
||||
|
||||
Free compression/decompression library.
|
||||
|
||||
ditto
|
||||
|
||||
@@ -1,110 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter Hardware to Ease Debugging
|
||||
|
||||
The items in this category provide information on various hardware
|
||||
debugging assistants that are available.
|
||||
|
||||
@section MC683xx BDM Support for GDB
|
||||
|
||||
Eric Norum (eric@@skatter.usask.ca) has a driver for a parallel
|
||||
port interface to a BDM module. This driver has a long history
|
||||
and is based on a driver by Gunter Magin (magin@@skil.camelot.de)
|
||||
which in turn was based on BD32 for DOS by Scott Howard. Eric Norum
|
||||
and Chris Johns (ccj@@acm.org) have put together a package containing
|
||||
everything you need to use this BDM driver including software, PCB layouts,
|
||||
and machining drawings. From the README:
|
||||
|
||||
"This package contains everything you need to be able to run GDB on
|
||||
Linux and control a Motorola CPU32+ (68360) or Coldfire (5206, 5206e, or
|
||||
5207) target through a standard PC parallel port."
|
||||
|
||||
Information on this BDM driver is available at the following URL:
|
||||
|
||||
@example
|
||||
http://www.calm.hw.ac.uk/davidf/coldfire/gdb-bdm-linux.htm
|
||||
@end example
|
||||
|
||||
The package is officially hosted at Eric Norum's ftp site:
|
||||
|
||||
@example
|
||||
ftp://skatter.usask.ca/pub/eric/BDM-Linux-gdb/
|
||||
@end example
|
||||
|
||||
Peter Shoebridge (peter@@zeecube.com) has ported the Linux
|
||||
parallel port BDM driver from Eric Norum to Windows NT. It is
|
||||
available at http://www.zeecube.com/bdm.
|
||||
|
||||
The efi332 project has a home-built BDM module and gdb backend for
|
||||
Linux. See http://efi332.eng.ohio-state.edu/efi332/hardware.html)
|
||||
for details. The device driver and gdb backend are based on those
|
||||
by Gunter Magin (magin@@skil.camelot.de) available from
|
||||
ftp.lpr.e-technik.tu-muenchen.de.
|
||||
|
||||
Pavel Pisa (pisa@@cmp.felk.cvut.cz) has one available at
|
||||
http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html.
|
||||
|
||||
Huntsville Microsystems (HMI) has GDB support for their BDM module
|
||||
available upon request. It is also available from their ftp site:
|
||||
ftp://ftp.hmi.com/pub/gdb
|
||||
|
||||
The Macraigor OCD BDM module has a driver for Linux
|
||||
written by Gunter Magin (magin@@skil.camelot.de).
|
||||
No URLs yet.
|
||||
|
||||
Finally, there is a overview of BDM at the following URL:
|
||||
http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html.
|
||||
|
||||
Information in this section from:
|
||||
|
||||
@itemize @bullet
|
||||
@item Brendan Simon <brendan@@dgs.monash.edu.au>
|
||||
@item W Gerald Hicks <wghicks@@bellsouth.net>
|
||||
@item Chris Johns <ccj@@acm.org>
|
||||
@item Eric Norum <eric@@skatter.usask.ca>
|
||||
@item Gunter Magin <magin@@skil.camelot.de>
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@section MPC8xx BDM Support for GDB
|
||||
|
||||
@c "Adrian Bocaniciu" <a.bocaniciu@computer.org> has a driver
|
||||
@c for NT and is willing to share it but he needs to be emailed
|
||||
@c privately since he needs to explain somethings about it.
|
||||
@c It has been used for over a year as of 08/18/99.
|
||||
|
||||
Christian Haan <chn@@intego.de> has written a driver for FreeBSD
|
||||
based for"a slightly changed ICD BDM module (because of changes
|
||||
in the BDM interface on the PowerPC)" that "probably will work with
|
||||
the PD module too." His work is based on the M68K BDM work by
|
||||
Gunter Magin (Gunter.Magin@@skil.camelot.de) and
|
||||
the PPC BDM for Linux work by Sergey Drazhnikov (swd@@agua.comptek.ru).
|
||||
This is not yet publicly available.
|
||||
|
||||
Sergey Drazhnikov (swd@@agua.comptek.ru) has written a PPC BDM driver for
|
||||
Linux. Information is available at http://cyclone.parad.ru/ppcbdm.
|
||||
|
||||
Huntsville Microsystems (HMI) has GDB support for their BDM module
|
||||
available upon request. It is also available from their ftp site:
|
||||
ftp://ftp.hmi.com/pub/gdb
|
||||
|
||||
GDB includes support for a set of primitives to support the Macraigor
|
||||
Wiggler (OCD BDM). Unfortunately, this requires the use of a
|
||||
proprietary interface and is supported only on Windows. This forces
|
||||
one to use CYGWIN. Reports are that this results in a slow
|
||||
interface. Scott Howard (http://www.objsw.com) has announced
|
||||
that support for the gdb+wiggler combination under DJGPP which should
|
||||
run significantly faster.
|
||||
|
||||
@itemize @bullet
|
||||
@item Leon Pollak <leonp@@plris.com>
|
||||
@item Christian Haan <chn@@intego.de>
|
||||
@end itemize
|
||||
|
||||
@@ -1,113 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter RTEMS Projects
|
||||
|
||||
The questions in this category are regarding things that people
|
||||
are working on or that the RTEMS community would like to see work on.
|
||||
|
||||
There are multiple ways to support the RTEMS Project. Financial support
|
||||
is always welcomed. This can be via sponsorship of a specific project
|
||||
such as one of the ones listed here or via volunteering in some
|
||||
capacity.
|
||||
|
||||
@section Other Filesystems
|
||||
|
||||
This is a list of the filesystems that would be nice to have support
|
||||
for in RTEMS. For each filsystem, status and contact information is
|
||||
provided for those who have expressed interest in helping out or are actively
|
||||
working on it.
|
||||
|
||||
@itemize @bullet
|
||||
@item TFTP client - read only, no write capability
|
||||
@itemize @bullet
|
||||
@item No Contact
|
||||
@end itemize
|
||||
|
||||
@item DOS Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Peter Shoebridge <peter@@zeecube.com>
|
||||
@item Victor V. Vengerov <vvv@@tepkom.ru>
|
||||
@end itemize
|
||||
|
||||
@item CD-ROM Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Peter Shoebridge <peter@@zeecube.com>
|
||||
@end itemize
|
||||
|
||||
@item Flash Filesystem(s) - ???
|
||||
@itemize @bullet
|
||||
@item Rod Barman <rodb@@ieee.org>
|
||||
@item Victor V. Vengerov <vvv@@tepkom.ru>
|
||||
@end itemize
|
||||
|
||||
@item Remote Host Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Wayne Bullaughey <wayne@@wmi.com>
|
||||
@end itemize
|
||||
|
||||
@item NFS client - ???
|
||||
@itemize @bullet
|
||||
@item No Contact
|
||||
@end itemize
|
||||
|
||||
@end itemize
|
||||
|
||||
@section Java
|
||||
|
||||
@subsection Kaffe
|
||||
|
||||
This porting effort is underway and active.
|
||||
|
||||
@itemize @bullet
|
||||
@item Jiri Gaisler <jgais@@ws.estec.esa.nl>
|
||||
@item Oscar Martinez de la Torre <omt@@wm.estec.esa.nl>
|
||||
@end itemize
|
||||
|
||||
NOTE: An older version of Kaffe was ported to a pre-4.0 version of RTEMS.
|
||||
The network support in RTEMS was immature at that port and Kaffe had
|
||||
portability problems. Together these resulted in an unclean port which
|
||||
was never merged.
|
||||
|
||||
@subsection GNU Java Compiler (gjc)
|
||||
|
||||
This porting effort is underway and active.
|
||||
|
||||
@itemize @bullet
|
||||
@item Charles-Antoine Gauthier <charles.gauthier@@iit.nrc.ca>
|
||||
@end itemize
|
||||
|
||||
@section CORBA
|
||||
|
||||
@subsection TAO
|
||||
|
||||
This porting effort is pending testing. Erik ported the code but then
|
||||
discovered that his target board did not have enough memory to run
|
||||
any TAO tests.
|
||||
|
||||
@itemize @bullet
|
||||
@item Erik Ivanenko <erik.ivanenko@@utoronto.ca>
|
||||
@end itemize
|
||||
|
||||
@section APIs
|
||||
|
||||
@subsection POSIX 1003.1b
|
||||
|
||||
Support for POSIX 1003.1b is mature but there are a few remaining
|
||||
items including a handful of services, performance tests, and
|
||||
documentation. Please refer to the Status chapter of the
|
||||
@i{POSIX API User's Guide} for more details.
|
||||
|
||||
@subsection ITRON 3.0
|
||||
|
||||
Support for ITRON 3.0 is in its beginning stages. There are
|
||||
numerous managers left to implement, both functional and
|
||||
performance tests to write, and much documentation remaining.
|
||||
Please refer to the Status chapter of the @i{ITRON 3.0 API User's Guide}
|
||||
for specific details.
|
||||
|
||||
@@ -1,4 +0,0 @@
|
||||
@set UPDATED 5 March 2004
|
||||
@set UPDATED-MONTH March 2004
|
||||
@set EDITION 4.6.99.3
|
||||
@set VERSION 4.6.99.3
|
||||
@@ -1,71 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
@chapter General Development Tool Hints
|
||||
|
||||
The questions in this category are related to the GNU development tools
|
||||
in a non-language specific way.
|
||||
|
||||
@section What is GNU?
|
||||
|
||||
Take a look at @uref{http://www.gnu.org,http://www.gnu.org} for information on the GNU Project.
|
||||
|
||||
@section How do I generate a patch?
|
||||
|
||||
The RTEMS patches to the development tools are generated using a
|
||||
command like this
|
||||
|
||||
@example
|
||||
diff -N -P -r -c TOOL-original-image TOOL-with-changes >PATCHFILE
|
||||
@end example
|
||||
|
||||
where the options are:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item -N and -P take care of adding and removing files (be careful not to
|
||||
include junk files like file.mybackup)
|
||||
|
||||
@item -r tells diff to recurse through subdirectories
|
||||
|
||||
@item -c is a context diff (easy to read for humans)
|
||||
|
||||
@end itemize
|
||||
|
||||
Please look at the generated PATCHFILE and make sure it does not
|
||||
contain anything you did not intend to send to the maintainers.
|
||||
It is easy to accidentally leave a backup file in the modified
|
||||
source tree or have a spurious change that should not be
|
||||
in the PATCHFILE.
|
||||
|
||||
If you end up with the entire contents of a file in the patch
|
||||
and can't figure out why, you may have different CR/LF scheme
|
||||
in the two source files. The GNU open-source packages usually have
|
||||
UNIX style CR/LF. If you edit on a Windows platform, the line
|
||||
terminators may have been transformed by the editor into Windows
|
||||
style.
|
||||
|
||||
@section How do I apply a patch?
|
||||
|
||||
Patches generated with the @code{diff} program are fed into the
|
||||
@code{patch} program as follows:
|
||||
|
||||
@example
|
||||
patch -p1 <PATCHFILE
|
||||
@end example
|
||||
|
||||
where the options are:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item -pNUM tells @code{patch} to strip off NUM slashes from the
|
||||
pathname.
|
||||
|
||||
@end itemize
|
||||
|
||||
If @code{patch} prompts for a file to patch, you may need to adjust NUM.
|
||||
@@ -1,4 +0,0 @@
|
||||
@set UPDATED 5 March 2004
|
||||
@set UPDATED-MONTH March 2004
|
||||
@set EDITION 4.6.99.3
|
||||
@set VERSION 4.6.99.3
|
||||
+3
-4
@@ -7,7 +7,7 @@ ACLOCAL_AMFLAGS = -I ../aclocal
|
||||
# NOTE: The order of the directories is essential.
|
||||
# + tools, common and images are shared across many documents
|
||||
|
||||
SUBDIRS = tools FAQ started user bsp_howto porting develenv posix_users \
|
||||
SUBDIRS = tools started user bsp_howto porting develenv posix_users \
|
||||
posix1003.1 filesystem itron3.0 networking ada_user started_ada \
|
||||
rtems_gdb rgdb_specs new_chapters relnotes cpu_supplement gnu_docs
|
||||
|
||||
@@ -17,9 +17,8 @@ endif
|
||||
|
||||
EXTRA_DIST = HELP.html rtems_header.html.in rtems_footer.html.in
|
||||
|
||||
EXTRA_DIST += common/cpright.texi common/setup.texi common/timemac.texi \
|
||||
common/timetbl.t common/treedef.tex common/wksheets.t common/timing.t \
|
||||
common/rtems.texi.in
|
||||
EXTRA_DIST += common/cpright.texi common/setup.texi \
|
||||
common/treedef.tex common/rtems.texi.in
|
||||
|
||||
html_imagesdir = $(htmldir)/images
|
||||
|
||||
|
||||
@@ -1,36 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
@c
|
||||
@c Macros to help with the tables in this file
|
||||
@c
|
||||
|
||||
@tex
|
||||
\global\advance \smallskipamount by -4pt
|
||||
|
||||
\global\def\rtemstimetable{
|
||||
\vrule\strut##&
|
||||
\hbox to 3.0in{\enskip##\hfil}&
|
||||
\hbox to 0.75in{\enskip##\hfil}&
|
||||
\vrule##\cr
|
||||
\noalign{\hrule}
|
||||
}
|
||||
|
||||
\global\def\rtemsendtimetable{}
|
||||
\global\def\rtemsonecase#1#2{
|
||||
& \bf #1\hfil& #2 & \cr\noalign{\hrule}
|
||||
}
|
||||
|
||||
\global\def\rtemsdirective#1{
|
||||
& \bf #1 \hfil& & \cr\noalign{\hrule}
|
||||
}
|
||||
|
||||
\global\def\rtemscase#1#2{
|
||||
& \hskip 0.3in #1\hfil& #2 & \cr\noalign{\hrule}
|
||||
}
|
||||
|
||||
@end tex
|
||||
File diff suppressed because it is too large.
Load diff
File diff suppressed because it is too large.
Load diff
@@ -177,7 +177,6 @@ _RTEMS_UPDATE_CONDITIONAL([common/rtems.sed],[common/rtems.sed~])
|
||||
|
||||
AC_CONFIG_FILES([
|
||||
index.html
|
||||
FAQ/Makefile
|
||||
develenv/Makefile
|
||||
user/Makefile
|
||||
bsp_howto/Makefile])
|
||||
|
||||
+13
-111
@@ -7,15 +7,7 @@
|
||||
<HR>
|
||||
<BODY>
|
||||
<MENU>
|
||||
<LI>
|
||||
<A HREF="../pdf/FAQ.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/FAQ.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/FAQ.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="FAQ/index.html">RTEMS FAQ</A>
|
||||
</LI>
|
||||
<LI><A HREF="http://www.rtems.org/wiki">RTEMS Wiki</A></LI>
|
||||
<LI>C/C++ Manuals</LI>
|
||||
<MENU>
|
||||
<LI><A HREF="../pdf/started.pdf">
|
||||
@@ -82,6 +74,16 @@
|
||||
</MENU>
|
||||
<LI>Miscellaneous Manuals</LI>
|
||||
<MENU>
|
||||
<LI><A HREF="../pdf/cpu_supplement.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/cpu_supplement.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/cpu_supplement.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="cpu_supplement/index.html">
|
||||
RTEMS CPU Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/develenv.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/develenv.ps">
|
||||
@@ -153,109 +155,9 @@
|
||||
</LI>
|
||||
</MENU>
|
||||
|
||||
|
||||
<LI>CPU Supplements for Primary Ports
|
||||
|
||||
<MENU>
|
||||
|
||||
<LI><A HREF="HELP.html">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
RTEMS Hitachi H8/300 Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/i386.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/i386.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/i386.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/i386/index.html">
|
||||
RTEMS Intel i386 Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/m68k.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/m68k.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/m68k.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/m68k/index.html">
|
||||
RTEMS Motorola MC68xxx Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/mips.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/mips.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/mips.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/mips/index.html">
|
||||
RTEMS MIPS Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/powerpc.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/powerpc.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/powerpc.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/powerpc/index.html">
|
||||
RTEMS PowerPC Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/sh.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/sh.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/sh.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/sh/index.html">
|
||||
RTEMS Hitachi SH Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="../pdf/sparc.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/sparc.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/sparc.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/sparc/index.html">
|
||||
RTEMS SPARC Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
<LI><A HREF="HELP.html">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="HELP.html">
|
||||
RTEMS UNIX Port Applications Supplement</A>
|
||||
</LI>
|
||||
|
||||
</MENU>
|
||||
|
||||
<LI>CPU Supplements for Secondary Ports
|
||||
|
||||
<MENU>
|
||||
<LI><A HREF="../pdf/c4x.pdf">
|
||||
<IMG SRC="images/pdf1.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../ps/c4x.ps">
|
||||
<IMG SRC="images/ps.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="../dvi/c4x.dvi">
|
||||
<IMG SRC="images/dvi.gif" HEIGHT=18 WIDTH=16></A>
|
||||
<A HREF="supplements/c4x/index.html">
|
||||
RTEMS Texas Instruments C3x/C4x Applications Supplement</A>
|
||||
</LI>
|
||||
</MENU>
|
||||
</LI>
|
||||
</li>
|
||||
|
||||
</MENU>
|
||||
<HR>
|
||||
Copyright © 1988-2004 <A HREF="http://www.oarcorp.com" target="Text Frame">OAR Corporation</A>
|
||||
Copyright © 1988-2006 <A HREF="http://www.oarcorp.com" target="Text Frame">OAR Corporation</A>
|
||||
</BODY></HTML>
|
||||
Reference in new issue
Block a user