First, a brief introduction on what I am doing. I have implemented a “firmware” module, activated by Illegal Instruction Exceptions, which simulates a few instructions of whatever software was running at the time of the Illegal Instruction Exception. The firmware backs-up the ISA-level state of the interrupted software, simulates some of the interrupted software’s instructions—updating the backed-up state---and restore the, now modified, backed-up software state to the hardware, exiting by returning control back to the interrupted software.
My firmware resides in DDR2 between 0x08000000 and 0x10000000. The toolchain is only given memory below 0x08000000 and IIEs are reconfigured to cause execution to jump to 0x08000000. I have also configured the processor to create an IIE whenever the state of the processor represents an assertion violation---the assertions have to do with known processor bugs. When running the dijkstra benchmark in bare metal (caches enabled, MMUs disabled), the processor halts with an alignment exception. The alignment exception occurs both in real hardware and in RTL simulation. Here is a link to a figure that shows the events that create the alignment exception: http://dl.dropbox.com/u/8768/cacheBug.png. The green circle represents the data that matches the assembly dump of that address in the benchmark program. The red circles represent contaminated instruction data. The yellow circles represent the program address that is associated with the corrupted instruction that causes the alignment exception. The blue circle represents the alignment exception. Am I doing something wrong or could this be a cache bug? Note that I have seen this behavior manifest before, which is why I disable both caches while my firmware executes. ---Matthew Hicks _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
