Subject: Re: Linux 2.4.27-pre6-bk hangs on MPC8540 board

From: Kumar Gala <[email-masked]>
Date: Fri, 13 Aug 2004 09:30:42 -0500

Try just enabling the L1 caches and see if the issue still exists.

- kumar

On Aug 12, 2004, at 5:07 PM, Cordes, Aaron M wrote:

>
> I completely disabled L1 and L2 cache in the processor and I am not
> seeing the memory corruption anymore.  So, good news is board is now
> booting, bad news is it's dog slow and we have a memory design to
> debug.
> Thanks to everyone for your prompt and helpful advice.
>
> Aaron
>
>
> -----Original Message-----
> From: VanBaren, Gerald (AGRE)
> [mailto:[email-masked]]
> Sent: Thursday, August 12, 2004 3:32 PM
> To: Cordes, Aaron M
> Subject: RE: Linux 2.4.27-pre6-bk hangs on MPC8540 board
>
>
>
> On 8xx and 82xx and, I presume, 85xx processors, disabling cache
> inhibits burst mode.  It is the cache line filling  and flushing that
> causes burst accesses.  Note that DMA also causes bursts, but that
> becomes a problem much later.
>
> gvb
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of
>> Cordes, Aaron M
>> Sent: Thursday, August 12, 2004 3:34 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: RE: Linux 2.4.27-pre6-bk hangs on MPC8540 board
>>
>>
>>
>> Is there a way in Linux or the 8540 to prevent burst accesses, in
>> order to test whether they are the problem?  I scanned the processor's
>> reference manual, but I didn't see anything that would let me do this.
>>
>> Thanks
>> Aaron
>>
>> Aaron Cordes
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Thursday, August 12, 2004 9:08 AM
>> To: Cordes, Aaron M
>> Cc: [email-masked]
>> Subject: Re: Linux 2.4.27-pre6-bk hangs on MPC8540 board
>>
>>
>> In message
>> <[email-masked]> you
>> wrote:
>>>
>>> We are bringing up an 8540-based board, and are getting hangs at
>>> random spots when booting Linux.  Sometimes the hangs occur
>> while the
>>> kernel is initializing, sometimes the boot gets far enough
>> where I can
>>
>>> log in and run a couple of programs.  Eventually the board locks up
>>> with no oopses or panics.  If I connect to the board with a
>> debugger,
>>> the processor is usually stopped in the Data miss exception handler,
>
>>> and there is usually memory corruption in the kernel code.
>>
>> That's it: memory problems.
>>
>>> I ran memory tests using both Edink and U-boot and they all
>> passed, so
>>
>>> I'm reluctant to blame hardware for the memory corruption.
>> Has anyone
>>
>>> seen similar behavior, or have any suggestions of things I
>> might try?
>>
>> All those memory tests only can test simple read and write  accesses;
>> they  all  fail to access burst mode accesses, which will happen when
>> Linux starts runing, and which are failing.
>>
>> Your SDRAM initialization is bad, and  the  system  crashes  when  it
>> tries to fetch instructions from RAM. Note that simple read and write
>> accesses may still work, it's the burst mode that is failing.
>>
>> It is NOT sufficient to program the memory controller  of  your  CPU;
>> each  SDRAM  chip  also  requires  a specific initialization sequence
>> which you must adhere  to  to  the  letter  -  check  with  the  chip
>> manufacturer's manual.
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>> --
>> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: [email-masked]
>> If this is a service economy, why is the service so bad?
>>
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/