> From [EMAIL PROTECTED] Mon Sep 20 15:53:48 1999
> Subject: Question: Code in head-armv.S
>
> Hi,
>
> I'm running an ebsa285-like system with 2.2.11-rmk1-stk1 (stk1 means
> some stuff specific to our board), and I'm seeing something strange.
> ... I've trace it to where the MMU is enabled. Here's the sequence:
> ...
> mcr p15, 0, r0, c1, c0 @ Enable MMU & caches. In 3
>instructions
> @ we lose this page!
> mov pc, lr
I ran into a similar problem. I'm actually using ARM Linux on a custom SW
simulator that mimics an ESBA285 w/ a StrongARM CPU. I decided I wasn't
interested in hacking the simulator to try and duplicate the StrongARM's
non-deterministic MMU-enable behavior, so instead I modified head-armv.S
to create a direct virtual-physical mapping for the section containing
the instruction that enables the MMU. I do this right after the page
table is cleared.
/*
* r4 = page dir in physical ram
* r5 = physical address of start of RAM
* r6 = I/O address
*/
mov r0, r4
mov r3, #0
add r2, r0, #0x4000
1: str r3, [r0], #4 @ Clear page table
teq r0, r2
bne 1b
/* JJS HACK -- add an entry to get us past the MMU being enabled. */
mov r3, #0x0c00;
orr r3, r3, #0x0e;
mov r0, #0x4000;
str r3, [r0];
Later on, as the kernel sets up the real page tables, it just overwrites
this entry. I think this should work fine on real StrongARM HW. I also
discovered at least one other place in the kernel where the MMU mapping
for the currently executing page changes, in the page table setup code.
However, it looks like that case will always work because of the way its
surrounded by TLB flushing code.
At any rate, you might try some trick like this and see if it helps.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
