516
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − + − + Line 20:
Line 20: + + Line 25:
Line 27: − + Line 118:
Line 120: − + + + + + + Line 130:
Line 137: + + + + + + + + + Line 216:
Line 232: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − + − + − **If the NAND is successfully initialized:+ − ***the ARM9 bootrom loads the [[FIRM|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 [[NCCH#CXI|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 [[FIRM|ARM9]].) − **If the NAND cannot be initialized (i.e. the NAND chip is not connected/damaged/etc), a [[Bootloader#Error_Codes|blue error screen]] appears. − − * 3 seconds - all essential hardware is active. − − +
→0x1FFFE000 memory
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]].
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.
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 ==
== 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 the regular and XL versions of the Old 3DS, 2DS and New 3DS consoles.
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 ==
== NAND FIRM boot ==
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).
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.
For non-NAND booting, NCSD / FIRM-backup is not used.
== SDMMC ==
== 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 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 ==
== Boot9 RSA keyslots ==
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.
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.
* 8bit-entry-array 0x1FFFE000+0xC: 8bit status-codes initialized by boot9 main(), for the FIRM-boot devices. +0 is NAND and +2 is wifi-spiflash.
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.
* 8bit-entry-array 0x1FFFE000+0x10: Status-codes originally from nand_findfirmpartition_loadfirm(), for each of the 8 NCSD partitions.
| 0x00
| 0x00
| Success
| 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)
| 0xDF(~32)
| Failed to read sector data from the device.
| Failed to read sector data from the device.
|-
| 0xCF(~48)
| FIRM section validation function failed: FIRM section is invalid.
|-
|-
| 0xF7(~8)
| 0xF7(~8)
FIRMLOAD_EXIT:
FIRMLOAD_EXIT:
Here firmboot() is called, which should never return. The instruction after this bl is a call for panic().
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 ==
== Boot Procedure ==
* 0 seconds - unit is powered on. The ARM9 and ARM11 [[Memory_layout|bootroms]] begin execution.
* 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.
* 2 seconds - ARM9 bootrom attempts to initialize the NAND.
**The ARM11 sysmodules included with FIRM are launched by ARM11-kernel, etc.
**The [[Process_Manager_Services|PM]] module launches [[NS]].
**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.
**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.
**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]].
**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.
* 4 seconds - the LCD screens are initialized.