mirror of
https://github.com/opnsense/src.git
synced 2026-04-02 16:05:17 -04:00
f10baa4049
After spending a lot of time trying to track down what was going on, I have isolated the "black screen" failures when using boot1 to boot a G4 machine. It turns out we were replacing the traps before installing the temporary BAT entry for the bottom of physical memory. That meant that until the MMU was bootstrapped, the cached translations were the only thing keeping us from losing. Throwing boot1 into the mix was affecting execution flow enough to cause us to hit an uncached page and crash. Fix this by properly setting up the initial BAT entry at the same time we are replacing the OpenFirmware traps, so we can continue executing in segment 0 until the rest of the DMAP has been set up. A second thing discovered while researching this is that we were entering a BAT region for segment 16. It turns out this range was a) considered part of KVA, and b) has firmware mappings with varying attributes. If we ever accessed an unmapped page in segment 16, it would cause a BAT entry to be installed for the whole segment, which would bypass the existing mappings until it was flushed out again. Instead, translate the OFW memory attributes into VM memory attributes and install the ranges into the kernel address space properly. Reviewed by: adalava MFC after: 3 weeks Sponsored by: Tag1 Consulting, Inc. Differential Revision: https://reviews.freebsd.org/D25547 |
||
|---|---|---|
| .. | ||
| aim_machdep.c | ||
| locore.S | ||
| locore32.S | ||
| locore64.S | ||
| mmu_oea.c | ||
| mmu_oea64.c | ||
| mmu_oea64.h | ||
| mmu_radix.c | ||
| moea64_native.c | ||
| mp_cpudep.c | ||
| slb.c | ||
| trap_subr32.S | ||
| trap_subr64.S | ||