RTEMS and LCVEB-US7032EVB1

[corsepiu at faw.uni-ulm.de (Ralf Corsepius)]

Silverio Diquigiovanni wrote:

> Hi,
>
> someone have used RTEMS 4.0.0 for Hitachi SH1 with evaluation board
> LCEVB-US7032EVB1 ?
>

Not me.

>
> I have tried to use RTEMS with it but I think have two problems :
>
> 1) In start.s, I think, RTEMS copy vector area in 0x0 memory address
>    actually occupied from CMON monitor (EPROM).
>

I don't understand your question.

start.s  copies the vector table from EPROM (0x00000000) to the .vects
section (0x0a042000) in RAM and then enters RTEMS. I.e. it uses values
found in EPROM at bootup as defaults for RTEMS. This normally is what you
want to have, because otherwise you would not be able to use gdb.
Afterwards you still have opportunities to set vector table entries inside
your application or inside drivers.

>
> 2) In linkcmds the segments are not correct for her memory locations !

The addresses may vary for your board.

>
>    (Ralf Corsepius said : "memory layout for an SH7032 with main memory
>     in area 2. This memory layout it very similar to that used for
> Hitachi's    EVB with CMON in rom".)

Please read again: I said "similar" - I did not say "identical".

FYI: I have the source code of CMON and I have the original Hitachi EVB
documentation, but I don't own a Hitachi EVB:

FWIW: This is one of the original Hitachi linker scripts from Hitachi's
manual:

ENTRY(_start)
OUTPUT_FORMAT(srec)
SECTIONS
{
  .vects 0x0A002000 : { *(.vects);}
  .text  0x0A004000 : { *(.text) _mdata = .;}
  .mdata 0x0A006000 : AT(ADDR(.text) + SIZEOF(.text))
                      { _data = .; *(.data) _edata = .;}
  .bss   .          : { _bss = .; *(.bss) *(COMMON) _ebss = .;}
  .stack 0x0A00F000 : { _stack = .; *(.stack)}
}

It also uses main RAM in area 2, and, though being much smaller than RTEMS
sh7032 linker script, it implements basically the same memory layout.

What may be confusing is this our way of setting up the start address of
the external RAM, because we use bits 16-19 for encoding access to
external memory mapped peripherials (The RAM is one of those).

0x08000000 (->16bit address mode) |
0x02000000 (-> area 2) |
0x00040000 (->physical start address)
= 0x0A040000

We have 256k of RAM onboard, therefore only the least 16bit of an address
are actually used for encoding an address inside the RAM.

* bits 28-31 are ignored by the CPU
* bit 27 is used by the CPU to encode 8/16bit address mode
* bits 24-26 encode the memory area
* bits 20-23 are unused
* bits 16-19 are used by our boards to access memory mapped external
peripherials
* bits 0-15 are the actual address bits to encode an address in RAM.

=> Our way of addressing is equivalent to Hitachi's original addressing
unless more than 256k is attached to a board.

AFAIK, the original Hitachi boards only have 32k or 64k of RAM. If you are
trying to use one of these boards you are probably seeing effects from
accessing memory addresses above the physical limits of  RAM being
shadowed to the memory you actually have => Your down load images are too
large.

If you have more than 256k (IIRC, up to 4MB are supported in area 2) you
have  to adapt the linker script for the EVB (set bits 16-19 to zero in
your BSP's 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