The MPCore stuff is already documented? Do you mean elsewhere than in official docs from ARM?profi200 wrote:The regs are already documented so why copy the official doc from ARM?
Yeah, I have probably really spent lots time and digged through tons of atheros driver code.profi200 wrote:It's not about testing. It's getting increasingly more complicated and no one wants to spend the time + digging through huge docs or existing driver code like in the Linux kernel.
Well, and after all that work, I hoped that SDIO/WPA/WPA2 support in the DSi wifiboot tool would allow hordes of homebrew DSi devr's to test their own code on real hardware - but somehow those hordes of devr's never showed up (the feedback was a bit disappointing: I know of only one person who had downloaded my wifiboot tool - and apparently didn't even got it working).
I am wondering if the feedback on other wifi tools (like FTP for nds/dsi/3ds) is equally rare?
I guess that's more poorly written driver code, not the hardware being too slow. IRQ forwarding would probably cost only 100 cycles per packet.profi200 wrote:Forwarding IRQs would be pretty inefficent. The ARM11 is meant to handle applications, network and more. Fun fact: The WiFi bottleneck is in part due to the slow CPUs. Where i know this from? WiFi speed increased on New 3DS with higher clock :wink: The ARM9 would slow that down a bit more.
The homebrew NDS/DSi wifi code is using ARM7+ARM9, so a 3DS port would run on ARM9+ARM11 accordingly (ARM9 for low-level SDIO, and ARM11 for high-level TCP/UDP etc). Of course, it could be more straight-forward to handle everything on one CPU, but it would be some extra work to modify the existing code.
The homebrew DSi code reached only 400-600 Kbyte/s (the difference between 400 and 600 Kbyte/s depends on the access point). I don't know why it doesn't reach 5-6 Mbyte/s, I think it might be an atheros-hardware issue, or just messy TCP flow in software, not just the DSi CPU being too slow.
One cpu/memory related bottleneck is that the packet body isn't word-aligned (the packet header has an odd amount of halfwords). That's a problem when copyting data from from "packet_buffer" to actual "target_address".
On NDS/DSi, I have solved by using the old NDS DMA registers with 16bit transfer units (which work with halfword aligned SAD/DAD addresses). Does the 3DS support anything similar?
I tried to, but at that time I only knew that the "3DS has AXI" what does that mean? That didn't yield any meaningful search results.coto wrote:Dude. Just google around : ARM AXI BUS (3DS)
Well, that was some weeks ago - before you had mentioned that it's an ARM BUS, which really good to know, thanks!
At the moment, I think it isn't so important to understand the differences between AXI and AHB. Or is there something really important to know? Like 3DS memory accesses being fundamentally incompatible with DSi-style memory accesses? (So far, my code and stacks and variables seem to be more or less working).
But a more general memory/cache question: NDS/DSi is having some issues with caches (ARM9 cache not updated when DMA or ARM7 changes memory). Does 3DS have similar issues?
I hope that the ARM11 cores are all sharing the same cache (or otherwise, that they can notify each other of memory changes & automatically update their caches)?
With the CDMA/XDMA being made by ARM, I hope that these DMA's are integrated with the corresponding CPU caches?
On the other hand, I guess nintendo's NDMA isn't aware of CPU caches?
And ARM9 cache isn't aware of ARM11 cache?
Oh, and ARM9 is having DTCM and ITCM. Does ARM11 have that kind of memory, too?
My wifi init code starts with sending SDIO CMD5 (the IO_SEND_OP_COND command assigning/detecting the supported SDIO bus voltages). That's working fine on DSi. But on 3DS I am just getting a transfer timeout (reading the SDIO irq/status register returns [1012201Ch]=20C00631h, with bit22 meaning CMDTIMEOUT).
I suspect that the problem is caused by some 3DS control register holding the atheros chip in reset state, or disabling some clock signal.
On the DSi, there are these wifi-related config registers:
Code: Select all
- SCFG_EXT7.bit19 needed for SDIO controller (else 4004Axxh-4004Bxxh disabled) - SCFG_CLK7 seems to be NOT needed for SDIO clock enable (unlike as for SDMMC clock) - SCFG_WL.bit0 seems to be wifi-related (but effect is unknown) - GPIO_WIFI.bit8 needed for AR6013G chips (else SDIO Function 1 fails) - I2C register BPTWL[30h] needed for LED and SDIO (else SDIO fails badly) - RTC.FOUT pin as configured by firmware (else WMI commands/events fail)
Code: Select all
- CFG11_WIFIUNK.bit4 should be set - CFG11_WIFICNT.bit0 should be set or cleared? - I2C register MCU[2Ah] should be whatever?
Any ideas what else to try?
The NWM driver does directly access the two CFG11_WIFIxxx registers. Maybe it's also accessing further I2C, MCU, RTC or GPIO or other stuff (but if so, then it's probably done via OS functions instead of via direct I/O addressing, and I don't know enough about the 3DS OS to figure out if or how it's doing that).