Changes

766 bytes added ,  03:16, 17 April 2018
no edit summary
Line 14: Line 14:  
=== Is there a JTAG? ===
 
=== Is there a JTAG? ===
 
=== Is there more than one revision of the bootrom? ===
 
=== Is there more than one revision of the bootrom? ===
'''Background:''' Bootrom visible portion has been dumped on 3DS, 3DSXL, 2DS, New3DS. All matching exactly.
+
'''Background:''' Bootrom visible portion has been dumped on the entire 3DS Family (3DS, 3DSXL, 2DS, New3DS, New3DSXL, New2DSXL), and even a prototype board from April(?) 2010. All matching exactly.
 +
 
 
=== What is the EMMC controller @ 0x10100000 doing? ===
 
=== What is the EMMC controller @ 0x10100000 doing? ===
 
'''Background:''' There's dead code in NWM referencing it.
 
'''Background:''' There's dead code in NWM referencing it.
Line 27: Line 28:     
=== How does Nintendo reflash bricked systems? ===
 
=== How does Nintendo reflash bricked systems? ===
'''Background:''' The boot ROM will boot from SPI flash if the FIRM partitions are both corrupt.  But if, say, Home Menu gets deleted, the system is dead, and boot ROM would still see the NAND as valid. How does Nintendo's refurbishing center reflash such systems?
+
Before trying to boot from NAND, the bootrom checks to see if a key combination (Start + Select + X) is being held, and whether the shell is closed. If so, it tries to boot from an inserted NTR (Nintendo DS) cartridge.
 +
This allows to execute a FIRM that is probably used by Nintendo to reflash the system.
    
== Software ==
 
== Software ==
Line 34: Line 36:  
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
 
=== What did SVC 0x74 in the ARM11 kernel do before it got stubbed? ===
 
=== What is the PTM abbreviation? ===
 
=== What is the PTM abbreviation? ===
 +
: Power/time management
 +
 
=== Why is the DTCM not used anywhere except bootrom? ===
 
=== Why is the DTCM not used anywhere except bootrom? ===
 
'''Background:''' Bootrom is known to use part of DTCM as state, memsetting it to 0 when it's done. After that, it is never used again.
 
'''Background:''' Bootrom is known to use part of DTCM as state, memsetting it to 0 when it's done. After that, it is never used again.
 
=== How is CTRAging launched during factory setup? ===
 
=== How is CTRAging launched during factory setup? ===
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.
+
'''Background:''' No TestMenu version is capable of launching CTRAging directly: O3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and the TWL/AGB test apps; N3DS factory TestMenu can only launch DevMenu installed on NAND, the inserted cartridge and System Settings.  
 +
 
 +
'''Theory:''' NtrBoot another time
 
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===
 
=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===
 +
=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===
 +
'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.
48

edits