MIPS Interface: Difference between revisions

Jump to navigation Jump to search
Content added Content deleted
(Few more details for MI_BB_SECURE_EXCEPTION)
Line 244: Line 244:
==== <span style="display:none;">0x0430 0014 - MI_BB_SECURE_EXCEPTION</code> ====
==== <span style="display:none;">0x0430 0014 - MI_BB_SECURE_EXCEPTION</code> ====
----
----
{{#invoke:Register table|head|550px|MI_BB_SECURE_EXCEPTION <code>0x0430 0014</code>}}
{{#invoke:Register table|head|700px|MI_BB_SECURE_EXCEPTION <code>0x0430 0014</code>}}
{{#invoke:Register table|row|31:24}}
{{#invoke:Register table|row|31:24}}
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-?
| U-? || U-? || U-? || U-? || U-? || U-? || W-? || W-?
|-
|-
| — || — || — || — || — || — || — ||
| — || — || — || — || — || — || — || SK RAM Access
{{#invoke:Register table|row|23:16}}
{{#invoke:Register table|row|23:16}}
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-?
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-?
Line 254: Line 254:
| — || — || — || — || — || — || — || —
| — || — || — || — || — || — || — || —
{{#invoke:Register table|row|15:8}}
{{#invoke:Register table|row|15:8}}
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || RW-?
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-?
|-
|-
| — || — || — || — || — || — || — || —
| — || — || — || — || — || — || — || —
{{#invoke:Register table|row|7:0}}
{{#invoke:Register table|row|7:0}}
| RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-?
| RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-0 || RW-1 || RW-1
|-
|-
| || Button || MI error || PI error || Timer || App. || || Secure mode
| Module || Button || MI error || PI error || Timer || Application || Boot memory swap || Secure mode
{{#invoke:Register table|foot}}
{{#invoke:Register table|foot}}
{{#invoke:Register table|definitions
{{#invoke:Register table|definitions
| 25 | Unknown | System software writes to this bit when launching an app or game. (TODO determine the purpose of this bit)
| 6 | Button | Secure trap caused by the power button being pressed
| 24 | SK RAM Access | Setting this bit to 1 enables access to an 0x8000-byte SRAM mapped at 0x1FC40000 outside of secure mode.
| 5 | MI error | Secure trap caused by an MI error
| 4 | PI error | Secure trap caused by a PI error
| 7 | Module | Secure trap caused by the memory card being removed. (TOVERIFY)
| 3 | Timer | Secure trap caused by the secure timer
| 6 | Button | Secure trap caused by the power button being pressed. (TOVERIFY there should be some way to control whether this event causes a secure trap or an Int2/PreNMI interrupt)
| 2 | Application | Secure trap caused by an application calling an SKC (see below)
| 5 | MI error | Secure trap caused by an MI error.
| 4 | PI error | Secure trap caused by a PI error.
| 0 | Secure mode | SK writes 0 here to exit secure mode; the bootrom writes 1 here just before jumping to SK, but it's not known what effect this has.
| 3 | Timer | Secure trap caused by the secure timer.
| 2 | Application | Secure trap caused by an application reading this register outside of secure mode.
| 1 | Boot memory swap | If this is set to 1 the boot ROM is mapped to 0x1FC00000 and Secure Kernel RAM is mapped at 0x1FC20000; this is the state at cold boot. If this is not set the Secure Kernel RAM is mapped at 0x1FC00000 and the boot ROM is mapped at 0x1FC20000.
| 0 | Secure mode | Secure Kernel writes 0 here to exit secure mode. This is effective immediately, all future memory accesses that miss the CPU cache will be unable to access secure mode resources. Whenever this register is written to without the intention to exit secure mode, a 1 must be re-written here.
}}
}}


'''Extra Details:'''
'''Extra Details:'''
: Secure traps are implemented as an NMI to the CPU and are vectored to 0xBFC00000, this register is then used by the Secure Kernel as a Cause register to determine the reason for the secure trap and the relevant handler is entered.
: The bootrom writes 0 to bit 1 just before jumping to SK; it's also unknown what effect this has.
: Reading this register from non-secure mode, i.e. as a game or application, causes a secure trap (execution jumps to the beginning of the secure kernel and the console enters secure mode) with the Application bit set in the register. Presumably, writing the register has the same effect, but this hasn't been checked.
: Reading (and possibly writing, TOVERIFY) this register from non-secure mode (i.e. from a game or application) causes a secure trap with the Application bit set in this register. This mechanism is how SKCs (Secure Kernel calls) are implemented; the application sets up the required CPU registers for the call before reading this register to trigger the Application trap.
: This mechanism is how SKCs (secure kernel calls) are implemented; the application sets up the required CPU registers for the call, then reads from MI_BB_SECURE_EXCEPTION to trigger the trap.