* Define a new "MMU type", ARM_MMU_SA1. While the SA-1's MMU is basically
compatible with the generic, the SA-1 cache does not have a write-through
mode, and it is useful to know have an indication of this.
* Add a new PMAP_NEEDS_PTE_SYNC indicator, and try to evaluate it at
compile time. We evaluate it like so:
- If SA-1-style MMU is the only type configured -> 1
- If SA-1-style MMU is not configured -> 0
- Otherwise, defer to a run-time variable.
If PMAP_NEEDS_PTE_SYNC might evaluate to true (SA-1 only or run-time
check), then we also define PMAP_INCLUDE_PTE_SYNC so that e.g. assembly
code can include the necessary run-time support. PMAP_INCLUDE_PTE_SYNC
largely replaces the ARM32_PMAP_NEEDS_PTE_SYNC manual setting Steve
included with the original new pmap.
* In the new pmap, make pmap_pte_init_generic() check to see if the CPU
has a write-back cache. If so, init the PT cache mode to C=1,B=0 to get
write-through mode. Otherwise, init the PT cache mode to C=1,B=1.
* Add a new pmap_pte_init_arm8(). Old pmap, same as generic. New pmap,
sets page table cacheability to 0 (ARM8 has a write-back cache, but
flushing it is quite expensive).
* In the new pmap, make pmap_pte_init_arm9() reset the PT cache mode to
C=1,B=0, since the write-back check in generic gets it wrong for ARM9,
since we use write-through mode all the time on ARM9 right now. (What
this really tells me is that the test for write-through cache is less
than perfect, but we can fix that later.)
* Add a new pmap_pte_init_sa1(). Old pmap, same as generic. New pmap,
does generic initialization, then resets page table cache mode to
C=1,B=1, since C=1,B=0 does not produce write-through on the SA-1.
/dev/power.
XXX - due to the way interrupt handling is structured we have no easy
way to defer clearing the button interrupt until the sysmon callback
has happened and the event is dispatched. We clear it imediately on
return from the interrupt handler. This means we get an interrupt storm
until the button is released, and then start to handle it.
This needs to be fixed! (But with the default application for the power
button does not make a user visible difference.)
was checked in:
* It was not actually disabling the MMU, and so jumping to the
reset vector would happily cause a panic(), since it would be
the kernel's reset vector, not the ROM's.
* In the event the system was using high vectors, VECRELOC was not
getting cleared, which has the potential to wreak havoc when re-entering
the ROM.
* It was totally broken for CPUs < ARMv4; you still need to disable
the MMU on those, just need to skip the ARMv4 TLB flush.
* The code that was checked in would only work if the kernel is mapped
VA==PA. For systems where the kernel is NOT mapped VA==PA, you only
get the prefetch depth # of insns (2) after the MMU is turned off before
you have fix the PC.
Backing out the change fixes rebooting on several evbarm platforms.
