sh architecture, "hello" sample doesn't work

[Steve Battazzo]

Alberico Colpo wrote:
> You probably already checked, but , is also the parity correct?
>   
>
> Well, after the hello.exe test I rewrote the console driver:
> having only 2 SCI, I'm using SCI1 for both as console and debug port, so I 
> have all the console io functions inside the BSP path.
> I'm not aware of  the changes in console driver for rtems-4.10 (still working 
> on 4.9).
> Anyway, I'm still having some problems (i think mostly configuration problems) 
> in getting the termios driver to use the interrupt driven functions.
>
> I think your debugger hang because the startup code of rtems will reassign the 
> vector table, you need to replace the stub traps (at least 32, 33 , 34 and 
> NMI) before the change of VBR occurs.
>   
Another update.. as you suggested before, checking the parity.. for some 
reason, setting the parity to "odd" on my terminal caused the characters 
to come through correctly.Strangely, I set a break just before the 
printf, and checked the contents of the serial mode register, and got 
back 0x04 which seems wrong.
This means the "multi-processor" bit is enabled, according to the SH 
hardware manual. I don't really know what this is for, but the hardware 
manual says that parity is NOT supposed to used at all when this bit is 
set. Also, looking in sh7_sci.h there is a #define for a flag for it, 
but it doesn't actually look to be implemented in sci.c when the SCI SMR 
is supposed to be written. So something kind of strange may be going on 
here.

I tried replacing the extra traps as you suggested in start.S, but the 
debug stub still hangs up.

The only other thing I could think of was overlap of the stack.
The debug stub puts its .bss section at 0xfffff000, though an objdump 
estimates the size of this at only 90 some odd bytes. The gensh2 bsp 
linkcmds puts the stack at 0xfffffec0, and I see somewhere these lines:

  _CPU_Interrupt_stack_low  = 0xFFFFF000;
  _CPU_Interrupt_stack_high = 0xFFFFFFFF;

I'm actually not really sure what this is for, but I suppose it might 
mean that rtems could be overwriting  part of the debug stub's workspace?
Though if this is the case, I'm surprised that it doesn't hang up 
somewhere in the initialization and memory allocation procedures rather 
than in the final application.

The 7145 CPU I have here actually has double the on chip ram, starting 
at 0xFFFFE000. So I decided to try adjusting the rtems linkerscript to 
put these things all in the part of the RAM that is not being used by 
gdbstubs. Unfortunately, this did not change the fact that gdbstub still 
hangs up before the rtems program can exit. Maybe there is another 
subtle difference between 7045 and 7145 that I haven't noticed yet.

Steve