3dbrew - User contributions [en]

Serials

2018-02-28T14:27:49Z

D0k3: /* Physical Serial */

This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).

== Console Serial Numbers ==

A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.

The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)

After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.

Example: CW404567772

The non-check digits are 40456777. Separating into odd and even groups, we get the following:

Odds: 4 + 4 + 6 + 7 = 21
Evens: 0 + 5 + 7 + 7 = 19

Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.

The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.

The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.

{| class="wikitable"
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)
|-
| ''DSi'' || T || V
|-
| ''DSi XL/LL'' || W || ''unknown''
|-
| ''Wii U'' || F || ''unknown''
|-
| 3DS || C || E
|-
| 3DS XL/LL || S || R
|-
| 2DS || A || P
|-
| New 3DS || Y || Y
|-
| New 3DS XL/LL || Q || Q
|-
| New 2DS XL/LL || N || N
|}

Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.

Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).

{| class="wikitable"
! Sales Region !! Region Lock !! Region Suffix
|-
| Japan || Japan || JF, JH, JM
|-
| North America || North America || W
|-
| Middle East / Southeast Asia || North America || S
|-
| Europe || Europe || EF, EH, EM
|-
| Australia || Europe || AH, AG
|-
| South Korea || Korea || KF, KH, KM
|-
| China (iQue) || China || CF, CH, CM
|}

== Console Models ==

{| class="wikitable"
! Device !! Product Code
|-
| ''DS'' || NTR
|-
| ''DS lite'' || USG
|-
| ''DSi'' || TWL
|-
| ''DSi XL/LL'' || UTL
|-
| ''Wii U'' || WUP
|-
| 3DS || CTR
|-
| 3DS XL/LL || SPR
|-
| 2DS || FTR
|-
| [[New 3DS]] || KTR
|-
| [[New 3DS]] XL/LL || RED
|-
| New 2DS XL/LL || JAN
|}

The DS had the product code NTR (short for Nitro), so we see the TR is recurring.

== Title ID and Unique ID ==
''see [[Titles]]''

== NCCH Product Code ==

This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.

The product code is located in a [[NCCH]]'s header (not its ExHeader).

The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".

So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".

A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:

[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]

{| class="wikitable"
! Category letter !! Description
|-
| P || Cartridge software, or downloadable versions of them.
|-
| N || Digital-only releases, including [[Title list|system applications and applets]].
|-
| M || [[DLC]]
|-
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.
|-
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.
|}

The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].

See the next chapter for explanation of the other components of the Product Code.

== Physical Serial ==

[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]

{| class="wikitable"
! Field !! Length !! Description !! colspan=2 | Values
|-
|-align=center
| rowspan="6" | Product
| rowspan="6" | 2
| rowspan="6" | Product type
|-
| LN || Cartridge
|-
| MA || Instruction manual
|-
| TS || Game box
|-
| FA || Leaflet
|-
| MK || Quick-start Guide
|-align=center
| rowspan="3" | Retail/Demo
| rowspan="3" | 1
| rowspan="3" |
|-
| A || Retail
|-
| Z || Demo
|-align=center
| rowspan="3" | CTR/KTR
| rowspan="3" | 3
| rowspan="3" | Platform
|-
| CTR || 3DS
|-
| KTR || New 3DS
|-align=center
| rowspan="11" | Type
| rowspan="11" | 1
| rowspan="11" |
|-
| A || retail
|-
| B || retail
|-
| C || used for N3DS exclusive retail and default 'CTAP'
|-
| E || used for card 2 type retail cartridges
|-
| H || used for built in applications like [[Mii Maker]]
|-
| J || normal eShop Title
|-
| K || unknown, seen in Mighty Gunvolt
|-
| S || usually a 3D Classics eShop title
|-
| P || used with GBA eShop titles
|-
| T || used with NES eShop titles
|-align=center
| Identifier
| 2
| colspan=3 |Game name (two alphanumeric characters)
|-align=center
| rowspan="10" | Region
| rowspan="10" | 1
| rowspan="10" |
|-
| E || English (US)
|-
| P || PAL (Europe/Australia)
|-
| J || Japanese (Japan)
|-
| K || Korean (Korea)
|-
| C || Chinese (China/Taiwan)
|-
| Y || Multiple regions
|-
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)
|-
| Z || Multiple regions
|-
| A || All (region-free)
|-
|-align=center
| rowspan="12" | Label Region
| rowspan="12" | 3
| rowspan="12" |
|-
| USA || United States
|-
| EUR || Europe
|-
| CAN || Canada
|-
| AUS || Australia
|-
| JPN || Japan
|-
| KOR || Korea
|-
| TWN || Taiwan/Hong Kong
|-
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")
|-
| CHN || China
|-
| UKV || United Kingdom ("United Kingdom version")
|-
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")
|}

=== Electronic Manuals ===

Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:

CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]

CTR-[Type][Identifier][Region]-[Region]-[Digit]

* P/N/T/U - Same as in product code structure
* [Type][Identifier][Region] - Same as in serial structure
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.

'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.

==Back of Card Serial==
AREPY10111 (example)

AAAABCDEEE (presumably) 
'''A''' - Identifier (last 4 digits of product code) 
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec) 
'''C''' - Production Year (2010 + C) 
'''D''' - Revision 
'''E''' - Production Run? (000-999)

Serials

2018-02-28T14:24:19Z

D0k3: /* Physical Serial */

This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).

== Console Serial Numbers ==

A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.

The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)

After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.

Example: CW404567772

The non-check digits are 40456777. Separating into odd and even groups, we get the following:

Odds: 4 + 4 + 6 + 7 = 21
Evens: 0 + 5 + 7 + 7 = 19

Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.

The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.

The current serial number scheme began with the DSi, hence its listing in the tables below. Among standalone consoles, the Wii U belongs to this scheme as well; the Switch started a new scheme.

{| class="wikitable"
! Model !! Device Prefix (Retail) !! Device Prefix (Dev/Test)
|-
| ''DSi'' || T || V
|-
| ''DSi XL/LL'' || W || ''unknown''
|-
| ''Wii U'' || F || ''unknown''
|-
| 3DS || C || E
|-
| 3DS XL/LL || S || R
|-
| 2DS || A || P
|-
| New 3DS || Y || Y
|-
| New 3DS XL/LL || Q || Q
|-
| New 2DS XL/LL || N || N
|}

Test ("Panda") units with the same prefix as retail can be distinguished by test units having 00 or 01 as the first two digits of the serial number portion. 00 was used with the New 3DS and New 3DS XL for test units; 01 was used with the New 2DS XL test unit. Preview versions of the N2DS XL given out to the press had 01; these appear to have been test units with the development titles deleted.

Old 3DS development systems (Partner-CTR, IS-CTR-BOX, IS-SPR-BOX) use the "E" and "R" prefixes like test systems, but have 90 (Partner-CTR) or 91 (IS-CTR-BOX, IS-SPR-BOX) as their first two digits. Similarly, the main New 3DS development unit, IS-SNAKE-BOX, uses the Y prefix (same as retail) with 91. It is currently unknown what is the serial number format of the rare New 3DS XL development system (IS-CLOSER-BOX).

{| class="wikitable"
! Sales Region !! Region Lock !! Region Suffix
|-
| Japan || Japan || JF, JH, JM
|-
| North America || North America || W
|-
| Middle East / Southeast Asia || North America || S
|-
| Europe || Europe || EF, EH, EM
|-
| Australia || Europe || AH, AG
|-
| South Korea || Korea || KF, KH, KM
|-
| China (iQue) || China || CF, CH, CM
|}

== Console Models ==

{| class="wikitable"
! Device !! Product Code
|-
| ''DS'' || NTR
|-
| ''DS lite'' || USG
|-
| ''DSi'' || TWL
|-
| ''DSi XL/LL'' || UTL
|-
| ''Wii U'' || WUP
|-
| 3DS || CTR
|-
| 3DS XL/LL || SPR
|-
| 2DS || FTR
|-
| [[New 3DS]] || KTR
|-
| [[New 3DS]] XL/LL || RED
|-
| New 2DS XL/LL || JAN
|}

The DS had the product code NTR (short for Nitro), so we see the TR is recurring.

== Title ID and Unique ID ==
''see [[Titles]]''

== NCCH Product Code ==

This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.

The product code is located in a [[NCCH]]'s header (not its ExHeader).

The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".

So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".

A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:

[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]

{| class="wikitable"
! Category letter !! Description
|-
| P || Cartridge software, or downloadable versions of them.
|-
| N || Digital-only releases, including [[Title list|system applications and applets]].
|-
| M || [[DLC]]
|-
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.
|-
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.
|}

The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].

See the next chapter for explanation of the other components of the Product Code.

== Physical Serial ==

[Product][Retail/Demo]-CTR-[Type][Identifier][Region]-[Label Region]

{| class="wikitable"
! Field !! Length !! Description !! colspan=2 | Values
|-
|-align=center
| rowspan="6" | Product
| rowspan="6" | 2
| rowspan="6" | Product type
|-
| LN || Cartridge
|-
| MA || Instruction manual
|-
| TS || Game box
|-
| FA || Leaflet
|-
| MK || Quick-start Guide
|-align=center
| rowspan="3" | Retail/Demo
| rowspan="3" | 1
| rowspan="3" |
|-
| A || Retail
|-
| Z || Demo
|-align=center
| rowspan="3" | CTR/KTR
| rowspan="3" | 3
| rowspan="3" | Platform
|-
| CTR || 3DS
|-
| KTR || New 3DS
|-align=center
| rowspan="11" | Type
| rowspan="11" | 1
| rowspan="11" |
|-
| A || retail
|-
| B || retail
|-
| C || part of the default serial 'CTAP', also used for N3DS exclusive retail
|-
| E || typically used for card 2 type retail cartridges
|-
| H || used for built in applications like [[Mii Maker]]
|-
| J || normal eShop Title
|-
| K || unknown, seen in Mighty Gunvolt
|-
| S || usually a 3D Classics eShop title
|-
| P || used with GBA eShop titles
|-
| T || used with NES eShop titles
|-align=center
| Identifier
| 2
| colspan=3 |Game name (two alphanumeric characters)
|-align=center
| rowspan="10" | Region
| rowspan="10" | 1
| rowspan="10" |
|-
| E || English (US)
|-
| P || PAL (Europe/Australia)
|-
| J || Japanese (Japan)
|-
| K || Korean (Korea)
|-
| C || Chinese (China/Taiwan)
|-
| Y || Multiple regions
|-
| W || Tai'''w'''an(?) (Taiwan/Hong Kong)
|-
| Z || Multiple regions
|-
| A || All (region-free)
|-
|-align=center
| rowspan="12" | Label Region
| rowspan="12" | 3
| rowspan="12" |
|-
| USA || United States
|-
| EUR || Europe
|-
| CAN || Canada
|-
| AUS || Australia
|-
| JPN || Japan
|-
| KOR || Korea
|-
| TWN || Taiwan/Hong Kong
|-
| CHT || Taiwan/Hong Kong ("Chinese-Traditional")
|-
| CHN || China
|-
| UKV || United Kingdom ("United Kingdom version")
|-
| MDE || Saudi Arabia/U.A.E./Malaysia/Singapore ("Middle East")
|}

=== Electronic Manuals ===

Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:

CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]

CTR-[Type][Identifier][Region]-[Region]-[Digit]

* P/N/T/U - Same as in product code structure
* [Type][Identifier][Region] - Same as in serial structure
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)
* [Digit] - A single digit usually '1' or '0' (not always present). Possibly revision or manual revision.

'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.

==Back of Card Serial==
AREPY10111 (example)

AAAABCDEEE (presumably) 
'''A''' - Identifier (last 4 digits of product code) 
'''B''' - Production Month (X,Y,Z -> Oct,Nov,Dec) 
'''C''' - Production Year (2010 + C) 
'''D''' - Revision 
'''E''' - Production Run? (000-999)

Bootloader

2018-01-16T00:10:53Z

D0k3: /* Boot11 image data memory layout */ Fixed a typo again

The bootloader is the binary code stored in the ARM9 and ARM11 boot ROMs and hence is ran when the 3DS is powered on. It's purpose is initializing hardware and loading the [[FIRM|system firmware]] from the internal [[Flash_Filesystem|NAND memory]]..

Besides NATIVE_FIRM, the bootloader is also capable of booting other firmwares (such as TWL_FIRM and AGB_FIRM). However, this will result either in a japanese error-screen or a system shutdown, directly after FIRM-Launching.

== Boot ROM ==
Upon boot, parts of the ARM9 and ARM11 boot ROMs are protected by writing to [[CONFIG#CFG_SYSPROT9|CFG_SYSPROT9]] and [[CONFIG#CFG_SYSPROT11|CFG_SYSPROT11]], respectively. The ARM9 and ARM11 boot ROMs are identical for all 3DS consoles (3DS, 3DS XL, 2DS, New 3DS, New 3DS XL, New 2DS XL)

== NAND FIRM boot ==
Boot9 is not hard-coded to only handle 2 FIRM partitions: it parses all 8 NCSD partitions for this. Boot9 will attempt to use every partition listed in the NCSD which is an actual FIRM partition, in the same order listed in the NCSD, until booting one of them succeeds. Among the not-yet-processed partitions, the FIRM which has the highest value at u32 firmhdr+4 will have a FIRM-boot attempted first. Since that value is normally 0x0, the order of FIRM-partition processing is normally identical to the order of the NCSD partitions.

Boot9 is hard-coded for using [[AES_Registers|AES]] keyslot 0x6 for NAND crypto.

== Non-NAND FIRM boot ==
Boot9 can also boot from non-NAND. For this a different set of RSA pubks are used(separate pubks for retail/devunit like NAND). The spiflash FIRM image for this is also encrypted with AES-CBC using a normalkey stored in prot_boot9(separate for retail/devunit). This encryption is basically used instead of what is used for NAND-firm-partitions. This encryption is only used for the FIRM sections, the FIRM header is used raw. The AES keyslot for this is only overwritten afterwards when booting from non-NAND fails. AES keyslot 0x3F is used for this.

CTR_word[0] = firmimageoffset;//FIRM section offset from FIRM header
CTR_word[1] = outbufaddr;//FIRM section load addr
CTR_word[2] = readsize;//FIRM section size
CTR_word[3] = readsize;//FIRM section size

When booting from NAND fails, boot9 will then attempt to boot from Wifi SPI-flash(this only triggers when the wifi module hw is properly accessible/connected, which is normally the case). The base offset for spiflash FIRM is 0x400. Note that this region(all data prior to offset 0x1F300) is write-protected by the spiflash(not writable from 3DS-mode / DS-mode).

Additionally, if the shell is closed and a special key combination (Start + Select + X) is held, boot9 will attempt to boot from an inserted NTR cartridge before booting from NAND. Note: While normally on O3DS/2DS the console will not turn on if the shell is closed (or this is faked by holding a magnet to the console), when this special key combination is held holding down the power button will cause boot to occur anyway.

For non-NAND booting, NCSD / FIRM-backup is not used.

== SDMMC ==

Boot9 has code implemented for using SD(HC) cards, but the input deviceids used by boot9 for those functions are hard-coded for NAND. However, it is possible to use an SD(HC) card in place of the NAND if the NAND chip is first disconnected, and a SD card connected to the bus. Due to the CID being different, partitions will need to be re-encrypted and TWL mode will not work, due to the MBR being in the NCSD header. Using sighax, it may be possible to replace the NCSD header.

== Boot9 RSA keyslots ==

The following are initialized during main() startup, by initialize_rsakeyslots_pubk(). Each of these, for the ones which are actually set, have different keydata for retail/devunit.
* 0: Not set.
* 1: Used for the NAND FIRM signature.
* 2: Used for the non-NAND-FIRM signature.
* 3: Used for the NAND-NCSD FIRM signature.

When FIRM loading is successful, initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk() is called, right before calling the final function in main(). Besides ITCM writing, this overwrites all 4 RSA keyslots with modulus + private-exponents loaded from boot9 data.

initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk():
This initializes the 4 0x100-byte/0x200-byte chunks at 0x07ffb800+0x500(0x07ffbd00)/0x07ffb800+0x900(0x07ffc100). End address of the first section is 0x07ffc100(start addr of the second section), end address of the second section is 0x07ffc900. Hence, the first section total size is 0x400-bytes, while the second section total size is 0x800-bytes.

These are initialized using via the boot9 data image, with ptrs from DTCM. Seperate keydata is used for retail/devunit.

When initializing the first ITCM area: rsa_setkeyslot_privk() is called for all 4 RSA keyslots. The modulo for each one is also copied to (index*0x100) + 0x07ffb800 + 0x500. The private exponent is not copied into ITCM.

The second ITCM area is initialized by copying 4 0x200-byte entries in a loop. These are RSA pubks+privks, which Boot9 doesn't use itself at all besides this copy loop.

== Boot9 image data memory layout ==
0xffffb088 is the beginning of the boot9 image data section.

* 0xffffb088 size 0x38-bytes: This is the array used during FIRM-section-loading for the memory-range blacklist for FIRM sections.
* 0xffffb0c0(end-addr of the above area) size 0x20-bytes: Unknown.
* 0xffffb0e0(end-addr of the above area) size 0x2f80-bytes: This is *all* of the keys stored in the image.
* 0xffffe060(end addr of the above key-area) size 0x230-bytes: This is the initial DTCM image @ 0xFFF00000, see below.
* 0xffffe290(DTCM_image_end) - {boot9 image end}: All-zero.

Layout of the 0x2f80-byte key-area at 0xffffb0e0:
* 0xffffb0e0 size 0x2600-bytes: This is the RSA key-data, see below.
* 0xffffd6e0(end-addr of the above area) size 0x40-bytes: This is the keydata used for crypting the entire OTP with keyslot 0x3f, used by main(). The first 0x20-bytes is for retail, the remaining 0x20-bytes starting at 0xffffd700 is for devunit. Chunk+0(retail=0xffffd6e0 devunit=0xffffd700) is the normalkey, chunk+0x10(retail=0xffffd6f0 devunit=0xffffd710) is the AES-IV.
* ...
* 0xffffd760: size 0x100-bytes: First 0x80-bytes is for retail, the remaining 0x80-bytes at 0xffffd7e0 is for devunit. This 0x80-byte block is copied to 0x07ffcd00 by a Boot9 function, however that code actually does the copy in two 0x40-bytes chunks.
* 0xffffd860(end-addr of the above area) size 0x400-bytes: This is the bootrom_dataptr passed to the aes-keyinit function for retail. See the below Tools section for how this is processed.
* 0xffffdc60(end-addr of the above area) size 0x400-bytes: This is the devunit version of the above the 0x400-byte chunk. This is very last chunk of data in the boot9 data-section key-area: end addr for this area is 0xffffe060.

Layout of the 0x2600-byte RSA key-data at 0xffffb0e0:
First 0x1300-bytes is for retail, the remaining 0x1300-bytes starting at 0xffffc3e0 is for devunit.
* +0x0 retail=0xffffb0e0 devunit=0xffffc3e0: RSA modulo for keyslot3, initialized by initialize_rsakeyslots_pubk().
* +0x100 retail=0xffffb1e0 devunit=0xffffc4e0: RSA modulo for keyslot1, initialized by initialize_rsakeyslots_pubk().
* +0x200 retail=0xffffb2e0 devunit=0xffffc5e0: RSA modulo for keyslot2, initialized by initialize_rsakeyslots_pubk().
* +0x300 size 0x200, retail=0xffffb3e0 devunit=0xffffc6e0: First 0x100-bytes is the RSA modulo, then the following 0x100-bytes is the RSA privk(private-exponent). This is for RSA-engine keyslot0 with initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk(), which also copies this modulo to the array starting at 0x07ffbd00.
* +0x500 size 0x200, retail=0xffffb5e0 devunit=0xffffc8e0: Used the same as the above block except for slot1.
* +0x700 size 0x200, retail=0xffffb7e0 devunit=0xffffcae0: Used the same as the above block except for slot2.
* +0x900 size 0x200, retail=0xffffb9e0 devunit=0xffffcce0: Used the same as the above block except for slot3.
* +0xb00 size 0x200, retail=0xffffbbe0 devunit=0xffffcee0: First 0x100-bytes is the RSA modulo, then the following 0x100-bytes is the RSA privk(private-exponent). The 0x200-bytes here is copied to slot0 in the array at 0x07ffc100 by initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk().
* +0xd00 size 0x200, retail=0xffffbde0 devunit=0xffffd0e0: Used the same as the above block except for slot1.
* +0xf00 size 0x200, retail=0xffffbfe0 devunit=0xffffd2e0: Used the same as the above block except for slot2.
* +0x1100 size 0x200, retail=0xffffc1e0 devunit=0xffffd4e0: Used the same as the above block except for slot3.

== Boot9 DTCM layout ==
Most of this is just ptrs / other unknown data, not actual keys. However, there is an unknown 0x10-byte block @ +0x124(there's a ptr initialized for this block elsewhere).

== Boot11 image data memory layout ==
* 0x0001817c..0x000181f4 size 0x78-bytes: This is the bootrom error screen font gfx data. This begins at the exact end-address of the crt0 code, the rest of the protected boot11 code begins at this end-address(0x000181f4). To extract the font gfx data from there, the 30 dwords at this address need to be converted to big endian. The correct resolution (when displayed as raw) is 32x30x1. The bootrom font looks very similar to [https://robey.lag.net/2010/01/23/tiny-monospace-font.html this font].
* 0x00019400 is the beginning of the boot11 data area, the first 8-bytes here are unknown.
* 0x00019408..0x0001b498 size 0x2090-bytes: This is the blowfish keydata which gets copied to arm9itcm_twlkeydata+0x3e0 later.
* 0x0001c498..0x0001c4f8 size 0x60-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x380.
* 0x0001c4f8..0x0001c538 size 0x40-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x340.
* 0x0001c538..0x0001c578 size 0x40-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x300.
* 0x0001c578..0x0001c5f8 size 0x80-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x280.
* 0x0001c5f8..0x0001c678 size 0x80-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x0.
* 0x0001c678..0x0001c878 size 0x200-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x80.
* 0x0001c878..0x0001d078 size 0x800-bytes: These are the 3DS RSA-2048 modulus which are eventually copied to arm9_itcm+0x4900: on retail the first 4 are copied there by boot9, on devunit the last 4 are copied to itcm.
* 0x0001d078 size 0x120-bytes is the initial data for the .data section @ 0x1ffe8000, this is the very end of the protected arm11-bootrom.

== AES keys ==
See the Tools section for how Boot9 initializes the keyslots.

See also [[AES_Registers|here]].

For an issue with console-unique key-init, see [[OTP_Registers|here]].

== BootROM Errors ==
Sample error-screen(where firm0+firm1 RSA signatures were corrupted):

BOOTROM 8046
ERRCODE: 00F800FF
DEDEFFFF FFFFFFFF
00000000 00000000

* 1st line is: <code>print_string(..., "BOOTROM %X", 0x8046);//This last param comes from the .pool.</code>
* 2nd line is: <code>print_string(..., "ERRCODE: %08X", *((unsigned int*)(0x1FFFE000+0xC)));//See below memory notes.</code>
* 3rd line is: <code>print_string(..., "%08X %08X", *((unsigned int*)(0x1FFFE000+0x10))`, `*((unsigned int*)(0x1fffe000+0x14)));//See below memory notes.</code>
* 4th line is: <code>print_string(..., "%08X %08X",*((unsigned int*)(0x1FFFE000+0x18))`, `*((unsigned int*)(0x1fffe000+0x1C)));//See below memory notes.</code>

== 0x1FFFE000 memory ==
This memory is used by boot9 mainly for sending info to the arm11 for the error-screen. The data in this region is still stored in memory by the time the ARM9+ARM11 jumps to FIRM.

Among boot9/boot11, the 3 words at 0x1FFFE000 seem to be ''only'' accessed by the boot11 function initializing those words.

* u32 0x1FFFE000+0: ARM11 MPCore "Cycle Counter Register (CCNT)".
* u32 0x1FFFE000+4: ARM11 MPCore "Count Register 0 (PMN0)".
* u32 0x1FFFE000+8: ARM11 MPCore "Count Register 1 (PMN0)".
* 8bit-entry-array 0x1FFFE000+0xC: 8bit status-codes initialized by boot9 main(), for the FIRM-boot devices. +0 is NAND, +1 is NTRCARD and +2 is wifi-spiflash.
* ...
* 8bit-entry-array 0x1FFFE000+0x10: Status-codes originally from nand_findfirmpartition_loadfirm(), for each of the 8 NCSD partitions.

== BootROM Status Codes ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x00
| Success
|-
| 0xEE(~17)
| NCSD header validation function failed: NCSD magicnum is invalid or RSA verification failed.
|-
| 0xDE(~33)
| FIRM header validation function failed: FIRM magicnum is invalid or RSA verification failed.
|-
| 0xDF(~32)
| Failed to read sector data from the device.
|-
| 0xCF(~48)
| FIRM section validation function failed: FIRM section is invalid.
|-
| 0xF7(~8)
| A NAND FIRM from another partition was already found with a priority(firmhdr+4) >= to the value for the current partition's FIRM priority.
|-
| 0xF8(~7)
| The FIRM magicnum(firmhdr+0) is invalid.
|-
| 0xFF(~0)
| Initial value for each entry in the 8-entry array of status-codes for the NAND NCSD partitions. Indicates that the partition is not a FIRM partition(partition fs type isn't 0x3 or partition fs crypt-type isn't 0x2).
|}

== Boot9 startup ==

0xffff0000 jumps to 0xffff8000. 0xffff8000 is crt0:
* Very first thing this does is clear u8 register 0x10000002 ([[CONFIG_Registers#CFG_RST11|CFG_RST11]]) bit 0 to zero.
* Then sp is initialized for each cpumode, IRQs/FIQs are disabled during the first mode-switch.
* Order of mode-switches + sp initialization: svc-mode = 0xfff04000, irq-mode = 0xfff03f00, system-mode = 0xfff03b00. Hence, the rest of the code following this runs in system-mode.
* Then L_ffff80cc/mpu_init() is called.
* Then L_ffff0038() is called, which initializes the exception-handler addresses @ 0x08000000.
* Then L_ffff81b8() is called(r4 + lr are saved on the DTCM stack), which after calling a memclear function which doesn't do anything, it then clears 0x08000030 size 0x10. Here the DTCM at 0xfff00000 size 0x4000 is cleared.
* Then L_ffff81b4() is called, which branches to DTCM_init(). This copies the initial DTCM data from the Boot9 data image into boot9, then it clears 0xFFF00230 - 0xFFF01AC0.
* Then LT_ffff8228/main is jumped to, with LR set to the address of an infinite-branch-loop instruction.

mpu_init():
* Bitmask 0x000f9005 is cleared in the cp15 control register. MCR instructions which do then following are then executed: flush entire instruction cache, flush entire data cache, and drain write buffer.
* Then the 8 [[Memory_layout|MPU]] memregions are initialized.
* ITCM memregion reg = 0x24: baseaddr=0x0, size = 128MB(0x08000000).
* DTCM memregion reg = 0xfff0000a: baseaddr=0xfff00000, size=16KB(0x00004000).
* Then instruction cachable and data cachable/bufferable bits for the MPU regions are setup.
* Then the instruction/data access permissions for the MPU regions are setup.
* Lastly bitmask 0x0005707d is orred in the cp15 control register.

== Boot9 main() ==

The following functions are called: LT_ffff2024(), LT_ffff1ff8(), pxi_init(), rsa_init(), initialize_rsakeyslots_pubk(), crypto_initialize(), and aesengine_reset().
Then AES keyslot 0x3F is setup: aesengine_setnormalkey(0x3f, 5, ptr) is called. ptr on retail(CFG_UNITINFO check) is 0xffffd6e0, 0xffffd700 for devunit. Then essentially, aesengine_setctr(5, ptr+0x10) is executed.
Then AES keyslot 0x3f is selected.
When calling the following functions, if any of them return zero, it will immediately jump to setting ptr to 0x10012000(otp), otherwise when all of them return non-zero ptr = sp+0x94. otp_decrypt(sp+4), otp_verify(sp+4), initialize_consoleunique_itcm(sp+4, 0x07ffb800).
Then the following is executed: initialize_aeskeys_wrap(ptr, 0x70);
Then sp+4 size 0x100 is cleared to zero.

...

NAND firm-boot code-block, is described below. Note that boot9 is basically hard-coded to use deviceid NAND, not SD.
{
timer_updatestoredstate() is called, then the AES keyslot for NAND-FIRM is selected(0x6).
Then LT_ffff56c8() is called, if that returns non-zero the statuscode variable is set to ~2 then it jumps to NAND_BOOTEND.
Then LT_ffff5774(0x201) is called, if that returns non-zero the statuscode variable is set to ~1 then it jumps to NAND_BOOTEND.
Then fsdriver_setup_mmc() is called. Then nand_findfirmpartition_loadfirm(0) is called, with the statuscode variable set to the retval.
Executes a loop which runs 8 times: write the output from get_errorcode_arrayentry_xfff005e8(loopindex) to u8 0x1fffe000+0x10+loopindex(copy the array of 32bit error-codes for all 8 NCSD partitions initialized by nand_findfirmpartition_loadfirm() to the array of 8bit entries at 0x1fffe000+0x10).

NAND_BOOTEND:
Then the statuscode variable is written to u8 0x1fffe000+0xc.
Then LT_ffff5690(0x201, 0x1fffe018, 0x1fffe01c) is called.
Then LT_ffff5644() is called.
Then timer_updatestoredstate() is called.
When statuscode==0 for success, it jumps to FIRMLOAD_END. Otherwise, it continues to the next code-block.
}

Wifi spi-flash firm-boot code-block, executed when no FIRM was loaded successfully so far.
{
timer_updatestoredstate() is called.

Then spi_wififlash_cmdgetstatusreg(sp+0x100) is executed. When bit0 of the output u8 at sp+0x100 is clear, it will continue this code-block, otherwise it will set the statuscode variable to ~1 then jump to SPIFLASH_BOOTEND.
Then fsdriver_setup_wififlash() is called.
Here read_firmhdr_validate_loadfirm(0, 2) is called, with the statuscode variable set to the retval.

SPIFLASH_BOOTEND:
Then the statuscode variable is written to u8 0x1fffe000+0xe.
Then timer_updatestoredstate() is called.
When statuscode==0 for success, it jumps to FIRMLOAD_END. Otherwise, it executes writenormalkey_keyslot3f(), then jumps to FIRMLOAD_FAILURE.
}

FIRMLOAD_END:
Here it calls firmhdr_getarm11_entrypoint() and firmhdr_getarm9_entrypoint(). Immediately after calling each function it checks if the retval is 0, if so it then jumps to FIRMLOAD_FAILURE.
After calling initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk(), it jumps to FIRMLOAD_EXIT.

FIRMLOAD_FAILURE:
Here it clears 0x07ffb800 size 0x3c70 to zero, endaddr = 0x07fff470.
Then it continues to FIRMLOAD_EXIT.

FIRMLOAD_EXIT:
Here firmboot() is called, which should never return. The instruction after this bl is a call for panic().

== Boot11 ==

* ...

main():
LT_1263c();
...
LT_13944()
...
pxi_init();
initializefuncptr_firmboot_start(firmbootbegin_funcptr);
firmboot();
return;

LT_12220/initializefuncptr_firmboot_start
inr0=funcptr
This writes inr0 to address 0x1ffe8028, then returns.
This initializes the funcptr which firmboot() can call after the very first func-call.

LT_13944
if([[I2C_Registers|i2cmcu_readregf]](sp+0)==0)
{
return (*((u8*)0x10147000) >> 4) & 1;//Reads [[GPIO_Registers|GPIO]] when reading I2C fails.
}
Here it basically does "return <byte loaded from sp+0> ^ 0x2". Hence in this case, it will return 0x2 when the system shell is closed(sleep-mode), otherwise 0x0 is returned.

LT_12454/firmboot
This is the arm11 version of the boot9 firmboot() function, like boot9 this is the final function called from main(). The functionality for these two functions are identical, minus addresses.
ptr = firmboot_loadentrypoint11();
funcptr = *(0x1ffe8028);
if(funcptr)funcptr(ptr);
LT_11ffc(ptr);
return;

== Boot Procedure ==

* 0 seconds - unit is powered on. The ARM9 and ARM11 [[Memory_layout|bootroms]] begin execution.
* <= ~1 second - BootROMs fully run, load FIRM, etc. The loaded FIRM begins running.
**The ARM11 sysmodules included with FIRM are launched by ARM11-kernel, etc.
**The [[Process_Manager_Services|PM]] module launches [[NS]].
**If [[Home_Menu#Auto-Boot_Function|auto-booting]] is needed, NS will [[NS#Auto-boot|auto-boot]] titles.
**Otherwise, NS will instead launch [[ErrDisp]] and the [[Configuration Memory#ACTIVEMENUTID|current active menu]] via the PM module. For retail units, this menu is usually the [[Home Menu]]. Note that the PM module first launches the module dependencies when launching a process, prior to actually launching the process.
**The further Home Menu startup process is described [[Home_Menu#Home_Menu_startup|here]]. This includes Home Menu manually launching various sysmodules.

* 4 seconds - the LCD screens are initialized.

* 7 seconds - [[Home Menu]] is fully initialized/loaded.

== NAND Reads during Boot ==
During a successful boot on 6.x, the bootloader (and firm) reads the following sectors from NAND (in this order):
00000000 (NCSD Partition Table)

Only verify 'FIRM' magic? (A second Header-read will be attempted even if everything except the magic is 0xFF...)
0B130000 (FIRM Partition)
0B530000 (Secondary FIRM Partition)

Verify RSA signature and parse Header:
0B130000 (FIRM: Header)
0B130200 (FIRM: Section 1)
0B163E00 (FIRM: Section 2)
0B193E00 (FIRM: Section 3)

00013000 .. Below is probably NATIVE_FIRM booting ..
00014000
00015000
00016000
00017000

09011A00
09011C00
09012000
09012400
...

== Error Codes ==
When the 3DS does not find the NAND chip, the following error is displayed:

[[Image:CTR_Bootrom_Error.jpg|240px]]

{| class="wikitable" border="1"
|-
! Error
! Description
|-
| <tt>00F800FE 00000000 00000000 00000200 00000000</tt>
| Error when having SD-card reader connected to NAND during boot.
|-
| <tt>00F800FE 00000000 00000000 00000400 00000000</tt>
| NAND not found error (?)
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000080 00800000</tt>
| NAND error when DAT1 was used as DAT0.
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000005 00800000</tt>
| NAND error when DAT2 was used as DAT0.
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000005 00000000</tt>
| NAND error when DAT3 was used as DAT0.
|-
| <tt>00F800FF F8F8FFFF FFFFFFFF 00000000 00000000</tt>
| Both the firm0 and firm1 partitions are corrupt (failed signature checks).
|-
| <tt>00F800EE FFFFFFFF FFFFFFFF 00000000 00000000</tt>
| [[NCSD]] header in sector 0 is corrupt (failed signature check).
|}

== Tools ==
* [https://github.com/yellows8/boot9_tools boot9_tools]

Bootloader

2018-01-16T00:10:15Z

D0k3: /* Boot11 image data memory layout */ fixed wording

The bootloader is the binary code stored in the ARM9 and ARM11 boot ROMs and hence is ran when the 3DS is powered on. It's purpose is initializing hardware and loading the [[FIRM|system firmware]] from the internal [[Flash_Filesystem|NAND memory]]..

Besides NATIVE_FIRM, the bootloader is also capable of booting other firmwares (such as TWL_FIRM and AGB_FIRM). However, this will result either in a japanese error-screen or a system shutdown, directly after FIRM-Launching.

== Boot ROM ==
Upon boot, parts of the ARM9 and ARM11 boot ROMs are protected by writing to [[CONFIG#CFG_SYSPROT9|CFG_SYSPROT9]] and [[CONFIG#CFG_SYSPROT11|CFG_SYSPROT11]], respectively. The ARM9 and ARM11 boot ROMs are identical for all 3DS consoles (3DS, 3DS XL, 2DS, New 3DS, New 3DS XL, New 2DS XL)

== NAND FIRM boot ==
Boot9 is not hard-coded to only handle 2 FIRM partitions: it parses all 8 NCSD partitions for this. Boot9 will attempt to use every partition listed in the NCSD which is an actual FIRM partition, in the same order listed in the NCSD, until booting one of them succeeds. Among the not-yet-processed partitions, the FIRM which has the highest value at u32 firmhdr+4 will have a FIRM-boot attempted first. Since that value is normally 0x0, the order of FIRM-partition processing is normally identical to the order of the NCSD partitions.

Boot9 is hard-coded for using [[AES_Registers|AES]] keyslot 0x6 for NAND crypto.

== Non-NAND FIRM boot ==
Boot9 can also boot from non-NAND. For this a different set of RSA pubks are used(separate pubks for retail/devunit like NAND). The spiflash FIRM image for this is also encrypted with AES-CBC using a normalkey stored in prot_boot9(separate for retail/devunit). This encryption is basically used instead of what is used for NAND-firm-partitions. This encryption is only used for the FIRM sections, the FIRM header is used raw. The AES keyslot for this is only overwritten afterwards when booting from non-NAND fails. AES keyslot 0x3F is used for this.

CTR_word[0] = firmimageoffset;//FIRM section offset from FIRM header
CTR_word[1] = outbufaddr;//FIRM section load addr
CTR_word[2] = readsize;//FIRM section size
CTR_word[3] = readsize;//FIRM section size

When booting from NAND fails, boot9 will then attempt to boot from Wifi SPI-flash(this only triggers when the wifi module hw is properly accessible/connected, which is normally the case). The base offset for spiflash FIRM is 0x400. Note that this region(all data prior to offset 0x1F300) is write-protected by the spiflash(not writable from 3DS-mode / DS-mode).

Additionally, if the shell is closed and a special key combination (Start + Select + X) is held, boot9 will attempt to boot from an inserted NTR cartridge before booting from NAND. Note: While normally on O3DS/2DS the console will not turn on if the shell is closed (or this is faked by holding a magnet to the console), when this special key combination is held holding down the power button will cause boot to occur anyway.

For non-NAND booting, NCSD / FIRM-backup is not used.

== SDMMC ==

Boot9 has code implemented for using SD(HC) cards, but the input deviceids used by boot9 for those functions are hard-coded for NAND. However, it is possible to use an SD(HC) card in place of the NAND if the NAND chip is first disconnected, and a SD card connected to the bus. Due to the CID being different, partitions will need to be re-encrypted and TWL mode will not work, due to the MBR being in the NCSD header. Using sighax, it may be possible to replace the NCSD header.

== Boot9 RSA keyslots ==

The following are initialized during main() startup, by initialize_rsakeyslots_pubk(). Each of these, for the ones which are actually set, have different keydata for retail/devunit.
* 0: Not set.
* 1: Used for the NAND FIRM signature.
* 2: Used for the non-NAND-FIRM signature.
* 3: Used for the NAND-NCSD FIRM signature.

When FIRM loading is successful, initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk() is called, right before calling the final function in main(). Besides ITCM writing, this overwrites all 4 RSA keyslots with modulus + private-exponents loaded from boot9 data.

initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk():
This initializes the 4 0x100-byte/0x200-byte chunks at 0x07ffb800+0x500(0x07ffbd00)/0x07ffb800+0x900(0x07ffc100). End address of the first section is 0x07ffc100(start addr of the second section), end address of the second section is 0x07ffc900. Hence, the first section total size is 0x400-bytes, while the second section total size is 0x800-bytes.

These are initialized using via the boot9 data image, with ptrs from DTCM. Seperate keydata is used for retail/devunit.

When initializing the first ITCM area: rsa_setkeyslot_privk() is called for all 4 RSA keyslots. The modulo for each one is also copied to (index*0x100) + 0x07ffb800 + 0x500. The private exponent is not copied into ITCM.

The second ITCM area is initialized by copying 4 0x200-byte entries in a loop. These are RSA pubks+privks, which Boot9 doesn't use itself at all besides this copy loop.

== Boot9 image data memory layout ==
0xffffb088 is the beginning of the boot9 image data section.

* 0xffffb088 size 0x38-bytes: This is the array used during FIRM-section-loading for the memory-range blacklist for FIRM sections.
* 0xffffb0c0(end-addr of the above area) size 0x20-bytes: Unknown.
* 0xffffb0e0(end-addr of the above area) size 0x2f80-bytes: This is *all* of the keys stored in the image.
* 0xffffe060(end addr of the above key-area) size 0x230-bytes: This is the initial DTCM image @ 0xFFF00000, see below.
* 0xffffe290(DTCM_image_end) - {boot9 image end}: All-zero.

Layout of the 0x2f80-byte key-area at 0xffffb0e0:
* 0xffffb0e0 size 0x2600-bytes: This is the RSA key-data, see below.
* 0xffffd6e0(end-addr of the above area) size 0x40-bytes: This is the keydata used for crypting the entire OTP with keyslot 0x3f, used by main(). The first 0x20-bytes is for retail, the remaining 0x20-bytes starting at 0xffffd700 is for devunit. Chunk+0(retail=0xffffd6e0 devunit=0xffffd700) is the normalkey, chunk+0x10(retail=0xffffd6f0 devunit=0xffffd710) is the AES-IV.
* ...
* 0xffffd760: size 0x100-bytes: First 0x80-bytes is for retail, the remaining 0x80-bytes at 0xffffd7e0 is for devunit. This 0x80-byte block is copied to 0x07ffcd00 by a Boot9 function, however that code actually does the copy in two 0x40-bytes chunks.
* 0xffffd860(end-addr of the above area) size 0x400-bytes: This is the bootrom_dataptr passed to the aes-keyinit function for retail. See the below Tools section for how this is processed.
* 0xffffdc60(end-addr of the above area) size 0x400-bytes: This is the devunit version of the above the 0x400-byte chunk. This is very last chunk of data in the boot9 data-section key-area: end addr for this area is 0xffffe060.

Layout of the 0x2600-byte RSA key-data at 0xffffb0e0:
First 0x1300-bytes is for retail, the remaining 0x1300-bytes starting at 0xffffc3e0 is for devunit.
* +0x0 retail=0xffffb0e0 devunit=0xffffc3e0: RSA modulo for keyslot3, initialized by initialize_rsakeyslots_pubk().
* +0x100 retail=0xffffb1e0 devunit=0xffffc4e0: RSA modulo for keyslot1, initialized by initialize_rsakeyslots_pubk().
* +0x200 retail=0xffffb2e0 devunit=0xffffc5e0: RSA modulo for keyslot2, initialized by initialize_rsakeyslots_pubk().
* +0x300 size 0x200, retail=0xffffb3e0 devunit=0xffffc6e0: First 0x100-bytes is the RSA modulo, then the following 0x100-bytes is the RSA privk(private-exponent). This is for RSA-engine keyslot0 with initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk(), which also copies this modulo to the array starting at 0x07ffbd00.
* +0x500 size 0x200, retail=0xffffb5e0 devunit=0xffffc8e0: Used the same as the above block except for slot1.
* +0x700 size 0x200, retail=0xffffb7e0 devunit=0xffffcae0: Used the same as the above block except for slot2.
* +0x900 size 0x200, retail=0xffffb9e0 devunit=0xffffcce0: Used the same as the above block except for slot3.
* +0xb00 size 0x200, retail=0xffffbbe0 devunit=0xffffcee0: First 0x100-bytes is the RSA modulo, then the following 0x100-bytes is the RSA privk(private-exponent). The 0x200-bytes here is copied to slot0 in the array at 0x07ffc100 by initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk().
* +0xd00 size 0x200, retail=0xffffbde0 devunit=0xffffd0e0: Used the same as the above block except for slot1.
* +0xf00 size 0x200, retail=0xffffbfe0 devunit=0xffffd2e0: Used the same as the above block except for slot2.
* +0x1100 size 0x200, retail=0xffffc1e0 devunit=0xffffd4e0: Used the same as the above block except for slot3.

== Boot9 DTCM layout ==
Most of this is just ptrs / other unknown data, not actual keys. However, there is an unknown 0x10-byte block @ +0x124(there's a ptr initialized for this block elsewhere).

== Boot11 image data memory layout ==
* 0x0001817c..0x000181f4 size 0x78-bytes: This is to be the bootrom error screen font gfx data. This begins at the exact end-address of the crt0 code, the rest of the protected boot11 code begins at this end-address(0x000181f4). To extract the font gfx data from there, the 30 dwords at this address need to be converted to big endian. The correct resolution (when displayed as raw) is 32x30x1. The bootrom font looks very similar to [https://robey.lag.net/2010/01/23/tiny-monospace-font.html this font].
* 0x00019400 is the beginning of the boot11 data area, the first 8-bytes here are unknown.
* 0x00019408..0x0001b498 size 0x2090-bytes: This is the blowfish keydata which gets copied to arm9itcm_twlkeydata+0x3e0 later.
* 0x0001c498..0x0001c4f8 size 0x60-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x380.
* 0x0001c4f8..0x0001c538 size 0x40-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x340.
* 0x0001c538..0x0001c578 size 0x40-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x300.
* 0x0001c578..0x0001c5f8 size 0x80-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x280.
* 0x0001c5f8..0x0001c678 size 0x80-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x0.
* 0x0001c678..0x0001c878 size 0x200-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x80.
* 0x0001c878..0x0001d078 size 0x800-bytes: These are the 3DS RSA-2048 modulus which are eventually copied to arm9_itcm+0x4900: on retail the first 4 are copied there by boot9, on devunit the last 4 are copied to itcm.
* 0x0001d078 size 0x120-bytes is the initial data for the .data section @ 0x1ffe8000, this is the very end of the protected arm11-bootrom.

== AES keys ==
See the Tools section for how Boot9 initializes the keyslots.

See also [[AES_Registers|here]].

For an issue with console-unique key-init, see [[OTP_Registers|here]].

== BootROM Errors ==
Sample error-screen(where firm0+firm1 RSA signatures were corrupted):

BOOTROM 8046
ERRCODE: 00F800FF
DEDEFFFF FFFFFFFF
00000000 00000000

* 1st line is: <code>print_string(..., "BOOTROM %X", 0x8046);//This last param comes from the .pool.</code>
* 2nd line is: <code>print_string(..., "ERRCODE: %08X", *((unsigned int*)(0x1FFFE000+0xC)));//See below memory notes.</code>
* 3rd line is: <code>print_string(..., "%08X %08X", *((unsigned int*)(0x1FFFE000+0x10))`, `*((unsigned int*)(0x1fffe000+0x14)));//See below memory notes.</code>
* 4th line is: <code>print_string(..., "%08X %08X",*((unsigned int*)(0x1FFFE000+0x18))`, `*((unsigned int*)(0x1fffe000+0x1C)));//See below memory notes.</code>

== 0x1FFFE000 memory ==
This memory is used by boot9 mainly for sending info to the arm11 for the error-screen. The data in this region is still stored in memory by the time the ARM9+ARM11 jumps to FIRM.

Among boot9/boot11, the 3 words at 0x1FFFE000 seem to be ''only'' accessed by the boot11 function initializing those words.

* u32 0x1FFFE000+0: ARM11 MPCore "Cycle Counter Register (CCNT)".
* u32 0x1FFFE000+4: ARM11 MPCore "Count Register 0 (PMN0)".
* u32 0x1FFFE000+8: ARM11 MPCore "Count Register 1 (PMN0)".
* 8bit-entry-array 0x1FFFE000+0xC: 8bit status-codes initialized by boot9 main(), for the FIRM-boot devices. +0 is NAND, +1 is NTRCARD and +2 is wifi-spiflash.
* ...
* 8bit-entry-array 0x1FFFE000+0x10: Status-codes originally from nand_findfirmpartition_loadfirm(), for each of the 8 NCSD partitions.

== BootROM Status Codes ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x00
| Success
|-
| 0xEE(~17)
| NCSD header validation function failed: NCSD magicnum is invalid or RSA verification failed.
|-
| 0xDE(~33)
| FIRM header validation function failed: FIRM magicnum is invalid or RSA verification failed.
|-
| 0xDF(~32)
| Failed to read sector data from the device.
|-
| 0xCF(~48)
| FIRM section validation function failed: FIRM section is invalid.
|-
| 0xF7(~8)
| A NAND FIRM from another partition was already found with a priority(firmhdr+4) >= to the value for the current partition's FIRM priority.
|-
| 0xF8(~7)
| The FIRM magicnum(firmhdr+0) is invalid.
|-
| 0xFF(~0)
| Initial value for each entry in the 8-entry array of status-codes for the NAND NCSD partitions. Indicates that the partition is not a FIRM partition(partition fs type isn't 0x3 or partition fs crypt-type isn't 0x2).
|}

== Boot9 startup ==

0xffff0000 jumps to 0xffff8000. 0xffff8000 is crt0:
* Very first thing this does is clear u8 register 0x10000002 ([[CONFIG_Registers#CFG_RST11|CFG_RST11]]) bit 0 to zero.
* Then sp is initialized for each cpumode, IRQs/FIQs are disabled during the first mode-switch.
* Order of mode-switches + sp initialization: svc-mode = 0xfff04000, irq-mode = 0xfff03f00, system-mode = 0xfff03b00. Hence, the rest of the code following this runs in system-mode.
* Then L_ffff80cc/mpu_init() is called.
* Then L_ffff0038() is called, which initializes the exception-handler addresses @ 0x08000000.
* Then L_ffff81b8() is called(r4 + lr are saved on the DTCM stack), which after calling a memclear function which doesn't do anything, it then clears 0x08000030 size 0x10. Here the DTCM at 0xfff00000 size 0x4000 is cleared.
* Then L_ffff81b4() is called, which branches to DTCM_init(). This copies the initial DTCM data from the Boot9 data image into boot9, then it clears 0xFFF00230 - 0xFFF01AC0.
* Then LT_ffff8228/main is jumped to, with LR set to the address of an infinite-branch-loop instruction.

mpu_init():
* Bitmask 0x000f9005 is cleared in the cp15 control register. MCR instructions which do then following are then executed: flush entire instruction cache, flush entire data cache, and drain write buffer.
* Then the 8 [[Memory_layout|MPU]] memregions are initialized.
* ITCM memregion reg = 0x24: baseaddr=0x0, size = 128MB(0x08000000).
* DTCM memregion reg = 0xfff0000a: baseaddr=0xfff00000, size=16KB(0x00004000).
* Then instruction cachable and data cachable/bufferable bits for the MPU regions are setup.
* Then the instruction/data access permissions for the MPU regions are setup.
* Lastly bitmask 0x0005707d is orred in the cp15 control register.

== Boot9 main() ==

The following functions are called: LT_ffff2024(), LT_ffff1ff8(), pxi_init(), rsa_init(), initialize_rsakeyslots_pubk(), crypto_initialize(), and aesengine_reset().
Then AES keyslot 0x3F is setup: aesengine_setnormalkey(0x3f, 5, ptr) is called. ptr on retail(CFG_UNITINFO check) is 0xffffd6e0, 0xffffd700 for devunit. Then essentially, aesengine_setctr(5, ptr+0x10) is executed.
Then AES keyslot 0x3f is selected.
When calling the following functions, if any of them return zero, it will immediately jump to setting ptr to 0x10012000(otp), otherwise when all of them return non-zero ptr = sp+0x94. otp_decrypt(sp+4), otp_verify(sp+4), initialize_consoleunique_itcm(sp+4, 0x07ffb800).
Then the following is executed: initialize_aeskeys_wrap(ptr, 0x70);
Then sp+4 size 0x100 is cleared to zero.

...

NAND firm-boot code-block, is described below. Note that boot9 is basically hard-coded to use deviceid NAND, not SD.
{
timer_updatestoredstate() is called, then the AES keyslot for NAND-FIRM is selected(0x6).
Then LT_ffff56c8() is called, if that returns non-zero the statuscode variable is set to ~2 then it jumps to NAND_BOOTEND.
Then LT_ffff5774(0x201) is called, if that returns non-zero the statuscode variable is set to ~1 then it jumps to NAND_BOOTEND.
Then fsdriver_setup_mmc() is called. Then nand_findfirmpartition_loadfirm(0) is called, with the statuscode variable set to the retval.
Executes a loop which runs 8 times: write the output from get_errorcode_arrayentry_xfff005e8(loopindex) to u8 0x1fffe000+0x10+loopindex(copy the array of 32bit error-codes for all 8 NCSD partitions initialized by nand_findfirmpartition_loadfirm() to the array of 8bit entries at 0x1fffe000+0x10).

NAND_BOOTEND:
Then the statuscode variable is written to u8 0x1fffe000+0xc.
Then LT_ffff5690(0x201, 0x1fffe018, 0x1fffe01c) is called.
Then LT_ffff5644() is called.
Then timer_updatestoredstate() is called.
When statuscode==0 for success, it jumps to FIRMLOAD_END. Otherwise, it continues to the next code-block.
}

Wifi spi-flash firm-boot code-block, executed when no FIRM was loaded successfully so far.
{
timer_updatestoredstate() is called.

Then spi_wififlash_cmdgetstatusreg(sp+0x100) is executed. When bit0 of the output u8 at sp+0x100 is clear, it will continue this code-block, otherwise it will set the statuscode variable to ~1 then jump to SPIFLASH_BOOTEND.
Then fsdriver_setup_wififlash() is called.
Here read_firmhdr_validate_loadfirm(0, 2) is called, with the statuscode variable set to the retval.

SPIFLASH_BOOTEND:
Then the statuscode variable is written to u8 0x1fffe000+0xe.
Then timer_updatestoredstate() is called.
When statuscode==0 for success, it jumps to FIRMLOAD_END. Otherwise, it executes writenormalkey_keyslot3f(), then jumps to FIRMLOAD_FAILURE.
}

FIRMLOAD_END:
Here it calls firmhdr_getarm11_entrypoint() and firmhdr_getarm9_entrypoint(). Immediately after calling each function it checks if the retval is 0, if so it then jumps to FIRMLOAD_FAILURE.
After calling initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk(), it jumps to FIRMLOAD_EXIT.

FIRMLOAD_FAILURE:
Here it clears 0x07ffb800 size 0x3c70 to zero, endaddr = 0x07fff470.
Then it continues to FIRMLOAD_EXIT.

FIRMLOAD_EXIT:
Here firmboot() is called, which should never return. The instruction after this bl is a call for panic().

== Boot11 ==

* ...

main():
LT_1263c();
...
LT_13944()
...
pxi_init();
initializefuncptr_firmboot_start(firmbootbegin_funcptr);
firmboot();
return;

LT_12220/initializefuncptr_firmboot_start
inr0=funcptr
This writes inr0 to address 0x1ffe8028, then returns.
This initializes the funcptr which firmboot() can call after the very first func-call.

LT_13944
if([[I2C_Registers|i2cmcu_readregf]](sp+0)==0)
{
return (*((u8*)0x10147000) >> 4) & 1;//Reads [[GPIO_Registers|GPIO]] when reading I2C fails.
}
Here it basically does "return <byte loaded from sp+0> ^ 0x2". Hence in this case, it will return 0x2 when the system shell is closed(sleep-mode), otherwise 0x0 is returned.

LT_12454/firmboot
This is the arm11 version of the boot9 firmboot() function, like boot9 this is the final function called from main(). The functionality for these two functions are identical, minus addresses.
ptr = firmboot_loadentrypoint11();
funcptr = *(0x1ffe8028);
if(funcptr)funcptr(ptr);
LT_11ffc(ptr);
return;

== Boot Procedure ==

* 0 seconds - unit is powered on. The ARM9 and ARM11 [[Memory_layout|bootroms]] begin execution.
* <= ~1 second - BootROMs fully run, load FIRM, etc. The loaded FIRM begins running.
**The ARM11 sysmodules included with FIRM are launched by ARM11-kernel, etc.
**The [[Process_Manager_Services|PM]] module launches [[NS]].
**If [[Home_Menu#Auto-Boot_Function|auto-booting]] is needed, NS will [[NS#Auto-boot|auto-boot]] titles.
**Otherwise, NS will instead launch [[ErrDisp]] and the [[Configuration Memory#ACTIVEMENUTID|current active menu]] via the PM module. For retail units, this menu is usually the [[Home Menu]]. Note that the PM module first launches the module dependencies when launching a process, prior to actually launching the process.
**The further Home Menu startup process is described [[Home_Menu#Home_Menu_startup|here]]. This includes Home Menu manually launching various sysmodules.

* 4 seconds - the LCD screens are initialized.

* 7 seconds - [[Home Menu]] is fully initialized/loaded.

== NAND Reads during Boot ==
During a successful boot on 6.x, the bootloader (and firm) reads the following sectors from NAND (in this order):
00000000 (NCSD Partition Table)

Only verify 'FIRM' magic? (A second Header-read will be attempted even if everything except the magic is 0xFF...)
0B130000 (FIRM Partition)
0B530000 (Secondary FIRM Partition)

Verify RSA signature and parse Header:
0B130000 (FIRM: Header)
0B130200 (FIRM: Section 1)
0B163E00 (FIRM: Section 2)
0B193E00 (FIRM: Section 3)

00013000 .. Below is probably NATIVE_FIRM booting ..
00014000
00015000
00016000
00017000

09011A00
09011C00
09012000
09012400
...

== Error Codes ==
When the 3DS does not find the NAND chip, the following error is displayed:

[[Image:CTR_Bootrom_Error.jpg|240px]]

{| class="wikitable" border="1"
|-
! Error
! Description
|-
| <tt>00F800FE 00000000 00000000 00000200 00000000</tt>
| Error when having SD-card reader connected to NAND during boot.
|-
| <tt>00F800FE 00000000 00000000 00000400 00000000</tt>
| NAND not found error (?)
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000080 00800000</tt>
| NAND error when DAT1 was used as DAT0.
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000005 00800000</tt>
| NAND error when DAT2 was used as DAT0.
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000005 00000000</tt>
| NAND error when DAT3 was used as DAT0.
|-
| <tt>00F800FF F8F8FFFF FFFFFFFF 00000000 00000000</tt>
| Both the firm0 and firm1 partitions are corrupt (failed signature checks).
|-
| <tt>00F800EE FFFFFFFF FFFFFFFF 00000000 00000000</tt>
| [[NCSD]] header in sector 0 is corrupt (failed signature check).
|}

== Tools ==
* [https://github.com/yellows8/boot9_tools boot9_tools]

Bootloader

2018-01-16T00:09:33Z

D0k3: Fixed formatting, added info about the stored font gfx format.

The bootloader is the binary code stored in the ARM9 and ARM11 boot ROMs and hence is ran when the 3DS is powered on. It's purpose is initializing hardware and loading the [[FIRM|system firmware]] from the internal [[Flash_Filesystem|NAND memory]]..

Besides NATIVE_FIRM, the bootloader is also capable of booting other firmwares (such as TWL_FIRM and AGB_FIRM). However, this will result either in a japanese error-screen or a system shutdown, directly after FIRM-Launching.

== Boot ROM ==
Upon boot, parts of the ARM9 and ARM11 boot ROMs are protected by writing to [[CONFIG#CFG_SYSPROT9|CFG_SYSPROT9]] and [[CONFIG#CFG_SYSPROT11|CFG_SYSPROT11]], respectively. The ARM9 and ARM11 boot ROMs are identical for all 3DS consoles (3DS, 3DS XL, 2DS, New 3DS, New 3DS XL, New 2DS XL)

== NAND FIRM boot ==
Boot9 is not hard-coded to only handle 2 FIRM partitions: it parses all 8 NCSD partitions for this. Boot9 will attempt to use every partition listed in the NCSD which is an actual FIRM partition, in the same order listed in the NCSD, until booting one of them succeeds. Among the not-yet-processed partitions, the FIRM which has the highest value at u32 firmhdr+4 will have a FIRM-boot attempted first. Since that value is normally 0x0, the order of FIRM-partition processing is normally identical to the order of the NCSD partitions.

Boot9 is hard-coded for using [[AES_Registers|AES]] keyslot 0x6 for NAND crypto.

== Non-NAND FIRM boot ==
Boot9 can also boot from non-NAND. For this a different set of RSA pubks are used(separate pubks for retail/devunit like NAND). The spiflash FIRM image for this is also encrypted with AES-CBC using a normalkey stored in prot_boot9(separate for retail/devunit). This encryption is basically used instead of what is used for NAND-firm-partitions. This encryption is only used for the FIRM sections, the FIRM header is used raw. The AES keyslot for this is only overwritten afterwards when booting from non-NAND fails. AES keyslot 0x3F is used for this.

CTR_word[0] = firmimageoffset;//FIRM section offset from FIRM header
CTR_word[1] = outbufaddr;//FIRM section load addr
CTR_word[2] = readsize;//FIRM section size
CTR_word[3] = readsize;//FIRM section size

When booting from NAND fails, boot9 will then attempt to boot from Wifi SPI-flash(this only triggers when the wifi module hw is properly accessible/connected, which is normally the case). The base offset for spiflash FIRM is 0x400. Note that this region(all data prior to offset 0x1F300) is write-protected by the spiflash(not writable from 3DS-mode / DS-mode).

Additionally, if the shell is closed and a special key combination (Start + Select + X) is held, boot9 will attempt to boot from an inserted NTR cartridge before booting from NAND. Note: While normally on O3DS/2DS the console will not turn on if the shell is closed (or this is faked by holding a magnet to the console), when this special key combination is held holding down the power button will cause boot to occur anyway.

For non-NAND booting, NCSD / FIRM-backup is not used.

== SDMMC ==

Boot9 has code implemented for using SD(HC) cards, but the input deviceids used by boot9 for those functions are hard-coded for NAND. However, it is possible to use an SD(HC) card in place of the NAND if the NAND chip is first disconnected, and a SD card connected to the bus. Due to the CID being different, partitions will need to be re-encrypted and TWL mode will not work, due to the MBR being in the NCSD header. Using sighax, it may be possible to replace the NCSD header.

== Boot9 RSA keyslots ==

The following are initialized during main() startup, by initialize_rsakeyslots_pubk(). Each of these, for the ones which are actually set, have different keydata for retail/devunit.
* 0: Not set.
* 1: Used for the NAND FIRM signature.
* 2: Used for the non-NAND-FIRM signature.
* 3: Used for the NAND-NCSD FIRM signature.

When FIRM loading is successful, initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk() is called, right before calling the final function in main(). Besides ITCM writing, this overwrites all 4 RSA keyslots with modulus + private-exponents loaded from boot9 data.

initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk():
This initializes the 4 0x100-byte/0x200-byte chunks at 0x07ffb800+0x500(0x07ffbd00)/0x07ffb800+0x900(0x07ffc100). End address of the first section is 0x07ffc100(start addr of the second section), end address of the second section is 0x07ffc900. Hence, the first section total size is 0x400-bytes, while the second section total size is 0x800-bytes.

These are initialized using via the boot9 data image, with ptrs from DTCM. Seperate keydata is used for retail/devunit.

When initializing the first ITCM area: rsa_setkeyslot_privk() is called for all 4 RSA keyslots. The modulo for each one is also copied to (index*0x100) + 0x07ffb800 + 0x500. The private exponent is not copied into ITCM.

The second ITCM area is initialized by copying 4 0x200-byte entries in a loop. These are RSA pubks+privks, which Boot9 doesn't use itself at all besides this copy loop.

== Boot9 image data memory layout ==
0xffffb088 is the beginning of the boot9 image data section.

* 0xffffb088 size 0x38-bytes: This is the array used during FIRM-section-loading for the memory-range blacklist for FIRM sections.
* 0xffffb0c0(end-addr of the above area) size 0x20-bytes: Unknown.
* 0xffffb0e0(end-addr of the above area) size 0x2f80-bytes: This is *all* of the keys stored in the image.
* 0xffffe060(end addr of the above key-area) size 0x230-bytes: This is the initial DTCM image @ 0xFFF00000, see below.
* 0xffffe290(DTCM_image_end) - {boot9 image end}: All-zero.

Layout of the 0x2f80-byte key-area at 0xffffb0e0:
* 0xffffb0e0 size 0x2600-bytes: This is the RSA key-data, see below.
* 0xffffd6e0(end-addr of the above area) size 0x40-bytes: This is the keydata used for crypting the entire OTP with keyslot 0x3f, used by main(). The first 0x20-bytes is for retail, the remaining 0x20-bytes starting at 0xffffd700 is for devunit. Chunk+0(retail=0xffffd6e0 devunit=0xffffd700) is the normalkey, chunk+0x10(retail=0xffffd6f0 devunit=0xffffd710) is the AES-IV.
* ...
* 0xffffd760: size 0x100-bytes: First 0x80-bytes is for retail, the remaining 0x80-bytes at 0xffffd7e0 is for devunit. This 0x80-byte block is copied to 0x07ffcd00 by a Boot9 function, however that code actually does the copy in two 0x40-bytes chunks.
* 0xffffd860(end-addr of the above area) size 0x400-bytes: This is the bootrom_dataptr passed to the aes-keyinit function for retail. See the below Tools section for how this is processed.
* 0xffffdc60(end-addr of the above area) size 0x400-bytes: This is the devunit version of the above the 0x400-byte chunk. This is very last chunk of data in the boot9 data-section key-area: end addr for this area is 0xffffe060.

Layout of the 0x2600-byte RSA key-data at 0xffffb0e0:
First 0x1300-bytes is for retail, the remaining 0x1300-bytes starting at 0xffffc3e0 is for devunit.
* +0x0 retail=0xffffb0e0 devunit=0xffffc3e0: RSA modulo for keyslot3, initialized by initialize_rsakeyslots_pubk().
* +0x100 retail=0xffffb1e0 devunit=0xffffc4e0: RSA modulo for keyslot1, initialized by initialize_rsakeyslots_pubk().
* +0x200 retail=0xffffb2e0 devunit=0xffffc5e0: RSA modulo for keyslot2, initialized by initialize_rsakeyslots_pubk().
* +0x300 size 0x200, retail=0xffffb3e0 devunit=0xffffc6e0: First 0x100-bytes is the RSA modulo, then the following 0x100-bytes is the RSA privk(private-exponent). This is for RSA-engine keyslot0 with initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk(), which also copies this modulo to the array starting at 0x07ffbd00.
* +0x500 size 0x200, retail=0xffffb5e0 devunit=0xffffc8e0: Used the same as the above block except for slot1.
* +0x700 size 0x200, retail=0xffffb7e0 devunit=0xffffcae0: Used the same as the above block except for slot2.
* +0x900 size 0x200, retail=0xffffb9e0 devunit=0xffffcce0: Used the same as the above block except for slot3.
* +0xb00 size 0x200, retail=0xffffbbe0 devunit=0xffffcee0: First 0x100-bytes is the RSA modulo, then the following 0x100-bytes is the RSA privk(private-exponent). The 0x200-bytes here is copied to slot0 in the array at 0x07ffc100 by initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk().
* +0xd00 size 0x200, retail=0xffffbde0 devunit=0xffffd0e0: Used the same as the above block except for slot1.
* +0xf00 size 0x200, retail=0xffffbfe0 devunit=0xffffd2e0: Used the same as the above block except for slot2.
* +0x1100 size 0x200, retail=0xffffc1e0 devunit=0xffffd4e0: Used the same as the above block except for slot3.

== Boot9 DTCM layout ==
Most of this is just ptrs / other unknown data, not actual keys. However, there is an unknown 0x10-byte block @ +0x124(there's a ptr initialized for this block elsewhere).

== Boot11 image data memory layout ==
* 0x0001817c..0x000181f4 size 0x78-bytes: This seems to be the bootrom error screen font gfx data. This begins at the exact end-address of the crt0 code, the rest of the protected boot11 code begins at this end-address(0x000181f4). To extract the font gfx data from there, the 30 dwords at this address need to be converted to big endian. The correct resolution (when displayed as raw) is 32x30x1. The bootrom font looks very similar to [https://robey.lag.net/2010/01/23/tiny-monospace-font.html this font].
* 0x00019400 is the beginning of the boot11 data area, the first 8-bytes here are unknown.
* 0x00019408..0x0001b498 size 0x2090-bytes: This is the blowfish keydata which gets copied to arm9itcm_twlkeydata+0x3e0 later.
* 0x0001c498..0x0001c4f8 size 0x60-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x380.
* 0x0001c4f8..0x0001c538 size 0x40-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x340.
* 0x0001c538..0x0001c578 size 0x40-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x300.
* 0x0001c578..0x0001c5f8 size 0x80-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x280.
* 0x0001c5f8..0x0001c678 size 0x80-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x0.
* 0x0001c678..0x0001c878 size 0x200-bytes: This is the data which eventually gets copied to arm9itcm_twlkeydata+0x80.
* 0x0001c878..0x0001d078 size 0x800-bytes: These are the 3DS RSA-2048 modulus which are eventually copied to arm9_itcm+0x4900: on retail the first 4 are copied there by boot9, on devunit the last 4 are copied to itcm.
* 0x0001d078 size 0x120-bytes is the initial data for the .data section @ 0x1ffe8000, this is the very end of the protected arm11-bootrom.

== AES keys ==
See the Tools section for how Boot9 initializes the keyslots.

See also [[AES_Registers|here]].

For an issue with console-unique key-init, see [[OTP_Registers|here]].

== BootROM Errors ==
Sample error-screen(where firm0+firm1 RSA signatures were corrupted):

BOOTROM 8046
ERRCODE: 00F800FF
DEDEFFFF FFFFFFFF
00000000 00000000

* 1st line is: <code>print_string(..., "BOOTROM %X", 0x8046);//This last param comes from the .pool.</code>
* 2nd line is: <code>print_string(..., "ERRCODE: %08X", *((unsigned int*)(0x1FFFE000+0xC)));//See below memory notes.</code>
* 3rd line is: <code>print_string(..., "%08X %08X", *((unsigned int*)(0x1FFFE000+0x10))`, `*((unsigned int*)(0x1fffe000+0x14)));//See below memory notes.</code>
* 4th line is: <code>print_string(..., "%08X %08X",*((unsigned int*)(0x1FFFE000+0x18))`, `*((unsigned int*)(0x1fffe000+0x1C)));//See below memory notes.</code>

== 0x1FFFE000 memory ==
This memory is used by boot9 mainly for sending info to the arm11 for the error-screen. The data in this region is still stored in memory by the time the ARM9+ARM11 jumps to FIRM.

Among boot9/boot11, the 3 words at 0x1FFFE000 seem to be ''only'' accessed by the boot11 function initializing those words.

* u32 0x1FFFE000+0: ARM11 MPCore "Cycle Counter Register (CCNT)".
* u32 0x1FFFE000+4: ARM11 MPCore "Count Register 0 (PMN0)".
* u32 0x1FFFE000+8: ARM11 MPCore "Count Register 1 (PMN0)".
* 8bit-entry-array 0x1FFFE000+0xC: 8bit status-codes initialized by boot9 main(), for the FIRM-boot devices. +0 is NAND, +1 is NTRCARD and +2 is wifi-spiflash.
* ...
* 8bit-entry-array 0x1FFFE000+0x10: Status-codes originally from nand_findfirmpartition_loadfirm(), for each of the 8 NCSD partitions.

== BootROM Status Codes ==
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0x00
| Success
|-
| 0xEE(~17)
| NCSD header validation function failed: NCSD magicnum is invalid or RSA verification failed.
|-
| 0xDE(~33)
| FIRM header validation function failed: FIRM magicnum is invalid or RSA verification failed.
|-
| 0xDF(~32)
| Failed to read sector data from the device.
|-
| 0xCF(~48)
| FIRM section validation function failed: FIRM section is invalid.
|-
| 0xF7(~8)
| A NAND FIRM from another partition was already found with a priority(firmhdr+4) >= to the value for the current partition's FIRM priority.
|-
| 0xF8(~7)
| The FIRM magicnum(firmhdr+0) is invalid.
|-
| 0xFF(~0)
| Initial value for each entry in the 8-entry array of status-codes for the NAND NCSD partitions. Indicates that the partition is not a FIRM partition(partition fs type isn't 0x3 or partition fs crypt-type isn't 0x2).
|}

== Boot9 startup ==

0xffff0000 jumps to 0xffff8000. 0xffff8000 is crt0:
* Very first thing this does is clear u8 register 0x10000002 ([[CONFIG_Registers#CFG_RST11|CFG_RST11]]) bit 0 to zero.
* Then sp is initialized for each cpumode, IRQs/FIQs are disabled during the first mode-switch.
* Order of mode-switches + sp initialization: svc-mode = 0xfff04000, irq-mode = 0xfff03f00, system-mode = 0xfff03b00. Hence, the rest of the code following this runs in system-mode.
* Then L_ffff80cc/mpu_init() is called.
* Then L_ffff0038() is called, which initializes the exception-handler addresses @ 0x08000000.
* Then L_ffff81b8() is called(r4 + lr are saved on the DTCM stack), which after calling a memclear function which doesn't do anything, it then clears 0x08000030 size 0x10. Here the DTCM at 0xfff00000 size 0x4000 is cleared.
* Then L_ffff81b4() is called, which branches to DTCM_init(). This copies the initial DTCM data from the Boot9 data image into boot9, then it clears 0xFFF00230 - 0xFFF01AC0.
* Then LT_ffff8228/main is jumped to, with LR set to the address of an infinite-branch-loop instruction.

mpu_init():
* Bitmask 0x000f9005 is cleared in the cp15 control register. MCR instructions which do then following are then executed: flush entire instruction cache, flush entire data cache, and drain write buffer.
* Then the 8 [[Memory_layout|MPU]] memregions are initialized.
* ITCM memregion reg = 0x24: baseaddr=0x0, size = 128MB(0x08000000).
* DTCM memregion reg = 0xfff0000a: baseaddr=0xfff00000, size=16KB(0x00004000).
* Then instruction cachable and data cachable/bufferable bits for the MPU regions are setup.
* Then the instruction/data access permissions for the MPU regions are setup.
* Lastly bitmask 0x0005707d is orred in the cp15 control register.

== Boot9 main() ==

The following functions are called: LT_ffff2024(), LT_ffff1ff8(), pxi_init(), rsa_init(), initialize_rsakeyslots_pubk(), crypto_initialize(), and aesengine_reset().
Then AES keyslot 0x3F is setup: aesengine_setnormalkey(0x3f, 5, ptr) is called. ptr on retail(CFG_UNITINFO check) is 0xffffd6e0, 0xffffd700 for devunit. Then essentially, aesengine_setctr(5, ptr+0x10) is executed.
Then AES keyslot 0x3f is selected.
When calling the following functions, if any of them return zero, it will immediately jump to setting ptr to 0x10012000(otp), otherwise when all of them return non-zero ptr = sp+0x94. otp_decrypt(sp+4), otp_verify(sp+4), initialize_consoleunique_itcm(sp+4, 0x07ffb800).
Then the following is executed: initialize_aeskeys_wrap(ptr, 0x70);
Then sp+4 size 0x100 is cleared to zero.

...

NAND firm-boot code-block, is described below. Note that boot9 is basically hard-coded to use deviceid NAND, not SD.
{
timer_updatestoredstate() is called, then the AES keyslot for NAND-FIRM is selected(0x6).
Then LT_ffff56c8() is called, if that returns non-zero the statuscode variable is set to ~2 then it jumps to NAND_BOOTEND.
Then LT_ffff5774(0x201) is called, if that returns non-zero the statuscode variable is set to ~1 then it jumps to NAND_BOOTEND.
Then fsdriver_setup_mmc() is called. Then nand_findfirmpartition_loadfirm(0) is called, with the statuscode variable set to the retval.
Executes a loop which runs 8 times: write the output from get_errorcode_arrayentry_xfff005e8(loopindex) to u8 0x1fffe000+0x10+loopindex(copy the array of 32bit error-codes for all 8 NCSD partitions initialized by nand_findfirmpartition_loadfirm() to the array of 8bit entries at 0x1fffe000+0x10).

NAND_BOOTEND:
Then the statuscode variable is written to u8 0x1fffe000+0xc.
Then LT_ffff5690(0x201, 0x1fffe018, 0x1fffe01c) is called.
Then LT_ffff5644() is called.
Then timer_updatestoredstate() is called.
When statuscode==0 for success, it jumps to FIRMLOAD_END. Otherwise, it continues to the next code-block.
}

Wifi spi-flash firm-boot code-block, executed when no FIRM was loaded successfully so far.
{
timer_updatestoredstate() is called.

Then spi_wififlash_cmdgetstatusreg(sp+0x100) is executed. When bit0 of the output u8 at sp+0x100 is clear, it will continue this code-block, otherwise it will set the statuscode variable to ~1 then jump to SPIFLASH_BOOTEND.
Then fsdriver_setup_wififlash() is called.
Here read_firmhdr_validate_loadfirm(0, 2) is called, with the statuscode variable set to the retval.

SPIFLASH_BOOTEND:
Then the statuscode variable is written to u8 0x1fffe000+0xe.
Then timer_updatestoredstate() is called.
When statuscode==0 for success, it jumps to FIRMLOAD_END. Otherwise, it executes writenormalkey_keyslot3f(), then jumps to FIRMLOAD_FAILURE.
}

FIRMLOAD_END:
Here it calls firmhdr_getarm11_entrypoint() and firmhdr_getarm9_entrypoint(). Immediately after calling each function it checks if the retval is 0, if so it then jumps to FIRMLOAD_FAILURE.
After calling initialize_x07ffbd00_x07ffc100_rsakeyslotsprivk(), it jumps to FIRMLOAD_EXIT.

FIRMLOAD_FAILURE:
Here it clears 0x07ffb800 size 0x3c70 to zero, endaddr = 0x07fff470.
Then it continues to FIRMLOAD_EXIT.

FIRMLOAD_EXIT:
Here firmboot() is called, which should never return. The instruction after this bl is a call for panic().

== Boot11 ==

* ...

main():
LT_1263c();
...
LT_13944()
...
pxi_init();
initializefuncptr_firmboot_start(firmbootbegin_funcptr);
firmboot();
return;

LT_12220/initializefuncptr_firmboot_start
inr0=funcptr
This writes inr0 to address 0x1ffe8028, then returns.
This initializes the funcptr which firmboot() can call after the very first func-call.

LT_13944
if([[I2C_Registers|i2cmcu_readregf]](sp+0)==0)
{
return (*((u8*)0x10147000) >> 4) & 1;//Reads [[GPIO_Registers|GPIO]] when reading I2C fails.
}
Here it basically does "return <byte loaded from sp+0> ^ 0x2". Hence in this case, it will return 0x2 when the system shell is closed(sleep-mode), otherwise 0x0 is returned.

LT_12454/firmboot
This is the arm11 version of the boot9 firmboot() function, like boot9 this is the final function called from main(). The functionality for these two functions are identical, minus addresses.
ptr = firmboot_loadentrypoint11();
funcptr = *(0x1ffe8028);
if(funcptr)funcptr(ptr);
LT_11ffc(ptr);
return;

== Boot Procedure ==

* 0 seconds - unit is powered on. The ARM9 and ARM11 [[Memory_layout|bootroms]] begin execution.
* <= ~1 second - BootROMs fully run, load FIRM, etc. The loaded FIRM begins running.
**The ARM11 sysmodules included with FIRM are launched by ARM11-kernel, etc.
**The [[Process_Manager_Services|PM]] module launches [[NS]].
**If [[Home_Menu#Auto-Boot_Function|auto-booting]] is needed, NS will [[NS#Auto-boot|auto-boot]] titles.
**Otherwise, NS will instead launch [[ErrDisp]] and the [[Configuration Memory#ACTIVEMENUTID|current active menu]] via the PM module. For retail units, this menu is usually the [[Home Menu]]. Note that the PM module first launches the module dependencies when launching a process, prior to actually launching the process.
**The further Home Menu startup process is described [[Home_Menu#Home_Menu_startup|here]]. This includes Home Menu manually launching various sysmodules.

* 4 seconds - the LCD screens are initialized.

* 7 seconds - [[Home Menu]] is fully initialized/loaded.

== NAND Reads during Boot ==
During a successful boot on 6.x, the bootloader (and firm) reads the following sectors from NAND (in this order):
00000000 (NCSD Partition Table)

Only verify 'FIRM' magic? (A second Header-read will be attempted even if everything except the magic is 0xFF...)
0B130000 (FIRM Partition)
0B530000 (Secondary FIRM Partition)

Verify RSA signature and parse Header:
0B130000 (FIRM: Header)
0B130200 (FIRM: Section 1)
0B163E00 (FIRM: Section 2)
0B193E00 (FIRM: Section 3)

00013000 .. Below is probably NATIVE_FIRM booting ..
00014000
00015000
00016000
00017000

09011A00
09011C00
09012000
09012400
...

== Error Codes ==
When the 3DS does not find the NAND chip, the following error is displayed:

[[Image:CTR_Bootrom_Error.jpg|240px]]

{| class="wikitable" border="1"
|-
! Error
! Description
|-
| <tt>00F800FE 00000000 00000000 00000200 00000000</tt>
| Error when having SD-card reader connected to NAND during boot.
|-
| <tt>00F800FE 00000000 00000000 00000400 00000000</tt>
| NAND not found error (?)
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000080 00800000</tt>
| NAND error when DAT1 was used as DAT0.
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000005 00800000</tt>
| NAND error when DAT2 was used as DAT0.
|-
| <tt>00F800FE FFFFFFFF FFFFFFFF 00000005 00000000</tt>
| NAND error when DAT3 was used as DAT0.
|-
| <tt>00F800FF F8F8FFFF FFFFFFFF 00000000 00000000</tt>
| Both the firm0 and firm1 partitions are corrupt (failed signature checks).
|-
| <tt>00F800EE FFFFFFFF FFFFFFFF 00000000 00000000</tt>
| [[NCSD]] header in sector 0 is corrupt (failed signature check).
|}

== Tools ==
* [https://github.com/yellows8/boot9_tools boot9_tools]

I2C Registers

2017-11-22T01:24:07Z

D0k3: /* Device 3 */

= Registers =
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! Used by
|-
| style="background: green" | Yes
| I2C1_DATA
| 0x10161000
| 1
| I2C bus 1 devices
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C1_CNT]]
| 0x10161001
| 1
| I2C bus 1 devices
|-
| style="background: green" | Yes
| I2C1_CNTEX
| 0x10161002
| 2
| I2C bus 1 devices
|-
| style="background: green" | Yes
| I2C1_SCL
| 0x10161004
| 2
| I2C bus 1 devices
|-
| style="background: green" | Yes
| I2C2_DATA
| 0x10144000
| 1
| I2C bus 2 devices
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C2_CNT]]
| 0x10144001
| 1
| I2C bus 2 devices
|-
| style="background: green" | Yes
| I2C2_CNTEX
| 0x10144002
| 2
| I2C bus 2 devices
|-
| style="background: green" | Yes
| I2C2_SCL
| 0x10144004
| 2
| I2C bus 2 devices
|-
| style="background: green" | Yes
| I2C3_DATA
| 0x10148000
| 1
| I2C bus 3 devices
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C3_CNT]]
| 0x10148001
| 1
| I2C bus 3 devices
|-
| style="background: green" | Yes
| I2C3_CNTEX
| 0x10148002
| 2
| I2C bus 3 devices
|-
| style="background: green" | Yes
| I2C3_SCL
| 0x10148004
| 2
| I2C bus 3 devices
|}

== I2C_CNT ==
{| class="wikitable" border="1"
! BIT
! DESCRIPTION
|-
| 0
| Stop (0=No, 1=Stop/last byte)
|-
| 1
| Start (0=No, 1=Start/first byte)
|-
| 2
| Pause (0=Transfer Data, 1=Pause after Error, used with/after Stop)
|-
| 4
| Ack Flag (0=Error, 1=Okay) (For DataRead: W, for DataWrite: R)
|-
| 5
| Data Direction (0=Write, 1=Read)
|-
| 6
| Interrupt Enable (0=Disable, 1=Enable)
|-
| 7
| Start/busy (0=Ready, 1=Start/busy)
|}

= I2C Devices =
{| class="wikitable" border="1"
! [[I2C_Registers|Device id]]
! Device bus id
! Device Write Address
! Accessible via I2C [[I2C_Services|service]]
! Device description
|-
| 0
| 1
| 0x4a
| "i2c::MCU"
| Power management?(same device addr as the DSi power-management)
|-
| 1
| 1
| 0x7a
| "i2c::CAM"
| Camera0?(same dev-addr as DSi cam0)
|-
| 2
| 1
| 0x78
| "i2c::CAM"
| Camera1?(same dev-addr as DSi cam1)
|-
| 3
| 2
| 0x4a
| "i2c::MCU"
| MCU
|-
| 4
| 2
| 0x78
| "i2c::CAM"
| ?
|-
| 5
| 2
| 0x2c
| "i2c::LCD"
| ?
|-
| 6
| 2
| 0x2e
| "i2c::LCD"
| ?
|-
| 7
| 2
| 0x40
| "i2c::DEB"
| ?
|-
| 8
| 2
| 0x44
| "i2c::DEB"
| ?
|-
| 9
| 3
| 0xa6
| "i2c::HID"
| Unknown. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with [[8.0.0-18]].
|-
| 10
| 3
| 0xd0
| "i2c::HID"
| Gyroscope
|-
| 11
| 3
| 0xd2
| "i2c::HID"
| ?
|-
| 12
| 3
| 0xa4
| "i2c::HID"
| DebugPad
|-
| 13
| 3
| 0x9a
| "i2c::IR"
| IR
|-
| 14
| 3
| 0xa0
| "i2c::EEP"
| eeprom?
|-
| 15
| 2
| 0xee
| "i2c::NFC"
| New3DS-only [[NFC_Services|NFC]]
|-
| 16
| 1
| 0x40
| "i2c::QTM"
| New3DS-only [[QTM_Services|QTM]]
|-
| 17
| 3
| 0x54
| "i2c::IR"
| Used by IR-module starting with [[8.0.0-18]], for New3DS-only HID via "ir:rst". This deviceid doesn't seem to be supported by i2c module on [[8.0.0-18]](actual support was later added in New3DS i2c module).
|}

'''Notice''': These device addresses are used for writing to the respective device, for reading bit0 must be set (see I2C protocol). Thus, the actual device address is >> 1.

== Device 3 ==
{| class="wikitable" border="1"
! REGISTER
! WIDTH
! INFO
! DESCRIPTION
|-
| 0x00
| s
| ro
| Version high
|-
| 0x01
| s
| ro
| Version low
|-
| 0x02
| s
| ro
| ?
|-
| 0x03
| s
| rw
| Top screen flicker
|-
| 0x04
| s
| rw
| Bottom screen flicker
|-
| 0x05
- 0x07
| s(3)
| rw
| Danger zone - [[MCU_Services#MCU_firmware_versions|MCU unlock sequence]] is written here
|-
| 0x08
| s
| ro
| Raw 3D slider position
|-
| 0x09
| s
| ro
| Volume slider state (0x00 - 0x3F)
This is the same value returned by [[MCUHWC:GetSoundVolume|MCUHWC:GetSoundVolume]]
|-
| 0x0A
| s
| ro
| ? (seems to be power management related?)
|-
| 0x0B
| s
| ro
| Battery percentage
|-
| 0x0C
| s
| ro
| ? (changes to 0 for a second when the charger is plugged in then it resets to its previous value)
|-
| 0x0D
| s
| ro
| System voltage
|-
| 0x0E
| s
| ro
| ?
|-
| 0x0F
| s
| ro
| Flags: bit7-5 are read via [[MCU_Services|mcu::GPU]]. The rest of these are read via [[MCU_Services|mcu::RTC]]: bit4 = BatteryChargeState. bit3 = AdapterState. bit1 = ShellState.
|-
| 0x10
- 0x13
| s
| ro
| Received interrupt bitmask, see register 0x18 for possible values
If no interrupt was received this register is 0
|-
| 0x14
| s
| ro
| ?
|-
| 0x15
| s
| rw
| ?
|-
| 0x16
| s
| rw
| ?
|-
| 0x17
| s
| rw
| ?
|-
| 0x18
- 0x1B
| s
| rw
| Interrupt mask for register 0x10 (0=enabled,1=disabled)
bit00: Power button press
bit01: Power button held (the 3DS turns off regardless after a fixed time)
bit02: HOME button press
bit03: HOME button release
bit04: WiFi switch button
bit05: Shell close
bit06: Shell open
bit07: Fatal hardware condition([[Services#Notifications|?]])
bit08: Charger removed
bit09: Charger plugged in
bit10: ??? (Power Management related?)
bit11: ??? (HID related)
bit12: HID update
bit13: Battery dead(?)
bit14: ??? (Power Management related?)
bit15: ??? (Power Management related?)
bit22: Volume slider position change
bit24: ??? (???)
bit25: ??? (???)
bit26: ??? (???)
bit27: ??? (???)
bit28: ??? (???)
bit29: ??? (???)
bit30: forced off my mcu sysmodule
bit31: forced off my mcu sysmodule
|-
| 0x1C
| s
| rw
| ? (survives reboot and power off)
|-
| 0x1D
| s
| rw
| ? (survives reboot and power off)
|-
| 0x1E
| s
| rw
| ? (survives reboot and power off)
|-
| 0x1F
| s
| rw
| ? (survives reboot and power off)
|-
| 0x20
| s
| wo
| System power control:
bit0: power off
bit1: reboot (unused?)
bit2: reboot (used by mcu sysmodule and LgyBg)
bit3: used by LgyBg to power off, causes hangs in 3DS-mode
bit4: doesn't seem to do anything, but an mcu::RTC command uses this
Other bits are unused, and seem to do nothing.
|-
| 0x21
| s
| ro(?)
| ?
|-
| 0x22
| s
| wo
| Used to set LCD states
bit0: don't push to LCDs
bit1: push to LCDs
bit2: bottom screen backlight off
bit3: bottom screen backlight on
bit4: top screen backlight off (does nothing on 2DS as the backlight is bottom only)
bit5: top screen backlight on (see above)
|-
| 0x23
| s
| ro(?)
| ?
|-
| 0x24
| s
| ??
| Watchdog timer. This must be set *before* the timer is triggered, otherwise the old value is used. Value zero disables the watchdog.
|-
| 0x25
| s
| rw
| ?
|-
| 0x26
| s
| rw
| ?
|-
| 0x27
| s
| ro
| Raw volume slider state
|-
| 0x28
| s
| rw
| Brightness of the WiFi/Power LED
|-
| 0x29
| ds(0x64)
| ro / rw
| Empty battery pattern holder, repeats all written bytes
|-
| 0x2A
| s
| rw
| WiFi LED state, non-0 value turns on the WiFi LED, capped at 0x0F
|-
| 0x2B
| s
| rw
| Camera LED state, 0, 3, 6-0xF = off, 1 = slowly blinking, 2 = constantly on, 4 = flash once, 5 = delay before changing to 2
|-
| 0x2C
| s
| rw
| 3D LED state, capped at 0x0F
|-
| 0x2D
| 0x64
| wo
| This is used for [[MCURTC:SetInfoLEDPattern|controlling]] the notification LED (see [[MCURTC:SetInfoLEDPatternHeader]] as well), when this register is written. It's possible to write data here with size less than 0x64, and only that portion of the pattern data will get overwritten. Reading from this register only returns zeroes, so it's considered write-only. Writing past the size of this register seems to do nothing.
|-
| 0x2E
| s
| ro
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read (1 means new cycle started)
|-
| 0x2F
| s
| ro(?)
| ?
|-
| 0x30
- 0x37
| s
| rw
| RTC time (system clock). 7 bytes are read from this. The upper nibble of each byte encodes 10s (BCD), so each byte is post-processed with (byte & 0xF) + (10 * (byte >> 4)).
byte 0: seconds
byte 1: minutes
byte 2: hours
byte 3: current day of the week (unused)
byte 4: days
byte 5: months
byte 6: years
byte 7: leap year counter (unused)
|-
| 0x38
- 0x3C
| s
| rw
| RTC alarm registers
Register 0x3B could be used to upload [[MCU_Services#MCU_firmware_versions|MCU firmware]] if some conditions are met.
|-
| 0x3D
0x3E
| s (2)
| ro
| RTC tick counter (resets to 0 when the seconds increase)
|-
| 0x3F
| s
| wo
| Peripheral power related? bit0 seems to depower everything, pressing the power key afterwards instantly turns the whole 3DS off
|-
| 0x40
| s
| rw
| Pedometer state (?)
|-
| 0x41
| s
| rw
| Index selector for register 0x44
|-
| 0x42
| s
| rw
| ?
|-
| 0x43
| s
| rw
| ???, accelometer related
|-
| 0x44
| s
| rw
| ???, accelometer related
|-
| 0x45
| s
| rw
| ?
|-
| 0x46
| s
| ro
| Gyro Y(?) axis rotation (0x00 = flat, 0x40 = 3DS standing on right side, 0xBE = 3DS standing on left side)
|-
| 0x48
| s
| ro
| Gyro Z(?) axis rotation (0x00 = flat, 0x40 = 3DS standing horizontally, 0xBE = 3DS base is horizontally upside-down)
|-
| 0x4A
| s
| ro
| Gyro X(?) axis rotation (0x00 = 3DS base facing upwards, 0x40 = face-down flat, 0xBE = standing(?) flat)
|-
| 0x4B
| s
| rw
| PedometerStepCount (for the current day)
|-
| 0x4C
| s
| rw
| ?
|-
| 0x4D
| s
| rw
| ?
|-
| 0x4E
| s
| rw
| ?
|-
| 0x4F
| 0x156
| ro
| ???
|-
| 0x50
| s
| rw
| ???
|-
| 0x51
| s
| rw
| ???
|-
| 0x52
- 0x57
| s
| rw
| ?
|-
| 0x58
| s
| rw
| DSP volume slider 0% volume offset (setting this to 0xFF will esentially mute the DSP as it's the volume slider's maximum raw value)
|-
| 0x59
| s
| rw
| DSP volume slider 100% volume offset (setting both this and the above to 0 will disable the volume slider with 100% volume, setting this to a lower value than the above will make the volume slider have only 2 states; on and off)
|-
| 0x5A
| s
| rw
| ?
|-
| 0x5B
- 0x5F
| s
| ro(?)
| ? (these seem to be invalid regsiters)
|-
| 0x60
| ds(1)
| ro
first byte is wo
| Looping queue register
Writing to first byte resets the queue position to the nth element
Reading from this register causes the values to shift up by `readsize-1`(needs confirmation) bytes after returning `readsize-1` bytes from the top of the stack (first byte is read-only, so is always zero)
|-
| 0x61
| ds(0x100)
| rw
| Writing to this register pushes values on top of register 0x60's stack. Reading from this register doesn't advance the stack.
The first byte is used to store flags for managing FIRM/NS state - bit0 = "WirelessDisabled", bit1 = "SoftwareClosed", bit2 = "PowerOffInitiated", bit4 = "LegacyJumpProhibited". This register survives power-off, but does not seem to be saved to non-volatile storage (does not survive battery pulls). This register doesn't seem to actually control MCU behaviour by itself, it just seems to be used for storing arbitrary data.
|-
| 0x62 - 0x7E
| s
| invalid (ro)
| These registers don't exist at all, thus reading them will yield 0xFF
|-
| 0x7F
| 19(?)
| ro
| Various system state information.
byte 06: battery related? (seems to decrease while charging and increase while discharging)
byte 09: system model (see [[Cfg:GetSystemModel#System_Model_Values|Cfg:GetSystemModel]] for values)
byte 10: power LED related? 0 is off, 1 is red
byte 13: RGB LED red intensity
byte 14: RGB LED green intensity
byte 15: RGB LED blue intensity
byte 17: WiFi LED brightness
byte 18: raw button states?
bit0: unset while power button is held
bit1: unset while home button is held
bit2: unset while Wifi slider is held
bit5: unset while the charging LED is active
bit6: unset while charger is plugged in

this byte is reset to 0 before an svcBreak takes effect
|-
| 0x80
- 0xFF
| s
| invalid (ro)
| These registers don't exist at all, thus reading them will yield 0xFF
|}

Note: the letter "s" in the size field means that the given register is in a "shared register pool", meaning if you read/write with size more than 1 you can read the next `readamount-1` of shared registers. It's possible to corrupt the shared value of a "non-shared" register by writing into a shared register with a size bigger than one. Writing more than 0x100 bytes into a shared register will corrupt all writable registers, including the shared portion of "non-shared" registers.

Non-shared register: it's a register separate from the shared register pool. Messing with these registers will not affect the shared register pool at all.

== Device 5 & 6 ==
LCD controllers for main/sub displays, most likely.

{| class="wikitable" border="1"
! Register
! Width
! Name
! Description
|-
| 0x1
| 8
| ?
|
|-
| 0x11
| 8
| ?
|
|-
| 0x40
| 8
| CMD_IN/CMD_RESULT1
| Write to trigger a command? Seen commands: 0xFF=Reset?, 0x62=IsFinished?. Result is stored in CMD_RESULT1:CMD_RESULT0.
|-
| 0x41
| 8
| CMD_RESULT0
| Read result
|-
| 0x50
| 8
| ?
|
|-
| 0x60
| 8
| ?
|
|-
| 0xFE
| 8
| ?
|
|}

== Device 10 ==
See the datasheet linked to on the [[Hardware]] page for reference.

== Device 12 ==
{| class="wikitable" border="1"
! REGISTER
! WIDTH
! DESCRIPTION
|-
| 0x0
| 21
| DebugPad state.
|}

This is the DebugPad device, see [[HID_Shared_Memory|here]].

== Device 13 ==
{| class="wikitable" border="1"
! Raw I2C register address
! Internal register address
! Width
! Description
|-
| 0x0
| 0x0
| 0x40
| RHR / THR (data receive/send FIFO)
|-
| 0x8
| 0x1
| 0x1
| IER
|-
| 0x10
| 0x2
| 0x1
| FCR/IIR
|-
| 0x18
| 0x3
| 0x1
| LCR
|-
| 0x20
| 0x4
| 0x1
| MCR
|-
| 0x28
| 0x5
| 0x1
| LSR
|-
| 0x30
| 0x6
| 0x1
| MSR/TCR
|-
| 0x38
| 0x7
| 0x1
| SPR/TLR
|-
| 0x40
| 0x8
| 0x1
| TXLVL
|-
| 0x48
| 0x9
| 0x1
| RXLVL
|-
| 0x50
| 0xA
| 0x1
| IODir
|-
| 0x58
| 0xB
| 0x1
| IOState
|-
| 0x60
| 0xC
| 0x1
| IoIntEna
|-
| 0x68
| 0xD
| 0x1
| reserved
|-
| 0x70
| 0xE
| 0x1
| IOControl
|-
| 0x78
| 0xF
| 0x1
| EFCR
|}

See the [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html datasheet] linked to on the [[Hardware]] page for reference. From that datasheet, for the structure of the I2C register address u8: "Bit 0 is not used, bits 2:1 select the channel, bits 6:3 select one of the UART internal registers. Bit 7 is not used with the I2C-bus interface, but it is used by the SPI interface to indicate a read or a write operation."

== Device 14 ==

Used by [[Config_Services|Cfg]]-sysmodule via the i2c::EEP service. This is presumably EEPROM going by the service name.

The Cfg-module code which loads the [[Flash_Filesystem|CCAL]](nandro:/sys/{HWCAL0.dat/HWCAL1.dat}) file from NAND will load it from I2C instead, if a certain state flag is non-zero. Likewise for the function which writes CCAL to NAND. HMAC/hash verification after loading is skipped when the CCAL was loaded from I2C.

== Device 15 ==
This the New3DS [[NFC_Services|NFC]] controller "I2C" interface. This device is accessed via the WriteDeviceRaw/ReadDeviceRaw I2C service [[I2C_Services|commands]].

Since the *Raw commands are used with this, this device has no I2C registers. Instead, raw data is transfered after the I2C device is selected. Hence, WriteDeviceRaw is used for sending commands to the controller, while ReadDeviceRaw is for receiving responses from the controller. Certain commands may return multiple command responses.

Command request / response structure:
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Normally 0x10?
|-
| 0x1
| 0x1
| Command source / destination.
|-
| 0x2
| 0x1
| CmdID
|-
| 0x3
| 0x1
| Payload size.
|}

Following the above header is the payload data(when payload size is non-zero), with the size specified in the header. The command response payload is usually at least 1-byte, where that byte appears to be normally 0x0. For command requests the payload data is the command parameters.

For command requests sent to the NFC tag itself, Cmd[1]=0x0 and CmdID=0x0. The command request payload data here is the actual command request data for the NFC tag, starting with the CmdID u8 at payload+0.

During NFC module startup, a certain command is sent to the controller which eventually(after various cmd-reply headers etc) returns the following the payload after the first byte in the payload:
000000: 44 65 63 20 32 32 20 32 30 31 32 31 34 3a 35 33 Dec 22 201214:53
000010: 3a 35 30 01 05 0d 46 05 1b 79 20 07 32 30 37 39 :50...F..y .2079
000020: 31 42 35 1B5

Or that is: "Dec 22 201214:53:50<binary>20791B5". Therefore, this appears to return the part-number of the NFC controller(other command request(s) / response(s) use this part-number value too).

=== NFC controller commands ===
{| class="wikitable" border="1"
! CmdRequest[1]
! CmdID
! Payload data for parameters
! Description
|-
| 0x2E
| 0x2F
| Firmware image for this chunk, size varies.
| This is used during NFC module startup to upload the firmware image to the NFC controller. This is used repeatedly to upload multiple chunks of the image.
|}

I2C Registers

2017-10-26T20:26:30Z

D0k3: Fixed typo for RTC offsets in MCU

= Registers =
{| class="wikitable" border="1"
! Old3DS
! Name
! Address
! Width
! Used by
|-
| style="background: green" | Yes
| I2C1_DATA
| 0x10161000
| 1
| I2C bus 1 devices
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C1_CNT]]
| 0x10161001
| 1
| I2C bus 1 devices
|-
| style="background: green" | Yes
| I2C1_CNTEX
| 0x10161002
| 2
| I2C bus 1 devices
|-
| style="background: green" | Yes
| I2C1_SCL
| 0x10161004
| 2
| I2C bus 1 devices
|-
| style="background: green" | Yes
| I2C2_DATA
| 0x10144000
| 1
| I2C bus 2 devices
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C2_CNT]]
| 0x10144001
| 1
| I2C bus 2 devices
|-
| style="background: green" | Yes
| I2C2_CNTEX
| 0x10144002
| 2
| I2C bus 2 devices
|-
| style="background: green" | Yes
| I2C2_SCL
| 0x10144004
| 2
| I2C bus 2 devices
|-
| style="background: green" | Yes
| I2C3_DATA
| 0x10148000
| 1
| I2C bus 3 devices
|-
| style="background: green" | Yes
| [[#I2C_CNT|I2C3_CNT]]
| 0x10148001
| 1
| I2C bus 3 devices
|-
| style="background: green" | Yes
| I2C3_CNTEX
| 0x10148002
| 2
| I2C bus 3 devices
|-
| style="background: green" | Yes
| I2C3_SCL
| 0x10148004
| 2
| I2C bus 3 devices
|}

== I2C_CNT ==
{| class="wikitable" border="1"
! BIT
! DESCRIPTION
|-
| 0
| Stop (0=No, 1=Stop/last byte)
|-
| 1
| Start (0=No, 1=Start/first byte)
|-
| 2
| Pause (0=Transfer Data, 1=Pause after Error, used with/after Stop)
|-
| 4
| Ack Flag (0=Error, 1=Okay) (For DataRead: W, for DataWrite: R)
|-
| 5
| Data Direction (0=Write, 1=Read)
|-
| 6
| Interrupt Enable (0=Disable, 1=Enable)
|-
| 7
| Start/busy (0=Ready, 1=Start/busy)
|}

= I2C Devices =
{| class="wikitable" border="1"
! [[I2C_Registers|Device id]]
! Device bus id
! Device Write Address
! Accessible via I2C [[I2C_Services|service]]
! Device description
|-
| 0
| 1
| 0x4a
| "i2c::MCU"
| Power management?(same device addr as the DSi power-management)
|-
| 1
| 1
| 0x7a
| "i2c::CAM"
| Camera0?(same dev-addr as DSi cam0)
|-
| 2
| 1
| 0x78
| "i2c::CAM"
| Camera1?(same dev-addr as DSi cam1)
|-
| 3
| 2
| 0x4a
| "i2c::MCU"
| MCU
|-
| 4
| 2
| 0x78
| "i2c::CAM"
| ?
|-
| 5
| 2
| 0x2c
| "i2c::LCD"
| ?
|-
| 6
| 2
| 0x2e
| "i2c::LCD"
| ?
|-
| 7
| 2
| 0x40
| "i2c::DEB"
| ?
|-
| 8
| 2
| 0x44
| "i2c::DEB"
| ?
|-
| 9
| 3
| 0xa6
| "i2c::HID"
| Unknown. The device table in I2C-module had the device address changed from 0xA6 to 0xD6 with [[8.0.0-18]].
|-
| 10
| 3
| 0xd0
| "i2c::HID"
| Gyroscope
|-
| 11
| 3
| 0xd2
| "i2c::HID"
| ?
|-
| 12
| 3
| 0xa4
| "i2c::HID"
| DebugPad
|-
| 13
| 3
| 0x9a
| "i2c::IR"
| IR
|-
| 14
| 3
| 0xa0
| "i2c::EEP"
| eeprom?
|-
| 15
| 2
| 0xee
| "i2c::NFC"
| New3DS-only [[NFC_Services|NFC]]
|-
| 16
| 1
| 0x40
| "i2c::QTM"
| New3DS-only [[QTM_Services|QTM]]
|-
| 17
| 3
| 0x54
| "i2c::IR"
| Used by IR-module starting with [[8.0.0-18]], for New3DS-only HID via "ir:rst". This deviceid doesn't seem to be supported by i2c module on [[8.0.0-18]](actual support was later added in New3DS i2c module).
|}

'''Notice''': These device addresses are used for writing to the respective device, for reading bit0 must be set (see I2C protocol). Thus, the actual device address is >> 1.

== Device 3 ==
{| class="wikitable" border="1"
! REGISTER
! WIDTH
! INFO
! DESCRIPTION
|-
| 0x00
| s
| ro
| Version high
|-
| 0x01
| s
| ro
| Version low
|-
| 0x02
| s
| ro
| ?
|-
| 0x03
| s
| rw
| Top screen flicker
|-
| 0x04
| s
| rw
| Bottom screen flicker
|-
| 0x05
- 0x07
| s(3)
| rw
| Danger zone - [[MCU_Services#MCU_firmware_versions|MCU unlock sequence]] is written here
|-
| 0x08
| s
| ro
| Raw 3D slider position
|-
| 0x09
| s
| ro
| Volume slider state (0x00 - 0x3F)
This is the same value returned by [[MCUHWC:GetSoundVolume|MCUHWC:GetSoundVolume]]
|-
| 0x0A
| s
| ro
| ? (seems to be power management related?)
|-
| 0x0B
| s
| ro
| Battery percentage
|-
| 0x0C
| s
| ro
| ? (changes to 0 for a second when the charger is plugged in then it resets to its previous value)
|-
| 0x0D
| s
| ro
| System voltage
|-
| 0x0E
| s
| ro
| ?
|-
| 0x0F
| s
| ro
| Flags: bit7-5 are read via [[MCU_Services|mcu::GPU]]. The rest of these are read via [[MCU_Services|mcu::RTC]]: bit4 = BatteryChargeState. bit3 = AdapterState. bit1 = ShellState.
|-
| 0x10
- 0x13
| s
| ro
| Received interrupt bitmask, see register 0x18 for possible values
If no interrupt was received this register is 0
|-
| 0x14
| s
| ro
| ?
|-
| 0x15
| s
| rw
| ?
|-
| 0x16
| s
| rw
| ?
|-
| 0x17
| s
| rw
| ?
|-
| 0x18
- 0x1B
| s
| rw
| Interrupt mask for register 0x10 (0=enabled,1=disabled)
bit00: Power button press
bit01: Power button held (the 3DS turns off regardless after a fixed time)
bit02: HOME button press
bit03: HOME button release
bit04: WiFi switch button
bit05: Shell close
bit06: Shell open
bit07: Fatal hardware condition([[Services#Notifications|?]])
bit08: Charger removed
bit09: Charger plugged in
bit10: ??? (Power Management related?)
bit11: ??? (HID related)
bit12: HID update
bit13: Battery dead(?)
bit14: ??? (Power Management related?)
bit15: ??? (Power Management related?)
bit22: Volume slider position change
bit24: ??? (???)
bit25: ??? (???)
bit26: ??? (???)
bit27: ??? (???)
bit28: ??? (???)
bit29: ??? (???)
bit30: forced off my mcu sysmodule
bit31: forced off my mcu sysmodule
|-
| 0x1C
| s
| rw
| ?
|-
| 0x1D
| s
| rw
| ?
|-
| 0x1E
| s
| rw
| ?
|-
| 0x1F
| s
| rw
| ?
|-
| 0x20
| s
| wo
| System power control:
bit0: power off
bit1: reboot (unused?)
bit2: reboot (used by mcu sysmodule and LgyBg)
bit3: used by LgyBg to power off, causes hangs in 3DS-mode
bit4: doesn't seem to do anything, but an mcu::RTC command uses this
Other bits are unused, and seem to do nothing.
|-
| 0x21
| s
| ro(?)
| ?
|-
| 0x22
| s
| wo
| Used to set LCD states
bit0: don't push to LCDs
bit1: push to LCDs
bit2: bottom screen backlight off
bit3: bottom screen backlight on
bit4: top screen backlight off
bit5: top screen backlight on
|-
| 0x23
| s
| ro(?)
| ?
|-
| 0x24
| s
| ??
| Watchdog timer. This must be set *before* the timer is triggered, otherwise the old value is used. Value zero disables the watchdog.
|-
| 0x25
| s
| rw
| ?
|-
| 0x26
| s
| rw
| ?
|-
| 0x27
| s
| ro
| Raw volume slider state
|-
| 0x28
| s
| rw
| Brightness of the WiFi/Power LED
|-
| 0x29
| ds(0x64)
| ro / rw
| Empty battery pattern holder, repeats all written bytes
|-
| 0x2A
| s
| rw
| WiFi LED state, non-0 value turns on the WiFi LED, capped at 0x0F
|-
| 0x2B
| s
| rw
| Camera LED state, 0, 3, 6-0xF = off, 1 = slowly blinking, 2 = constantly on, 4 = flash once, 5 = delay before changing to 2
|-
| 0x2C
| s
| rw
| 3D LED state, capped at 0x0F
|-
| 0x2D
| 0x64
| wo
| This is used for [[MCURTC:SetInfoLEDPattern|controlling]] the notification LED (see [[MCURTC:SetInfoLEDPatternHeader]] as well), when this register is written. It's possible to write data here with size less than 0x64, and only that portion of the pattern data will get overwritten. Reading from this register only returns zeroes, so it's considered write-only. Writing past the size of this register seems to do nothing.
|-
| 0x2E
| s
| ro
| This [[MCURTC:GetInfoLEDStatus|returns]] the notification LED status when read (1 means new cycle started)
|-
| 0x2F
| s
| ro(?)
| ?
|-
| 0x30
- 0x37
| s
| rw
| RTC time (system clock). 7 bytes are read from this. The upper nibble of each byte encodes 10s (BCD), so each byte is post-processed with (byte & 0xF) + (10 * (byte >> 4)).
byte 0: seconds
byte 1: minutes
byte 2: hours
byte 3: current day of the week (unused)
byte 4: days
byte 5: months
byte 6: years
byte 7: leap year counter (unused)
|-
| 0x38
- 0x3C
| s
| rw
| RTC alarm registers
Register 0x3B could be used to upload [[MCU_Services#MCU_firmware_versions|MCU firmware]] if some conditions are met.
|-
| 0x3D
0x3E
| s (2)
| ro
| RTC tick counter (resets to 0 when the seconds increase)
|-
| 0x3F
| s
| wo
| Peripheral power related? bit0 seems to depower everything, pressing the power key afterwards instantly turns the whole 3DS off
|-
| 0x40
| s
| rw
| Pedometer state (?)
|-
| 0x41
| s
| rw
| Index selector for register 0x44
|-
| 0x42
| s
| rw
| ?
|-
| 0x43
| s
| rw
| ???, accelometer related
|-
| 0x44
| s
| rw
| ???, accelometer related
|-
| 0x45
| s
| rw
| ?
|-
| 0x46
| s
| ro
| Gyro Y(?) axis rotation (0x00 = flat, 0x40 = 3DS standing on right side, 0xBE = 3DS standing on left side)
|-
| 0x48
| s
| ro
| Gyro Z(?) axis rotation (0x00 = flat, 0x40 = 3DS standing horizontally, 0xBE = 3DS base is horizontally upside-down)
|-
| 0x4A
| s
| ro
| Gyro X(?) axis rotation (0x00 = 3DS base facing upwards, 0x40 = face-down flat, 0xBE = standing(?) flat)
|-
| 0x4B
| s
| rw
| PedometerStepCount (for the current day)
|-
| 0x4C
| s
| rw
| ?
|-
| 0x4D
| s
| rw
| ?
|-
| 0x4E
| s
| rw
| ?
|-
| 0x4F
| 0x156
| ro
| ???
|-
| 0x50
| s
| rw
| ???
|-
| 0x51
| s
| rw
| ???
|-
| 0x52
- 0x57
| s
| rw
| ?
|-
| 0x58
| s
| rw
| DSP volume slider 0% volume offset (setting this to 0xFF will esentially mute the DSP as it's the volume slider's maximum raw value)
|-
| 0x59
| s
| rw
| DSP volume slider 100% volume offset (setting both this and the above to 0 will disable the volume slider with 100% volume, setting this to a lower value than the above will make the volume slider have only 2 states; on and off)
|-
| 0x5A
| s
| rw
| ?
|-
| 0x5B
- 0x5F
| s
| ro(?)
| ? (these seem to be invalid regsiters)
|-
| 0x60
| ds(1)
| ro
first byte is wo
| Looping queue register
Writing to first byte resets the queue position to the nth element
Reading from this register causes the values to shift up by `readsize-1`(needs confirmation) bytes after returning `readsize-1` bytes from the top of the stack (first byte is read-only, so is always zero)
|-
| 0x61
| ds(0x100)
| rw
| Writing to this register pushes values on top of register 0x60's stack. Reading from this register doesn't advance the stack.
The first byte is used to store flags for managing FIRM/NS state - bit0 = "WirelessDisabled", bit1 = "SoftwareClosed", bit2 = "PowerOffInitiated", bit4 = "LegacyJumpProhibited". This register survives power-off, but does not seem to be saved to non-volatile storage (does not survive battery pulls). This register doesn't seem to actually control MCU behaviour by itself, it just seems to be used for storing arbitrary data.
|-
| 0x62 - 0x7E
| s
| invalid (ro)
| These registers don't exist at all, thus reading them will yield 0xFF
|-
| 0x7F
| 19(?)
| ro
| Various system state information.
byte 06: battery related? (seems to decrease while charging and increase while discharging)
byte 09: system model (see [[Cfg:GetSystemModel#System_Model_Values|Cfg:GetSystemModel]] for values)
byte 10: power LED related? 0 is off, 1 is red
byte 13: RGB LED red intensity
byte 14: RGB LED green intensity
byte 15: RGB LED blue intensity
byte 17: WiFi LED brightness
byte 18: raw button states?
bit0: unset while power button is held
bit1: unset while home button is held
bit2: unset while Wifi slider is held
bit5: unset while the charging LED is active
bit6: unset while charger is plugged in

this byte is reset to 0 before an svcBreak takes effect
|-
| 0x80
- 0xFF
| s
| invalid (ro)
| These registers don't exist at all, thus reading them will yield 0xFF
|}

Note: the letter "s" in the size field means that the given register is in a "shared register pool", meaning if you read/write with size more than 1 you can read the next `readamount-1` of shared registers. It's possible to corrupt the shared value of a "non-shared" register by writing into a shared register with a size bigger than one. Writing more than 0x100 bytes into a shared register will corrupt all writable registers, including the shared portion of "non-shared" registers.

Non-shared register: it's a register separate from the shared register pool. Messing with these registers will not affect the shared register pool at all.

== Device 5 & 6 ==
LCD controllers for main/sub displays, most likely.

{| class="wikitable" border="1"
! Register
! Width
! Name
! Description
|-
| 0x1
| 8
| ?
|
|-
| 0x11
| 8
| ?
|
|-
| 0x40
| 8
| CMD_IN/CMD_RESULT1
| Write to trigger a command? Seen commands: 0xFF=Reset?, 0x62=IsFinished?. Result is stored in CMD_RESULT1:CMD_RESULT0.
|-
| 0x41
| 8
| CMD_RESULT0
| Read result
|-
| 0x50
| 8
| ?
|
|-
| 0x60
| 8
| ?
|
|-
| 0xFE
| 8
| ?
|
|}

== Device 10 ==
See the datasheet linked to on the [[Hardware]] page for reference.

== Device 12 ==
{| class="wikitable" border="1"
! REGISTER
! WIDTH
! DESCRIPTION
|-
| 0x0
| 21
| DebugPad state.
|}

This is the DebugPad device, see [[HID_Shared_Memory|here]].

== Device 13 ==
{| class="wikitable" border="1"
! Raw I2C register address
! Internal register address
! Width
! Description
|-
| 0x0
| 0x0
| 0x40
| RHR / THR (data receive/send FIFO)
|-
| 0x8
| 0x1
| 0x1
| IER
|-
| 0x10
| 0x2
| 0x1
| FCR/IIR
|-
| 0x18
| 0x3
| 0x1
| LCR
|-
| 0x20
| 0x4
| 0x1
| MCR
|-
| 0x28
| 0x5
| 0x1
| LSR
|-
| 0x30
| 0x6
| 0x1
| MSR/TCR
|-
| 0x38
| 0x7
| 0x1
| SPR/TLR
|-
| 0x40
| 0x8
| 0x1
| TXLVL
|-
| 0x48
| 0x9
| 0x1
| RXLVL
|-
| 0x50
| 0xA
| 0x1
| IODir
|-
| 0x58
| 0xB
| 0x1
| IOState
|-
| 0x60
| 0xC
| 0x1
| IoIntEna
|-
| 0x68
| 0xD
| 0x1
| reserved
|-
| 0x70
| 0xE
| 0x1
| IOControl
|-
| 0x78
| 0xF
| 0x1
| EFCR
|}

See the [http://www.alldatasheet.net/datasheet-pdf/pdf/347838/NXP/SC16IS750IBS.html datasheet] linked to on the [[Hardware]] page for reference. From that datasheet, for the structure of the I2C register address u8: "Bit 0 is not used, bits 2:1 select the channel, bits 6:3 select one of the UART internal registers. Bit 7 is not used with the I2C-bus interface, but it is used by the SPI interface to indicate a read or a write operation."

== Device 14 ==

Used by [[Config_Services|Cfg]]-sysmodule via the i2c::EEP service. This is presumably EEPROM going by the service name.

The Cfg-module code which loads the [[Flash_Filesystem|CCAL]](nandro:/sys/{HWCAL0.dat/HWCAL1.dat}) file from NAND will load it from I2C instead, if a certain state flag is non-zero. Likewise for the function which writes CCAL to NAND. HMAC/hash verification after loading is skipped when the CCAL was loaded from I2C.

== Device 15 ==
This the New3DS [[NFC_Services|NFC]] controller "I2C" interface. This device is accessed via the WriteDeviceRaw/ReadDeviceRaw I2C service [[I2C_Services|commands]].

Since the *Raw commands are used with this, this device has no I2C registers. Instead, raw data is transfered after the I2C device is selected. Hence, WriteDeviceRaw is used for sending commands to the controller, while ReadDeviceRaw is for receiving responses from the controller. Certain commands may return multiple command responses.

Command request / response structure:
{| class="wikitable" border="1"
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Normally 0x10?
|-
| 0x1
| 0x1
| Command source / destination.
|-
| 0x2
| 0x1
| CmdID
|-
| 0x3
| 0x1
| Payload size.
|}

Following the above header is the payload data(when payload size is non-zero), with the size specified in the header. The command response payload is usually at least 1-byte, where that byte appears to be normally 0x0. For command requests the payload data is the command parameters.

For command requests sent to the NFC tag itself, Cmd[1]=0x0 and CmdID=0x0. The command request payload data here is the actual command request data for the NFC tag, starting with the CmdID u8 at payload+0.

During NFC module startup, a certain command is sent to the controller which eventually(after various cmd-reply headers etc) returns the following the payload after the first byte in the payload:
000000: 44 65 63 20 32 32 20 32 30 31 32 31 34 3a 35 33 Dec 22 201214:53
000010: 3a 35 30 01 05 0d 46 05 1b 79 20 07 32 30 37 39 :50...F..y .2079
000020: 31 42 35 1B5

Or that is: "Dec 22 201214:53:50<binary>20791B5". Therefore, this appears to return the part-number of the NFC controller(other command request(s) / response(s) use this part-number value too).

=== NFC controller commands ===
{| class="wikitable" border="1"
! CmdRequest[1]
! CmdID
! Payload data for parameters
! Description
|-
| 0x2E
| 0x2F
| Firmware image for this chunk, size varies.
| This is used during NFC module startup to upload the firmware image to the NFC controller. This is used repeatedly to upload multiple chunks of the image.
|}

3DS Virtual Console

2017-10-10T12:36:22Z

D0k3: /* NAND Savegame on SD */ terminology fix

There are several types of VC titles: NES/GB/GBC VC titles, SNES VC titles, GameGear VC titles and GBA VC titles.
Except for GBA VC, the games are ran using emulators.

=NES/GB/GBC VC=
An emulator application + VC ROM in the NCCH [[RomFS]] (among other things in the RomFS). The emulator build includes support for all these three platforms, not specific to just the included ROM platform.

This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.

Unlike Wii VC, the 3DS VC ROMs for NES use [http://pastebin.com/KLeWt2W3 the "TNES" header].

==RomFS==
* "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
* "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
* "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
* "rom:/agb.bin" GBA BIOS.
* "rom:/buildtime.txt" Emulator app build timestamp.
* "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
* "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
* "rom:/shader.shbin" GPU shader.

==Savedata==
The savedata can contain:
* "rsm1.dat": Same format as the below rsm2.dat. Probably used for the "restore-point".
* "rsm2.dat": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "sav.dat": The actual savedata used by the emulated ROM.
* "SecureValue": The random number used by [[Anti Savegame Restore]]. No known version of the emulator implements both savestates and secure value.
Overwriting sav.dat with 0xFF-bytes doesn't have any affect on the actual emulator. Doing that with most of the rsm*.dat data doesn't crash anything.

=SNES VC=
An emulator application + VC ROM in the NCCH [[RomFS]] (among other things in the RomFS).
SNES VC titles are New 3DS exclusive.

==RomFS==
* "rom:/ErrorMessage/" This directory contains text used by the emulator app.
* "rom:/shader/" This directory contains .shbin GPU shaders used by the emulator app.
* "rom:/VCM/" This directory contains text used by the emulator app.
* "rom:/caravel.bcsar" This file contains audio used by the emulator app.
* "rom:/ctrl_change.arc" This file contains graphics used by the emulator app.
* "rom:/data.bin" This file contains the ROM and other data. See below for documentation.
* "rom:/ErrorMessage.arc" This file contains graphics used by the emulator app.
* "rom:/KTR-XXXX.icn" Copy of the SMDH of the game.
* "rom:/shader.shbin" GPU shader.
* "rom:/nnfont_RectDrawerShader.shbin" GPU shader.
* "rom:/VCM.arc" This file contains graphics used by the emulator app.

===data.bin structure===
The file begins with a header (all values are little-endian):
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x4
| Always 0x00000100
|-
| 0x04
| 0x4
| File size
|-
| 0x08
| 0x4
| Always 0x00000030
|-
| 0x0C
| 0x4
| Always 0x00000050
|-
| 0x10
| 0x4
| Start of the ROM (always 0x00000060 in official VC)
|-
| 0x14
| 0x4
| End of the ROM
|-
| 0x18
| 0x4
| Start of the footer region (presumably an index for the PCM audio samples). Matches end of file/file size if PCM data is missing
|-
| 0x1C
| 0x4
| Always 0
|-
| 0x20
| 0x4
| Start of decompressed SDD-1 graphics data region. Matches end of file/file size if no SDD-1 chip is present
|-
| 0x24
| 0x8
| Product ID (KTR-XXXX), determines filenames in savedata
|-
| 0x2C
| 0x4
| Always 0
|-
| 0x30
| 0x1
| Emulation speed in FPS (always 0x3C in official VC)
|-
| 0x31
| 0x3
| ROM size
|-
| 0x34
| 0x1
| Always 0
|-
| 0x35
| 0x3
| Size of the converted PCM audio samples region (starting after ROM). 0 if PCM data is missing
|-
| 0x38
| 0x1
| Always 0
|-
| 0x39
| 0x2
| Footer region size. 0 if PCM data is missing
|-
| 0x3B
| 0x2
| Always 0
|-
| 0x3D
| 0x2
| Game preset ID? (varies for each game). Incremental, started with 0x10XX values in old releases, newest ones have 0x11XX (with XX being back to low values).
|-
| 0x3F
| 0x1
| Always 0x2
|-
| 0x40
| 0x1
| Sound volume
|-
| 0x41
| 0x1
| ROM type (0x15 == HiROM/0x14 == LoROM)
|-
| 0x42
| 0xE
| Always 0
|-
| 0x50
| 0x4
| Always 0x00000003
|-
| 0x54
| 0x4
| Always 0x00000001
|-
| 0x58
| 0x8
| Always 0
|}

The 0x60 header is followed by the SNES ROM, often altered to replace audio samples with pointers to external PCM audio files converted from the game, presumably to speed up emulation (these pointers can be found by looking for "PCMF" in the ROM, as seen on [https://github.com/Plombo/vcromclaim/blob/master/snesrestore.py Wii VC]).
The ROM is then optionally followed by the PCM audio files, by the SDD-1 decompressed graphics data (presumably the emulator doesn't properly emulate the chip because of hardware constraints) and by a footer which appears to be an index for the PCM audio data.
There are no setting fields for specific cart features, and it appears that the emulator has "game presets" stored in its own code, which determine the cart expansion chip and probably more game-specific settings. Each official VC release has a different preset ID in the header.

==Savedata==
The savedata contains:
* "KTR-XXXX.cfg": Appears to contain the "preset ID" and possibly more game/save information.
* "KTR-XXXX.vea": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "KTR-XXXX.ves": The actual savedata used by the emulated ROM.

Filenames are determined in the ROM header.

=GBA VC=
GBA VC is run by [[FIRM|AGB_FIRM]]. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH [[ExeFS]] contains the same files as a normal application. The [[ExeFS]]:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.

===Footer===
All values in the GBA VC footer are little-endian.
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x004
| 0x4
| GBA ROM Filesize
|-
| 0x008
| 0x4
| Save type (see below)
|-
| 0x020
| 0x4
| LCD ghosting (01-FF, lower values equal more ghosting)
|-
| 0x024
| 0x300
| Video LUT (black to full, rgbrgbrgb...)?, three different types of this data have been observed.
|-
| 0x338
| 0x4
| GBA ROM Filesize
|-
| 0x344
| 0x4
| GBA ROM Filesize
|-
| 0x350
| 0x4
| Magic '.CAA'
|-
| 0x35A
| 0x2
| High two bytes of GBA ROM file size
|}

Save types:
* 0x0: EEPROM 8k
* 0x1: EEPROM 8k (?)
* 0x2: EEPROM 64k
* 0x3: EEPROM 64k (?)
* 0x4: Flash 512k (Atmel, ID: 0x3D1F) + RTC
* 0x5: Flash 512k (Atmel, ID: 0x3D1F)
* 0x6: Flash 512k (SST, ID: 0xD4BF) + RTC
* 0x7: Flash 512k (SST, ID: 0xD4BF)
* 0x8: Flash 512k (Panasonic, ID: 0x1B32) + RTC
* 0x9: Flash 512k (Panasonic, ID: 0x1B32)
* 0xA: Flash 1Mbit (Macronix, ID: 0x09C2) + RTC
* 0xB: Flash 1Mbit (Macronix, ID: 0x09C2)
* 0xC: Flash 1Mbit (Sanyo, ID: 0x1362) + RTC
* 0xD: Flash 1Mbit (Sanyo, ID: 0x1362)
* 0xE: SRAM/FRAM 256k

Everything above 0xE results in no save chip and nothing being saved to NAND.

===NAND Savegame===
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]]. From there, this is verified and copied out to SD (also see below). The savegame format is as follows:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Magic ('.SAV')
|-
| 0x4
| 0xC
| Always 0xFF
|-
| 0x10
| 0x10
| AES-CMAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata
|-
| 0x20
| 0x10
| Always 0xFF
|-
|-
| 0x30
| 0x4
| Always 0x1
|-
| 0x34
| 0x4
| Number of times saved (unused?)
|-
| 0x38
| 0x8
| AGB TitleID
|-
| 0x40
| 0x10
| SD card CID from the console the save was made on (verified on load)
|-
| 0x50
| 0x4
| Save start addr (always 0x200)
|-
| 0x54
| 0x4
| Save size
|-
| 0x58
| 0x8
| Always 0xFF (?)
|-
| 0x60
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x64
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x68
| 0x198
| Always 0xFF
|}

===NAND Savegame on SD===
A NAND savegame copied to the SD by process9 is identical to its counterpart on the NAND partition, save for the CMAC. For SD copies on retail units, the CMAC is recalculated as the AES-CMAC of the (SHA256 hash of ("CTR-SIGN" + AGB TitleID (little endian) + SHA256 hash of ("CTR-SAV0" + SHA256 hash of (0x30..0x200 + the entire save itself)))), using keyslot 0x30 set up with the keyY from movable.sed. For SD copies on devkit units, the CMAC is recalculated using the SHA256 hash of 0x30..0x200 + the entire save itself, using a different key from process9 .rodata.

3DS Virtual Console

2017-10-10T12:29:30Z

D0k3: /* NAND Savegame on SD */ Fixed endianness of the title ID

There are several types of VC titles: NES/GB/GBC VC titles, SNES VC titles, GameGear VC titles and GBA VC titles.
Except for GBA VC, the games are ran using emulators.

=NES/GB/GBC VC=
An emulator application + VC ROM in the NCCH [[RomFS]] (among other things in the RomFS). The emulator build includes support for all these three platforms, not specific to just the included ROM platform.

This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.

Unlike Wii VC, the 3DS VC ROMs for NES use [http://pastebin.com/KLeWt2W3 the "TNES" header].

==RomFS==
* "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
* "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
* "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
* "rom:/agb.bin" GBA BIOS.
* "rom:/buildtime.txt" Emulator app build timestamp.
* "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
* "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
* "rom:/shader.shbin" GPU shader.

==Savedata==
The savedata can contain:
* "rsm1.dat": Same format as the below rsm2.dat. Probably used for the "restore-point".
* "rsm2.dat": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "sav.dat": The actual savedata used by the emulated ROM.
* "SecureValue": The random number used by [[Anti Savegame Restore]]. No known version of the emulator implements both savestates and secure value.
Overwriting sav.dat with 0xFF-bytes doesn't have any affect on the actual emulator. Doing that with most of the rsm*.dat data doesn't crash anything.

=SNES VC=
An emulator application + VC ROM in the NCCH [[RomFS]] (among other things in the RomFS).
SNES VC titles are New 3DS exclusive.

==RomFS==
* "rom:/ErrorMessage/" This directory contains text used by the emulator app.
* "rom:/shader/" This directory contains .shbin GPU shaders used by the emulator app.
* "rom:/VCM/" This directory contains text used by the emulator app.
* "rom:/caravel.bcsar" This file contains audio used by the emulator app.
* "rom:/ctrl_change.arc" This file contains graphics used by the emulator app.
* "rom:/data.bin" This file contains the ROM and other data. See below for documentation.
* "rom:/ErrorMessage.arc" This file contains graphics used by the emulator app.
* "rom:/KTR-XXXX.icn" Copy of the SMDH of the game.
* "rom:/shader.shbin" GPU shader.
* "rom:/nnfont_RectDrawerShader.shbin" GPU shader.
* "rom:/VCM.arc" This file contains graphics used by the emulator app.

===data.bin structure===
The file begins with a header (all values are little-endian):
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x4
| Always 0x00000100
|-
| 0x04
| 0x4
| File size
|-
| 0x08
| 0x4
| Always 0x00000030
|-
| 0x0C
| 0x4
| Always 0x00000050
|-
| 0x10
| 0x4
| Start of the ROM (always 0x00000060 in official VC)
|-
| 0x14
| 0x4
| End of the ROM
|-
| 0x18
| 0x4
| Start of the footer region (presumably an index for the PCM audio samples). Matches end of file/file size if PCM data is missing
|-
| 0x1C
| 0x4
| Always 0
|-
| 0x20
| 0x4
| Start of decompressed SDD-1 graphics data region. Matches end of file/file size if no SDD-1 chip is present
|-
| 0x24
| 0x8
| Product ID (KTR-XXXX), determines filenames in savedata
|-
| 0x2C
| 0x4
| Always 0
|-
| 0x30
| 0x1
| Emulation speed in FPS (always 0x3C in official VC)
|-
| 0x31
| 0x3
| ROM size
|-
| 0x34
| 0x1
| Always 0
|-
| 0x35
| 0x3
| Size of the converted PCM audio samples region (starting after ROM). 0 if PCM data is missing
|-
| 0x38
| 0x1
| Always 0
|-
| 0x39
| 0x2
| Footer region size. 0 if PCM data is missing
|-
| 0x3B
| 0x2
| Always 0
|-
| 0x3D
| 0x2
| Game preset ID? (varies for each game). Incremental, started with 0x10XX values in old releases, newest ones have 0x11XX (with XX being back to low values).
|-
| 0x3F
| 0x1
| Always 0x2
|-
| 0x40
| 0x1
| Sound volume
|-
| 0x41
| 0x1
| ROM type (0x15 == HiROM/0x14 == LoROM)
|-
| 0x42
| 0xE
| Always 0
|-
| 0x50
| 0x4
| Always 0x00000003
|-
| 0x54
| 0x4
| Always 0x00000001
|-
| 0x58
| 0x8
| Always 0
|}

The 0x60 header is followed by the SNES ROM, often altered to replace audio samples with pointers to external PCM audio files converted from the game, presumably to speed up emulation (these pointers can be found by looking for "PCMF" in the ROM, as seen on [https://github.com/Plombo/vcromclaim/blob/master/snesrestore.py Wii VC]).
The ROM is then optionally followed by the PCM audio files, by the SDD-1 decompressed graphics data (presumably the emulator doesn't properly emulate the chip because of hardware constraints) and by a footer which appears to be an index for the PCM audio data.
There are no setting fields for specific cart features, and it appears that the emulator has "game presets" stored in its own code, which determine the cart expansion chip and probably more game-specific settings. Each official VC release has a different preset ID in the header.

==Savedata==
The savedata contains:
* "KTR-XXXX.cfg": Appears to contain the "preset ID" and possibly more game/save information.
* "KTR-XXXX.vea": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "KTR-XXXX.ves": The actual savedata used by the emulated ROM.

Filenames are determined in the ROM header.

=GBA VC=
GBA VC is run by [[FIRM|AGB_FIRM]]. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH [[ExeFS]] contains the same files as a normal application. The [[ExeFS]]:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.

===Footer===
All values in the GBA VC footer are little-endian.
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x004
| 0x4
| GBA ROM Filesize
|-
| 0x008
| 0x4
| Save type (see below)
|-
| 0x020
| 0x4
| LCD ghosting (01-FF, lower values equal more ghosting)
|-
| 0x024
| 0x300
| Video LUT (black to full, rgbrgbrgb...)?, three different types of this data have been observed.
|-
| 0x338
| 0x4
| GBA ROM Filesize
|-
| 0x344
| 0x4
| GBA ROM Filesize
|-
| 0x350
| 0x4
| Magic '.CAA'
|-
| 0x35A
| 0x2
| High two bytes of GBA ROM file size
|}

Save types:
* 0x0: EEPROM 8k
* 0x1: EEPROM 8k (?)
* 0x2: EEPROM 64k
* 0x3: EEPROM 64k (?)
* 0x4: Flash 512k (Atmel, ID: 0x3D1F) + RTC
* 0x5: Flash 512k (Atmel, ID: 0x3D1F)
* 0x6: Flash 512k (SST, ID: 0xD4BF) + RTC
* 0x7: Flash 512k (SST, ID: 0xD4BF)
* 0x8: Flash 512k (Panasonic, ID: 0x1B32) + RTC
* 0x9: Flash 512k (Panasonic, ID: 0x1B32)
* 0xA: Flash 1Mbit (Macronix, ID: 0x09C2) + RTC
* 0xB: Flash 1Mbit (Macronix, ID: 0x09C2)
* 0xC: Flash 1Mbit (Sanyo, ID: 0x1362) + RTC
* 0xD: Flash 1Mbit (Sanyo, ID: 0x1362)
* 0xE: SRAM/FRAM 256k

Everything above 0xE results in no save chip and nothing being saved to NAND.

===NAND Savegame===
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]]. From there, this is verified and copied out to SD (also see below). The savegame format is as follows:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Magic ('.SAV')
|-
| 0x4
| 0xC
| Always 0xFF
|-
| 0x10
| 0x10
| AES-CMAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata
|-
| 0x20
| 0x10
| Always 0xFF
|-
|-
| 0x30
| 0x4
| Always 0x1
|-
| 0x34
| 0x4
| Number of times saved (unused?)
|-
| 0x38
| 0x8
| AGB TitleID
|-
| 0x40
| 0x10
| SD card CID from the console the save was made on (verified on load)
|-
| 0x50
| 0x4
| Save start addr (always 0x200)
|-
| 0x54
| 0x4
| Save size
|-
| 0x58
| 0x8
| Always 0xFF (?)
|-
| 0x60
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x64
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x68
| 0x198
| Always 0xFF
|}

===NAND Savegame on SD===
A NAND savegame copied to the SD by process9 is identical to its counterpart on the NAND partition, save for the CMAC. For SD copies on retail units, the CMAC is recalculated as the AES-CMAC of the (SHA256 hash of ("CTR-SIGN" + Title ID (little endian) + SHA256 hash of ("CTR-SAV0" + SHA256 hash of (0x30..0x200 + the entire save itself)))), using keyslot 0x30 set up with the keyY from movable.sed. For SD copies on devkit units, the CMAC is recalculated using the SHA256 hash of 0x30..0x200 + the entire save itself, using a different key from process9 .rodata.

3DS Virtual Console

2017-10-10T12:27:22Z

D0k3: /* GBA VC */ Add information about CMACs on SD AGBSAVE copies

There are several types of VC titles: NES/GB/GBC VC titles, SNES VC titles, GameGear VC titles and GBA VC titles.
Except for GBA VC, the games are ran using emulators.

=NES/GB/GBC VC=
An emulator application + VC ROM in the NCCH [[RomFS]] (among other things in the RomFS). The emulator build includes support for all these three platforms, not specific to just the included ROM platform.

This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.

Unlike Wii VC, the 3DS VC ROMs for NES use [http://pastebin.com/KLeWt2W3 the "TNES" header].

==RomFS==
* "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
* "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
* "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
* "rom:/agb.bin" GBA BIOS.
* "rom:/buildtime.txt" Emulator app build timestamp.
* "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
* "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
* "rom:/shader.shbin" GPU shader.

==Savedata==
The savedata can contain:
* "rsm1.dat": Same format as the below rsm2.dat. Probably used for the "restore-point".
* "rsm2.dat": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "sav.dat": The actual savedata used by the emulated ROM.
* "SecureValue": The random number used by [[Anti Savegame Restore]]. No known version of the emulator implements both savestates and secure value.
Overwriting sav.dat with 0xFF-bytes doesn't have any affect on the actual emulator. Doing that with most of the rsm*.dat data doesn't crash anything.

=SNES VC=
An emulator application + VC ROM in the NCCH [[RomFS]] (among other things in the RomFS).
SNES VC titles are New 3DS exclusive.

==RomFS==
* "rom:/ErrorMessage/" This directory contains text used by the emulator app.
* "rom:/shader/" This directory contains .shbin GPU shaders used by the emulator app.
* "rom:/VCM/" This directory contains text used by the emulator app.
* "rom:/caravel.bcsar" This file contains audio used by the emulator app.
* "rom:/ctrl_change.arc" This file contains graphics used by the emulator app.
* "rom:/data.bin" This file contains the ROM and other data. See below for documentation.
* "rom:/ErrorMessage.arc" This file contains graphics used by the emulator app.
* "rom:/KTR-XXXX.icn" Copy of the SMDH of the game.
* "rom:/shader.shbin" GPU shader.
* "rom:/nnfont_RectDrawerShader.shbin" GPU shader.
* "rom:/VCM.arc" This file contains graphics used by the emulator app.

===data.bin structure===
The file begins with a header (all values are little-endian):
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x00
| 0x4
| Always 0x00000100
|-
| 0x04
| 0x4
| File size
|-
| 0x08
| 0x4
| Always 0x00000030
|-
| 0x0C
| 0x4
| Always 0x00000050
|-
| 0x10
| 0x4
| Start of the ROM (always 0x00000060 in official VC)
|-
| 0x14
| 0x4
| End of the ROM
|-
| 0x18
| 0x4
| Start of the footer region (presumably an index for the PCM audio samples). Matches end of file/file size if PCM data is missing
|-
| 0x1C
| 0x4
| Always 0
|-
| 0x20
| 0x4
| Start of decompressed SDD-1 graphics data region. Matches end of file/file size if no SDD-1 chip is present
|-
| 0x24
| 0x8
| Product ID (KTR-XXXX), determines filenames in savedata
|-
| 0x2C
| 0x4
| Always 0
|-
| 0x30
| 0x1
| Emulation speed in FPS (always 0x3C in official VC)
|-
| 0x31
| 0x3
| ROM size
|-
| 0x34
| 0x1
| Always 0
|-
| 0x35
| 0x3
| Size of the converted PCM audio samples region (starting after ROM). 0 if PCM data is missing
|-
| 0x38
| 0x1
| Always 0
|-
| 0x39
| 0x2
| Footer region size. 0 if PCM data is missing
|-
| 0x3B
| 0x2
| Always 0
|-
| 0x3D
| 0x2
| Game preset ID? (varies for each game). Incremental, started with 0x10XX values in old releases, newest ones have 0x11XX (with XX being back to low values).
|-
| 0x3F
| 0x1
| Always 0x2
|-
| 0x40
| 0x1
| Sound volume
|-
| 0x41
| 0x1
| ROM type (0x15 == HiROM/0x14 == LoROM)
|-
| 0x42
| 0xE
| Always 0
|-
| 0x50
| 0x4
| Always 0x00000003
|-
| 0x54
| 0x4
| Always 0x00000001
|-
| 0x58
| 0x8
| Always 0
|}

The 0x60 header is followed by the SNES ROM, often altered to replace audio samples with pointers to external PCM audio files converted from the game, presumably to speed up emulation (these pointers can be found by looking for "PCMF" in the ROM, as seen on [https://github.com/Plombo/vcromclaim/blob/master/snesrestore.py Wii VC]).
The ROM is then optionally followed by the PCM audio files, by the SDD-1 decompressed graphics data (presumably the emulator doesn't properly emulate the chip because of hardware constraints) and by a footer which appears to be an index for the PCM audio data.
There are no setting fields for specific cart features, and it appears that the emulator has "game presets" stored in its own code, which determine the cart expansion chip and probably more game-specific settings. Each official VC release has a different preset ID in the header.

==Savedata==
The savedata contains:
* "KTR-XXXX.cfg": Appears to contain the "preset ID" and possibly more game/save information.
* "KTR-XXXX.vea": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "KTR-XXXX.ves": The actual savedata used by the emulated ROM.

Filenames are determined in the ROM header.

=GBA VC=
GBA VC is run by [[FIRM|AGB_FIRM]]. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH [[ExeFS]] contains the same files as a normal application. The [[ExeFS]]:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.

===Footer===
All values in the GBA VC footer are little-endian.
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x004
| 0x4
| GBA ROM Filesize
|-
| 0x008
| 0x4
| Save type (see below)
|-
| 0x020
| 0x4
| LCD ghosting (01-FF, lower values equal more ghosting)
|-
| 0x024
| 0x300
| Video LUT (black to full, rgbrgbrgb...)?, three different types of this data have been observed.
|-
| 0x338
| 0x4
| GBA ROM Filesize
|-
| 0x344
| 0x4
| GBA ROM Filesize
|-
| 0x350
| 0x4
| Magic '.CAA'
|-
| 0x35A
| 0x2
| High two bytes of GBA ROM file size
|}

Save types:
* 0x0: EEPROM 8k
* 0x1: EEPROM 8k (?)
* 0x2: EEPROM 64k
* 0x3: EEPROM 64k (?)
* 0x4: Flash 512k (Atmel, ID: 0x3D1F) + RTC
* 0x5: Flash 512k (Atmel, ID: 0x3D1F)
* 0x6: Flash 512k (SST, ID: 0xD4BF) + RTC
* 0x7: Flash 512k (SST, ID: 0xD4BF)
* 0x8: Flash 512k (Panasonic, ID: 0x1B32) + RTC
* 0x9: Flash 512k (Panasonic, ID: 0x1B32)
* 0xA: Flash 1Mbit (Macronix, ID: 0x09C2) + RTC
* 0xB: Flash 1Mbit (Macronix, ID: 0x09C2)
* 0xC: Flash 1Mbit (Sanyo, ID: 0x1362) + RTC
* 0xD: Flash 1Mbit (Sanyo, ID: 0x1362)
* 0xE: SRAM/FRAM 256k

Everything above 0xE results in no save chip and nothing being saved to NAND.

===NAND Savegame===
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]]. From there, this is verified and copied out to SD (also see below). The savegame format is as follows:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Magic ('.SAV')
|-
| 0x4
| 0xC
| Always 0xFF
|-
| 0x10
| 0x10
| AES-CMAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata
|-
| 0x20
| 0x10
| Always 0xFF
|-
|-
| 0x30
| 0x4
| Always 0x1
|-
| 0x34
| 0x4
| Number of times saved (unused?)
|-
| 0x38
| 0x8
| AGB TitleID
|-
| 0x40
| 0x10
| SD card CID from the console the save was made on (verified on load)
|-
| 0x50
| 0x4
| Save start addr (always 0x200)
|-
| 0x54
| 0x4
| Save size
|-
| 0x58
| 0x8
| Always 0xFF (?)
|-
| 0x60
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x64
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x68
| 0x198
| Always 0xFF
|}

===NAND Savegame on SD===
A NAND savegame copied to the SD by process9 is identical to its counterpart on the NAND partition, save for the CMAC. For SD copies on retail units, the CMAC is recalculated as the AES-CMAC of the (SHA256 hash of ("CTR-SIGN" + Title ID (big endian) + SHA256 hash of ("CTR-SAV0" + SHA256 hash of (0x30..0x200 + the entire save itself)))), using keyslot 0x30 set up with the keyY from movable.sed. For SD copies on devkit units, the CMAC is recalculated using the SHA256 hash of 0x30..0x200 + the entire save itself, using a different key from process9 .rodata.

3DS Virtual Console

2017-09-12T09:50:00Z

D0k3: /* NAND Savegame */ - fixed a typo

There's two types of VC titles: regular VC titles, and dedicated GBA VC titles.

=Regular VC=
Regular VC titles: an emulator application + VC ROM in the NCCH [[RomFS]](among other things in the RomFS). The emulator build includes support for all supported VC platfms, not specific to just the included ROM platform.

This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.

Unlike Wii VC, the 3DS VC ROMs for NES use [http://pastebin.com/KLeWt2W3 the "TNES" header].

==RomFS==
* "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
* "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
* "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
* "rom:/agb.bin" GBA BIOS.
* "rom:/buildtime.txt" Emulator app build timestamp.
* "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
* "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
* "rom:/shader.shbin" GPU shader.

==Savedata==
The savedata can contain:
* "rsm1.dat": Same format as the below rsm2.dat. Probably used for the "restore-point".
* "rsm2.dat": Current emulator save-state, for storing/loading state at VC-title launch/exit.
* "sav.dat": The actual savedata used by the emulated ROM.
* "SecureValue": The random number used by [[Anti Savegame Restore]]. No known version of the emulator implements both savestates and secure value.
Overwriting sav.dat with 0xFF-bytes doesn't have any affect on the actual emulator. Doing that with most of the rsm*.dat data doesn't crash anything.

=GBA VC=
GBA VC is run by [[FIRM|AGB_FIRM]]. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH [[ExeFS]] contains the same files as a normal application. The [[ExeFS]]:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.

===Footer===
All values in the GBA VC footer are little-endian.
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x004
| 0x4
| GBA ROM Filesize
|-
| 0x008
| 0x4
| Save type (see below)
|-
| 0x020
| 0x4
| LCD ghosting (01-FF, lower values equal more ghosting)
|-
| 0x024
| 0x300
| Video LUT (black to full, rgbrgbrgb...)?, three different types of this data have been observed.
|-
| 0x338
| 0x4
| GBA ROM Filesize
|-
| 0x344
| 0x4
| GBA ROM Filesize
|-
| 0x350
| 0x4
| Magic '.CAA'
|-
| 0x35A
| 0x2
| High two bytes of GBA ROM file size
|}

Save types:
* 0x0: EEPROM 8k
* 0x1: EEPROM 8k (?)
* 0x2: EEPROM 64k
* 0x3: EEPROM 64k (?)
* 0x4: Flash 512k (Atmel, ID: 0x3D1F) + RTC
* 0x5: Flash 512k (Atmel, ID: 0x3D1F)
* 0x6: Flash 512k (SST, ID: 0xD4BF) + RTC
* 0x7: Flash 512k (SST, ID: 0xD4BF)
* 0x8: Flash 512k (Panasonic, ID: 0x1B32) + RTC
* 0x9: Flash 512k (Panasonic, ID: 0x1B32)
* 0xA: Flash 1Mbit (Macronix, ID: 0x09C2) + RTC
* 0xB: Flash 1Mbit (Macronix, ID: 0x09C2)
* 0xC: Flash 1Mbit (Sanyo, ID: 0x1362) + RTC
* 0xD: Flash 1Mbit (Sanyo, ID: 0x1362)
* 0xE: SRAM/FRAM 128k

Everything above 0xE results in no save chip and nothing being saved to NAND.

===NAND Savegame===
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking [[CONFIG_Registers#CFG_BOOTENV|CFG_BOOTENV]]. From there, this is verified and copied out to SD. The savegame format is as follows:
{| class="wikitable" border="1"
|-
! START
! SIZE
! DESCRIPTION
|-
| 0x0
| 0x4
| Magic ('.SAV')
|-
| 0x4
| 0xC
| Always 0xFF
|-
| 0x10
| 0x10
| AES-CMAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata
|-
| 0x20
| 0x10
| Always 0xFF
|-
|-
| 0x30
| 0x4
| Always 0x1
|-
| 0x34
| 0x4
| Number of times saved (unused?)
|-
| 0x38
| 0x8
| AGB TitleID
|-
| 0x40
| 0x10
| SD card CID from the console the save was made on (verified on load)
|-
| 0x50
| 0x4
| Save start addr (always 0x200)
|-
| 0x54
| 0x4
| Save size
|-
| 0x58
| 0x8
| Always 0xFF (?)
|-
| 0x60
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x64
| 0x4
| See [[ARM7_Registers|here]]
|-
| 0x68
| 0x198
| Always 0xFF
|}

NCSD

2017-01-23T12:20:10Z

D0k3: /* NCSD header */ fixed bad reserved size and offset

[[Category:File formats]]
This page documents the format of NCSD.

== Overview ==
There are two known specialisations of the NCSD container format. The CTR Cart Image (CCI) format and the 3DS' raw [[Flash Filesystem#NAND structure|NAND format]]. CCI is the format of game ROM images.

'''CTR System Update (CSU)''' is a variant of CCI, where the only difference is in the file extension. This is used with developer System Updates and associated [[3DS Development Unit Software|Tools]].

NCSD images start with a NCSD header, followed by up to a maximum of 8 [[NCCH]] partitions.

For CCI images, the partitions are reserved as follows:

{| class="wikitable" border="1"
|-
! [[NCCH]] Index
! Reserved Use
|-
| 0
| Executable Content ([[NCCH#CXI|CXI]])
|-
| 1
| E-Manual ([[NCCH#CFA|CFA]])
|-
| 2
| [[Download Play]] Child container ([[NCCH#CFA|CFA]])
|-
| 6
| New3DS [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])
|-
| 7
| [[System_Update_CFA|Update Data]] ([[NCCH#CFA|CFA]])
|}

The format of partitions can be determined from the partition FS flags (normally these are zero for CCI/CSU NCSD Images).

== NCSD header ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x000
| 0x100
| RSA-2048 SHA-256 signature of the NCSD header
|-
| 0x100
| 4
| Magic Number 'NCSD'
|-
| 0x104
| 4
| Size of the NCSD image, in media units (1 media unit = 0x200 bytes)
|-
| 0x108
| 8
| Media ID
|-
| 0x110
| 8
| Partitions FS type (0=None, 1=Normal, 3=FIRM, 4=AGB_FIRM save)
|-
| 0x118
| 8
| Partitions crypt type (each byte corresponds to a partition in the partition table)
|-
| 0x120
| 0x40=(4+4)*8
| Offset & Length partition table, in media units
|-
| 0x160
| 0xA0
| ...
|}

For carts,
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x160
| 0x20
| Exheader SHA-256 hash
|-
| 0x180
| 0x4
| Additional header size
|-
| 0x184
| 0x4
| Sector zero offset
|-
| 0x188
| 8
| Partition Flags (See Below)
|-
| 0x190
| 0x40=8*8
| Partition ID table
|-
| 0x1D0
| 0x20
| Reserved
|-
| 0x1F0
| 0xE
| Reserved?
|-
| 0x1FE
| 0x1
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM. Bit0=1 enables using bits 1-2, it's unknown what these two bits are actually used for(the value of these two bits get compared with some other value during NCSD verification/loading). This appears to enable a new, likely hardware-based, antipiracy check on cartridges.
|-
| 0x1FF
| 0x1
| Support for this was implemented with [[9.6.0-24|9.6.0-X]] FIRM, see below regarding save crypto.
|}

For NAND,

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x160
| 0x5E
| Unknown
|-
| 0x1BE
| 0x42
| Encrypted MBR partition-table, for the TWL partitions(key-data used for this keyslot is console-unique).
|}

=== NCSD Signature ===
The RSA pubk used for gamecard NCSD is stored in [[Memory_layout|ITCM]]. The separate pubk used for NAND NCSD is stored in Process9 .(ro)data instead of ITCM.

=== Partition Flags ===
{| class="wikitable" border="1"
|-
! Byte Index
! Description
|-
| 0
| Backup Write Wait Time (The time to wait to write save to backup after the card is recognized (0-255 seconds)).NATIVE_FIRM loads this flag from the gamecard NCSD header starting with [[6.0.0-11]].
|-
| 3
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (SDK 3.X+)
|-
| 4
| Media Platform Index (1 = CTR)
|-
| 5
| Media Type Index (0 = Inner Device, 1 = Card1, 2 = Card2, 3 = Extended Device)
|-
| 6
| Media Unit Size i.e. u32 MediaUnitSize = 0x200*2^flags[6];
|-
| 7
| Media Card Device (1 = NOR Flash, 2 = None, 3 = BT) (Only SDK 2.X)
|}

=== Partition Flags (In Terms of Save Crypto Determination) ===
{| class="wikitable" border="1"
|-
! Byte Index
! Description
|-
| 1
| Starting with [[6.0.0-11]] NATIVE_FIRM will use this flag to determine the gamecard [[Savegames|savegame]] keyY method, when flag[3] is set. 0 = [[2.0.0-2]] hashed keyY, 1 = [[Savegames|new]] keyY method implemented with [[6.0.0-11]]. 0x0A = implemented with [[9.3.0-21|9.3.0-X]]. On Old3DS this is identical to the [[2.2.0-4]] crypto. On New3DS this is identical to the [[2.2.0-4]] crypto, except with New3DS-only gamecard savedata [[AES|keyslots]].
Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 now sets <savecrypto_stateval> to partitionflag[1] + <the u8 value from NCSD+0x1FF>, instead of just setting it to partitionflag[1].
|-
| 3
| Support for this flag was implemented in NATIVE_FIRM with [[2.0.0-2]]. When this flag is set the hashed gamecard [[Savegames|savegame]] keyY method is used, this likely still uses the repeating-CTR however. With [[6.0.0-11]] the system will determine the gamecard savegame keyY method via flag[1], instead of just using the hashed keyY via this flag.
|-th
| 7
| This flag enables using the hashed gamecard [[Savegames|savegame]] keyY method, support for this flag was implemented in NATIVE_FIRM with [[2.2.0-4]]. All games with the NCSD image finalized since [[2.2.0-4]](and contains [[2.2.0-4]]+ in the system update partition) have this flag set, this flag also enables using new CTR method as well.
|}

Starting with [[9.6.0-24|9.6.0-X]] FIRM, Process9 will just write val0 to a state field then return 0, instead of returning an error when the save crypto type isn't recognized. This was the *only* actual functionality change in the Old3DS Process9 function for gamecard savedata crypto init.

== Card Info Header ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x200
| 4
| CARD2: Writable Address In Media Units (For 'On-Chip' Savedata). CARD1: Always 0xFFFFFFFF.
|-
| 0x204
| 4
| Card Info Bitmask
|-
| 0x208
| 0x108
| Reserved1
|-
| 0x310
| 2
| Title version
|-
| 0x312
| 2
| Card revision
|-
| 0x208
| 0xCEE
| Reserved2
|-
| 0x1000
| 0x10
| Card seed keyY (first u64 is Media ID (same as first NCCH partitionId))
|-
| 0x1010
| 0x10
| Encrypted card seed (AES-CCM, keyslot 0x3B for retail cards, see [[CTRCARD_Registers|CTRCARD_SECSEED]])
|-
| 0x1020
| 0x10
| Card seed AES-MAC
|-
| 0x1030
| 0xC
| Card seed nonce
|-
| 0x103C
| 0xC4
| Reserved3
|-
| 0x1100
| 0x100
| Copy of first NCCH header (excluding RSA signature)
|}

== Development Card Info Header Extension ==
{| class="wikitable" border="1"
|-
! OFFSET
! SIZE
! DESCRIPTION
|-
| 0x1200
| 0x200
| CardDeviceReserved1
|-
| 0x1400
| 0x10
| TitleKey
|-
| 0x1410
| 0xF0
| CardDeviceReserved2
|}

Note that a particular flashcard vendor puts what many refer to as "private headers" here in place of actual development card information. This header is constituted by a cartridge-unique Id obtained from [[Process_Services_PXI|pxi:ps9::GetRomId]] and the title-unique cart ID (identical for all carts of the same title; can be retrieved using the NTR gamecard protocol command 0x90 or through the CTR protocol commands 0x90 or 0xA2).

== Tools ==

[https://github.com/3dshax/ctr/tree/master/ctrtool ctrtool] - (CMD)(Windows/Linux) Parsing NCSD files

[[3DSExplorer]] - (GUI)(Windows Only) Parsing NCSD files

Serials

2016-10-22T11:04:43Z

D0k3: /* Fix check digit formula (old formula does not work for certain combinations) */

This page talks about the 3DS products' serial number and model number structures (the console, manual, accessories, games, etc...).

== Console Serial Numbers ==

A 3DS console serial number is composed of at least two letters followed by nine decimal digits. The ninth digit is a "check digit", meaning that it is derived from the other digits.

The check digit is an industry-standard algorithm, the one used for UPC codes. To calculate the check digit of a 3DS console, separate the non-check digits into "odd" and "even" groups, where the "odd" group is digits in odd-numbered positions, and the "even" group is digits in even-numbered positions. (The first digit is "odd", with "first" representing "1".)

After separating the digits, add the digits in each group together. Multiply the sum of the even digits by 3, then add the sum of the odd digits. To calculate the check digit, take this value modulo 10, and if not 0, subtract from 10.

Example: CW404567772

The non-check digits are 40456777. Separating into odd and even groups, we get the following:

Odds: 4 + 4 + 6 + 7 = 21
Evens: 0 + 5 + 7 + 7 = 19

Applying the algorithm, we get ((3 * 19) + 21) % 10 = 8, which is not 0, thus 10 - 8 = 2, matching the example's check digit.

The letter prefixes are a letter specifying the device, followed by one letter specifying the region in which it was sold. In some regions, a third letter is present; a current guess is that this letter distinguishes among factories for a given sales region. Note that several different sales regions' console may be considered to be the same region for region-locking purposes, such as Europe and Australia.

{| class="wikitable"
! Model !! Device Prefix (Retail) !! Device Prefix (Dev)
|-
| 3DS || C || E
|-
| 3DS XL/LL || S
|-
| 2DS || A || P
|-
| New 3DS || Y || Y
|-
| New 3DS XL/LL || Q || Q
|}

Development units with the same prefix as retail can be distinguished by development units having a 0 as the first digit of the serial number portion.

{| class="wikitable"
! Sales Region !! Region Lock !! Region Suffix
|-
| Japan || Japan || JF, JH, JM
|-
| North America || North America || W
|-
| Middle East / Southeast Asia || North America || S
|-
| Europe || Europe || EF, EH, EM
|-
| Australia || Europe || AH
|}

== Console Models ==

{| class="wikitable"
! Device !! Product Code
|-
| 3DS || CTR
|-
| 3DS XL/LL || SPR
|-
| 2DS || FTR
|-
| [[New 3DS]] || KTR
|-
| [[New 3DS]] XL/LL || RED
|}

The DS had the product code NTR, so we see the TR is recurring.

== Title ID and Unique ID ==
''see [[Titles]]''

== NCCH Product Code ==

This serial is similiar to the "physical serial" described later in this page; it is the canonical identifier for a specific title in the field of business formalities with Nintendo, but this is not reflected in the 3DS's software architecture (where it is vastly unused in favor of the Title ID: it is therefore considered the successor of the "internal name" contained in ROMs of previous handhelds), is not guaranteed to be unique.

The product code is located in a [[NCCH]]'s header (not its ExHeader).

The product code "CTR-P-CTAP" is the default generic product code for NCCH files. Most [[NCSD|NCCHs apart from the first one]] in a title are generally CTR-P-CTAP.
Referring to "the product code of a title" is therefore a simplification for "the product code of the NCCH in its first partition".

So, for example, a Japanese copy of Ridge Racer 3D would have a product code of "CTR-P-ARRJ" and a serial of "LNA-CTR-ARRJ-JPN".

A Nintendo-assigned product code follows this format, however, there is no requirement for a product code to match or resemble this structure as long as it's within the length limit:

[CTR/KTR]-[Category letter]-[Type][Identifier][Region]-[Sub ID]

{| class="wikitable"
! Category letter !! Description
|-
| P || Cartridge software, or downloadable versions of them.
|-
| N || Digital-only releases, including [[Title list|system applications and applets]].
|-
| M || [[DLC]]
|-
| T || [[eShop Demos]], excluding so-called "special demos" which are category N.
|-
| U || [[Title list#0004000E - Add-on Content (Updates)|Patches]] for category P titles.
|}

The "sub ID" only applies to DLC, demos, and local copies of Download Play titles. It's a 2-digit number associated with the [[Title list|Title ID Variation]].

See the next chapter for explanation of the other components of the Product Code.

== Physical (only?) Serial ==

[Product][Retail/Demo]-CTR-[Type][Identifier][Region]

{| class="wikitable"
! Field !! Length !! Description
|-
| Product || 2 || Product type (cartridges are LN, game boxes are TS, instruction manuals are MA, leaflets are FA, quick-start guides are MK)
|-
| Retail/Demo || 1 || Retail (A) or Demo (Z)
|-
| CTR/KTR || 3 || Platform. CTR = 3DS, KTR = New 3DS
|-
| Type || 1 || [A/C/H/J/K/S/P/T] - Retail / C is part of the default serial 'CTAP' / H is used for built in applications like [[Mii Maker]] / J is for a normal eShop Title / K is unknown, seen in Mighty Gunvolt / S is usually a 3D Classics eShop title / P is used with GBA eShop titles / T is used with NES eShop titles.
|-
| Identifier || 2 || game name (two alphanumeric characters).
|-
| Region || 1 || [E/P/J/K/C/Y/Z/A] - English (US) / PAL (Europe/Australia) / Japanese (Japan) / Korean (Korea) / Chinese (China/Taiwan) / Unknown (Japan/Korea?) (seen in Johnny's Payday Panic (Korea)) / Unknown (seen in Mighty Gunvolt) / All (region-free)
|}

The longer version of the serial number adds a geographical region (usually because of extra languages).

Those are 3 letters codes at the end of the serial (can be found mostly on demos).

For example, the code of the Canadian version of Mario Kart 7 is CAN (link removed, links to incorrect image).

=== Electronic Manuals ===

Some eShop titles have [[NCCH#CFA|Electronic Manuals]] which store the product code at the end of the 'Health & Safety' section of the manual. However, product codes can differ from the above format as shown below:

CTR-[P/N/T/U]-[Type][Identifier][Region]-[Region]-[Digit]

CTR-[Type][Identifier][Region]-[Region]-[Digit]

* P/N/T/U - Same as in product code structure
* [Type][Identifier][Region] - Same as in serial structure
* [Region] - A three character representation of the title region, i.e. 'EUR' (not always present)
* [Digit] - A single digit usually '1' or '0' (not always present)

'''Note:''' These alternate versions of the product code, potentially found in [[NCCH#CFA|Electronic Manuals]] don't represent the actual product code, as found in the game's CXI. They are only found in the game's Home Menu manual, and on the game's packaging and external labeling.

==Back of Card Serial==
AREPY10111

[Identifier]-[Production Month]-[Production Year]-[Revision]-[Production Run?]

Config Savegame

2016-06-15T09:28:39Z

D0k3:

This page describes the format of the [[Config_Services|Cfg]] [[System_SaveData|NAND]] savegame. These blocks can be accessed with the Cfg service commands.

==Structure of save-file "/config"==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Total entries
|-
| 0x2
| 0x2
| Data entries offset
|-
| 0x4
| 0x4558
| Block entries
|-
| 0x455C
|
| Data for the entries
|}

The filesize for this /config file is 0x8000-bytes.

==Configuration block entry ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| BlkID
|-
| 0x4
| 0x4
| Offset to the data for this block when size is >4, otherwise this word is the data for this block
|-
| 0x8
| 0x2
| Size
|-
| 0xA
| 0x2
| Flags
|}

==Configuration blocks==
{| class="wikitable" border="1"
|-
! BlkID
! Size
! Flags
! Description
|-
| 0x00000000
| 0x2
| ?
| Config savegame version?
|-
| 0x00030001
| 0x8
| 0xE
| Changes when data / time is changed in settings (read by CECD)
|-
| 0x00040000
| 0x10
| 0x8
| ? (read by HID)
|-
| 0x00040001
| 0x1C
| 0x8
| ? (read by HID)
|-
| 0x00040002
| 0x12
| 0x8
| ? (read by HID)
|-
| 0x00040003
| 0xC
| 0x8
| ? (read by HID)
|-
| 0x00050001
| 0x2
| 0x8
| ? (read by GSP)
|-
| 0x00050002
| 0x38
| 0x8
| ? (read by GSP)
|-
| 0x00050003
| 0x20
| 0x8
| ? (read by GSP)
|-
| 0x00050005
| 0x20
|?
| Stereo camera settings?
|-
| 0x00050006
| 0x2
| 0x8
| ?
|-
| 0x00070001
| 0x1
|?
| Sound output mode (mono/stereo/surround)?
|-
| 0x00080000
| 0xC00
| 0x2?
| WiFi configuration slot 0
|-
| 0x00080001
| 0xC00
| 0x2?
| WiFi configuration slot 1
|-
| 0x00080002
| 0xC00
| 0x2?
| WiFi configuration slot 2
|-
| 0x00090000
| 0x8
| 0x2?
| This contains a u64 ID, used by processes using [[NWMUDS:InitializeWithVersion]]. The first word is the same as [[CfgS:GetLocalFriendCodeSeed|LocalFriendCodeSeed]], while the latter is a separate word.
|-
| 0x00090001
| 0x8
| 0xE
| This console-unique u64 used by [[Cfg:GenHashConsoleUnique|GenHashConsoleUnique]] is generated with the LocalFriendCodeSeed and with random data
|-
| 0x000A0000
| 0x1C
| 0xE
| Username
|-
| 0x000A0001
| 0x2
| 0xE
| Birthday (u8 month, u8 day)
|-
| 0x000A0002
| 0x1
| 0xA
| Language

|-
| 0x000B0000
| 0x4
| 0x8
| CountryInfo
|-
| 0x000B0001
| 0x800
| 0x2?
| Country name in UTF-16, every 0x80-bytes is an entry for each language, in the order of the Language table below (not all entries are set)
|-
| 0x000B0002
| 0x800
| 0x2?
| State name in UTF-16, every 0x80-bytes is an entry for each language
|-
| 0x000B0003
| 0x4
| 0xE
| Pair of 16-bit values, meaning unknown but related to address (ZIP code?)

|-
| 0x000C0000
| 0xC0
| 0x8
| Restricted photo exchange data, and other info
|-
| 0x000C0001
| 0x14
|?
| Same as above?
|-
| 0x000D0000
| 0x4
| 0x2
| u16 at offset 0x0: [[SMDH#EULA_Version|EULA Version]] which was agreed to.
|-
| 0x000F0000
| 0x10
| 0x8?
| Unknown, used by [[NS]] on dev-units for [[SVC|svcKernelSetState]], where Type is 6. During NS startup on debug-units, NS compares the u32 from +8 in this config-block with the [[Configuration_Memory#APPMEMTYPE|APPMEMTYPE]]. When those don't match NS starts a FIRM-launch (with the same FIRM titleID as the currently running one) to boot into a FIRM with the APPMEMTYPE value from this config-block
|-
| 0x000F0004
| 0x4
| 0x8?
| The first u8 is the System-Model [[Cfg:GetSystemModel|value]], the last 3-bytes are unknown
|-
| 0x00110000
| 0x4
|?
| The low u16 indicates whether the system setup is required, such as when the system is booted for the first time or after doing a [[System Settings|System Format]]: 0 = setup required, non-zero = no setup required
|-
| 0x00110001
| 0x8
| 0xA?
| TitleID of the menu to launch, used by [[NS]] on dev units (this block can be edited on dev units with [[3DS Development Unit Software#Config|Config]])
|-
| 0x00120000
| 0x8
| 0x8
| ? (read by HID)
|-
| 0x00130000
| 0x4
|?
| If response is 0x100 then debug mode is enabled.
|-
| 0x00160000
| 0x4
| 0x8?
| Unknown, first byte is used by config service-cmd [[Config_Services|0x00070040]]. (Unknown whether the last 3-bytes are used)
|-
| 0x00190000
| 0x1
| 0x8?
| Unknown. NFC-module checks for value1/non-value1.
|}

The developer unit TID block only exists on developer units.

===Languages===
{| class="wikitable" border="1"
|-
! ID
! Description
|-
| 0
| JP
|-
| 1
| EN
|-
| 2
| FR
|-
| 3
| DE
|-
| 4
| IT
|-
| 5
| ES
|-
| 6
| ZH
|-
| 7
| KO
|-
| 8
| NL
|-
| 9
| PT
|-
| 10
| RU
|-
| 11
| TW
|}

===CountryInfo===
{| class="wikitable" border="1"
|-
! Byte
! Description
|-
| 0
|?
|-
| 1
|?
|-
| 2
|?
|-
| 3
| Country code, same as DSi/Wii country codes. Value 0xFF is invalid.
|}

===0x000A0000 Block===
{| class="wikitable" border="1"
|-
! Byte
! Description
|-
| 0x0-0x13
| UTF-16 username, with no NULL-terminator.
|-
| 0x14-17
| Usually zero?
|-
| 0x18-0x1B
| u32 NGWord version the username was last checked with. If this value is less than the u32 stored in the NGWord CFA "romfs:/version.dat", the system then checks the username string with the bad-word list CFA again, then updates this field with the value from the CFA
|}

===LCD display config===
There seems to be some sort of LCD display configuration stored in this cfg. When using the cfg-save from an Old3DS on a New3DS without formatting the cfg first, the bottom-screen display is somewhat off(which is fixed by formatting the cfg-save).