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

[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

[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] u-boot for EmbeddedPlanet EP862 board

["XOL"]

Hello.
I'm trying to run u-boot on EmbeddedPlanet EP862 board.
I based on RPXClassic configuration and made some changes. 
For a while without success. The u-boot stuck without any output.

The problem could be because of the way I try to run it.
My board has 16MB flash at 
FF00_0000 - FFFF_FFFF
The original EP bootloader is burned at
FF00_0000 - FF08_FFFF
I do not want to erase it and put u-boot instead untill I'm sure
it will work. Otherwise I can loose a board because I have no
BDM to burn it externally. 
So I put u-boot at FF80_0000
After board power up it runs EP bootloader which has
interractive commands shell.
I issue 
go FF80_0000 
to make it branch to specifyed address and thus run u-boot.
At this point the system stuck.
While configuring u-boot I updated FLASH definitions to 
FF80_0000 address.
My question is if this approach can work?
What can be a problem of stuck. Does it metter to u-boot
to run on board after power up or reset or to run on already 
configured board.
What about epprom and nvram usage. EP boot loader use them for itself
can this false u-boot and stuck him?
Maybe anyone has configuration for EP862 board. 

Thank you in advance.
Xol.

[U-Boot-Users] u-boot for EmbeddedPlanet EP862 board

[Wolfgang Denk]

In message <E19edct-0004wX-00.xol-mail-ru@f15.mail.ru> you wrote:
> 
> The problem could be because of the way I try to run it.

Probably.

> The original EP bootloader is burned at
> FF00_0000 - FF08_FFFF
> I do not want to erase it and put u-boot instead untill I'm sure
> it will work. Otherwise I can loose a board because I have no

This cannot be done. To make U-Boot runnable by some other bootloader
you will have to modify U-Boot. For example, you will have to disable
the code which is responsible for initialization of the  SRDAM.  This
is  very  sensible  code,  which  makes  for  some 99% of all trouble
reports on this list. Now when you think everything is working  fine,
you will have to enable this code, and use it - completely untested.

> BDM to burn it externally. 

Get yourself a BDI2000, or at least a BDM4GDB adapter.

> My question is if this approach can work?

It will NOT save you any effort, and it will NOT save you any risk.
In other words: use wasted effort.

> What can be a problem of stuck. Does it metter to u-boot
> to run on board after power up or reset or to run on already 
> configured board.

Yes, this matters. U-Boot expects and requires a "virgin" CPU,  fresh
out of reset.


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
Harrison's Postulate:
	For every action, there is an equal and opposite criticism.

[U-Boot-Users] u-boot for EmbeddedPlanet EP862 board

["XOL"]

Ok.
I see this is really waste of time.
Now I got another idea. I still burn u-boot
at 0xFF80_0000
and I need to force PPC reset system think that I have
8Mbyte of Flash and not 16Mbyte. This will cause to
run bootloader from 0xFF80_0000 and not 0xFF00_0000.
In this way I could switch between this two options. 
The question is how to control it. 
I'm going to read about reset on PPC and as far as I remember 
this should be somewhere in strapping options.
What do you think about?
Thanks.

-----Original Message-----
From: Wolfgang Denk <wd@denx.de>
To: "XOL"  <xol@mail.ru>
Date: Mon, 21 Jul 2003 19:25:31 +0200
Subject: Re: [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board 

> 
> In message <E19edct-0004wX-00.xol-mail-ru@f15.mail.ru> you wrote:
> > 
> > The problem could be because of the way I try to run it.
> 
> Probably.
> 
> > The original EP bootloader is burned at
> > FF00_0000 - FF08_FFFF
> > I do not want to erase it and put u-boot instead untill I'm sure
> > it will work. Otherwise I can loose a board because I have no
> 
> This cannot be done. To make U-Boot runnable by some other bootloader
> you will have to modify U-Boot. For example, you will have to disable
> the code which is responsible for initialization of the  SRDAM.  This
> is  very  sensible  code,  which  makes  for  some 99% of all trouble
> reports on this list. Now when you think everything is working  fine,
> you will have to enable this code, and use it - completely untested.
> 
> > BDM to burn it externally. 
> 
> Get yourself a BDI2000, or at least a BDM4GDB adapter.
> 
> > My question is if this approach can work?
> 
> It will NOT save you any effort, and it will NOT save you any risk.
> In other words: use wasted effort.
> 
> > What can be a problem of stuck. Does it metter to u-boot
> > to run on board after power up or reset or to run on already 
> > configured board.
> 
> Yes, this matters. U-Boot expects and requires a "virgin" CPU,  fresh
> out of reset.
> 
> 
> 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
> Harrison's Postulate:
> 	For every action, there is an equal and opposite criticism.
> 

[U-Boot-Users] u-boot for EmbeddedPlanet EP862 board

[Wolfgang Denk]

In message <E19esiV-000Fro-00.xol-mail-ru@f23.mail.ru> you wrote:
>
> and I need to force PPC reset system think that I have
> 8Mbyte of Flash and not 16Mbyte. This will cause to
> run bootloader from 0xFF80_0000 and not 0xFF00_0000.

The PPC does not "think". It does  not  care  at  all  how  big  your
flashes  are.  The  MPC8xx just jumps to one of two fixed reset entry
points (0x100 or 0xFFF00100) - which one gets selected by the HRCW.

> The question is how to control it. 

HRCW.

> I'm going to read about reset on PPC and as far as I remember 
> this should be somewhere in strapping options.
> What do you think about?

I still think it would be much more  straightforward  to  use  a  BDM
debugger.  With  the time used so far you could have easily assembled
your own BDM4GDB.


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
Real computer scientists despise the idea of actual  hardware.  Hard-
ware has limitations, software doesn't. It's a real shame that Turing
machines are so poor at I/O.

[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

[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

[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

[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]

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

[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