How to say 'hello' on EVB7045F? (gensh2)

[Ralf Corsepius]

Radzislaw Galler wrote:
> 
> Hi
> 
> 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.
> (success)
> 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.

> (success)
> 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 1.10.2.1 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
>     )
> {
>     writew(PFC_PEIOR,0xFFFF);

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
> ar
> welcome to change it and/or distribute copies of it under certain
> condition
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "--host=i586-pc-linux-gnu
> --target=sh-rtemself"...

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
> Continuing.

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
hangups).
 
> -----------------------------------------
> 
> I can see here two strange things:
> 1. The debugger couldn't find debug symbols
cf. above.

> 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
(linkcmds).

Ralf
-- 
Ralf Corsepius 
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany     Tel: +49/731/501-8690
mailto:corsepiu at faw.uni-ulm.de           FAX: +49/731/501-999  
http://www.faw.uni-ulm.de