|
| ||
| Views: 1,610,743 | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search | 11-27-24 02:13 AM |
| Guest: | ||
| Main - Posts by nocash |
| nocash |
| ||
|
Normal user Level: 20 Posts: 1/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
I've just discovered this forum, and it looks exciting - especially as it's having a reverse-engineering section! My current impression was that the 3DS rev-engineering scene didn't exist yet (or that it was hiding in chatrooms). Now that a 3DS-dev forum exists, I really wonder what will happen in future!
As by now, I am only having a DSi console (no 3DS yet), and I am mostly interested in low level hardware stuff (not higher level 3DS operating system stuff, although, if the low level hardware isn't accessible, then one would probably need to deal with the OS). Concerning DSi hardware: Is it allowed to post DSi stuff on 4dsdev? Asking because there isn't any DSi-dev forum yet, and understanding the DSi hardware would certainly help understanding the 3DS hardware. So I am hoping that DSi reverse-engineering might be welcome, too? If yes, maybe adding some sentence "forum dedicated for 3DS and DSi" on the mainpage would do it (such a sentence might be nice anyways, since the current headline doesn't even mention the 3DS yet). For a sepatate DSi section, that might be nice, too. On the other hand, many of the 3DS and DSi stuff is overlapping, for example, I wouldn't know where to ask questions about 3DS-vs-DSi compatibility... is that a 3DS topic or a DSi topic? PS. there a few people interested in a DSi forum, see http://gbatemp.net/threads/nintendo-dsi-section.393580/ - the gbatemp admins don't seem to like the idea though, and a "dev" forum would be better than a "consumer" forum like gbatemp anyways. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 2/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Just wondering how far homebrew Wifi is possible on different consoles yet.
First of, there are a two different Wifi controller/modes: 1) the old NDS mode (with max 2Mbit/s, the controller is apparently contained in the main CPU chip since it's accessed via direct I/O) 2) the new SDIO mode (with faster transfers, the controller is located in the DWM-W0xx Wifi daughterboard, and accessed via SDIO bus) And, different daughterboards: DWM-W015 with AR6002G-AC1B chip in old DSi's DWM-W024 with AR6013G-AL1C chip in later DSi's DWM-W028 reportedly with AR6014 chip in 3DS (and maybe further variants in later 3DS revisiosns) The old NDS mode can be used on DSi's with DWM-W015 boards (eg. for uploading code via "dslink"). But I don't know if it's also working with other daughterboards. Can somebody confirm that, ie. is dslink working on later DSi with DWM-W024 boards, and on 3DS (in DSi mode)? And btw. is there a similar wifi-upload utility for 3DS in 3DS mode? And the new SDIO mode, did anybody figure out how to use that yet? On the DSi, the ARM7 firmware is uploading WLANFIRM firmware to the AR600xx chip via SDIO, and the games are then supposed to communicate with that uploaded WLAN firmware (plus further undumped code in a ROM inside of the AR600xx chip) - but the communication protocol seems to be still unknown (at least on DSi, maybe there's more known on 3DS). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 3/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
I've dumped the ROM from the AR6002G-AC1B chip. It's 80Kbytes (as specified in the datasheet), located at 8E0000h (as indicated by the vectors in RAM).
The CRC32 for the ROM image is 04573BB0h. There are also some ASCII strings in the ROM image: "Athos/Xt BSP", "Nov 23 2007", "00:20:38". ROMs for other AR60xx chips aren't dumped yet, as far as I know. If you want to dump those chips, it can be done via these two SDIO Function Registers (sent via SDIO CMD53) (CMD52 doesn't seem to work for them): - WINDOW_DATA (32bit, SDIO Function 1:00474h) - WINDOW_READ_ADDR (32bit, SDIO Function 1:0047Ch) First, write the upper-3-bytes of the address to (WINDOW_READ_ADDR+1..3), then write the lower-byte to (WINDOW_READ_ADDR+0), then read the addressed 4-bytes from (WINDOW_DATA+0..3). If needed, I can post some messy source code for doing the above stuff. Some background info on the "internal" atheros I/O ports and its "external" SDIO registers is found in these older posts: http://ngemu.com/threads/dsi-wifi-hardware-discovered.173033/ (the attachments contain quite detailed register specs, extracted from 'official' AR6002 source code). I have also tried to dump the whole internal atheros memory space. Reading certain addresses crashes the SDIO interface (making it impossine to do any further SDIO reads without rebooting), but after skipping those "dangerous" addresses, I got this overall memory map puzzled together: 000000 Deadc0de
Above is a dump of the first 4Mbytes, done by reading 8-byte units from addresses incrementing at 1000h-byte step.
004000 sth (01 00 00 00, 00 00 00 00) ;"RTC" fragment? 005000 Deadc0de 008000 sth (00 00 00 00, 00 00 00 00) ;"VMC?" 009000 Deadc0de 014000 sth (00 00 00 00, 00 00 00 00) (--crash-- at 0140cx) ;"GPIO?" 015000 Deadc0de 018000 sth (00 01 0E 00, 00 01 0E 00) ;\MBOX 019000 sth (00 01 0E 00, 00 01 0E 00) ;/ 01A000 sth (00 01 0E 00, 00 01 0E 00) ;\MBOX:HOST_IF? 01B000 sth (--crash-- at 01B00x) ;/ 01C000 sth (00 00 14 00, D8 48 45 0E) ;-ANALOG? 01D000 Deadc0de 020000 sth (00's) ;\DMA? 021000 sth (01 00 00 00, 02 00 00 00) ;/ 022000 sth (00's) ;\ ;\same as 023000 sth (01 00 00 00, 02 00 00 00) ; ;/DMA? 024000 sth (00's) ; ?? 025000 sth (00's) ; 026000 sth (00's) ; 027000 sth (00's) ;/ 028000 sth (00 23 CC 70, 82 43 86 38) ;\MAC_PCU? 029000 sth (14 E1 38 8A, 80 73 00 00) ;/ ;\ 02A000 sth (00's) ; BB at 29800h? 02B000 sth (00's) ;/ 02C000 sth (00's) ;-UART maybe? 02D000 sth (00's) ;-UART debug? 02E000 sth (00's) ;-UMBOX? 02F000 sth (00's) ;-?? (not SI?) 030000 Deadc0de ;RDMA?? and (not?) EFUSE?? 040000 Deadbeef 050000 Deadbeef 060000 Deadbeef 070000 Deadbeef 080000 004F1B74 090000 004F1B74 0A0000 004F1B74 0B0000 004F1B74 0C0000 004F1B74 0D0000 004F1B74 0E0000 sth (06 10 00 00, 21 22 22 22) ;\80K ROM (14000h bytes) 0F0000 sth (00 00 05 60, FF DF FF FF) ;/ 0F4000 004F1B74 100000 sth (48 0F 8E 00, 70 14 50 00) ;\ 110000 sth ; 184K RAM (2E000h bytes) 120000 sth ;/ 12E000 98A8A2AA ... 1FF000 98A8A2AA 200000 Deadbeef 300000 Deadbeef ... 3FF000 Deadbeef The comments are showing which memory and I/O regions are assumed to be mapped at the separate addresses. Some I/O regions that are claimed to be located at 00xxxxh seem to be actually located at 02xxxxh (namely, the ports at 9800h..E000h seem to be at 29800h..2E000h). After the first 4Mbyte, the following memory seems to be just containing mirrors of the first 4Mbyte. I've tested some addresses... 00400000 looks like mirror of 000000
The ROM and RAM seem to be actually accessed via mirrors (RAM at 500000h and ROM at 8E0000h). Don't know why... maybe write-access & execute-access is permitted only in certain mirrors.
0041B000 looks like mirror of 01B000 --crash-- ... probably more mirrors... FFC00000 looks like mirror of 000000 FFC1B000 looks like mirror of 01B000 --crash-- ... probably more mirrors till FFFFFFFF |
| nocash |
| ||
|
Normal user Level: 20 Posts: 4/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
The code .. /code tags (in square brackets) are truncating any leading spaces in the first line of text. For example, below should have all three lines indented with two leading spaces:
Blah
Blahblah Blahblahblah The "MM-DD-YY" date format doesn't look too intuitive. Something like "DD Month YYYY" would be clearer. At the moment one could only guess which of the two-digit values is day or month or year. Colors/fonts are hard to read in some cases. Especially headlines with gray/white/magenta text.. drawn on light-blue background? That's making the user names (and link/edit/quote buttons) almost inlegible. At normal viewing distance (about 40 centimeters) it's looking as if all board members are called "oooo", "dolo", and "ooooob". If I climb on the table, then I can decipher the text (from about 20 centimeters distance). Using a darker background color than light-blue should fix it; best combined with brighter text colors than gray or magenta. I am using some old Opera version (which normally works well with other forums). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 5/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 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. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 6/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
On the DSi, the BPTWL chip (I2C device 4Ah) is used for LED/Volume/Powerbutton/Reset control. On the 3DS the chip is called somewhat different, but it should have the device number and same functions (plus some extra functions).
Somebody told me that 3DS people have found a firmware for that chip, is that true? If yes, how does that firmware look like? What's it's filename, is it a separate file, or a datablock inside of a bigger file? Is there some file header, how does the instruction set look like, and is the instruction set already identified? And how is the firmware uploaded to the chip, is it stored permanently in FLASH, or only loaded temporarily to RAM? And is there anything similar on DSi? Etc... If it's patch-able and stored permanently in FLASH, then it might be useful for forcing the "warmboot" flag to be always set (which would theoretically allow to bypass the annoying health safety message). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 7/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Thanks for fixing the code/code issue, I thought that one would have been most difficult.
Edit profile? Ah, yes, that works (I've formerly only viewed my user profile, which showed the same settings, but didn't allow to change them). Okay, changed time/date to my preferred format. The theme already looked identical as in your screenshot, except that my browser did have a slightly smaller font... I've changed the font size from "82" to "100", and the user names are now looking about exactly as your screenshot. But the user names are still hard to read. Especially if the names have darker colors (like nocash or dela or plutoo) (the ones with brighter colors like StapleButter are easier to read). Part of the problem is that magenta isn't having good contrast against the blue background, and the black outlines drawn around the dark magenta text are making things even worse (eg. an "o" is looking like a blurred solid-filled circle, without any hole in the middle of the "o"; and most other lowercase letters like "a", "e", "s" are looking the same). It does of course depend on your eyes, monitor resolution, and font size - but the overall effect should apply under all circumstances: the user names are much harder to read than normal text (which is still legible at greater distances). Only thing that is even harder to read is the "Acmlmboard" style, with lightblue user names on white background :- ) but I prefer dark themes anyways. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 8/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Yes, change colors! Making all user names white with black outlines should do it (and same for Link/Quote/Edit/Delete buttons). Making the lightblue background a bit darker would be also nice.
Or if there's some meaning behind different user name colors, use very bright pastelized colors (something near white, with only some slight color tones). For the font size, "90" seems to look best for me. But that might depend on my browser & browser settings. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 9/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 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? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 10/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Posted by StapleButter Don't know if that questions do still apply, but anyways: The DSi uses "MBK" registers http://problemkaputt.de/gbatek.htm#dsinewsharedwramforarm7arm9dsp for mapping WRAM either to DSP or ARM memory at 3000000h-3FFFFFFh. I would assume that the 3DS has some similar "MBK" mapping mechanism (but mapping to 1FF00000h-1FF7FFFFh instead of 3000000h-3FFFFFFh). Or is there no such mapping stuff on 3DS, and the ARM can access the memory even when the DSP is running? Yes, Teaklite 1 did support on 16bit addresses. And the (undocumented) Teaklite 2 seems to have been expanded to at least 18bit addresses. The 16bit br/call/bkrep opcodes are using two formerly unused bits to gain 18bit range (except bkrep with imm8, which is still restricted to 16bit). Don't know if/how call+ret are managing 18bit return addresses though. Mov opcodes must be in fact use some extra "bank" register. Maybe set via the new "load imm2,movpd" opcode, the "PD" might stand for "DataPage" or so. There are some new "movp" ocodes, allowing to use "(Ax)" (instead of 16bit "(Axl)") for program memory addressing, so there would be no "ProgramPage" required in that case. Normal "mov" opcodes should be always accessing data ram (else executing the opcode fetch and data access in one clock cycle wouldn't work out). The movd/movp opcodes are: movp = move FROM PROGRAM RAM (to data ram, or to register) movd = move TO PROGRAM RAM (from data ram) They could be used for manipulating program code (probably rarely done), or loading constants from program memory (might be done more often, but loading constants from data ram would be ways faster). --- For the DSi, I have found some teak code in a file called "aac.a" (inside of the NITRO filesystem of the DSi Sound utility). It seems to using COFF format, containing binary and symbolic labels, which would very useful for debugging. Are there any read-for-use utilities for extracting symbols from COFF files? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 11/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
One of the obscurities in the DSi world is that we know that the DSi supports a "banner.sav". But we don't know what that banner.sav is good for, what kind of fileformat it might have, or if that feature was ever used by any existing DSi games.
The only reference is at http://dsibrew.org/wiki/DSi_Cartridge_Header - does anybody know more about it? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 12/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Some RSA questions...
1) Does somebody have some source code example for decrypting the RSA signatures in DSi cart headers? I guess any open source RSA implementations could do that, when calling the correct functions with correct parameters. 2) The DSi BIOS has two different subfunctions for RSA decryption functions (either one of them used, depending on bit0 of the first byte of the RSA key). Is that something common in RSA world? And what is it good for? Are that two different RSA variants, or is just some kind of optimization for faster processing of "even/odd" keys? 3) The DSi's encrypted RSA data is always 80h bytes in size. But the size of the decrypted output is variable (from what I've seen, it's always (?) 7Fh bytes; whereas those 7Fh bytes are usually mainly consisting of padding bytes). What is that variable length good for? Are there cases where it could be bigger or smaller than 7Fh? And is it something that can be freely assigned at encryption time, or is it just some "dirt effect" where the compressor is "randomly" assigning different lengths depending on the input? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 13/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Thanks, good to know! Did anybody already dump that banner file from eMMC? Or know which exact Brain Age express title(s) are using it (or if any other games use it, too)?
Anyways, great to know that the feature was ever used, and where to start searching. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 14/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Does anybody know how to decompress the DSi's "\sys\TWLFontTable.dat" file?
The file header and the actual font format are more or less known, see http://problemkaputt.de/gbatek.htm#dsisdmmcfirmwarefontfile The only problem is that the font seems to be somehow compressed - it looks like some LZ compression variant, but I couldn't even figure out where the uncompressed header ends, and where the compressed font starts. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 15/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Did anybody ever dump the chip IDs for the DSi/3DS cameras?
The IDs could be read fairly easily via I2C bus, see http://problemkaputt.de/gbatek.htm#dsii2cbus My DSi uses Aptina MT9V113 Cameras (with ID=2580h, accessed as I2C device 78h/7Ah), but later models like 3DS might use some different camera revision(?) And, apart from device 78h/7Ah, the DSi firmware is also supporting device A0h/E0h - which seem to be alternate cameras from whatever unknown manufacturer. Did anybody ever see a DSi or 3DS with device A0h/E0h installed? |
| nocash |
| ||
|
Normal user Level: 20 Posts: 16/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
The DSi Camera utility stores some Exif header with AES signature in JPEG files, and refuses to load any JPEGs without such signatures from SD card. The 3DS is probably having same/similar JPEG signatures.
The overall format for DSi JPEGs is described here, http://problemkaputt.de/gbatek.htm#dsisdmmccamerafilesjpegs A real DSi jpeg can be found here, http://dsibrew.org/w/images/d/d4/DSiCameraSampleImage.jpg Seeing a 3DS jpeg would be nice too. Can somebody upload such a file somewhere, or did anybody already do so? Does the 3DS contain the "DSi Camera" utility, too? If so, seeing a JPEG taken on "a 3DS in DSi mode" would be interesting, too. I haven't yet tried to modify DSi JPEGs (or to import non-DSi images), but from what I can see, the signature stuff seems to be working as so: DSi Signature (IV+MAC)
If you want to experiment with it, mind that the DSi uses little-endian AES (unlike most open source AES implementations), and observe that the official AES specs seem to require a 'header' (containing the extra data length with some weird encoding) in the first "extra associated data" block, but the DSi hardware does simply omit that weird header.
The 1Ch-byte Signature is split into a 0Ch-byte IV value (this might be just a random number?), and a 10h-byte MAC value. The MAC is computed via AES-CCM: IV[00h..0Bh] = First 0Ch-bytes of signature KEY[00h..0Fh] = Constant (70,88,52,06,...) ;from BIOS ROM Zerofill the 1Ch-byte signature area in the JPEG file Probably zeropad(?) the JPEG file (if filesize isn't a multiple of 16 bytes) Pass the whole JPEG as "extra associated data" to the AES-CCM hardware Copy the IV value and computed MAC value back to the JPEG's signature area Unknown if the IV value is just random, and unknown if there are further requirements (such like using same Maker/Model strings or same resolution as in original DSi files). Locating "ldr rx,=927Ch" opcodes at various locations in Nintendo DSi Camera is easy; but the stuff is handled via numerous sub-functions, including IPC stuff with both ARM7 and ARM9 envolved; which isn't too easy to disassemble. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 17/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
The DSi has a bunch of RSA, AES, Blowfish keys in ROM. The only two ways for dumping that keys would be decapping the Main CPU, or using a main memory hack for dumping RAM copies of that keys during booting - which is both nothing that could be done easily at home.
However, http://3dbrew.org/wiki/Memory_layout#ARM9_ITCM says that the DSi keys can be also found on 3DS at ARM9 ITCM address 01FFD000h or 07FFD000h. Is it difficult to dump that memory area? And does anybody know more about which DSi key is stored at which 3DS address? Knowing that stuff would help on building working DSi BIOS ROM images - needed for emulating the DSi boot process. As by know, the DSi ROMs can be dumped only partially: http://problemkaputt.de/gbatek.htm#biosdumping The DSi seems to have some extra keys that are missing in 3DS - but the DSi doesn't seem to use those extra keys keys either (maybe they are used only for DSi-debug version or so). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 18/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Posted by nocash Okay, I will just post the source code, so you have no excuse that you didn't got told how to do it. First of, init sdio like so (parts of it probably not realy required, and parts are relying on pre-initializations by firmware): sdio_init:
push lr ldr r9,=4004a00h ;---part1 ldrh r0,[r9,0e0h] ;\ bic r0,3 ; SDIO_SOFT_RESET clear bit0-1 strh r0,[r9,0e0h] ;/ ldrh r0,[r9,0e0h] ;\ orr r0,3 ; SDIO_SOFT_RESET set bit0-1 strh r0,[r9,0e0h] ;/ ldrh r0,[r9,008h] ;\ bic r0,1 ; SDIO_STOP_INTERNAL clear bit0 strh r0,[r9,008h] ;/ ldr r0,=80d0h ;\SDIO_CARD_OPTION = 80D0h strh r0,[r9,028h] ;/ ;---part2a mov r0,0040h ;\SDIO_CARD_CLK_CTL = 0040h strh r0,[r9,024h] ;/ ldrh r0,[r9,028h] ;\ orr r0,8000h ; SDIO_CARD_OPTION set bit15 bic r0,8000h ;clear --> want 4bit DATA mode !!! strh r0,[r9,028h] ;/ ;---part2b ldrh r0,[r9,028h] ;\ orr r0,0100h ; SDIO_CARD_OPTION set bit8 strh r0,[r9,028h] ;/ ldrh r0,[r9,028h] ;\ bic r0,0100h ; SDIO_CARD_OPTION clear bit8 strh r0,[r9,028h] ;/ ;---part3a mov r0,0100h ;\SDIO_CARD_CLK_CTL set bit8 strh r0,[r9,024h] ;/ pop pc This is dumping wifi memory 8C0000h..94FFFFh (the ROM is probably at 8E0000h and up, and RAM at 900000h or 920000h, depending on what AR60xx chip you have), the dumped area is a bit bigger to see which regions are actually occupied by ROM/RAM. push r1-r12,lr
mov r10,8c0000h ;src index mov r12,90000h ;len @@dir_sector_lop: mov r2,200h ;\ ldr r3,=sdmmc_sector_buf ;dst ; read SDIO data @@rd_sdio_lop: ; (based on "sdio_dump_internal_registers") push r0-r12 tst r10,0ffh ;\output addr.MSBs only bne @@skip_addr_msbs ;/at start of 256-byte areas mov r0,r10,lsr 8 ;\ ldr r1,=1000047dh ; addr.bit8-15 bl sdio_cmd53_write_r0_to_register_r1 ;/ mov r0,r10,lsr 16 ;\ ldr r1,=1000047eh ; addr.bit16-23 bl sdio_cmd53_write_r0_to_register_r1 ;/ mov r0,r10,lsr 24 ;\ ldr r1,=1000047fh ; addr.bit24-31 bl sdio_cmd53_write_r0_to_register_r1 ;/ @@skip_addr_msbs: mov r0,r10,lsr 0 ;\ ;and r0,0fch ;hardware is ignoring LSBs anyways; addr.bit0-7 (this last?) ldr r1,=1000047ch ; bl sdio_cmd53_write_r0_to_register_r1 ;/ pop r0-r12 ldr r1,=10000474h ;\read 4byte data bl sdio_cmd53_read_32bit_register_r1 ;/ str r0,[r3],4 ;\ add r10,4 ; store and lop next 4byte subs r2,4 ; bne @@rd_sdio_lop ;/ ... write 200h bytes from "sdmmc_sector_buf" to file ... subs r12,200h ;len bne @@dir_sector_lop ;/ pop r1-r12,pc The read 32bit subfunction: ;------------------
sdio_cmd53_read_32bit_register_r1: ;in: r1=addr(bit0-16)+func(bit28-30) push r1-r12,lr ;;;@@param equ (04000100h + (@@func shl 28)) ;---part3b mov r0,r1,lsl 9 ;data(NONE), addr(bit9-25) and r2,r1,(7 shl 28);func(bit28-30) orr r0,r0,r2 ;func(bit28-30) orr r0,1 shl 26 ;increasing address bic r0,0ffh ;strip data orr r0,04h ;replace by len (4 bytes) ldr r9,=4004a00h str r0,[r9,004h] ;SDIO_CMD_PARAM ldr r0,[r9,01ch] ;\SDIO_IRQ_STAT bic r0,83000000h ; clear bit31,25,24 (error, txrq, rxrdy) bic r0,007f0000h ; clear bit22..16 (error) bic r0,00000005h ; clear bit2,0 (dataend,cmdrespend) str r0,[r9,01ch] ;/ ldrh r0,[r9,008h] ;\ bic r0,1 ; SDIO_STOP_INTERNAL clear bit0 strh r0,[r9,008h] ;/ mov r0,4 ;\SDIO_BLKLEN16 strh r0,[r9,026h] ;/ mov r0,1 ;\SDIO_NUMBLK16 strh r0,[r9,00ah] ;/ ldr r0,=5c35h ;cmd.rd ;\SDIO_CMD strh r0,[r9,000h] ;/ ;- - - mov r2,10000h ;\ @@wait_rxrdy: ; subs r2,1 ; beq @@error_sw_timeout ; wait for data ldrh r0,[r9,01eh] ;SDIO_IRQ_STAT_HI ; tst r0,100h ;rxrdy ; beq @@wait_rxrdy ;/ ldrh r0,[r9,030h] ;SDIO_DATA16 ;\ ldrh r1,[r9,030h] ;SDIO_DATA16 ; fetch data (2x16bit) orr r0,r0,r1,lsl 16 ;/ @@wait_dataend: ;\ subs r2,1 ; beq @@error_sw_timeout ; wait for end ldrh r1,[r9,01ch] ;SDIO_IRQ_STAT_LO ; tst r1,4 ;dataend ; (works BETTER with this!) beq @@wait_dataend ;/ @@error_sw_timeout: pop r1-r12,pc And, very messy, the 8bit write function: ;------------------
sdio_cmd53_write_r0_to_register_r1: ;in: r0=data(8bit), r1=addr(bit0-16)+func(bit28-30) push r2,lr ;---part3b and r0,0ffh ;data orr r0,r0,r1,lsl 9 ;data(bit0-7), addr(bit9-25) and r2,r1,(7 shl 28);func(bit28-30) orr r0,r0,r2 ;func(bit28-30) orr r0,1 shl 31 ;writeflag(bit31) b sdio_cmd53_access_register_core_inj ;------------------ sdio_cmd53_access_register_core_inj: ;in: r0=param, out: r0=data (if reading) push r8 and r8,r0,0ffh ;-memorize data (for write) bic r0,0ffh ;strip data orr r0,01h ;replace by len (1 byte) ldr r9,=4004a00h strh r0,[r9,004h] ;\ mov r0,r0,lsr 16 ; SDIO_CMD_PARAM strh r0,[r9,06h] ;/ ldr r0,[r9,01ch] ;\SDIO_IRQ_STAT bic r0,83000000h ; clear bit31,25,24 (error, txrq, rxrdy) bic r0,007f0000h ; clear bit22..16 (error) bic r0,00000005h ; clear bit2,0 (dataend,cmdrespend) str r0,[r9,01ch] ;/ ldrh r0,[r9,008h] ;\ bic r0,1 ; SDIO_STOP_INTERNAL clear bit0 strh r0,[r9,008h] ;/ mov r0,1 ;\SDIO_BLKLEN16 strh r0,[r9,026h] ;/ mov r0,1 ;\SDIO_NUMBLK16 strh r0,[r9,00ah] ;/ ldrh r0,[r9,06h] ;\SDIO_CMD_PARAM (MSB=write) tst r0,8000h ;/ ldrne r0,=4c35h ;cmd.wr;\ ldreq r0,=5c35h ;cmd.rd; SDIO_CMD strh r0,[r9,000h] ;/ ;- - - mov r2,100000h ;timeout (ca. 1 Million) ;<-- ENDLESS SLOW (at least several MINUTES... or HOURS) (ie. in fact NEVER) mov r2,1000h ;<-- REASONABLE SLOW (hmmm, even for 256-bytes, this is WAYS FASTER than above delay, which is 256-times slower, how is THAT possible??) mov r2,10000h @@busy_lop: ldrh r0,[r9,02ch] ;\SDIO_ERROR_DETAIL_LO tst r0,005h ; bit0, CMD CmdIndex-Error tsteq r0,100h ; bit2, CMD End-Bit-Error bne @@error_detail ;/ bit8, CMD CRC-Error ldrh r0,[r9,01ch] ;\SDIO_IRQ_STAT_LO tst r0,1 ; bit0, CMDRESPEND bne @@busy_done ;/ subs r2,1 ;\lop next, till timeout bne @@busy_lop ;/ b @@error_sw_timeout ;XXX accessing DISABLED function 1 does HANG (rather than reaching timeout?) ;--- @@busy_done: ldrh r0,[r9,01eh] ;\SDIO_IRQ_STAT_HI tst r0,40h ; bit22, CMDTIMEOUT bne @@error_hw_timeout;/ ldr r0,[r9,00ch] ;\SDIO_REPLY (00001000h, ie. state = "dis"; if it's "CSR") and r0,00ffh ;/ ldrh r0,[r9,06h] ;\SDIO_CMD_PARAM (MSB=write) tst r0,8000h ; bne @@write ;/ @@wait_rxrdy: ;\ subs r2,1 ; beq @@error_sw_timeout ; ldrh r0,[r9,01eh] ; SDIO_IRQ_STAT_HI tst r0,100h ;rxrdy ; beq @@wait_rxrdy ;/ ldrh r0,[r9,030h] ;\SDIO_DATA16 and r0,00ffh ;/ b @@finish @@write: @@wait_txrq: ;\ subs r2,1 ; beq @@error_sw_timeout ; ldrh r0,[r9,01eh] ; SDIO_IRQ_STAT_HI tst r0,200h ;txrq ; beq @@wait_txrq ;/ strh r8,[r9,030h] ;-SDIO_DATA16 mov r0,0 ;return 0=dummy b @@finish @@finish: push r0 @@wait_dataend: ;\ subs r2,1 ; beq @@error_sw_timeout_pop; ldrh r0,[r9,01ch] ; SDIO_IRQ_STAT_LO tst r0,4 ;dataend ; (works BETTER with this!) beq @@wait_dataend ;/ pop r0 @@done: pop r8 pop r2,pc ;--- @@error_sw_timeout_pop: pop r0 ;flush @@error_detail: @@error_sw_timeout: @@error_hw_timeout: mov r0,-1 b @@done The code should be working on DSi (or on 3DS in DSi mode). For 3DS (in 3DS mode), the 4004a00h I/O base address would need to be changed accordingly. |
| nocash |
| ||
|
Normal user Level: 20 Posts: 19/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
The DSi is having a "SCFG_MC - Memory Card Interface Status" register, see http://problemkaputt.de/gbatek.htm#dsicontrolregistersscfg for details (aside from the cartidge insert/eject flag, there isn't much known about it yet though).
My current theory is that the register contains 4bits for the NDS cart slot, and another 4bits for the second NDS cart slot (DSi prototypes seem to have had two slots). So essentially, there are only 4bits used and it should be very simple to understand what the register is doing - the problem is that it's read-only on ARM9 side. It should be read/write-able on ARM7 side, but it's unfortunately disabled after booting, and thus not write-able with existing DSi exploits... Does the 3DS have anything similar? And is it write-able on 3DS exploits, and know what the separate bits are doing? The register is fairly important for booting/emulating the DSi firmware (at the moment, no$gba can boot the firmware only when having the register set to "no cartridge inserted" - thus making it impossible to debug the cartridge boot process). |
| nocash |
| ||
|
Normal user Level: 20 Posts: 20/77 EXP: 39028 Next: 3411 Since: 10-09-15 Last post: 2103 days ago Last view: 2018 days ago |
Yes, the two round dots on the package seem to be somewhat common for Renesas chips.
There're also two snippets from a decapped "BP_TWL-2" chip shown at https://chipworks.secure.force.com/catalog/ProductDetails?sku=NIN-BP_TWL-2 with text "NEC Electronics Corp. 2009, 33A" and "67". Whereas, NEC appears to have been sold to Renesas, so both manufacturer names are probably correct. Maybe the instruction set is described in some older NEC datasheets. The upload sequence looks odd. Especially reading register 15 and 16 - are that decimal numbers? Register 16 (=10 hex) would be the power button status, http://problemkaputt.de/gbatek.htm#dsii2cdevice4ahbptwlchip at least, it should be so in DSi mode; maybe the 3DS uses other register indices when running in 3DS mode...? |
| Main - Posts by nocash |
|
Page rendered in 0.074 seconds. (2048KB of memory used) MySQL - queries: 21, rows: 96/96, time: 0.005 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |
