Bootloader

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 system firmware from the internal 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 CFG_SYSPROT9 and CFG_SYSPROT11, respectively. The non-protected areas of the ARM9 and ARM11 boot ROMs are identical for launch-day regular Old3DS, 2DS, and regular New3DS.

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;
 CTR_word[1] = outbufaddr;
 CTR_word[2] = readsize;
 CTR_word[3] = readsize;

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 is write-protected by the spiflash.

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.

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 ptr passed to the aes-keyinit function for retail.
• 0xffffdc60(end-addr of the above area) size 0x400-bytes: This is the ptr passed to the aes-keyinit function for devunit. 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.

• ...

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).

Boot Procedure

• 0 seconds - unit is powered on. The ARM9 and ARM11 bootroms begin execution.

• 2 seconds - ARM9 bootrom attempts to initialize the NAND.
  • If the NAND is successfully initialized:
    • the ARM9 bootrom loads the firmware stored in the NAND FIRM partition which handles booting the rest of the system (if verification for NAND firm0 fails, the ARM9 bootrom will attempt to use firm1 instead).
    • The ARM11 kernel loaded from FIRM then launches the CXI ARM11 system modules loaded from FIRM (i.e. sm, fs, pm, loader, and pxi). (Note that the ARM11 kernel does not handle any encryption/RSA verification, this is handled by the ARM9.)
  • If the NAND cannot be initialized (i.e. the NAND chip is not connected/damaged/etc), a blue error screen appears.

• 3 seconds - all essential hardware is active.
  • The PM module launches NS
  • If auto-booting is needed, NS will auto-boot titles.
  • Otherwise, NS will instead launch ErrDisp and the 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 here.

• 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:

Error	Description
00F800FE 00000000 00000000 00000200 00000000	Error when having SD-card reader connected to NAND during boot.
00F800FE 00000000 00000000 00000400 00000000	NAND not found error (?)
00F800FE FFFFFFFF FFFFFFFF 00000080 00800000	NAND error when DAT1 was used as DAT0.
00F800FE FFFFFFFF FFFFFFFF 00000005 00800000	NAND error when DAT2 was used as DAT0.
00F800FE FFFFFFFF FFFFFFFF 00000005 00000000	NAND error when DAT3 was used as DAT0.
00F800FF F8F8FFFF FFFFFFFF 00000000 00000000	Both the firm0 and firm1 partitions are corrupt (failed signature checks).
00F800EE FFFFFFFF FFFFFFFF 00000000 00000000	NCSD header in sector 0 is corrupt (failed signature check).

Tools

• boot9_tools