> I'm still wrestling with getting a kernel to boot on our SA1110
> development board. After a series of crazy, inconsistent behaviors I
> set up a new kernel tree and started over. Now I think I have a
> consistent symptom I can use to find the problem. In head.S after the
> kernel is decompressed, there is some code that moves everything from
> reloc_start: to reloc_end: to the address at the end of the
> decompressed
> kernel. After the move it jumps to the new reloc_start:
> address. In my
> case it never gets there; debug messages immediately after
> the jump never
> appear and within a second or so I get repeated:
>
> We made it to the breakpoint vector!!
> R13: 0XC0FFFFC8
> R14: 0X800F0010
>
> I verified that the value passed to the pc (approximately
> 0xc00f9c0c) equals the value calculated for the destination of
> reloc_start: code. I have the mmu and caches off at this point.
>
> Aside from mis-configured or broken hardware, is there another
> plausible explanation for this behavior?
>
> Thanks,
> Chris
Unless you've seriously munged your new kernel this is almost assuredly
hardware related. The decompressing/moving/relocating process is pretty
well rung out, even on the StrongARM. If you can't run reliably without any
of the caches or MMU turned on, it's time to start debugging hardware or
your bootloader's SDRAM setup routines.
//Jeff
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++ Please use [EMAIL PROTECTED] for ++
++ kernel-related discussions. ++
