Changes

980 bytes added ,  07:56, 10 August 2022
formatting
Line 5: Line 5:  
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
 
: C may stand for Chiheisen ("horizon" in Japanese, the O3DS's codename being "Project Horizon").
 
:: Not true, Horizon refers to the OS.
 
:: Not true, Horizon refers to the OS.
 +
: CTR stands for Citrus.
    
== Hardware ==
 
== Hardware ==
Line 25: Line 26:     
=== What is the PDN abbreviation? ===
 
=== What is the PDN abbreviation? ===
: Power distribution network
+
: PowerDowN
    
=== How does Nintendo reflash bricked systems? ===
 
=== How does Nintendo reflash bricked systems? ===
Line 34: Line 35:  
=== What was the problem in "initial program loader" that was mentioned in an FCC filing by Nintendo for 2DS? ===
 
=== What was the problem in "initial program loader" that was mentioned in an FCC filing by Nintendo for 2DS? ===
 
'''Background:''' http://www.neogaf.com/forum/showthread.php?t=814624&page=1
 
'''Background:''' http://www.neogaf.com/forum/showthread.php?t=814624&page=1
 +
 +
This could be referring to the ROM on the AR6K wireless chip:
 +
* Some 2DS units have the WiFi chip soldered directly to the board (such as the 2DS in this FCC filing: https://fccid.link/BKE/FTR001N), and some do not.
 +
* The AR6K ROM only acts as an initial loader.
 +
* Maybe some AR6K-family devices allow signature checks on the firmware? Or maybe some registers weren't write-once but should have been?
 +
 
=== 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
+
: PlayTime Management
    
=== Why is the DTCM not used anywhere except bootrom? ===
 
=== Why is the DTCM not used anywhere except bootrom? ===
Line 45: Line 52:  
'''Theory:''' NtrBoot another time  
 
'''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.