[ECOS] question of Gdbstub for NECVR4373 board

[ECOS] question of Gdbstub for NECVR4373 board

[Ling Su]

Hello,

I sent following message regarding to eCos on NEC board, seems he is not
availabe that days, could anyone else help me. Thanks.

I can not make the gdb stub work on the NEC board, and I doubt if the serial
port doesn't support 38400. Therefore, I tried your 9600B version gdb stub,
and also produced one 9600B version by myself. Unfortunately both of them
don't work. :(

I tried to observe something by Logical Analyzer, for the orignal PMON rom,
it works fine. The chip select(CS) for EPROM is high, and I can see the
signal from PCI bus. For the gdb stub binary, the CS is selected once and
once again, nothing appears on PCI bus. I have several specific questions,

<1>. I found even I change the template to vr4373 in eCos configuration
tools, the default setting for the Clock is 50MHZ, actually the MIPS chip on
my
board is 133MHZ. Need I change it? What's your board's clock frequency then?
<2>. What is the start address when I burn the gdbstub EPROM? I burn it from
0x0000, is that correct? I found the inital binary codes for GDB is
different from PMON? Actually I don't know where the system boot from? For
0x0000 address or somewhere else? I tried to decode the stub binary to see
if I can watch in on Logical Analyzer  now.
<3>. I found a minor buggy point of the eCos Configure tools, even I change
the configuration of gdb serial speed to 9600B, when I run tests, it still
"set remotebaud 38400". I feel it will be more convenient if this can be
consistent with what I configured.

Anyway, I still can not successfully communicate with the board by
Hyperterminal or gdb... How eager I am to see a working piece of board! :)

Best Rgds,
-Ling


----- Original Message -----
From: "Jonathan Larmour" <jlarmour@redhat.co.uk>
To: "Ling Su" <lingsu@palmmicro.com>
Sent: Friday, July 28, 2000 6:57 PM
Subject: Re: [ECOS] Help needed: eCos on NEC vr4300 board.


> Ling Su wrote:
> >
> > Thanks a lot! I will take a try soon.
> >
> > One minor question, what's the difference between a .img file and a .bin
> > file, how to convernt between them?
>
> .img is what we use to indicate the ELF executable for the file. You can
> use "mips64vr4300-elf-objcopy -O binary" to convert this into binary
format
> suitable for blowing in a PROM. But we just generate both as part of the
> build process so that you don't have to!
>
> Jifl
> --
> Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223)
728762
> "Plan to be spontaneous tomorrow."  ||  These opinions are all my own
fault
>

Re: [ECOS] question of Gdbstub for NECVR4373 board

[Bart Veer]

>>>>> "Ling" == Ling Su <lingsu@palmmicro.com> writes:

    Ling> I sent following message regarding to eCos on NEC board,
    Ling> seems he is not availabe that days, could anyone else help
    Ling> me. Thanks.

The Red Hat eCos engineers will not generally answer questions sent by
private email, especially non-trivial questions. They may respond to
public questions on ecos-discuss, depending on such factors as their
work load, the complexity of the question, and how likely it is that
the answer will benefit other eCos users in future. If this is
insufficient for your needs you should consider a commercial support
contract, please contact ecos-info@redhat.com for details.

   <snip questions about the NEC board, I do not know much about that
    one>

    Ling> <3>. I found a minor buggy point of the eCos Configure
    Ling> tools, even I change the configuration of gdb serial speed
    Ling> to 9600B, when I run tests, it still "set remotebaud 38400".
    Ling> I feel it will be more convenient if this can be consistent
    Ling> with what I configured.

The various host-side tools (configtool, gdb, ...) have been developed
independently. At some point they may start interacting via e.g. a
CORBA backplane, and things like setting the baud rate correctly will
just work. I have no idea when anything like that is likely to happen.

Of course gdb is used for many different systems, not just eCos. It
cannot be changed in ways that will affect the ability to debug other
systems.

Bart Veer // eCos net maintainer

Re: [ECOS] question of Gdbstub for NECVR4373 board

[Jonathan Larmour]

Bart Veer wrote:
> 
>     Ling> <3>. I found a minor buggy point of the eCos Configure
>     Ling> tools, even I change the configuration of gdb serial speed
>     Ling> to 9600B, when I run tests, it still "set remotebaud 38400".
>     Ling> I feel it will be more convenient if this can be consistent
>     Ling> with what I configured.
> 
> The various host-side tools (configtool, gdb, ...) have been developed
> independently. At some point they may start interacting via e.g. a
> CORBA backplane, and things like setting the baud rate correctly will
> just work. I have no idea when anything like that is likely to happen.
> 
> Of course gdb is used for many different systems, not just eCos. It
> cannot be changed in ways that will affect the ability to debug other
> systems.

I think Ling was referring to the "Run Tests" functionality - it runs GDB
and passes the baud rate in. Perhaps John/Julian can confirm this and have
a look.

[ Julian, are you subscribed to ecos-discuss yet? If not, you should be
:-). ]

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] question of Gdbstub for NECVR4373 board

[Ling Su]

Hi, Jifl,

I know you won't answer private email message sent to you, so I posted it on
the mailing list. I am still stocked by the GDBstub problem. Could you
please take a look at my previous message, and give me some points. For
example, if I should burn the stubrom from zero address, or somewhere else?

When a Cygmon could be available for NEC MIPS board?

Regards,
-Ling

Re: [ECOS] question of Gdbstub for NECVR4373 board

[Jonathan Larmour]

Ling Su wrote:
> 
> Hi, Jifl,
> 
> I know you won't answer private email message sent to you, so I posted it on
> the mailing list. I am still stocked by the GDBstub problem. Could you
> please take a look at my previous message, and give me some points. For
> example, if I should burn the stubrom from zero address, or somewhere else?

Yes, burn it from zero.
 
> When a Cygmon could be available for NEC MIPS board?

No one is paying us to do it, and it would take a little while to code, so
I can't see it happening soon unless someone on the net does it.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: [ECOS] question of Gdbstub for NECVR4373 board

[Bart Veer]

>>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> writes:

    Jifl> Bart Veer wrote:
    >> 
    Ling> <3>. I found a minor buggy point of the eCos Configure
    Ling> tools, even I change the configuration of gdb serial speed
    Ling> to 9600B, when I run tests, it still "set remotebaud 38400".
    Ling> I feel it will be more convenient if this can be consistent
    Ling> with what I configured.
    >> 
    >> The various host-side tools (configtool, gdb, ...) have been developed
    >> independently. At some point they may start interacting via e.g. a
    >> CORBA backplane, and things like setting the baud rate correctly will
    >> just work. I have no idea when anything like that is likely to happen.
    >> 
    >> Of course gdb is used for many different systems, not just eCos. It
    >> cannot be changed in ways that will affect the ability to debug other
    >> systems.

    Jifl> I think Ling was referring to the "Run Tests" functionality
    Jifl> - it runs GDB and passes the baud rate in. 

The whole testing area needs a lot more work than just having the
config tool look for some option that corresponds to the baud rate -
especially since the option name appears to be platform-specific. For
example consider ethernet-based debugging, or more generic device
driver testing.

IMO we need to move to a script-based solution of some sort, which
will require a serious amount of design and implementation.

Bart Veer // eCos net maintainer