Changed section numbers.

11 files changed, 86 insertions, 93 deletions

diff --git a/doc/bsp_howto/Makefile b/doc/bsp_howto/Makefile
index d258548d73..4bb613362c 100644
--- a/doc/bsp_howto/Makefile
+++ b/doc/bsp_howto/Makefile
@@ -21,7 +21,7 @@ COMMON_FILES=../common/cpright.texi ../common/setup.texi
 GENERATED_FILES= clock.texi console.texi init.texi intro.texi \
     linkcmds.texi bspstruct.texi makefiles.texi target.texi timer.texi
 
-FILES= $(PROJECT).texi versions.texi $(GENERATED_FILES)
+FILES= $(PROJECT).texi $(GENERATED_FILES)
 
 INFOFILES=$(wildcard $(PROJECT) $(PROJECT)-*)
 
@@ -45,47 +45,47 @@ $(PROJECT).dvi: $(FILES)
 	texi2dvi -v $(PROJECT).texi
 
 intro.texi: intro.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 target.texi: target.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 bspstruct.texi: bspstruct.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 makefiles.texi: makefiles.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 linkcmds.texi: linkcmds.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 init.texi: init.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 clock.texi: clock.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 console.texi: console.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
 timer.texi: timer.t Makefile
-	$(BMENU) -c -p "" \
+	$(BMENU) -p "" \
 	    -u "Top" \
 	    -n "" ${*}.t
 
diff --git a/doc/bsp_howto/bsp_howto.texi b/doc/bsp_howto/bsp_howto.texi
index eb3cd1dde2..8ca794a195 100644
--- a/doc/bsp_howto/bsp_howto.texi
+++ b/doc/bsp_howto/bsp_howto.texi
@@ -21,11 +21,6 @@
 
 @include ../common/setup.texi
 
-@c
-@c  Now set all the tool version dependent information
-@c
-@include versions.texi
-
 @ignore
 @ifinfo
 @format
@@ -78,8 +73,8 @@ END-INFO-DIR-ENTRY
 @include timer.texi
 
 @ifinfo
-@node Top, Introduction, (dir), (dir)
-@top started
+@node Top, , (dir), (dir)
+@top bsp_howto
 
 This is the online version of the Getting Started with RTEMS for C/C++ Users.
 
diff --git a/doc/bsp_howto/bspstruct.t b/doc/bsp_howto/bspstruct.t
index 9715c4fa73..b957b1e035 100644
--- a/doc/bsp_howto/bspstruct.t
+++ b/doc/bsp_howto/bspstruct.t
@@ -6,7 +6,7 @@
 @c  $Id$
 @c
 
-@chapter = Board Support Package Structure
+@chapter Board Support Package Structure
 
 The BSP are all kept in the $RTEMS_ROOT/c/src/lib/libbsp directory. They
 are filed under the processor family (m68k, powerpc, etc.). A given BSP
diff --git a/doc/bsp_howto/clock.t b/doc/bsp_howto/clock.t
index 65f55e0a16..a00eb0f769 100644
--- a/doc/bsp_howto/clock.t
+++ b/doc/bsp_howto/clock.t
@@ -6,9 +6,9 @@
 @c  $Id$
 @c
 
-@chapter = Clock Driver
+@chapter Clock Driver
 
-@subsection = Introduction
+@section Introduction
 
 The clock driver aims at giving a steady time basis to the kernel, so that
 the RTEMS primitives that need a clock tick work properly. <insert a link
@@ -16,9 +16,9 @@ to the Clock Driver defs>
 
 The clock driver is located in the clock directory of the BSP. 
 
-@subsection = Primitives
+@section Primitives
 
-@subsection = Initialization
+@section Initialization
 
 The major and minor numbers of the clock driver can be made available to
 the others, such as the Shared Memory Driver. 
@@ -36,7 +36,7 @@ the VBR:
 rtems_interrupt_catch (InterruptHandler, CONSOLE_VECTOR, &old_handler); 
 @end example
 
-@subsection = The clock interrupt subroutine
+@section The clock interrupt subroutine
 
 It only has to inform the kernel that a ticker has elapsed, so call : 
 
diff --git a/doc/bsp_howto/console.t b/doc/bsp_howto/console.t
index 0196f378bc..8ed64be4bc 100644
--- a/doc/bsp_howto/console.t
+++ b/doc/bsp_howto/console.t
@@ -6,9 +6,9 @@
 @c  $Id$
 @c
 
-@chapter = Console Driver
+@chapter Console Driver
 
-@subsection = Introduction
+@section Introduction
 
 This chapter describes how to do a console driver using RTEMS Termios
 support. 
@@ -28,7 +28,7 @@ line, tabulations, etc...) recognition and processing,
 We may think that one need two serial drivers to deal with those two types
 of data, but Termios permits having only one driver. 
 
-@subsection = Termios
+@section Termios
 
 Termios is a standard for terminal management, included in several Unix
 versions. Termios is good because: 
@@ -57,7 +57,7 @@ Timeout.
 For more information on Termios, type man termios in your Unix box or go
 to http://www.freebsd.org/cgi/man.cgi. 
 
-@subsection = Driver Functioning Modes
+@section Driver Functioning Modes
 
 There are generally two main functioning modes for an UART (Universal
 Asynchronous Receiver-Transmitter, i.e. the serial chip): 
@@ -82,7 +82,7 @@ remaining in the output buffer the same way.
 
 @end itemize
 
-@subsection = Serial Driver Functioning Overview
+@section Serial Driver Functioning Overview
 
 Figure 5 is an attempt of showing how a Termios driven serial driver works : 
 
@@ -99,7 +99,7 @@ $RTEMS_ROOT/c/src/lib/libc directory,
 
 @end itemize
 
-@subsection = Polled I/O
+@section Termios and Polled I/O
 
 You have to point Termios out which functions are used for simple
 character input/output: 
@@ -112,17 +112,17 @@ Description
 @example
 int pollWrite (int minor, const char *buf, int len) 
 
-for (i=0; i<len; i++) {
+for (i=0; i<len; i++) @{
      put buf[i] into the UART channel minor
      wait for the character to be transmitted
      on the serial line
-}
+@}
 int pollread(int minor)
 @end example
 
 wait for a character to be available in the UART channel minor, then return it.
 
-@subsection = Interrupted I/O
+@section Termios and Interrupt Driven I/O
 
 The UART generally generates interrupts when it is ready to accept or to
 emit a number of characters. In this mode, the interrupt subroutine is the
@@ -162,7 +162,7 @@ UART.
 
 Figure 5: general TERMIOS driven serial driver functioning
 
-@subsection = Initialization
+@section Initialization
 
 The driver initialization is called once during RTEMS initialization
 process. 
@@ -200,7 +200,7 @@ rtems_io_register_name ("dev/console", major, i);
 
 @end itemize
 
-@subsection = Opening a serial device
+@section Opening a serial device
 
 The console device is opened during RTEMS initialization but the
 console_open function is called when a new device is opened. For instance,
@@ -217,17 +217,17 @@ The gen68340 BSP defines two kinds of callbacks:
 
 @item functions to use with polled input/output,
 
-@item functions to use with interrupted input/output. 
+@item functions to use with interrupt input/output. 
 
 @end itemize
 
-@subsubsection = Polled I/O
+@ection Polled I/O
 
 You have to point Termios out which functions are used for simple
 character input/output, i.e. pointers to pollWrite and pollRead functions
 defined in 8.4.1. 
 
-@subsubsection = Interrupted I/O
+@ection Interrupt Driven I/O
 
 Driver functioning is quite different in this mode. You can see there's no
 read function passed to Termios. Indeed a console_read call returns the
@@ -236,14 +236,14 @@ interrupt subroutine (cf. 8.4.2).
 
 But you actually have to provide a pointer to the InterruptWrite function. 
 
-@subsection = Closing a serial device
+@section Closing a serial device
 
 The driver entry point is: console_close. 
 
 You just have to notify Termios that the serial device was closed, with a
 call to rtems_termios_close. 
 
-@subsection = Reading characters from the serial device
+@section Reading characters from the serial device
 
 The driver entry point is: console_read. 
 
@@ -251,7 +251,7 @@ You just have to return the content of the Termios input buffer.
 
 Call rtems_termios_read. 
 
-@subsection = Writing characters to the serial device
+@section Writing characters to the serial device
 
 The driver entry point is: console_write. 
 
@@ -260,7 +260,7 @@ buffer.
 
 Call rtems_termios_write. 
 
-@subsection = Changing serial line parameters
+@section Changing serial line parameters
 
 The driver entry point is: console_control. 
 
diff --git a/doc/bsp_howto/init.t b/doc/bsp_howto/init.t
index aefbd1336c..32d66257ce 100644
--- a/doc/bsp_howto/init.t
+++ b/doc/bsp_howto/init.t
@@ -6,9 +6,9 @@
 @c  $Id$
 @c
 
-@chapter = Initialization Code
+@chapter Initialization Code
 
-@subsection = Introduction
+@section Introduction
 
 The initialization code is the first piece of code executed when there's a
 reset/reboot. It aims at initializing the main functions of the board. As
@@ -25,13 +25,13 @@ initialization related).
 
 @end itemize
 
-@subsection = Board Initialization
+@section Board Initialization
 
 You'll find two files under the $BSP340_ROOT/start340/ directory, open
 rtemsfor340only.s which holds initialization code for a MC68340 board only
 and is simpler. 
 
-@subsection = The Interrupts Vector Table
+@section The Interrupts Vector Table
 
 After the entry label starts a code section in which some room is
 allocated for the table of interrupts vectors. They are assigned to the
@@ -44,7 +44,7 @@ $BSP_ROOT/startup/dumpanic.c - that pri nts which address caused the
 interrupt and the contents of the registers, stack...), but this should
 not return. 
 
-@subsection = Chip Select Initialization
+@section Chip Select Initialization
 
 When the microprocessor accesses a memory area, address decoding is
 handled by an address decoder (!), so that the microprocessor knows which
@@ -57,13 +57,13 @@ the linkcmds settings. In this BSP ROM and RAM addresses can be found in
 both the linkcmds and initialization code, but this is not a great way to
 do, better use some shared variables . 
 
-@subsection = Integrated processor registers initialization
+@section Integrated processor registers initialization
 
 There are always some specific integrated processor registers
 initialization to do. Integrated processors' user manuals often detail
 them. 
 
-@subsection = Data section recopy
+@section Data section recopy
 
 The next initialization part can be found in
 $BSP340_ROOT/start340/init68340.c. First the Interrupt Vector Table is
@@ -83,9 +83,9 @@ This code :
 
 Then control is passed to the RTEMS-specific initialization code. 
 
-@subsection = RTEMS-Specific Initialization
+@section RTEMS-Specific Initialization
 
-@subsection = The RTEMS configuration table
+@section The RTEMS configuration table
 
 The RTEMS configuration table contains the maximum number of objects RTEMS
 can handle during the application (e.g. maximum number of tasks,
@@ -101,7 +101,7 @@ The BSP_Configuration label points on this table.
 For more information on the RTEMS configuration table, refer to C user's
 guide, chapter 23 <insert a link here>. 
 
-@subsection = RTEMS initialization procedure
+@section RTEMS initialization procedure
 
 The RTEMS initialization procedure is described in the 3rd chapter of the
 C user's manual <insert a link here>. Please read it carefully. 
@@ -149,7 +149,7 @@ bsp_cleanup
 
 Return control to the monitor. 
 
-@subsection = Drivers initialization
+@section Drivers initialization
 
 The Driver Address Table is part of the RTEMS configuration table. It
 defines RTEMS drivers entry points (initialization, open, close, read,
diff --git a/doc/bsp_howto/intro.t b/doc/bsp_howto/intro.t
index 80d7678703..9af8c46b89 100644
--- a/doc/bsp_howto/intro.t
+++ b/doc/bsp_howto/intro.t
@@ -6,7 +6,7 @@
 @c  $Id$
 @c
 
-@chapter = Introduction
+@chapter Introduction
 
 Before reading this documentation, it is strongly advised to read the
 RTEMS Development Environment Guide to get acquainted with the RTEMS
@@ -31,7 +31,7 @@ are provided for the following topics:
 @end itemize
 
 The original version of this manual was written by Geoffroy Montel
-<g_montel@yahoo.com>.  When he started development of the gen68340
+<g_montel@@yahoo.com>.  When he started development of the gen68340
 BSP, this manual did not exist.  He wrote this manual as the result
 of his experiences.  At that time, this document was viewed internally
 as the most important "missing manual" in the RTEMS documentation set.
diff --git a/doc/bsp_howto/linkcmds.t b/doc/bsp_howto/linkcmds.t
index 648425db2e..67015e2740 100644
--- a/doc/bsp_howto/linkcmds.t
+++ b/doc/bsp_howto/linkcmds.t
@@ -6,14 +6,14 @@
 @c  $Id$
 @c
 
-@chapter = Linkcmds
+@chapter Linkcmds
 
-@subsection = What is a "linkcmds" file?
+@section What is a "linkcmds" file?
 
 The linkcmds file is a script which is passed to the linker at linking
 time. It holds somewhat the board memory configuration. 
 
-@subsection = Image of an Executable
+@section Image of an Executable
 
 A program destined to be embedded has some specificities. Embedded
 machines often mean average performances and small memory usage. 
@@ -43,8 +43,7 @@ initialized variables of the program. It can stay in RAM.
 @item the initialized data section (aka ".data" section): it holds the
 program data which are to be modified during the program's life, which
 means they have to be in RAM. On another hand, these variables must be set
-to predefined values, which have to be
- stored in ROM... 
+to predefined values, which have to be stored in ROM... 
 
 @end itemize
 
@@ -81,17 +80,17 @@ RamSize = DEFINED(RamSize) ? RamSize : 4M;
 HeapSize = DEFINED(HeapSize) ? HeapSize : 0x10000;
 StackSize = DEFINED(StackSize) ? StackSize : 0x1000;
 
-MEMORY {
+MEMORY @{
           ram : ORIGIN = 0x10000000, LENGTH = 4M
           rom : ORIGIN = 0x01000000, LENGTH = 4M
-}
+@}
 
 ETHERNET_ADDRESS = DEFINED(ETHERNET_ADDRESS) ? ETHERNET_ADDRESS : 0xDEAD12;
 
 /*
  * Load objects
  */
-SECTIONS {
+SECTIONS @{
 	/*
 	 * Hardware variations
 	 */
@@ -101,23 +100,23 @@ SECTIONS {
         /*
          * Boot PROM
          */
-        rom : {
+        rom : @{
                 _RomBase = .;
                 __RomBase = .;
-        } >rom
+        @} >rom
 
         /*
          * Dynamic RAM
          */
-        ram : {
+        ram : @{
                 _RamBase = .;
                 __RamBase = .;
-        } >ram
+        @} >ram
 
         /*
          * Text, data and bss segments
          */
-        .text : {
+        .text : @{
                 CREATE_OBJECT_SYMBOLS
 
 
@@ -136,34 +135,34 @@ SECTIONS {
 
                 etext = .;
                 _etext = .;
-        } >rom 
+        @} >rom 
 
-	.eh_fram : {
+	.eh_fram : @{
 		. = ALIGN (16);
 		*(.eh_fram)
-	} >ram
+	@} >ram
 
-	.gcc_exc : {
+	.gcc_exc : @{
 		. = ALIGN (16);
 		*(.gcc_exc)
-	} >ram
+	@} >ram
 
-        dpram : {
+        dpram : @{
                 m340 = .;
                 _m340 = .;
                 . += (8 * 1024);
-        } >ram
+        @} >ram
 
-        .data : {
+        .data : @{
                 copy_start = .;
                 *(.data)
 
                 . = ALIGN (16);
                 _edata = .;
                 copy_end = .;
-        } >ram
+        @} >ram
 
-        .bss : {
+        .bss : @{
                 M68Kvec = .;
                 _M68Kvec = .;
                 . += (256 * 4);
@@ -192,8 +191,8 @@ SECTIONS {
 
 
 
-        } >ram
-}
+        @} >ram
+@}
 @end example
 
 executable format is COFF
@@ -328,9 +327,9 @@ m68k-rtems-objcopy \
 --adjust-section-vma .data= \
 
 `m68k-rtems-objdump --section-headers \
-$(basename $@).exe \
+$(basename $@@).exe \
 | awk '[...]` \
-$(basename $@).exe
+$(basename $@@).exe
 @end example
 
 use the target objcopy
diff --git a/doc/bsp_howto/makefiles.t b/doc/bsp_howto/makefiles.t
index e13a6f3e40..cee9930415 100644
--- a/doc/bsp_howto/makefiles.t
+++ b/doc/bsp_howto/makefiles.t
@@ -6,9 +6,9 @@
 @c  $Id$
 @c
 
-@chapter = Makefiles
+@chapter Makefiles
 
-@subsection = Makefiles Used During The BSP Building Process
+@section Makefiles Used During The BSP Building Process
 
 There's a makefile template in each directory of a BSP. They are called
 "makefile.in" and are processed when building RTEMS for a given BSP. One
@@ -51,7 +51,7 @@ process, usually in your <the RTEMS build
 directory>/c/src/lib/libbsp/<your BSP family>/<your BSP>/<your driver>
 directory) by hand. 
 
-@subsection = Makefiles Used Both During The BSP Design and its Use
+@section Makefiles Used Both During The BSP Design and its Use
 
 A BSP must go with his configuration file. The configuration files can be
 found under $RTEMS_ROOT/c/make/custom. The configuration file is taken
@@ -92,9 +92,9 @@ ifeq ($(RTEMS_USE_GCC272),yes)
 else
 
 define make-exe
-	$(CC) $(CFLAGS) $(CFLAGS_LD) -o $(basename $@).exe $(LINK_OBJS)
-	$(NM) -g -n $(basename $@).exe > $(basename $@).num
-	$(SIZE) $(basename $@).exe
+	$(CC) $(CFLAGS) $(CFLAGS_LD) -o $(basename $@@).exe $(LINK_OBJS)
+	$(NM) -g -n $(basename $@@).exe > $(basename $@@).num
+	$(SIZE) $(basename $@@).exe
 endif
 @end example
 
diff --git a/doc/bsp_howto/target.t b/doc/bsp_howto/target.t
index 1ecadac541..c405c7ee52 100644
--- a/doc/bsp_howto/target.t
+++ b/doc/bsp_howto/target.t
@@ -6,7 +6,7 @@
 @c  $Id$
 @c
 
-@chapter = Target Dependent and Board Dependent Files
+@chapter Target Dependent and Board Dependent Files
 
 RTEMS divides board dependencies into two parts :
 
@@ -21,12 +21,11 @@ descriptions of each needed CPU dependant function.
 
 @item the board dependant code : it includes support for a given board,
 such as the board initialization code and drivers for the various devices:
-clock, UARTs, ethernet board, etc.
 
 
 @end itemize
 
-Porting RTEMS on a new board should raise two questions :
+Porting RTEMS on a new board should raise two questions:
 
 @itemize @bullet
 
diff --git a/doc/bsp_howto/timer.t b/doc/bsp_howto/timer.t
index a6e3653128..2427d519c1 100644
--- a/doc/bsp_howto/timer.t
+++ b/doc/bsp_howto/timer.t
@@ -6,12 +6,12 @@
 @c  $Id$
 @c
 
-@chapter = Timer Driver
+@chapter Timer Driver
 
 You can program the timer driver for your own needs, but here are two uses
 of it: 
 
-@subsection = UART'S FIFO Full Mode
+@section UART'S FIFO Full Mode
 
 The gen68340 BSP is an example of the use of the timer to support the UART
 input FIFO full mode (FIFO means First In First Out and roughly means
@@ -33,7 +33,7 @@ receipt.
 
 @end itemize
 
-@subsection = Measuring RTEMS Primitives Time
+@section Measuring RTEMS Primitives Time
 
 RTEMS Timing Test Suite needs a timer support. You have to provide two
 primitives: