[U-Boot-Users] Debugging u-boot with BDI2000

[U-Boot-Users] Debugging u-boot with BDI2000

[Juergen Beisert]

Hello Wolfgang,

>>I'm trying to debug my u-boot with BDI. It's a 405GP based system.
>> In the telnet sessoin I can insert "reset run" and u-boot starts. When I
>> enter "reset halt" and then "go" it won't do anything. I have tried with
>> ddd
>
>What do you mean with "it won't do anything"? Who won't do  anything?
>The  BDI2000?  The  CPU?  What  makes  you  think the CPU does not do
>anything?

At first I thought the 405GP cpu does not start. On my card is a LED display, 
so I can output some numbers very early in the startup process. With "reset 
halt", "go" the display never change its contents, with "reset run" it does.

>Are you sure your BDI2000 config file is OK for your board?

Good question. What should happen, to be shure? I have debugged a running 
Linux kernel with this configuration. So I think(!) the major settings are 
ok.

>  How  did you  configure  "RESET  type"  and  "STARTUP  mode"?  Is  your
> "START address" ok?

RESET is not set, defaults to "SYSTEM"
STARTUP is set to RESET
START is set to 0x0000'0000 (readed from a default file)

With "reset halt", "info" I see the CPU waiting at address 0xFFFF'FFFC, after 
one single step ("ti") it waits at address 0xFFFF'C0100. Seems ok.

>> When I step the mtmsr instruction ddd shows address 0x700, and the esr
>> register has 0x8800'0000 (illegal instruction occured?????).
>> Same when I place a breakpoint behind the mtmsr instruction und use "cont"
>> instead of "stepi".
>
>You  are  aware  that  you  cannot  single   step   through   certain
>instructions, aren't you?

If the mtmsr instruction is not "single step able", it should run, if I place 
a breakpoint behind this instruction (for example later in the C routines) 
and use "go" to run up the breakpoint. Or not?

>> What is the difference between "reset run" and "reset halt", "go"?

>"reset run" and "reset halt" change the startup  mode  to  "run"  and
>"halt",  respectively. "go" sets the PC and starts the target system.
>Ummm.. is there any specific part where the BDI2000 manual is unclear
>about this?

Perhaps my english is very bad. Question was: Why the cpu is running normal 
with "reset run", and did not run, when I enter "reset halt", enter a 
breakpoint and than "go" (it never reaches the breakpoint).

-- JB

[U-Boot-Users] Debugging u-boot with BDI2000

[Wolfgang Denk]

Hi,

in message <200307181321.29058.jbeisert@eurodsn.de> you wrote:
> 
> With "reset halt", "info" I see the CPU waiting at address 0xFFFF'FFFC, after 
> one single step ("ti") it waits at address 0xFFFF'C0100. Seems ok.

Indeed, this looks OK.

BTW: plain "reset" is all you need. You don't have to specify  a  new
mode if you don't want to change it.

> If the mtmsr instruction is not "single step able", it should run, if I place 
> a breakpoint behind this instruction (for example later in the C routines) 
> and use "go" to run up the breakpoint. Or not?

Maybe. If you're using hardware breakpoints, for example.

> Perhaps my english is very bad. Question was: Why the cpu is running normal 
> with "reset run", and did not run, when I enter "reset halt", enter a 
> breakpoint and than "go" (it never reaches the breakpoint).

Which address is PC pointing to when you enter "go"?

You may want to ask Abatron support  for  details  about  the  exactl
meaning of these options. My interpretation is that "reset run" means
the  same  as  a  reset  in  startup  mode  run,  while  "reset halt"
equivalents to a reset in startup mode stop.  I  never  used  any  of
these.

Why don't you use plain "reset" ? [Did you try it?]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"If anything can go wrong, it will."                   - Edsel Murphy

[U-Boot-Users] Debugging u-boot with BDI2000

[Juergen Beisert]

I have wrote
> With "reset halt", "info" I see the CPU waiting at address 0xFFFF'FFFC,
> after one single step ("ti") it waits at address 0xFFFF'C0100. Seems ok.

Uuups. One 'F' to much. The cpu waits at 0xFFFC'0100 after the first step. 

-- JB

[U-Boot-Users] Debugging u-boot with BDI2000

[Juergen Beisert]

Am Freitag, 18. Juli 2003 14:05 schrieb Wolfgang Denk:
> > If the mtmsr instruction is not "single step able", it should run, if I
> > place a breakpoint behind this instruction (for example later in the C
> > routines) and use "go" to run up the breakpoint. Or not?
>
> Maybe. If you're using hardware breakpoints, for example.

I did use hardware breakpoints.

> > Perhaps my english is very bad. Question was: Why the cpu is running
> > normal with "reset run", and did not run, when I enter "reset halt",
> > enter a breakpoint and than "go" (it never reaches the breakpoint).
>
> Which address is PC pointing to when you enter "go"?

0x700. It wants to handle an exeption (but at this point, there is no code 
present). So it hangs forever.

> You may want to ask Abatron support  for  details  about  the  exactl
> meaning of these options. My interpretation is that "reset run" means
> the  same  as  a  reset  in  startup  mode  run,  while  "reset halt"
> equivalents to a reset in startup mode stop.  I  never  used  any  of
> these.
>
> Why don't you use plain "reset" ? [Did you try it?]

My u-boot implementation hangs at a very late position. So I have to place a 
breakpoint before the point it hangs (to see what happens before the hang). 
But with "reset run" the breakpoint is lost....And with "reset halt", setting 
a breakpoint and "go" it hangs after a few instructions...Aaargh.

Thanks for your answers

-- JB

[U-Boot-Users] Debugging u-boot with BDI2000

[Wolfgang Denk]

Dear J?rgen,

in message <200307181428.20714.jbeisert@eurodsn.de> you wrote:
>
> I did use hardware breakpoints.

OK.

> > > Perhaps my english is very bad. Question was: Why the cpu is running
> > > normal with "reset run", and did not run, when I enter "reset halt",
> > > enter a breakpoint and than "go" (it never reaches the breakpoint).
> >
> > Which address is PC pointing to when you enter "go"?
> 
> 0x700. It wants to handle an exeption (but at this point, there is no code 
> present). So it hangs forever.

It will do you little good to try "go" when PC points to 0x700.

> > Why don't you use plain "reset" ? [Did you try it?]
> 
> My u-boot implementation hangs at a very late position. So I have to place a 

Sorry, but this statement makes no sense.

After a "reset", the BDI is expected to stop the  CPU  right  at  the
reset entry point, i. e. PC should point to 0xFFFFFFFC or so.

Not a single instruction of U-Boot code should be  executed  after  a
reset.

> But with "reset run" the breakpoint is lost....And with "reset halt", setting 
> a breakpoint and "go" it hangs after a few instructions...Aaargh.

Let me repeat my question:

Why don't you use plain "reset" ? [Did you try it?]

Did you make sure thet the CPUi s stopped when you attempt to set the
breakpoint? (issue a "halt" command before setting the BP).


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"What if" is a trademark of Hewlett Packard, so stop using it in your
sentences without permission, or risk being sued.

[U-Boot-Users] Debugging U-Boot with BDI2000

[Robert Schwebel]

On Thu, Sep 11, 2003 at 12:11:58PM +0200, Glenson Muthedan wrote:
> I'm quite new to U-Boot and trying to get started with the
> Bootloader-Stuff for some weeks now. My Board is similar to Accelent
> IDP or CSB226(PXA250 with 32 MB Strataflash and 32 MB SDRAM).

Did you try using U-Boot + one of my -ptx patches? Should work better on
PXA than vanilla because of the memory layout problems. 

> U-Boot seems to crash on my board before it can output something through
> the serial line. So I wanted step through U-Boot right from the very
> first instruction using BDI2000 while booting. The problem is that the
> information the bdi user manual gives, is quite confusing. I tried out
> various configurations for BDI2000, but really don't know what to do
> with the vector table in the "Mini IC" and the debug handler stuff.

I currently use this one: 

[TARGET]
CPUTYPE         PXA250          ; the target CPU type
JTAGCLOCK       1               ; use 8 MHz JTAG clock
DBGHANDLER      0xFE000800      ; 
ENDIAN          LITTLE          ; memory model (LITTLE | BIG)
BREAKMODE       HARD            ; SOFT or HARD; HARD does only allow two
                                ; breakpoints, but does work on flash
;VECTOR         CATCH 0xDE      ; trap all vectors
;VTABLO         0xE59FF014      ; Use fixed vectors "ldr pc, [pc, #14]"

> The situation now is as following: The target is in debug mode right
> from the start and the PC is pointing to 0xffff0004. "go" or "ti"
> doesn't work because of access to an invalid memory address. (My
> configuration file now contains a blank [INIT] section and no vector
> table/debug handler stuff in the [TARGET] part)

I started with the Lubbock config which came with the BDI and it worked
quite fine. 

> 1) Is it possible to debug U-Boot with BDI2000 (Linux host) at all?
> (eg. step through the instructions)

Yes, works perfectly. 

> 2) Do somebody have a working configuration file for BDI2000 (Linux 
> host) to be used with a PXA250-target?

I send you my CSB config with separate mail. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Debugging U-Boot with BDI2000

[Wolfgang Denk]

In message <3F604A6E.7030308@gmx.de> you wrote:
> 
> 1) Is it possible to debug U-Boot with BDI2000 (Linux host) at all?
> (eg. step through the instructions)

Yes, of course!!!

> 2) Do somebody have a working configuration file for BDI2000 (Linux 
> host) to be used with a PXA250-target?

Configuration files for some targets are included  with  the  BDI2000
firmware  -  see  the floppy disk, or the .zip file you received with
the device.

But a configuration file for _some_ PXA250 board is only an  EXAMPLE,
you  cannot use it unchanged on different hardware. You must create a
NEW  configuration  file  which  matches  exactly  the  hardware   as
implemented on your board.

This is not a trivial task, but the knowledge you need to do this  is
necessary to successfully port and debug U-Boot anyway. 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot-Users] Debugging U-Boot with BDI2000

[Glenson Muthedan]

Hello!

I'm quite new to U-Boot and trying to get started with the
Bootloader-Stuff for some weeks now. My Board is similar to Accelent IDP
or CSB226(PXA250 with 32 MB Strataflash and 32 MB SDRAM).
U-Boot seems to crash on my board before it can output something through
the serial line. So I wanted step through U-Boot right from the very
first instruction using BDI2000 while booting. The problem is that the
information the bdi user manual gives, is quite confusing. I tried out
various configurations for BDI2000, but really don't know what to do
with the vector table in the "Mini IC" and the debug handler stuff.
The situation now is as following: The target is in debug mode right 
from the start and the PC is pointing to 0xffff0004. "go" or "ti" 
doesn't work because of access to an invalid memory address.
(My configuration file now contains a blank [INIT] section and no vector 
table/debug handler stuff in the [TARGET] part)

I'd be very thankful if someone could answer my questions:

1) Is it possible to debug U-Boot with BDI2000 (Linux host) at all?
(eg. step through the instructions)

2) Do somebody have a working configuration file for BDI2000 (Linux 
host) to be used with a PXA250-target?

Hope, you can give me at least a hint.

Regards,
Glenson Muthedan.

[U-Boot-Users] Debugging u-boot with BDI2000

[Juergen Beisert]

Hello Wolfgang,

> > Does anybody knows something about the registers OPBA0_CR and OPBA0_PR
> > (OPB Arbiter control and priority)? After reset its contents shows
> > illegal bit values (if I try to interpret the value after reset based on
> > my 405GP manual).
>
> And which CPU model is on your board?

IBM PowerPC 405GP Rev. E (rev register ID is 0x40110145).
The register descriptions of OPBA0_CR and OPBA0_PR confusing me: OPBA0_CR 
resides at MMIO location 0xEF60'0600 and OPBA0_PR at 0xEF60'0601. Both are 
described as two 32 bit registers, but only using the upper 8 bits.

I think I have to access these registers only byte wide at their locations 
0xEF60'0600 and 0xEF60'0601, or both in one 16 bit access at 0xEF60'0600. 
Right?

Best regards, 
Juergen Beisert

[U-Boot-Users] Debugging u-boot with BDI2000

[Wolfgang Denk]

Dear J?rgen,

in message <200307211005.32005.jbeisert@eurodsn.de> you wrote:
> 
> My code does some modifications in chipset registers. One of it seems the bad 
> one and the cpu hangs when executing it. While I can't trace it, I have now 
> disabled the modifications step by step and find the bad one (OPBA0_CR).
> 
> Does anybody knows something about the registers OPBA0_CR and OPBA0_PR
> (OPB Arbiter control and priority)? After reset it's contents shows illegal 
> bit values (if I try to interpret the value after reset based on my 405GP 
> manual).

And which CPU model is on your board?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Most people would like to be delivered  from  temptation  but  would
like it to keep in touch."                             - Robert Orben