* [U-Boot-Users] Debugging u-boot with BDI2000
[not found] <200307211005.32005.jbeisert@eurodsn.de>
@ 2003-07-21 8:36 ` Wolfgang Denk
2003-07-21 9:36 ` Juergen Beisert
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2003-07-21 8:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] Debugging u-boot with BDI2000
2003-07-21 8:36 ` [U-Boot-Users] Debugging u-boot with BDI2000 Wolfgang Denk
@ 2003-07-21 9:36 ` Juergen Beisert
2003-07-21 16:35 ` [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board "XOL"
0 siblings, 1 reply; 6+ messages in thread
From: Juergen Beisert @ 2003-07-21 9:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board
2003-07-21 9:36 ` Juergen Beisert
@ 2003-07-21 16:35 ` "XOL"
2003-07-21 17:25 ` Wolfgang Denk
0 siblings, 1 reply; 6+ messages in thread
From: "XOL" @ 2003-07-21 16:35 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board
2003-07-21 16:35 ` [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board "XOL"
@ 2003-07-21 17:25 ` Wolfgang Denk
2003-07-22 8:41 ` "XOL"
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Denk @ 2003-07-21 17:25 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board
2003-07-21 17:25 ` Wolfgang Denk
@ 2003-07-22 8:41 ` "XOL"
2003-07-22 9:09 ` Wolfgang Denk
0 siblings, 1 reply; 6+ messages in thread
From: "XOL" @ 2003-07-22 8:41 UTC (permalink / raw)
To: u-boot
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board
2003-07-22 8:41 ` "XOL"
@ 2003-07-22 9:09 ` Wolfgang Denk
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Denk @ 2003-07-22 9:09 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-07-22 9:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200307211005.32005.jbeisert@eurodsn.de>
2003-07-21 8:36 ` [U-Boot-Users] Debugging u-boot with BDI2000 Wolfgang Denk
2003-07-21 9:36 ` Juergen Beisert
2003-07-21 16:35 ` [U-Boot-Users] u-boot for EmbeddedPlanet EP862 board "XOL"
2003-07-21 17:25 ` Wolfgang Denk
2003-07-22 8:41 ` "XOL"
2003-07-22 9:09 ` Wolfgang Denk
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.