Re: [U-Boot-Users] u-boot hangs in ./cpu/mpc8xx/cpu_init.c when changing br0

SOLUTION (or at least an explanation, and it has nothing to do with the longish comment in this source file)
Form the MPC866 data sheet: "When the MPC866 internal core begins accessing memory at system reset, CS0 is asserted for every address, unless an internal register is accessed...CS0 operates this way until the first write to OR0 and it can be used as any other chip-select register once the preferred address range is loaded into BR0."
All of this is already loaded by the BDI debugger, so that is what is throwing off the processor. OR0 already has an address range set, so when BR0's address mask is changed, the program gets "lost" because the next instruction cannot be found. Of course, the instruction cache has already been enabled, so the lost instruction is not an issue until a few lines later.
Proposed solution: Before clearing BR0, include the following:
#ifdef DEBUG [temp] = [OR0] [temp] |= 0x0000ffff [OR0] = [temp] #endif
The next e-mail will be a patch
-JM
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Wednesday, June 21, 2006 4:57 PM To: Jeff Mann Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] u-boot hangs in ./cpu/mpc8xx/cpu_init.c when changing br0
In message 1628E43D99629C46988BE46087A3FBB95C58A9@ep-01.EmbeddedPlanet.local you wrote:
But back to the problem.
./cpu/mpc8xx/cpu_init.c
There is a longish commet in this source file, lines 127...149.
r28 holds the value 0xfa200100 (the location of br0) At line 118, br0 is loaded into r0. r0 then holds 0xfc000001. At line 119, r0 becomes 0x00000000. <<-- This is the problem, I think At line 120, r0 becomes 0x00000001 At line 121, r0 is saved to br0 (the address pointed to by r28). (br0 becomes 0x00000001)
The C comment says: "Clear everything except Port Size bits, then add just the "Bank Valid" bit". Looks as if exactly this was happening. What's the problem?
The program fails at ln 180 with: "Program received signal SIGABRT, aborted." But by this time, br0 was reloaded with CFG_BR0_PRELIM from line 176.
Any more ideas?
Misconfiguration?
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Tuesday, June 20, 2006 5:53 PM To: Jeff Mann Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] u-boot hangs in ./cpu/mpc8xx/cpu_init.c when changing br0
Please don't top post / full quote. Read http://www.netmeister.org/news/learn2quote.html
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "Gravitation cannot be held responsible for people falling in love." - Albert Einstein

In message 1628E43D99629C46988BE46087A3FBB95C59D2@ep-01.EmbeddedPlanet.local you wrote:
SOLUTION (or at least an explanation, and it has nothing to do with the longish comment in this source file)
Oh yes, it has.
Form the MPC866 data sheet: "When the MPC866 internal core begins accessing memory at system reset, CS0 is asserted for every address, unless an internal register is accessed...CS0 operates this way until the first write to OR0 and it can be used as any other chip-select register once the preferred address range is loaded into BR0."
Standard MPC8xx init sequence, that is.
All of this is already loaded by the BDI debugger, so that is what is
Argh. Why are you doing this? I've been preaching for ages that your BDI config file should be basicly EMPTY, i. e. just contain the unavoidable stuff like disabling the watchdog. But it MUST NOT touch the memory controller. U-Boot expects a VIRGIN CPU frosh out of reset.
If you mess with it you get what you deserve.
Proposed solution: Before clearing BR0, include the following:
Wrong. Solution is: DON'T MESS THE CPU STATE before passing control to U-Boot.
The next e-mail will be a patch
It will be rejected.
Best regards,
Wolfgang Denk
participants (2)
-
Jeff Mann
-
Wolfgang Denk