public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] MPC8360E & Large DDR Capacities
       [not found] <mailman.100173.1166298011.30209.u-boot-users@lists.sourceforge.net>
@ 2006-12-16 23:17 ` Russell McGuire
  2006-12-18 15:53   ` Timur Tabi
  0 siblings, 1 reply; 5+ messages in thread
From: Russell McGuire @ 2006-12-16 23:17 UTC (permalink / raw)
  To: u-boot


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot-Users] MPC8360E & Large DDR Capacities
  2006-12-16 23:17 ` [U-Boot-Users] MPC8360E & Large DDR Capacities Russell McGuire
@ 2006-12-18 15:53   ` Timur Tabi
  0 siblings, 0 replies; 5+ messages in thread
From: Timur Tabi @ 2006-12-18 15:53 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot-Users] MPC8360E & Large DDR Capacities
       [not found] <mailman.113204.1166449236.30209.u-boot-users@lists.sourceforge.net>
@ 2006-12-18 23:26 ` Russell McGuire
  2006-12-18 23:32   ` Timur Tabi
  0 siblings, 1 reply; 5+ messages in thread
From: Russell McGuire @ 2006-12-18 23:26 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot-Users] MPC8360E & Large DDR Capacities
  2006-12-18 23:26 ` Russell McGuire
@ 2006-12-18 23:32   ` Timur Tabi
  2006-12-18 23:58     ` Russell McGuire
  0 siblings, 1 reply; 5+ messages in thread
From: Timur Tabi @ 2006-12-18 23:32 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [U-Boot-Users] MPC8360E & Large DDR Capacities
  2006-12-18 23:32   ` Timur Tabi
@ 2006-12-18 23:58     ` Russell McGuire
  0 siblings, 0 replies; 5+ messages in thread
From: Russell McGuire @ 2006-12-18 23:58 UTC (permalink / raw)
  To: u-boot

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-12-18 23:58 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <mailman.100173.1166298011.30209.u-boot-users@lists.sourceforge.net>
2006-12-16 23:17 ` [U-Boot-Users] MPC8360E & Large DDR Capacities Russell McGuire
2006-12-18 15:53   ` Timur Tabi
     [not found] <mailman.113204.1166449236.30209.u-boot-users@lists.sourceforge.net>
2006-12-18 23:26 ` Russell McGuire
2006-12-18 23:32   ` Timur Tabi
2006-12-18 23:58     ` Russell McGuire

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox