[U-Boot-Users] U-boot reset command on MPC8548CDS

[U-Boot-Users] U-boot reset command on MPC8548CDS

[Thomas Schafer]

Hi,

I have u-boot 1.1.6 running on my MPC8548CDS board. When trying the
u-boot 'reset' command, the board hangs after RAM initialization.
Stepping through the code showed, that the board hangs when accessing
the DDR RAM during relocation. Accessing RAM isn't also possible with my
BDI2000 in that state.

Is this a known issue? Why is the RAM not longer accessible after the
2nd initialization?

Best regards,

Thomas Schafer

____________________________________

Kontron Modular Computers GmbH

Heinrich-Barth-Str. 1a
66115 Saarbrucken

Tel.: + 49 (0)681 / 95916 - 203
Fax:  + 49 (0)681 / 95916 - 100
E-mail: thomas.schaefer at kontron.com 

[U-Boot-Users] U-boot reset command on MPC8548CDS

[Timur Tabi]

Thomas Schafer wrote:
> Hi,
> 
> I have u-boot 1.1.6 running on my MPC8548CDS board. When trying the
> u-boot 'reset' command, the board hangs after RAM initialization.
> Stepping through the code showed, that the board hangs when accessing
> the DDR RAM during relocation. Accessing RAM isn't also possible with my
> BDI2000 in that state.
> 
> Is this a known issue? Why is the RAM not longer accessible after the
> 2nd initialization?

Does this happen with earlier versions of U-Boot?  The reason I ask is that 
the I2C code for 85xx was recently changed (see fsl_i2c.c), and I2C is used to 
initialize DDR.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] U-boot reset command on MPC8548CDS

[Dan Malek]

On Nov 15, 2006, at 12:14 PM, Thomas Schafer wrote:

> Is this a known issue? Why is the RAM not longer accessible after the
> 2nd initialization?

The software 'reset' in u-boot only causes the
e500 core to reset, none of the peripherals nor
memory controllers.  Whacking the DDR setup
again in this state just makes a big mess.

The only proper way to do this is with a board
design where you can drive the external reset
out of the processor, with external hardware that
will then "loop" this back as a hard reset.  See
HRESET_REQ in the RSTCR.  It's a simple patch
that I guess I could submit :-)  Not all board
designs support this, though.

Thanks.

	-- Dan

[U-Boot-Users] U-boot reset command on MPC8548CDS

[Thomas Schäfer]

Hi Dan,

> > Is this a known issue? Why is the RAM not longer accessible 
> after the 
> > 2nd initialization?
> 
> The software 'reset' in u-boot only causes the e500 core to 
> reset, none of the peripherals nor memory controllers.  
> Whacking the DDR setup again in this state just makes a big mess.
> 
> The only proper way to do this is with a board design where 
> you can drive the external reset out of the processor, with 
> external hardware that will then "loop" this back as a hard 
> reset.  See HRESET_REQ in the RSTCR.  It's a simple patch 
> that I guess I could submit :-)  Not all board designs 
> support this, though.
> 

Thank you for your help. The MPC8548CDS actually provides this loop with the HRESET_REQ signal of the CPU. Thus I got the reset command working by setting that bit in the RSTCR. The patch against u-boot 1.1.6 is added below:

diff -NurbB u-boot-1.1.6/cpu/mpc85xx/cpu.c u-boot-1.1.6-work/cpu/mpc85xx/cpu.c
--- u-boot-1.1.6/cpu/mpc85xx/cpu.c	2006-11-02 15:15:01.000000000 +0100
+++ u-boot-1.1.6-work/cpu/mpc85xx/cpu.c	2006-11-16 18:02:13.000000000 +0100
@@ -141,15 +141,24 @@
 int do_reset (cmd_tbl_t *cmdtp, bd_t *bd, int flag, int argc, char *argv[])
 {
 	/*
-	 * Initiate hard reset in debug control register DBCR0
-	 * Make sure MSR[DE] = 1
+	 * Set HRESET_REQ in Reset Control Register thereby
+	 * requesting a HRESET
 	 */
 	unsigned long val;
+	volatile immap_t *immap = (immap_t *)CFG_CCSRBAR;
+	volatile ccsr_gur_t *gur = &immap->im_gur;
 
+	gur->rstcr = 0x00000002;
+	while (1);
+	/*
+	 * Initiate hard reset in debug control register DBCR0
+	 * Make sure MSR[DE] = 1
+	 */
+/*
 	val = mfspr(DBCR0);
 	val |= 0x70000000;
 	mtspr(DBCR0,val);
-
+*/
 	return 1;
 }
 
diff -NurbB u-boot-1.1.6/include/asm-ppc/immap_85xx.h u-boot-1.1.6-work/include/asm-ppc/immap_85xx.h
--- u-boot-1.1.6/include/asm-ppc/immap_85xx.h	2006-11-02 15:15:01.000000000 +0100
+++ u-boot-1.1.6-work/include/asm-ppc/immap_85xx.h	2006-11-16 12:08:35.000000000 +0100
@@ -1548,7 +1548,9 @@
 	char	res9[12];
 	uint	pvr;		/* 0xe00a0 - Processor version register */
 	uint	svr;		/* 0xe00a4 - System version register */
-	char	res10[3416];
+	char	res9a[8];
+	uint	rstcr;		/* 0xe00b0 - Reset control register */
+	char	res10[3404];
 	uint	clkocr;		/* 0xe0e00 - Clock out select register */
 	char	res11[12];
 	uint	ddrdllcr;	/* 0xe0e10 - DDR DLL control register */



Should this be included into the public tree? This only works, if the system performs a HRESET when HRESET_REQ has been set. On the other hand, what would be the sense of a reset command that hangs after the following RAM initialization? Or is there other behaviour with different 85xx CPUs?

Best regards,

Thomas Sch?fer

[U-Boot-Users] U-boot reset command on MPC8548CDS

[Kim Phillips]

On Thu, 16 Nov 2006 19:22:22 +0100
Thomas Sch?fer <thomas.schaefer@kontron.com> wrote:

> Thank you for your help. The MPC8548CDS actually provides this loop with the HRESET_REQ signal of the CPU. Thus I got the reset command working by setting that bit in the RSTCR. The patch against u-boot 1.1.6 is added below:

I posted a "Fixed MPC8548CDS post-reset freeze" patch on behalf of Dai Haruki soon after your query post (that way it could be easily applied).  It does the same thing yours does, but also for the 8543.

Kim