1 | # |
---|
2 | # $Id$ |
---|
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 | |
---|