[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Ralf Corsepius wrote:
> 
> 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.

Hmmm... I wonder what got larger. :(  Size is a continuous
battle.

> > (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 :)

My understanding is that it is "const" data.  It is usually
loaded in the same area as .text.  The ld manual shows it
immediately after .text.  

This is distinct from the initialized values for the .data section.
For information on how to handle these better, look for "output 
section LMA" in the GNU ld manual.  I think the sim68000 BSP does
this correctly.

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

Did you actually get to your task?  When you switch to the first
task interrupts are enabled for the first time and it is common
to get an interrupt there from something that you forgot to disable.

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

:(  Probably the best idea is to simply remove the OUTPUT_FORMAT
line and make it default.  Very likely, the sh gdb does not include
the bfd sh-coff routines.

> 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 :) ).

Yeah!  This simulator is only suitable for running tests without
the clock tick but that helps a lot anyway.

I have a (large) patch from  Dietmar Petras
<Dietmar.Petras at elsa.de> to add proper SH3 support.  It simulates
the devices on the SH7708.  I have not had time to look at it.

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

And that is why sh-elf is still the secondary format.  No one
has demonstrated it is suitable for the main format.  I would
love to switch and obsolete the sh-coff.  
 
> Ralf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985