URL
https://opencores.org/ocsvn/or1k/or1k/trunk
Subversion Repositories or1k
Compare Revisions
- This comparison shows the changes necessary to convert path
/or1k/trunk/rtems-20020807/doc/supplements/arm
- from Rev 1028 to Rev 1765
- ↔ Reverse comparison
Rev 1028 → Rev 1765
/Makefile.in
0,0 → 1,598
# Makefile.in generated by automake 1.6.2 from Makefile.am. |
# @configure_input@ |
|
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 |
# Free Software Foundation, Inc. |
# This Makefile.in is free software; the Free Software Foundation |
# gives unlimited permission to copy and/or distribute it, |
# with or without modifications, as long as this notice is preserved. |
|
# This program is distributed in the hope that it will be useful, |
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without |
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A |
# PARTICULAR PURPOSE. |
|
@SET_MAKE@ |
|
# |
# COPYRIGHT (c) 1988-2002. |
# On-Line Applications Research Corporation (OAR). |
# All rights reserved. |
# |
# Makefile.am,v 1.1 2002/07/30 21:43:53 joel Exp |
# |
SHELL = @SHELL@ |
|
srcdir = @srcdir@ |
top_srcdir = @top_srcdir@ |
VPATH = @srcdir@ |
prefix = @prefix@ |
exec_prefix = @exec_prefix@ |
|
bindir = @bindir@ |
sbindir = @sbindir@ |
libexecdir = @libexecdir@ |
datadir = @datadir@ |
sysconfdir = @sysconfdir@ |
sharedstatedir = @sharedstatedir@ |
localstatedir = @localstatedir@ |
libdir = @libdir@ |
infodir = @infodir@ |
mandir = @mandir@ |
includedir = @includedir@ |
oldincludedir = /usr/include |
pkgdatadir = $(datadir)/@PACKAGE@ |
pkglibdir = $(libdir)/@PACKAGE@ |
pkgincludedir = $(includedir)/@PACKAGE@ |
top_builddir = ../.. |
|
ACLOCAL = @ACLOCAL@ |
AUTOCONF = @AUTOCONF@ |
AUTOMAKE = @AUTOMAKE@ |
AUTOHEADER = @AUTOHEADER@ |
|
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd |
INSTALL = @INSTALL@ |
INSTALL_PROGRAM = @INSTALL_PROGRAM@ |
INSTALL_DATA = @INSTALL_DATA@ |
install_sh_DATA = $(install_sh) -c -m 644 |
install_sh_PROGRAM = $(install_sh) -c |
install_sh_SCRIPT = $(install_sh) -c |
INSTALL_SCRIPT = @INSTALL_SCRIPT@ |
INSTALL_HEADER = $(INSTALL_DATA) |
transform = @program_transform_name@ |
NORMAL_INSTALL = : |
PRE_INSTALL = : |
POST_INSTALL = : |
NORMAL_UNINSTALL = : |
PRE_UNINSTALL = : |
POST_UNINSTALL = : |
|
EXEEXT = @EXEEXT@ |
OBJEXT = @OBJEXT@ |
PATH_SEPARATOR = @PATH_SEPARATOR@ |
AMTAR = @AMTAR@ |
AWK = @AWK@ |
BMENU2 = @BMENU2@ |
DEPDIR = @DEPDIR@ |
DVIPS = @DVIPS@ |
ENDIF = @ENDIF@ |
EPSTOPDF = @EPSTOPDF@ |
GS = @GS@ |
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ |
LN_S = @LN_S@ |
MAINT = @MAINT@ |
MAKE = @MAKE@ |
PACKAGE = @PACKAGE@ |
PERL = @PERL@ |
PROJECT_ROOT = @PROJECT_ROOT@ |
PROJECT_TOPdir = @PROJECT_TOPdir@ |
RTEMS_TOPdir = @RTEMS_TOPdir@ |
STRIP = @STRIP@ |
TEXI2DVI = @TEXI2DVI@ |
TEXI2PDF = @TEXI2PDF@ |
TEXI2WWW = @TEXI2WWW@ |
VERSION = @VERSION@ |
am__include = @am__include@ |
am__quote = @am__quote@ |
htmldir = @htmldir@ |
install_sh = @install_sh@ |
pkgdocdir = @pkgdocdir@ |
|
PROJECT = arm |
EDITION = 1 |
|
SUFFIXES = .t .pdf .eps .html |
|
MAINTAINERCLEANFILES = $(PROJECT) $(PROJECT)-[0-9] $(PROJECT)-[0-9][0-9] $(GENERATED_FILES) $(GENERATED_FILES) |
|
MOSTLYCLEANFILES = $(PDF_IMAGES) index.html $(PROJECT)*.html rtems_header.html \ |
rtems_footer.html |
|
CLEANFILES = $(PROJECT).pdf timeBSP_.t |
|
dvidir = $(pkgdocdir)/dvi |
|
psdir = $(pkgdocdir)/ps |
|
pdfdir = $(pkgdocdir)/pdf |
|
@USE_HTML_TRUE@html_project_DATA = index.html $(PROJECT)*.html |
|
@USE_DVI_TRUE@dvi_DATA = $(PROJECT).dvi |
|
@USE_DVI_TRUE@@USE_PS_TRUE@ps_DATA = $(PROJECT).ps |
|
@USE_PDF_TRUE@pdf_DATA = $(PROJECT).pdf |
|
REPLACE2 = $(PERL) $(top_srcdir)/tools/word-replace2 |
|
TEXINFO_TEX = ../../texinfo/texinfo.tex |
AM_MAKEINFOFLAGS = -I ../.. |
html_projectdir = $(htmldir)/supplements/$(PROJECT) |
|
TEXI2WWW_ARGS = \ |
-I $(srcdir) -I $(top_srcdir) \ |
-dirfile ../../index.html \ |
-header rtems_header.html \ |
-footer rtems_footer.html \ |
-icons ../../images |
|
|
GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ |
fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ |
timeBSP.texi |
|
COMMON_FILES = $(top_srcdir)/common/setup.texi \ |
$(top_srcdir)/common/cpright.texi $(top_srcdir)/common/timemac.texi |
|
|
FILES = preface.texi |
|
info_TEXINFOS = arm.texi |
arm_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) |
|
EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ |
intr_NOTIMES.t memmodel.t timeBSP.t |
|
subdir = supplements/arm |
mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs |
CONFIG_CLEAN_FILES = |
CFLAGS = @CFLAGS@ |
COMPILE = $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ |
$(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) |
CCLD = $(CC) |
LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@ |
DIST_SOURCES = |
INFO_DEPS = arm |
DVIS = arm.dvi |
TEXINFOS = arm.texi |
DATA = $(dvi_DATA) $(html_project_DATA) $(pdf_DATA) $(ps_DATA) |
|
DIST_COMMON = $(arm_TEXINFOS) ChangeLog Makefile.am Makefile.in \ |
stamp-vti version.texi |
all: all-am |
|
.SUFFIXES: |
.SUFFIXES: .t .pdf .eps .html .dvi .info .ps .texi |
$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ Makefile.am $(top_srcdir)/project.am $(top_srcdir)/supplements/supplement.am $(top_srcdir)/configure.ac $(ACLOCAL_M4) |
cd $(top_srcdir) && \ |
$(AUTOMAKE) --foreign supplements/arm/Makefile |
Makefile: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.in $(top_builddir)/config.status |
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe) |
|
$(srcdir)/version.texi: @MAINTAINER_MODE_TRUE@ $(srcdir)/stamp-vti |
@: |
$(srcdir)/stamp-vti: arm.texi $(top_srcdir)/configure.ac |
@(set `$(SHELL) $(top_srcdir)/../mdate-sh $(srcdir)/arm.texi`; \ |
echo "@set UPDATED $$1 $$2 $$3"; \ |
echo "@set UPDATED-MONTH $$2 $$3"; \ |
echo "@set EDITION $(VERSION)"; \ |
echo "@set VERSION $(VERSION)") > vti.tmp |
@cmp -s vti.tmp $(srcdir)/version.texi \ |
|| (echo "Updating $(srcdir)/version.texi"; \ |
cp vti.tmp $(srcdir)/version.texi) |
-@rm -f vti.tmp |
@cp $(srcdir)/version.texi $@ |
|
mostlyclean-vti: |
-rm -f vti.tmp |
|
maintainer-clean-vti: |
@MAINTAINER_MODE_TRUE@ -rm -f $(srcdir)/stamp-vti $(srcdir)/version.texi |
|
arm: arm.texi $(srcdir)/version.texi $(arm_TEXINFOS) |
arm.dvi: arm.texi $(srcdir)/version.texi $(arm_TEXINFOS) |
|
.texi.info: |
@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9] |
cd $(srcdir) \ |
&& $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) \ |
`echo $< | sed 's,.*/,,'` |
|
@USE_DVI_FALSE@.texi.dvi: |
@USE_DVI_FALSE@ TEXINPUTS="$(top_srcdir)/..$(PATH_SEPARATOR)$$TEXINPUTS" \ |
@USE_DVI_FALSE@ MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \ |
@USE_DVI_FALSE@ $(TEXI2DVI) $< |
|
.texi: |
@cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9] |
cd $(srcdir) \ |
&& $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) \ |
`echo $< | sed 's,.*/,,'` |
|
MAKEINFO = @MAKEINFO@ |
@USE_DVI_FALSE@@USE_PS_TRUE@.dvi.ps: |
@USE_DVI_FALSE@@USE_PS_TRUE@ $(DVIPS) $< -o $@ |
@USE_DVI_TRUE@@USE_PS_FALSE@.dvi.ps: |
@USE_DVI_TRUE@@USE_PS_FALSE@ $(DVIPS) $< -o $@ |
@USE_DVI_FALSE@@USE_PS_FALSE@.dvi.ps: |
@USE_DVI_FALSE@@USE_PS_FALSE@ $(DVIPS) $< -o $@ |
|
uninstall-info-am: |
$(PRE_UNINSTALL) |
@if (install-info --version && \ |
install-info --version | fgrep -i -v debian) >/dev/null 2>&1; then \ |
list='$(INFO_DEPS)'; \ |
for file in $$list; do \ |
echo " install-info --info-dir=$(DESTDIR)$(infodir) --remove $(DESTDIR)$(infodir)/$$file"; \ |
install-info --info-dir=$(DESTDIR)$(infodir) --remove $(DESTDIR)$(infodir)/$$file; \ |
done; \ |
else :; fi |
@$(NORMAL_UNINSTALL) |
@list='$(INFO_DEPS)'; \ |
for file in $$list; do \ |
(if cd $(DESTDIR)$(infodir); then \ |
echo " rm -f $$file $$file-[0-9] $$file-[0-9][0-9])"; \ |
rm -f $$file $$file-[0-9] $$file-[0-9][0-9]; \ |
else :; fi); \ |
done |
|
dist-info: $(INFO_DEPS) |
list='$(INFO_DEPS)'; \ |
for base in $$list; do \ |
d=$(srcdir); \ |
for file in $$d/$$base*; do \ |
relfile=`expr "$$file" : "$$d/\(.*\)"`; \ |
test -f $(distdir)/$$relfile || \ |
cp -p $$file $(distdir)/$$relfile; \ |
done; \ |
done |
|
mostlyclean-aminfo: |
-rm -f arm.aux arm.cp arm.cps arm.dvi arm.fn arm.fns arm.ky arm.log arm.pg \ |
arm.ps arm.toc arm.tp arm.vr |
|
maintainer-clean-aminfo: |
cd $(srcdir) && \ |
list='$(INFO_DEPS)'; for i in $$list; do \ |
rm -f $$i; \ |
if test "`echo $$i-[0-9]*`" != "$$i-[0-9]*"; then \ |
rm -f $$i-[0-9]*; \ |
fi; \ |
done |
dviDATA_INSTALL = $(INSTALL_DATA) |
install-dviDATA: $(dvi_DATA) |
@$(NORMAL_INSTALL) |
$(mkinstalldirs) $(DESTDIR)$(dvidir) |
@list='$(dvi_DATA)'; for p in $$list; do \ |
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " $(dviDATA_INSTALL) $$d$$p $(DESTDIR)$(dvidir)/$$f"; \ |
$(dviDATA_INSTALL) $$d$$p $(DESTDIR)$(dvidir)/$$f; \ |
done |
|
uninstall-dviDATA: |
@$(NORMAL_UNINSTALL) |
@list='$(dvi_DATA)'; for p in $$list; do \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " rm -f $(DESTDIR)$(dvidir)/$$f"; \ |
rm -f $(DESTDIR)$(dvidir)/$$f; \ |
done |
html_projectDATA_INSTALL = $(INSTALL_DATA) |
install-html_projectDATA: $(html_project_DATA) |
@$(NORMAL_INSTALL) |
$(mkinstalldirs) $(DESTDIR)$(html_projectdir) |
@list='$(html_project_DATA)'; for p in $$list; do \ |
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " $(html_projectDATA_INSTALL) $$d$$p $(DESTDIR)$(html_projectdir)/$$f"; \ |
$(html_projectDATA_INSTALL) $$d$$p $(DESTDIR)$(html_projectdir)/$$f; \ |
done |
|
uninstall-html_projectDATA: |
@$(NORMAL_UNINSTALL) |
@list='$(html_project_DATA)'; for p in $$list; do \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " rm -f $(DESTDIR)$(html_projectdir)/$$f"; \ |
rm -f $(DESTDIR)$(html_projectdir)/$$f; \ |
done |
pdfDATA_INSTALL = $(INSTALL_DATA) |
install-pdfDATA: $(pdf_DATA) |
@$(NORMAL_INSTALL) |
$(mkinstalldirs) $(DESTDIR)$(pdfdir) |
@list='$(pdf_DATA)'; for p in $$list; do \ |
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " $(pdfDATA_INSTALL) $$d$$p $(DESTDIR)$(pdfdir)/$$f"; \ |
$(pdfDATA_INSTALL) $$d$$p $(DESTDIR)$(pdfdir)/$$f; \ |
done |
|
uninstall-pdfDATA: |
@$(NORMAL_UNINSTALL) |
@list='$(pdf_DATA)'; for p in $$list; do \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " rm -f $(DESTDIR)$(pdfdir)/$$f"; \ |
rm -f $(DESTDIR)$(pdfdir)/$$f; \ |
done |
psDATA_INSTALL = $(INSTALL_DATA) |
install-psDATA: $(ps_DATA) |
@$(NORMAL_INSTALL) |
$(mkinstalldirs) $(DESTDIR)$(psdir) |
@list='$(ps_DATA)'; for p in $$list; do \ |
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " $(psDATA_INSTALL) $$d$$p $(DESTDIR)$(psdir)/$$f"; \ |
$(psDATA_INSTALL) $$d$$p $(DESTDIR)$(psdir)/$$f; \ |
done |
|
uninstall-psDATA: |
@$(NORMAL_UNINSTALL) |
@list='$(ps_DATA)'; for p in $$list; do \ |
f="`echo $$p | sed -e 's|^.*/||'`"; \ |
echo " rm -f $(DESTDIR)$(psdir)/$$f"; \ |
rm -f $(DESTDIR)$(psdir)/$$f; \ |
done |
tags: TAGS |
TAGS: |
|
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) |
|
top_distdir = ../.. |
distdir = $(top_distdir)/$(PACKAGE)-$(VERSION) |
|
distdir: $(DISTFILES) |
$(mkinstalldirs) $(distdir)/$(top_srcdir)/common |
@list='$(DISTFILES)'; for file in $$list; do \ |
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \ |
dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \ |
if test "$$dir" != "$$file" && test "$$dir" != "."; then \ |
dir="/$$dir"; \ |
$(mkinstalldirs) "$(distdir)$$dir"; \ |
else \ |
dir=''; \ |
fi; \ |
if test -d $$d/$$file; then \ |
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \ |
cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \ |
fi; \ |
cp -pR $$d/$$file $(distdir)$$dir || exit 1; \ |
else \ |
test -f $(distdir)/$$file \ |
|| cp -p $$d/$$file $(distdir)/$$file \ |
|| exit 1; \ |
fi; \ |
done |
$(MAKE) $(AM_MAKEFLAGS) \ |
top_distdir="${top_distdir}" distdir="$(distdir)" \ |
dist-info |
check-am: all-am |
check: check-am |
all-am: Makefile $(INFO_DEPS) $(DATA) |
|
installdirs: |
$(mkinstalldirs) $(DESTDIR)$(infodir) $(DESTDIR)$(dvidir) $(DESTDIR)$(html_projectdir) $(DESTDIR)$(pdfdir) $(DESTDIR)$(psdir) |
|
install: install-am |
install-exec: install-exec-am |
install-data: install-data-am |
uninstall: uninstall-am |
|
install-am: all-am |
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am |
|
installcheck: installcheck-am |
install-strip: |
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \ |
INSTALL_STRIP_FLAG=-s \ |
`test -z '$(STRIP)' || \ |
echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install |
mostlyclean-generic: |
-test -z "$(MOSTLYCLEANFILES)" || rm -f $(MOSTLYCLEANFILES) |
|
clean-generic: |
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES) |
|
distclean-generic: |
-rm -f Makefile $(CONFIG_CLEAN_FILES) |
|
maintainer-clean-generic: |
@echo "This command is intended for maintainers to use" |
@echo "it deletes files that may require special tools to rebuild." |
-test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES) |
clean: clean-am |
|
clean-am: clean-generic mostlyclean-am |
|
distclean: distclean-am |
|
distclean-am: clean-am distclean-generic |
|
dvi: dvi-am |
|
dvi-am: $(DVIS) |
|
info: info-am |
|
info-am: $(INFO_DEPS) |
|
install-data-am: install-dviDATA install-html_projectDATA \ |
install-info-am install-pdfDATA install-psDATA |
|
install-exec-am: |
|
install-info: install-info-am |
|
install-info-am: $(INFO_DEPS) |
@$(NORMAL_INSTALL) |
$(mkinstalldirs) $(DESTDIR)$(infodir) |
@list='$(INFO_DEPS)'; \ |
for file in $$list; do \ |
d=$(srcdir); \ |
for ifile in echo $$d/$$file $$d/$$file-[0-9] $$d/$$file-[0-9][0-9]; do \ |
if test -f $$ifile; then \ |
relfile=`expr "$$ifile" : "$$d/\(.*\)"`; \ |
echo " $(INSTALL_DATA) $$ifile $(DESTDIR)$(infodir)/$$relfile"; \ |
$(INSTALL_DATA) $$ifile $(DESTDIR)$(infodir)/$$relfile; \ |
else : ; fi; \ |
done; \ |
done |
@$(POST_INSTALL) |
@if (install-info --version && \ |
install-info --version | fgrep -i -v debian) >/dev/null 2>&1; then \ |
list='$(INFO_DEPS)'; \ |
for file in $$list; do \ |
echo " install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file";\ |
install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file || :;\ |
done; \ |
else : ; fi |
install-man: |
|
installcheck-am: |
|
maintainer-clean: maintainer-clean-am |
|
maintainer-clean-am: distclean-am maintainer-clean-aminfo \ |
maintainer-clean-generic maintainer-clean-vti |
|
mostlyclean: mostlyclean-am |
|
mostlyclean-am: mostlyclean-aminfo mostlyclean-generic mostlyclean-vti |
|
uninstall-am: uninstall-dviDATA uninstall-html_projectDATA \ |
uninstall-info-am uninstall-pdfDATA uninstall-psDATA |
|
.PHONY: all all-am check check-am clean clean-generic dist-info \ |
distclean distclean-generic distdir dvi dvi-am info info-am \ |
install install-am install-data install-data-am install-dviDATA \ |
install-exec install-exec-am install-html_projectDATA \ |
install-info install-info-am install-man install-pdfDATA \ |
install-psDATA install-strip installcheck installcheck-am \ |
installdirs maintainer-clean maintainer-clean-aminfo \ |
maintainer-clean-generic maintainer-clean-vti mostlyclean \ |
mostlyclean-aminfo mostlyclean-generic mostlyclean-vti \ |
uninstall uninstall-am uninstall-dviDATA \ |
uninstall-html_projectDATA uninstall-info-am uninstall-pdfDATA \ |
uninstall-psDATA |
|
|
@EPSTOPDF_TRUE@.eps.pdf: |
@EPSTOPDF_TRUE@ $(EPSTOPDF) $< --outfile=$@ |
|
$(PROJECT).pdf: $(PROJECT).texi $($(PROJECT)_TEXINFOS) $(PDF_IMAGES) |
|
rtems_header.html: $(top_srcdir)/rtems_header.html.in version.texi |
@sed -e s%\.\./images/%$(top_builddir)/images/%g \ |
-e s%\@VERSION\@%@VERSION@%g \ |
< $< > $@ |
rtems_footer.html: $(top_srcdir)/rtems_footer.html.in version.texi |
@sed -e s%\.\./images/%$(top_builddir)/%g \ |
-e s%\@VERSION\@%@VERSION@%g \ |
< $< > $@ |
|
index.html $(PROJECT)*.html: $(PROJECT).texi \ |
rtems_header.html rtems_footer.html |
$(TEXI2WWW) $(TEXI2WWW_ARGS) -base $(PROJECT) $< |
|
@USE_DVI_TRUE@.texi.dvi: |
@USE_DVI_TRUE@ $(TEXI2DVI) -q -I $(srcdir) -I $(top_srcdir) $< |
@USE_DVI_TRUE@@USE_PS_TRUE@.dvi.ps: |
@USE_DVI_TRUE@@USE_PS_TRUE@ TEXINPUTS="$(srcdir)$(PATH_SEPARATOR)$$TEXINPUTS" \ |
@USE_DVI_TRUE@@USE_PS_TRUE@ $(DVIPS) $< -o $@ |
|
@TEXI2PDF_TRUE@@USE_PDF_TRUE@.texi.pdf: |
@TEXI2PDF_TRUE@@USE_PDF_TRUE@ rm -f *.aux *.cp *.fn *.ky *.pg *.tp *.toc *.vr |
@TEXI2PDF_TRUE@@USE_PDF_TRUE@ $(TEXI2PDF) -q -I $(srcdir) -I $(top_srcdir) $< |
|
# |
# Chapters which get automatic processing |
# |
|
$(srcdir)/cpumodel.texi: cpumodel.t |
$(BMENU2) -p "Preface" \ |
-u "Top" \ |
-n "Calling Conventions" < $< > $@ |
|
$(srcdir)/callconv.texi: callconv.t |
$(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \ |
-u "Top" \ |
-n "Memory Model" < $< > $@ |
|
$(srcdir)/memmodel.texi: memmodel.t |
$(BMENU2) -p "Calling Conventions User-Provided Routines" \ |
-u "Top" \ |
-n "Interrupt Processing" < $< > $@ |
|
# Interrupt Chapter: |
# 1. Replace Times and Sizes |
# 2. Build Node Structure |
$(srcdir)/intr.texi: intr_NOTIMES.t BSP_TIMES |
${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ |
$(BMENU2) -p "Memory Model Flat Memory Model" \ |
-u "Top" \ |
-n "Default Fatal Error Processing" > $@ |
|
$(srcdir)/fatalerr.texi: fatalerr.t |
$(BMENU2) -p "Interrupt Processing Interrupt Stack" \ |
-u "Top" \ |
-n "Board Support Packages" < $< > $@ |
|
$(srcdir)/bsp.texi: bsp.t |
$(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ |
-u "Top" \ |
-n "Processor Dependent Information Table" < $< > $@ |
|
$(srcdir)/cputable.texi: cputable.t |
$(BMENU2) -p "Board Support Packages Processor Initialization" \ |
-u "Top" \ |
-n "Memory Requirements" < $< > $@ |
|
# Worksheets Chapter: |
# 1. Obtain the Shared File |
# 2. Replace Times and Sizes |
# 3. Build Node Structure |
|
$(srcdir)/wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES |
${REPLACE2} -p $(srcdir)/BSP_TIMES \ |
$(top_srcdir)/common/wksheets.t | \ |
$(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ |
-u "Top" \ |
-n "Timing Specification" > $@ |
|
# Timing Specification Chapter: |
# 1. Copy the Shared File |
# 3. Build Node Structure |
|
$(srcdir)/timing.texi: $(top_srcdir)/common/timing.t |
$(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ |
-u "Top" \ |
-n "MYBSP Timing Data" < $< > $@ |
|
# Timing Data for BSP BSP Chapter: |
# 1. Copy the Shared File |
# 2. Replace Times and Sizes |
# 3. Build Node Structure |
|
$(srcdir)/timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t |
cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t |
@echo >>timeBSP_.t |
@echo "@tex" >>timeBSP_.t |
@echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t |
@echo "@end tex" >>timeBSP_.t |
${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ |
$(BMENU2) -p "Timing Specification Terminology" \ |
-u "Top" \ |
-n "Command and Variable Index" > $@ |
# Tell versions [3.59,3.63) of GNU make to not export all variables. |
# Otherwise a system limit (for SysV at least) may be exceeded. |
.NOEXPORT: |
/stamp-vti
0,0 → 1,4
@set UPDATED 30 July 2002 |
@set UPDATED-MONTH July 2002 |
@set EDITION ss-20020717 |
@set VERSION ss-20020717 |
/BSP_TIMES
0,0 → 1,247
# |
# CPU MODEL/BSP Timing and Size Information |
# |
# BSP_TIMES,v 1.2 2002/08/02 00:45:38 joel Exp |
# |
|
# |
# CPU Model Information |
# |
RTEMS_BSP generic-arm9dtmi |
RTEMS_CPU_MODEL arm9dtmi |
# |
# Interrupt Latency |
# |
# NOTE: In general, the text says it is hand-calculated to be |
# RTEMS_MAXIMUM_DISABLE_PERIOD at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ |
# Mhz and this was last calculated for Release |
# RTEMS_VERSION_FOR_MAXIMUM_DISABLE_PERIOD. |
# |
RTEMS_MAXIMUM_DISABLE_PERIOD TBD |
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ 100 |
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD ss-20020301 |
# |
# Context Switch Times |
# |
RTEMS_NO_FP_CONTEXTS 11 |
RTEMS_RESTORE_1ST_FP_TASK NA |
RTEMS_SAVE_INIT_RESTORE_INIT NA |
RTEMS_SAVE_IDLE_RESTORE_INIT NA |
RTEMS_SAVE_IDLE_RESTORE_IDLE NA |
# |
# Task Manager Times |
# |
RTEMS_TASK_CREATE_ONLY 43 |
RTEMS_TASK_IDENT_ONLY 85 |
RTEMS_TASK_START_ONLY 19 |
RTEMS_TASK_RESTART_CALLING_TASK 26 |
RTEMS_TASK_RESTART_SUSPENDED_RETURNS_TO_CALLER 23 |
RTEMS_TASK_RESTART_BLOCKED_RETURNS_TO_CALLER 28 |
RTEMS_TASK_RESTART_READY_RETURNS_TO_CALLER 24 |
RTEMS_TASK_RESTART_SUSPENDED_PREEMPTS_CALLER 35 |
RTEMS_TASK_RESTART_BLOCKED_PREEMPTS_CALLER 64 |
RTEMS_TASK_RESTART_READY_PREEMPTS_CALLER 64 |
RTEMS_TASK_DELETE_CALLING_TASK 55 |
RTEMS_TASK_DELETE_SUSPENDED_TASK 42 |
RTEMS_TASK_DELETE_BLOCKED_TASK 43 |
RTEMS_TASK_DELETE_READY_TASK 43 |
RTEMS_TASK_SUSPEND_CALLING_TASK 21 |
RTEMS_TASK_SUSPEND_RETURNS_TO_CALLER 9 |
RTEMS_TASK_RESUME_TASK_READIED_RETURNS_TO_CALLER 10 |
RTEMS_TASK_RESUME_TASK_READIED_PREEMPTS_CALLER 18 |
RTEMS_TASK_SET_PRIORITY_OBTAIN_CURRENT_PRIORITY 7 |
RTEMS_TASK_SET_PRIORITY_RETURNS_TO_CALLER 15 |
RTEMS_TASK_SET_PRIORITY_PREEMPTS_CALLER 29 |
RTEMS_TASK_MODE_OBTAIN_CURRENT_MODE 4 |
RTEMS_TASK_MODE_NO_RESCHEDULE 4 |
RTEMS_TASK_MODE_RESCHEDULE_RETURNS_TO_CALLER 13 |
RTEMS_TASK_MODE_RESCHEDULE_PREEMPTS_CALLER 30 |
RTEMS_TASK_GET_NOTE_ONLY 8 |
RTEMS_TASK_SET_NOTE_ONLY 7 |
RTEMS_TASK_WAKE_AFTER_YIELD_RETURNS_TO_CALLER 5 |
RTEMS_TASK_WAKE_AFTER_YIELD_PREEMPTS_CALLER 17 |
RTEMS_TASK_WAKE_WHEN_ONLY 33 |
# |
# Interrupt Manager |
# |
RTEMS_INTR_ENTRY_RETURNS_TO_NESTED unavailable |
RTEMS_INTR_ENTRY_RETURNS_TO_INTERRUPTED_TASK unavailable |
RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK unavailable |
RTEMS_INTR_EXIT_RETURNS_TO_NESTED unavailable |
RTEMS_INTR_EXIT_RETURNS_TO_INTERRUPTED_TASK unavailable |
RTEMS_INTR_EXIT_RETURNS_TO_PREEMPTING_TASK unavailable |
# |
# Clock Manager |
# |
RTEMS_CLOCK_SET_ONLY 21 |
RTEMS_CLOCK_GET_ONLY 1 |
RTEMS_CLOCK_TICK_ONLY 10 |
# |
# Timer Manager |
# |
RTEMS_TIMER_CREATE_ONLY 8 |
RTEMS_TIMER_IDENT_ONLY 83 |
RTEMS_TIMER_DELETE_INACTIVE 11 |
RTEMS_TIMER_DELETE_ACTIVE 12 |
RTEMS_TIMER_FIRE_AFTER_INACTIVE 14 |
RTEMS_TIMER_FIRE_AFTER_ACTIVE 15 |
RTEMS_TIMER_FIRE_WHEN_INACTIVE 21 |
RTEMS_TIMER_FIRE_WHEN_ACTIVE 21 |
RTEMS_TIMER_RESET_INACTIVE 14 |
RTEMS_TIMER_RESET_ACTIVE 15 |
RTEMS_TIMER_CANCEL_INACTIVE 7 |
RTEMS_TIMER_CANCEL_ACTIVE 9 |
# |
# Semaphore Manager |
# |
RTEMS_SEMAPHORE_CREATE_ONLY 27 |
RTEMS_SEMAPHORE_IDENT_ONLY 97 |
RTEMS_SEMAPHORE_DELETE_ONLY 24 |
RTEMS_SEMAPHORE_OBTAIN_AVAILABLE 5 |
RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_NO_WAIT 5 |
RTEMS_SEMAPHORE_OBTAIN_NOT_AVAILABLE_CALLER_BLOCKS 28 |
RTEMS_SEMAPHORE_RELEASE_NO_WAITING_TASKS 9 |
RTEMS_SEMAPHORE_RELEASE_TASK_READIED_RETURNS_TO_CALLER 14 |
RTEMS_SEMAPHORE_RELEASE_TASK_READIED_PREEMPTS_CALLER 22 |
# |
# Message Manager |
# |
RTEMS_MESSAGE_QUEUE_CREATE_ONLY 54 |
RTEMS_MESSAGE_QUEUE_IDENT_ONLY 83 |
RTEMS_MESSAGE_QUEUE_DELETE_ONLY 32 |
RTEMS_MESSAGE_QUEUE_SEND_NO_WAITING_TASKS 14 |
RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_RETURNS_TO_CALLER 16 |
RTEMS_MESSAGE_QUEUE_SEND_TASK_READIED_PREEMPTS_CALLER 25 |
RTEMS_MESSAGE_QUEUE_URGENT_NO_WAITING_TASKS 14 |
RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_RETURNS_TO_CALLER 16 |
RTEMS_MESSAGE_QUEUE_URGENT_TASK_READIED_PREEMPTS_CALLER 25 |
RTEMS_MESSAGE_QUEUE_BROADCAST_NO_WAITING_TASKS 11 |
RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_RETURNS_TO_CALLER 35 |
RTEMS_MESSAGE_QUEUE_BROADCAST_TASK_READIED_PREEMPTS_CALLER 42 |
RTEMS_MESSAGE_QUEUE_RECEIVE_AVAILABLE 15 |
RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_NO_WAIT 10 |
RTEMS_MESSAGE_QUEUE_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 29 |
RTEMS_MESSAGE_QUEUE_FLUSH_NO_MESSAGES_FLUSHED 8 |
RTEMS_MESSAGE_QUEUE_FLUSH_MESSAGES_FLUSHED 9 |
# |
# Event Manager |
# |
RTEMS_EVENT_SEND_NO_TASK_READIED 7 |
RTEMS_EVENT_SEND_TASK_READIED_RETURNS_TO_CALLER 13 |
RTEMS_EVENT_SEND_TASK_READIED_PREEMPTS_CALLER 22 |
RTEMS_EVENT_RECEIVE_OBTAIN_CURRENT_EVENTS 1 |
RTEMS_EVENT_RECEIVE_AVAILABLE 14 |
RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_NO_WAIT 7 |
RTEMS_EVENT_RECEIVE_NOT_AVAILABLE_CALLER_BLOCKS 24 |
# |
# Signal Manager |
# |
RTEMS_SIGNAL_CATCH_ONLY 7 |
RTEMS_SIGNAL_SEND_RETURNS_TO_CALLER 16 |
RTEMS_SIGNAL_SEND_SIGNAL_TO_SELF 29 |
RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_CALLING_TASK 22 |
RTEMS_SIGNAL_EXIT_ASR_OVERHEAD_RETURNS_TO_PREEMPTING_TASK 25 |
# |
# Partition Manager |
# |
RTEMS_PARTITION_CREATE_ONLY 27 |
RTEMS_PARTITION_IDENT_ONLY 83 |
RTEMS_PARTITION_DELETE_ONLY 18 |
RTEMS_PARTITION_GET_BUFFER_AVAILABLE 14 |
RTEMS_PARTITION_GET_BUFFER_NOT_AVAILABLE 10 |
RTEMS_PARTITION_RETURN_BUFFER_ONLY 17 |
# |
# Region Manager |
# |
RTEMS_REGION_CREATE_ONLY 29 |
RTEMS_REGION_IDENT_ONLY 84 |
RTEMS_REGION_DELETE_ONLY 17 |
RTEMS_REGION_GET_SEGMENT_AVAILABLE 14 |
RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_NO_WAIT 18 |
RTEMS_REGION_GET_SEGMENT_NOT_AVAILABLE_CALLER_BLOCKS 56 |
RTEMS_REGION_RETURN_SEGMENT_NO_WAITING_TASKS 15 |
RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_RETURNS_TO_CALLER 40 |
RTEMS_REGION_RETURN_SEGMENT_TASK_READIED_PREEMPTS_CALLER 58 |
# |
# Dual-Ported Memory Manager |
# |
RTEMS_PORT_CREATE_ONLY 18 |
RTEMS_PORT_IDENT_ONLY 83 |
RTEMS_PORT_DELETE_ONLY 19 |
RTEMS_PORT_INTERNAL_TO_EXTERNAL_ONLY 6 |
RTEMS_PORT_EXTERNAL_TO_INTERNAL_ONLY 6 |
# |
# IO Manager |
# |
RTEMS_IO_INITIALIZE_ONLY 2 |
RTEMS_IO_OPEN_ONLY 1 |
RTEMS_IO_CLOSE_ONLY 1 |
RTEMS_IO_READ_ONLY 1 |
RTEMS_IO_WRITE_ONLY 1 |
RTEMS_IO_CONTROL_ONLY 1 |
# |
# Rate Monotonic Manager |
# |
RTEMS_RATE_MONOTONIC_CREATE_ONLY 18 |
RTEMS_RATE_MONOTONIC_IDENT_ONLY 83 |
RTEMS_RATE_MONOTONIC_CANCEL_ONLY 18 |
RTEMS_RATE_MONOTONIC_DELETE_ACTIVE 23 |
RTEMS_RATE_MONOTONIC_DELETE_INACTIVE 21 |
RTEMS_RATE_MONOTONIC_PERIOD_INITIATE_PERIOD_RETURNS_TO_CALLER 25 |
RTEMS_RATE_MONOTONIC_PERIOD_CONCLUDE_PERIOD_CALLER_BLOCKS 20 |
RTEMS_RATE_MONOTONIC_PERIOD_OBTAIN_STATUS 13 |
# |
# Size Information |
# |
# |
# xxx alloted for numbers |
# |
RTEMS_DATA_SPACE na |
RTEMS_MINIMUM_CONFIGURATION na |
RTEMS_MAXIMUM_CONFIGURATION na |
# x,xxx alloted for numbers |
RTEMS_CORE_CODE_SIZE na |
RTEMS_INITIALIZATION_CODE_SIZE na |
RTEMS_TASK_CODE_SIZE na |
RTEMS_INTERRUPT_CODE_SIZE na |
RTEMS_CLOCK_CODE_SIZE na |
RTEMS_TIMER_CODE_SIZE na |
RTEMS_SEMAPHORE_CODE_SIZE na |
RTEMS_MESSAGE_CODE_SIZE na |
RTEMS_EVENT_CODE_SIZE na |
RTEMS_SIGNAL_CODE_SIZE na |
RTEMS_PARTITION_CODE_SIZE na |
RTEMS_REGION_CODE_SIZE na |
RTEMS_DPMEM_CODE_SIZE na |
RTEMS_IO_CODE_SIZE na |
RTEMS_FATAL_ERROR_CODE_SIZE na |
RTEMS_RATE_MONOTONIC_CODE_SIZE na |
RTEMS_MULTIPROCESSING_CODE_SIZE na |
# xxx alloted for numbers |
RTEMS_TIMER_CODE_OPTSIZE na |
RTEMS_SEMAPHORE_CODE_OPTSIZE na |
RTEMS_MESSAGE_CODE_OPTSIZE na |
RTEMS_EVENT_CODE_OPTSIZE na |
RTEMS_SIGNAL_CODE_OPTSIZE na |
RTEMS_PARTITION_CODE_OPTSIZE na |
RTEMS_REGION_CODE_OPTSIZE na |
RTEMS_DPMEM_CODE_OPTSIZE na |
RTEMS_IO_CODE_OPTSIZE na |
RTEMS_RATE_MONOTONIC_CODE_OPTSIZE na |
RTEMS_MULTIPROCESSING_CODE_OPTSIZE na |
# xxx alloted for numbers |
RTEMS_BYTES_PER_TASK na |
RTEMS_BYTES_PER_TIMER na |
RTEMS_BYTES_PER_SEMAPHORE na |
RTEMS_BYTES_PER_MESSAGE_QUEUE na |
RTEMS_BYTES_PER_REGION na |
RTEMS_BYTES_PER_PARTITION na |
RTEMS_BYTES_PER_PORT na |
RTEMS_BYTES_PER_PERIOD na |
RTEMS_BYTES_PER_EXTENSION na |
RTEMS_BYTES_PER_FP_TASK na |
RTEMS_BYTES_PER_NODE na |
RTEMS_BYTES_PER_GLOBAL_OBJECT na |
RTEMS_BYTES_PER_PROXY na |
# x,xxx alloted for numbers |
RTEMS_BYTES_OF_FIXED_SYSTEM_REQUIREMENTS na |
/bsp.t
0,0 → 1,93
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c bsp.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter Board Support Packages |
|
@section Introduction |
|
An RTEMS Board Support Package (BSP) must be designed |
to support a particular processor and target board combination. |
This chapter presents a discussion of XXX specific BSP |
issues. For more information on developing a BSP, refer to the |
chapter titled Board Support Packages in the RTEMS |
Applications User's Guide. |
|
@section System Reset |
|
An RTEMS based application is initiated or |
re-initiated when the XXX processor is reset. When the |
XXX is reset, the processor performs the following actions: |
|
@itemize @bullet |
@item The tracing bits of the status register are cleared to |
disable tracing. |
|
@item The supervisor interrupt state is entered by setting the |
supervisor (S) bit and clearing the master/interrupt (M) bit of |
the status register. |
|
@item The interrupt mask of the status register is set to |
level 7 to effectively disable all maskable interrupts. |
|
@item The vector base register (VBR) is set to zero. |
|
@item The cache control register (CACR) is set to zero to |
disable and freeze the processor cache. |
|
@item The interrupt stack pointer (ISP) is set to the value |
stored at vector 0 (bytes 0-3) of the exception vector table |
(EVT). |
|
@item The program counter (PC) is set to the value stored at |
vector 1 (bytes 4-7) of the EVT. |
|
@item The processor begins execution at the address stored in |
the PC. |
@end itemize |
|
@section Processor Initialization |
|
The address of the application's initialization code |
should be stored in the first vector of the EVT which will allow |
the immediate vectoring to the application code. If the |
application requires that the VBR be some value besides zero, |
then it should be set to the required value at this point. All |
tasks share the same XXX's VBR value. Because interrupts |
are enabled automatically by RTEMS as part of the initialize |
executive directive, the VBR MUST be set before this directive |
is invoked to insure correct interrupt vectoring. If processor |
caching is to be utilized, then it should be enabled during the |
reset application initialization code. |
|
In addition to the requirements described in the |
Board Support Packages chapter of the Applications User's |
Manual for the reset code which is executed before the call to |
initialize executive, the XXX version has the following |
specific requirements: |
|
@itemize @bullet |
@item Must leave the S bit of the status register set so that |
the XXX remains in the supervisor state. |
|
@item Must set the M bit of the status register to remove the |
XXX from the interrupt state. |
|
@item Must set the master stack pointer (MSP) such that a |
minimum stack size of MINIMUM_STACK_SIZE bytes is provided for |
the initialize executive directive. |
|
@item Must initialize the XXX's vector table. |
@end itemize |
|
Note that the BSP is not responsible for allocating |
or installing the interrupt stack. RTEMS does this |
automatically as part of initialization. If the BSP does not |
install an interrupt stack and -- for whatever reason -- an |
interrupt occurs before initialize_executive is invoked, then |
the results are unpredictable. |
|
/arm.texi
0,0 → 1,114
\input texinfo @c -*-texinfo-*- |
@c %**start of header |
@setfilename arm |
@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 arm.texi,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@c |
@c Master file for the ARM Applications Supplement |
@c |
|
@include version.texi |
@include common/setup.texi |
|
@ifset use-ascii |
@dircategory RTEMS Target Supplements |
@direntry |
* RTEMS ARM Applications Supplement: (arm). |
@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 ARM Applications Supplement |
|
@setchapternewpage odd |
@settitle RTEMS ARM Applications Supplement |
@titlepage |
@finalout |
|
@title RTEMS ARM Applications Supplement |
@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. |
|
@include preface.texi |
@include cpumodel.texi |
@include callconv.texi |
@include memmodel.texi |
@include intr.texi |
@include fatalerr.texi |
@include bsp.texi |
@include cputable.texi |
@include wksheets.texi |
@include timing.texi |
@include timeBSP.texi |
@ifinfo |
@node Top, Preface, (dir), (dir) |
@top arm |
|
This is the online version of the RTEMS ARM |
Applications Supplement. |
|
@menu |
* Preface:: |
* CPU Model Dependent Features:: |
* Calling Conventions:: |
* Memory Model:: |
* Interrupt Processing:: |
* Default Fatal Error Processing:: |
* Board Support Packages:: |
* Processor Dependent Information Table:: |
* Memory Requirements:: |
* Timing Specification:: |
* MYBSP Timing Data:: |
* Command and Variable Index:: |
* Concept Index:: |
@end menu |
|
@end ifinfo |
@c |
@c |
@c Need to copy the emacs stuff and "trailer stuff" (index, toc) into here |
@c |
|
@node Command and Variable Index, Concept Index, MYBSP Timing Data Rate Monotonic Manager, 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 |
|
@contents |
@bye |
|
/ChangeLog
0,0 → 1,21
2002-08-01 Joel Sherrill <joel@OARcorp.com> |
|
* BSP_TIMES, wksheets.texi: Updated to reflect ARM times |
reported by Jay Monkman <jmonkman@adventnetworks.com>. These |
times are subject to change as he tunes the ARM port and their BSP. |
|
2002-07-30 Joel Sherrill <joel@OARcorp.com> |
|
* .cvsignore: Corrected by tailoring for the ARM. |
|
2002-07-30 Joel Sherrill <joel@OARcorp.com> |
|
* .cvsignore: New file. |
|
2002-07-30 Joel Sherrill <joel@OARcorp.com> |
|
* BSP_TIMES, ChangeLog, Makefile.am, arm.texi, bsp.t, callconv.t, |
cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t, |
preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi, |
wksheets.texi: New files as ARM supplement initial version added. |
|
/version.texi
0,0 → 1,4
@set UPDATED 30 July 2002 |
@set UPDATED-MONTH July 2002 |
@set EDITION ss-20020717 |
@set VERSION ss-20020717 |
/timing.texi
0,0 → 1,460
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c timing.texi,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
|
@node Timing Specification, Timing Specification Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top |
|
@chapter Timing Specification |
@ifinfo |
@menu |
* Timing Specification Introduction:: |
* Timing Specification Philosophy:: |
* Timing Specification Methodology:: |
@end menu |
@end ifinfo |
|
|
@node Timing Specification Introduction, Timing Specification Philosophy, Timing Specification, Timing Specification |
|
@section Introduction |
|
This chapter provides information pertaining to the |
measurement of the performance of RTEMS, the methods of |
gathering the timing data, and the usefulness of the data. Also |
discussed are other time critical aspects of RTEMS that affect |
an applications design and ultimate throughput. These aspects |
include determinancy, interrupt latency and context switch times. |
|
|
@node Timing Specification Philosophy, Timing Specification Determinancy, Timing Specification Introduction, Timing Specification |
|
@section Philosophy |
@ifinfo |
@menu |
* Timing Specification Determinancy:: |
* Timing Specification Interrupt Latency:: |
* Timing Specification Context Switch Time:: |
* Timing Specification Directive Times:: |
@end menu |
@end ifinfo |
|
Benchmarks are commonly used to evaluate the |
performance of software and hardware. Benchmarks can be an |
effective tool when comparing systems. Unfortunately, |
benchmarks can also be manipulated to justify virtually any |
claim. Benchmarks of real-time executives are difficult to |
evaluate for a variety of reasons. Executives vary in the |
robustness of features and options provided. Even when |
executives compare favorably in functionality, it is quite |
likely that different methodologies were used to obtain the |
timing data. Another problem is that some executives provide |
times for only a small subset of directives, This is typically |
justified by claiming that these are the only time-critical |
directives. The performance of some executives is also very |
sensitive to the number of objects in the system. To obtain any |
measure of usefulness, the performance information provided for |
an executive should address each of these issues. |
|
When evaluating the performance of a real-time |
executive, one typically considers the following areas: |
determinancy, directive times, worst case interrupt latency, and |
context switch time. Unfortunately, these areas do not have |
standard measurement methodologies. This allows vendors to |
manipulate the results such that their product is favorably |
represented. We have attempted to provide useful and meaningful |
timing information for RTEMS. To insure the usefulness of our |
data, the methodology and definitions used to obtain and |
describe the data are also documented. |
|
|
@node Timing Specification Determinancy, Timing Specification Interrupt Latency, Timing Specification Philosophy, Timing Specification Philosophy |
|
@subsection Determinancy |
|
The correctness of data in a real-time system must |
always be judged by its timeliness. In many real-time systems, |
obtaining the correct answer does not necessarily solve the |
problem. For example, in a nuclear reactor it is not enough to |
determine that the core is overheating. This situation must be |
detected and acknowledged early enough that corrective action |
can be taken and a meltdown avoided. |
|
Consequently, a system designer must be able to |
predict the worst-case behavior of the application running under |
the selected executive. In this light, it is important that a |
real-time system perform consistently regardless of the number |
of tasks, semaphores, or other resources allocated. An |
important design goal of a real-time executive is that all |
internal algorithms be fixed-cost. Unfortunately, this goal is |
difficult to completely meet without sacrificing the robustness |
of the executive's feature set. |
|
Many executives use the term deterministic to mean |
that the execution times of their services can be predicted. |
However, they often provide formulas to modify execution times |
based upon the number of objects in the system. This usage is |
in sharp contrast to the notion of deterministic meaning fixed |
cost. |
|
Almost all RTEMS directives execute in a fixed amount |
of time regardless of the number of objects present in the |
system. The primary exception occurs when a task blocks while |
acquiring a resource and specifies a non-zero timeout interval. |
|
Other exceptions are message queue broadcast, |
obtaining a variable length memory block, object name to ID |
translation, and deleting a resource upon which tasks are |
waiting. In addition, the time required to service a clock tick |
interrupt is based upon the number of timeouts and other |
"events" which must be processed at that tick. This second |
group is composed primarily of capabilities which are inherently |
non-deterministic but are infrequently used in time critical |
situations. The major exception is that of servicing a clock |
tick. However, most applications have a very small number of |
timeouts which expire at exactly the same millisecond (usually |
none, but occasionally two or three). |
|
|
@node Timing Specification Interrupt Latency, Timing Specification Context Switch Time, Timing Specification Determinancy, Timing Specification Philosophy |
|
@subsection Interrupt Latency |
|
Interrupt latency is the delay between the CPU's |
receipt of an interrupt request and the execution of the first |
application-specific instruction in an interrupt service |
routine. Interrupts are a critical component of most real-time |
applications and it is critical that they be acted upon as |
quickly as possible. |
|
Knowledge of the worst case interrupt latency of an |
executive aids the application designer in determining the |
maximum period of time between the generation of an interrupt |
and an interrupt handler responding to that interrupt. The |
interrupt latency of an system is the greater of the executive's |
and the applications's interrupt latency. If the application |
disables interrupts longer than the executive, then the |
application's interrupt latency is the system's worst case |
interrupt disable period. |
|
The worst case interrupt latency for a real-time |
executive is based upon the following components: |
|
@itemize @bullet |
@item the longest period of time interrupts are disabled |
by the executive, |
|
@item the overhead required by the executive at the |
beginning of each ISR, |
|
@item the time required for the CPU to vector the |
interrupt, and |
|
@item for some microprocessors, the length of the longest |
instruction. |
@end itemize |
|
The first component is irrelevant if an interrupt |
occurs when interrupts are enabled, although it must be included |
in a worst case analysis. The third and fourth components are |
particular to a CPU implementation and are not dependent on the |
executive. The fourth component is ignored by this document |
because most applications use only a subset of a |
microprocessor's instruction set. Because of this the longest |
instruction actually executed is application dependent. The |
worst case interrupt latency of an executive is typically |
defined as the sum of components (1) and (2). The second |
component includes the time necessry for RTEMS to save registers |
and vector to the user-defined handler. RTEMS includes the |
third component, the time required for the CPU to vector the |
interrupt, because it is a required part of any interrupt. |
|
Many executives report the maximum interrupt disable |
period as their interrupt latency and ignore the other |
components. This results in very low worst-case interrupt |
latency times which are not indicative of actual application |
performance. The definition used by RTEMS results in a higher |
interrupt latency being reported, but accurately reflects the |
longest delay between the CPU's receipt of an interrupt request |
and the execution of the first application-specific instruction |
in an interrupt service routine. |
|
The actual interrupt latency times are reported in |
the Timing Data chapter of this supplement. |
|
|
@node Timing Specification Context Switch Time, Timing Specification Directive Times, Timing Specification Interrupt Latency, Timing Specification Philosophy |
|
@subsection Context Switch Time |
|
An RTEMS context switch is defined as the act of |
taking the CPU from the currently executing task and giving it |
to another task. This process involves the following components: |
|
@itemize @bullet |
@item Saving the hardware state of the current task. |
|
@item Optionally, invoking the TASK_SWITCH user extension. |
|
@item Restoring the hardware state of the new task. |
@end itemize |
|
RTEMS defines the hardware state of a task to include |
the CPU's data registers, address registers, and, optionally, |
floating point registers. |
|
Context switch time is often touted as a performance |
measure of real-time executives. However, a context switch is |
performed as part of a directive's actions and should be viewed |
as such when designing an application. For example, if a task |
is unable to acquire a semaphore and blocks, a context switch is |
required to transfer control from the blocking task to a new |
task. From the application's perspective, the context switch is |
a direct result of not acquiring the semaphore. In this light, |
the context switch time is no more relevant than the performance |
of any other of the executive's subroutines which are not |
directly accessible by the application. |
|
In spite of the inappropriateness of using the |
context switch time as a performance metric, RTEMS context |
switch times for floating point and non-floating points tasks |
are provided for comparison purposes. Of the executives which |
actually support floating point operations, many do not report |
context switch times for floating point context switch time. |
This results in a reported context switch time which is |
meaningless for an application with floating point tasks. |
|
The actual context switch times are reported in the |
Timing Data chapter of this supplement. |
|
|
@node Timing Specification Directive Times, Timing Specification Methodology, Timing Specification Context Switch Time, Timing Specification Philosophy |
|
@subsection Directive Times |
|
Directives are the application's interface to the |
executive, and as such their execution times are critical in |
determining the performance of the application. For example, an |
application using a semaphore to protect a critical data |
structure should be aware of the time required to acquire and |
release a semaphore. In addition, the application designer can |
utilize the directive execution times to evaluate the |
performance of different synchronization and communication |
mechanisms. |
|
The actual directive execution times are reported in |
the Timing Data chapter of this supplement. |
|
|
@node Timing Specification Methodology, Timing Specification Software Platform, Timing Specification Directive Times, Timing Specification |
|
@section Methodology |
@ifinfo |
@menu |
* Timing Specification Software Platform:: |
* Timing Specification Hardware Platform:: |
* Timing Specification What is measured?:: |
* Timing Specification What is not measured?:: |
* Timing Specification Terminology:: |
@end menu |
@end ifinfo |
|
|
@node Timing Specification Software Platform, Timing Specification Hardware Platform, Timing Specification Methodology, Timing Specification Methodology |
|
@subsection Software Platform |
|
The RTEMS timing suite is written in C. The overhead |
of passing arguments to RTEMS by C is not timed. The times |
reported represent the amount of time from entering to exiting |
RTEMS. |
|
The tests are based upon one of two execution models: |
(1) single invocation times, and (2) average times of repeated |
invocations. Single invocation times are provided for |
directives which cannot easily be invoked multiple times in the |
same scenario. For example, the times reported for entering and |
exiting an interrupt service routine are single invocation |
times. The second model is used for directives which can easily |
be invoked multiple times in the same scenario. For example, |
the times reported for semaphore obtain and semaphore release |
are averages of multiple invocations. At least 100 invocations |
are used to obtain the average. |
|
|
@node Timing Specification Hardware Platform, Timing Specification What is measured?, Timing Specification Software Platform, Timing Specification Methodology |
|
@subsection Hardware Platform |
|
Since RTEMS supports a variety of processors, the |
hardware platform used to gather the benchmark times must also |
vary. Therefore, for each processor supported the hardware |
platform must be defined. Each definition will include a brief |
description of the target hardware platform including the clock |
speed, memory wait states encountered, and any other pertinent |
information. This definition may be found in the processor |
dependent timing data chapter within this supplement. |
|
|
@node Timing Specification What is measured?, Timing Specification What is not measured?, Timing Specification Hardware Platform, Timing Specification Methodology |
|
@subsection What is measured? |
|
An effort was made to provide execution times for a |
large portion of RTEMS. Times were provided for most directives |
regardless of whether or not they are typically used in time |
critical code. For example, execution times are provided for |
all object create and delete directives, even though these are |
typically part of application initialization. |
|
The times include all RTEMS actions necessary in a |
particular scenario. For example, all times for blocking |
directives include the context switch necessary to transfer |
control to a new task. Under no circumstances is it necessary |
to add context switch time to the reported times. |
|
The following list describes the objects created by |
the timing suite: |
|
@itemize @bullet |
@item All tasks are non-floating point. |
|
@item All tasks are created as local objects. |
|
@item No timeouts are used on blocking directives. |
|
@item All tasks wait for objects in FIFO order. |
|
@end itemize |
|
In addition, no user extensions are configured. |
|
|
@node Timing Specification What is not measured?, Timing Specification Terminology, Timing Specification What is measured?, Timing Specification Methodology |
|
@subsection What is not measured? |
|
The times presented in this document are not intended |
to represent best or worst case times, nor are all directives |
included. For example, no times are provided for the initialize |
executive and fatal_error_occurred directives. Other than the |
exceptions detailed in the Determinancy section, all directives |
will execute in the fixed length of time given. |
|
Other than entering and exiting an interrupt service |
routine, all directives were executed from tasks and not from |
interrupt service routines. Directives invoked from ISRs, when |
allowable, will execute in slightly less time than when invoked |
from a task because rescheduling is delayed until the interrupt |
exits. |
|
|
@node Timing Specification Terminology, MYBSP Timing Data, Timing Specification What is not measured?, Timing Specification Methodology |
|
@subsection Terminology |
|
The following is a list of phrases which are used to |
distinguish individual execution paths of the directives taken |
during the RTEMS performance analysis: |
|
@table @b |
@item another task |
The directive was performed |
on a task other than the calling task. |
|
@item available |
A task attempted to obtain a resource and |
immediately acquired it. |
|
@item blocked task |
The task operated upon by the |
directive was blocked waiting for a resource. |
|
@item caller blocks |
The requested resoure was not |
immediately available and the calling task chose to wait. |
|
@item calling task |
The task invoking the directive. |
|
@item messages flushed |
One or more messages was flushed |
from the message queue. |
|
@item no messages flushed |
No messages were flushed from |
the message queue. |
|
@item not available |
A task attempted to obtain a resource |
and could not immediately acquire it. |
|
@item no reschedule |
The directive did not require a |
rescheduling operation. |
|
@item NO_WAIT |
A resource was not available and the |
calling task chose to return immediately via the NO_WAIT option |
with an error. |
|
@item obtain current |
The current value of something was |
requested by the calling task. |
|
@item preempts caller |
The release of a resource caused a |
task of higher priority than the calling to be readied and it |
became the executing task. |
|
@item ready task |
The task operated upon by the directive |
was in the ready state. |
|
@item reschedule |
The actions of the directive |
necessitated a rescheduling operation. |
|
@item returns to caller |
The directive succeeded and |
immediately returned to the calling task. |
|
@item returns to interrupted task |
The instructions |
executed immediately following this interrupt will be in the |
interrupted task. |
|
@item returns to nested interrupt |
The instructions |
executed immediately following this interrupt will be in a |
previously interrupted ISR. |
|
@item returns to preempting task |
The instructions |
executed immediately following this interrupt or signal handler |
will be in a task other than the interrupted task. |
|
@item signal to self |
The signal set was sent to the |
calling task and signal processing was enabled. |
|
@item suspended task |
The task operated upon by the |
directive was in the suspended state. |
|
@item task readied |
The release of a resource caused a |
task of lower or equal priority to be readied and the calling |
task remained the executing task. |
|
@item yield |
The act of attempting to voluntarily release |
the CPU. |
|
@end table |
|
|
/memmodel.t
0,0 → 1,38
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c memmodel.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter Memory Model |
|
@section Introduction |
|
A processor may support any combination of memory |
models ranging from pure physical addressing to complex demand |
paged virtual memory systems. RTEMS supports a flat memory |
model which ranges contiguously over the processor's allowable |
address space. RTEMS does not support segmentation or virtual |
memory of any kind. The appropriate memory model for RTEMS |
provided by the targeted processor and related characteristics |
of that model are described in this chapter. |
|
@section Flat Memory Model |
|
Members of the ARM family newer than Version 3 support a flat |
32-bit address space with addresses ranging from 0x00000000 to |
0xFFFFFFFF (4 gigabytes). Each address is represented by a |
32-bit value and is byte addressable. |
The address may be used to reference a |
single byte, word (2-bytes), or long word (4 bytes). Memory |
accesses within this address space are performed in the endian |
mode that the processor is configured for. In general, ARM |
processors are used in little endian mode. |
|
Some of the ARM family members such as the |
920 and 720 include an MMU and thus support virtual memory and |
segmentation. RTEMS does not support virtual memory or |
segmentation on any of the ARM family members. |
|
/cputable.t
0,0 → 1,109
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c cputable.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter Processor Dependent Information Table |
|
@section Introduction |
|
Any highly processor dependent information required |
to describe a processor to RTEMS is provided in the CPU |
Dependent Information Table. This table is not required for all |
processors supported by RTEMS. This chapter describes the |
contents, if any, for a particular processor type. |
|
@section CPU Dependent Information Table |
|
The XXX version of the RTEMS CPU Dependent |
Information Table contains the information required to interface |
a Board Support Package and RTEMS on the XXX. This |
information is provided to allow RTEMS to interoperate |
effectively with the BSP. The C structure definition is given |
here: |
|
@example |
@group |
typedef struct @{ |
void (*pretasking_hook)( void ); |
void (*predriver_hook)( void ); |
void (*postdriver_hook)( void ); |
void (*idle_task)( void ); |
boolean do_zero_of_workspace; |
unsigned32 idle_task_stack_size; |
unsigned32 interrupt_stack_size; |
unsigned32 extra_mpci_receive_server_stack; |
void * (*stack_allocate_hook)( unsigned32 ); |
void (*stack_free_hook)( void* ); |
/* end of fields required on all CPUs */ |
|
/* XXX CPU family dependent stuff */ |
@} rtems_cpu_table; |
@end group |
@end example |
|
@table @code |
@item pretasking_hook |
is the address of the user provided routine which is invoked |
once RTEMS APIs are initialized. This routine will be invoked |
before any system tasks are created. Interrupts are disabled. |
This field may be NULL to indicate that the hook is not utilized. |
|
@item predriver_hook |
is the address of the user provided |
routine that is invoked immediately before the |
the device drivers and MPCI are initialized. RTEMS |
initialization is complete but interrupts and tasking are disabled. |
This field may be NULL to indicate that the hook is not utilized. |
|
@item postdriver_hook |
is the address of the user provided |
routine that is invoked immediately after the |
the device drivers and MPCI are initialized. RTEMS |
initialization is complete but interrupts and tasking are disabled. |
This field may be NULL to indicate that the hook is not utilized. |
|
@item idle_task |
is the address of the optional user |
provided routine which is used as the system's IDLE task. If |
this field is not NULL, then the RTEMS default IDLE task is not |
used. This field may be NULL to indicate that the default IDLE |
is to be used. |
|
@item do_zero_of_workspace |
indicates whether RTEMS should |
zero the Workspace as part of its initialization. If set to |
TRUE, the Workspace is zeroed. Otherwise, it is not. |
|
@item idle_task_stack_size |
is the size of the RTEMS idle task stack in bytes. |
If this number is less than MINIMUM_STACK_SIZE, then the |
idle task's stack will be MINIMUM_STACK_SIZE in byte. |
|
@item interrupt_stack_size |
is the size of the RTEMS |
allocated interrupt stack in bytes. This value must be at least |
as large as MINIMUM_STACK_SIZE. |
|
@item extra_mpci_receive_server_stack |
is the extra stack space allocated for the RTEMS MPCI receive server task |
in bytes. The MPCI receive server may invoke nearly all directives and |
may require extra stack space on some targets. |
|
@item stack_allocate_hook |
is the address of the optional user provided routine which allocates |
memory for task stacks. If this hook is not NULL, then a stack_free_hook |
must be provided as well. |
|
@item stack_free_hook |
is the address of the optional user provided routine which frees |
memory for task stacks. If this hook is not NULL, then a stack_allocate_hook |
must be provided as well. |
|
@item XXX |
is where the CPU family dependent stuff goes. |
|
@end table |
/fatalerr.t
0,0 → 1,37
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c fatalerr.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter Default Fatal Error Processing |
|
@section Introduction |
|
Upon detection of a fatal error by either the |
application or RTEMS the fatal error manager is invoked. The |
fatal error manager will invoke the user-supplied fatal error |
handlers. If no user-supplied handlers are configured, the |
RTEMS provided default fatal error handler is invoked. If the |
user-supplied fatal error handlers return to the executive the |
default fatal error handler is then invoked. This chapter |
describes the precise operations of the default fatal error |
handler. |
|
@section Default Fatal Error Handler Operations |
|
The default fatal error handler which is invoked by |
the @code{rtems_fatal_error_occurred} directive when there is |
no user handler configured or the user handler returns control to |
RTEMS. The default fatal error handler performs the |
following actions: |
|
@itemize @bullet |
@item disables processor interrupts, |
@item places the error code in @b{r0}, and |
@item executes an infinite loop (@code{while(0);} to |
simulate a halt processor instruction. |
@end itemize |
|
/callconv.t
0,0 → 1,73
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c callconv.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter Calling Conventions |
|
@section Introduction |
|
Each high-level language compiler generates |
subroutine entry and exit code based upon a set of rules known |
as the compiler's calling convention. These rules address the |
following issues: |
|
@itemize @bullet |
@item register preservation and usage |
@item parameter passing |
@item call and return mechanism |
@end itemize |
|
A compiler's calling convention is of importance when |
interfacing to subroutines written in another language either |
assembly or high-level. Even when the high-level language and |
target processor are the same, different compilers may use |
different calling conventions. As a result, calling conventions |
are both processor and compiler dependent. |
|
@section Processor Background |
|
The ARM architecture supports a simple yet |
effective call and return mechanism. A subroutine is invoked |
via the branch and link (@code{bl}) instruction. This instruction |
saves the return address in the @code{lr} register. Returning |
from a subroutine only requires that the return address be |
moved into the program counter (@code{pc}), possibly with |
an offset. It is is important to |
note that the @code{bl} instruction does not |
automatically save or restore any registers. It is the |
responsibility of the high-level language compiler to define the |
register preservation and usage convention. |
|
@section Calling Mechanism |
|
All RTEMS directives are invoked using the @code{bl} |
instruction and return to the user application via the |
mechanism described above. |
|
@section Register Usage |
|
As discussed above, the ARM's call and return mechanism dos |
not automatically save any registers. RTEMS uses the registers |
@code{r0}, @code{r1}, @code{r2}, and @code{r3} as scratch registers and |
per ARM calling convention, the @code{lr} register is altered |
as well. These registers are not preserved by RTEMS directives |
therefore, the contents of these registers should not be assumed |
upon return from any RTEMS directive. |
|
@section Parameter Passing |
|
RTEMS assumes that ARM calling conventions are followed and that |
the first four arguments are placed in registers @code{r0} through |
@code{r3}. If there are more arguments, than that, then they |
are place on the stack. |
|
@section User-Provided Routines |
|
All user-provided routines invoked by RTEMS, such as |
user extensions, device drivers, and MPCI routines, must also |
adhere to these calling conventions. |
|
/timeBSP.t
0,0 → 1,113
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c timeBSP.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@include common/timemac.texi |
@tex |
\global\advance \smallskipamount by -4pt |
@end tex |
|
@chapter MYBSP Timing Data |
|
@section Introduction |
|
The timing data for the ARM version of RTEMS is |
provided along with the target dependent aspects concerning the |
gathering of the timing data. The hardware platform used to |
gather the times is described to give the reader a better |
understanding of each directive time provided. Also, provided |
is a description of the interrupt latency and the context switch |
times as they pertain to the ARM version of RTEMS. |
|
@section Hardware Platform |
|
All times reported except for the maximum period |
interrupts are disabled by RTEMS were measured using a Motorola |
MYBSP CPU board. The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ |
Mhz board with SDRAM and no numeric coprocessor. A |
countdown timer on this board was used to measure |
elapsed time with a 20 nanosecond resolution. All |
sources of hardware interrupts were disabled, although the |
interrupt level of the ARM microprocessor allows all interrupts. |
|
The maximum period interrupts are disabled was |
measured by summing the number of CPU cycles required by each |
assembly language instruction executed while interrupts were |
disabled. The worst case times of the ARM9DTMI microprocessor |
were used for each instruction. Zero wait state memory was |
assumed. The total CPU cycles executed with interrupts |
disabled, including the instructions to disable and enable |
interrupts, was divided by TBD to simulate a TBD Mhz processor. It |
should be noted that the worst case instruction times |
assume that the internal cache is disabled and that no |
instructions overlap. |
|
@section Interrupt Latency |
|
The maximum period with interrupts disabled within |
RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD |
microseconds including the instructions |
which disable and re-enable interrupts. The time required for |
the processor to vector an interrupt and for the RTEMS entry |
overhead before invoking the user's interrupt handler are a |
total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK |
microseconds. These combine to yield a worst case |
interrupt latency of less than |
RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK |
microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ |
Mhz. [NOTE: The maximum period with interrupts |
disabled was last determined for Release |
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
|
It should be noted again that the maximum period with |
interrupts disabled within RTEMS is hand-timed and based upon |
worst case (i.e. CPU cache disabled and no instruction overlap) |
times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor. |
The interrupt vector and entry |
overhead time was generated on an MYBSP benchmark platform |
using the Multiprocessing Communications registers to generate |
as the interrupt source. |
|
@section Context Switch |
|
The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS |
microseconds on the MYBSP benchmark platform when no floating |
point context is saved or restored. Additional execution time |
is required when a TASK_SWITCH user extension is configured. |
The use of the TASK_SWITCH extension is application dependent. |
Thus, its execution time is not considered part of the raw |
context switch time. |
|
The ARM processor benchmarked does not have a floating point |
unit and consequently no FPU results are reported. |
|
@c Since RTEMS was designed specifically for embedded |
@c missile applications which are floating point intensive, the |
@c executive is optimized to avoid unnecessarily saving and |
@c restoring the state of the numeric coprocessor. The state of |
@c the numeric coprocessor is only saved when an FLOATING_POINT |
@c task is dispatched and that task was not the last task to |
@c utilize the coprocessor. In a system with only one |
@c FLOATING_POINT task, the state of the numeric coprocessor will |
@c never be saved or restored. When the first FLOATING_POINT task |
@c is dispatched, RTEMS does not need to save the current state of |
@c the numeric coprocessor. |
|
@c The exact amount of time required to save and restore |
@c floating point context is dependent on whether an XXX or |
@c XXX is being used as well as the state of the numeric |
@c coprocessor. These numeric coprocessors define three operating |
@c states: initialized, idle, and busy. RTEMS places the |
@c coprocessor in the initialized state when a task is started or |
@c restarted. Once the task has utilized the coprocessor, it is in |
@c the idle state when floating point instructions are not |
@c executing and the busy state when floating point instructions |
@c are executing. The state of the coprocessor is task specific. |
|
The following table summarizes the context switch |
times for the MYBSP benchmark platform: |
|
/wksheets.texi
0,0 → 1,437
@c ****** This comment is here to remind you not to edit the wksheets.t |
@c ****** in any directory but common. |
@c |
@c Figures ... |
@c RTEMS RAM Workspace Worksheet |
@c RTEMS Code Space Worksheet |
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c wksheets.texi,v 1.2 2002/08/02 00:45:38 joel Exp |
@c |
|
|
@node Memory Requirements, Memory Requirements Introduction, Processor Dependent Information Table CPU Dependent Information Table, Top |
|
@chapter Memory Requirements |
@ifinfo |
@menu |
* Memory Requirements Introduction:: |
* Memory Requirements Data Space Requirements:: |
* Memory Requirements Minimum and Maximum Code Space Requirements:: |
* Memory Requirements RTEMS Code Space Worksheet:: |
* Memory Requirements RTEMS RAM Workspace Worksheet:: |
@end menu |
@end ifinfo |
|
|
@node Memory Requirements Introduction, Memory Requirements Data Space Requirements, Memory Requirements, Memory Requirements |
|
@section Introduction |
|
Memory is typically a limited resource in real-time |
embedded systems, therefore, RTEMS can be configured to utilize |
the minimum amount of memory while meeting all of the |
applications requirements. Worksheets are provided which allow |
the RTEMS application developer to determine the amount of RTEMS |
code and RAM workspace which is required by the particular |
configuration. Also provided are the minimum code space, |
maximum code space, and the constant data space required by |
RTEMS. |
|
|
@node Memory Requirements Data Space Requirements, Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements Introduction, Memory Requirements |
|
@section Data Space Requirements |
|
RTEMS requires a small amount of memory for its |
private variables. This data area must be in RAM and is |
separate from the RTEMS RAM Workspace. The following |
illustrates the data space required for all configurations of |
RTEMS: |
|
@itemize @bullet |
@item Data Space: na |
@end itemize |
|
|
@node Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements RTEMS Code Space Worksheet, Memory Requirements Data Space Requirements, Memory Requirements |
|
@section Minimum and Maximum Code Space Requirements |
|
A maximum configuration of RTEMS includes the core |
and all managers, including the multiprocessing manager. |
Conversely, a minimum configuration of RTEMS includes only the |
core and the following managers: initialization, task, interrupt |
and fatal error. The following illustrates the code space |
required by these configurations of RTEMS: |
|
@itemize @bullet |
@item Minimum Configuration: na |
@item Maximum Configuration: na |
@end itemize |
|
|
@node Memory Requirements RTEMS Code Space Worksheet, Memory Requirements RTEMS RAM Workspace Worksheet, Memory Requirements Minimum and Maximum Code Space Requirements, Memory Requirements |
|
@section RTEMS Code Space Worksheet |
|
The RTEMS Code Space Worksheet is a tool provided to |
aid the RTEMS application designer to accurately calculate the |
memory required by the RTEMS run-time environment. RTEMS allows |
the custom configuration of the executive by optionally |
excluding managers which are not required by a particular |
application. This worksheet provides the included and excluded |
size of each manager in tabular form allowing for the quick |
calculation of any custom configuration of RTEMS. The RTEMS |
Code Space Worksheet is below: |
|
@ifset use-ascii |
@page |
@end ifset |
@ifset use-tex |
@page |
@end ifset |
|
@page |
@center @b{RTEMS Code Space Worksheet} |
@sp 1 |
|
@ifset use-ascii |
|
The following is a list of the components of the RTEMS code space. The first |
number in parentheses is the size when the component is included, |
while the second number indicates its size when not included. If the second |
number is "NA", then the component must always be included. |
|
@itemize @bullet |
@item Core (na, NA) |
@item Initialization (na, NA) |
@item Task (na, NA) |
@item Interrupt (na, NA) |
@item Clock (na, NA) |
@item Timer (na, na) |
@item Semaphore (na, na) |
@item Message (na, na) |
@item Event (na, na) |
@item Signal (na, na) |
@item Partition (na, na) |
@item Region (na, na) |
@item Dual Ported Memory (na, na) |
@item I/O (na, na) |
@item Fatal Error (na, NA) |
@item Rate Monotonic (na, na) |
@item Multiprocessing (na, na) |
@end itemize |
@end ifset |
|
@ifset use-tex |
|
@tex |
\line{\hskip 0.50in\vbox{\offinterlineskip\halign{ |
\vrule\strut#& |
\hbox to 2.25in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 1.00in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 1.00in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 1.25in{\enskip\hfil#\hfil}& |
\vrule#\cr |
\noalign{\hrule} |
&\bf Component && \bf Included && \bf Not Included && \bf Size &\cr\noalign{\hrule} |
&Core && na && NA && &\cr\noalign{\hrule} |
&Initialization && na && NA && &\cr\noalign{\hrule} |
&Task && na && NA && &\cr\noalign{\hrule} |
&Interrupt && na && NA && &\cr\noalign{\hrule} |
&Clock && na && NA && &\cr\noalign{\hrule} |
&Timer && na && na && &\cr\noalign{\hrule} |
&Semaphore && na && na && &\cr\noalign{\hrule} |
&Message && na && na && &\cr\noalign{\hrule} |
&Event && na && na && &\cr\noalign{\hrule} |
&Signal && na && na && &\cr\noalign{\hrule} |
&Partition && na && na && &\cr\noalign{\hrule} |
&Region && na && na && &\cr\noalign{\hrule} |
&Dual Ported Memory && na && na && &\cr\noalign{\hrule} |
&I/O && na && na && &\cr\noalign{\hrule} |
&Fatal Error && na && NA && &\cr\noalign{\hrule} |
&Rate Monotonic && na && na && &\cr\noalign{\hrule} |
&Multiprocessing && na && na && &\cr\noalign{\hrule} |
&\multispan 5 \bf\hfil Total Code Space Requirements\qquad\hfil&&&\cr\noalign{\hrule} |
}}\hfil} |
@end tex |
@end ifset |
|
@ifset use-html |
@html |
<CENTER> |
<TABLE COLS=4 WIDTH="80%" BORDER=2> |
<TR><TD ALIGN=center><STRONG>Component</STRONG></TD> |
<TD ALIGN=center><STRONG>Included</STRONG></TD> |
<TD ALIGN=center><STRONG>Not Included</STRONG></TD> |
<TD ALIGN=center><STRONG>Size</STRONG></TD></TR> |
<TR><TD ALIGN=center>Core</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>NA</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Initialization</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>NA</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Task</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>NA</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Interrupt</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>NA</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Clock</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>NA</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Timer</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Semaphore</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Message</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Event</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Signal</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Partition</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Region</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Dual Ported Memory</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>I/O</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Fatal Error</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>NA</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Rate Monotonic</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center>Multiprocessing</TD> |
<TD ALIGN=center>na</TD> |
<TD ALIGN=center>na</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=center COLSPAN=3> |
<STRONG>Total Code Space Requirements</STRONG></TD> |
<TD><BR></TD></TR> |
</TABLE> |
</CENTER> |
@end html |
@end ifset |
|
@page |
|
@c ****** Next node is set by a sed script in the document Makefile. |
@c ****** This comment is here to remind you not to edit the wksheets.t |
@c ****** in any directory but common. |
|
|
@node Memory Requirements RTEMS RAM Workspace Worksheet, Timing Specification, Memory Requirements RTEMS Code Space Worksheet, Memory Requirements |
|
@section RTEMS RAM Workspace Worksheet |
|
The RTEMS RAM Workspace Worksheet is a tool provided |
to aid the RTEMS application designer to accurately calculate |
the minimum memory block to be reserved for RTEMS use. This |
worksheet provides equations for calculating the amount of |
memory required based upon the number of objects configured, |
whether for single or multiple processor versions of the |
executive. This information is presented in tabular form, along |
with the fixed system requirements, allowing for quick |
calculation of any application defined configuration of RTEMS. |
The RTEMS RAM Workspace Worksheet is provided below: |
|
@ifset use-ascii |
@page |
@end ifset |
@ifset use-tex |
@sp 2 |
@end ifset |
|
@center @b{RTEMS RAM Workspace Worksheet} |
@sp 2 |
|
@ifset use-ascii |
The total RTEMS RAM Workspace required is the sum of the following: |
|
@itemize @bullet |
@item maximum_tasks * na |
@item maximum_timers * na |
@item maximum_semaphores * na |
@item maximum_message_queues * na |
@item maximum_regions * na |
@item maximum_partitions * na |
@item maximum_ports * na |
@item maximum_periods * na |
@item maximum_extensions * na |
@item Floating Point Tasks * na |
@item Task Stacks |
@item maximum_nodes * na |
@item maximum_global_objects * na |
@item maximum_proxies * na |
@item Fixed System Requirements of na |
@end itemize |
@end ifset |
|
@ifset use-tex |
@tex |
\line{\hskip 0.75in\vbox{\offinterlineskip\halign{ |
\vrule\strut#& |
\hbox to 3.0in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 0.75in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 1.25in{\enskip\hfil#\hfil}& |
\vrule#\cr |
\noalign{\hrule} |
& \bf Description && \bf Equation && \bf Bytes Required &\cr\noalign{\hrule} |
& maximum\_tasks && * na = &&&\cr\noalign{\hrule} |
& maximum\_timers && * na = &&&\cr\noalign{\hrule} |
& maximum\_semaphores && * na = &&&\cr\noalign{\hrule} |
& maximum\_message\_queues && * na = &&&\cr\noalign{\hrule} |
& maximum\_regions && * na = &&&\cr\noalign{\hrule} |
& maximum\_partitions && * na = &&&\cr\noalign{\hrule} |
& maximum\_ports && * na = &&&\cr\noalign{\hrule} |
& maximum\_periods && * na = &&&\cr\noalign{\hrule} |
& maximum\_extensions && * na = &&&\cr\noalign{\hrule} |
& Floating Point Tasks && * na = &&&\cr\noalign{\hrule} |
& Task Stacks &&\hskip 2.3em=&&&\cr\noalign{\hrule} |
& Total Single Processor Requirements &&&&&\cr\noalign{\hrule} |
}}\hfil} |
|
\line{\hskip 0.75in\vbox{\offinterlineskip\halign{ |
\vrule\strut#& |
\hbox to 3.0in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 0.75in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 1.25in{\enskip\hfil#\hfil}& |
\vrule#\cr |
\noalign{\hrule} |
& \bf Description && \bf Equation && \bf Bytes Required &\cr\noalign{\hrule} |
& maximum\_nodes && * na = &&&\cr\noalign{\hrule} |
& maximum\_global\_objects && * na = &&&\cr\noalign{\hrule} |
& maximum\_proxies && * na = &&&\cr\noalign{\hrule} |
}}\hfil} |
|
\line{\hskip 0.75in\vbox{\offinterlineskip\halign{ |
\vrule\strut#& |
\hbox to 3.0in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 0.75in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 1.25in{\enskip\hfil#\hfil}& |
\vrule#\cr |
\noalign{\hrule} |
& Total Multiprocessing Requirements &&&&&\cr\noalign{\hrule} |
& Fixed System Requirements && na &&&\cr\noalign{\hrule} |
& Total Single Processor Requirements &&&&&\cr\noalign{\hrule} |
& Total Multiprocessing Requirements &&&&&\cr\noalign{\hrule} |
& Minimum Bytes for RTEMS Workspace &&&&&\cr\noalign{\hrule} |
}}\hfil} |
@end tex |
@end ifset |
|
@ifset use-html |
@html |
<CENTER> |
<TABLE COLS=3 WIDTH="80%" BORDER=2> |
<TR><TD ALIGN=center><STRONG>Description</STRONG></TD> |
<TD ALIGN=center><STRONG>Equation</STRONG></TD> |
<TD ALIGN=center><STRONG>Bytes Required</STRONG></TD></TR> |
<TR><TD ALIGN=left>maximum_tasks</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_timers</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_semaphores</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_message_queues</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_regions</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_partitions</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_ports</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_periods</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_extensions</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>Floating Point Tasks</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left COLSPAN=2>Task Stacks</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left COLSPAN=2> |
<STRONG>Total Single Processor Requirements</STRONG></TD> |
<TD><BR></TD></TR> |
<TR></TR> |
<TR><TD ALIGN=center><STRONG>Description</STRONG></TD> |
<TD ALIGN=center><STRONG>Equation</STRONG></TD> |
<TD ALIGN=center><STRONG>Bytes Required</STRONG></TD></TR> |
<TR><TD ALIGN=left>maximum_nodes</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_global_objects</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left>maximum_proxies</TD> |
<TD ALIGN=right>* na =</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left COLSPAN=2> |
<STRONG>Total Multiprocessing Requirements</STRONG></TD> |
<TD><BR></TD></TR> |
<TR></TR> |
<TR><TD ALIGN=left COLSPAN=2>Fixed System Requirements</TD> |
<TD ALIGN=center>na</TD></TR> |
<TR><TD ALIGN=left COLSPAN=2>Total Single Processor Requirements</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left COLSPAN=2>Total Multiprocessing Requirements</TD> |
<TD><BR></TD></TR> |
<TR><TD ALIGN=left COLSPAN=2> |
<STRONG>Minimum Bytes for RTEMS Workspace</STRONG></TD> |
<TD><BR></TD></TR> |
</TABLE> |
</CENTER> |
@end html |
@end ifset |
|
|
/Makefile.am
0,0 → 1,109
# |
# COPYRIGHT (c) 1988-2002. |
# On-Line Applications Research Corporation (OAR). |
# All rights reserved. |
# |
# Makefile.am,v 1.1 2002/07/30 21:43:53 joel Exp |
# |
|
|
PROJECT = arm |
EDITION = 1 |
|
include $(top_srcdir)/project.am |
include $(top_srcdir)/supplements/supplement.am |
|
GENERATED_FILES = cpumodel.texi callconv.texi memmodel.texi intr.texi \ |
fatalerr.texi bsp.texi cputable.texi wksheets.texi timing.texi \ |
timeBSP.texi |
COMMON_FILES = $(top_srcdir)/common/setup.texi \ |
$(top_srcdir)/common/cpright.texi $(top_srcdir)/common/timemac.texi |
|
FILES = preface.texi |
|
info_TEXINFOS = arm.texi |
arm_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) |
|
# |
# Chapters which get automatic processing |
# |
|
$(srcdir)/cpumodel.texi: cpumodel.t |
$(BMENU2) -p "Preface" \ |
-u "Top" \ |
-n "Calling Conventions" < $< > $@ |
|
$(srcdir)/callconv.texi: callconv.t |
$(BMENU2) -p "CPU Model Dependent Features Floating Point Unit" \ |
-u "Top" \ |
-n "Memory Model" < $< > $@ |
|
$(srcdir)/memmodel.texi: memmodel.t |
$(BMENU2) -p "Calling Conventions User-Provided Routines" \ |
-u "Top" \ |
-n "Interrupt Processing" < $< > $@ |
|
# Interrupt Chapter: |
# 1. Replace Times and Sizes |
# 2. Build Node Structure |
$(srcdir)/intr.texi: intr_NOTIMES.t BSP_TIMES |
${REPLACE2} -p $(srcdir)/BSP_TIMES $(srcdir)/intr_NOTIMES.t | \ |
$(BMENU2) -p "Memory Model Flat Memory Model" \ |
-u "Top" \ |
-n "Default Fatal Error Processing" > $@ |
|
$(srcdir)/fatalerr.texi: fatalerr.t |
$(BMENU2) -p "Interrupt Processing Interrupt Stack" \ |
-u "Top" \ |
-n "Board Support Packages" < $< > $@ |
|
$(srcdir)/bsp.texi: bsp.t |
$(BMENU2) -p "Default Fatal Error Processing Default Fatal Error Handler Operations" \ |
-u "Top" \ |
-n "Processor Dependent Information Table" < $< > $@ |
|
$(srcdir)/cputable.texi: cputable.t |
$(BMENU2) -p "Board Support Packages Processor Initialization" \ |
-u "Top" \ |
-n "Memory Requirements" < $< > $@ |
|
# Worksheets Chapter: |
# 1. Obtain the Shared File |
# 2. Replace Times and Sizes |
# 3. Build Node Structure |
|
$(srcdir)/wksheets.texi: $(top_srcdir)/common/wksheets.t BSP_TIMES |
${REPLACE2} -p $(srcdir)/BSP_TIMES \ |
$(top_srcdir)/common/wksheets.t | \ |
$(BMENU2) -p "Processor Dependent Information Table CPU Dependent Information Table" \ |
-u "Top" \ |
-n "Timing Specification" > $@ |
|
# Timing Specification Chapter: |
# 1. Copy the Shared File |
# 3. Build Node Structure |
|
$(srcdir)/timing.texi: $(top_srcdir)/common/timing.t |
$(BMENU2) -p "Memory Requirements RTEMS RAM Workspace Worksheet" \ |
-u "Top" \ |
-n "MYBSP Timing Data" < $< > $@ |
|
# Timing Data for BSP BSP Chapter: |
# 1. Copy the Shared File |
# 2. Replace Times and Sizes |
# 3. Build Node Structure |
|
$(srcdir)/timeBSP.texi: $(top_srcdir)/common/timetbl.t timeBSP.t |
cat $(srcdir)/timeBSP.t $(top_srcdir)/common/timetbl.t >timeBSP_.t |
@echo >>timeBSP_.t |
@echo "@tex" >>timeBSP_.t |
@echo "\\global\\advance \\smallskipamount by 4pt" >>timeBSP_.t |
@echo "@end tex" >>timeBSP_.t |
${REPLACE2} -p $(srcdir)/BSP_TIMES timeBSP_.t | \ |
$(BMENU2) -p "Timing Specification Terminology" \ |
-u "Top" \ |
-n "Command and Variable Index" > $@ |
CLEANFILES += timeBSP_.t |
|
EXTRA_DIST = BSP_TIMES bsp.t callconv.t cpumodel.t cputable.t fatalerr.t \ |
intr_NOTIMES.t memmodel.t timeBSP.t |
/cpumodel.t
0,0 → 1,85
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c cpumodel.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter CPU Model Dependent Features |
|
@section Introduction |
|
Microprocessors are generally classified into |
families with a variety of CPU models or implementations within |
that family. Within a processor family, there is a high level |
of binary compatibility. This family may be based on either an |
architectural specification or on maintaining compatibility with |
a popular processor. Recent microprocessor families such as the |
ARM, SPARC, and PA-RISC are based on an architectural specification |
which is independent or any particular CPU model or |
implementation. Older families such as the M68xxx and the iX86 |
evolved as the manufacturer strived to produce higher |
performance processor models which maintained binary |
compatibility with older models. |
|
RTEMS takes advantage of the similarity of the |
various models within a CPU family. Although the models do vary |
in significant ways, the high level of compatibility makes it |
possible to share the bulk of the CPU dependent executive code |
across the entire family. Each processor family supported by |
RTEMS has a list of features which vary between CPU models |
within a family. For example, the most common model dependent |
feature regardless of CPU family is the presence or absence of a |
floating point unit or coprocessor. When defining the list of |
features present on a particular CPU model, one simply notes |
that floating point hardware is or is not present and defines a |
single constant appropriately. Conditional compilation is |
utilized to include the appropriate source code for this CPU |
model's feature set. It is important to note that this means |
that RTEMS is thus compiled using the appropriate feature set |
and compilation flags optimal for this CPU model used. The |
alternative would be to generate a binary which would execute on |
all family members using only the features which were always |
present. |
|
This chapter presents the set of features which vary |
across ARM implementations and are of importance to RTEMS. |
The set of CPU model feature macros are defined in the file |
cpukit/score/cpu/arm/rtems/score/arm.h based upon the particular CPU |
model defined on the compilation command line. |
|
@section CPU Model Name |
|
The macro @code{CPU_MODEL_NAME} is a string which designates |
the architectural level of this CPU model. The following is |
a list of the settings for this string based upon @code{gcc} |
CPU model predefines: |
|
@example |
__ARM_ARCH4__ "ARMv4" |
__ARM_ARCH4T__ "ARMv4T" |
__ARM_ARCH5__ "ARMv5" |
__ARM_ARCH5T__ "ARMv5T" |
__ARM_ARCH5E__ "ARMv5E" |
__ARM_ARCH5TE__ "ARMv5TE" |
@end example |
|
@section Count Leading Zeroes Instruction |
|
The macro @code{ARM_HAS_CLZ} is set to 1 to indicate that |
the architectural version has the @code{clz} instruction. |
On ARM architectural version 5 and above, the count |
leading zeroes instruction (@code{clz}) is available and |
can be used to speed up the find first bit operation. |
The use of this instruction significantly speeds up the |
scheduling associated with a thread blocking. |
|
@section Floating Point Unit |
|
The macro ARM_HAS_FPU is set to 1 to indicate that |
this CPU model has a hardware floating point unit and 0 |
otherwise. It does not matter whether the hardware floating |
point support is incorporated on-chip or is an external |
coprocessor. |
|
/intr_NOTIMES.t
0,0 → 1,196
@c |
@c Interrupt Stack Frame Picture |
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c intr_NOTIMES.t,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@chapter Interrupt Processing |
|
@section Introduction |
|
Different types of processors respond to the |
occurrence of an interrupt in its own unique fashion. In |
addition, each processor type provides a control mechanism to |
allow for the proper handling of an interrupt. The processor |
dependent response to the interrupt modifies the current |
execution state and results in a change in the execution stream. |
Most processors require that an interrupt handler utilize some |
special control mechanisms to return to the normal processing |
stream. Although RTEMS hides many of the processor dependent |
details of interrupt processing, it is important to understand |
how the RTEMS interrupt manager is mapped onto the processor's |
unique architecture. Discussed in this chapter are the XXX's |
interrupt response and control mechanisms as they pertain to |
RTEMS. |
|
@section Vectoring of an Interrupt Handler |
|
Depending on whether or not the particular CPU |
supports a separate interrupt stack, the XXX family has two |
different interrupt handling models. |
|
@subsection Models Without Separate Interrupt Stacks |
|
Upon receipt of an interrupt the XXX family |
members without separate interrupt stacks automatically perform |
the following actions: |
|
@itemize @bullet |
@item To Be Written |
@end itemize |
|
@subsection Models With Separate Interrupt Stacks |
|
Upon receipt of an interrupt the XXX family |
members with separate interrupt stacks automatically perform the |
following actions: |
|
@itemize @bullet |
@item saves the current status register (SR), |
|
@item clears the master/interrupt (M) bit of the SR to |
indicate the switch from master state to interrupt state, |
|
@item sets the privilege mode to supervisor, |
|
@item suppresses tracing, |
|
@item sets the interrupt mask level equal to the level of the |
interrupt being serviced, |
|
@item pushes an interrupt stack frame (ISF), which includes |
the program counter (PC), the status register (SR), and the |
format/exception vector offset (FVO) word, onto the supervisor |
and interrupt stacks, |
|
@item switches the current stack to the interrupt stack and |
vectors to an interrupt service routine (ISR). If the ISR was |
installed with the interrupt_catch directive, then the RTEMS |
interrupt handler will begin execution. The RTEMS interrupt |
handler saves all registers which are not preserved according to |
the calling conventions and invokes the application's ISR. |
@end itemize |
|
A nested interrupt is processed similarly by these |
CPU models with the exception that only a single ISF is placed |
on the interrupt stack and the current stack need not be |
switched. |
|
The FVO word in the Interrupt Stack Frame is examined |
by RTEMS to determine when an outer most interrupt is being |
exited. Since the FVO is used by RTEMS for this purpose, the |
user application code MUST NOT modify this field. |
|
The following shows the Interrupt Stack Frame for |
XXX CPU models with separate interrupt stacks: |
|
@ifset use-ascii |
@example |
@group |
+----------------------+ |
| Status Register | 0x0 |
+----------------------+ |
| Program Counter High | 0x2 |
+----------------------+ |
| Program Counter Low | 0x4 |
+----------------------+ |
| Format/Vector Offset | 0x6 |
+----------------------+ |
@end group |
@end example |
@end ifset |
|
@ifset use-tex |
@sp 1 |
@tex |
\centerline{\vbox{\offinterlineskip\halign{ |
\strut\vrule#& |
\hbox to 2.00in{\enskip\hfil#\hfil}& |
\vrule#& |
\hbox to 0.50in{\enskip\hfil#\hfil} |
\cr |
\multispan{3}\hrulefill\cr |
& Status Register && 0x0\cr |
\multispan{3}\hrulefill\cr |
& Program Counter High && 0x2\cr |
\multispan{3}\hrulefill\cr |
& Program Counter Low && 0x4\cr |
\multispan{3}\hrulefill\cr |
& Format/Vector Offset && 0x6\cr |
\multispan{3}\hrulefill\cr |
}}\hfil} |
@end tex |
@end ifset |
|
@ifset use-html |
@html |
<CENTER> |
<TABLE COLS=2 WIDTH="40%" BORDER=2> |
<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD> |
<TD ALIGN=center>0x0</TD></TR> |
<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD> |
<TD ALIGN=center>0x2</TD></TR> |
<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD> |
<TD ALIGN=center>0x4</TD></TR> |
<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD> |
<TD ALIGN=center>0x6</TD></TR> |
</TABLE> |
</CENTER> |
@end html |
@end ifset |
|
@section Interrupt Levels |
|
Eight levels (0-7) of interrupt priorities are |
supported by XXX family members with level seven (7) being |
the highest priority. Level zero (0) indicates that interrupts |
are fully enabled. Interrupt requests for interrupts with |
priorities less than or equal to the current interrupt mask |
level are ignored. |
|
Although RTEMS supports 256 interrupt levels, the |
XXX family only supports eight. RTEMS interrupt levels 0 |
through 7 directly correspond to XXX interrupt levels. All |
other RTEMS interrupt levels are undefined and their behavior is |
unpredictable. |
|
@section Disabling of Interrupts by RTEMS |
|
During the execution of directive calls, critical |
sections of code may be executed. When these sections are |
encountered, RTEMS disables interrupts to level seven (7) before |
the execution of this section and restores them to the previous |
level upon completion of the section. RTEMS has been optimized |
to insure that interrupts are disabled for less than |
RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a |
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor with |
zero wait states. These numbers will vary based the |
number of wait states and processor speed present on the target board. |
[NOTE: The maximum period with interrupts disabled is hand calculated. This |
calculation was last performed for Release |
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
|
Non-maskable interrupts (NMI) cannot be disabled, and |
ISRs which execute at this level MUST NEVER issue RTEMS system |
calls. If a directive is invoked, unpredictable results may |
occur due to the inability of RTEMS to protect its critical |
sections. However, ISRs that make no system calls may safely |
execute as non-maskable interrupts. |
|
@section Interrupt Stack |
|
RTEMS allocates the interrupt stack from the |
Workspace Area. The amount of memory allocated for the |
interrupt stack is determined by the interrupt_stack_size field |
in the CPU Configuration Table. During the initialization |
process, RTEMS will install its interrupt stack. |
|
The XXX port of RTEMS supports a software managed |
dedicated interrupt stack on those CPU models which do not |
support a separate interrupt stack in hardware. |
|
|
/preface.texi
0,0 → 1,49
@c |
@c COPYRIGHT (c) 1988-2002. |
@c On-Line Applications Research Corporation (OAR). |
@c All rights reserved. |
@c |
@c preface.texi,v 1.1 2002/07/30 21:43:53 joel Exp |
@c |
|
@ifinfo |
@node Preface, CPU Model Dependent Features, Top, Top |
@end ifinfo |
@unnumbered Preface |
|
The Real Time Executive for Multiprocessor Systems (RTEMS) |
is designed to be portable across multiple processor |
architectures. However, the nature of real-time systems makes |
it essential that the application designer understand certain |
processor dependent implementation details. These processor |
dependencies include calling convention, board support package |
issues, interrupt processing, exact RTEMS memory requirements, |
performance data, header files, and the assembly language |
interface to the executive. |
|
This document discusses the ARM architecture dependencies |
in this port of RTEMS. The ARM family has a wide variety |
of implementations by a wide range of vendors. Consequently, |
there are 100's of CPU models within it. |
|
It is highly recommended that the ARM |
RTEMS application developer obtain and become familiar with the |
documentation for the processor being used as well as the |
documentation for the ARM architecture as a whole. |
|
@subheading Architecture Documents |
|
For information on the ARM architecture, |
refer to the following documents available from Arm, Limited |
(@file{http//www.arm.com/}). There does not appear to |
be an electronic version of a manual on the architecture |
in general on that site. The following book is a good |
resource: |
|
@itemize @bullet |
@item @cite{David Seal. "ARM Architecture Reference Manual." |
Addison-Wesley. @b{ISBN 0-201-73719-1}. 2001.} |
|
@end itemize |
|
|
.
Property changes :
Added: svn:ignore
## -0,0 +1,36 ##
+Makefile
+Makefile.in
+bsp.texi
+callconv.texi
+cpumodel.texi
+cputable.texi
+fatalerr.texi
+arm
+arm*.html
+arm-?
+arm-??
+arm.aux
+arm.cp
+arm.dvi
+arm.fn
+arm.ky
+arm.log
+arm.pdf
+arm.pg
+arm.ps
+arm.toc
+arm.tp
+arm.vr
+index.html
+intr.t
+intr.texi
+mdate-sh
+memmodel.texi
+timeBSP_.t
+timeBSP.texi
+timing.t
+timing.texi
+wksheets.t
+wksheets.texi
+rtems_header.html
+rtems_footer.html