diff options
Diffstat (limited to 'doc/started')
43 files changed, 0 insertions, 1231 deletions
diff --git a/doc/started/Makefile.am b/doc/started/Makefile.am deleted file mode 100644 index 0eef621ffd..0000000000 --- a/doc/started/Makefile.am +++ /dev/null @@ -1,79 +0,0 @@ -# -# COPYRIGHT (c) 1988-2010. -# On-Line Applications Research Corporation (OAR). -# All rights reserved. - -PROJECT = started - -include $(top_srcdir)/project.am -include $(top_srcdir)/main.am - -GENERATED_FILES = buildc.texi buildrt.texi intro.texi nt.texi \ - require.texi nextstep.texi sample.texi - -COMMON_FILES += $(top_srcdir)/common/cpright.texi - -FILES = - -info_TEXINFOS = started.texi -started_TEXINFOS = $(FILES) $(COMMON_FILES) $(GENERATED_FILES) - -intro.texi: intro.t - $(BMENU2) -c -p "Top" \ - -u "Top" \ - -n "Requirements" < $< > $@ - -require.texi: require.t - $(BMENU2) -c -p "RTEMS Mailing Lists" \ - -u "Top" \ - -n "Building the GNU Cross Compiler Toolset with RSB" < $< > $@ - -buildc.texi: buildc.t - $(BMENU2) -c \ - -p "Distribution Independent Potential GNU/Linux Issues" \ - -u "Top" \ - -n "Building RTEMS" < $< > $@ - -buildrt.texi: buildrt.t - $(BMENU2) -c \ - -p "Building the GNU Cross Compiler Toolset with RSB" \ - -u "Top" \ - -n "Building the Sample Applications" < $< > $@ - -sample.texi: sample.t - $(BMENU2) -c -p "Using the RTEMS configure Script Directly" \ - -u "Top" \ - -n "Where To Go From Here" < $< > $@ - -nextstep.texi: nextstep.t - $(BMENU2) -c -p "More Information on RTEMS Application Makefiles" \ - -u "Top" \ - -n "Using MS-Windows as a Development Host" < $< > $@ - -nt.texi: nt.t - $(BMENU2) -c -p "Writing an Application" \ - -u "Top" \ - -n "" < $< > $@ - -EXTRA_DIST = buildc.t buildrt.t intro.t nextstep.t nt.t require.t \ - sample.t - -if USE_HTML -html_project_DATA += pictures/sfile12c.jpg pictures/bit_c.jpg -endif - -PICTURES = pictures/bit_ada.jpg pictures/bit_ada.vsd pictures/bit_c.jpg \ - pictures/bit_c.vsd pictures/scfile10.jpg pictures/scfile10.vsd \ - pictures/scfile11.jpg pictures/scfile11.vsd pictures/scfile12.jpg \ - pictures/scfile12.vsd pictures/scfile13.jpg pictures/scfile13.vsd \ - pictures/scsfile1.jpg pictures/scsfile1.vsd pictures/scsfile2.jpg \ - pictures/scsfile2.vsd pictures/scsfile3.jpg pictures/scsfile3.vsd \ - pictures/scsfile4.jpg pictures/scsfile4.vsd pictures/scsfile5.jpg \ - pictures/scsfile5.vsd pictures/scsfile6.jpg pictures/scsfile6.vsd \ - pictures/scsfile7.jpg pictures/scsfile7.vsd pictures/scsfile8.jpg \ - pictures/scsfile8.vsd pictures/scsfile9.jpg pictures/scsfile9.vsd \ - pictures/sfile12c.jpg pictures/sfile12c.vsd - -EXTRA_DIST += $(PICTURES) - -CLEANFILES += started.info started.info-? diff --git a/doc/started/buildc.t b/doc/started/buildc.t deleted file mode 100644 index b4544ab9ee..0000000000 --- a/doc/started/buildc.t +++ /dev/null @@ -1,16 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2014. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Building the GNU Cross Compiler Toolset with RSB - -The RTEMS Projects recommends using the RTEMS Source Builder (RSB) -for building the toolset from source. RSB has evolved over time from -various instructions and scripts for building the toolset, and it removes -much of the frustration associated with building the toolset from source. -Although prebuilt binaries are much easier to install, they are harder -for the RTEMS Project to support. - -Documentation for RSB is available from @uref{https://docs.rtems.org/rsb/,https://docs.rtems.org/rsb/}. - diff --git a/doc/started/buildrt.t b/doc/started/buildrt.t deleted file mode 100644 index 549e3094df..0000000000 --- a/doc/started/buildrt.t +++ /dev/null @@ -1,192 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2014. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Building RTEMS - -@b{NOTE}: If you built your toolset with RSB, by default the RSB also -builds RTEMS while building the compiler toolset. You may already have -a built and installed RTEMS in this case, and if not you should check -the RSB documentation at @uref{https://docs.rtems.org/rsb/,https://docs.rtems.org/rsb/}. - -@section Obtain the RTEMS Source Code - -This section provides pointers to the RTEMS source code and example -programs. These files should be placed in your @code{archive} directory. -The set of tarballs which comprise an RTEMS release is placed in a -directory whose name is the release on the ftp site. The RTEMS ftp site -is accessible via both the ftp and http protocols at the following URLs: - -@itemize @bullet -@item @uref{http://ftp.rtems.org/pub/rtems,http://ftp.rtems.org/pub/rtems} -@item @uref{ftp://ftp.rtems.org/pub/rtems,ftp://ftp.rtems.org/pub/rtems} -@end itemize - -Associated with each RTEMS Release is a set of example programs. -Prior to the 4.10 Release Series, these examples were in a "Class -Examples" and an "Examples" collection. Beginning with the 4.10 Release -Series, these examples collections were merged and other examples added. -This new collection is called "Examples V2". It is contained in the file -@code{examples-v2-<VERSION>.tar.bz2>} within the RTEMS release directory. - -@c -@c Unarchive the RTEMS Source -@c - -@section Unarchive the RTEMS Source - -Use the following command sequence to unpack the RTEMS source into the -tools directory: - -@example -cd tools -tar xjf ../archive/rtems-@value{RTEMSAPI}.<VERSION>.tar.bz2 -@end example - -This creates the directory rtems-@value{RTEMSAPI}.<VERSION> - -@section Obtaining the RTEMS Source from Git - -Instead of downloading release tarballs you may choose to check out the current -RTEMS source from the project's source code repository. For details on -accessing the RTEMS source repository consult: - -@uref{https://devel.rtems.org/wiki/Developer/Git,https://devel.rtems.org/wiki/Developer/Git}. - -@section Add <INSTALL_POINT>/bin to Executable PATH - -In order to compile RTEMS, you must have the cross compilation toolset -in your search path. It is important to have the RTEMS toolset first -in your path to ensure that you are using the intended version of all -tools. The following command prepends the directory where -the tools were installed in a previous step. If you are using -binaries installed to @code{/opt/rtems-@value{RTEMSAPI}}, then the -<INSTALL_POINT> will be @code{/opt/rtems-@value{RTEMSAPI}} - -@example -export PATH=<INSTALL_POINT>/bin:$@{PATH@} -@end example - -@b{NOTE:} The above command is in Bourne shell (@code{sh}) syntax and should -work with the Korn (@code{ksh}) and GNU Bourne Again Shell (@code{bash}). -It will not work with the C Shell (@code{csh}) or derivatives of the -C Shell. - -@section Verifying the Operation of the Cross Toolset - -In order to ensure that the cross-compiler is invoking the correct -subprograms (like @code{as} and @code{ld}), one can test assemble -a small program. When in verbose mode, @code{gcc} prints out information -showing where it found the subprograms it invokes. In a temporary -working directory, place the following function in a file named @code{f.c}: - -@example -int f( int x ) -@{ - return x + 1; -@} -@end example - -Then assemble the file using a command similar to the following: - -@example -m68k-rtems@value{RTEMSAPI}-gcc -v -S f.c -@end example - -Where @code{m68k} should be changed to match the target architecture -of your cross compiler. The result of this command will be a sequence -of output showing where the cross-compiler searched for and found -its subcomponents. Verify that these paths correspond to your -<INSTALL_POINT>. - -Look at the created file @code{f.s} and verify that it is in fact -for your target processor. - -Then try to compile the file @code{f.c} directly to object code -using a command like the following: - -@example -m68k-rtems@code{RTEMSAPI}-gcc -v -c f.c -@end example - -If this produces messages that indicate the assembly code is not valid, -then it is likely that you have fallen victim to one of the most -common installation errors and the cross-compiler is not able -to find the cross assembler and defaults to using the native @code{as}. -This can result in very confusing error messages. - -@section Building RTEMS for a Specific Target and BSP - -This section describes how to configure and build RTEMS -so that it is specifically tailored for your BSP (Board Support Package) -and the CPU model it uses. There is currently only one supported -method to compile and install RTEMS: - -@itemize @bullet -@item direct invocation of @code{configure} and @code{make} -@end itemize - -Direct invocation of @code{configure} and @code{make} provides more control -and easier recovery from problems when building. - -This section describes how to build RTEMS. - -@subsection Using the RTEMS configure Script Directly - -Make a build directory under tools and build the RTEMS product in this -directory. The @code{../rtems-@value{RTEMSAPI}.<VERSION>/configure} -command has numerous command line arguments. These arguments are -discussed in detail in documentation that comes with the RTEMS -distribution. A full list of these arguments can be obtained by running -@code{../rtems-@value{RTEMSAPI}.<VERSION>/configure --help} If you -followed the procedure described in the section @ref{Unarchive -the RTEMS Source} or @ref{Obtaining the RTEMS Source from Git}, -these configuration options can be found in the file -rtems-@value{RTEMSAPI}.<VERSION>/README.configure. - -@b{NOTE}: The GNAT/RTEMS run-time implementation is based on the POSIX -API and the GNAT/RTEMS run-time cannot be compiled with networking -disabled. Your application does not have to use networking but it must -be enabled. Thus the RTEMS configuration for a GNAT/RTEMS environment -MUST include the @code{--enable-posix --enable-networking} flag. - -@b{NOTE}: Building RTEMS requires that a few support programs be compiled -natively. This means there must be a native toolchain installed on your -development host. You will need to have a native compiler such as @i{gcc} -or @i{cc} in your execution path. If you cannot compile, link and execute -a native hello world program, then you will be unable to build RTEMS. - -The following shows the command sequence required to configure, -compile, and install RTEMS with the POSIX API, FreeBSD TCP/IP, -and C++ support disabled. RTEMS will be built to target -the @code{BOARD_SUPPORT_PACKAGE} board. - -@example -mkdir build-rtems -cd build-rtems -../rtems-@value{RTEMSAPI}.VERSION/configure \ - --target=<TARGET_CONFIGURATION> \ - --disable-networking \ - --enable-rtemsbsp=<BSP>\ - --prefix=<INSTALL_POINT> -make all -make install -@end example - -<TARGET> is of the form <CPU>-rtems@value{RTEMSAPI} and the list of -currently supported <TARGET> configuration's and <BSP>'s can be found in -@code{tools/RTEMS-@value{RTEMSAPI}.<VERSION>/README.configure}. - -<INSTALL_POINT> is typically the installation point for the tools and -defaults to @code{/opt/rtems-@value{RTEMSAPI}}. - -BSP is a supported BSP for the selected CPU family. -The list of supported BSPs may be found in the file -@code{tools/rtems-@value{RTEMSAPI}.<VERSION>/README.configure} in the -RTEMS source tree. If the BSP parameter is not specified, then all -supported BSPs for the selected CPU family will be built. - -@b{NOTE:} The POSIX API and networking must be enabled to use GNAT/RTEMS. - -@b{NOTE:} The @code{make} utility used should be GNU make. diff --git a/doc/started/intro.t b/doc/started/intro.t deleted file mode 100644 index d9879e1834..0000000000 --- a/doc/started/intro.t +++ /dev/null @@ -1,159 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2010. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Introduction - -The purpose of this document is to guide you through the process of -installing a GNU cross development environment to use with RTEMS. - -If you are already familiar with the concepts behind a cross compiler and -have a background in Unix, these instructions should provide the bare -essentials for performing a setup of the following items: - -@itemize @bullet -@item GNU Cross Compilation Tools for RTEMS on your build-host system -@item RTEMS OS for the target -@item GNU Debugger (GDB) -@end itemize - -The remainder of this chapter provides background information on real-time -embedded systems and cross development and an overview of other -resources of interest on the Internet. If you are not familiar with -real-time embedded systems or the other areas, please read those sections. -These sections will help familiarize you with the -types of systems RTEMS is designed to be used in and the cross development -process used when developing RTEMS applications. - -@section Real-Time Embedded Systems - -Real-time embedded systems are found in practically every facet of our -everyday lives. Today's systems range from the common telephone, automobile -control systems, and kitchen appliances to complex air traffic control -systems, military weapon systems, and production line control including -robotics and automation. However, in the current climate of rapidly changing -technology, it is difficult to reach a consensus on the definition of a -real-time embedded system. Hardware costs are continuing to rapidly decline -while at the same time the hardware is increasing in power and functionality. -As a result, embedded systems that were not considered viable two years ago -are suddenly a cost effective solution. In this domain, it is not uncommon -for a single hardware configuration to employ a variety of architectures and -technologies. Therefore, we shall define an embedded system as any computer -system that is built into a larger system consisting of multiple technologies -such as digital and analog electronics, mechanical devices, and sensors. - -Even as hardware platforms become more powerful, most embedded systems are -critically dependent on the real-time software embedded in the systems -themselves. Regardless of how efficiently the hardware operates, the -performance of the embedded real-time software determines the success of the -system. As the complexity of the embedded hardware platform grows, so does -the size and complexity of the embedded software. Software systems must -routinely perform activities which were only dreamed of a short time ago. -These large, complex, real-time embedded applications now commonly contain -one million lines of code or more. - -Real-time embedded systems have a complex set of characteristics that -distinguish them from other software applications. Real-time embedded -systems are driven by and must respond to real world events while adhering to -rigorous requirements imposed by the environment with which they interact. -The correctness of the system depends not only on the results of -computations, but also on the time at which the results are produced. The -most important and complex characteristic of real-time application systems is -that they must receive and respond to a set of external stimuli within rigid -and critical time constraints. - -A single real-time application can be composed of both soft and hard -real-time components. A typical example of a hard real-time system is a -nuclear reactor control system that must not only detect failures, but must -also respond quickly enough to prevent a meltdown. This application also has -soft real-time requirements because it may involve a man-machine interface. -Providing an interactive input to the control system is not as critical as -setting off an alarm to indicate a failure condition. However, the -interactive system component must respond within an acceptable time limit to -allow the operator to interact efficiently with the control system. - -@section Cross Development - -Today almost all real-time embedded software systems are developed in a -@b{cross development} environment using cross development tools. In the cross -development environment, software development activities are typically -performed on one computer system, the @b{build-host} system, while the result of the -development effort (produced by the cross tools) is a software system that -executes on the @b{target} platform. The requirements for the target platform are -usually incompatible and quite often in direct conflict with the requirements -for the build-host. Moreover, the target hardware is often custom designed for a -particular project. This means that the cross development toolset must allow -the developer to customize the tools to address target specific run-time -issues. The toolset must have provisions for board dependent initialization -code, device drivers, and error handling code. - -The build-host computer is optimized to support the code development cycle with -support for code editors, compilers, and linkers requiring large disk drives, -user development windows, and multiple developer connections. Thus the build-host -computer is typically a traditional UNIX workstation such as those available -from SUN or Silicon Graphics, or a PC running either a version of MS-Windows -or UNIX. The build-host system may also be required to execute -office productivity applications to allow the software developer -to write documentation, make presentations, or track the project's -progress using a project management tool. This necessitates that the -build-host computer be general purpose with resources such as a -thirty-two or sixty-four bit processor, large amounts of -RAM, a monitor, mouse, keyboard, hard and floppy disk drives, CD-ROM drive, -and a graphics card. It is likely that the system will be multimedia capable -and have some networking capability. - -Conversely, the target platform generally has limited traditional computer -resources. The hardware is designed for the particular functionality and -requirements of the embedded system and optimized to perform those tasks -effectively. Instead of hard drives and keyboards, it is composed of -sensors, relays, and stepper motors. The per-unit cost of the target platform -is typically a critical concern. No hardware component is included without -being cost justified. As a result, the processor of the target system is -often from a different processor family than that of the build-host system and -usually has lower performance. In addition to the processor families -designed only for use in embedded systems, there are versions of nearly every -general-purpose processor specifically tailored for real-time embedded -systems. For example, many of the processors targeting the embedded market -do not include hardware floating point units, but do include peripherals such -as timers, serial controllers, or network interfaces. - -@section Resources on the Internet - -This section describes various resources on the Internet which are of -use to RTEMS users. - -@c -@c Online Tool Documentation -@c - -@subsection Online Tool Documentation - -Each of the tools in the GNU development suite comes with documentation. -It is in the reader's and tool maintainers' interest that one read the -documentation before posting a problem to a mailing list or news group. -The RTEMS Project provides formatted documentation for the primary -tools in the cross development toolset including BINUTILS, GCC, -NEWLIB, and GDB with the pre-built versions of those tools. - -Much of the documentation is available at other sites on the Internet, -for example the GNU manuals are hosted by the Free Software Foundation -at @uref{http://www.gnu.org/manual/manual.html, http://www.gnu.org/manual/manual.html}. - -@subsection RTEMS Mailing Lists - -@uref{mailto:@value{RTEMSUSERS},@value{RTEMSUSERS}} - -The users mailing list is for any and all questions about RTEMS, especially -those focusing on how to use RTEMS. -If you would like to browse the thousands of messages in the fifteen -year archive of the mailing list or subscribe to it, please visit -@uref{https://lists.rtems.org/mailman/listinfo/users,https://lists.rtems.org/mailman/listinfo/users} for -more information, - -@uref{mailto:@value{RTEMSDEVEL},@value{RTEMSDEVEL}} - -The devel mailing list is the place to track ongoing RTEMS development -and to discuss changes to RTEMS. This list is also where patches are -submitted. - diff --git a/doc/started/nextstep.t b/doc/started/nextstep.t deleted file mode 100644 index 82074cbd2b..0000000000 --- a/doc/started/nextstep.t +++ /dev/null @@ -1,131 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2010. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Where To Go From Here - -At this point, you should have successfully installed a GNU Cross -Compilation Tools for RTEMS on your host system as well as the RTEMS OS -for the target host. You should have successfully linked the "hello -world" program. You may even have downloaded the executable to that -target and run it. What do you do next? - -The answer is that it depends. You may be interested in writing an -application that uses one of the multiple APIs supported by RTEMS. -You may need to investigate the network or filesystem support in RTEMS. -The common thread is that you are largely finished with this manual and -ready to move on to others. - -Whether or not you decide to dive in now and write application code or -read some documentation first, this chapter is for you. The first section -provides a quick roadmap of some of the RTEMS documentation. The next -section provides a brief overview of the RTEMS application structure. - -@section Documentation Overview - -When writing RTEMS applications, you should find the following manuals -useful because they define the calling interface to many of the services -provided by RTEMS: - -@itemize @bullet -@item @b{RTEMS Applications C User's Guide} describes the -Classic RTEMS API based on the RTEID specification. - -@item @b{RTEMS POSIX API User's Guide} describes the RTEMS POSIX API -that is based on the POSIX 1003.1b API. If there is any place where -this manual is thin or unclear, please refer to the OpenGroup Single -UNIX Specification. RETEMS tracks that specification for future POSIX -revisions. - -@item @b{RTEMS Network Supplement} provides information on the network -services provided by RTEMS. RTEMS provides a BSD sockets programming -interface so any network programming book should be helpful. - -@end itemize - -In addition, the following manuals from the GNU Cross Compilation Toolset -include information on run-time services available. - -@itemize @bullet -@item @b{C Support Library} describes the Standard C Library -functionality provided by Newlib's libc. - -@item @b{C Math Library} describes the Standard C Math Library -functionality provided by Newlib's libm. - -@end itemize - -Finally, the RTEMS FAQ, Wiki, and mailing list archives are available -at @uref{http://www.rtems.org, http://www.rtems.org}. - -There is a wealth of documentation available for RTEMS and the GNU tools -supporting it. If you run into something that is not clear or missing, -bring it to our attention. - -Also, some of the RTEMS documentation is still under construction. -If you would like to contribute to this effort, please contact the -RTEMS Team at @uref{mailto:@value{RTEMSUSERS}, @value{RTEMSUSERS}}. -If you are interested in sponsoring the development of a new feature, -BSP, device driver, port of an existing library, etc., please contact -@uref{mailto:sales@@oarcorp.com, sales@@oarcorp.com}. - -@section Writing an Application - -From an application author's perspective, the structure of -an RTEMS application is very familiar. In POSIX language, -RTEMS provides a single process, multi-threaded run-time -environment. However there are two important things that are -different from a standard UNIX hosted program. - -First, the application developer must provide configuration information -for RTEMS. This configuration information includes limits on the maximum -number of various OS resources available and networking configuration -among other things. See the @b{Configuring a System} in the @b{RTEMS -Applications C User's Guide} for more details. - -Second, RTEMS applications may or may not start at @code{main()}. -Applications begin execution at one or more user configurable application -initialization tasks or threads. It is possible to configure an -application to start with a single thread that whose entry point is -@code{main()}. - -Each API supported by RTEMS (Internal, Classic, and POSIX) allows -the user to configure a set of one or more tasks that are created and -started automatically during RTEMS initialization. The RTEMS Automatic -Configuration Generation (@code{confdefs.h}) scheme can be used to easily -generate the configuration information for an application that starts -with a single initialization task. By convention, unless overridden, -the default name of the initialization task varies based up API. - -@itemize @bullet -@item @code{Init} - single Classic API Initialization Task - -@item @code{POSIX_Init} - single POSIX API Initialization Thread -@end itemize - -Regardless of the API used, when the initialization task executes, -all non-networking device drivers are normally initialized, -processor interrupts are enabled, and any C++ global constructors -have been run. The initialization task then goes about its -business of performing application specific initialization which -will include initializing the networking subsystem if it is to be -used. The application initialization may also involve creating -tasks and other system resources such as semaphores or message queues -and allocating memory. In the RTEMS examples and tests, the -file @code{init.c} usually contains the initialization task. Although -not required, in most of the examples, the initialization task -completes by deleting itself. - -As you begin to write RTEMS application code, you may be confused by the -range of alternatives. Supporting multiple tasking APIs can make the -choices confusing. Many application groups writing new code choose one -of the APIs as their primary API and only use services from the others if -nothing comparable is in their preferred one. However, the support for -multiple APIs is a powerful feature when integrating code from multiple -sources. You can write new code using POSIX services and still use -services written in terms of the other APIs. Moreover, by adding support -for yet another API, one could provide the infrastructure required to -migrate from a legacy RTOS with a non-standard API to an API like POSIX. - - diff --git a/doc/started/nt.t b/doc/started/nt.t deleted file mode 100644 index cb34fd9d66..0000000000 --- a/doc/started/nt.t +++ /dev/null @@ -1,145 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2010. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@appendix Using MS-Windows as a Development Host - -This chapter discusses the installation of the GNU tool chain -on a computer running the Microsoft Windows operating system. - -This chapter was originally written by -@uref{mailto:g_montel@@yahoo.com, Geoffroy Montel <g_montel@@yahoo.com>} -with input from -@uref{mailto:<D.J@@fiddes.surfaid.org>, David Fiddes <D.J@@fiddes.surfaid.org>}. -It was based upon his successful but unnecessarily painful efforts with -Cygwin beta versions. Cygwin and this chapter have been updated multiple -times since those early days although their pioneering efforts and input -is still greatly appreciated. - -@section Microsoft Windows Version Requirements - -RTEMS users report fewer problems when using Microsoft Windows XP or newer. - -@section Cygwin - -For RTEMS development, the recommended approach is to use Cygwin. Cygwin -is available from @uref{http://www.cygwin.com, http://www.cygwin.com} . -The primary issues reported by users of Cygwin is that it is slower -on the same hardware than a native GNU/Linux installation and strange -issues over carriage return/line feed inconsistencies between UNIX and -Windows environments. However, there are a handful of other issues that -may turn up when using Cygwin as an RTEMS development environment. - -@itemize @bullet - -@item There is no @code{cc} program by default. The GNU configure -scripts used by RTEMS require this to be present to work properly. -The solution is to link @code{gcc.exe} to @code{cc.exe} as follows: - -@example -ln -s /bin/gcc.exe /bin/cc.exe -@end example - -@item Make sure @code{/bin/sh.exe} is GNU Bash. Some Cygwin -versions provide a light Bourne shell which is insufficient to build -RTEMS. To see which shell is installed as @code{/bin/sh.exe}, execute -the command @code{/bin/sh --version}. If it looks similar to -the following, then it is GNU Bash and you are OK: - -@example -GNU bash, version 2.04.5(12)-release (i686-pc-cygwin) -Copyright 1999 Free Software Foundation, Inc. -@end example - -If you get an error or it claims to be any other shell, you need -to copy it to a fake name and copy -@code{/bin/bash.exe} to @code{/bin/sh.exe}: - -@example -cd /bin -mv sh.exe old_sh.exe -cp bash.exe sh.exe -@end example - -The Bourne shell has to be present in @code{/bin} directory to run -shell scripts properly. - -@item Make sure you unarchive and build in a binary mounted -filesystem (e.g. mounted with the @code{-b} option). Otherwise, -many confusing errors will result. - -@item A user has reported that they needed to set @code{CYGWIN=ntsec} -for chmod to work correctly, but had to set @code{CYGWIN=nontsec} -for compile to work properly (otherwise there were complaints about -permissions on a temporary file). - -@item If you want to build the tools from source, you have the -same options as UNIX users. - -@item You may have to uncompress archives during this process. You must -@b{NOT} use @code{WinZip} or @code{PKZip}. Instead the un-archiving -process uses the GNU @code{zip} and @code{tar} programs as shown below: - -@example -tar -xzvf archive.tgz -@end example - -@code{tar} is provided with Cygwin. - -@end itemize - -@section MingGW - -You might consider choosing MinGW since it provides better perfomance. There is a wiki entry on a MinGW RTEMS toolset installer available at @uref{http://www.rtems.org/wiki/index.php/MinGW_Tools_for_Windows,http://www.rtems.org/wiki/index.php/MinGW_Tools_for_Windows}. Also, there are prebuilt tools for different architectures available for download at @uref{http://www.rtems.org/ftp/pub/rtems/mingw32,http://www.rtems.org/ftp/pub/rtems/mingw32}. - -@section Text Editor - -You absolutely have to use a text editor which can save files with Unix format. -So do @b{NOT} use Notepad or Wordpad! Basically, any more or less advanced -text editor is usually able to do that. There is a number of editors freely -available that can be used. - -@itemize @bullet -@item @b{Notepad++} has an interface familiar to Windows users and can be downloaded from @uref{http://notepad-plus-plus.org/,http://notepad-plus-plus.org/}. - -@item @b{VIM} (@b{Vi IMproved}) is available from -@uref{http://www.vim.org/,http://www.vim.org/}. This editor has the very -handy ability to easily read and write files in either DOS or UNIX style. - -@item @b{GNU Emacs} is available for many platforms -including MS-Windows. The official homepage is -@uref{http://www.gnu.org/software/emacs/emacs.html, -http://www.gnu.org/software/emacs/emacs.html}. -The GNU Emacs on Windows NT and Windows 95/98 FAQ is at -@uref{http://www.gnu.org/software/emacs/windows/ntemacs.html, -http://www.gnu.org/software/emacs/windows/ntemacs.html}. - -@end itemize - -If you do accidentally end up with files having MS-DOS style line -termination, then you may have to convert them to Unix format for some -Cygwin programs to operate on them properly. The program @code{dos2unix} -can be used to put them -back into Unix format as shown below: - -@example -$ dos2unix XYZ -Dos2Unix: Cleaning file XYZ ... -@end example - -@section System Requirements - -Although the finished cross-compiler is fairly easy on resources, building -it can take a significant amount of processing power and disk space. -Luckily, desktop computers have progressed very far since this guide -was originally written so it is unlikely you will have any problems. -Just do not use an old cast-off machine with < 1 GB RAM and a 1 Ghz CPU. -Unless, of course, you enjoy waiting for things to complete. - -The more disk space, the better. You need more if you are building the -GNU tools and the amount of disk space for binaries is obviously directly -dependent upon the number of CPUs you have cross toolsets installed for. -In addition to the disk space requirements documented earlier for tool -building, you will also have to have enough space to install the Cygwin -environment. diff --git a/doc/started/pictures/bit_ada.jpg b/doc/started/pictures/bit_ada.jpg Binary files differdeleted file mode 100644 index 774b103711..0000000000 --- a/doc/started/pictures/bit_ada.jpg +++ /dev/null diff --git a/doc/started/pictures/bit_ada.vsd b/doc/started/pictures/bit_ada.vsd Binary files differdeleted file mode 100644 index 51e8e1fe53..0000000000 --- a/doc/started/pictures/bit_ada.vsd +++ /dev/null diff --git a/doc/started/pictures/bit_c.jpg b/doc/started/pictures/bit_c.jpg Binary files differdeleted file mode 100644 index 158beb4bd1..0000000000 --- a/doc/started/pictures/bit_c.jpg +++ /dev/null diff --git a/doc/started/pictures/bit_c.vsd b/doc/started/pictures/bit_c.vsd Binary files differdeleted file mode 100644 index a6db26bd15..0000000000 --- a/doc/started/pictures/bit_c.vsd +++ /dev/null diff --git a/doc/started/pictures/scfile10.jpg b/doc/started/pictures/scfile10.jpg Binary files differdeleted file mode 100644 index 22a83877ce..0000000000 --- a/doc/started/pictures/scfile10.jpg +++ /dev/null diff --git a/doc/started/pictures/scfile10.vsd b/doc/started/pictures/scfile10.vsd Binary files differdeleted file mode 100644 index 07efb1f18b..0000000000 --- a/doc/started/pictures/scfile10.vsd +++ /dev/null diff --git a/doc/started/pictures/scfile11.jpg b/doc/started/pictures/scfile11.jpg Binary files differdeleted file mode 100644 index f70986ef55..0000000000 --- a/doc/started/pictures/scfile11.jpg +++ /dev/null diff --git a/doc/started/pictures/scfile11.vsd b/doc/started/pictures/scfile11.vsd Binary files differdeleted file mode 100644 index 25871be19a..0000000000 --- a/doc/started/pictures/scfile11.vsd +++ /dev/null diff --git a/doc/started/pictures/scfile12.jpg b/doc/started/pictures/scfile12.jpg Binary files differdeleted file mode 100644 index 22a83877ce..0000000000 --- a/doc/started/pictures/scfile12.jpg +++ /dev/null diff --git a/doc/started/pictures/scfile12.vsd b/doc/started/pictures/scfile12.vsd Binary files differdeleted file mode 100644 index 750e7cdf56..0000000000 --- a/doc/started/pictures/scfile12.vsd +++ /dev/null diff --git a/doc/started/pictures/scfile13.jpg b/doc/started/pictures/scfile13.jpg Binary files differdeleted file mode 100644 index 7ea418b7a7..0000000000 --- a/doc/started/pictures/scfile13.jpg +++ /dev/null diff --git a/doc/started/pictures/scfile13.vsd b/doc/started/pictures/scfile13.vsd Binary files differdeleted file mode 100644 index 581eff901c..0000000000 --- a/doc/started/pictures/scfile13.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile1.jpg b/doc/started/pictures/scsfile1.jpg Binary files differdeleted file mode 100644 index d1d497e955..0000000000 --- a/doc/started/pictures/scsfile1.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile1.vsd b/doc/started/pictures/scsfile1.vsd Binary files differdeleted file mode 100644 index a7314848fc..0000000000 --- a/doc/started/pictures/scsfile1.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile2.jpg b/doc/started/pictures/scsfile2.jpg Binary files differdeleted file mode 100644 index afbe1db125..0000000000 --- a/doc/started/pictures/scsfile2.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile2.vsd b/doc/started/pictures/scsfile2.vsd Binary files differdeleted file mode 100644 index d2bb29a6e8..0000000000 --- a/doc/started/pictures/scsfile2.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile3.jpg b/doc/started/pictures/scsfile3.jpg Binary files differdeleted file mode 100644 index b0e135994d..0000000000 --- a/doc/started/pictures/scsfile3.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile3.vsd b/doc/started/pictures/scsfile3.vsd Binary files differdeleted file mode 100644 index da98158c85..0000000000 --- a/doc/started/pictures/scsfile3.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile4.jpg b/doc/started/pictures/scsfile4.jpg Binary files differdeleted file mode 100644 index 1c01cbb460..0000000000 --- a/doc/started/pictures/scsfile4.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile4.vsd b/doc/started/pictures/scsfile4.vsd Binary files differdeleted file mode 100644 index 50823fa67e..0000000000 --- a/doc/started/pictures/scsfile4.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile5.jpg b/doc/started/pictures/scsfile5.jpg Binary files differdeleted file mode 100644 index 8fe8df173c..0000000000 --- a/doc/started/pictures/scsfile5.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile5.vsd b/doc/started/pictures/scsfile5.vsd Binary files differdeleted file mode 100644 index 614736593a..0000000000 --- a/doc/started/pictures/scsfile5.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile6.jpg b/doc/started/pictures/scsfile6.jpg Binary files differdeleted file mode 100644 index 58a3489242..0000000000 --- a/doc/started/pictures/scsfile6.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile6.vsd b/doc/started/pictures/scsfile6.vsd Binary files differdeleted file mode 100644 index a970df509a..0000000000 --- a/doc/started/pictures/scsfile6.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile7.jpg b/doc/started/pictures/scsfile7.jpg Binary files differdeleted file mode 100644 index 68cff033b8..0000000000 --- a/doc/started/pictures/scsfile7.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile7.vsd b/doc/started/pictures/scsfile7.vsd Binary files differdeleted file mode 100644 index 0af5ae9f4f..0000000000 --- a/doc/started/pictures/scsfile7.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile8.jpg b/doc/started/pictures/scsfile8.jpg Binary files differdeleted file mode 100644 index a2ef5954ca..0000000000 --- a/doc/started/pictures/scsfile8.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile8.vsd b/doc/started/pictures/scsfile8.vsd Binary files differdeleted file mode 100644 index 0ed6dedf6d..0000000000 --- a/doc/started/pictures/scsfile8.vsd +++ /dev/null diff --git a/doc/started/pictures/scsfile9.jpg b/doc/started/pictures/scsfile9.jpg Binary files differdeleted file mode 100644 index 04f623e62d..0000000000 --- a/doc/started/pictures/scsfile9.jpg +++ /dev/null diff --git a/doc/started/pictures/scsfile9.vsd b/doc/started/pictures/scsfile9.vsd Binary files differdeleted file mode 100644 index ca3222b4cf..0000000000 --- a/doc/started/pictures/scsfile9.vsd +++ /dev/null diff --git a/doc/started/pictures/sfile12c.jpg b/doc/started/pictures/sfile12c.jpg Binary files differdeleted file mode 100644 index aba5bf21a2..0000000000 --- a/doc/started/pictures/sfile12c.jpg +++ /dev/null diff --git a/doc/started/pictures/sfile12c.vsd b/doc/started/pictures/sfile12c.vsd Binary files differdeleted file mode 100644 index fc0616cf1e..0000000000 --- a/doc/started/pictures/sfile12c.vsd +++ /dev/null diff --git a/doc/started/require.t b/doc/started/require.t deleted file mode 100644 index 0e0f7d1d34..0000000000 --- a/doc/started/require.t +++ /dev/null @@ -1,154 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2010. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Requirements - -This chapter describes the build-host system requirements and initial steps -in installing the GNU Cross Compiler Tools and RTEMS on a build-host. - -@section Disk Space - -A fairly large amount of disk space is required to perform the build of the -GNU C/C++ Cross Compiler Tools for RTEMS. The following table may help in -assessing the amount of disk space required for your installation: - -@example -+------------------------------------+--------------------------+ -| Component | Disk Space Required | -+------------------------------------+--------------------------+ -| archive directory | 120 Mbytes | -| tools src unarchived | 1400 Mbytes | -| each individual build directory | up to 2500 Mbytes | -| each installation directory | 900 Mbytes | -+------------------------------------+--------------------------+ -@end example - -It is important to understand that the above requirements only address the -GNU C/C++ Cross Compiler Tools themselves. Adding additional languages -such as Ada or Go can increase the size of the build and installation -directories. Also, the unarchived source and build directories can be -removed after the tools are installed. - -After the tools themselves are installed, RTEMS must be built -and installed for each Board Support Package that you wish -to use. Thus the precise amount of disk space required -for each installation directory depends highly on the number -of RTEMS BSPs which are to be installed. If a single BSP is -installed, then the additional size of each install directory -will tend to be in the 40-60 Mbyte range. - -There are a number of factors which must be taken into -account in order to estimate the amount of disk space required -to build RTEMS itself. Attempting to build multiple BSPs in -a single step increases the disk space requirements. On some -target architectures, this can lead to disk usage during the build -of over one gigabyte. - -Similarly enabling optional features increases the build and install -space requirements. In particular, enabling and building -the RTEMS tests results in a significant increase in build -space requirements but since the tests are not installed has, -enabling them has no impact on installation requirements. - -@section General Host Software Requirements - -The instructions in this manual should work on any computer running -a POSIX environment including GNU/Linux and Cygwin. Mingw users may -encounter additional issues due to the limited POSIX compatibility. -Some native GNU tools are used by this procedure including: - -@itemize @bullet -@item GCC -@item GNU make -@item GNU makeinfo -@end itemize - -In addition, some native utilities may be deficient for building the -GNU tools. On hosts which have m4 but it is not GNU m4, it is not -uncommon to have to install GNU m4. Similarly, some shells are not -capable of fully supporting the RTEMS configure scripts. - -@subsection GCC - -Although RTEMS itself is intended to execute on an embedded target, -there is source code for some native programs included with the RTEMS -distribution. Some of these programs are used to assist in the building -of RTEMS itself, while others are BSP specific tools. Regardless, -no attempt has been made to compile these programs with a non-GNU -compiler. - -@subsection GNU Make - -Both NEWLIB and RTEMS use GNU make specific features and can only be built -using GNU make. Many systems include a make utility that is not GNU make. -The safest way to meet this requirement is to ensure that when you invoke -the command @code{make}, it is GNU make. This can be verified by -attempting to print the GNU make version information: - -@example -make --version -@end example - -If you have GNU make and another make on your system, it is common to put -the directory containing GNU make before the directory containing other -implementations of make. - -@subsection GNU makeinfo Version Requirements - -In order to build gcc 2.9.x or newer versions, the GNU @code{makeinfo} program -installed on your system must be at least version 1.68. The appropriate -version of @code{makeinfo} is distributed with @code{gcc}. - -The following demonstrates how to determine the version of @code{makeinfo} -on your machine: - -@example -makeinfo --version -@end example - -@c -@c Host Specific Notes -@c - -@section Host Specific Notes - -@subsection Solaris 2.x - -The following problems have been reported by Solaris 2.x users: - -@itemize @bullet - -@item The build scripts are written in "shell". The program @code{/bin/sh} -on Solaris 2.x is not robust enough to execute these scripts. If you -are on a Solaris 2.x host, then use the @code{/bin/ksh} or -@code{/bin/bash} shell instead. - -@item The native @code{patch} program is broken. Install the GNU version. - -@item The native @code{m4} program is deficient. Install the GNU version. - -@end itemize - -@subsection Distribution Independent Potential GNU/Linux Issues - -The following problems have been reported by users of various GNU/Linux -distributions: - -@itemize @bullet - -@item Certain versions of GNU fileutils include a version of -@code{install} which does not work properly. Please perform -the following test to see if you need to upgrade: - -@example -install -c -d /tmp/foo/bar -@end example - -If this does not create the specified directories your install -program will not install RTEMS properly. You will need to upgrade -to at least GNU fileutils version 3.16 to resolve this problem. - -@end itemize - diff --git a/doc/started/sample.t b/doc/started/sample.t deleted file mode 100644 index 108c9626f7..0000000000 --- a/doc/started/sample.t +++ /dev/null @@ -1,248 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2010. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Building the Sample Applications - -The RTEMS distribution includes a number of sample C, C++, -Ada, and networking applications. This chapter will provide -an overview of those sample applications. - -@c -@c Set the Environment Variable RTEMS_MAKEFILE_PATH -@c -@section Set the Environment Variable RTEMS_MAKEFILE_PATH - -The sample application sets use the RTEMS Application Makefiles. -This requires that the environment variable -@code{RTEMS_MAKEFILE_PATH} point to the appropriate directory containing -the installed RTEMS image built to target your particular CPU and -board support package combination. - -@example -export RTEMS_MAKEFILE_PATH=<INSTALLATION_POINT>/<CPU>-rtems/<BOARD_SUPPORT_PACKAGE> -@end example - -Where <INSTALLATION_POINT> and <BOARD_SUPPORT_PACKAGE> are those used when -configuring and installing RTEMS. - -@b{NOTE}: In release 4.0, BSPs were installed at -@code{<INSTALLATION_POINT>/rtems/<BOARD_SUPPORT_PACKAGE>}. This -was changed to be more in compliance with GNU standards. - -@b{NOTE}: GNU make is the preferred @code{make} utility. Other @code{make} -implementations may work but all testing is done with GNU make. - -If no errors are detected during the sample application build, it is -reasonable to assume that the build of the GNU Cross Compiler Tools -for RTEMS and RTEMS itself for the selected host and target -combination was done properly. - -@c -@c Executing the Sample Applications -@c -@section Executing the Sample Applications - -How each sample application executable is downloaded -to your target board and executed is very dependent -on the board you are using. The following is a list of -commonly used BSPs classified by their RTEMS CPU family and pointers -to instructions on how to use them. [NOTE: All file names should be -prepended with @code{rtems-@value{RTEMSAPI}.<VERSION>/c/src/lib/libbsp}.] - -@need 1000 -@table @b - -@item arm/edp7312 -The arm/edp7312 BSP is for the ARM7-based Cogent EDP7312 board. - -@item c4x/c4xsim -The c4x/c4xsim BSP is designed to execute on any member of -the Texas Instruments C3x/C4x DSP family using only on-CPU -peripherals for the console and timers. - -@item i386/pc386 -See @code{i386/pc386/HOWTO} - -@item i386/pc486 -The i386/pc386 BSP specially compiled for an i486-class CPU. - -@item i386/pc586 -The i386/pc386 BSP specially compiled for a Pentium-class CPU. - -@item i386/pc686 -The i386/pc386 BSP specially compiled for a Pentium II. - -@item i386/pck6 -The i386/pc386 BSP specially compiled for an AMD K6. - -@item m68k/gen68360 -This BSP is for a MC68360 CPU. See @code{m68k/gen68360/README} for details. - -@item m68k/mvme162 -See @code{m68k/mvme162/README}. - -@item m68k/mvme167 -See @code{m68k/mvme167/README}. - -@item mips/jmr3904 -This is a BSP for the Toshiba TX3904 evaluation board -simulator included with @code{mipstx39-rtems-gdb}. The -BSP is located in @code{mips/jmr3904}. -The TX3904 is a MIPS R3000 class CPU with serial ports and timers -integrated with the processor. This BSP can be used with -either real hardware or with the simulator included with -@code{mipstx39-rtems-gdb}. An application can be run on the simulator -by executing the following commands upon entering @code{mipstx39-rtems-gdb}: - -@example -target sim --board=jmr3904 -load -run -@end example - -@item powerpc/mcp750 -See @code{powerpc/motorola_shared/README}. - -@item powerpc/mvme230x -See @code{powerpc/motorola_shared/README.MVME2300}. - -@item powerpc/psim -This is a BSP for the PowerPC simulator included with @code{powerpc-rtems-gdb}. -The simulator is complicated to initialize by hand. The user is referred -to the script @code{powerpc/psim/tools/psim}. - -@item sparc/erc32 -The ERC32 is a radiation hardened SPARC V7. This BSP can be used with either -real ERC32 hardware or with the simulator included with @code{sparc-rtems-gdb} -(for this, you should configure RTEMS to use @code{sis} BSP). An application -can be run on the simulator by executing the following commands upon entering -@code{sparc-rtems-gdb}: - -@example -target sim -load -run -@end example - -In case that you don't need a debugger, an application can be run by -@code{spart-rtems-run}. - - -@end table - -RTEMS has many more BSPs and new BSPs for commercial boards and CPUs -with on-CPU peripherals are generally welcomed. - -@c -@c C/C++ Sample Applications -@c -@section C/C++ Sample Applications - -The C/C++ sample application set includes a number of simple applications. -Some demonstrate some basic functionality in RTEMS such as writing -a file, closing it, and reading it back while others can serve as -starting points for RTEMS applications or libraries. Start by -unarchiving them so you can peruse them. Use a command similar to -the following to unarchive the sample applications: - -@example -cd tools -tar xjf ../archive/examples-v2-@value{RTEMSAPI}.<VERSION>.tgz -@end example - -Each tests is found in a separate subdirectory and built using the same -command sequence. The @code{hello/hello_world_c} sample will be used -as an example. - -@c -@c Build the C Hello World Application -@c -@subheading Build the C Hello World Application - -Use the following command to start the build of the sample hello -world application: - -@example -cd hello_world_c -make -@end example - - -If the sample application has successfully been built, then the application -executable is placed in the following directory: - -@example -hello_world_c/o-optimize/<filename>.ralf -@end example - -The other sample applications are built using a similar procedure. - -@c -@c Ada Sample Applications -@c -@section Ada Sample Applications - -The Ada sample application set primarily includes a a simple Hello -World Ada program which can be used as a starting point for GNAT/RTEMS -applications. Use the following command to unarchive the Ada sample -applications: - -@example -cd tools -tar xjf ../archive/ada-examples-@value{RTEMSAPI}.<VERSION>.tgz -@end example - -@subheading Create a BSP Specific Makefile - -Currently, the procedure for building and linking an Ada application -is a bit more difficult than a C or C++ application. This is certainly -an opportunity for a volunteer project. - -If your BSP requires special arguments when linking, you may have to augment the file @code{ada-examples-@value{RTEMSAPI}.<VERSION>/Makefile.shared}. Most RTEMS BSPs do not require special linking arguments so this should not be frequently needed. - -Use the <INSTALLATION_POINT> and <BOARD_SUPPORT_PACKAGE> specified when -configuring and installing RTEMS. - -@section Build the Sample Application - -Use the following command to start the build of the sample application: - -@example -cd tools/ada-examples-@value{RTEMSAPI}.<VERSION>/ada-examples/hello_world_ada -@end example - -If no errors are detected during the sample application build, it is -reasonable to assume that the build of the GNAT/RTEMS Cross Compiler Tools -for RTEMS and RTEMS itself for the selected host and target combination -was done properly. - -@section Application Executable - -If the sample application has successfully been build, then the application -executable is placed in the following directory: - -@example -tools/@code{ada-examples-@value{RTEMSAPI}.<VERSION>}/hello_world_ada/o-optimize/<filename>.exe -@end example - -How this executable is downloaded to the target board is very dependent -on the BOARD_SUPPORT_PACKAGE selected. - -@c -@c More Information on RTEMS Application Makefiles -@c -@section More Information on RTEMS Application Makefiles - -These sample applications are examples of simple RTEMS applications -that use the RTEMS Application Makefile system. This Makefile system -simplifies building RTEMS applications by providing Makefile templates and -capturing the configuration information used to build RTEMS specific to -your BSP. Building an RTEMS application for different BSPs is as simple -as switching the setting of @code{RTEMS_MAKEFILE_PATH}. This Makefile -system is described in the file @code{make/README}. - -It is very likely in the future that the RTEMS examples built using an -installed RTEMS will be converted to autoconf. - diff --git a/doc/started/stamp-vti b/doc/started/stamp-vti deleted file mode 100644 index 5634951ec8..0000000000 --- a/doc/started/stamp-vti +++ /dev/null @@ -1,4 +0,0 @@ -@set UPDATED 24 February 2013 -@set UPDATED-MONTH February 2013 -@set EDITION 4.10.99.0 -@set VERSION 4.10.99.0 diff --git a/doc/started/started.texi b/doc/started/started.texi deleted file mode 100644 index 4d453e672c..0000000000 --- a/doc/started/started.texi +++ /dev/null @@ -1,99 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@setfilename started.info -@setcontentsaftertitlepage -@syncodeindex vr fn -@synindex ky cp -@c @paragraphindent 0 -@c %**end of header - -@c -@c COPYRIGHT (c) 1989-2013. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@c -@c Master file for the Getting Started (C) Guide -@c - -@include version.texi -@include common/setup.texi -@include common/rtems.texi - -@ifset use-ascii -@dircategory RTEMS On-Line Manual -@direntry -* Getting Started with RTEMS: (started). -@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 Getting Started with RTEMS - -@setchapternewpage odd -@settitle Getting Started with RTEMS -@titlepage -@finalout - -@title Getting Started with RTEMS -@subtitle Edition @value{EDITION}, for @value{VERSION} -@sp 1 -@subtitle @value{UPDATED} -@author On-Line Applications Research Corporation -@page -@include common/cpright.texi -@end titlepage - -@c This prevents a black box from being printed on "overflow" lines. -@c The alternative is to rework a sentence to avoid this problem. - -@contents - -@ifnottex -@node Top, Introduction, (dir), (dir) -@top Getting Started With RTEMS - -This is the online version of the Getting Started with RTEMS. - -@menu -* Introduction:: -* Requirements:: -* Building the GNU Cross Compiler Toolset with RSB:: -* Building RTEMS:: -* Building the Sample Applications:: -* Where To Go From Here:: -* Using MS-Windows as a Development Host:: -@end menu -@c * Command and Variable Index:: -@c * Concept Index:: -@end ifnottex - -@include intro.texi -@include require.texi -@include buildc.texi -@include buildrt.texi -@include sample.texi -@include nextstep.texi -@include nt.texi - -@c @node Command and Variable Index, Concept Index, Installing GCC AND NEWLIB, Top -@c @unnumbered Command and Variable Index - -@c There are currently no Command and Variable Index entries. - -@c @printindex fn - -@c @node Concept Index, , Command and Variable Index, Top -@c @unnumbered Concept Index - -@c There are currently no Concept Index entries. -@c @printindex cp - -@bye - diff --git a/doc/started/version.texi b/doc/started/version.texi deleted file mode 100644 index c0e4bbb7b6..0000000000 --- a/doc/started/version.texi +++ /dev/null @@ -1,4 +0,0 @@ -@set UPDATED 17 July 2015 -@set UPDATED-MONTH July 2015 -@set EDITION 4.10.99.0 -@set VERSION 4.10.99.0 |
