RTEMS 6.1-rc6
|
Author: Ralf Corsepius (corse.nosp@m.piu@.nosp@m.faw.u.nosp@m.ni-u.nosp@m.lm.de) Adapted by: John Mills (jmill.nosp@m.s@tg.nosp@m.a.com) Corrections: Radzislaw Galler (rgall.nosp@m.er@e.nosp@m.t.put.nosp@m..poz.nosp@m.nan.p.nosp@m.l)
(1) The present 'hw_init.c' file provides 'early_hw_init'(void) which is normally called from 'start.S' to provide such minimal HW setup as is conveniently written in 'C' and can make use of global symbols for 7045F processor elements. It also provides 'void bsp_hw_init (void)' normally called from 'bspstart.c', shortly before RTEMS itself is started.
These are both minimal functions intended to support the RTEMS test suites.
(2) See README.EVB7045F
Author: Radzislaw Galler (rgall.nosp@m.er@e.nosp@m.t.put.nosp@m..poz.nosp@m.nan.p.nosp@m.l)
This is a capture of success path to put a RTEMS sample 'hello.exe' on the evaluation board EVB7045F.
Once you downladed and unzipped gdbstubs you have to compile it. First modify the Makefile to use the compiler installed on your machine. Then issue the command:
$ make
This should produce the default target sh2-7045edk.out. This is the S-record file which should be added to FDT project (renaming it to *.mot extension helps a bit). If you are lucky you will be able to put the file into the FLASH following the instuctions in FDT and EVB manuals.
Well I wasn't lucky so I had to bypass the Universal Programming Board (see EVB7045F User Manual) and manually put the processor into BOOT mode. This can be done by shortening the capacitor C8 (or C108 on schematics) which puts the UPB into permanent reset state, and by removing jumper JP4 (or JP104 on schematics) and connecting its middle pin to the ground. After pressing CRES button the processor is in BOOT mode. In FDT select "direct connection":
Menu Project->Properties->Device->Select Interface
After that there should be no problem in putting the program into the FLASH.
I assume you are able to compile RTEMS with 'gensh2' BSP and necessary tools. If not please refer to 'started.pdf' document which describes the procedure (http://www.oarcorp.com/).
At the time of writing this document 'gdbstubs' default communication port was SCI1. So it was the default port for /dev/console in RTEMS. To avoid problems I had check these settings both in 'gdbstubs' and $RTEMS_ROOT/c/src/lib/libbsp/sh/gensh2/include/bsp.h
After changing the line
to
in 'bsp.h' and rebuilding RTEMS there should no problem in running 'hello.exe' and other samples.
For downloading connect a serial cable to computer and EVB. You will also need a second cable and second serial port to see the effects of your work.
Assuming you are working in Linux and Xwindows fire up two terminal windows. In the first one run sh-rtems-gdb, in the second run a serial port terminal (for example 'minicom'). Set up the serial terminal to a port connected to SCI0 and leave the window in a visible place on the desktop. The debugger should be invoked best from the directory where 'hello.exe' is placed. Assuming that here is a GDB session:
-----—start---—
And here is a capture from the serial terminal window:
I'm sure that not every one can afford having two operating systems on one computer. I believe there will be a day that nobody will need an MS stuff anymore... ;)
It is possible to repeat the success on MS Windows only. To do the same on Linux only you need a tool to downlad 'gdbstubs' on the board. This should be no problem to find it on the net but right now I don't know about it.
For your convenience there are several graphical interfaces for GDB available on the net. I just name two of them:
DDD - stands for Data Display Debugger (http://www.gnu.org/software/ddd/)
Insight - a Tcl/Tk interface available both for MS Windows and Xwindows (http://sources.redhat.com/insight/)