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

[Ralf Corsepius]

Radzislaw Galler wrote:
> 
> Ralf Corsepius wrote:
> > Does this look better (gensh2)?
> >
> > # sh-rtemself-size o-debug/hello.exe
> >   text    data     bss     dec     hex filename
> >  83508    3376    5544   92428   1690c o-debug/hello.exe
> >
> > (gdb) load o-debug/hello.exe
> > Loading section .text, size 0x1395c vma 0x444000
> > Loading section .rodata, size 0xcd8 vma 0x45795c
> > Loading section .data, size 0xd2c vma 0x4586b4
> > Loading section .stack, size 0x4 vma 0xfffffec0
> > Start address 0x444000
> 
> Now with prebuild tools I've got:
> 
> /opt/rtems/bin/sh-rtems-size o-debug/hello.exe
>    text    data     bss     dec     hex filename
>   77200    2944    5404   85548   14e2c o-debug/hello.exe
Looks reasonable, because I used newlib-1.9.0 and a local
development version of RTEMS.
 
> (gdb) load o-debug/hello.exe
> Loading section .text, size 0x12d80 lma 0x444000
> Loading section .data, size 0xb80 lma 0x456d80
> Loading section .stack, size 0x10 lma 0xfffffec0
> Start address 0x444000 , load size 80144
> 
> As you can see the sections problem is fixed, but there's .rodata
> missing.
I don't know what the .rodata section is :)

You might consider to compare the gensh2's linkcmds against gcc's
default linkerscripts (eg. shelf.x) which should be somewhere in
sh-rtemself-gcc's installation tree.
 
> And the LED still doesn't go out...
This could be anything, eg. incorrectly setting up the cpu's
peripherials. Did you try to set breakpoints and to step through
instructions? If this doesn't work, there is a problem with gdb.

> >
> > Solution: Change the output format in linkcmds to elf32-sh:
> >
> > -OUTPUT_FORMAT("coff-sh")
> > +OUTPUT_FORMAT("elf32-sh", "elf32-sh", "elf32-sh")
> >  OUTPUT_ARCH(sh)
> >  ENTRY(_start)
> 
> I did that, but gdb crashed saying something about unrecognized
> architecture sh4 (?!), so I decided to install prebuild toolset.
I saw this happening too - Seems to be a bug in libbfd or gdb to me.

But I only saw it, when explicitly setting the architecture to
something > sh3 (eg. set archi sh4).

> Could you tell me what versions of build tools do you use and

binutils-2.10 + binutils-2.10-rtems-20000726.diff
gcc-2.96.2 + gcc-2.95.2-rtems-20001030.diff
newlib-1.9.0 + newlib-1.9.0-rtems-20001219.diff
gdb-5.0 + gdb-5.0-rtems-20000718.diff

Both sh-rtems and sh-rtemself.

The tar balls originate from ftp://ftp.gnu.org, the patches are
OAR's original patches.

All toolchains built from scratch on Saturday, using RTEMS's
rpm-specs (cf. scripts/) under SuSE-7.0 (+ local modifications)
using SuSE's gcc-2.96 and VaLinux's (H.J.Lu's ) binutils-2.10.1.0.2.

> what kind of monitor do you have on your EVB?
I don't have an sh7045EVB. I have custom designed sh7032 (SH1)
boards, which are very similar to Hitachi's original SH7032EVB. On
these boards, the same monitor as on the sh7032EVBs (Hitachi's CMON)
is used, which includes a very simple gdb-stub, derived from the old
m68k gdb-stub from gdb.

To check the loading behaviour, I used gdb-5.0's sh simulator.
 
> Have you succeed running some application? How?

Not any SH2 application, yet (No board, no simulator bsp). 

However I have been running SH1-rtems (coff) applications with our
custom BSP (gensh1 adapted to your board's specific needs) and to
some very limited extend (hello.exe :), SH1-rtems (coff) and
SH1-rtemself applications with gdb's sh-simulator (Yes, Joel, I have
got it (partially) working :) ).

When trying sh-rtemself with our SH1-boards the last time (> 1.5
years ago), I had severe problems.

Ralf