Views: 614,232 Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 11-24-17 09:15 PM

Main - Posts by nocash

Pages: 1 2 3
Posted on 10-09-15 09:13 AM, in DSi reverse-engineering? (rev. 2 of 10-09-15 09:19 AM) Link | #461
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.

Posted on 10-09-15 05:29 PM, in Wifi for DSi and 3DS Link | #469
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).

Posted on 10-11-15 10:55 AM, in Wifi for DSi and 3DS (rev. 4 of 10-11-15 11:10 AM) Link | #480
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
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
Above is a dump of the first 4Mbytes, done by reading 8-byte units from addresses incrementing at 1000h-byte step.
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
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
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.

Posted on 10-11-15 11:26 AM, in 4dsdev cosmetics thread (rev. 2 of 10-11-15 11:31 AM) Link | #481
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:

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

Posted on 10-11-15 01:14 PM, in I/O ports for SD/MMC/SDIO on DSi (and 3DS) (rev. 2 of 10-11-15 01:15 PM) Link | #483
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.

Posted on 10-11-15 03:53 PM, in I2C Device 4Ah (LED/Volume/Powerbutton/Reset controller) Link | #486
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).

Posted on 10-11-15 04:20 PM, in 4dsdev cosmetics thread (rev. 3 of 10-11-15 04:25 PM) Link | #487
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.

Posted on 10-12-15 05:59 AM, in 4dsdev cosmetics thread Link | #492
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.

Posted on 10-12-15 02:15 PM, in I/O ports for SD/MMC/SDIO on DSi (and 3DS) Link | #498
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
Bit9 DSi7: SDIO card 1 async ;?
Bit10 DSi7: SD card 2 ;Atheros Wifi
Bit11 DSi7: SDIO card 2 async ;?
Bit8 is for SD/MMC controller. Bit10 is for SDIO controller. But Bit9 and Bit11 are what?

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?

Posted on 10-12-15 03:18 PM, in DSP reverse engineering Link | #499
Posted by StapleButter
I wanted to start by the basics and determine how the DSP memory is mapped, and what is what on the DSP side.

DSP RAM goes from 1FF00000 to 1FF7FFFF. So far we have:

1FF00000 - 1FF3FFFF? -> program RAM (DSP exception vectors at 1FF00000+)
1FF40000 - 1FF5FFFF -> data RAM region 1 (1FF50000-1FF5FFFF exposed read-only to ARM11 userland)
1FF60000 - 1FF7FFFF -> data RAM region 2 (1FF70000-1FF7FFFF exposed read-only to ARM11 userland)

Does the program RAM end at 1FF3FFFF or 1FF1FFFF? (if then, what's in the leftover space?)

The DSP can only address 65536 words without switching banks or something in the like. That is, 128K. Assuming the two data RAM regions map to X-RAM and Y-RAM, and the program RAM goes from 1FF00000 to 1FF1FFFF, what would be in the leftover space? DSP-side I/O?

Well uh, clearly this DSP is able to address more than 128K of memory. There has to be a way to select which chunk of memory is being accessed, like on the SNES where they have DBR and PBR to specify which banks the CPU will access.

The docs mention movp and movd instructions, moving from/to data/program RAM. But nothing precises if the regular mov instructions access program RAM or data RAM.

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?

Posted on 10-13-15 02:26 PM, in DSi banner.sav? Link | #507
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?

Posted on 10-25-15 07:04 AM, in RSA Questions Link | #550
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?

Posted on 10-25-15 07:09 AM, in DSi banner.sav? Link | #551
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.

Posted on 10-25-15 07:16 AM, in DSi font Link | #552
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.

Posted on 10-25-15 07:24 AM, in Camera chip IDs for DSi and 3DS Link | #553
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?

Posted on 10-25-15 07:44 AM, in JPEG Signatures Link | #554
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)
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.
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.

Posted on 10-25-15 08:04 AM, in DSi Keys on 3DS (rev. 2 of 10-25-15 08:07 AM) Link | #555
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).

Posted on 10-25-15 08:28 AM, in Wifi for DSi and 3DS Link | #557
Posted by nocash
If needed, I can post some messy source code for doing the above stuff.

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):
push lr
ldr r9,=4004a00h
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] ;/
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] ;/
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] ;/
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
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 ;/
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))
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 ;/
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
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
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?)
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
@@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
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

pop r8
pop r2,pc
pop r0 ;flush
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.

Posted on 10-25-15 09:09 AM, in SCFG_MC - Memory Card Interface Status Link | #558
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).

Posted on 10-25-15 09:41 AM, in I2C Device 4Ah (LED/Volume/Powerbutton/Reset controller) (rev. 2 of 10-25-15 09:42 AM) Link | #559
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,
at least, it should be so in DSi mode; maybe the 3DS uses other register indices when running in 3DS mode...?
Pages: 1 2 3

Main - Posts by nocash

Page rendered in 0.053 seconds. (2048KB of memory used)
MySQL - queries: 21, rows: 96/96, time: 0.022 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.