Two other h1940 fixes

This might be a good time to mention two other changes I had
to do in order to get my 2.6.20-rcX kernels to boot reliably.

1) In the early startup in mach-h1940.c/h1940_map_io(), the
suspend/wakeup routine h1940_pm_return() is copied to a fixed
address in memory, so the wakeup code can jump to it. The
init code copies 1024 bytes, and my kernels on my h1940 fault
every time it boots, it can't even start up. I have no idea why
Arjan's kernels work, mine sure don't.

In any case the h1940_pm_return() routine is only two instructions,
8 bytes, so I just clipped down the memcpy length. Everything works
fine. If you're having trouble, you might try this. I guess 1024 is there
for insurance? The rx3715 code copies the same amount.

Index: kernel/arch/arm/mach-s3c2410/mach-h1940.c
===================================================================
--- kernel.orig/arch/arm/mach-s3c2410/mach-h1940.c
+++ kernel/arch/arm/mach-s3c2410/mach-h1940.c
@@ -390,7 +391,7 @@ static void __init h1940_map_io(void)
 
        /* setup PM */
 
- memcpy(phys_to_virt(H1940_SUSPEND_RESUMEAT), h1940_pm_return, 1024);
+ memcpy(phys_to_virt(H1940_SUSPEND_RESUMEAT), h1940_pm_return, 8);
        s3c2410_pm_init();
 }
 

2) The h1940 kernel default configuration sets the "optimize for size"
parameter in the General Setup section. With a gcc4.1.1 toolchain
I have had a lot of trouble with this. I got strange and random faults
in the SysV IPC code, and in __link_path_walk(), i.e. not code you'd
expect to fault. I got these with both the OpenEmbedded and Code
Sourcery 4.1.1-based toolchains.

I recommend turning off -Os, the problems vanished and the kernel is a
lot more stable.

Tom.
Received on Thu Jan 25 2007 - 22:17:39 EST