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