Problems on porting the linux 2.6.23 kernel to MCF5475

[fulivi]

Hello,

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=10.3.3.56:/home/evb/rootfs ip=10.3.3.220:10.3.3.1:10.3.3.255:255.255.255.0:ColdFire:eth0ff 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.

Regards,

Federico Ulivi
Embedded software developer

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

[fulivi]

Hi everyone,

I eventually figured out the problem. It was a truly nasty one!
Basically the processor got a double fault (an fault-on-fault as the freescale manual calls it).
In the "resume" function when the context of the task the processor is switching to is recalled, the processor gets an access exception because the page containing the stack has been evicted from TLB some time earlier. But, in order to process the exception, the stack must be accessible to save the return address and the exception data. And so the CPU enters a fault-on-fault condition from which reset only can force it out.

It looks like Freescale people already encountered this problem when they did the port of 2.6.10 kernel to coldfire. Their solution was to allocate some locked lines in TLB covering a portion of RAM (8 Mb) and to allocate all thread stacks in this part. The trick was to declare this part of memory as a DMA zone and to use the GFP_DMA flag when the stack for new threads was allocated (by alloc_thread_info function).

The port of 2.6.23 kernel to MCF54455 used a simpler version of this solution: there they allocate 256 Mb of RAM in locked TLB lines. In this way they cover any reasonable amount of RAM that the processor is ever going to use and they don't need to specify GFP_DMA when allocating stack memory. Unfortunately, this solution is not applicable to MCF5475 because the maximum size of TLB lines is 1 Mb (as opposed to 16 Mb in MCF54455). With 1Mb lines you can't cover more than 32 Mb of RAM (if you are willing to use the whole TLB) and the EVB  board carries 64 Mb.

Regards,

Federico Ulivi
Embedded software developer

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

[jkimble]

Were you ever able to resolve this problem (complete the port)?

Would this work on the 5484? I'm still fighting the 2.6.10 kernel and back porting drivers is getting real old, real quick.... Freescale hasn't responded to my posts requesting a time line for their release of a later kernel for this processor.

Appreciate any insight you can give me.

[comio]

jkimble..., please, read your mail

ciao

luigi

[aeg]

Hey luigi!!!

Read that you had a 547x/548x version working on 2.6.23. I'm working on the same thing myself but have been struggling a bit.
How far have you made it and are there any outstanding problems?
I'm willing to help and also add to the effort with various drivers etc. etc.

Best,
Andreas