516
edits
Changes
Jump to navigation
Jump to search
Line 368:
Line 368: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
oops
PDN services holds reset for 0x30 Arm11 cycles.
PDN services holds reset for 0x30 Arm11 cycles.
== PDN_MPCORE_CLKCNT ==
This is used for configuring the New3DS ARM11 CPU clock-rate. This register is New3DS-only: reading from here on Old3DS always returns all-zeros even when one tried writing data here prior to the read.
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Enable clock multiplier? This must be set to 1 before writing a non-zero value to bit1-2, otherwise freeze. This enables the New 3DS FCRAM extension.
|-
| 1-2
| Clock multiplier (0=1x, 1=2x, 2=3x, 3=hang)
|-
| 15
| Busy
|}
[[SVC#KernelSetState|svcKernelSetState]] type10, only implemented on New3DS, uses this register. That code writes the following values to this register, depending on the input Param0 bit0 state, and the state of [[CONFIG11 Registers#CFG11_SOCINFO|CFG11_SOCINFO]]:
{| class="wikitable" border="1"
! Register value
! Higher-clockrate bit set in svcKernelSetState Param0
! CFG11_SOCINFO bit2 set
! MPCore timer/watchdog prescaler value, prior to subtracting it by 0x1 when writing it into hw/state
! Clock-rate multiplier
! Description
|-
| 0x01
| No
| Yes
| 0x01
| 1x
| 268MHz
|-
| 0x02
| No
| No
| 0x01
| 1x
| 268MHz
|-
| 0x05
| Yes
| Yes
| 0x03
| 3x
| 804MHz
|-
| 0x03
| Yes
| No
| 0x02
| 2x
| 536MHz (tested on New3DS)
|}
Note that the above CFG11_SOCINFO bit is 1 on New3DS, and 0 on Old3DS. Since this SVC is only available with the New3DS ARM11-kernel, the only additional available clock-rate is 804MHz when running on New3DS(with official kernel code).
The following register value(s) were tested on New3DS by patching the kernel:
* 0x00: Entire system hangs.
* 0x02: Entire system hangs.
* 0x03: ARM11 runs at 536MHz.
* 0x04: Entire system hangs.
* 0x06: Entire system hangs.
* 0x07: Same result as 0x05.
* 0x08: Entire system hangs.
* 0x09: Entire system hangs.
* 0x0A: Entire system hangs.
* 0x0B: Same result as 0x03.
* 0x0C: Entire system hangs.
* 0x0D: Same result as 0x05.
* 0x0E: Entire system hangs.
* 0x0F: Same result as 0x05.
* 0x1F, 0x2F, 0x4F, 0x8F, 0xFF: Same result as 0x05.
== PDN_MPCORE_CNT ==
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| ?
|-
| 8
| ?
|}
Kernel11 sets this to 0x101 when bit 2 in [[CONFIG11 Registers#CFG11_SOCINFO|CFG11_SOCINFO]] is set otherwise 1.
== PDN_MPCORE_BOOTCNT<0-3> ==
{| class="wikitable" border="1"
! Bits
! Description
|-
| 0
| Enable bootrom instruction overlay, maybe? This bit is only writable for core2 and core3.
|-
| 1
| Enable bootrom data overlay. This bit is only writable for core2 and core3.
|-
| 4
| Has core booted maybe?
|-
| 5
| Always 1?
|}
The normal ARM11 bootrom checks cpuid and hangs if cpuid >= 2. This is a problem when booting the 2 additional New3DS ARM11 MPCores. NewKernel11 solves this by using a hardware feature to overlay the bootrom with a configurable branch to a kernel function. This overlay feature was added with the New3DS.
Bit1 in register above enables a bootrom data-override for physical addresses 0xFFFF0000-0xFFFF1000 and 0x10000-0x11000. All _data reads_ made to those regions now read the 32-bit value provided in [[CONFIG11 Registers #CFG11_BOOTROM_OVERLAY_VAL|CFG11_BOOTROM_OVERLAY_VAL]].
Bit0 enables a bootrom instruction-overlay which means that _instruction reads_ made to the bootrom region are overridden. We have not been able to dump what instructions are actually placed at bootrom by this switch (because reading the area only yields data-reads). Jumping randomly into the 0xFFFF0000-0xFFFF1000 region works fine and jumps to the value provided by the data overlay [[CONFIG11 Registers #CFG11_BOOTROM_OVERLAY_VAL|CFG11_BOOTROM_OVERLAY_VAL]]. Thus we may predict that the entire bootrom region is filled by:
ldr pc, [pc]
Or equivalent. However, jumping to some high addresses such as 0xFFFF0FF0+ will crash the core. This may be explained by prefetching in the Arm pipeline, and might help us identify what instructions are placed by the instruction-overlay.