It is currently Mon Jul 22, 2019 9:41 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 76 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Thu May 30, 2019 3:51 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
Thanks for the background info on where the abbreviations came from! In some cases I would have wished that the 3dbrew wiki would be more clear on the meaning of that abbreviations, like "MPCore = ARM's interrupt controller". Or just mark unknown meanings as such, like "CGC = Unknown purpose".

profi200 wrote:
The regs are already documented so why copy the official doc from ARM?
The MPCore stuff is already documented? Do you mean elsewhere than in official docs from ARM?

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.
Yeah, I have probably really spent lots time and digged through tons of atheros driver code.
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?

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

coto wrote:
Dude. Just google around : ARM AXI BUS (3DS)
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.
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?


Problem!
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:
 - 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)
For 3DS, there are some registers that may have similar purposes:
Code:
 - CFG11_WIFIUNK.bit4 should be set
 - CFG11_WIFICNT.bit0 should be set or cleared?
 - I2C register MCU[2Ah] should be whatever?
I have tried to init the above registers (and tried to set almost all unknown CFG9/CFG11 bits, and to set/clear all GPIO registers), but that didn't help.
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).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu May 30, 2019 7:23 pm 
Offline

Joined: Wed Mar 06, 2019 6:00 pm
Posts: 8
nocash wrote:
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).


Of course it is important, but I think it requires a rather mature Nintendo DS emulator that is able to run NDS titles fully. As the earlier document describes thoroughly how to emulate the MPU (on AHB, being the NDS), which is useful for GBA virtualization as seen in open source GBA "hypervisors" for NDS. There's no other workaround for running GBA code (at least when a data abort/instruction abort happens due to unmapped memory read/written)


On the 3DS I don't know. Since GBA VC games are able to run from 1:1 GBA images, that leads me to believe there is some sort of Memory Mapping scheme in the GBA VC emulator using the MMU "ARM demand paging" feature, described in these two docs:

(1: armv7 doc, but still useful info to understand the 2: armv6 doc)

1)
http://liacs.leidenuniv.nl/~rietveldkfd ... rm-mmu.pdf (Page 36 onwards, the "2 level page tables." will help to understand

2)
this


Top
 Profile  
 
PostPosted: Fri May 31, 2019 5:46 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
Got it going a step farther!
The hardware specs on https://www.3dbrew.org/wiki/GPIO_Registers are rather meaningless. But the software specs on https://www.3dbrew.org/wiki/GPIO_Services are revealing a bit more info (including on hardware bits). Namely, this GPIO setting "[10147028h]=1" fixes the SDIO timeout issue.
The parts that I am still concerned about are the 3DS equivalents to BPTWL[30h] and especially RTC.FOUT. But those will be needed only later in wifi init... I don't know yet if there will be really any problems with that stuff.

coto wrote:
On the 3DS I don't know. Since GBA VC games are able to run from 1:1 GBA images, that leads me to believe there is some sort of Memory Mapping scheme in the GBA VC emulator using the MMU "ARM demand paging" feature, described in...
I would assume that they are loading the GBA ROM-image to Main RAM, and then map the RAM to the GBA's physical ROM-address space. Using vitual MMU addresses for GBA mode would be very unexpected. But if they do, then I promise that I will read all the AXI and AHB docs ; )

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Fri May 31, 2019 12:01 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
Almost there. Uploading the four firmware blocks seems to work fine, and I am getting meaningful responses for the chip_id, eeprom_id, and rom_version.

The part where I am stuck now is the final "handshake" after firmware upload, the first handshake message (from the wifi chip) seems to arrive... but my code is using NDMA for transferring that kind of messages... and it does look as if 3DS doesn't have any WifiSDIO startup mode for NDMA (I've tried all unknown modes: 06h,07h,0Dh,0Eh, but none worked).

The other option on ARM9 side would be XDMA, currently there seem to be only two known XDMA startup modes (00h and 07h).
Does somebody have a list with more XDMA modes? That would be very useful! : )

Well, and otherwise I am in the unfortunate situation of having a (supposedly) perfectly working wifi engine, but on the wrong CPU : /

Then I could try port the whole ARM9 code to ARM11 side (lots of work). Or go dirty, and forward a "please do a CDMA for me" message from ARM9 to ARM11 via IPC interrupts (ugly, but it might be the fastest way to get things working, and it would help to implement a better solution later on).

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Jun 01, 2019 1:58 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
The wifi hardware interface seems to be working fine now. The firmware upload/handshake is passing okay, and wifiboot then goes into channel scanning mode. For testing, I've made it to display the names of all access points in the neighborhood, which is working pretty well.

With NDMA didn't work. There seems to be no SDIO startup mode (for auto-starting on each block of a multiblock transfer). So I've tried to manually start NDMA on each separate block (with polling the SDIO_IRQ32 register). That is actually working okay on DSi - but doesn't work on 3DS (it passes through the NDMA's, but then hangs when waiting for the final SDIO DATAEND flag). I don't know what is wrong there. It almost looks as if some SDIO or NDMA bits are slightly different on 3DS? Or it's some sinister timing issue.

Without NDMA does work. The DSi wifiboot code did already have an option for using DATA16 with LDRH/STRH (instead of DATA32 with NDMA), so I just had to enable that option. The downside is that manually reading 16bit data tends to be slower (or, when using faster/cached memory or 16bit DMAs, then it can become too fast: I had problems with that on DSi, it became unstable when reading multiple blocks without delays at block boundaries).
Anyways, for now, the DMA-less 16bit access seems to be working well enough.

Still missing is overall software stuff for handling files with FIRM headers, ie. loading them into no$gba, sending them with the no$gba wifi upload function, and receiving them with the 3ds wifiboot code, well, and then jumping to the entrypoints. And, alongsides I will need to rearrange my memory map (wifiboot is currently executing in AXI RAM, where it would get overwritten by the uploaded file).
I guess moving wifiboot into Main RAM should work (FIRM's don't seem to be allowed to be loaded to Main RAM; but Main RAM might be slower than preferred).
Or I could try to execute code in VRAM, if that's working and faster? Theoretically FIRM blocks could be loaded into VRAM, so that could be a conflict - but the conflict is already there because of the screen output during wifi transfers).
But before continuing with that stuff, I will probably pause for a week & enjoy some summer days.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Wed Jun 05, 2019 7:37 am 
Offline

Joined: Mon May 13, 2019 5:32 pm
Posts: 7
I've made some more progress on my own emulator. I hit a wall in getting Process9 to work, so I implemented the ARM11 MMU to get Kernel11 further. It's very basic and will break once we hit userland, but it'll have to do for now. I also had to redesign my ARM11 interrupt handling to support more than a single core.

With this, both the appcore and syscore are active, and I was able to get rid of some hacks I used to get Process9 to boot. It now crashes because Kernel11 reads from DSP memory, which is unimplemented. This is where the sysmodules are located. I need to implement ARM11 timers and improve my MMU emulation before I go further.

AXI seems to be a way for the cores to synchronize with each other. The cores share kernel code and data in AXI WRAM, so they use "load exclusive" and "store exclusive" operations as some sort of mutex/semaphore. These operations only work properly when the memory system has a monitor for those exclusive operations.


Top
 Profile  
 
PostPosted: Wed Jun 12, 2019 3:41 pm 
Offline

Joined: Mon May 13, 2019 5:32 pm
Posts: 7
Another progress report! After fixing countless CPU, MMU, DMA, eMMC, and PMR bugs, we finally have sysmodules running on the emulator. Kernel11 manages to load these modules: PXI, FS, PM, and SM. All four modules are running as their own processes mapped in userland. Process9 initialization is complete, and the ARM9 can accept PXI commands from the ARM11.

PM tries (and fails) to load the NS module. Process9 is unable to find NS for some reason, which I'm currently investigating. I'm also starting to do some optimization, since we're currently only able to run about 10 million instructions every second when all three cores are active. There's a lot of low-hanging fruit, and we should be able to get reasonably decent speeds even with just an interpreter.


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 12:52 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
I got the 3DS wifi uploader working and booting the uploaded FIRM file!
Altogether it wasn't too difficult to implement the missing stuff since last post. Apart from two bugs that had delayed things:

I spent almost a whole day on finding a bug related to a misaligned memory access (the bug did exist in nds/dsi version, too, but the 3DS does apparently default to trigger an exeption in such situations).

And then I've spent a whole day on trying to get bloody IPC_SYNC messages working, which shouldn't have been an issue at all - but it didn't work no matter what.
The problem was that the send-value is write-only on 3DS. Unlike as on NDS/DSi (and unlike as what is said on 3dbrew wiki), the 3DS send-value isn't R/W, and does merely return zero when trying to read it!
My code was using 32bit "LDR+SetBit31+STR" to enable IPC IRQs (and thereby unintentionally replaced the send-value by zero). As work-around, I am now using 8bit "LDRB+SetBit7+STRB".

I'll still need to fine-tune the transfer protocol, and perhaps improve the transfer speed, but at least I can now do that stuff via wifi, without needing to plug/unplug SD/MMC stuff any longer : )

It would be also nice to support uploading NDS/DSi and GBA files to 3DS. Are there already homebrew tools that can switch to GBA/NDS/DSi mode (without using the 3DS operating system)?
For now, it would be easier to implement GBA/NDS/DSi as than trying to upload 3DS .code files (which would require to boot the OS, or even write a complete OS clone).

PSI wrote:
I've made some more progress on my own emulator.
Cool! I am still far away from emulating anything myself. I will probably first do some tests on how the hardware is working (there are some things that I wanted to know for years, and now I can finally test them).
Well, and I am a bit afraid of trying to allocate 128Mbytes of MainRAM in no$gba... I am not too sure if my PC can handle that.

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 4:13 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 13
nocash wrote:
profi200 wrote:
The regs are already documented so why copy the official doc from ARM?
The MPCore stuff is already documented? Do you mean elsewhere than in official docs from ARM?

I mean the official documentation.

nocash wrote:
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?

The DSi never caught much interest is why. It's really just a more powerful DS unlike the 3DS which is an entirely new platform (but with backwards compatibility).
Feedback for FTPd was always there but recently it's quiet because most people moved on to the Switch.

nocash wrote:
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?

[...]

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?

It's probably so slow because it still uses the old propritary interface (? not familiar with libnds code) instead of SDIO and lots of overhead in old, poorly written code. I don't know.

The only DMA controllers that may be able to do unaligned accesses and halfwords are the CoreLink DMA-330 controllers (C/XDMA) which are a bit of a pain since you need an assembler/runtime translation code for them (ARM only provides one for paying customers but at least the instruction encoding is public). And no, there is no coherency at all between CPU and any periphals not part of the CPUs. That feature was added in ARMv8 i think.
CPU caches are separate between CPU clusters. The ARM9 could not access the ARM11 caches even if Nintendo wanted that since it would require a heck of hackjob that would break ARM's specs. The 2/4 ARM11 cores all have their own L1 cache but coherency between them is guaranteed in SMP mode (if you give the CPUs a bit of a helping hand by using ldrex/strex and such). The L2 cache on N3DS is shared by all 4 ARM11 cores.

There are no TCMs at all on the ARM11 side (implementation defined but Nintendo did not include TCMs for ARM11).



nocash wrote:
I would assume that they are loading the GBA ROM-image to Main RAM, and then map the RAM to the GBA's physical ROM-address space. Using vitual MMU addresses for GBA mode would be very unexpected. But if they do, then I promise that I will read all the AXI and AHB docs ; )

The ROM is stored in FCRAM and the remaining is some sort of physical memory mapping stuff. There is actual DS and GBA hardware in there. No emulation. This has not been looked into much at all but the mode switch + turning on the ARM7 was archived. Without the "twlbg" process on ARM11 you can't get DS(i) mode working since it does at least display and sound.



nocash wrote:
...it does look as if 3DS doesn't have any WifiSDIO startup mode for NDMA (I've tried all unknown modes: 06h,07h,0Dh,0Eh, but none worked).

The other option on ARM9 side would be XDMA, currently there seem to be only two known XDMA startup modes (00h and 07h).
Does somebody have a list with more XDMA modes? That would be very useful! : )

The ARM9 is not meant to handle WiFi in 3DS mode so it doesn't have startup modes or IRQs for any of the WiFi/SDIO hardware. The startup modes on 3dbrew are the only known ones.



nocash wrote:
I guess moving wifiboot into Main RAM should work (FIRM's don't seem to be allowed to be loaded to Main RAM; but Main RAM might be slower than preferred).
Or I could try to execute code in VRAM, if that's working and faster? Theoretically FIRM blocks could be loaded into VRAM, so that could be a conflict - but the conflict is already there because of the screen output during wifi transfers).

FCRAM is pretty slow. VRAM behaves exactly like all the others unlike on GBA/DS(i). Code can be executed there and non-word accesses work.



PSI wrote:
Another progress report! [snip]

But what about the other platforms? firm0/1 verification is still broken on Windows and Linux. A working bare metal emu that can emulate ARM9/11 well enough to run the fastboot3DS codebase would be very helpful for my own kernel project (based on that fb3DS code).



nocash wrote:
I spent almost a whole day on finding a bug related to a misaligned memory access (the bug did exist in nds/dsi version, too, but the 3DS does apparently default to trigger an exeption in such situations).

My code was using 32bit "LDR+SetBit31+STR" to enable IPC IRQs (and thereby unintentionally replaced the send-value by zero). As work-around, I am now using 8bit "LDRB+SetBit7+STRB".

It would be also nice to support uploading NDS/DSi and GBA files to 3DS. Are there already homebrew tools that can switch to GBA/NDS/DSi mode (without using the 3DS operating system)?
For now, it would be easier to implement GBA/NDS/DSi as than trying to upload 3DS .code files (which would require to boot the OS, or even write a complete OS clone).

Well, and I am a bit afraid of trying to allocate 128Mbytes of MainRAM in no$gba... I am not too sure if my PC can handle that.

ARM9 should have the old unaligned access behavior where it rotates stuff around. ARM11 can do proper unaligned access depending on the control register config.

Nintendo accesses that reg with ldrb/strb after initialization.

There is no AGB-/TWL_FIRM replacement at all. Trust me it's more complicated than you think (LGCY regs, GPU, sound and more...).
And for 3DS userland there is already a homebrew SDK. Otherwise there is plenty of working bare metal code.

I can't resist to ask but is that a joke? Barely anyone has <4 GiB RAM these days. I have 16 GiB.


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 7:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21511
Location: NE Indiana, USA (NTSC)
profi200 wrote:
nocash wrote:
Well, and I am a bit afraid of trying to allocate 128Mbytes of MainRAM in no$gba... I am not too sure if my PC can handle that.

I can't resist to ask but is that a joke? Barely anyone has <4 GiB RAM these days. I have 16 GiB.

He appears to still use a PC running Windows 9x.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 7:42 pm 
Offline

Joined: Mon May 13, 2019 5:32 pm
Posts: 7
nocash wrote:
Cool! I am still far away from emulating anything myself. I will probably first do some tests on how the hardware is working (there are some things that I wanted to know for years, and now I can finally test them).
Well, and I am a bit afraid of trying to allocate 128Mbytes of MainRAM in no$gba... I am not too sure if my PC can handle that.

I've encountered a couple of unknowns already - in particular, some of the poorly defined NDMA startup modes are still used.

It only gets worse with New3DS, as there's an additional 128 MB of FCRAM (256 MB total), as well as two new cores and other features. That being said, I don't think the boot ROMs access FCRAM at all, so you can at least use those for testing.

profi200 wrote:
But what about the other platforms? firm0/1 verification is still broken on Windows and Linux. A working bare metal emu that can emulate ARM9/11 well enough to run the fastboot3DS codebase would be very helpful for my own kernel project (based on that fb3DS code).

Of course I'd like Corgi3DS to be cross-platform, and in theory it should be. In practice, the library I'm using for RSA (libgmp) seems to easily expose various compiler bugs. Someone has made a PR to use polarssl instead which should be more portable, but I haven't had time to look at it (and there's various merge conflicts on it now).

I haven't tested fastboot3DS at all, only NATIVE_FIRM and Luma3DS. Could you give more details on your kernel project?


Top
 Profile  
 
PostPosted: Thu Jun 13, 2019 10:45 pm 
Offline

Joined: Fri May 10, 2019 4:48 am
Posts: 13
tepples wrote:
He appears to still use a PC running Windows 9x.

Yeah, i knew that but i would at least expect 1 or 2 GiB. 98 or XP takes next to nothing on resources.

Btw something this forum really needs is a multi quote function.



PSI wrote:
That being said, I don't think the boot ROMs access FCRAM at all, so you can at least use those for testing.

As long as the bootroms are unlocked (sysprot regs) FCRAM is not accessible at all. 3dbrew may be missing this little detail.

PSI wrote:
Of course I'd like Corgi3DS to be cross-platform, and in theory it should be. In practice, the library I'm using for RSA (libgmp) seems to easily expose various compiler bugs. Someone has made a PR to use polarssl instead which should be more portable, but I haven't had time to look at it (and there's various merge conflicts on it now).

I haven't tested fastboot3DS at all, only NATIVE_FIRM and Luma3DS. Could you give more details on your kernel project?

Meh, i may look into porting the code over to mbedtls (which is the successor of polarssl and has proper hardware acceleration).

I have been working privately on it for a while. It's a cooperative library kernel that's linked directly with the application. Currently there is a bug where it corrupts the console for a moment and i could not figure out what causes it yet. Emulation may help here.


Top
 Profile  
 
PostPosted: Sat Jun 15, 2019 2:56 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
Cameras: I've dumped the 3DS camera chip IDs. They are 2280h (Aptina MT9V113). So, all three New3DS cameras are having same chip ID as the two DSi cameras. That was one of big unanswered questions that I've been wondering about ever since 4-5 years ago.
But then, I've also had a look at Nintendo.com, and there they are saying that the New3DS has "Improved Cameras" with support for brighter pictures in dark environments. I don't know what's that about, maybe they have just improved the shutter time in software, or the hardware is actually using different camera revisions despite of the same chip IDs.

Eye-tracking: How does that work, and what is it good for?
Is that simply using the internal camera, and running image-recognition software on ARM11 for eye-tracking? Or is there some extra hardware component that spits out eye-tracking coordinates?
Reportedly there is a "IR LED" (not an IR sensor, nor IR camera) next to the internal camera, said to improve eye-tracking, but I don't understand how an IR light source code improve anything... unless the camera were able to receive IR alongsides with the usual RGB/YUV image... and even then, I would have assumed that IR cameras worked best by picking up body temperatures, without needing an external IR light source.
And finally, going by 3dbrew, there is a "parallax barrier" to separate left/right stereoscopic pixels. Does the eye-tracking thing allow to shift the direction of that parallax barrier?

profi200 wrote:
There are no TCMs at all on the ARM11 side (implementation defined but Nintendo did not include TCMs for ARM11).
Good to know! Reminds me of another basic beginners question:
Does 3DS/ARM11 support THUMB2 instruction set?

Oh, and DSi CPU chip did support two NDS-cartridge slots (a prototype relict, the actual mainboards did have only one cart slot).
The 3DS CPU chip seems to have completely ditched that feature (eg. 3DS Port 10000010h seems to be equivalent to SCFG_MC on DSi, but without the extra bits for 2nd slot in bit4-7 and bit15). And there seems to be only one set of "Ntrcard" registers for accessing the cart slot in NDS mode.
But then, there are two sets of "Ctrcard" registers for accessing the cart slot in 3DS mode - what is that good for?

profi200 wrote:
It's probably so slow because it still uses the old propritary interface (? not familiar with libnds code) instead of SDIO and lots of overhead in old, poorly written code. I don't know.
No, libnds probably doesn't support SDIO yet. But for my own wifiboot uploader, I've rev-engineered SDIO and WPA/WPA2 some months ago: viewtopic.php?f=23&t=18065 - The 400-600 Kbyte/s was for SDIO on DSi. I don't know either why it won't get faster (the source code is included in the wifiboot package, just in case somebody wants to try to improve the transfer speed, or port it to libnds).
For SDIO on 3DS, I am only getting 150 Kbyte/s yet (probably because packets are merely polled via 60Hz timer IRQ, that could be fixed by forwarding the actual wifi IRQs from ARM11 to ARM9) (and I should someday enable data caches for improving 3DS memory timings). But I am currently uploading only small .firm files with 20-60 Kbytes, so 150K/s is more than fast enough.

profi200 wrote:
The only DMA controllers that may be able to do unaligned accesses and halfwords are the CoreLink DMA-330 controllers (C/XDMA) which are a bit of a pain since you need an assembler/runtime translation code for them (ARM only provides one for paying customers but at least the instruction encoding is public).
The CDMA/XDMA controllers have their own instruction set??? Though I don't see that when looking at the CDMA/XDMA functions in bootrom.

profi200 wrote:
ARM9 should have the old unaligned access behavior where it rotates stuff around. ARM11 can do proper unaligned access depending on the control register config.
Well, then I could also use non-DMA for fast unaligned memory transfers, on ARM11 side at least. Or, otherwise, it might also work with LDR/STR (or LDMIA/STMIA) on ARM9, when manually shifting the misaligned words; that would be a bit complicated, but probably faster than looping through hundreds of LDRH/STRH opcodes.

profi200 wrote:
Without the "twlbg" process on ARM11 you can't get DS(i) mode working since it does at least display and sound.
Is that just some initialization stuff for preparing the 3DS-to-DS(i) mode switch, or is there code running on ARM11 while in DS(i) mode?
Hmmmm, yeah, mode switching might require some months of research (switching from DSi-to-DS mode wasn't so easy either; it did require several small functions for the different hardware components, nothing really complicated, but it did sum up to get everything working).

profi200 wrote:
FCRAM is pretty slow. VRAM behaves exactly like all the others unlike on GBA/DS(i). Code can be executed there and non-word accesses work.
Yeah, I am running my code in VRAM meanwhile. DSi did support 8bit VRAM-writes, too.

PSI wrote:
I've encountered a couple of unknowns already - in particular, some of the poorly defined NDMA startup modes are still used.
One further mode is mode=12 for NTRCARD, used by bootrom:
Code:
FFFF31AA 0689     lsls    r1,r1,1Ah     ;2Ch shl 24 ;startup=0Ch and bit29=1
Some things that could be more clear on the 3dbrew NDMA page are the difference between "INFIFO" and "INFIFO", and which of the MMC modes is refering to the actually used SD/MMC hardware. And mode 13 and 14 might be something unknown yet.
And I guess XDMA might also support more modes (possibly even SDIO Wifi). But it would require some trial and error testing to find out if any of the XDMA modes responds to this or that hardware events.

PSI wrote:
It only gets worse with New3DS, as there's an additional 128 MB of FCRAM (256 MB total), as well as two new cores and other features. That being said, I don't think the boot ROMs access FCRAM at all, so you can at least use those for testing.
Yup, there I could really get away without FCRAM for now. Or brew up something that allocates only as much RAM as currently used (and re-allocates more if needed).

PSI wrote:
I haven't tested fastboot3DS at all
I haven't tried it yet, too, but I'll test it next some days. I am curious if my wifiboot tool can upload and boot it (and if there are some other useful tools in it (I still need an OTP dumper, which might be in there? and an atheros wifi ROM dumper, which probably doesn't exist yet?)).
As far as I know, fastboot uses the same LCD framebuffer video output as bootrom, so that might be a pretty nice thing to test if you don't have GPU video emulated yet.

profi200 wrote:
I can't resist to ask but is that a joke? Barely anyone has <4 GiB RAM these days. I have 16 GiB.
I think that I have 256Mbyte in my PC. But I am more fond of having written a Color Gameboy emulator on a monochrome VGA monitor : )

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Sat Jun 15, 2019 5:00 pm 
Offline

Joined: Mon May 13, 2019 5:32 pm
Posts: 7
nocash wrote:
Does 3DS/ARM11 support THUMB2 instruction set?

They do not. All ARM11 kernel/process code I've seen thus far only uses ARM mode as well. The ARM9 mainly uses Thumb mode.

nocash wrote:
The CDMA/XDMA controllers have their own instruction set??? Though I don't see that when looking at the CDMA/XDMA functions in bootrom.

Indeed they do. The XDMA functions take a set of parameters and then create the bytecode based upon those parameters.

nocash wrote:
Some things that could be more clear on the 3dbrew NDMA page are the difference between "INFIFO" and "INFIFO", and which of the MMC modes is refering to the actually used SD/MMC hardware. And mode 13 and 14 might be something unknown yet.
And I guess XDMA might also support more modes (possibly even SDIO Wifi). But it would require some trial and error testing to find out if any of the XDMA modes responds to this or that hardware events.

Something I found completely mystifying is that when decrypting the FIRM, Boot9 sets two NDMA channels to mode 15 (eMMC->AES, AES->SHA). I use a hackish method to handle this, but I don't know how exactly these channels are supposed to be triggered.

Boot9 only seems to reset channels 0 and 7 on XDMA (CTRCARD and SHA). I have a feeling that's all the ARM9 supports, unlike the ARM11 which does have all eight channels.


Top
 Profile  
 
PostPosted: Sun Jun 23, 2019 10:22 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 941
I have dumped the AR6014 ROM and spent some days on searching differences in the ROM/RAM code for AR6014 vs AR6013 vs AR6002 (good way to get your head spinning). The most striking finding is that - apart from software revisions - there don't seem to be any relevant differences in the underlaying hardware...

hw2/hw4/hw6: Atheros source code exists for three hardware revisions (hw2/hw4/hw6), and I had expected AR6002/AR6013/AR6014 to use that hardware revisions accordingly. But it turned out that they are all using the old "hw2" variant. For example, they are all using the same ADDR_ERROR and TCAM registers.
There are some small differences on how the chips are wired up, especially between AR6002 and AR6013: The I2C EEPROM is wired to different GPIO pins (that originally made me think it were hw2 vs hw4, but actually it's both hw2). The other differences between that two chips are different ROM/RAM sizes, different package, different oscillator(s), and built-in MM3218 in AR6013.
On the other hand, there seem to be no differences between AR6013 and AR6014 (apart from minimal changes to the ROM, which could have been as well patched in the firmware RAM, one wouldn't have needed a new chip for that).

NWM variants 1/4/5: There are those three different variants labelled 1/4/5 in each NWM file...
Type1 is the smallest, and it seems to be working best for compatibility with DSi code (and I guess that it's probably actually intended for that purpose).
Type4 crashed my wifiboot code during the DHCP phase where it did throw an unexpected event number: 1025h (that whould be WMI_ACL_DATA_EVENT going by official source code; though they tend to change and mess up their numbering every once and then). I've changed the wifiboot code to ignore that event, and the upload is now working fine with it, too. (I guess Type4 is just same as Type1, plus some extra functions for use by 3DS titles).
Type5 doesn't work with wifiboot at all, it doesn't even find my access point. The Type5 code contains some ASCII strings saying "MACFilter" and "GameID", so that seems to be some nintendo-specific gaming stuff, probably for Local-Network-Multiplayer games (assuming that 3DS is no longer using the old NDS-wifi hardware for that purpose).

NWM revisions: There are several NWM revisions released with 3DS firmware updates (and a safemode NWM version that should be same most firmwares). I was wondering if they contain different ARM code and/or actual changes to the Xtensa code... so I have written a tool that loads the Xtensa code/data from the safemode NWM files, and then searches the same code/data in other NWM files. As by now I have compared only two files (the safemode thing, and another one extracted from 00000017.app). Unfortunately, there are differences:
Code:
 MainCodeDSi = ERROR   ;Type1 (dsi code?)
 MainCodeMac = ERROR   ;Type5 (3ds multiplayer code?)
 MainCodeAcl = ERROR   ;Type4 (3ds code?)
 DatabaseDat = OK      ;Database
 EepromStubC = OK      ;Eeprom loading stub code
 EepromStubD = OK      ;Eeprom loading stub data
Well, at least the database and eeprom stuff is same. Btw. the eeprom stuff is also almost same as in AR6013 (on AR6104 the code is 4 bytes bigger; the differences seem to be 5 new opcode bytes (and a removed padding byte), for setting a reserved word at index FCh in the host interest area to 00000003h).
And the other stuff... 3dbrew title list is listing 11 NWM versions (plus 3 safemode NWM versions), and if Type1/4/5 are changed in each version... then that would be up to 42 different code blocks. Hmmm, rev-engineering the exact differences in 42 versions wouldn't be so much fun.

Does somebody have a collection of those NWM files? Best as raw .code files (=extracted from the encrypted/compressed .app files). I could use my NWM comparision tool to check if there are at least some versions containing the same Xtensa code in them.

And some other news... the wifiboot code is getting better and hopefully ready for release soon. The SDIO IRQ is now forwarded from ARM11 to ARM9... that has raised the transfer speed to more than 300Kbyte/s (and I still have some ideas that should get it yet a bit faster). And I've finally added the feature for updating the console's RTC from PC's local time, so the console won't be stuck on 00:00:00 1st January 2000 after each battery removal.

_________________
homepage - patreon


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 76 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group