[U-Boot-Users] Freescale MPC8349EMDS hang on boot

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Ira Snyder wrote:
> On Fri, Jul 18, 2008 at 07:59:36AM -0400, Jerry Van Baren wrote:
>> Hi Ira,
>>
>> This is a long shot, but could there be a problem with the DDR SDRAM  
>> and/or its initialization?
> 
> I suppose it could be, but this seems unlikely. Why would aligning the
> start of a section to a 32 byte boundary make the ram initialization fail,
> but any other alignment works?

Not the initialization itself, but an incorrect initialization can cause 
funny things to happen when the SDRAM is used.  As you note here and 
below, doesn't look like this is the problem.

The thought was that your moving memory contents around ("misaligning" 
it) causes changes to the bus cycles which make it work or not.

> Also, I have two nearly identical boards here. One is a MPC8349EMDS
> Rev-3.1 (it's an EA board, using DDR2) and another, older MPC8349EMDS
> Rev-1.1 (it's an E board, using plain DDR). Both fail in exactly the
> same way.

That is useful to know (I think).  It doesn't sound like a hardware problem.

>> Are you using a factory-provided DIMM?  What  
>> if you try a different one (preferably a different brand/size)?
>>
> 
> Yes, both boards have the factory provided memory. There are different
> DIMMs on each of the two boards. The DDR is Micron, the DDR2 I don't
> recognize the manufacturer for. Hopefully they're different enough.
> Unfortunately, I don't have any more memory that fits these boards.

Good enough, especially since you are using DIMMs that are provided with 
the boards and thus (should be) used around the world without problems.

>> I'm not familiar with the board configuration, I presume instruction  
>> caches are enabled.  Are data caches enabled too?  What happens if you  
>> disable cache(s)?
> 
> Yes, both caches are enabled. I'm not really sure how to turn them off
> without effecting the bootup sequence. It looks like they are assumed to
> enabled during parts of startup in cpu/mpc83xx/start.S

That is the trick using data cache for the stack before the SDRAM is 
initialized, not really what I was referring to.  My question probably 
is immaterial because your failure occurs before (at?) SDRAM 
initialization, before the caches would be enabled as real caches.

> I checked include/configs/MPC8349EMDS.h and didn't find any obvious
> config options for disabling the cache.
> 
> The hang happens before the relocation to RAM. The "I2C:" line where it
> hangs is printed before the relocation. There are "SPI:" and "DRAM:"
> lines that should also be printed before the relocation to RAM.

I2C is used to read the SPD configuration off the memory DIMM. 
Interesting, but I'm not sure what it is telling us...

>> Best regards,
>> gvb
> 
> As some added information, I tried building with ELDK-4.1 (rather than
> ELDK-4.2, which I have been using) and was unable to get the lockup.
> However, in the past I did get several similar lockups using ELDK-4.1,
> which went away when I upgraded to ELDK-4.2 (the problems prompted the
> upgrade). Unfortunately, I just thought the problem was my code at the
> time, and so I did not keep any images around.
> 
> Thanks for your help,
> Ira

Weird behavior that changes with different builds and/or shifting things 
in memory quite often are build tools or memory problems.  It doesn't 
sound like you are having memory problems, but your build tools sound 
suspicious.  There are lots of people running ELDK4.1 and 4.2 (myself 
included - on debian, cross compiling for a MPC8360) so that probably 
isn't the problem.

What is your build host running (OS, distribution)?  Any chance of doing 
a clean OS and ELDK installation on a different machine?

Running low on theories,
gvb