MCF5329 w/ ucLinux Kernel Panic

[richard_bair]

Hello & thanks for reading.

I've been working on a persistent kernel panic for the last week or so and seem to have hit a wall so any advice is much appreciated.

BACKGROUND:

============

This is a custom board with MCF5329, 32MB of SDRAM, Flash, SD Card and an LCD.  U-boot is being used to boot ucLinux.  ucLinux kernel is being created using LTIB (from Freescale site).

PROBLEM:

========

The kernel continues to panic.  From the console perspective this can happen just as u-boot completes uncompressing the kernel, mid kernel bring up and sometimes 15s into a stable prompt.  Via trial and error, I've noticied that if I comment out 1 line in the mcf-fb.c (.../drivers/vided/mfc-fb.c) module I can reach a stable kernel.  This is the line in which LCDCHEN in MISCCR is set to a 1.  If I comment out this line, I can get to a stable prompt but as you can imagine...the LCD is *not* functional.  In general, after the panic, I see my first screen on the LCD.

WHAT I'VE TRIED:

==============

1) Using ./ltib -c I changed the kernel configuration from a 4k to 8k stack.  The thougth here was to rule out a stack overflow.  Btw, it seems I should be able to set the stack to whatever value I want but I can't seem to determne how to accomplish this.

2) I've tried activating LCDCHEN in a totally different location.  For example, I moved this line to the SD module which comes up later in stable versions with LCDCHEN deactivated.  This tends to shift the kernel panic out later in the bring up process.

3) I noted that ucLinux seems to be reserving the frambuffer at 0x40400000 for 0x96000 length.  Thus, I went to a CodeWarrior program trying to run setting LCD-SSAR to that address.  This test hasn't worked yet.  I can't seem to figure out the syntax to change the following:

unsigned char my_image[] {0x00, 0xAA, .....};

to (2 attempts made)

unsigned char my_image[] @0x40400000 {0x00, 0xAA, .....};unsigned char my_image[] : 0x40400000 {0x00, 0xAA, .....};

So this test isn't complete.  I have tried u-boot memtest functions in that area and in general have checked the timing of SDRAM and don't believe I have any problems accessing memory in this area.

CURRENT STATUS:

===============

Well, I'm late getting this board working!  I'm new to ucLinux and suspect when LCDCHEN is activated that I'm creating some type of memory conflict but I've had no luck decoding the panic messages or deciphering /var/log.  I haven't ruled out a HW problem as this is a rev1 of a rev0 board.  The rev0 board used a PCF5328 and I've converted over to a MCF5329.  The rev0 version is functional and of course every change is under scrutiny; however, I can't seem to find the issue.

Any takers on this one for advice on next steps?

[TomE]

> This is a custom board with MCF5329, 32MB of SDRAM, Flash,

SDR or DDR? Shared 32-bit bus or split bus?

We're running 32-bit non-split and have had troubles galore.

We converted from an MCF5235 to the MCF5329. There are some nasty gotchas.

The MCF5329 defaults all pins to "low drive strength". The MCF5329 does that for "normal pins", but

defaults the Flexbus and SDRAM pins to VERY high drive strength.

Then the manual hides the relevant "drive strength" registers, mis-naming and mis-describing them as

"SDRAM Mode Select Control Register (MSCR_SDRAM)" and "FlexBus Mode Select Control Register (MSCR_FLEXBUS)".

We had random memory corruptions until we programmed the Flexbus to 10pF and the SDRAM to 30pF.

Look out for the Cache Config. You probably need "Writethrough" if you're using video memory. That worked

out best for us.

Where'd the kernel port come from? Does it run on the eval board? If so, what did you change?

Can you run the thing from scratch with a debugger pod attached? That might let you debug it easier.

Good luck.

[dan77]

I've got the same problem.  As soon as I try and set the LCDCHEN bit in the CCM MISCCR register my system hangs.  Did anyone ever get a solution to this problem?

[maxhexis]

Hi all,

are you sure the problem is related to enabling the LCD controller? In your first post you say that sometimes the system hangs while decompressing Linux, or randomly during Linux boot.

I have experienced similar problems and I have found the following points useful to fix them:

1) Check proper series termination of SDRAM lines. Some models have problems if you have under/overshoots on signals (not only control ones).

2) Try to change the delay of SDQM signal, a quadrature clock which is used to sample SDRAM data during reads. I found that reducing the delay of this signal with respect to the real board delay solved the problem.

3) I have found a type of SDRAM which needs a dummy read/write cycle just after the initialization code in u-boot. At the moment I do not know if it is a problem of the SDRAM, or the controller which needs some read/write operations to put it in the correct way of operations

Bye,

[TomE]

Another possibility is that the LCDC might be set up with vertical interrupts enabled, and the vertical interrupt handler may be causing the problem.

> I have found a type of SDRAM which needs a dummy read/write cycle just after the initialization code in u-boot.

We got that too, big time. After the SDRAM initialisation code has done everything "the book" says we have to do, we then perform some dummy reads and writes or the first instruction read will pull junk into the cache line. Because we have the cache enabled, and because that reads "whole cache lines" and because we want multiple reads we do the following:

  move.l #0xA0000200,%d0  movec %d0,%CACR /* enable cache */  nop  /* Do a read from RAM */  /* NOTE! This is a hack until the issue is better understood!     Without this read here, some boards read corrupt values out     of RAM on the first burst read. If the first burst read is     when the code is being executed from RAM then corrupt     instructions are read and an illegal instruction occurs.   */  move.l  #0x10, %d0  /* Cache line length */  move.l  #0x40010000, %a0   move.l  #0x40040000, %a1 /* Destination NOT in the boot itself */  move.l  (%a0), (%a1)  add.l   %d0, a0  add.l   %d0, a1  move.l  (%a0), (%a1)  add.l   %d0, a0  add.l   %d0, a1  move.l  (%a0), (%a1)  add.l   %d0, a0  add.l   %d0, a1  move.l  (%a0), (%a1)  add.l   %d0, a0  add.l   %d0, a1

If the cache isn't set up at the time of the crash, then the LCDC might be the only thing performing burst-reads from the RAM, and it might be the burst cycles that are causing problems.

Tom

[maxhexis]

I have a suspect: couldn't be the cache the source of the problem? Usually flash memory space is not cached, so the access to SDRAM is the first which really uses caches. Is it real for your boot code?

Morevoer, look at your private mail.

Max

[Eyore]

Try the cfinit tool available from http://www.microapl.co.uk/.  It's a gui  that helps setup initilization code for various coldfire processors.  It does support the 5329.