|
| ||
| Views: 1,611,767 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 12-03-24 05:07 PM |
| Guest: | ||
| 0 users reading I/O ports for SD/MMC/SDIO on DSi (and 3DS) | 1 bot |
| Main - Reverse-engineering - I/O ports for SD/MMC/SDIO on DSi (and 3DS) | Hide post layouts | New reply |
| nocash |
| ||
|
Normal user Level: 20 Posts: 5/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
I've reverse engineered the DSi's SD/MMC/SDIO I/O ports a while ago, see http://gbatemp.net/threads/dsi-reverse-engineering-sd-mmc-sdio-registers.395787/ for details.
Most of the results are summarized here: http://dsibrew.org/wiki/SD/MMC/SDIO_Registers (and will be also included in next gbatek version). Most of the regular bits (those used by existing DSi software) should be known now - except for some bits in 40048F6h/4004AF6h, and (somewhat SDIO related) bits in 4004836h/4004A36h, 4004838h/4004A38h. Going by 3DS source code, the 3DS should be using exactly the same registers (but located at a different base address, ie. not at 4004800h-4004BFFh). Would be great if somebody could verify those findings. Especially one thing: Verifiying if the fixed bits are really fixed, and if they are always having the same values (even on 3DS). I've compiled lists of fixed 16bit values & fixed bits (and sample source code for using those lists): For fixed 16bit values, see this post http://gbatemp.net/threads/dsi-reverse-engineering-sd-mmc-sdio-registers.395787/#post-5640698 For fixed bits (in registers with fixed/variable bits mixed together), see this post: http://gbatemp.net/threads/dsi-reverse-engineering-sd-mmc-sdio-registers.395787/page-2#post-5648142 If you have some working SD/MMC/SDIO engine, it should be easy to add the above fixed-verification stuff in there - best call the verifications in different places (eg. before, during, and after transfers) and throw some warning when encountering unexpected values. For example, the 3DS might have different chip ID in some register, and/or extra functions in other registers. |
| plutoo |
| ||
|
Member Normal user Level: 11 Posts: 3/19 EXP: 4804 Next: 1181 Since: 09-17-15 Last post: 3284 days ago Last view: 3208 days ago |
I'm not touching my SD/NAND registers for fearing a brick. However, reading from physaddr 0x10122000 the following is read (repeated every 0x100 bytes throughout that page). These are the SDIO registers for WiFi on the 3DS.
000e00: 35 4c 00 01 01 00 1f 9c 00 00 01 00 00 10 00 00 5L..............
000e10: 00 10 00 00 00 10 00 00 00 10 00 00 31 07 a0 20 ............1.. 000e20: 1d 03 7f 8b 01 00 80 00 d0 40 00 00 00 20 00 00 .........@... .. 000e30: a2 f3 00 00 01 00 02 00 06 c0 00 00 00 00 00 00 ................ 000e40: 3f 00 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 ?.*............. 000e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000eb0: 00 00 ff ff 00 00 00 00 00 00 00 02 00 00 00 00 ................ 000ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ed0: 00 00 00 00 00 00 00 00 10 10 00 00 00 00 00 00 ................ 000ee0: 07 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ef0: 00 00 00 00 00 07 00 00 00 00 00 00 ff 00 ff 00 ................ 000f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As you can see, this seems to match up pretty well with your notes. Hopefully it'll be of some use to you. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 9/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Thanks, very nice to see how those ports look like for real on 3DS.
Yes, they are looking as on DSi, even with the same fixed 3Fh, 2Ah values. One thing that I haven't fully figured out yet are the SD/MMC/SDIO irq sources. On DSi, the IE2/IF2 registers are having four interrupt lines: Bit8 DSi7: SD card 1 ;Onboard eMMC
Bit8 is for SD/MMC controller. Bit10 is for SDIO controller. But Bit9 and Bit11 are what?
Bit9 DSi7: SDIO card 1 async ;? Bit10 DSi7: SD card 2 ;Atheros Wifi Bit11 DSi7: SDIO card 2 async ;? I have tried GNDing the "IRQ" pin on the SD slot, but that didn't trigger Bit9 (nor any other bit of Bit8..11). Also tried that with all variable bits in SD/MMC registers set and cleared (except SOFT_RESET of course), but didn't seem to enable the external IRQ pin either. Did anybody ever see the IRQ pins used/working? |
| plutoo |
| ||
|
Member Normal user Level: 11 Posts: 4/19 EXP: 4804 Next: 1181 Since: 09-17-15 Last post: 3284 days ago Last view: 3208 days ago |
I made a pretty cool discovery. There are two WiFi SDIO controllers (!) mapped on the 3DS, at physical addresses 0x10100000 and 0x10122000 respectively.
NWM contains code to use both, even though the process doesn't have read/write access to 0x10100000. This appears to be left-over debug code, and seem to imply the existence of a debug WiFi SDIO bus. Anyway, the normal SDIO area has two interrupts associated with it: 0x40 and 0x41. But NWM only registers a listener for the first one. So the 3DS doesn't even seem to care about the other interrupt; whatever it is it is probably not important. 
The 0x10100000 has it's own equivalent of the 0x40 interrupt called 0x42. Here's a dump of 0x10100000: 000e00: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e10: 00 00 00 00 00 00 00 00 00 00 00 00 18 06 80 20 ............... 000e20: 1d 03 7f 8b 20 00 00 02 ee 40 00 00 00 20 00 00 .... ....@... .. 000e30: 00 00 00 00 00 00 00 00 07 c0 00 00 00 00 00 00 ................ 000e40: 3f 00 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 ?.*............. 000e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000eb0: 00 00 ff ff 00 00 00 00 00 00 00 02 00 00 00 00 ................ 000ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ed0: 00 00 00 00 00 00 00 00 10 10 00 00 00 00 00 00 ................ 000ee0: 06 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ef0: 00 00 00 00 00 07 00 00 00 00 03 00 ff 00 ff 00 ................ 000f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 000ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
| nocash |
| ||
|
Normal user Level: 20 Posts: 25/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
I've found the CardIRQ signal; triggered when dragging /IRQ (aka Data1 pin) to LOW. The thing require an ENABLE bit, and a DISABLE bit, and correct settings in PORT_SELECT and CLK_CTL registers - so that explains why nobody has figured out how to receive those /IRQ yet; just trying to enable it by setting or clearing all bits won't work.
Alongsides, I've found four other (rather weird) IRQ sources: 4004836h/4004A36h - SD_CARD_IRQ_STAT (R/ack)
4004838h/4004A38h - SD_CARD_IRQ_DISABLE (R/W) IRQ Flags/Write (0=Acknowledge, 1=No change) IRQ Flags/Read (0=No IRQ, 1=IRQ) IRQ Mask (0=Enable, 1=Disable) (C007h when all IRQs disabled) Bit Stat Mask Function 15 undoc undoc SomeIRQ (triggered SOMETIMES on forced CMDTIMEOUT?) 14 undoc undoc SomeIRQ (triggered near DATAEND?) 13-3 0 0 Always zero 2 undoc undoc SomeIRQ (triggered on forced TXUNDERRUN?) 1 undoc undoc SomeIRQ (triggered about once per datablock?) 0 CINT0 CIMSK0 CardIRQ (triggered by /IRQ aka Data1 pin; for SDIO devices) All stat bits (except bit1) are triggered only if enabled in SD_CARD_IRQ_ENABLE. Bit0 is actually used (for SDIO hardware), the other bits aren't used by existing software (they don't seem to be useful; purpose might be error testing, or forcing commands to abort). 4004834h/4004A34h - SD_CARD_IRQ_ENABLE (R/W) CardIRQ Enable works only when also writing SD_CARD_PORT_SELECT.bit10=0 and only with valid SD_CARD_CLK_CTL setting. 15-10 Always zero 9 Enable setting SD_CARD_IRQ_STAT.bit14 and cause nothing special? (R/W) 8 Enable setting SD_CARD_IRQ_STAT.bit15 and cause CMDTIMEOUT? (R/W) 7-3 Always zero 2 Enable setting SD_CARD_IRQ_STAT.bit2 and cause TXUNDERRUN? (R/W) 1 Always zero 0 Enable setting SD_CARD_IRQ_STAT.bit0 (CardIRQ upon Data1=LOW) (R/W) Bit9 is autocleared at time when bit9 causes setting SD_CARD_IRQ_STAT.bit14. Bit2 is autocleared shortly before bit8 causes CMDTIMEOUT. SD_CARD_IRQ_STAT.bit15 is set only when setting bit8 AND bit2 DURING cmd/xfer. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 30/77 EXP: 39067 Next: 3372 Since: 10-09-15 Last post: 2110 days ago Last view: 2025 days ago |
Just stumbled over some detail: Port 4004800h.bit6=1 causes the SD/MMC controller to send an APP_CMD prefix... but, it doesn't seem to be possible to specify the RCA value for the APP_CMD's parameter field.
That would be no issue for MMC, since ACMD0..63 aren't used for MMC. But for SD cards, the DSi is using ACMD41, ACMD6, ACMD13 (of which, ACMD41 should be sent with RCA=0, the other two should theoretically send the card's RCA value). Does anybody know how that is working? Or does somebody have SD-bus logging hardware to see what is happening on the SD bus? Btw. I don't really understand why SD is using RCA values at all (MMC allows to share the same CMD line for cards with different RCAs, but SD specs suggest that each card must have an own CMD line, so RCA would be rather irrelevant). |
| Main - Reverse-engineering - I/O ports for SD/MMC/SDIO on DSi (and 3DS) | Hide post layouts | New reply |
|
Page rendered in 0.040 seconds. (2048KB of memory used) MySQL - queries: 28, rows: 75/75, time: 0.009 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |