Re: [U-Boot-Users] Debugging u-boot with BDI2000
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
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
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.
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
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@denx.de Harrison's Postulate: For every action, there is an equal and opposite criticism.
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
participants (3)
-
"XOL -
Juergen Beisert -
Wolfgang Denk