>       I'm trying to get a kernel to boot on an SA1110 platform
> (development board with 64mb SDRAM).  I set up the memory 
> configurations
> in mm/mm-sa1100.c and kernel/arch.c.  I pass architecture 
> number 0x10 from
> the bootloader but it never gets out of head-armv.S.  I 
> traced the problem
> to the instruction turning on the MMU:
> 
> mcr     p15, 0, r0, c1, c0
> 
>       At this point r0 = 0xc000517d; mmu, write buffer, and all caches
> on.  Is all of that really supposed to happen here?  Or is r0 getting
> incorrectly set in __create_page_tables?
> 
>       I remember someone else reporting a freeze when the MMU is
> switched on (SA1110 also).  Any ideas?
> 
> Thanks,
> Chris

Well, I'm not exactly an expert on this, but I did successfully get a kernel
running on an SA1110 platform.  First off, what kernel are you using?  For
SA1110 you'd better go get 2.3.99-pre3 and the latest patches from
ftp.netwinder.org/users/n/nico and ftp.arm.linux.org.uk.  The kernel wants
to begin execution at 0xC0008000.  Stock setup has the compressed kernel
image being loaded at 0xC008000, then jump to that address. Then it
decompresses, etc. etc. but you know all that already I assume.  I moved the
initial load address to accommodate my custom bootloader but the
decompressed kernel still gets put at 0xC008000.  I suspect that if you're
trying to load the kernel somewhere else that's where things are getting
messed up.  Russell King had a good comment about possible problems when
using a debugger.

Another possibility: If the Icache has not been enabled up to now, turning
on the buffers and the Icache initiates an 8 word burst transfer on the
memory buss.  If the memory timing is not set correctly, especially when
using SDRAMs on the SA1110, or there are other signal integrity issues, this
is a good time for things to blow up.  How do I know this???

Regards,
//Jeff

unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++        Please use [EMAIL PROTECTED] for           ++
++                        kernel-related discussions.                      ++

Reply via email to