[U-Boot-Users] MPC8360E & Large DDR Capacities

[U-Boot-Users] MPC8360E & Large DDR Capacities

[Russell McGuire]

All

After digging around it would seem that U-boot is resetting after the first
direct access to DDR memory. I placed a number of statements and installed a
'memory test' function. 

I think the DDR init is failing due to the udelay(200) function early in the
MPC8360E-MDS board files. The delay does not seem to be operational, so I
'think' the DDR gets enabled before the specked 200us delay that the MPC8360
manual requires.

Anyone have any ideas what might cause the udelay function to not 'delay' as
advertised. <My core clock is setup@533 Mhz, but 200us should be will
within the non-overflow capability>.

-Russ 
-----Original Message-----
From: Timur Tabi [mailto:timur at freescale.com] 
Sent: Monday, December 18, 2006 7:53 AM
To: rmcguire at videopresence.com
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] MPC8360E & Large DDR Capacities

Russell McGuire wrote:
> Does anybody know if there are any issues with using DDR capacities above
> 256MB? I am attempting to use a 512MB DIMM at the moment, and am not sure
if
> I am getting a SDRAM init issue that is causing U-boot to continuously
> reset, 

It would be very helpful if you could narrow down the exact line of code
that is 
causing the reset.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] MPC8360E & Large DDR Capacities

[Timur Tabi]

Russell McGuire wrote:

> I think the DDR init is failing due to the udelay(200) function early in the
> MPC8360E-MDS board files. The delay does not seem to be operational, so I
> 'think' the DDR gets enabled before the specked 200us delay that the MPC8360
> manual requires.

Have you tried creating your own delay function that waits several seconds, just 
to be sure?  A for-loop would do.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] MPC8360E & Large DDR Capacities

[Russell McGuire]

All,

I found the first error.

The MPC8360EMDS.c file is missing a single write during the startup
sequence. This is also an error in the MPC8360E family manual I found about
2 weeks ago, though I notified Freescale, nobody has issued a revised manual
yet.

The DDR_SDRAM_CLK_CNTL register is missing two bit fields in the manual,
though it's the same as the MPC8349E so one can read the 8349E manual to get
the right info, see 9.4.1.14 in the MPC8360E for the bad info.

Anyway added the following line to the MPC8360EMDS board and now DDR will
initialize. 

ADD:

im->ddr.sdram_clk_cntl = 0x83000000;

Note the '8' is the undocumented bit. SS_EN I think is the name.

Anyway, now I can get up to the 'relocate_code' call. So we'll see if the
DDR is stable enough for full speed execution.

Russell McGuire
Systems Engineer
VideoPresence, Inc.
rmcguire at videopresence.com
503.888.0968 

-----Original Message-----
From: Timur Tabi [mailto:timur at freescale.com] 
Sent: Monday, December 18, 2006 3:32 PM
To: rmcguire at videopresence.com
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] MPC8360E & Large DDR Capacities

Russell McGuire wrote:

> I think the DDR init is failing due to the udelay(200) function early in
the
> MPC8360E-MDS board files. The delay does not seem to be operational, so I
> 'think' the DDR gets enabled before the specked 200us delay that the
MPC8360
> manual requires.

Have you tried creating your own delay function that waits several seconds,
just 
to be sure?  A for-loop would do.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] MPC8360E & Large DDR Capacities

[Russell McGuire]

Does anybody know if there are any issues with using DDR capacities above
256MB? I am attempting to use a 512MB DIMM at the moment, and am not sure if
I am getting a SDRAM init issue that is causing U-boot to continuously
reset, <Yes I have read the U-boot FAQ on this>, or whether I have hosed
over the BAT setup trying to cache all 512MB.

I see in the code there is a single CONFIG_VERY_BIG_RAM setting, and in the
board.c file that 'may' effect the position of the final stack location.

As well I have a question regarding a MAXIMUM supportable RAM by U-boot.
I.e. could it go as high as 2 GB? And if so, what would the BAT settings
look like. I am assuming that each bat on the E300 core can only map 256MB,
so would it require all 8 BATS just to map the DDR? Or can the BATS just be
enabled for the lower portions, or is there some nifty way to link them to
span higher ranges than 256MB?

As well I have mapped the DDRLAW0 to span a single 512MB range.
Each CS0 and CS1 is mapped to handle 256MB.

See my current BATS below:

My Laws are using 
/* DDR: cache cacheable, first 256MB, should be 0x0000_0000 to 0x0FFF_FFFF*/
#define CFG_IBAT0L	(CFG_DDR_SDRAM_BASE | BATL_PP_10 |
BATL_MEMCOHERENCE)
#define CFG_IBAT0U	(CFG_DDR_SDRAM_BASE | BATU_BL_256M | BATU_VS |
BATU_VP)
#define CFG_DBAT0L	CFG_IBAT0L
#define CFG_DBAT0U	CFG_IBAT0U

/* DDR: cache cacheable, second 256MB, should be 0x1000_0000 to
0x1FFF_FFFF*/
#define CFG_IBAT1L	((CFG_DDR_SDRAM_BASE+0x10000000) | BATL_PP_10 |
BATL_MEMCOHERENCE)
#define CFG_IBAT1U	((CFG_DDR_SDRAM_BASE+0x10000000) | BATU_BL_256M |
BATU_VS | BATU_VP)
#define CFG_DBAT1L	CFG_IBAT1L
#define CFG_DBAT1U	CFG_IBAT1U


-Russ

[U-Boot-Users] MPC8360E & Large DDR Capacities

[Timur Tabi]

Russell McGuire wrote:
> Does anybody know if there are any issues with using DDR capacities above
> 256MB? I am attempting to use a 512MB DIMM at the moment, and am not sure if
> I am getting a SDRAM init issue that is causing U-boot to continuously
> reset, 

It would be very helpful if you could narrow down the exact line of code that is 
causing the reset.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale