LinuxSH

Did you used sh-ipl+g as is for sh-2 only setting you serial line?
It should be working with the job done by Paul Mundt.
Is it rigth Paul?
Anyway Min ZOU, we have a working version for sh4 7044.

Regards

Fabio


On Thursday 20 January 2005 09:30, Min ZOU wrote:
> Hi,
>
> Sorry this problem is not really Linux related. It is about GDB stub
> implementation for SH2.
>
> I have modified the sh-stub.c from gdb-v6.3 source, and integrated to an
> existing monitor code for my SH2 target (SH7145). It is like a
> simplified version of "sh-ipl+g" for SH2. However I have problem to boot
> T-Kernel(yet another RTOS) using the gdb stub.
>
> I followed the procedure in this document:
> http://linuxsh.sourceforge.net/docs/gdb.php3
>
> Here is my steps:
>
> 1. boot the target into gdb stub mode (via trapa #32), which outputs:
>     $S05#b8
> 2. quit the terminal, and start gdb on host with the kernel ELF binary:
>     sh-elf-gdb kernel-rom.abs
> 3. the following is printed out:
>     0x00001314 in ?? ()
> 4. load the binary:
>     (gdb) load
> 5. start the kernel:
>     (gdb) c
>     Continuing.
>     Sending packet: $Z0,1ba26,2#70...Ack
>     Packet received:
>     Packet Z0 (software-breakpoint) is NOT supported
>     Sending packet: $m1ba26,2#27...Ack
>     Packet received: d107
>     Sending packet: $M1ba26,2:c320#39...Ack
>     Packet received: OK
>     Sending packet: $Hc0#db...Ack
>     Packet received:
>     Sending packet: $c#63...Ack
>
>
> After that, the gdb just hangs and has no responding...
> I am not sure if I missed any modification to the gdb-stub or the kernel
> code. Do I need to insert a software breakpoint in the kernel?
>
> Or, is any other simple way to test if the gdb stub is working?
>
> Thanks for any hints!
>
> P.S. I am not on the list. Please CC me.
>
> --
> Best regards,
> Min

Hi Fabio,

Fabio Giovagnini wrote:
> Did you used sh-ipl+g as is for sh-2 only setting you serial line?

I used my own UART initialization routine, and it is working. In fact, 
the hardware initialization part is not the issue. The problem is more 
on how gdb stub handles breakpoint and continue commands from gdb.

 >>5. start the kernel:
 >>    (gdb) c
 >>    Continuing.
 >>    Sending packet: $Z0,1ba26,2#70...Ack
 >>    Packet received:
 >>    Packet Z0 (software-breakpoint) is NOT supported
 >>    Sending packet: $m1ba26,2#27...Ack
 >>    Packet received: d107
 >>    Sending packet: $M1ba26,2:c320#39...Ack
 >>    Packet received: OK
 >>    Sending packet: $Hc0#db...Ack
 >>    Packet received:
 >>    Sending packet: $c#63...Ack

For the above scenario (in my previous email), I have a few questions:
- why does gdb know to write "c320" which is the opcode for "trapa #32" 
for SH2?
- what are the possible reasons of why there is no response from stub 
after gdb sends the packet "$c#63"?

> It should be working with the job done by Paul Mundt.
> Is it rigth Paul?
> Anyway Min ZOU, we have a working version for sh4 7044.

Where is the source code available?

Thanks!

-- 
Best regards,
Min

Hi Paul, was the sh-ipl+g you developed for arn44b (sh2 7044 based board) 
available on CVS? Did you test it?

Thanks 

Ciao

Fabio


On Thursday 20 January 2005 12:41, Min ZOU wrote:
> Hi Fabio,
>
> Fabio Giovagnini wrote:
> > Did you used sh-ipl+g as is for sh-2 only setting you serial line?
>
> I used my own UART initialization routine, and it is working. In fact,
> the hardware initialization part is not the issue. The problem is more
> on how gdb stub handles breakpoint and continue commands from gdb.
>
>  >>5. start the kernel:
>  >>    (gdb) c
>  >>    Continuing.
>  >>    Sending packet: $Z0,1ba26,2#70...Ack
>  >>    Packet received:
>  >>    Packet Z0 (software-breakpoint) is NOT supported
>  >>    Sending packet: $m1ba26,2#27...Ack
>  >>    Packet received: d107
>  >>    Sending packet: $M1ba26,2:c320#39...Ack
>  >>    Packet received: OK
>  >>    Sending packet: $Hc0#db...Ack
>  >>    Packet received:
>  >>    Sending packet: $c#63...Ack
>
> For the above scenario (in my previous email), I have a few questions:
> - why does gdb know to write "c320" which is the opcode for "trapa #32"
> for SH2?
> - what are the possible reasons of why there is no response from stub
> after gdb sends the packet "$c#63"?
>
> > It should be working with the job done by Paul Mundt.
> > Is it rigth Paul?
> > Anyway Min ZOU, we have a working version for sh4 7044.
>
> Where is the source code available?
>
> Thanks!