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