[OpenBIOS] sparc32 trap recovery
breuerr at mc.net
Wed Jun 19 16:44:42 CEST 2013
On 6/16/2013 4:38 AM, Mark Cave-Ayland wrote:
> On 15/06/13 18:50, Bob Breuer wrote:
>> I'm aiming for a cpeek that catches the data faults on sparc32, so I've
>> coded up the attached test code.
Got some good suggestions, thanks guys. So I need to read the fault
status register to clear it before the OS boots, and may as well use the
status itself as the flag to indicate if a fault happened. Also the
interrupt handler I had posted is overkill, so I'll narrow the focus.
> I took a peek at the OpenBOOT source code to see what that does, and it
> seems that under the hood it is based on a trap handling solution. The
> key is newguarded-execute which on SPARC64 does the following:
> * Save the current contents of traps 30, 1f, 32 and 34
> 0x30 = Data Access Exception
> 0x1f = Level 15 interrupt
> 0x32 = Data Access Error
> 0x34 = Unaligned Access Error
> * Invoke the Forth word, throwing an a Forth exception upon error
> * Restore the contents of the above traps
> From the SPARCv8 manual we could say that these map to the following
> SPARC32 traps:
> * 0x09 Data Access Exception
> * 0x1f Level 15 interrupt
> * 0x29 Data Access Error
> * 0x07 Unaligned Access Error
So I fired up my SS-20 and did a little poking around to see how the
SuperSparc-II behaves here.
* page not mapped: read/write = Data Access Exception
* sbus timeout: read = Data Access Exception, write = Level 15 int
* afterwards, SFSR will always be cleared to 0
For cpeek/cpoke, OBP will catch the Access Exception and Access Error,
but it won't catch the Unaligned Access or Level 15 int.
So how about if I setup an interrupt handler that skips over the
faulting instruction when a global flag is set, otherwise continues as
is today. Then cpeek can become:
- set skip_datafault flag
- clear SFSR
- chain to c@
- clear skip_datafault flag
- check SFSR
- if fault, fixup stack and return false, else return true
Now, I might be able to code up this cpeek version in forth, or just
leave it in C?
> In terms of the routine itself, have you had a look at the work I did a
> while back to catch the I/D-MMU miss traps on SPARC64? In particular I
> added SAVE_CPU_STATE(x) and RESTORE_CPU_STATE(x) macros to
> arch/sparc64/vectors.S that do all of the context save/restore work so
> that the code required to get back into C outside of this is fairly
> minimal (see reload_DMMU_tlb in the same file).
We can probably come back to this later, but I don't see any similar
code for sparc32.
More information about the OpenBIOS