[U-Boot-Users] [PATCH] Fixed reset for syscon3
From: Sergei Poselenov sposelenov@emcraft.com
Signed-off-by: Sergei Poselenov sposelenov@emcraft.com --- cpu/mpc85xx/cpu.c | 23 ++++++++++++++--------- 1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c index 74b210c..9873383 100644 --- a/cpu/mpc85xx/cpu.c +++ b/cpu/mpc85xx/cpu.c @@ -174,28 +174,33 @@ int do_reset (cmd_tbl_t *cmdtp, bd_t *bd, int flag, int argc, char *argv[]) { uint pvr; uint ver; + unsigned long val, msr; + pvr = get_pvr(); ver = PVR_VER(pvr); + if (ver & 1){ /* e500 v2 core has reset control register */ volatile unsigned int * rstcr; rstcr = (volatile unsigned int *)(CFG_IMMR + 0xE00B0); *rstcr = 0x2; /* HRESET_REQ */ - }else{ + udelay(100); + } + /* + * Fallthrough if the code above failed * Initiate hard reset in debug control register DBCR0 * Make sure MSR[DE] = 1 */ - unsigned long val, msr;
- msr = mfmsr (); - msr |= MSR_DE; - mtmsr (msr); + msr = mfmsr (); + msr |= MSR_DE; + mtmsr (msr); + + val = mfspr(DBCR0); + val |= 0x70000000; + mtspr(DBCR0,val);
- val = mfspr(DBCR0); - val |= 0x70000000; - mtspr(DBCR0,val); - } return 1; }
Hi Andy,
could you please have a look at this patch?
The situation is that we don't understand why it's necessary - we have verified that the correct register (RSTCR at IMMR+0xe00b0) is updated with the correct value (0x2), but this doesn't cause a reset. Documentation states that no other prerequisites or conditions are required for hard reset to work.
We have the same problem in Linux, too.
This is on a custom MPC8548 board...
Any ideas what might be causing such behaviour and/or how to avoid this?
Thanks in advance.
Best regards,
Wolfgang Denk
Wolfgang,
I don't think this patch is necessary because for all e500v2 core, setting RSTCR is the right way to reset the board.
I think you should check board FPGA. I met the similar problem before. Since FPGA did not correctly route the HRESET_REQ signal, setting RSTCR did not cause reset. After hardware person fixed the FPGA code, it worked fine.
Haiying
On Fri, 2008-05-09 at 17:51 +0200, Wolfgang Denk wrote:
Hi Andy,
could you please have a look at this patch?
The situation is that we don't understand why it's necessary - we have verified that the correct register (RSTCR at IMMR+0xe00b0) is updated with the correct value (0x2), but this doesn't cause a reset. Documentation states that no other prerequisites or conditions are required for hard reset to work.
We have the same problem in Linux, too.
This is on a custom MPC8548 board...
Any ideas what might be causing such behaviour and/or how to avoid this?
Thanks in advance.
Best regards,
Wolfgang Denk
In message 1210354701.2948.14.camel@r54964-12.am.freescale.net you wrote:
I don't think this patch is necessary because for all e500v2 core, setting RSTCR is the right way to reset the board.
Agreed,t hat's how it should wor. But it doesn't on the syscon3 board.
I think you should check board FPGA. I met the similar problem before. Since FPGA did not correctly route the HRESET_REQ signal, setting RSTCR did not cause reset. After hardware person fixed the FPGA code, it worked fine.
Ummm... This is on a custom design, the syscon3 board. There is no FPGA there...
Best regards,
Wolfgang Denk
On Fri, 2008-05-09 at 19:43 +0200, Wolfgang Denk wrote:
In message 1210354701.2948.14.camel@r54964-12.am.freescale.net you wrote:
I don't think this patch is necessary because for all e500v2 core, setting RSTCR is the right way to reset the board.
Agreed,t hat's how it should wor. But it doesn't on the syscon3 board.
I think you should check board FPGA. I met the similar problem before. Since FPGA did not correctly route the HRESET_REQ signal, setting RSTCR did not cause reset. After hardware person fixed the FPGA code, it worked fine.
Ummm... This is on a custom design, the syscon3 board. There is no FPGA there...
There must be some mechanism to reset the board if the HRESET_REQ is connected. If not connected, the board design must accomplish it in another way. Then the platform code should take care of that.
York
In message 1210361475.20678.14.camel@laptop you wrote:
There must be some mechanism to reset the board if the HRESET_REQ is connected. If not connected, the board design must accomplish it in another way. Then the platform code should take care of that.
Thanks a lot.
I see only a 1k pull-up in the schematics, nothing else.
Best regards,
Wolfgang Denk
I have a customized MPC8548 board with several hardware reset source (to HRESET AG17), and the trigger signal is a GPIO pin instead of the default HRESET_REQ (AG16). the patch simply replaces the HRESET_REQ by the certain pin of GUR registers on both cpu/mpc85xx/cpu.c of the u-boot and arch/powerpc/platforms/85xx/misc.c of the linux.
For your reference. BRs
HarryCheng
wd wrote:
In message 1210361475.20678.14.camel@laptop you wrote:
There must be some mechanism to reset the board if the HRESET_REQ is connected. If not connected, the board design must accomplish it in another way. Then the platform code should take care of that.
Thanks a lot.
I see only a 1k pull-up in the schematics, nothing else.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "The number of Unix installations has grown to 10, with more expected." - The Unix Programmer's Manual, 2nd Edition, June, 1972
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
participants (4)
-
Haiying Wang -
HarryCheng -
Wolfgang Denk -
York Sun