Changes

Jump to navigation Jump to search
1,006 bytes added ,  23:55, 28 July 2017
m
Line 72: Line 72:     
===0x17E10000===
 
===0x17E10000===
The 32bit register at 0x17E10000+0x100 only has bit0 set when, on New3DS, [[PTMSYSM:ConfigureNew3DSCPU]] was used with bit1 set for the input value(the L2 cache flag). All other bits in this register are normally all-zero. Therefore: bit0 set = new cache hardware enabled, clear = new cache hardware disabled(this bit is how the ARM11-kernel checks whether the additional cache hw is enabled).
+
The 32-bit register at <code>0x17E10000</code>+<code>0x100</code> only has bit 0 set when, on New 3DS, [[PTMSYSM:ConfigureNew3DSCPU]] was used with bit 1 set for the input value (the L2 cache flag). All other bits in this register are normally all-zero. Therefore, bit 0 set = new cache hardware enabled, bit 0 clear = new cache hardware disabled. This bit is how the ARM11 kernel checks whether the additional cache hardware is enabled).
   −
To enable the additional cache hw, the following is used by the ARM11-kernel:
+
To enable the additional cache hardware, the following is used by the ARM11 kernel:
* Sets bit0 in 32bit register 0x17E10000+0x100.
+
* Sets bit 0 in 32-bit register <code>0x17E10000</code>+<code>0x100</code>.
   −
To disable the additional cache hw, the following is used by the ARM11-kernel:
+
To disable the additional cache hardware, the following is used by the ARM11 kernel:
* Writes value 0xFFFF to 32bit register 0x17E10000+0x77C.
+
* Writes value <code>0xFFFF</code> to 32-bit register <code>0x17E10000</code>+<code>0x77C</code>.
* Waits for bit0 in 32bit register 0x17E10000+0x730 to become clear.
+
* Waits for bit 0 in 32-bit register <code>0x17E10000</code>+<code>0x730</code> to become clear.
* Writes value 0x0 to 32bit register 0x17E10000+0x0.
+
* Writes value <code>0x0</code> to 32-bit register <code>0x17E10000</code>+<code>0x0</code>.
* Clears bit0 in 32bit register 0x17E10000+0x100.
+
* Clears bit 0 in 32-bit register <code>0x17E10000</code>+<code>0x100</code>.
   −
=== 0x1F000000 ([[New_3DS]]-only) ===
+
=== <code>0x1F000000</code> ([[New 3DS]] only) ===
This area is used by [[QTM Services]](starting at offset 0x200000, size 0x180000). This area is not accessible to the GPU on the old 3DS. The old 3DS and New 3DS GSP module has vaddr->physaddr conversion code for this entire region. On the New 3DS, only the first 0x200000-bytes (half of this memory) are accessible to the GPU.
+
This area is used by [[QTM Services]],starting at offset <code>0x200000</code>, size <code>0x180000</code>. This area is not accessible to the GPU on the old 3DS. The old 3DS and New 3DS GSP module has <code>vaddr-&gt;physaddr</code> conversion code for this entire region. On the New 3DS, only the first <code>0x200000</code> bytes (half of this memory) are accessible to the GPU.
    
== ARM9 ==
 
== ARM9 ==
Line 152: Line 152:  
| 0xFFF00000
 
| 0xFFF00000
 
| 0x00004000
 
| 0x00004000
| Data TCM (Mapped during bootrom)
+
| Data TCM (Mapped during bootrom). Enabled at the time Boot9 jumps to FIRM, however Kernel9+arm9loader disables it.
 
|-
 
|-
 
| style="background: green" | Yes
 
| style="background: green" | Yes
Line 160: Line 160:  
|}
 
|}
   −
==ARM9 MPU Setup==
+
==ARM9 MPU Regions==
 
For the below instruction permissions: RO = memory is executable, while None = not-executable.
 
For the below instruction permissions: RO = memory is executable, while None = not-executable.
   Line 366: Line 366:  
| RO
 
| RO
 
|}
 
|}
 +
 +
===[[Bootloader|Boot9]]===
 +
{| class="wikitable" border="1"
 +
|-
 +
!  Region
 +
!  Address
 +
!  Size
 +
!  Privileged-mode data permissions
 +
!  User-mode data permissions
 +
!  Privileged-mode instruction permissions
 +
!  User-mode instruction permissions
 +
|-
 +
| 0
 +
| 0x20000000
 +
| 0x08000000
 +
| None
 +
| None
 +
| None
 +
| None
 +
|-
 +
| 1
 +
| 0x10000000
 +
| 0x10000000
 +
| RW
 +
| RW
 +
| None
 +
| None
 +
|-
 +
| 2
 +
| 0x08000000
 +
| 0x00100000
 +
| RW
 +
| RW
 +
| None
 +
| None
 +
|-
 +
| 3
 +
| 0x08000000
 +
| 0x00000400
 +
| RW
 +
| RW
 +
| RO
 +
| RO
 +
|-
 +
| 4
 +
| 0xFFF00000
 +
| 0x00004000
 +
| RW
 +
| RW
 +
| None
 +
| None
 +
|-
 +
| 5
 +
| 0x07FF8000
 +
| 0x00008000
 +
| RW
 +
| RW
 +
| RO
 +
| RO
 +
|-
 +
| 6
 +
| 0xFFFF0000
 +
| 0x00010000
 +
| RO
 +
| RO
 +
| RO
 +
| RO
 +
|-
 +
| 7
 +
| 0x1FFFE000
 +
| 0x00000800
 +
| RW
 +
| RW
 +
| None
 +
| None
 +
|}
 +
 +
* Instruction cachable bits = 0x40(only enabled for region6).
 +
* Data cachable bits = 0x44(only enabled for region2 and region6).
 +
* Data bufferable bits = 0x44(only enabled for region2 and region6).
 +
 +
These are the same for both Old3DS/New3DS.
    
==ARM9 ITCM==
 
==ARM9 ITCM==
Line 391: Line 473:  
|  
 
|  
 
| 0x3800
 
| 0x3800
| 0x4
+
| 0x100
| This is always 0xDEADB00F.
+
| This is the first 0x90 bytes of [[OTP_Registers#Plaintext_OTP|plaintext OTP]] when OTP hash verification is successful. The remaining 0x70 bytes are cleared.
|-
  −
| 0x01FFB804
  −
|
  −
| 0x3804
  −
| 0x4
  −
| This is the u32 DeviceId.
  −
|-
  −
| 0x01FFB808
  −
|
  −
| 0x3808
  −
| 0x10
  −
| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the last two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
  −
|-
  −
| 0x01FFB818
  −
|
  −
| 0x3818
  −
| 0x1
  −
| ?
  −
|-
  −
| 0x01FFB819
  −
|
  −
| 0x3819
  −
| 0x1
  −
| This is the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
  −
|-
  −
| 0x01FFB81A
  −
|
  −
| 0x381A
  −
| 0x6
  −
| ?
  −
|-
  −
| 0x01FFB820
  −
|
  −
| 0x3820
  −
| 0x4
  −
| This is the CTCert ECDSA exponent, this is byte-swapped when *((u8*)(0x01FFB800+0x18)) is >=5.
  −
|-
  −
| 0x01FFB824
  −
|
  −
| 0x3824
  −
| 0x2
  −
| ?
  −
|-
  −
| 0x01FFB826
  −
|
  −
| 0x3826
  −
| 0x1E
  −
| This is the CTCert ECDSA privk.
  −
|-
  −
| 0x01FFB844
  −
|
  −
| 0x3844
  −
| 0x3C
  −
| This is the CTCert ECDSA signature.
   
|-
 
|-
 
| 0x01FFB880
 
| 0x01FFB880
 
|  
 
|  
| 0x3880
+
| 0x3890
| 0x80
+
| 0x70
| This is all-zero.
+
| This is all zeros; boot ROM does not reveal the console-specific keys or the OTP hash in ITCM.
 
|-
 
|-
 
| 0x01FFB900
 
| 0x01FFB900
Line 464: Line 492:  
| 0x3B00
 
| 0x3B00
 
| 0x200
 
| 0x200
| This is the 0x200-bytes from the plaintext NAND firm partition FIRM header, read by bootrom.
+
| This is the 0x200-bytes from the plaintext FIRM header for the FIRM which was loaded by [[Bootloader|Boot9]]. This is the only location Boot9 uses for storing the loaded FIRM headers internally, it's not stored anywhere else.
 
|-
 
|-
 
| 0x01FFBD00
 
| 0x01FFBD00
Line 553: Line 581:  
| 0xB90
 
| 0xB90
 
| Uninitialized memory.
 
| Uninitialized memory.
0x01FFFC00 size 0x100-bytes starting with [[9.5.0-22|9.5.0-X]] is the FIRM header used during FIRM-launching.
+
|-
 +
| 0x01FFFC00
 +
|
 +
| 0x7C00
 +
| 0x100
 +
| Starting with [[9.5.0-22|9.5.0-X]] is the FIRM header used during FIRM-launching.
 
|}
 
|}
   Line 573: Line 606:  
* [[Virtual address mapping New3DS v9.0]]
 
* [[Virtual address mapping New3DS v9.0]]
 
* [[Virtual address mapping New3DS v9.2]]
 
* [[Virtual address mapping New3DS v9.2]]
 +
* [[Virtual address mapping New3DS v11.1]]
    
=ARM11 Detailed physical memory map=
 
=ARM11 Detailed physical memory map=
Line 602: Line 636:     
== FCRAM memory-regions layout ==
 
== FCRAM memory-regions layout ==
 +
FCRAM is partitioned into three regions of memory (APPLICATION, SYSTEM, and BASE). Most applications can only allocate memory from one of these regions (which is encoded in the [[NCCH/Extended_Header#ARM11_Kernel_Flags|process kernel flags]]). There is a fixed set of possible size of each memory region, determined by the APPMEMTYPE value in [[Configuration_Memory#APPMEMTYPE|configuration memory]] (which in turn is set up according to the [[FIRM#FIRM_Launch_Parameters|firmware launch parameters]]).
 +
 +
Support for APPMEMTYPEs 6 and 7 was implemented in [[NS]] with [[8.0.0-18]]. These configurations are only supported in the [[New_3DS]] ARM11-kernel, and are in fact the only ones supported there at all. Applications only get access to the larger memory regions when this is specified in their [[NCCH/Extended Header#New3DS System Mode|extended header]].
 +
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
[[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]] Value
+
!  APPMEMTYPE
Base address relative to FCRAM+0, for APPLICATION mem-region
+
APPLICATION starting address (relative to FCRAM)
Region size, for APPLICATION mem-region
+
!  APPLICATION region size
Base address relative to FCRAM+0, for SYSTEM mem-region
+
SYSTEM starting address (relative to FCRAM)
Region size, for SYSTEM mem-region
+
!  SYSTEM region size
Base address relative to FCRAM+0, for BASE mem-region
+
BASE starting address (relative to FCRAM)
Region size, for BASE mem-region
+
!  BASE region size
 
|-
 
|-
 
| 0 (default with regular 3DS kernel, used when the type is not 2-5)
 
| 0 (default with regular 3DS kernel, used when the type is not 2-5)
Line 669: Line 707:     
The SYSTEM mem-region size is calculated with: size = FCRAMTOTALSIZE - (APPLICATION_MEMREGIONSIZE + BASE_MEMREGIONSIZE).
 
The SYSTEM mem-region size is calculated with: size = FCRAMTOTALSIZE - (APPLICATION_MEMREGIONSIZE + BASE_MEMREGIONSIZE).
  −
Support for type6/7 was [[NCCH/Extended Header|implemented]] in [[NS]] with [[8.0.0-18]], these are only supported in the [[New_3DS]] ARM11-kernel not the regular 3DS kernel. These two types are the only ones supported by the New3DS kernel.
      
All memory allocated by the kernel itself for kernel use is located under BASE. Most system-modules run under the BASE memregion too.
 
All memory allocated by the kernel itself for kernel use is located under BASE. Most system-modules run under the BASE memregion too.
Line 772: Line 808:     
==0xFF4XX000==
 
==0xFF4XX000==
Each [[KThread|thread]] is allocated a 0x1000-byte page in this region: the first page at 0xFF401000 is for the first created thread, 0xFF403000 for the second thread. This region is used to store the SVC-mode stack for the thread, and thread context data used for context switching. When the IRQ handler, prefetch/data abort handlers, and undefined instruction handler are entered where the SPSR-mode=user, these handlers then store LR+SPSR for the current mode on the SVC-mode stack, then these handlers switch to SVC-mode.
+
Each [[KThread|thread]] is allocated a 0x1000-byte page in this region for the [[KThreadContext|thread context]]: the first page at 0xFF401000 is for the first created thread, 0xFF403000 for the second thread. This region is used to store the SVC-mode stack for the thread, and thread context data used for context switching. When the IRQ handler, prefetch/data abort handlers, and undefined instruction handler are entered where the SPSR-mode=user, these handlers then store LR+SPSR for the current mode on the SVC-mode stack, then these handlers switch to SVC-mode.
    
This page does not contain a dedicated block for storing R0-PC(etc). For user-mode, the user-mode regs are instead saved on the SVC-mode stack when IRQs such as timers for context switching are triggered.
 
This page does not contain a dedicated block for storing R0-PC(etc). For user-mode, the user-mode regs are instead saved on the SVC-mode stack when IRQs such as timers for context switching are triggered.
   −
Structure of this page, relative to page_endaddr-0xC8:
  −
{| class="wikitable" border="1"
  −
|-
  −
!  Offset
  −
!  Size
  −
!  Description
  −
|-
  −
| 0x0
  −
|
  −
| SVC-mode stack-top. The 0x10-byte SVC-access-control for this thread is also located here, which is checked by the SVC-handler.
  −
|-
  −
| 0x18
  −
| 0x28
  −
| SVC-mode saved registers, stored/loaded during context switches: R4-R9, SL, FP, SP, LR. After loading these registers, the context switch code will jump to the loaded LR.
  −
|-
  −
| 0xC0
  −
| 4
  −
| fpexc from vmrs, used during context switches with the above saved registers.
  −
|}
      
For NATIVE_FIRM the memory pages for this region are located in FCRAM, however for TWL_FIRM these are located in AXI WRAM. For TWL_FIRM v6704 the first thread's page for this region is located at physical address 0x1FF93000, the next one at 0x1FF92000, etc.
 
For NATIVE_FIRM the memory pages for this region are located in FCRAM, however for TWL_FIRM these are located in AXI WRAM. For TWL_FIRM v6704 the first thread's page for this region is located at physical address 0x1FF93000, the next one at 0x1FF92000, etc.
   −
== IO Process/Kernel virtual addressing equivalence ==
+
== IO Process virtual addressing equivalence ==
It seems an IO register's process virtual address can be calculated by adding 0xEB00000 to its physical address.
+
It seems an IO register's process virtual address can be calculated by adding 0xEB00000 to its physical address. However for kernel mappings there is no fixed address equivalence.
    
=ARM11 User-land memory regions=
 
=ARM11 User-land memory regions=
Line 855: Line 872:  
| 0x1EC00000
 
| 0x1EC00000
 
| 0x10100000
 
| 0x10100000
| 0x01000000
+
| 0x00400000
 
| No
 
| No
| [[IO]] registers, the mapped IO pages which each process can access is specified in the [[NCCH#CXI|CXI]] exheader.(Applications normally don't have access to registers in this range)
+
| [[IO]] registers, the mapped IO pages which each process can access is specified in the [[NCCH/Extended_Header|exheader]]. (Applications normally don't have access to registers in this range)
 
|-
 
|-
 
| 0x1F000000
 
| 0x1F000000
Line 884: Line 901:  
|-
 
|-
 
| 0x1FF82000
 
| 0x1FF82000
| ?
+
| Dynamically taken from the BASE region of FCRAM
| ?
+
| Number of threads * 0x1000 / 8
 
| No
 
| No
 
| [[Thread Local Storage]]
 
| [[Thread Local Storage]]
Line 994: Line 1,011:  
  0xFFFF9004 Pointer to the current KProcess instance
 
  0xFFFF9004 Pointer to the current KProcess instance
 
  0xFFFF9008 Pointer to the current KScheduler instance
 
  0xFFFF9008 Pointer to the current KScheduler instance
 +
0xFFFF900C Pointer to the current KSchedulableInterruptEventLinkedList instance
 
  0xFFFF9010 Pointer to the last KThread to encounter an exception
 
  0xFFFF9010 Pointer to the last KThread to encounter an exception
   Line 1,002: Line 1,020:  
= VRAM Map While Running System Applets =
 
= VRAM Map While Running System Applets =
 
*0x1E6000-0x22C500 -- top screen 3D left framebuffer 0(240x400x3) (The "3D right first-framebuf" addr stored in the LCD register is set to this, when the 3D is set to "off")
 
*0x1E6000-0x22C500 -- top screen 3D left framebuffer 0(240x400x3) (The "3D right first-framebuf" addr stored in the LCD register is set to this, when the 3D is set to "off")
*0x22C800-0x272D00 -- top screen 3D left framebuffer 1(240x400x3)
+
*0x22C800-0x272D00 -- top screen 3D right framebuffer 0(240x400x3)
*0x273000-0x2B9500 -- top screen 3D right framebuffer 0(240x400x3)
+
*0x273000-0x2B9500 -- top screen 3D left framebuffer 1(240x400x3)
 
*0x2B9800-0x2FFD00 -- top screen 3D right framebuffer 1(240x400x3)
 
*0x2B9800-0x2FFD00 -- top screen 3D right framebuffer 1(240x400x3)
 
*0x48F000-0x4C7400 -- bottom screen framebuffer 0(240x320x3)
 
*0x48F000-0x4C7400 -- bottom screen framebuffer 0(240x320x3)
2

edits

Navigation menu