http://www.iquebrew.org/api.php?action=feedcontributions&feedformat=atom&user=Stuckpixel
iQueBrew - User contributions [en]
2026-08-07T14:35:53Z
User contributions
MediaWiki 1.35.2
http://www.iquebrew.org/index.php?title=IO&diff=1421
IO
2024-03-21T08:07:50Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = AES, 0x100 = RDB, 0x200 = PI_ERR, 0x400 = USB0, 0x800 = USB1, 0x1000 = ??, 0x2000 = MD). Bottom bits appear to mirror MI_INTR_REG.<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || PI_ATB_NEXT_CONFIG || takes in configuration info about the next ATB entry<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_CNT_REG || Control register for the NAND controller<br />
{| class="wikitable"<br />
|-<br />
!Bit<br />
!Write<br />
!Read<br />
|-<br />
| 31 || Start || Busy<br />
|-<br />
| 30-24 || ? || ?<br />
|-<br />
| 23-16 || NAND command || ?<br />
|-<br />
| 15 || ? || ?<br />
|-<br />
| 14 || Buffer select. Controls where in PI_EX_DMA_BUF the result is read to.<br />0: PI_EX_DMA_BUF + 0<br />1: PI_EX_DMA_BUF + 0x200 || ?<br />
|-<br />
| 13-11 || ? || ?<br />
|-<br />
| 10 || ? || some kind of error status? After a transfer, bootrom checks this bit and returns an error if it was set<br />
|-<br />
| 9-0 || Size to receive to PI_EX_DMA_BUF from NAND, in bytes. || Size to send from PI_EX_DMA_BUF to NAND, in bytes.<br />
|-<br />
|}<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 * 0xC0 || PI_ATB_ENTRY || Associates a particular page (or pages) in cartridge space with a particular NAND block (or blocks) <br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1419
IO
2022-07-29T03:50:04Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND). Bottom bits appear to mirror MI_INTR_REG.<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || PI_ATB_NEXT_CONFIG || takes in configuration info about the next ATB entry<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_CNT_REG || Control register for the NAND controller<br />
{| class="wikitable"<br />
|-<br />
!Bit<br />
!Write<br />
!Read<br />
|-<br />
| 31 || Start || Busy<br />
|-<br />
| 30-24 || ? || ?<br />
|-<br />
| 23-16 || NAND command || ?<br />
|-<br />
| 15 || ? || ?<br />
|-<br />
| 14 || Buffer select. Controls where in PI_EX_DMA_BUF the result is read to.<br />0: PI_EX_DMA_BUF + 0<br />1: PI_EX_DMA_BUF + 0x200 || ?<br />
|-<br />
| 13-11 || ? || ?<br />
|-<br />
| 10 || ? || some kind of error status? After a transfer, bootrom checks this bit and returns an error if it was set<br />
|-<br />
| 9-0 || Size to receive to PI_EX_DMA_BUF from NAND, in bytes. || Size to send from PI_EX_DMA_BUF to NAND, in bytes.<br />
|-<br />
|}<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 * 0xC0 || PI_ATB_ENTRY || Associates a particular page (or pages) in cartridge space with a particular NAND block (or blocks) <br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1418
IO
2022-07-29T00:43:19Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND). Bottom bits appear to mirror MI_INTR_REG.<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || PI_ATB_NEXT_CONFIG || takes in configuration info about the next ATB entry<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_CNT_REG || Control register for the NAND controller<br />
{| class="wikitable"<br />
|-<br />
!Bit<br />
!Write<br />
!Read<br />
|-<br />
| 31 || Start || Busy<br />
|-<br />
| 30-24 || ? || ?<br />
|-<br />
| 23-16 || NAND command || ?<br />
|-<br />
| 15 || ? || ?<br />
|-<br />
| 14 || Buffer select. Controls where in PI_EX_DMA_BUF the result is read to.<br />0: PI_EX_DMA_BUF + 0<br />1: PI_EX_DMA_BUF + 0x200 || ?<br />
|-<br />
| 13-10 || ? || ?<br />
|-<br />
| 9-0 || Size to receive to PI_EX_DMA_BUF from NAND, in bytes. || Size to send from PI_EX_DMA_BUF to NAND, in bytes.<br />
|-<br />
|}<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 * 0xC0 || PI_ATB_ENTRY || Associates a particular page (or pages) in cartridge space with a particular NAND block (or blocks) <br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1412
IO
2021-08-11T17:15:34Z
<p>Stuckpixel: /* MI */</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND). Bottom bits appear to mirror MI_INTR_REG.<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_CNT_REG || Control register for the NAND controller<br />
{| class="wikitable"<br />
|-<br />
!Bit<br />
!Write<br />
!Read<br />
|-<br />
| 31 || Start || Busy<br />
|-<br />
| 30-24 || ? || ?<br />
|-<br />
| 23-16 || NAND command || ?<br />
|-<br />
| 15 || ? || ?<br />
|-<br />
| 14 || Buffer select. Controls where in PI_EX_DMA_BUF the result is read to.<br />0: PI_EX_DMA_BUF + 0<br />1: PI_EX_DMA_BUF + 0x200 || ?<br />
|-<br />
| 13-10 || ? || ?<br />
|-<br />
| 9-0 || Size to receive to PI_EX_DMA_BUF from NAND, in bytes. || Size to send from PI_EX_DMA_BUF to NAND, in bytes.<br />
|-<br />
|}<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1411
IO
2021-08-08T07:32:50Z
<p>Stuckpixel: /* PI */</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x10 = PI EX DMA, 0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_CNT_REG || Control register for the NAND controller<br />
{| class="wikitable"<br />
|-<br />
!Bit<br />
!Write<br />
!Read<br />
|-<br />
| 31 || Start || Busy<br />
|-<br />
| 30-24 || ? || ?<br />
|-<br />
| 23-16 || NAND command || ?<br />
|-<br />
| 15 || ? || ?<br />
|-<br />
| 14 || Buffer select. Controls where in PI_EX_DMA_BUF the result is read to.<br />0: PI_EX_DMA_BUF + 0<br />1: PI_EX_DMA_BUF + 0x200 || ?<br />
|-<br />
| 13-10 || ? || ?<br />
|-<br />
| 9-0 || Size to receive to PI_EX_DMA_BUF from NAND, in bytes. || Size to send from PI_EX_DMA_BUF to NAND, in bytes.<br />
|-<br />
|}<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1410
IO
2021-08-06T18:44:34Z
<p>Stuckpixel: /* PI */</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x10 = PI EX DMA, 0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_CNT_REG || Control register for the NAND controller.<br /><br />
Bit 31: [W] Start [R] Busy<br /><br />
Bit 23-16: [W] NAND command; can be obtained from the datasheet for the NAND. [R] ?<br /><br />
Bit 15: [W] ? [R] ?<br /><br />
Bit 14: [W] Buffer select. Controls where in PI_EX_DMA_BUF the result is read to. 0: PI_EX_DMA_BUF + 0 1: PI_EX_DMA_BUF + 0x200 [R] ?<br /><br />
Bit 13-10: [W] ? [R] ?<br /><br />
Bit 9-0: [W]/[R] Size to send/receive to/from PI_EX_DMA_BUF to NAND, in bytes.<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1409
IO
2021-08-04T03:09:08Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x10 = PI EX DMA, 0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1408
IO
2021-08-04T03:08:48Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x10, = PI EX DMA, 0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1407
IO
2021-08-04T02:58:28Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_BUF || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IQue_Card&diff=1406
IQue Card
2021-07-19T05:42:42Z
<p>Stuckpixel: </p>
<hr />
<div>{{DISPLAYTITLE:iQue Card}}<br />
[[File:IQue_card_disassembled.jpg|thumb|A disassembled '''iQue Card'''.]]<br />
<br />
The '''iQue Card''' (Chinese: 神游卡) is a removable memory card of the [[iQue Player]], used to store [[games]] and the [[SKSA|"Upgradeable Operating System"]]. It is located on the bottom of every unit.<br />
<br />
The iQue Card is housed in a plastic shell, which contains a Samsung K9F1208U0M-YCB0 NAND chip on a special PCB codenamed "DOOKIE". The contents of the NAND are documented on the [[NAND]] page.<br />
<br />
Datasheet: [http://www.reinerziegler.de/ique/ds_k9f1208u0m.pdf]<br />
<br />
== DOOKIE ==<br />
The DOOKIE board is very basic, and it contains the NAND flash, a few capacitors, and an edge connector to connect with an [[iQue Player]]. The connector has a 1.1mm pitch and seems to be custom made. No other commonly-available connector appears to fit in it except the MicroSD.<br />
<br />
== Pinout ==<br />
[[File:Card_pin_numbers.png|thumb|Pin numbers for the '''iQue Card'''.]]<br />
<br />
{| class="wikitable"<br />
|-<br />
! Pin #<br />
! Name<br />
! Function<br />
|-<br />
| 1 || GND || Power<br />
|-<br />
| 2 || /WP || Write Protect<br />
|-<br />
| 3 || /WE || Write Enable<br />
|-<br />
| 4 || ALE || Address Latch Enable<br />
|-<br />
| 5 || CLE || Command Latch Enable<br />
|-<br />
| 6 || VCC || Power (3.3v)<br />
|-<br />
| 7 || /CE || Chip Enable<br />
|-<br />
| 8 || /RE || Read Enable<br />
|-<br />
| 9 || R/B || Read/Busy<br />
|-<br />
| 10 || N/C || Not Connected<br />
|-<br />
| 11 || N/C || Not Connected<br />
|-<br />
| 12 || IO7 || Data Input/Output 7<br />
|-<br />
| 13 || IO6 || Data Input/Output 6<br />
|-<br />
| 14 || IO5 || Data Input/Output 5<br />
|-<br />
| 15 || IO4 || Data Input/Output 4<br />
|-<br />
| 16 || GND || Power<br />
|-<br />
| 17 || VCC || Power (3.3v)<br />
|-<br />
| 18 || IO3 || Data Input/Output 3<br />
|-<br />
| 19 || IO2 || Data Input/Output 2<br />
|-<br />
| 20 || IO1 || Data Input/Output 1<br />
|-<br />
| 21 || IO0 || Data Input/Output 0<br />
|-<br />
| 22 || GND || Power<br />
|}<br />
<br />
[[Category:Hardware]]</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=File:Card_pin_numbers.png&diff=1405
File:Card pin numbers.png
2021-07-19T05:27:28Z
<p>Stuckpixel: iQue card edge pin numbers</p>
<hr />
<div>== Summary ==<br />
iQue card edge pin numbers</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1404
IO
2021-07-08T05:44:53Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_OUT || output of current PI DMA operation; used for NAND, AES and the PI_EX_READ\WRITE operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1403
IO
2021-07-07T17:09:27Z
<p>Stuckpixel: PI_AES_DATA_OUT -> PI_EX_DMA_OUT</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x400 || PI_EX_DMA_OUT || output of current PI DMA operation; used for NAND, AES and the PI_EX_(READ|WRITE) operations<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1402
IO
2021-07-07T17:07:09Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the bottom 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1401
IO
2021-07-07T17:03:45Z
<p>Stuckpixel: /* PI_ALLOWED_IO */</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]. Only the first 8 bits of this field are used for this register<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1400
IO
2021-07-07T17:01:14Z
<p>Stuckpixel: /* PI_ALLOWED_IO */</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || PI_ALLOWED_IO || Allows/disallows access to new PI features. This register is set by SK using the hwAccessRights field of the [[CMD]]<br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1399
IO
2021-07-04T03:03:00Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA busy.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || || Feature bitmask? <br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1398
IO
2021-07-04T03:00:14Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || bit 31: NAND (maybe other sources?) DMA complete.<br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || || Feature bitmask? <br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=Memory_Map&diff=1397
Memory Map
2021-06-27T23:45:27Z
<p>Stuckpixel: Create Memory Map</p>
<hr />
<div>{| class="wikitable" border="1"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
|-<br />
| 0x80000000<br />
| 0x00800000<br />
| DRAM<br />
|-<br />
| 0x9FC00000<br />
|?<br />
| Secure RAM<br />
|-<br />
| 0xA4300000<br />
| ?<br />
| [[IO]]<br />
|-<br />
| 0xBFC20000<br />
| 0x00002000<br />
| [[bootrom]]<br />
|-<br />
| 0xBFC80000<br />
| ?<br />
| Virage 0 [[Virage0-1]]<br />
|-<br />
| 0xBFC90000<br />
| ?<br />
| Virage 1 [[Virage0-1]]<br />
|-<br />
| 0xBFCA0000<br />
| 0x00000100<br />
| [[Virage2]]<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=Main_Page&diff=1376
Main Page
2020-02-02T21:22:00Z
<p>Stuckpixel: Reverted edits by Helloitsme (talk) to last revision by Normmatt</p>
<hr />
<div>{{:Main Page/Header}}<br />
{{:Main Page/Navigation}}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1151
IO
2020-01-30T04:50:19Z
<p>Stuckpixel: this isn't just a status bit, it's a control bit.</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || || Feature bitmask? <br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power control<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=Libultra_Boot_Parameters&diff=1134
Libultra Boot Parameters
2020-01-29T18:12:01Z
<p>Stuckpixel: fix inverted condition</p>
<hr />
<div>Parameters set by the SA before booting a game. BB's modified libultra uses these values at runtime.<br />
<br />
= Used by both N64 and BB =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0x800001a0|| 4 || leoBootID || not used on iQue, related to 64DD (which has codename Leo)<br />
|-<br />
| 0x80000300|| 4 || osTvType || 0: PAL, 1: NTSC, 2: MPAL<br />
|-<br />
| 0x80000304|| 4 || osRomType|| Determines if cartridge boot, or 64DD boot<br />
|-<br />
| 0x80000308|| 4 || osRomBase || Base uncached address of cartridge (PI) region<br />
|-<br />
| 0x8000030c || 4 || osResetType || Whether the system was cold-booted (0) or warm-resetted NMI (1). <br>On iQue, this may be fixed one way or the another because all games are soft-booted.<br />
|-<br />
| 0x80000310|| 4 || osCicId || Contains result of PIF<>CIC interaction. Value on iQue is not yet known. Rareware games like to check this value. <br>Depending on the CIC it may have the decimal number of CIC used, such as 0x17D9 (6105).<br>Note that 6106 games will use the value 6104 (on N64).<br />
|-<br />
| 0x80000314|| 4 || osVersion || Some version info created in N64 boot process. Unknown on iQue.<br />
|-<br />
| 0x80000318 || 4 || osMemSize || Contains number of bytes of physical memory installed. Games that check for expansion pak look at this value.<br />
|-<br />
| 0x8000031c|| 64 || osAppNMIBuffer || Buffer where application can put persistent information that is guaranteed not to be disturbed by a warm reset. <br>Unknown behavior on iQue.<br />
|}<br />
<br />
= Used only by BB =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0x8000035c || 4 || __osBbEepromAddress || <br />
|-<br />
| 0x80000360 || 4 || __osBbEepromSize ||<br />
|-<br />
| 0x80000364 || 4 || __osBbFlashAddress ||<br />
|-<br />
| 0x80000368 || 4 || __osBbFlashSize ||<br />
|-<br />
| 0x8000036c || 4 || __osBbSramAddress ||<br />
|-<br />
| 0x80000370 || 4 || __osBbSramSize ||<br />
|-<br />
| 0x80000374 || 16 || __osBbPakAddress || Array of 4 u32 pointers<br />
|-<br />
| 0x80000384 || 4 || __osBbPakSize ||<br />
|-<br />
| 0x80000388 || 4 || __osBbIsBb || Can be used to determine if running on vanilla N64, or BB.<br><br />
0: if (*0xa430003c & 0x140)==0<br><br />
1: if (*0xa430003c & 0x140)!=0<br><br />
2: if ((*0xa430003c & 0x140)!=0) && ((*0xa4600060) & 0xc0000000)!=0<br />
|-<br />
| 0x8000038c || 4 || __osBbHackFlags ||<br />
|-<br />
| 0x80000390 || 4 || __osBbStashMagic ||<br />
|-<br />
| 0x80000394 || 16 || __osBbPakBindings || Array of 4 u32 pointers<br />
|-<br />
| 0x800003a4 || 16 || __osBbStateName ||<br />
|-<br />
| 0x800003b4 || 4 || __osBbStateDirty ||<br />
|-<br />
| 0x800003b8 || 4 || __osBbAuxDataLimit ||<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1005
IO
2020-01-23T17:40:02Z
<p>Stuckpixel: Add AES engine info</p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || PI_AES_CNT(?) || Seems to be used for controlling the AES hardware. Bit31: start/busy<br />
|-<br />
| 0xA4600054 || 4 || || Feature bitmask? <br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 0x200 || PI_AES_DATA_OUT || output of current AES operation<br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 0xB0 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 0x10 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power status (on or off)<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=Virage0-1&diff=1004
Virage0-1
2019-10-16T07:31:03Z
<p>Stuckpixel: </p>
<hr />
<div>Virage0 and Virage1 are two 4K EEPROM banks located inside the SoC that can only be read in secure mode.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0x00 || 0x01 || tsCrlVersion || Seems to be always 0x00<br />
|-<br />
| 0x01 || 0x01 || caCrlVersion || Seems to be always 0x00<br />
|-<br />
| 0x02 || 0x01 || cpCrlVersion || Seems to be always 0x01<br />
|-<br />
| 0x03 || 0x01 || contentRlVersion || Seems to be always 0x00<br />
|-<br />
| 0x04 || 0x02 || ticketRlVersion || Seems to be always 0x0000<br />
|-<br />
| 0x06 || 0x02 || tidWindow || Seems to be always 0x001A<br />
|-<br />
| 0x08 || 0x2 * 0x1A || cc || Play-time (600 minutes = 0x0258)<br />
|-<br />
| 0x3C || 0x02 || seq || CRC<br />
|-<br />
| 0x3E || 0x02 || sum || CRC<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1003
IO
2019-10-13T02:08:22Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within non-secure mode causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || ||<br />
|-<br />
| 0xA4600054 || 4 || || Feature bitmask? <br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 4 || || <br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power status (on or off)<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=1002
IO
2019-10-13T02:06:45Z
<p>Stuckpixel: </p>
<hr />
<div>Memory mapped registers available on the iQue Player.<br />
<br />
= MI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300000 || 4 || MI_INIT_MODE_REG/MI_MODE_REG ||<br />
|-<br />
| 0xA4300004 || 4 || MI_VERSION_REG/MI_NOOP_REG ||<br />
|-<br />
| 0xA4300008 || 4 || MI_INTR_REG ||<br />
|-<br />
| 0xA430000C || 4 || MI_INTR_MASK_REG ||<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4 || MI_SK_EXCEPTION_REG || Reading from this address within game code causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = Watchdog Timer timeout, bit 2 = SKC.<br />
|-<br />
| 0xA4300018 || 4 || MI_SK_WATCHDOG_TIMER || Set to 0x7530c800 by SK to start or reset the timer. The bottom 16 bits appear to be the number of timer ticks to wait before an interrupt is fired, and bit 3 of MI_SK_EXCEPTION_REG is set. When reading from this register while the timer is ticking, the top 16 bits appear to be the remaining number of ticks until the interrupt fires. This is mainly used by SK to deal with trial/demo games. The timer is reset by SK when skKeepAlive is called. Depending on the trial type (timed vs number of launches), this timer is either used to detect a game crash or other event which would cause skKeepAlive calls to stop being made, or for timed trials, to keep track of the remaining time on the trial. One tick appears to happen every 1.220703 milliseconds with the configuration SK sets. Other tick rates and behaviors maybe be configurable, but it is unknown at this time if that is the case.<br />
|-<br />
| 0xA4300028 || 4 || ||<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4 || ||<br />
|-<br />
| 0xA4300038 || 4 || MI_HW_INTR_REG || Hardware interrupts (0x40 = NAND DMA, 0x80 = MD, 0x100 = RDB, 0x200 = AES, 0x400 = PI_ERR, 0x800 = USB0, 0x1000 = USB1, 0x2000 = NAND).<br />
|-<br />
| 0xA430003C || 4 || MI_HW_INTR_MASK_REG || Hardware interrupt mask.<br />
|}<br />
<br />
= VI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4400000 || 4 || VI_STATUS_REG/VI_CONTROL_REG || If bit 13 is set (normally documented as unused/reserved), the console will display corrupted graphics. N64 games usually (always?) have this bit set, which is the cause of corrupted graphics seen when vanilla N64 games are played on an iQue Player.<br />
|-<br />
| 0xA4400004 || 4 || VI_ORIGIN_REG/VI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4400008 || 4 || VI_WIDTH_REG/VI_H_WIDTH_REG || <br />
|-<br />
| 0xA440000C || 4 || VI_INTR_REG/VI_V_INTR_REG || <br />
|-<br />
| 0xA4400010 || 4 || VI_CURRENT_REG/VI_V_CURRENT_LINE_REG || <br />
|-<br />
| 0xA4400014 || 4 || VI_BURST_REG/VI_TIMING_REG || <br />
|-<br />
| 0xA4400018 || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA440001C || 4 || VI_V_SYNC_REG || <br />
|-<br />
| 0xA4400020 || 4 || VI_LEAP_REG/VI_H_SYNC_LEAP_REG || <br />
|-<br />
| 0xA4400024 || 4 || VI_H_START_REG/VI_H_VIDEO_REG ||<br />
|-<br />
| 0xA4400028 || 4 || VI_V_START_REG/VI_V_VIDEO_REG ||<br />
|-<br />
| 0xA440002C || 4 || VI_V_BURST_REG ||<br />
|-<br />
| 0xA4400030 || 4 || VI_X_SCALE_REG ||<br />
|-<br />
| 0xA4400034 || 4 || VI_Y_SCALE_REG ||<br />
|}<br />
<br />
= AI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4500000 || 4 || AI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4500004 || 4 || AI_LEN_REG || <br />
|-<br />
| 0xA4500008 || 4 || AI_CONTROL_REG || <br />
|-<br />
| 0xA450000C || 4 || AI_STATUS_REG || <br />
|-<br />
| 0xA4500010 || 4 || AI_DACRATE_REG || <br />
|-<br />
| 0xA4500014 || 4 || AI_BITRATE_REG ||<br />
|}<br />
<br />
= PI =<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4600000 || 4 || PI_DRAM_ADDR_REG || <br />
|-<br />
| 0xA4600004 || 4 || PI_CART_ADDR_REG || <br />
|-<br />
| 0xA4600008 || 4 || PI_RD_LEN_REG || <br />
|-<br />
| 0xA460000C || 4 || PI_WR_LEN_REG || <br />
|-<br />
| 0xA4600010 || 4 || PI_STATUS_REG || <br />
|-<br />
| 0xA4600014 || 4 || PI_BSD_DOM1_LAT_REG || <br />
|-<br />
| 0xA4600018 || 4 || PI_BSD_DOM1_PWD_REG || <br />
|-<br />
| 0xA460001C || 4 || PI_BSD_DOM1_PGS_REG || <br />
|-<br />
| 0xA4600020 || 4 || PI_BSD_DOM1_RLS_REG || <br />
|-<br />
| 0xA4600024 || 4 || PI_BSD_DOM2_LAT_REG ||<br />
|-<br />
| 0xA4600028 || 4 || PI_BSD_DOM2_PWD_REG ||<br />
|-<br />
| 0xA460002C || 4 || PI_BSD_DOM2_PGS_REG ||<br />
|-<br />
| 0xA4600030 || 4 || PI_BSD_DOM2_RLS_REG ||<br />
|-<br />
| 0xA4600038 || 4 || PI_CARD_STATUS_REG || Tells if the NAND card is present or not<br />
|-<br />
| 0xA4600040 || 4 || ||<br />
|-<br />
| 0xA4600044 || 4 || ||<br />
|-<br />
| 0xA4600048 || 4 || PI_CARD_ADDR_REG || Takes the device buffer address for RAM<->NAND DMA<br />
|-<br />
| 0xA460004C || 4 || PI_CARD_CONFIG_REG || Takes configuration parameters for the NAND card<br />
|-<br />
| 0xA4600050 || 4 || ||<br />
|-<br />
| 0xA4600054 || 4 || || Feature bitmask? <br />
|-<br />
| 0xA4600058 || 4 || PI_EX_RD_LEN_REG || Enhanced PI read length register<br />
|-<br />
| 0xA460005C || 4 || PI_EX_WR_LEN_REG || Enhanced PI write length register<br />
|-<br />
| 0xA4600060 || 4 || [[#PI_MISC_REG|PI_MISC_REG]] || This register is used for RTC, error led, power and more<br />
|-<br />
| 0xA4600070 || 4 || PI_CARD_BLK_OFFSET_REG || Takes the NAND card block offset for reading/writing<br />
|-<br />
| 0xA4610000 || 4 || || <br />
|-<br />
| 0xA4610200 || 4 || ||<br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || || ATB?<br />
|-<br />
| 0xA4610504 || 4 || || ATB?<br />
|-<br />
| 0xA4620000 || 4 || ||<br />
|-<br />
| 0xA46E0000 || 2 || PI_RDB_REQ_HI_REG ||<br />
|-<br />
| 0xA46E0002 || 2 || PI_RDB_REQ_LO_REG ||<br />
|-<br />
| 0xA46E0004 || 2 || ||<br />
|-<br />
| 0xA46E0400 || 2 || || RDB related<br />
|-<br />
| 0xA46E0402 || 2 || || RDB related<br />
|-<br />
| 0xA46E8000 || 2 || PI_RDB_STATUS_REG ||<br />
|}<br />
<br />
== PI_MISC_REG ==<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| 31-15 || Box Id<br />
|-<br />
| 6-7 || RTC mask<br />
|-<br />
| 5 || Error led mask (always 0x01)<br />
|-<br />
| 4 || Power mask (always 0x01)<br />
|-<br />
| 2-3 || RTC status<br />
|-<br />
| 1 || Error led<br />
|-<br />
| 0 || Power status (on or off)<br />
|}<br />
<br />
= USB =<br />
The iQue Player has support for two USB controllers, one mapped at 0xA4900000 and another at 0xA4A00000.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4900000 || 4 || || <br />
|-<br />
| 0xA4940010 || 4 || USB0_STATUS_REG || <br />
|-<br />
| 0xA4A00000 || 4 || || <br />
|-<br />
| 0xA4A40010 || 4 || USB1_STATUS_REG || <br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=CMD&diff=964
CMD
2019-02-04T09:32:00Z
<p>Stuckpixel: Actually link to IA8</p>
<hr />
<div>A '''content metadata''' or '''CMD''' is a file or structure used to store data about an iQue app, such as encryption keys, its access to secure kernel calls, and its access to various hardware. It is used on its own in [[SKSA]] (where SA1 and SA2 both have their own attached CMD) and also contained as part of every [[ticket]]. <br />
<br />
== Format ==<br />
A CMD consists of two parts: '''contentDesc''', an optional 0x2800-byte long structure containing information about a game such as its save type, title, and thumbnail image; and '''BbContentMetaDataHead'''. The former is not used in the content metadata for SAs.<br />
<br />
=== contentDesc ===<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Length<br />
! Type<br />
! Information<br />
|-<br />
| 0x00<br />
| 0x04<br />
| uint32<br />
| EEPROM RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x04<br />
| 0x04<br />
| uint32<br />
| EEPROM size (either 0x200 or 0x800)<br />
|-<br />
| 0x08<br />
| 0x04<br />
| uint32<br />
| Flash RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x0C<br />
| 0x04<br />
| uint32<br />
| Flash size (0x20000 if used)<br />
|-<br />
| 0x10<br />
| 0x04<br />
| uint32<br />
| SRAM RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x14<br />
| 0x04<br />
| uint32<br />
| SRAM size (0x8000 if used)<br />
|-<br />
| 0x18<br />
| 0x04<br />
| uint32<br />
| Controller Pak 0 RDRAM location (could be 0x807C0000 or 0x807C0000, 0 if unused)<br />
|-<br />
| 0x1C<br />
| 0x04<br />
| uint32<br />
| Controller Pak 1 RDRAM location (0 if unused)<br />
|-<br />
| 0x20<br />
| 0x04<br />
| uint32<br />
| Controller Pak 2 RDRAM location (0 if unused)<br />
|-<br />
| 0x24<br />
| 0x04<br />
| uint32<br />
| Controller Pak 3 RDRAM location (0 if unused)<br />
|-<br />
| 0x28<br />
| 0x04<br />
| uint32<br />
| Controller Pak size (0x8000 when used)<br />
|-<br />
| 0x2C<br />
| 0x04<br />
| uint32<br />
| Probably osRomBase (always 0xB0000000?)<br />
|-<br />
| 0x30<br />
| 0x04<br />
| uint32<br />
| Probably osTvType (always 1? which is for NTSC)<br />
|-<br />
| 0x34<br />
| 0x04<br />
| uint32<br />
| Probably osMemSize (always 0x400000? for no expansion pak)<br />
|-<br />
| 0x38<br />
| 0x04<br />
| uint32<br />
| Unknown, possibly another libultra boot param<br />
|-<br />
| 0x3C<br />
| 0x04<br />
| uint32<br />
| Unknown, possibly another libultra boot param<br />
|-<br />
| 0x40<br />
| 0x03<br />
| chars<br />
| "CAM", unknown purpose<br />
|-<br />
| 0x43<br />
| 0x01<br />
| byte<br />
| Number of ".u0x" files for this game?<br />
|-<br />
| 0x44<br />
| 0x02<br />
| uint16<br />
| Thumb image length (can't be more than 0x4000, decompressed size must be exactly 0x1880)<br />
|-<br />
| 0x46<br />
| 0x02<br />
| uint16<br />
| Title image length (can't be more than 0x10000, how exactly would that even fit?)<br />
|-<br />
| 0x48<br />
| ''Thumb image length''<br />
| bytes<br />
| DEFLATE-compressed thumb image, stored as RGBA5551 (56w * 56h)<br />
|-<br />
| 0x48 + ''Thumb image length''<br />
| ''Title image length''<br />
| bytes<br />
| DEFLATE-compressed title image, stored as [http://wiki.tockdom.com/wiki/Image_Formats#IA8 IA8] (184w * 24h)<br />
|-<br />
| 0x48 + ''Thumb image length'' + ''Title image length''<br />
| 0x27B8 - image lengths<br />
| chars<br />
| Title name + ISBN<br />
|}<br />
<br />
=== BbContentMetaDataHead ===<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Length<br />
! Type<br />
! Description<br />
! Information<br />
|-<br />
| 0x2800<br />
| 0x04<br />
| uint32<br />
| unusedPadding<br />
| padding<br />
|-<br />
| 0x2804<br />
| 0x04<br />
| uint32<br />
| caCrlVersion<br />
| Certificate Authority(?) CRL version<br />
|-<br />
| 0x2808<br />
| 0x04<br />
| uint32<br />
| cpCrlVersion<br />
| Content Protection(?) CRL version<br />
|-<br />
| 0x280C<br />
| 0x04<br />
| uint32<br />
| size<br />
| Size (in bytes) of the associated app<br />
|-<br />
| 0x2810<br />
| 0x04<br />
| uint32<br />
| descFlags<br />
| Seemingly unused/unchecked; bit 0 set if the associated app is SA <br />
|-<br />
| 0x2814<br />
| 0x10<br />
| uint8[16]<br />
| commonCmdIv<br />
| titlekey_iv; IV used to encrypt title key (with common key) <br />
|-<br />
| 0x2824<br />
| 0x14<br />
| uint8[20]<br />
| hash<br />
| SHA-1 hash of the plaintext of the associated app<br />
|-<br />
| 0x2838<br />
| 0x10<br />
| uint8[16]<br />
| iv<br />
| content_iv; IV used to encrypt content<br />
|-<br />
| 0x2848<br />
| 0x04<br />
| uint32<br />
| execFlags<br />
| Despite the name, only one use/flag is known: if bit 1 is set (the "recrypt flag"), the associated app will be re-encrypted on first launch<br />
|-<br />
| 0x284C<br />
| 0x04<br />
| uint32<br />
| hwAccessRights<br />
| bitfield, each bit enables access to some MMIO regs new to iQue Player:<br />
* bits 0-7: new PI stuff <br />
* bit 0: PI buffer used for aes/NAND read output and PI DMA (1KB at PI_BASE+0x10000) <br />
* bit 1: NAND flash regs in PI <br />
* bit 2: memory mapper for old PI dma <br />
* bit 3: hardware AES-engine in PI<br />
* bit 4: new PI dma engine, DMAs from/to PI buffer<br />
* bit 5: new GPIO; power + LED<br />
* bit 6: external IO bus stuff (debug?)<br />
* bit 7: new PI error stuff<br />
* bit 8: enables access to USB regs<br />
* bit 9: enables access to internal ram used for SK stack <br />
(0x0000 for games except for Animal Forest which is 0x0033, 0x0013 for iQue Club, 0x01F7/0x01B3 for SA)<br />
|-<br />
| 0x2850<br />
| 0x04<br />
| uint32<br />
| secureKernelRights<br />
| Which [[SKC|secure kernel calls]] the associated app can use, one bit per syscall: bit 0 allows SKC 0, etc.<br />
|-<br />
| 0x2854<br />
| 0x04<br />
| uint32<br />
| bbid<br />
| If not zero, can only be run on the specified console (used for SAs, not games) <br />
|-<br />
| 0x2858<br />
| 0x40<br />
| uint8[64]<br />
| issuer<br />
| Certificate used to sign the cmd<br />
|-<br />
| 0x2898<br />
| 0x04<br />
| uint32<br />
| id<br />
| Content ID of the associated app<br />
|-<br />
| 0x289C<br />
| 0x10<br />
| uint8[16]<br />
| key<br />
| The associated app's title key. It is encrypted once with the common key. If the associated app is not an SA, then it is encrypted ''again'' with a key derived using the result of ECDH with the console's private key in the Virage2 and the public key in the app's ticket.<br />
|-<br />
| 0x28AC<br />
| 0x100<br />
| uint8[256]<br />
| contentMetaDataSign<br />
| RSA-2048 signature over all of the above, but before the title key is encrypted a second time.<br />
|}<br />
<br />
[[Category:File formats]]</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=CMD&diff=963
CMD
2019-02-04T09:30:23Z
<p>Stuckpixel: Link to IA8 format</p>
<hr />
<div>A '''content metadata''' or '''CMD''' is a file or structure used to store data about an iQue app, such as encryption keys, its access to secure kernel calls, and its access to various hardware. It is used on its own in [[SKSA]] (where SA1 and SA2 both have their own attached CMD) and also contained as part of every [[ticket]]. <br />
<br />
== Format ==<br />
A CMD consists of two parts: '''contentDesc''', an optional 0x2800-byte long structure containing information about a game such as its save type, title, and thumbnail image; and '''BbContentMetaDataHead'''. The former is not used in the content metadata for SAs.<br />
<br />
=== contentDesc ===<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Length<br />
! Type<br />
! Information<br />
|-<br />
| 0x00<br />
| 0x04<br />
| uint32<br />
| EEPROM RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x04<br />
| 0x04<br />
| uint32<br />
| EEPROM size (either 0x200 or 0x800)<br />
|-<br />
| 0x08<br />
| 0x04<br />
| uint32<br />
| Flash RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x0C<br />
| 0x04<br />
| uint32<br />
| Flash size (0x20000 if used)<br />
|-<br />
| 0x10<br />
| 0x04<br />
| uint32<br />
| SRAM RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x14<br />
| 0x04<br />
| uint32<br />
| SRAM size (0x8000 if used)<br />
|-<br />
| 0x18<br />
| 0x04<br />
| uint32<br />
| Controller Pak 0 RDRAM location (could be 0x807C0000 or 0x807C0000, 0 if unused)<br />
|-<br />
| 0x1C<br />
| 0x04<br />
| uint32<br />
| Controller Pak 1 RDRAM location (0 if unused)<br />
|-<br />
| 0x20<br />
| 0x04<br />
| uint32<br />
| Controller Pak 2 RDRAM location (0 if unused)<br />
|-<br />
| 0x24<br />
| 0x04<br />
| uint32<br />
| Controller Pak 3 RDRAM location (0 if unused)<br />
|-<br />
| 0x28<br />
| 0x04<br />
| uint32<br />
| Controller Pak size (0x8000 when used)<br />
|-<br />
| 0x2C<br />
| 0x04<br />
| uint32<br />
| Probably osRomBase (always 0xB0000000?)<br />
|-<br />
| 0x30<br />
| 0x04<br />
| uint32<br />
| Probably osTvType (always 1? which is for NTSC)<br />
|-<br />
| 0x34<br />
| 0x04<br />
| uint32<br />
| Probably osMemSize (always 0x400000? for no expansion pak)<br />
|-<br />
| 0x38<br />
| 0x04<br />
| uint32<br />
| Unknown, possibly another libultra boot param<br />
|-<br />
| 0x3C<br />
| 0x04<br />
| uint32<br />
| Unknown, possibly another libultra boot param<br />
|-<br />
| 0x40<br />
| 0x03<br />
| chars<br />
| "CAM", unknown purpose<br />
|-<br />
| 0x43<br />
| 0x01<br />
| byte<br />
| Number of ".u0x" files for this game?<br />
|-<br />
| 0x44<br />
| 0x02<br />
| uint16<br />
| Thumb image length (can't be more than 0x4000, decompressed size must be exactly 0x1880)<br />
|-<br />
| 0x46<br />
| 0x02<br />
| uint16<br />
| Title image length (can't be more than 0x10000, how exactly would that even fit?)<br />
|-<br />
| 0x48<br />
| ''Thumb image length''<br />
| bytes<br />
| DEFLATE-compressed thumb image, stored as RGBA5551 (56w * 56h)<br />
|-<br />
| 0x48 + ''Thumb image length''<br />
| ''Title image length''<br />
| bytes<br />
| DEFLATE-compressed title image, stored as [http://wiki.tockdom.com/wiki/Image_Formats#I8 IA8] (184w * 24h)<br />
|-<br />
| 0x48 + ''Thumb image length'' + ''Title image length''<br />
| 0x27B8 - image lengths<br />
| chars<br />
| Title name + ISBN<br />
|}<br />
<br />
=== BbContentMetaDataHead ===<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Length<br />
! Type<br />
! Description<br />
! Information<br />
|-<br />
| 0x2800<br />
| 0x04<br />
| uint32<br />
| unusedPadding<br />
| padding<br />
|-<br />
| 0x2804<br />
| 0x04<br />
| uint32<br />
| caCrlVersion<br />
| Certificate Authority(?) CRL version<br />
|-<br />
| 0x2808<br />
| 0x04<br />
| uint32<br />
| cpCrlVersion<br />
| Content Protection(?) CRL version<br />
|-<br />
| 0x280C<br />
| 0x04<br />
| uint32<br />
| size<br />
| Size (in bytes) of the associated app<br />
|-<br />
| 0x2810<br />
| 0x04<br />
| uint32<br />
| descFlags<br />
| Seemingly unused/unchecked; bit 0 set if the associated app is SA <br />
|-<br />
| 0x2814<br />
| 0x10<br />
| uint8[16]<br />
| commonCmdIv<br />
| titlekey_iv; IV used to encrypt title key (with common key) <br />
|-<br />
| 0x2824<br />
| 0x14<br />
| uint8[20]<br />
| hash<br />
| SHA-1 hash of the plaintext of the associated app<br />
|-<br />
| 0x2838<br />
| 0x10<br />
| uint8[16]<br />
| iv<br />
| content_iv; IV used to encrypt content<br />
|-<br />
| 0x2848<br />
| 0x04<br />
| uint32<br />
| execFlags<br />
| Despite the name, only one use/flag is known: if bit 1 is set (the "recrypt flag"), the associated app will be re-encrypted on first launch<br />
|-<br />
| 0x284C<br />
| 0x04<br />
| uint32<br />
| hwAccessRights<br />
| bitfield, each bit enables access to some MMIO regs new to iQue Player:<br />
* bits 0-7: new PI stuff <br />
* bit 0: PI buffer used for aes/NAND read output and PI DMA (1KB at PI_BASE+0x10000) <br />
* bit 1: NAND flash regs in PI <br />
* bit 2: memory mapper for old PI dma <br />
* bit 3: hardware AES-engine in PI<br />
* bit 4: new PI dma engine, DMAs from/to PI buffer<br />
* bit 5: new GPIO; power + LED<br />
* bit 6: external IO bus stuff (debug?)<br />
* bit 7: new PI error stuff<br />
* bit 8: enables access to USB regs<br />
* bit 9: enables access to internal ram used for SK stack <br />
(0x0000 for games except for Animal Forest which is 0x0033, 0x0013 for iQue Club, 0x01F7/0x01B3 for SA)<br />
|-<br />
| 0x2850<br />
| 0x04<br />
| uint32<br />
| secureKernelRights<br />
| Which [[SKC|secure kernel calls]] the associated app can use, one bit per syscall: bit 0 allows SKC 0, etc.<br />
|-<br />
| 0x2854<br />
| 0x04<br />
| uint32<br />
| bbid<br />
| If not zero, can only be run on the specified console (used for SAs, not games) <br />
|-<br />
| 0x2858<br />
| 0x40<br />
| uint8[64]<br />
| issuer<br />
| Certificate used to sign the cmd<br />
|-<br />
| 0x2898<br />
| 0x04<br />
| uint32<br />
| id<br />
| Content ID of the associated app<br />
|-<br />
| 0x289C<br />
| 0x10<br />
| uint8[16]<br />
| key<br />
| The associated app's title key. It is encrypted once with the common key. If the associated app is not an SA, then it is encrypted ''again'' with a key derived using the result of ECDH with the console's private key in the Virage2 and the public key in the app's ticket.<br />
|-<br />
| 0x28AC<br />
| 0x100<br />
| uint8[256]<br />
| contentMetaDataSign<br />
| RSA-2048 signature over all of the above, but before the title key is encrypted a second time.<br />
|}<br />
<br />
[[Category:File formats]]</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=CMD&diff=961
CMD
2019-02-04T08:27:12Z
<p>Stuckpixel: proper image format</p>
<hr />
<div>A '''content metadata''' or '''CMD''' is a file or structure used to store data about an iQue app, such as encryption keys, its access to secure kernel calls, and its access to various hardware. It is used on its own in [[SKSA]] (where SA1 and SA2 both have their own attached CMD) and also contained as part of every [[ticket]]. <br />
<br />
== Format ==<br />
A CMD consists of two parts: '''contentDesc''', an optional 0x2800-byte long structure containing information about a game such as its save type, title, and thumbnail image; and '''BbContentMetaDataHead'''. The former is not used in the content metadata for SAs.<br />
<br />
=== contentDesc ===<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Length<br />
! Type<br />
! Information<br />
|-<br />
| 0x00<br />
| 0x04<br />
| uint32<br />
| EEPROM RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x04<br />
| 0x04<br />
| uint32<br />
| EEPROM size (either 0x200 or 0x800)<br />
|-<br />
| 0x08<br />
| 0x04<br />
| uint32<br />
| Flash RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x0C<br />
| 0x04<br />
| uint32<br />
| Flash size (0x20000 if used)<br />
|-<br />
| 0x10<br />
| 0x04<br />
| uint32<br />
| SRAM RDRAM location (typically 0x807C0000, 0 if unused)<br />
|-<br />
| 0x14<br />
| 0x04<br />
| uint32<br />
| SRAM size (0x8000 if used)<br />
|-<br />
| 0x18<br />
| 0x04<br />
| uint32<br />
| Controller Pak 0 RDRAM location (could be 0x807C0000 or 0x807C0000, 0 if unused)<br />
|-<br />
| 0x1C<br />
| 0x04<br />
| uint32<br />
| Controller Pak 1 RDRAM location (0 if unused)<br />
|-<br />
| 0x20<br />
| 0x04<br />
| uint32<br />
| Controller Pak 2 RDRAM location (0 if unused)<br />
|-<br />
| 0x24<br />
| 0x04<br />
| uint32<br />
| Controller Pak 3 RDRAM location (0 if unused)<br />
|-<br />
| 0x28<br />
| 0x04<br />
| uint32<br />
| Controller Pak size (0x8000 when used)<br />
|-<br />
| 0x2C<br />
| 0x04<br />
| uint32<br />
| Probably osRomBase (always 0xB0000000?)<br />
|-<br />
| 0x30<br />
| 0x04<br />
| uint32<br />
| Probably osTvType (always 1? which is for NTSC)<br />
|-<br />
| 0x34<br />
| 0x04<br />
| uint32<br />
| Probably osMemSize (always 0x400000? for no expansion pak)<br />
|-<br />
| 0x38<br />
| 0x04<br />
| uint32<br />
| Unknown, possibly another libultra boot param<br />
|-<br />
| 0x3C<br />
| 0x04<br />
| uint32<br />
| Unknown, possibly another libultra boot param<br />
|-<br />
| 0x40<br />
| 0x03<br />
| chars<br />
| "CAM", unknown purpose<br />
|-<br />
| 0x43<br />
| 0x01<br />
| byte<br />
| Number of ".u0x" files for this game?<br />
|-<br />
| 0x44<br />
| 0x02<br />
| uint16<br />
| Thumb image length (can't be more than 0x4000, decompressed size must be exactly 0x1880)<br />
|-<br />
| 0x46<br />
| 0x02<br />
| uint16<br />
| Title image length (can't be more than 0x10000, how exactly would that even fit?)<br />
|-<br />
| 0x48<br />
| ''Thumb image length''<br />
| bytes<br />
| DEFLATE-compressed thumb image RGBA5551 (56px * 56px)<br />
|-<br />
| 0x48 + ''Thumb image length''<br />
| ''Title image length''<br />
| bytes<br />
| DEFLATE-compressed title image IA8 (184px * 24px)<br />
|-<br />
| 0x48 + ''Thumb image length'' + ''Title image length''<br />
| 0x27B8 - image lengths<br />
| chars<br />
| Title name + ISBN<br />
|}<br />
<br />
=== BbContentMetaDataHead ===<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Length<br />
! Type<br />
! Description<br />
! Information<br />
|-<br />
| 0x2800<br />
| 0x04<br />
| uint32<br />
| unusedPadding<br />
| padding<br />
|-<br />
| 0x2804<br />
| 0x04<br />
| uint32<br />
| caCrlVersion<br />
| Certificate Authority(?) CRL version<br />
|-<br />
| 0x2808<br />
| 0x04<br />
| uint32<br />
| cpCrlVersion<br />
| Content Protection(?) CRL version<br />
|-<br />
| 0x280C<br />
| 0x04<br />
| uint32<br />
| size<br />
| Size (in bytes) of the associated app<br />
|-<br />
| 0x2810<br />
| 0x04<br />
| uint32<br />
| descFlags<br />
| Seemingly unused/unchecked; bit 0 set if the associated app is SA <br />
|-<br />
| 0x2814<br />
| 0x10<br />
| uint8[16]<br />
| commonCmdIv<br />
| titlekey_iv; IV used to encrypt title key (with common key) <br />
|-<br />
| 0x2824<br />
| 0x14<br />
| uint8[20]<br />
| hash<br />
| SHA-1 hash of the plaintext of the associated app<br />
|-<br />
| 0x2838<br />
| 0x10<br />
| uint8[16]<br />
| iv<br />
| content_iv; IV used to encrypt content<br />
|-<br />
| 0x2848<br />
| 0x04<br />
| uint32<br />
| execFlags<br />
| Despite the name, only one use/flag is known: if bit 1 is set (the "recrypt flag"), the associated app will be re-encrypted on first launch<br />
|-<br />
| 0x284C<br />
| 0x04<br />
| uint32<br />
| hwAccessRights<br />
| bitfield, each bit enables access to some MMIO regs new to iQue Player:<br />
* bits 0-7: new PI stuff <br />
* bit 0: PI buffer used for aes/NAND read output and PI DMA (1KB at PI_BASE+0x10000) <br />
* bit 1: NAND flash regs in PI <br />
* bit 2: memory mapper for old PI dma <br />
* bit 3: hardware AES-engine in PI<br />
* bit 4: new PI dma engine, DMAs from/to PI buffer<br />
* bit 5: new GPIO; power + LED<br />
* bit 6: external IO bus stuff (debug?)<br />
* bit 7: new PI error stuff<br />
* bit 8: enables access to USB regs<br />
* bit 9: enables access to internal ram used for SK stack <br />
(0x0000 for games except for Animal Forest which is 0x0033, 0x0013 for iQue Club, 0x01F7/0x01B3 for SA)<br />
|-<br />
| 0x2850<br />
| 0x04<br />
| uint32<br />
| secureKernelRights<br />
| Which [[SKC|secure kernel calls]] the associated app can use, one bit per syscall: bit 0 allows SKC 0, etc.<br />
|-<br />
| 0x2854<br />
| 0x04<br />
| uint32<br />
| bbid<br />
| If not zero, can only be run on the specified console (used for SAs, not games) <br />
|-<br />
| 0x2858<br />
| 0x40<br />
| uint8[64]<br />
| issuer<br />
| Certificate used to sign the cmd<br />
|-<br />
| 0x2898<br />
| 0x04<br />
| uint32<br />
| id<br />
| Content ID of the associated app<br />
|-<br />
| 0x289C<br />
| 0x10<br />
| uint8[16]<br />
| key<br />
| The associated app's title key. It is encrypted once with the common key. If the associated app is not an SA, then it is encrypted ''again'' with a key derived using the result of ECDH with the console's private key in the Virage2 and the public key in the app's ticket.<br />
|-<br />
| 0x28AC<br />
| 0x100<br />
| uint8[256]<br />
| contentMetaDataSign<br />
| RSA-2048 signature over all of the above, but before the title key is encrypted a second time.<br />
|}<br />
<br />
[[Category:File formats]]</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=SKC&diff=898
SKC
2018-07-10T06:58:03Z
<p>Stuckpixel: /* Secure Kernel calls */</p>
<hr />
<div>= Secure Kernel calls =<br />
All secure kernel calls return a s32 error code in $v0. 0 means success, below zero means error.<br />
<br />
{| class=wikitable<br />
! Id || Name || Arguments<br />
|-<br />
| 0x0 || skGetId || $a0=u32* out_bbid<br />
|-<br />
| 0x1 || skLaunchSetup || $a0=[[Ticket|BbTicket]]** ticket, $a1=???, $a2=u8* recrypt_list<br />
|-<br />
| 0x2 || skLaunch || $a0=u8* decrypted_content<br />
|-<br />
| 0x3 || skRecryptListValid || $a0=u8* recrypt_list<br />
|-<br />
| 0x4 || skRecryptBegin || $a0=???, $a1=???, $a2=???<br />
|-<br />
| 0x5 || skRecryptData || $a0=u8* buf, $a1=u32 size<br />
|-<br />
| 0x6 || skRecryptComputeState || $a0=u8* buf, $a1=u32 size<br />
|-<br />
| 0x7 || skRecryptEnd || $a0=u8* buf<br />
|-<br />
| 0x8 || skSignHash || $a0=u8* sha1hash, $a1=u8* out_signature<br />
|-<br />
| 0x9 || skVerifyHash || $a0=u8* sha1hash, $a1=u8* signature, $a2=certificate** certificate_chain, $a3=crl** crls?<br />
|-<br />
| 0xA || skGetConsumption || $a0=u8* out_size_buf, $a1=u8* out_buf<br />
|-<br />
| 0xB || skAdvanceTicketWindow || void<br />
|-<br />
| 0xC || skSetLimit || $a0=u16 limit_low?, $a1=u16 limit_high?<br />
|-<br />
| 0xD || skExit || void<br />
|-<br />
| 0xE || skKeepAlive || void<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=Bootrom&diff=895
Bootrom
2018-07-04T02:20:05Z
<p>Stuckpixel: Created page with "{{DISPLAYTITLE:Bootrom}} The bootrom is located at 0xBFC20000 and is 0x2000 bytes large. The bootrom is largely made up of NAND reading, aes decryption and sha1 hashing code...."</p>
<hr />
<div>{{DISPLAYTITLE:Bootrom}}<br />
The bootrom is located at 0xBFC20000 and is 0x2000 bytes large. The bootrom is largely made up of NAND reading, aes decryption and sha1 hashing code. Its primary function is to load the Secure Kernel from NAND, decrypt it, hash it and compare the hash, before jumping to it. It compares the hash against the hash stored in [[Virage2]]. The key and IV used to decrypt SK are located within the bootrom, the key being at offset 0x1460 and the IV being at 0x1470.</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=SKC&diff=889
SKC
2018-06-17T05:26:57Z
<p>Stuckpixel: oops</p>
<hr />
<div>= Secure Kernel calls =<br />
All secure kernel calls return a s32 error code in $v0. 0 means success, below zero means error.<br />
<br />
{| class=wikitable<br />
! Id || Name || Arguments<br />
|-<br />
| 0x0 || skGetId || $a0=u32* out_bbid<br />
|-<br />
| 0x1 || skLaunchSetup || $a0=[[Ticket|BbTicket]]** ticket, $a1=???, $a2=???<br />
|-<br />
| 0x2 || skLaunch || $a0=u8* decrypted_content<br />
|-<br />
| 0x3 || skRecryptListValid || $a0=u8* recrypt_list<br />
|-<br />
| 0x4 || skRecryptBegin || $a0=???, $a1=???, $a2=???<br />
|-<br />
| 0x5 || skRecryptData || $a0=u8* buf, $a1=u32 size<br />
|-<br />
| 0x6 || skRecryptComputeState || $a0=u8* buf, $a1=u32 size<br />
|-<br />
| 0x7 || skRecryptEnd || $a0=u8* buf<br />
|-<br />
| 0x8 || skSignHash || $a0=u8* sha1hash, $a1=u8* out_signature<br />
|-<br />
| 0x9 || skVerifyHash || $a0=u8* sha1hash, $a1=u8* signature, $a2=certificate** certificate_chain, $a3=crl** crls?<br />
|-<br />
| 0xA || skGetConsumption || $a0=u8* out_size_buf, $a1=u8* out_buf<br />
|-<br />
| 0xB || skAdvanceTicketWindow || void<br />
|-<br />
| 0xC || skSetLimit || $a0=u16 limit_low?, $a1=u16 limit_high?<br />
|-<br />
| 0xD || skExit || void<br />
|-<br />
| 0xE || skKeepAlive || void<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=SKC&diff=888
SKC
2018-06-17T05:05:01Z
<p>Stuckpixel: </p>
<hr />
<div>= Secure Kernel calls =<br />
All secure kernel calls return a s32 error code in $v0. 0 means success, below zero means error.<br />
<br />
{| class=wikitable<br />
! Id || Name || Arguments<br />
|-<br />
| 0x0 || skGetId || $a0=u32* out_bbid<br />
|-<br />
| 0x1 || skLaunchSetup || $a0=[[Ticket|BbTicket]]* ticket, $a1=???, $a2=???<br />
|-<br />
| 0x2 || skLaunch || $a0=u8* decrypted_content<br />
|-<br />
| 0x3 || skRecryptListValid || $a0=u8* recrypt_list<br />
|-<br />
| 0x4 || skRecryptBegin || $a0=???, $a1=???, $a2=???<br />
|-<br />
| 0x5 || skRecryptData || $a0=u8* buf, $a1=u32 size<br />
|-<br />
| 0x6 || skRecryptComputeState || $a0=u8* buf, $a1=u32 size<br />
|-<br />
| 0x7 || skRecryptEnd || $a0=u8* buf<br />
|-<br />
| 0x8 || skSignHash || $a0=u8* sha1hash, $a1=u8* out_signature<br />
|-<br />
| 0x9 || skVerifyHash || $a0=u8* sha1hash, $a1=u8* signature, $a2=certificate** certificate_chain, $a3=crl** crls?<br />
|-<br />
| 0xA || skGetConsumption || $a0=u8* out_size_buf, $a1=u8* out_buf<br />
|-<br />
| 0xB || skAdvanceTicketWindow || void<br />
|-<br />
| 0xC || skSetLimit || $a0=u16 limit_low?, $a1=u16 limit_high?<br />
|-<br />
| 0xD || skExit || void<br />
|-<br />
| 0xE || skKeepAlive || void<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IQue_Player_System_Flaws&diff=817
IQue Player System Flaws
2018-05-03T20:53:12Z
<p>Stuckpixel: fix small typo</p>
<hr />
<div>{{DISPLAYTITLE:iQue Player System Flaws}}<br />
==Hardware==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| No known hardware exploits <br />
|<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Secure Kernel==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| psychic paper: Secure Kernel could incorrectly consider a self-signed certificate chain as valid<br />
| The function for verifying certificate chains at <tt>0x9FC028BC</tt> is passed an array of pointers to certificates.<br />
For the first 5 elements, it checks to see if the certificate was issued by <tt>Root</tt>, if so it checks if the certificate was signed by the hardcoded <tt>Root</tt> public key (and returns immediately with the result).<br />
<br />
If the certificate wasn't signed by <tt>Root</tt>, it checks if the certificate was signed by the public key of the next certificate in the array.<br />
<br />
If all 5 certificates verified correctly, the function will return success.<br />
| Assuming this function can be called with an attacker-controlled array of certificates (this is possible, thanks to other (below) issues), self-signing of certificates (and thus, arbitrary code execution, with full non-Secure Mode privileges)<br />
(This is not the case for Secure Applications, the code in SK for verifying those sets up a hardcoded array on the stack for the certificate verification function)<br />
| April 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| skLaunchSetup and skRecryptBegin leave CMD in memory if its signature does not verify<br />
| The function called by skLaunchSetup (and skRecryptBegin) at <tt>0x9FC00BAC</tt> verifies ticket and CMD, and decrypts the titlekey.<br />
After verifying the ticket signature, it copies the CMD to another place in memory, derives the titlekey encryption key, decrypts the titlekey with the titlekek, then verifies the CMD signature.<br />
<br />
If the CMD signature does not verify successfully, the function just returns an error, leaving the unsigned CMD in place.<br />
<br />
Most of the code that uses a CMD in SK uses the CMD in that place in memory that this function copies the CMD to, and trusts that whatever data is there has been verified already.<br />
<br />
The entire CMD is covered by the ticket signature anyway, so this isn't that useful really, besides potentially making psychic paper easier to exploit.<br />
| With existing code execution with access to skLaunchSetup or skRecryptBegin and some other SKC that uses SK's internal CMD copy (only non-test SAs have this level of access), and the ability to sign a ticket but not a CMD:<br />
Allowing the use of an unsigned CMD by SK, potentially leading to privilege escalation (by specifying arbitrary allowed hardware access/allowed SKCs).<br />
| April 26, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| skLaunch does not check content hash if recrypt flag is set in CMD<br />
| skLaunch calculates the SHA1 hash of the content and compares it to the value in the CMD, returning an error if the hash doesn't match. This entire block of code is jumped over if the recrypt flag is set in the CMD.<br />
| With plaintext of an application with the recrypt flag set in its CMD, arbitrary code execution (via, for example, implementation of the attack described in pocorgtfo17)<br />
| Early 2018?<br />
| Everyone<br />
|-<br />
| skVerifyHash signature pointer not validated<br />
| skVerifyHash takes in a u8 pointer to a signature to verify, but does not actually validate this pointer is valid before treating the memory it points to as an RSA/ECC signature.<br />
| Causing the Secure Kernel to data abort -- possibly usable as an infoleak, depending on the provided cert chain<br />
| April 29, 2018<br />
| [[User:SciresM|SciresM]]<br />
|-<br />
| SK's ECDH implementation does no validation of the other party's public key<br />
| When deriving the titlekek using ECDH, SK does no validation whatsoever of the public key, which comes from the ticket. Because ECDH is just multiplication, passing in an all-zero public key would lead to an all-zero titlekek being used.<br />
| With the ability to sign a ticket and CMD (for example, psychic paper): causing SK to use a constant titlekek; no need to know a console's ECC keypair.<br />
| April 29, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| skRecryptData insufficient checks<br />
| skRecryptData allows for NULL to be passed in as a pointer, for supporting some alternate mode controlled by a u32 in SK .data.<br />
However, if this u32 is 0 (which is the default), no further checks are done and recrypt operations are done starting from NULL with provided length (in 0x400 chunks).<br />
<br />
Also, if skRecryptBegin wasn't called, the recrypt operation is done by decrypting using the current hardware AES engine state, then re-encrypting with a completely zero internal state (which is invalid, so nothing will be done).<br />
<br />
If skRecryptBegin was called, the re-encryption will succeed as the internal state would have been set, and re-encrypted data would be written to the same area that the original data was read from. (To get to the SK code area with this, though, requires overwriting all of DRAM)<br />
| Possible infoleak into the PI buffer. (without recrypt state set)<br />
Possible secure mode code execution. (with recrypt state set)<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| SK's CRL checking function will not check a ticket CRL at all if the ticket CRL version in the ticket (as s32) is < 0<br />
| The function in SK that checks provided CRLs at <tt>0x9FC02CB4</tt> checks the provided ticket CRL version first (which comes from the ticket.) If it's less than 0 as s32, it will not be checked at all, that call will be jumped over.<br />
<br />
The first CRL in the list is the ticket CRL; thus this could provide a favourable situation for exploiting psychic paper.<br />
<br />
Additionally, the required elements to craft a CRL such that SA believes it to be valid with the public key in the correct place for psychic paper do not overlap.<br />
<br />
Furthermore, libultra function osBbSaGamePrelaunch (which calls skLaunchSetup/skRecryptBegin/etc), which is called by SA when launching a game, stores the CRL structure for those two SKCs directly after the ticket bundle structure in .data. This, plus other flaws (below) lead directly to the successful exploitation of psychic paper.<br />
| Exploitation of psychic paper<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| eSKape: bad SKC table bounds check<br />
| SK's Secure Kernel Call handler bounds check uses a signed comparison when checking the SKC number that's being called to make sure it is within the bounds of the table, leading to the ability to have SK take the SKC function pointer from non-secure RAM, and thus, arbitrary code execution in secure mode.<br />
| Secure mode code execution.<br />
| May 1, 2018<br />
| [[User:Stuckpixel|Stuckpixel]] and [[User:Riley|Riley]] (complementary)<br />
|}<br />
<br />
==System Applications==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Exploitable System Applications<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| libultra _osBbSaVerifyTickets gets an entire ticket bundle then just uses skVerifyHash with the ticket cert-chain ptr<br />
| _osBbVerifyTickets is called by osBbSaMetaGetTickets if argument 2 is not 0. (osBbSaMetaGetTickets, in turn, is called by a function in SA that appears to get the data for the game menu?)<br />
This function calls osBbSaBundleTicket, which gets a "ticket bundle" (struct containing ticket + ticket+CMD cert chain + CRL pointers, pointer to which is used as an argument for skLaunchSetup and skRecryptBegin), then proceeds to call skVerifyHash passing a pointer to the ticket cert-chain pointer array from that structure.<br />
<br />
Given that the CMD cert chain pointer array is directly after the ticket cert-chain pointer array in that structure, this gives a favourable situation for exploitation of psychic paper.<br />
| Exploitation of psychic paper and self-signing tickets such that non-test SAs believe them to be valid.<br />
| All non-test SAs?<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| libultra osBbSaCertCreateChain only uses the endmost certificate's issuer<br />
| osBbSaCertCreateChain parses cert.sys to create a cert chain array for SK (first element points to the object's signer, second element points to its signer, etc.).<br />
This function only uses the issuer of the endmost certificate (object's signer), to get a list of certificate names to obtain.<br />
<br />
The rest of the certificates only have their name compared against the one currently being searched for. There are no checks that the chain being created ends in Root. This gives a favourable situation for exploitation of psychic paper.<br />
| Exploitation of psychic paper<br />
| All non-test SAs?<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=804
IO
2018-05-03T07:33:50Z
<p>Stuckpixel: Add some NAND info</p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4? || || Reading from this address within game code causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = ?, bit 2 = SKC, the other bits seem unused. bit 9 = execute related? (isBb?), bit 8 = execute related?<br />
|-<br />
| 0xA430002C || 1 || MI_RANDOM_BIT || Hardware RNG? Seems to return 1 bit of randomness, SK function at <tt>0x9FC03410</tt> gets lots of entropy from this then hashes it with SHA1 (several times?), this function is used to get randomness used when ECC signing, and when creating key material for recrypt.sys.<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Writes to this address seem to indicate the address to read data into RAM from the NAND<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=Virage2&diff=745
Virage2
2018-05-02T22:22:59Z
<p>Stuckpixel: </p>
<hr />
<div>OTP is a One Time Programmable 256 (0xFF) Byte memory region located inside the SoC. It seems to be called "virage2" in the SDK code. It can only be read in secure mode, and is mapped to <tt>0xBFCA0000</tt>.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Offset<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0x00 || 0x14 || SK Hash || common<br />
|-<br />
| 0x14 || 0x10 x 4 || ROM Patch || common<br />
|-<br />
| 0x54 || 0x20 || EccPublicKey || per-console<br />
|-<br />
| 0x74 || 0x04 || bbId || per-console<br />
|-<br />
| 0x78 || 0x40 || EccPrivateKey || per-console<br />
|-<br />
| 0xB8 || 0x10 || bootAppKey - COMMON KEY || common<br />
|-<br />
| 0xC8 || 0x10 || recryptListKey || per-console<br />
|-<br />
| 0xD8 || 0x10 || appStateKey || per-console<br />
|-<br />
| 0xE8 || 0x10 || selfMsgKey || per-console<br />
|-<br />
| 0xF8 || 0x04 || csumAdjust || per-console<br />
|-<br />
| 0xFC || 0x04 || jtagEnable || common</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IQue_Player_System_Flaws&diff=728
IQue Player System Flaws
2018-05-02T00:40:02Z
<p>Stuckpixel: document eSKape</p>
<hr />
<div>{{DISPLAYTITLE:iQue Player System Flaws}}<br />
==Hardware==<br />
{| class="wikitable" border="1"<br />
! Summary<br />
! Description<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| No known hardware exploits <br />
|<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
==Secure Kernel==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| psychic paper: Secure Kernel could incorrectly consider a self-signed certificate chain as valid<br />
| The function for verifying certificate chains at <tt>0x9FC028BC</tt> is passed an array of pointers to certificates.<br />
For the first 5 elements, it checks to see if the certificate was issued by <tt>Root</tt>, if so it checks if the certificate was signed by the hardcoded <tt>Root</tt> public key (and returns immediately with the result).<br />
<br />
If the certificate wasn't signed by <tt>Root</tt>, it checks if the certificate was signed by the public key of the next certificate in the array.<br />
<br />
If all 5 certificates verified correctly, the function will return success.<br />
| Assuming this function can be called with an attacker-controlled array of certificates (this is possible, thanks to other (below) issues), self-signing of certificates (and thus, arbitrary code execution, with full non-Secure Mode privileges)<br />
(This is not the case for Secure Applications, the code in SK for verifying those sets up a hardcoded array on the stack for the certificate verification function)<br />
| April 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| skLaunchSetup and skRecryptBegin leave CMD in memory if its signature does not verify<br />
| The function called by skLaunchSetup (and skRecryptBegin) at <tt>0x9FC00BAC</tt> verifies ticket and CMD, and decrypts the titlekey.<br />
After verifying the ticket signature, it copies the CMD to another place in memory, derives the titlekey encryption key, decrypts the titlekey with the titlekek, then verifies the CMD signature.<br />
<br />
If the CMD signature does not verify successfully, the function just returns an error, leaving the unsigned CMD in place.<br />
<br />
Most of the code that uses a CMD in SK uses the CMD in that place in memory that this function copies the CMD to, and trusts that whatever data is there has been verified already.<br />
<br />
The entire CMD is covered by the ticket signature anyway, so this isn't that useful really, besides potentially making psychic paper easier to exploit.<br />
| With existing code execution with access to skLaunchSetup or skRecryptBegin and some other SKC that uses SK's internal CMD copy (only non-test SAs have this level of access), and the ability to sign a ticket but not a CMD:<br />
Allowing the use of an unsigned CMD by SK, potentially leading to privilege escalation (by specifying arbitrary allowed hardware access/allowed SKCs).<br />
| April 26, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| skLaunch does not check content hash if recrypt flag is set in CMD<br />
| skLaunch calculates the SHA1 hash of the content and compares it to the value in the CMD, returning an error if the hash doesn't match. This entire block of code is jumped over if the recrypt flag is set in the CMD.<br />
| With plaintext of an application with the recrypt flag set in its CMD, arbitrary code execution (via, for example, implementation of the attack described in pocorgtfo17)<br />
| Early 2018?<br />
| Everyone<br />
|-<br />
| skVerifyHash signature pointer not validated<br />
| skVerifyHash takes in a u8 pointer to a signature to verify, but does not actually validate this pointer is valid before treating the memory it points to as an RSA/ECC signature.<br />
| Causing the Secure Kernel to data abort -- possibly usable as an infoleak, depending on the provided cert chain<br />
| April 29, 2018<br />
| [[User:SciresM|SciresM]]<br />
|-<br />
| SK's ECDH implementation does no validation of the other party's public key<br />
| When deriving the titlekek using ECDH, SK does no validation whatsoever of the public key, which comes from the ticket. Because ECDH is just multiplication, passing in an all-zero public key would lead to an all-zero titlekek being used.<br />
| With the ability to sign a ticket and CMD (for example, psychic paper): causing SK to use a constant titlekek; no need to know a console's ECC keypair.<br />
| April 29, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| skRecryptData insufficient checks<br />
| skRecryptData allows for NULL to be passed in as a pointer, for supporting some alternate mode controlled by a u32 in SK .data.<br />
However, if this u32 is 0 (which is the default), no further checks are done and recrypt operations are done starting from NULL with provided length (in 0x400 chunks).<br />
<br />
Also, if skRecryptBegin wasn't called, the recrypt operation is done by decrypting using the current hardware AES engine state, then re-encrypting with a completely zero internal state (which is invalid, so nothing will be done).<br />
<br />
If skRecryptBegin was called, the re-encryption will succeed as the internal state would have been set, and re-encrypted data would be written to the same area that the original data was read from. (To get to the SK code area with this, though, requires overwriting all of DRAM)<br />
| Possible infoleak into the PI buffer. (without recrypt state set)<br />
Possible secure mode code execution. (with recrypt state set)<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| SK's CRL checking function will not check a ticket CRL at all if the ticket CRL version in the ticket (as s32) is < 0<br />
| The function in SK that checks provided CRLs at <tt>0x9FC02CB4</tt> checks the provided ticket CRL version first (which comes from the ticket.) If it's less than 0 as s32, it will not be checked at all, that call will be jumped over.<br />
<br />
The first CRL in the list is the ticket CRL; thus this could provide a favourable situation for exploiting psychic paper.<br />
<br />
Additionally, the required elements to craft a CRL such that SA believes it to be valid with the public key in the correct place for psychic paper do not overlap.<br />
<br />
Furthermore, libultra function osBbSaGamePrelaunch (which calls skLaunchSetup/skRecryptBegin/etc), which is called by SA when launching a game, stores the CRL structure for those two SKCs directly after the ticket bundle structure in .data. This, plus other flaws (below) lead directly to the successful exploitation of psychic paper.<br />
| Exploitation of psychic paper<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| eSKape: bad SKC table bounds check<br />
| SK's Secure Kernel Call handler bounds checks uses a signed comparison when checking the SKC number that's being called to make sure it is within the bounds of the table, leading to the ability to have SK take the SKC function pointer from non-secure RAM, and thus, arbitrary code execution in secure mode.<br />
| Secure mode code execution.<br />
| May 1, 2018<br />
| [[User:Stuckpixel|Stuckpixel]] and [[User:Riley|Riley]] (complementary)<br />
|}<br />
<br />
==System Applications==<br />
{| class="wikitable" border="1"<br />
|-<br />
! Summary<br />
! Description<br />
! Successful exploitation result<br />
! Exploitable System Applications<br />
! Timeframe this was discovered<br />
! Discovered by<br />
|-<br />
| libultra _osBbSaVerifyTickets gets an entire ticket bundle then just uses skVerifyHash with the ticket cert-chain ptr<br />
| _osBbVerifyTickets is called by osBbSaMetaGetTickets if argument 2 is not 0. (osBbSaMetaGetTickets, in turn, is called by a function in SA that appears to get the data for the game menu?)<br />
This function calls osBbSaBundleTicket, which gets a "ticket bundle" (struct containing ticket + ticket+CMD cert chain + CRL pointers, pointer to which is used as an argument for skLaunchSetup and skRecryptBegin), then proceeds to call skVerifyHash passing a pointer to the ticket cert-chain pointer array from that structure.<br />
<br />
Given that the CMD cert chain pointer array is directly after the ticket cert-chain pointer array in that structure, this gives a favourable situation for exploitation of psychic paper.<br />
| Exploitation of psychic paper and self-signing tickets such that non-test SAs believe them to be valid.<br />
| All non-test SAs?<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|-<br />
| libultra osBbSaCertCreateChain only uses the endmost certificate's issuer<br />
| osBbSaCertCreateChain parses cert.sys to create a cert chain array for SK (first element points to the object's signer, second element points to its signer, etc.).<br />
This function only uses the issuer of the endmost certificate (object's signer), to get a list of certificate names to obtain.<br />
<br />
The rest of the certificates only have their name compared against the one currently being searched for. There are no checks that the chain being created ends in Root. This gives a favourable situation for exploitation of psychic paper.<br />
| Exploitation of psychic paper<br />
| All non-test SAs?<br />
| April 30, 2018<br />
| [[User:Riley|Riley]]<br />
|}</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=727
IO
2018-05-01T22:56:47Z
<p>Stuckpixel: fix typo</p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4? || || Reading from this address within game code causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = ?, bit 2 = SKC, the other bits seem unused<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Many times used for read/write actions. (card data access register???)<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=726
IO
2018-05-01T22:52:43Z
<p>Stuckpixel: </p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4? || || Reading from the address within game code causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value: bits 7-4 = ?, bit 3 = ?, bit 2 = SKC, the other bits seem unused<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Many times used for read/write actions. (card data access register???)<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=725
IO
2018-05-01T22:16:53Z
<p>Stuckpixel: clarify</p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4? || || Reading from the address within game code causes an exception; SK exception handler checks this address as well, and makes some decisions based on the value<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Many times used for read/write actions. (card data access register???)<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=724
IO
2018-05-01T22:16:22Z
<p>Stuckpixel: </p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4? || || Reading from the address within game code causes an exception; SK checks this address as well, and makes some decisions based on the value<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Many times used for read/write actions. (card data access register???)<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=722
IO
2018-05-01T20:39:04Z
<p>Stuckpixel: Add address SK refers to</p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300010 || 4 || ||<br />
|-<br />
| 0xA4300014 || 4? || ||<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Many times used for read/write actions. (card data access register???)<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IO&diff=721
IO
2018-05-01T19:30:02Z
<p>Stuckpixel: the card only contains NAND</p>
<hr />
<div>Custom registers.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Address<br />
! Size<br />
! Description<br />
! Note<br />
|-<br />
| 0xA4300014 || 4? || ||<br />
|-<br />
| 0xA4300030 || 4? || ||<br />
|-<br />
| 0xA4300038 || 4? || || <br />
|-<br />
| 0xA430003C || 4? || || <br />
|-<br />
| 0xA4400000 || 4? || ||<br />
|-<br />
| 0xA4500008 || 4? || ||<br />
|-<br />
| 0xA4600010 || 4? || || <br />
|-<br />
| 0xA4600014 || 4? || || <br />
|-<br />
| 0xA4600018 || 4? || || <br />
|-<br />
| 0xA460001C || 4? || || <br />
|-<br />
| 0xA4600020 || 4? || || <br />
|-<br />
| 0xA4600024 || 4? || ||<br />
|-<br />
| 0xA4600028 || 4? || ||<br />
|-<br />
| 0xA460002C || 4? || ||<br />
|-<br />
| 0xA4600030 || 4? || ||<br />
|-<br />
| 0xA4600040 || 4? || ||<br />
|-<br />
| 0xA4600044 || 4? || ||<br />
|-<br />
| 0xA4600048 || 4? || || Many times used for read/write actions. (card data access register???)<br />
|-<br />
| 0xA4600050 || 4? || ||<br />
|-<br />
| 0xA4600054 || 4? || || <br />
|-<br />
| 0xA4600060 || 4 || [[#StatusField| StatusField]] || This register is used for RTC, error led and other things... (probably status register?, made-up name)<br />
|-<br />
| 0xA4600070 || 4? || || <br />
|-<br />
| 0xA4610000 || 4? || || <br />
|-<br />
| 0xA4610200 || 4? || || <br />
|-<br />
| 0xA4610420 || 176 || PI_AES_EXPANDED_KEY || AES-128 expanded key for hardware AES engine<br />
|-<br />
| 0xA46104D0 || 16 || PI_AES_IV || AES-128-CBC initialisation vector for hardware AES engine<br />
|-<br />
| 0xA4610500 || 4 || ||<br />
|-<br />
| 0xA4610504 || 4? || || atb? (virtual address?)<br />
|-<br />
| 0xA46E0400 || 4? or 2? || || rdb?<br />
|-<br />
| 0xA4940010 || 4? || ||<br />
|-<br />
| 0xA4A40010 || 4? || ||<br />
|}<br />
<br />
= StatusField = <br />
<br />
{| class="wikitable"<br />
|-<br />
! Bit(s)<br />
! Description<br />
|-<br />
| ?-15 || Box Id<br />
|-<br />
| 27 || Power (on and off)<br />
|-<br />
| 28 || RTC related?<br />
|-<br />
| 29 || Unknown bit<br />
|-<br />
| 30 || Error led<br />
|-<br />
| 31 || Power (only on)<br />
|}<br />
<br />
== RTC ==<br />
<br />
The iQue Player has a custom RTC functionality. The Nintendo 64 doesn't have a RTC, except the Nintendo 64 version of Animal Crossing which uses a special custom RTC chip instead of a built-in RTC. The RTC functionality is heavly used in the game [[Animal_Crossing| Animal Crossing]]. The RTC can be accessed through 0xA4600060. (unknown how)</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=IQue_Card&diff=709
IQue Card
2018-04-30T22:37:14Z
<p>Stuckpixel: Add NAND datasheet</p>
<hr />
<div>{{DISPLAYTITLE:iQue Card}}<br />
[[File:IQue_card_disassembled.jpg|thumb|A disassembled '''iQue Card'''.]]<br />
<br />
The '''iQue Card''' (Chinese: 神游卡) is a removable memory card of the [[iQue Player]], used to store [[games]] and the [[SKSA|"Upgradeable Operating System"]]. It is located on the bottom of every unit.<br />
<br />
The iQue Card is housed in a plastic shell, which contains a Samsung K9F1208U0M-YCB0 NAND chip on a special PCB codenamed "DOOKIE". The contents of the NAND are documented on the [[NAND]] page.<br />
<br />
Datasheet: [http://www.reinerziegler.de/ique/ds_k9f1208u0m.pdf]<br />
<br />
== DOOKIE ==<br />
The DOOKIE board is very basic, and it contains the NAND flash, a few resistors, and an edge connector to connect with an [[iQue Player]]. The connector has a 1.1mm pitch and seems to be custom made. No other commonly-available connector appears to fit in it except the MicroSD.<br />
<br />
[[Category:Hardware]]</div>
Stuckpixel
http://www.iquebrew.org/index.php?title=SKC&diff=691
SKC
2018-04-29T07:45:23Z
<p>Stuckpixel: add skcKeepAlive</p>
<hr />
<div>= Secure Kernel calls =<br />
<br />
All secure kernel calls return a s32 error code in $v0. 0 means success, below zero means error.<br />
<br />
{| class=wikitable<br />
! Id || Name || In<br />
|-<br />
| 0x0 || skcGetBBID || $a0=u32* out_bbid<br />
|-<br />
| 0x1 || skcPrepareCMDAndTik || ???<br />
|-<br />
| 0x2 || skcStartContent || $a0=address where decrypted content has been loaded<br />
|-<br />
| 0x3 || skcVerifyRecryptSys || $a0=address of recrypt.sys contents<br />
|-<br />
| 0x4 || ??? || ???<br />
|-<br />
| 0x5 || ??? || ???<br />
|-<br />
| 0x6 || ??? || ???<br />
|-<br />
| 0x7 || ??? || ???<br />
|-<br />
| 0x8 || skcECCSignSHA1Hash || $a0=u8* sha1hash, $a1=u8* out_signature<br />
|-<br />
| 0x9 || skcVerifySignature || $a0=u8* sha1hash, $a1=u8* signature, $a2=certificate** certificate_chain, $a3=crl** crls?<br />
|-<br />
| 0xA || ??? || ???<br />
|-<br />
| 0xB || ??? || ???<br />
|-<br />
| 0xC || ??? || ???<br />
|-<br />
| 0xD || skcReboot || void<br />
|-<br />
| 0xE || skcKeepAlive || void<br />
|}</div>
Stuckpixel