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