Federico Ulivi

Problems on porting the linux 2.6.23 kernel to MCF5475

Discussion created by Federico Ulivi on Feb 28, 2008
Latest reply on May 6, 2008 by Andreas Engberg

I'm a embedded sw developer working on a port of linux 2.6.23 to MCF547x. I started by taking the current port of 2.6.23 on MCF54455. I modified the memory mapping and the drivers for devices that are different between the two processors.
I'm currently using the current development environment:
- M5475EVB board from Freescale/Logic PD
- toolchain version:gcc (Sourcery G++ Lite 4.2-8) 4.2.0 20070318 (prerelease)
- Lauterbach ICD Trace32 to debug through the BDM port

The kernel works fine from boot to the final phases of initialization. Then it crashes before being able to launch the init process. On TRACE32 I get a "emulator reset" error, whereas, if I launch the kernel without the debugger, it crashes at the same point and it just stops (no "oops").

This is the trace:
[42949372.960000] Linux version 2.6.23 (gcc version 4.2.0 20070318 (prerelease) (Sourcery G++ Lite 4.2-8)) #37 Thu Feb 28 18:21:09 CET 2008
[42949372.960000] starting up linux startmem 0xc01de000, endmem 0xc4000000,    size 62MB
[42949372.960000] console [ttyS0] enabled
[42949372.960000] Built 1 zonelists in Zone order.  Total pages: 8157
[42949372.960000] Kernel command line: mac0=00:08:EE:00:9F:10 noinitrd root=/dev/nfs rw nfsroot= ip= mtdparts=phys_mapped_flash:256k(Colilo),2816k(kernel),13312k(user)
[42949372.960000] PID hash table entries: 256 (order: 8, 1024 bytes)
[42949372.960000] No real time clock, nothing to read, returning 1970.
[42949372.960000] Console: colour dummy device 80x25
[42949372.960000] Dentry cache hash table entries: 8192 (order: 2, 32768 bytes)
[42949372.970000] Inode-cache hash table entries: 4096 (order: 1, 16384 bytes)
[42949372.990000] Memory: 63232k/63232k available (1216k kernel code, 1024k data, 64k init)
[42949373.230000] Mount-cache hash table entries: 1024

I was able to find that a particular movem instruction in the "resume" function crashes the debugger. To me it appears like there is some "mmu starvation" (for a lack of a better name).  If I reduce the amount of locked TLB lines (the ones that are allocated in head.S), the crash occurs later.
I tried to change the attributes of DTLB lines (e.g. I removed the "X" attribute) but nothing changed.

Do you have any suggestion on the use of MMU on 5475 that are not written in the manual, please? I mean, some peculiar condition to be aware of or anything that may cause the MMU to "lock"?

Thanks in advance for your help.

I can provide a lot more information if needed.

Federico Ulivi
Embedded software developer

Sky-Technology srl
V. Gonin, 55
20147 Milano - Italia