Difference between revisions of "ARM7 Registers"
Dark samus (talk | contribs) |
Dark samus (talk | contribs) m |
||
Line 68: | Line 68: | ||
===ARM7_CODE=== | ===ARM7_CODE=== | ||
− | This region is an arm7 bootrom overlay, over the vector table at address 0. Once the ARM7 is taken out of reset by <code>TwlProcess9</code>, the reset vector will be jumped to, beginning execution. <code>TwlProcess9</code> uses this to put ARM7 in a loop (TWL), and to set the <code>POSTFLG</code> and branch to more copied code (GBA). Execution is started by writing <code>0x8001</code> to [[CONFIG11_Registers#CFG11_TWLMODE_0|CFG11_TWLMODE_0]]. Later, this overlay is disabled by the ARM7 via the "biosprot" register (0x04000308). | + | This region is an arm7 bootrom overlay, over the vector table at address 0. Once the ARM7 is taken out of reset by <code>TwlProcess9</code>, the reset vector will be jumped to, beginning execution. <code>TwlProcess9</code> uses this to put ARM7 in a loop (TWL), and to set the <code>POSTFLG</code> and branch to more copied code (GBA). Execution is started by writing <code>0x8001</code> to [[CONFIG11_Registers#CFG11_TWLMODE_0|CFG11_TWLMODE_0]] after setting the mode via <code>ARM7_CNT</code>. Later, this overlay is disabled by the ARM7 via the "biosprot" register (0x04000308). |
Reading uninitialized data in this 32-byte region leads to both screens displaying solid green (exception), and the CPU locking up. | Reading uninitialized data in this 32-byte region leads to both screens displaying solid green (exception), and the CPU locking up. |
Revision as of 07:24, 8 June 2019
The 3DS utilizes an onboard ARM7 core to handle TWL_FIRM
and AGB_FIRM
's ARM7 requirements. This is due to the fact that much of the hardware used by both ARM7 and ARM9 is (evidently) not physically hooked up to ARM11. Thus, ARM11 cannot simply emulate ARM7.
ARM7 has the GBA BIOS implemented in hardware. The BIOS is completely identical to the original GBA BIOS. The system is booted silently by calling SWI 0x1
(a.k.a. RegisterRamReset
), followed by jumping to the code that does SWI 0x0
(a.k.a. SoftReset
) to finish booting. The boot splash is still in BIOS, however, and can be seen by calling or replacing one of the previous interrupts with SWI 0x26
(a.k.a. HardReset
).
Registers
ARM9 interfaces with the ARM7 through the following registers:
Type | Address | Name | Size (bytes) |
---|---|---|---|
u8
|
0x10018000
|
ARM7_CNT
|
1 |
Code | 0x10018080
|
ARM7_CODE
|
32 |
u16
|
0x10018100
|
ARM7_SAVE_MODE
|
2 |
u16
|
0x10018104
|
ARM7_?_CNT
|
2 |
u16
|
0x10018108
|
ARM7_RTC_CNT?
|
2 |
u32
|
0x10018110
|
ARM7_RTC_VAL_LO
|
4 |
u32
|
0x10018114
|
ARM7_RTC_VAL_HI
|
4 |
u32
|
0x10018118
|
ARM7_RTC_LO?
|
4 |
u32
|
0x1001811C
|
ARM7_RTC_HI?
|
4 |
arm7_save_cfg_t
|
0x10018120
|
ARM7_SAVE_CFG
|
16 |
ARM7_CNT
This seems to control the mode of the ARM7. 1 = TWL, 2 = GBA.
ARM7_CODE
This region is an arm7 bootrom overlay, over the vector table at address 0. Once the ARM7 is taken out of reset by TwlProcess9
, the reset vector will be jumped to, beginning execution. TwlProcess9
uses this to put ARM7 in a loop (TWL), and to set the POSTFLG
and branch to more copied code (GBA). Execution is started by writing 0x8001
to CFG11_TWLMODE_0 after setting the mode via ARM7_CNT
. Later, this overlay is disabled by the ARM7 via the "biosprot" register (0x04000308).
Reading uninitialized data in this 32-byte region leads to both screens displaying solid green (exception), and the CPU locking up.
ARM7_SAVE_MODE
This tells the save storage emulation hardware which device type to emulate (64k EEPROM, a 512k Flash chip model, and SRAM are all that have been used officially; several other 512k Flash chip models, two 1 Mbit Flash chip models and 8k EEPROM are also supported). This comes directly from the ROM footer.
ARM7_RTC_VAL
These registers are set to the current LgyP9 date+time before ARM7_RTC_CNT/ARM7_RTC_? registers are used. They contain the following structure, set up on the stack then both u32 registers are written one after the other:
s8 year_since_2000_bcd; s8 month_bcd; s8 day_bcd; s8 day_of_week; s8 hour_bcd; s8 minute_bcd; s8 second_bcd;
ARM7_RTC ?
These registers may be used to control a real-time clock. To set or read the data here, first ARM7_RTC_CNT
's bit 15 is waited on. Next ARM7_RTC_CNT
is set to zero.
For a write: the two registers are written, a 1 is written to ARM7_RTC_CNT
, and it is waited on the same as before. Afterwards if bit 14 is not set in ARM7_RTC_CNT
, the value was set successfully.
For a read: a 2 is written to ARM7_RTC_CNT
, it's waited on again. Afterwards, if bit 14 is not set, the RTC can be read. Presumably the hardware can be re-enabled by writing a zero to ARM7_RTC_CNT
at this point, but AGB_FIRM
does not.
ARM7_SAVE_CFG
This is copied from rom footer + 0x10
. It presumably configures details about storage, such as IDs, and likely allows enabling the RTC for games which need it. Format of this data is unknown, and slightly difficult to determine without some hardware poking.
Memory map
The virtual memory mapping for the ARM7 is the same as for the other core. However, it has additional internal memory mapped to it. Interestingly enough, much of this memory seems to lie within ARM9's own internal memory.
0x08060000
→0x03800000
, ARM7 WRAM (64KiB)0x080B0000
→0x03000000
, GBA IWRAM (32KiB)0x08080000
→ EEPROM/SRAM/Flash 512k/Flash 1Mbit (the 2 512k banks are contiguous in memory). Appears to be mirrored at0x080C0000
, maybe first mapping is read-only and second is writable?0x10018104
must be set to 1 before reading memory here, and restored to its previous value afterwards0x01FFC000
→0x01000000
, ARM9 ITCM under TWL (16KiB)