[ECOS] Question on wigglers, debugging Redboot in flash fortheXScale target in single step mode

[Krishna Ganugapati]

Thanks Gary. I'm investigating why the single step fails, (I've sent logs to
Macraigor). Thanks for the tip on BDI2000 - I hope to switch debuggers and
JTAG devices.

-- Krishna
-------------------------------------------------
----- Original Message ----- 
From: "Gary Thomas" <gary@mlbassoc.com>
To: "Krishna Ganugapati" <krishnag@marakicorp.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Monday, August 02, 2004 8:20 AM
Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash
fortheXScale target in single step mode


> On Mon, 2004-08-02 at 09:12, Krishna Ganugapati wrote:
> > Gary, Thanks for the response.
> >
> > I'm afraid I don't quite understand what you're saying..
> >
> > a)  > Why do you think this is wrong?  When you reset the board, single
> > > stepping (via hardware which is very different that what you describe
in
> > > item "c" above), you should execute the "reset handler" an instruction
> > > at a time.  This is just what is supposed to happen.
> >
> > Are you saying that this is correct behavior?
>
> Yes.
>
> >
> > When I hit the reset vector, I'm stuck.. subsequent single steps only
keep
> > me at the reset vector - I don't advance any further..
> >
> > b) How do I debug my redboot image?
>
> Figure out the answer to why single step doesn't progress, then you'll
> be able to debug RedBoot.  You _should_ be able to do this with the
> hardware you have, but alas you may have problems.  Given that MacRaigor
> doesn't really support OCD and the Wiggler is pretty primitive and ...
>
> You might consider getting a more powerful debug tool, especially if
> debugging hardware [initialization] is new to you.  One of the best
> available is the BDI2000 from Abatron, but there are many others.
>
> > -------------------------------------------------
> > ----- Original Message ----- 
> > From: "Gary Thomas" <gary@mlbassoc.com>
> > To: "Krishna Ganugapati" <krishnag@marakicorp.com>
> > Cc: <ecos-discuss@sources.redhat.com>
> > Sent: Monday, August 02, 2004 7:59 AM
> > Subject: Re: [ECOS] Question on wigglers, debugging Redboot in flash
forthe
> > XScale target in single step mode
> >
> >
> > > On Mon, 2004-08-02 at 08:49, Krishna Ganugapati wrote:
> > > > Hello,
> > > >
> > > > I'm looking for some clarification on the following issues.
> > > >
> > > > Target;: Custom IXP425 XScale (almost identical to the IXDP
development
> > > > board, minus the highspeed UART and minus the LEDs), Redboot in ROM
> > mode.
> > > > Debugging interface:  Macraigor Wiggler, OCD Commander for the
software
> > > > debugger on the host.
> > > >
> > > > Situation:  I can successfully download my redboot rom image to
Flash
> > using
> > > > the Wiggler and the Macraigor Flash Programmer.
> > > > When I reset my target, I connect to the JTAG port using the OCD
> > Commander
> > > > debugger and attempt to single step through instructions.
> > > >
> > > > Results
> > > >
> > > > 1) Through the OCD Debugger, I note that Flash memory is correctly
> > relocated
> > > > at 0x000000000.
> > > > 2) Using the OCD Debugger, I can manual configure the SDRAM
registers
> > and
> > > > determine that my SDRAM acc ANy recess is good. I flip the
> > > > EXP_BUS_CONFIGURATION bits that switc SDRAM and Flash around and
> > determine
> > > > that SDRAM is now located at 0x00000000 - I can successfully read
and
> > write
> > > > words to the first 256 MB so I am assuming memory is good.
> > > >
> > > > 3) Reset the board, board is now in bootup mode, flash is at
0x00000000.
> > I
> > > > now attempt to single step through my redboot rom image. On the
first
> > > > instruction, the board transfers control to the reset handler.
> > > >
> > > > Questions:
> > > >
> > > >  a) Has anyone seen behavior like this?
> > > > b) On the web it looks like quite a few people have seen something
like
> > > > this, but there have been no followups on how to fix this.
> > > > c) When I reviewed the XScale documentation, it says that when a
> > debugger
> > > > executes a single step instruction, a debug event handler is
expected
> > and
> > > > that this debug event handler is overloaded at the reset handler. It
> > also
> > > > says that the debug event handler code needs to be downloaded to the
> > target
> > > > through the JTAG. Questions:
> > > >     i) Does the OCD Commander software debugger  interface actually
> > download
> > > > a debug event handler? If it does, then my conclusions are wrong and
I
> > have
> > > > to look elsewhere for why things in single step are not progressing,
but
> > if
> > > > I'm right, then perhaps I need a more sophisticated debugger for my
JTAG
> > > > interface (the OCD Commander is free). Any recommendations
> > >
> > > Why do you think this is wrong?  When you reset the board, single
> > > stepping (via hardware which is very different that what you describe
in
> > > item "c" above), you should execute the "reset handler" an instruction
> > > at a time.  This is just what is supposed to happen.
> > >
> > > >
> > > > Other clarifications:
> > > > 1) One thing that was not very clear in XScale little endian vs big
> > endian
> > > > modes was the opcode fetch modes for the XScale. After
investigating, my
> > > > understanding is that whether in big endian or in little endian
mode,
> > > > XScale opcode fetches are always in little endian mode. Which is why
> > when
> > > > you build a big endian target for the XScale IXP425 board which
> > generates
> > > > the instructions in big endian mode, you need to byte swap the
image. Is
> > > > this correct?
> > > >
> > > > Thanks for any input.
> > > >
> > > > Krishna
> > > -- 
> > > Gary Thomas <gary@mlbassoc.com>
> > > MLB Associates
> > >
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
>
> -- 
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss