The kernel recovers almost all of the time
from this. Almost being the operative word.
Note that the rPC of C0168AEC is a zeroed
out area after _etext. which is c0168ad8.
We think that when in __down_read, at the
very end, when interrupts are enabled, an interrupt occurs that then causes
an MMU exception. On return from the interrupt, execution starts after
the correct address for the instruction. This is just a guess...
I have not been able to catch this in the
page fault routine.
To catch this I put a hardware breakpoint
at "illegal_opcode_trap_wrapper:" The
debugger register output is below.
Configuration:
We are using the PetaLogix MMU distro
mmu-v0.10.
Ours is a custom board, with a Virtex5.
We have 512M of DRAM, and are using
the UartLite.
I tried to match the config settings
from the ML505 example.
From GDB:
MicroBlaze Processor Configuration :
-------------------------------------
Version............................7.00.a
Optimization.......................Performance
Interconnect.......................PLBv46
MMU Type...........................Full_MMU
No of PC Breakpoints...............1
No of Read Addr/Data Watchpoints...0
No of Write Addr/Data Watchpoints..0
Instruction Cache Support..........on
Instruction Cache Base Address.....0x80000000
Instruction Cache High Address.....0x9fffffff
Data Cache Support.................on
Data Cache Base Address............0x80000000
Data Cache High Address............0x9fffffff
Exceptions Support................on
FPU Support.......................off
Hard Divider Support...............on
Hard Multiplier Support............on
- (Mul64)
Barrel Shifter Support.............on
MSR clr/set Instruction Support....on
Compare Instruction Support........on
PVR Supported......................on
PVR Configuration Type.............Full
