> The system hangs after executing the instruction to
> enable the mmu "mcr p15, 0, r0, c1, c0" located a
> few lines after the "aligned_call:" label. If I
> comment out that instruction, it hangs on the next
> instruction trying to jump to .Lalready_done_mmap via
> the "mov pc,lr" instruction. (Sounds like an
> addressing problem to me)
I ran into this same problem after changing the version of gcc that I was
using. I've been debugging with a logic analyzer attached to the SA110 bus.
With icache and dcache disabled, I can watch the instructions as they are
fetched and data as it is read and written.
This code that initially enables the MMU is very fragile -- it depends on
the timing of the instructions being exactly right. As it is now, the MMU
must be enabled after the "mov pc, lr" instruction is fetched but before it
is executed. (A) If the MMU is enabled before the mov is fetched, then you
get a instruction fetch fault because there is no mapping in the MMU table
for addresses in the 0x8000 page. (B) If the mov is executed before the MMU
is enabled, it fetches from bogus physical addresses.
I added code in head-armv.S (in linux-2.3.29-rmk1) to map the first 2MB of
DRAM into the first 2MB of virtual memory to solve (A). I added a number of
nops between the mcr and the mov to solve (B). I think this is a more
robust implementation than the current one. Attached is a patch file
showing my changes. They need some cleaning up before I submit it as an
official patch, but it might help you with the problem you're having.
-Jamey
patch-head-armv.S
