1 |
30 |
unneback |
#
|
2 |
|
|
# $Id: README,v 1.2 2001-09-27 11:59:44 chris Exp $
|
3 |
|
|
#
|
4 |
|
|
|
5 |
|
|
#
|
6 |
|
|
# Please send any comments, improvements, or bug reports to:
|
7 |
|
|
# Chris Johns
|
8 |
|
|
# Objective Design Systems
|
9 |
|
|
# 35 Cairo Street
|
10 |
|
|
# Cammeray
|
11 |
|
|
# Sydney, NSW 2062
|
12 |
|
|
# ccj@acm.org
|
13 |
|
|
#
|
14 |
|
|
|
15 |
|
|
#
|
16 |
|
|
# Overview
|
17 |
|
|
# ~~~~~~~~
|
18 |
|
|
# This board support package is not a board support package at all, but
|
19 |
|
|
# a means to build the RTEMS kernel without using a specific BSP.
|
20 |
|
|
#
|
21 |
|
|
# You should be able to build to build this BSP for any cpu type.
|
22 |
|
|
#
|
23 |
|
|
# You must provide the standard BSP type functions and support yourself
|
24 |
|
|
# externally to RTEMS.
|
25 |
|
|
#
|
26 |
|
|
# This BSP is intended to be used by people who fit one or more of the
|
27 |
|
|
# categories below :
|
28 |
|
|
#
|
29 |
|
|
# 1) using custom hardware of little use or interest to others. If you
|
30 |
|
|
# intend to use hardware available to others, please create a BSP
|
31 |
|
|
# and send to OARCorp.
|
32 |
|
|
#
|
33 |
|
|
# 2) production code cannot depend on software which can change. BSP code
|
34 |
|
|
# can change with-out notice, while RTEMS has very tightly defined
|
35 |
|
|
# interfaces which do not change.
|
36 |
|
|
#
|
37 |
|
|
# 3) the need to extend or change an existing BSP in ways which are not
|
38 |
|
|
# of interest to others or the BSP maintainer.
|
39 |
|
|
#
|
40 |
|
|
# I fit all the above.
|
41 |
|
|
#
|
42 |
|
|
# Issues
|
43 |
|
|
# ~~~~~~
|
44 |
|
|
# I do not consider the bare BSP as a starting point for RTEMS. The
|
45 |
|
|
# BSP code integrated into the RTEMS build tree has the advantage of
|
46 |
|
|
# building all the test and sample code. The sample and test code is
|
47 |
|
|
# important for validatation of your tools, and getting your BSP
|
48 |
|
|
# working correctly.
|
49 |
|
|
#
|
50 |
|
|
# Once you gain experience with RTEM and your application matures the
|
51 |
|
|
# need to break the BSP code out from the kernel becomes important. It
|
52 |
|
|
# is at this point in time that the bare BSP becomes useful.
|
53 |
|
|
#
|
54 |
|
|
# Once free you are able to upgrade without the worry of makefile or
|
55 |
|
|
# build tree changes which can break your BSP.
|
56 |
|
|
#
|
57 |
|
|
# How To Configure
|
58 |
|
|
# ~~~~~~~~~~~~~~~~
|
59 |
|
|
# RTEMS requires you to select a BSP inorder to build the kernel.
|
60 |
|
|
# If you take a close look at a BSP which is closest to your
|
61 |
|
|
# needs you will find somewhere the CPU model and CPU compile
|
62 |
|
|
# flags are specified. This is the only piece of information
|
63 |
|
|
# required by the kernel inorder for it to build.
|
64 |
|
|
#
|
65 |
|
|
# This highlights the clean design of the kernel and its
|
66 |
|
|
# independence from the particulars of target hardware.
|
67 |
|
|
#
|
68 |
|
|
# The CPU model is the RTEMS model and usually tries to match with
|
69 |
|
|
# the GCC model. There are variations on some processors. If you are
|
70 |
|
|
# unsure please ask on the RTEMS list. Someone will know (I hope).
|
71 |
|
|
#
|
72 |
|
|
# The CPU flags allow you to select specific operating modes for
|
73 |
|
|
# GCC. For example the PowerPC has specific flags to control various
|
74 |
|
|
# cache resouces. Another example is the 68000 family of embedded
|
75 |
|
|
# processor do not have FPU hardware and require software emulation.
|
76 |
|
|
#
|
77 |
|
|
# An example configuration command line is:
|
78 |
|
|
#
|
79 |
|
|
# ../rtems-4.0/configure --target=m68k-rtems \
|
80 |
|
|
# --prefix=/ods/egcs/test \
|
81 |
|
|
# --enable-cxx \
|
82 |
|
|
# --enable-gmake-print-directory \
|
83 |
|
|
# --disable-tests \
|
84 |
|
|
# --disable-posix \
|
85 |
|
|
# --enable-networking \
|
86 |
|
|
# --enable-bare-cpu-cflags=-mcpu32 \
|
87 |
|
|
# --enable-bare-cpu-model=mcpu32 \
|
88 |
|
|
# --enable-rtemsbsp=bare
|
89 |
|
|
#
|
90 |
|
|
# Building RTEMS
|
91 |
|
|
# ~~~~~~~~~~~~~~
|
92 |
|
|
# You are required to do nothing special here. Just follow the documented
|
93 |
|
|
# steps. The samples are built but no linking occurs. The link command
|
94 |
|
|
# is stubbed out to produce a Unix shell script.
|
95 |
|
|
#
|
96 |
|
|
# After installation you will find a directory called 'bare'. The nature
|
97 |
|
|
# of the RTEMS build system means the bare BSP will only install into the
|
98 |
|
|
# the bare directory under the specifed configuration prefix.
|
99 |
|
|
#
|
100 |
|
|
# I therefore suggest you move the directory to another name. This allows
|
101 |
|
|
# you to make and install another bare BSP for a different variant of
|
102 |
|
|
# CPU without over writing the last installed variant.
|
103 |
|
|
#
|
104 |
|
|
# I have provided a script file I use to configure and build RTEMS
|
105 |
|
|
# from the arcihve. Take a copy and use it if you find it useful.
|
106 |
|
|
#
|
107 |
|
|
# Creating an Application.
|
108 |
|
|
# ~~~~~~~~~~~~~~~~~~~~~~~~
|
109 |
|
|
# This is something which is usually specific to your local environment.
|
110 |
|
|
# The bare BSP does not lock you into any specific makefile or build
|
111 |
|
|
# system. A couple of suggestions are:
|
112 |
|
|
#
|
113 |
|
|
# o Get the sample bare BSP application, or
|
114 |
|
|
# o Watch RTEMS build a BSP which is closest to yours and copy
|
115 |
|
|
# the command lines used.
|
116 |
|
|
#
|
117 |
|
|
|