How to say 'hello' on EVB7045F? (gensh2)
corsepiu at faw.uni-ulm.de
Fri Jan 5 13:31:50 UTC 2001
Radzislaw Galler wrote:
> I need some hint how to put 'hello.exe' sample on the evaluation board
> EVB7045F. Looking into the sources seems that the SH2 BSP development
> was done on this particular board. But when I download the file to the
> board and nothing happens.
> Here are steps I have done:
> 1. build tools for target sh-rtemself on Linux (RH 7.0) (success)
> 2. build RTEMS 4.5.0-beta3a with no POSIX, no C++, no networking etc.
> 3. modified init.c of 'helo' sample so it should turn off green LED on
> the EVB (I know that console is not ready for this BSP)
Well, I know that the sci driver works on on the sh7032. I don't
know about the sh7045s sci driver's status. To my knowledge it
should basically work but would need some more work and debugging.
> 4. the FLASH memory of the processor is programmed with 'gdbstubs'
> (http://sourceforge.net) - I am able to debug some simple selfmade
> programs with it. (success)
> 5. loaded the compiled sample into the EVB (success)
> 6. runnung the sample (failure)
> Here is modified init.c:
> /* Init
> * This routine is the initialization task for this test program.
> * It is called from init_exec and has the responsibility for creating
> * and starting the tasks that make up the test. If the time of day
> * clock is required for the test, it should also be set to a known
> * value by this function.
> * Input parameters: NONE
> * Output parameters: NONE
> * COPYRIGHT (c) 1989-1999.
> * On-Line Applications Research Corporation (OAR).
> * The license and distribution terms for this file may be
> * found in the file LICENSE in this distribution or at
> * http://www.OARcorp.com/rtems/license.html.
> * $Id: init.c,v 22.214.171.124 2000/05/05 12:58:06 joel Exp $
> #define CONFIGURE_INIT
> #include "system.h"
> #include <stdio.h>
> #include <rtems/score/iosh7045.h>
> #include <rtems/score/sh_io.h>
> rtems_task Init(
> rtems_task_argument ignored
Setting up hardware in Init is too late in many cases and is
definitely wrong from a portability point of view.
Things like these should better go to your BSP's start.S/hw_init.c,
bspstart.c (preferred if possible), to your ROMed startup code
(Sometimes required, eg. to setup the SH's memory areas) or in case
you need to set up periperials, to a device drivers *_init function
(allows dynamical configuration).
> printf( "\n\n*** HELLO WORLD TEST ***\n" );
> printf( "Hello World\n" );
> printf( "*** END OF HELLO WORLD TEST ***\n" );
> exit( 0 );
> and here is my gdb session:
> ~/prog/projects/rtems/tests/hello$ sh-rtemself-gdb o-debug/hello.exe
> GNU gdb 5.0
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> welcome to change it and/or distribute copies of it under certain
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> This GDB was configured as "--host=i586-pc-linux-gnu
sh-rtemself with gcc-2.95.2 is known to have a lot of problems,
which is why the defaults for gensh1 and gensh2 still are sh-rtems
(== coff). But YMMV, and it would be nice to hear success stories :)
> (no debugging symbols found)...
Normally, this indicates that -g had not been used during
compilation. By default, -g is used when compiling RTEMS (even with
the optimized version), so I don't know what is happening.
> (gdb) target remote /dev/ttyS0
> Remote debugging using /dev/ttyS0
> 0x0 in CPU_Interrupt_stack_high ()
> (gdb) load
> Loading section .text, size 0x12250 lma 0x444000
> Loading section .rodata, size 0xa70 lma 0x45624c
> Loading section .data, size 0xaf0 lma 0x456d34
> Loading section .comment, size 0x1ee0 lma 0x0
> Loading section .line, size 0x15280 lma 0x0
> Loading section .debug_s, size 0x3870 lma 0x0
> Loading section .debug_s, size 0xa980 lma 0x0
> Loading section .debug_a, size 0x25e0 lma 0x0
> Loading section .debug_p, size 0x3d60 lma 0x0
> Loading section .stack, size 0x10 lma 0xfffffec0
> Start address 0x444000 , load size 257616
> Transfer rate: 62452 bits/sec, 156 bytes/write.
> (gdb) c
You should also consider to set remotebaud and remotecache (help set
remotebaud and help set remotecache in gdb). At least gdb-4.1*
versions had problems in debugging the target, otherwise (random
> I can see here two strange things:
> 1. The debugger couldn't find debug symbols
> 2. There are some sections loaded at address 0x0 which is unaccesible on
> this EVB (RAM starts from 0x400000). The sections overlap each other.
I think you are just being fooled by the debugger's messages. The
debug sections normally do not get downloaded to the target, but
stay on the host.
Otherwise this would indicate a bug in your BSP's link script
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de FAX: +49/731/501-999
More information about the users