source: rtems/c/src/lib/libbsp/m68k/mvme162/README @ 254b4450

4.104.114.84.95
Last change on this file since 254b4450 was 5c491aef, checked in by Joel Sherrill <joel.sherrill@…>, on 12/20/95 at 15:39:19

changes remerged after lost in disk crash -- recovered from snapshot, partially recovered working tree, etc

  • Property mode set to 100644
File size: 5.8 KB
Line 
1--
2--  EISCAT Scientific Association. M.Savitski
3--
4--  This material is a part of the MVME162 Board Support Package
5--  for the RTEMS executive. Its licensing policies are those of the
6--  RTEMS distribution.
7--
8--  Updated by Joel Sherrill (jsherril@redstone.army.mil) after
9--  inclusion in the standard release.
10--
11--  $Id$
12--
13
14This is a README file for the MVME162 port of RTEMS.
15
16Disclaimer
17----------
18This is my first attempt at porting RTEMS. The resulting code obviously
19contains bugs (know and unknown) and limitations. I assume no
20responsibility for quality and support of the software in question.
21
22Now on more optimistic note:
23
24I have run most of the standard RTEMS sptests, and neither of them
25failed. My present (short) experience of developing RTEMS applications
26is essentially positive and suggestive of a long-term commitment. In
27any case I am ready to answer questions regarding the port and intend
28to follow the future RTEMS versions. I will do my best to provide
29whatever support I can afford time-wise.
30
31MVME162FX and DMA on the IP bus
32-------------------------------
33
34From Eric Vaitl <eric@viasat.com>:
35
36If you have any customers that will be using the 162FX, tell them to
37be careful. The main difference between the 162 and the 162FX is DMA
38on the IP bus. I spent over a month trying to write a DMA HDLC driver
39for GreenSprings IP-MP and couldn't get it to work. I talked to some
40people at GreenSprings, and they agreed that there really is no way to
41get DMA to work unless you know the size of the packets in advance.
42Once the IP2 chip DMA controller is given the character count and
43enabled, it doesn't accept further commands until all of the
44characters have arrived. The only way to terminate a DMA transfer
45prematurely is by raising DMAEND* during the last read. None of the IP
46modules that I know of are currently able to do that. GreenSprings is
47working on the problem, but nothing is going to available for a few
48months.
49
50Installation
51------------
52Nothing unique to the MVME162.  It has been incorporated into the
53standard release.
54
55Port Description
56----------------
57The port was done using already existing ports to the M68020 boards,
58DMV152 and MVME136.
59
60The host system was SUN/Solaris 2.3, and the cross-development
61environment consisted of Free Software Foundation (FSF)'s GNU C
62compiler (version 2.6), GNU Assembler (version 2.3) and GNU binary
63utilities binutils version 2.5.2, built with m68k as a target. The
64recent/latest versions of other GNU programs (flex, make, etc) were
65also used at the build stage.
66
67In all subdirectories of the RTEMS distribution tree, the directories
68mvme136 were duplicated as mvme162.
69
70Essential modifications are detailed below:
71
72- the MVME162-specific hardware registers were described in bsp.h
73
74- timer and clock routines were made to use the MVME162's Tick Timers 1
75and 2, respectively
76
77- shared memory support was replaced by stubs for the time being
78
79- console IO was lifted entirely from the DMV152 support code, thanks
80to the fact that Z8530 SCC used in DMV152 is upwards compatible with
81the Z85230 SCC of the MVME162. (Only the memory mapping of the SCC
82registers had to be changed.)
83
84- symbols in several *.s files were prepended with underscores to
85comply with the xgcc configuration used (it prepends underscores to all
86symbols defined in c code)
87
88- linkcmds file was modified to place the linked code into the memory
89configured for the board in use
90
91- bspstart.c was modified as follows:
92
93         monitors_vector_table = (m68k_isr *)0xFFE00000;
94
95was made to point to the power-up location of MVME162 interrupt vector
96table. 
97     
98- The shutdown is a temporary solution. To exit cleanly, it has to disable
99all enabled interrupts and restore the board to its power-up status.
100Presently this is not done satisfactorily, as a result, the board needs
101a hardware reset from the external VMEbus master or from the front
102panel to ensure correct operation for subsequent downloads.
103
104Host System
105-----------
106The VMEbus master used to externally control and download the MVME162
107is a FORCE CPU-2CE board running Solaris 2.3. A simple program to load
108s-records and start/reset the MVME162 was written. The code is in the
109file tools/sload.c
110
111This code depends on the external VMEbus master's vme driver and is
112provided as an example, without the Makefile. The bulk of the program
113which parses the s-records is courtesy of Kym Newbery,
114(8918927y@lux.levels.unisa.edu.au).
115
116In general, apart from x-gcc, the tools most often used while building
117RTEMS for MVME162 were: find, grep, diff, and, of course
118
119MVME162 Embedded Controller Programmer's Reference Guide,
120Motorola, MVME162PG/D1.
121
122Thanks
123------
124- to On-Line Applications Research Corporation (OAR) for developing
125RTEMS and making it available on a Technology Transfer basis;
126- to Joel Sherril, the leader of the RTEMS development group for
127stimulating and helpful discussions;
128- to Kym Newbery (8918927y@lux.levels.unisa.edu.au) for his s-record
129parser;
130- to Gerd Truschinski (gt@first.gmd.de) for creating and running the
131crossgcc mailing list
132- to FSF and Cygnus Support for great free software;
133
134What's new
135----------
136  - 28.07.95 BSP adjusted to rtems-3.2.0.
137  - Now console driver uses interrupts on receive (ring buffer
138    code lifted with thanks from the IDP BSP next door (../idp))
139  - both front-panel serial interfaces are supported
140  - serious bug in timer interrupts fixed
141  - interrupt test tm27 now supported
142 
143+----------------------------------+-------------------------------+
144|  Dr. Mikhail (Misha) Savitski    |  Voice : +46-980-79162        |
145|  Software Systems Engineer       |  Fax   : +46-980-79161        |
146|  EISCAT Svalbard Radar Project   |  E-mail: mms@eiscathq.irf.se  |
147|  EISCAT Scientific Association   |-----------  /\_/\  -----------|
148|  Box 812 S-98128 Kiruna, Sweden  |  EIS       { o o }       CAT  |
149+----------------------------------+-------oQQQ--(>I<)--QQQo-------+
150
151
Note: See TracBrowser for help on using the repository browser.