nesdev.org

Posted: **Sun Jul 21, 2019 4:02 pm**

nocash wrote:Ooops, yes, I didn't have the .fix directive in diag3ds for fixing the sha256's, thanks.
Immeditialy powering down in diag3ds happens if you have button a/b pressed (I guess you did so in fastboot menu).
Well, at least you do now know how immediately powering off looks like, without the led fade-out delay.

Choosing A for poweroff is not a good idea. Very quickly pressing A makes that tool actually work.

nocash wrote:I've spent the whole day on trying to figure out why wifiboot doesn't work with fastboot. I didn't found the problem. But noticed some other issues.

Fastboot seems to destroy the "LDR PC,[$+4]" opcodes in the exception handlers. That's causing diag3ds to hang upon data aborts (in the memdump screens) (because it's setting only vector at address $+4, but not the LDR opcode in the preceeding word).

You should not rely on the bootloader to setup things like that. You maybe can assume that when booted by the bootroms but not bootloaders running after the bootroms. fb3DS stubs the second exception vectors before it loads a FIRM to prevent it from jumping who knows where (in case of an exception). A few other FIRM loaders do this too because it's considered good practice.

nocash wrote:Fastboot seems to have some of the New3DS-only CFG11 registers set to nonzero values (unlike when booting from bootrom).
For example, reading 10141300h (CFG11_MPCORE_CLKCNT) returns 00018001h. That would be bit16=unknown?, bit15=busy???, bit0=enable something.
I've tried to reset the New3DS-related CFG11 registers to zero, but that didn't help (but I don't know if it's that easy, or if one must reset them in a specfic order).

This reg is 16 bits wide and it's set to 1 to enable the other 128 MB RAM for FIRM files booted through it. It has no other (known) effect. To undo this you need interrupts enabled doing this: https://github.com/derrekr/fastboot3DS/ ... cpu.c#L134
This will hang if all the ARM11 cores don't enter wait for interrupt state. The part where it changes it is line 123.

nocash wrote:Running out of ideas, I've tried to add a huge wait-by-loop delay in wifiboot (to see how fast the arm11 cpu is running; with code cache enabled). The delay takes 10s when booted from bootrom, but with fastboot it comes out as 15 second delay.

If you have hardmod, then you could simply install wifiboot as firm0, I am quite optimistic that it will boot perfectly (or if it doesn't work then you would need the hardmod to uninstall it).

You seem to make a lot of assumptions about the environment/hardware state your code is running under. For example you are sending an IRQ over PXI without doing any sort of handshaking after control is handed over to your code (= assuming ARM11 is not slower than ARM9 which may not be true depending on the FIRM loader) or you are assuming r0 is 0 on entry and passing this immediately to the cache mcr instructions when ARM states the register "SBZ" (should be zero). The bootroms only clear all the regs because of security reasons just like they are going insane clearing the cache lines manually. I would recommend you initializing absolutely every piece of hardware you use just like we and others do. It makes it far less likely to run into strange freeze errors taking ages to debug.

I have tried running it from firm0 and indeed it started working but it still gives this hexdump running it again. You are probably not disconnecting properly from the AP is my guess (in this case). And i don't need no boring hardmod anymore since ntrboot (flashcard) is way easier and faster

Posted: **Tue Jul 23, 2019 11:52 am**

I've made a database with some of the most important initial bootrom register values, mostly AMR9 registers, plus ARM11 IRQ registers. And a selftest function that displays all mis-initialized registers (ie. showing addresss, correct, incorrect values):

diag3ds.ZIP: (9.5 KiB) Downloaded 229 times

The main issue that breaks wifiboot seems to be that fastboot is routing all ARM11 IRQs to "target=nowhere" (instead of "target=CPU0"). The IRQ priorities are also set to non-default values (but that shouldn't disturb in case of wifiboot).

Okay, if wifiboot is working when you boot it as firm0 (or change the IRQ targets mentioned above)... what is working exactly?

Uploading and starting .firm files is working, right?

Are the display glitches still occurring?
And if yes, does the bootrom's blue-screen have those glitches, too?
Asking because my code is based on the bootrom screen output.

The hexdump error is from an unexpected WMI_DISCONNECT_EVENT (with reason value AUTH_FAILED). I have never experienced that with my APs (except perhaps on bad WEP passwords, but not on simple re-connections) (well, and I do occassionally get disconnected after several minutes of inactivity, not sure why, the code should send dummy messages every once and then to prevent that).

I'll add a WMI_DISCONNECT_CMD after successful upload in next version, maybe that will convince your AP that it may process new re-connections thereafter.
Of course, I can't do that if wifiboot has crashed (that will hopefully no longer happen, when fixing the IRQ targets).
And, the very nature of mobile wifi is that connections can get lost without proper disconnection. If your AP is really insisting on disconnections, and refusing re-connection otherwise - that might be a bit frustating.

I could also add retries in the connect function, but if that works depends on how often or long your AP is refusing connections...
Does the hexdump error occur only ONCE, on the first reboot after the upload?
Or does it occur REPEATEDLY upon each and every reboot, until some timeout has ellapsed after some minute(s)?

In the latter case, automatic retries won't help too much.

Posted: **Tue Jul 23, 2019 1:44 pm**

nocash wrote:I've made a database with some of the most important initial bootrom register values, mostly AMR9 registers, plus ARM11 IRQ registers. And a selftest function that displays all mis-initialized registers (ie. showing addresss, correct, incorrect values):
diag3ds.ZIP
The main issue that breaks wifiboot seems to be that fastboot is routing all ARM11 IRQs to "target=nowhere" (instead of "target=CPU0"). The IRQ priorities are also set to non-default values (but that shouldn't disturb in case of wifiboot).

This is not worth changing in my opinion. I spent quite a bit time to understand how the GIC works and getting it in a stable, initialized state. It's worth noting that the GIC causes issues to FIRM files booted through fb3DS if it doesn't reset it before jumping to the loaded FIRM. I don't know how that happens to FIRMs not using IRQs at all but it did. Initially i was setting the priorities all to 0xF which caused NATIVE_FIRM to hang on N3DS. Stuff like that pisses me off but i can't do anything but "fix" it on my side since Nintendo will not give a fuck fixing their code. This does a full reset on it and it works with everything else including Nintendos FIRMs: https://github.com/derrekr/fastboot3DS/ ... rupt.c#L31

nocash wrote:Okay, if wifiboot is working when you boot it as firm0 (or change the IRQ targets mentioned above)... what is working exactly?

Uploading and starting .firm files is working, right?

It's uploading and running the FIRM as intended. Note: You should check the FIRM section hashes in wifiboot. It looks like it doesn't care currently but trust me, if you are dealing with noobs you want to be on the safe side and verify the FIRM.

nocash wrote:Are the display glitches still occurring?
And if yes, does the bootrom's blue-screen have those glitches, too?
Asking because my code is based on the bootrom screen output.

Not tested on N3DS. I did all this on my test dummy old 3DS. The N3DS i'm using for playing games and i had to fix corrupted files on the SD card just a few days ago so i would rather not take any chance.

nocash wrote:The hexdump error is from an unexpected WMI_DISCONNECT_EVENT (with reason value AUTH_FAILED). I have never experienced that with my APs (except perhaps on bad WEP passwords, but not on simple re-connections) (well, and I do occassionally get disconnected after several minutes of inactivity, not sure why, the code should send dummy messages every once and then to prevent that).

I'll add a WMI_DISCONNECT_CMD after successful upload in next version, maybe that will convince your AP that it may process new re-connections thereafter.
Of course, I can't do that if wifiboot has crashed (that will hopefully no longer happen, when fixing the IRQ targets).
And, the very nature of mobile wifi is that connections can get lost without proper disconnection. If your AP is really insisting on disconnections, and refusing re-connection otherwise - that might be a bit frustating.

I could also add retries in the connect function, but if that works depends on how often or long your AP is refusing connections...
Does the hexdump error occur only ONCE, on the first reboot after the upload?
Or does it occur REPEATEDLY upon each and every reboot, until some timeout has ellapsed after some minute(s)?

In the latter case, automatic retries won't help too much.

It's happening on every try until after a few minutes. Then it suddely works again. Something that also fixes it is doing the connection test in the system settings which succeeds even faster than usual after wifiboot ran. So nwm is not having any issues connecting even when wifiboot ran beforehand.

Posted: **Tue Jul 23, 2019 2:28 pm**

The ARM datasheet has this sentence -One consequence of the strict comparison is that a Pending interrupt with the lowest possible priority, 0xF, never causes the assertion of an interrupt request to MP11 CPUs, permitting an extra level of interrupt enabling
It isn't quite clear what they are trying to say about which strict comparision, but it might mean that priority 0Fh is disabling the interrupt. The default priority setting when booting firm files is 08h, so you must use that, too, for booting firm files. After all, you do already have code for cleaning up things, you just need to change that code to use the correct values in the cleanup. There are several good reasons for maintaining compatibility with the original bootrom.

Posted: **Tue Jul 23, 2019 3:12 pm**

nocash wrote:The ARM datasheet has this sentence -One consequence of the strict comparison is that a Pending interrupt with the lowest possible priority, 0xF, never causes the assertion of an interrupt request to MP11 CPUs, permitting an extra level of interrupt enabling
It isn't quite clear what they are trying to say about which strict comparision, but it might mean that priority 0Fh is disabling the interrupt. The default priority setting when booting firm files is 08h, so you must use that, too, for booting firm files. After all, you do already have code for cleaning up things, you just need to change that code to use the correct values in the cleanup. There are several good reasons for maintaining compatibility with the original bootrom.

Here, "strict comparison" means that the priority of an interrupt must be lower than the priority mask in order to be asserted. Because the highest value of the priority mask is 0xF, this means that an interrupt with a priority of 0xF will never fire.

...

I've been reading through the last couple pages. nocash, I respect your work and what you've done for the NDS/DSi scene, so I'll try to say this as politely as possible. You are hitting your head against a brick wall if you expect current FIRM loaders to recreate the boot ROM environment. These tools have been around for several years, and they have already set the standards for homebrew FIRMs to follow. If you want wifiboot and any other software you write to be compatible with these loaders, you have to follow their standards, not try to get them to change. That means you must properly initialize all registers on the ARM11 and ARM9. It's a good idea to initialize your environment when writing bare-metal code no matter what the platform is anyway, but here, it's absolutely necessary.

Posted: **Wed Jul 24, 2019 1:50 am**

Ah, okay, that comparision. Now that you mention it, they have that confusing sentence twice in the datasheet (once for the priority mask where it makes sense, and once for the priority values where it appears to out of context because it doesn't mention the relation to the mask thing). Hmmm, the term "mask" is confusing by itself, I guess it's meant to be a 4bit COMPARE value (not an AND-mask).

As for whose head is harder or softer, we will see. I am not srtrictly against proper initializations, but I do think other software - especially bootloaders - are responsible to initialize things properly, too. I hope that I've convinced 1-2 people in NDS scene about that, too (admittingly that wasn't easy). For bootloaders, initialization would be important because otherwise people might think that seemingly working .firm files could be safely installed as firm0, causing bricks. And vice-versa, people thinking that wifiboot didn't work, or that it wasn't properly tested on real hardware.

The goal of some of the conversation is a bit unlcear. It feels a bit like we are saying "my bugs will outperform your bugs" and everyone disagrees on fixing their own bugs, even when knowing about how and what to fix.
Or it looks like so. Behind the scenes: I didn't ignore all advice and I have fixed a couple of bigger and smaller details in my code. I would be glad if future bootloaders will recurse some of my findings, too.
That, even (or especially) if improved initialization accurracy breaks compatibility with older homebrew .firm files. The same problem exists for emulator devrs, too. If an emu can play bugged homebrews then it's an emulation inaccuracy (and potentially hard to fix).

Posted: **Thu Jul 25, 2019 2:20 pm**

I've found out why executing the same "wait-by-loop" did sometimes take around 10 seconds, and sometimes around 15 seconds. That effect was caused by the Branch Prediction bit in ARM11 CP15 Control register. Normally, a SUBS+BNE takes 4 clks per loop cycle, with the branch prediction enabled it does take only 2.5 clks per loop cycle

Ie. it looks as if the CPU predicts 75% of the jumps to be taken; maybe because somebody had estimated loops to repeat in multiples of 4 loop cycles, or whatever.
My test used SUBS r0,1, and BNE for the loop. The bootrom uses SUBS r0,5 and BCS. So, I've tested that, too: The prediction is producing the same timings of 2.5 clks per loop cycle there, too. That timings are all with code enabled, of course.

The two important findings are that: It might be good to enable ARM11 branch prediction to speed up things. And, one must recurse whether branch prediction is enabled when computing timings for "wait-by-loop" functions.

---

And, I have rev-engineered how the CPU clock/mode change register is working exactly:

Code: Select all

10141300h - New3DS - CFG11_MPCORE_CLKCNT
  0-2    Desired Mode (0,1,2,3,4,5,6,7) (see below)                   (R/W)
  3-14   Unused (0)
  15     Mode Change IRQ Flag (0=None, 1=IRQ 58h) (write 1 to reset)  (R/ack)
  16-18  Current Mode (0,1,3,5,7) (see below)                         (R)
  19-31  Unused (0)
Mode values:
  Mode 0: Old3DS Mode, 268MHz (1x), 128MB FCRAM, no L2C cache
  Mode 1: New3DS Mode, 268MHz (1x), 256MB FCRAM, and L2C cache controller
  Mode 3: New3DS Mode, 536MHz (2x), 256MB FCRAM, and L2C cache controller
  Mode 5: New3DS Mode, 804MHz (3x), 256MB FCRAM, and L2C cache controller
  Mode 2/4/6 are same as Mode 0. Mode 7 is same as Mode 5
Mode changes are applied ONLY once when all ARM11 cores are in Wait for IRQ
state (eg. "WFI" opcode). At that point, the IRQ flag in bit15 is set, and IRQ
58h is triggered.
IRQs are triggered ONLY when changing to different modes:
  - Changing between mode 0/1/3/5/7 (because they are different)
  - Changing between mode 5/7 (although they appear to be same)
IRQs are NOT triggered when:
  - Rewriting the current mode value (because mode is already same)
  - Changing between mode 0/2/4/6 (because they are all same as mode 0)

In Old3DS mode, data abort occurs when trying to access the extra FCRAM at 28000000h, or the L2C cache controller at 17E10000h. The other "extra memory" at 1F000000h isn't affected by mode change?
Clock changes affect the ARM11 CPU clock, including the MPCore Timer/Watchdog registers at 17E00600h (if desired, one can change their prescalers to maintain them running at same speed despite of the higher CPU clock).
The 804MHz mode should be used only if CFG11_SOCINFO.bit2 indicates that it is supported.
The IRQ flag in bit15 should be acknowledge before (or alongsides with) writing the desired clock value (needed if it was still set from an older un-acknowledged clock change).
IRQ 58h should be enabled (to recover from WFI, or maybe anything like Vblank IRQ might work for that, too). CPSR.I flag does not need to be enabled, WFI does only wait for IRQs (but can recover without executing them). Using the old CP15 wait for IRQ opcode instead of WFI does work, too.

Posted: **Fri Jul 26, 2019 11:22 am**

profi200 wrote:CARDSPI has been fully figured out by the way and 3dbrew has been updated with all details including a little bug.

Thanks for pointing out! I've just checked the https://3dbrew.org/wiki/SPICARD_Registers page. It looks much than some months ago!
There are some small details that are still unlclear. And some general descriptions could also help to make easier to figure out what the registers & bits are good for.

The overall purpose is related to "savedate on SPI flash chips in game cartridges", right? Well, noob question (and the AUTOPOLL description does already answer the question). Anyways, it would be more clear if it were mentioned at the begin of the article.

The select flag in the DONE register might deserve another short sentence. I assume using (or not using) it between transfers allows to do multiblock transfers, including combined WriteCmd+ReadData transfers.

Some bits have only the purpose described, but not what they are doing on which specific value. Ie. many people only say "enable flag", and forget to say "1=enabled", or just say "length", but forget to say "in bytes" or "in bits".

For FIFO status, it isn't clear to me if it refers to Read-fifo, or Write-fifo, or both. I guess DMA is handling that stuff automatically. But for manual transfers, I am a bit lost how it works. For reading, there should be also a fifo empty flag? And what is the fifo size? And if the transfer length is less than the fifo size, does the fifo ever get "full"?
With the current description, it sounds as if reading would work as so:
- If fifo=full then read one word (or up to as many words that are known to fit into the fifo).
- If transfer=done then read any remaining words (even if fifo isn't full).
Not so sure if I am right there.

Timeout for AUTOPOLL brings up many questions (although that nasty details aren't sooo important).
There seems to be a pair of brackets missing in the "Tries = 31<<Baudrate + Timeout" formula?
If one wants to know the timeout duration, then one would compute "Duration=Baudrate*Time/Baudrate"?
Something like "Duration=Time" would be easier to read. Or is the baudrate technically relevant in that formula?
Of course, for the full formula, "Time" would be replaced by be something like "Duration=(xxx*(2^n)) microseconds".
If "Tries" means number of bytes (?) then I would assume that 4bit mode will cause earlier timeouts than 1bit mode?
EDIT: That is, if 4bit mode can be used for AUTOPOLL at all (most SPI FLASH chips are likely to support 4bit only for data transfers, not for mere status reads).
EDIT-EDIT: Or, if tries consists of command AND status bytes, then one try would be worth 16bits, perhaps with a small pause for toggling chipselect?

Small detail: "bit offset" is a bit confusing, "bit number" might be clearer.
EDIT: Ah, or is it the offset in respect to the transfer order, ie. 0 = first bit (MSB)?

A link/note on the card pinout would be also nice... the 3dbrew Pinouts page doesn't mention game cards, but I fould them mentioned here: http://www.3dbrew.org/wiki/Gamecards

PS. I've had troubles testing R/W for BLKLEN and INT_MASK. It seems that they become read-only(?) during active transfers (ie. when starting a transfer via CNT or AUTOPOLL registers). If there's no transfer, then they are R/W... and INT_MASK is 4bit wide (not 3bit).
The glitch with the lower 8bit of CNT appering shifted to upper bits didn't occur for me yet. Are you sure about the bug, and have some info how to reproduce it? And if lower 8bit are shifted... does that mean that bit0-7 are then read as zero, or do they still contain the intact value, too?

Posted: **Sat Jul 27, 2019 12:29 pm**

I've started doing 3DS memory allocation in no$gba & adding support for load firm files (for viewing them in the disassembler). My first attempts crashed because some firms load to VRAM and DSP RAM. Here's some run-down commonly used & unsupported areas:

Code: Select all

Common FIRM Load areas are:
  08006000h 0.9M  ARM9-WRAM  (common for ARM9 code) (not first/last some bytes)
  18000000h 6.0M  VRAM       (eg. used by GBA/DSi firmwares)
  1FF00000h 0.5M  DSP Memory (eg. used by FIRM0, initially mapped to ARM9 side)
  1FF80000h 0.5M  AXI RAM    (common for ARM11 code)
With that areas, a FIRM file can be max 7.9Mbyte (if it is loaded as file, the
default size of the firm0/firm1 partitions is only 4Mbyte each).
There is a blacklist in bootrom preventing some memory regions:
  07FFB800h..07FFFBFFh  ARM9 ITCM part (otp, mbr, keys...)
  FFF00000h..FFF02FFFh  ARM9 DTCM (first 3000h) (arm9 data)
  FFF03000h..FFF03FFFh  ARM9 DTCM (last 1000h) (arm9 stack)
  080F8000h..080FFFFFh  ARM9 WRAM (last 8000h) (rom card related?)
  08000000h..0800003Fh  ARM9 WRAM (first 40h) (exception vectors, etc)
  20000000h..27FFFFFFh  FCRAM (whole 128MB)
  FFF00000h..1FFFFFFFh  Bugged (size of that area is negative/nonsense)
Moreover, the bootrom doesn't have Main RAM and New3DS memory enabled. And, the
bootrom PU has also disabled some memory areas (though those might pass when
using DMA for loading?).

Okay, with VRAM being 'officiallly used', I should really support that in wifiboot, too. It's already (almost) working because the code is loading firm sections to a temp buffer in main ram; the part that needs to be changed is to wait with the final code relocation until vram is no longer used for video output.

The ARM11 FIRMs are surprisingly starting with a seemingly undocumented opcode: F10C01C0. I could only find out that this opcode is said to be called "CPSID IAF". Plus some blurb on the syntax & parameters: http://infocenter.arm.com/help/topic/co ... hfdbhd.htm but that doesn't describe the binary opcode encoding. I have docs for other ARM11 opcodes like WFI or CLREX. But that CPS thing seems to be hard to get by : /
Does somebody know docs for that?

PS. I mean for ARM mode. The encoding for CPS in THUMB mode is officially documented.

Edit: ~~Found it, https://developer.arm.com/docs/ddi0597/ ... e-pe-state (if the page isn't showing all 32 bits of the instruction: there is an invisible scrollbar for viewing the remaining bits).~~ Of course that link is blocked for win9x browsers, but I've found a pdf that can be download (though not viewed) under win9x, but I have somehow got the text extracted from it:

DDI_0597_ARM_a32_t32_instruction_set_architecture.pdf wrote: CPS, CPSID, CPSIE
Change PE State changes one or more of the PSTATE.{A, I, F} interrupt mask bits and, optionally, the PSTATE.M mode field, without changing any
other PSTATE bits.
CPS is treated as NOP if executed in User mode unless it is defined as being CONSTRAINED UNPREDICTABLE elsewhere in this section.
The PE checks whether the value being written to PSTATE.M is legal. See Illegal changes to PSTATE.M.
It has encodings from the following instruction sets: A32 ( A1 ) and T32 ( T1 and T2 ) .
A1
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
1 1 1 1 0 0 0 1 0 0 0 0 imod M 0 (0) (0) (0) (0) (0) (0) (0) A I F 0 mode
CPS (imod == 00 && M == 1)
CPS{<q>} #<mode> // (Cannot be conditional)
CPSID (imod == 11 && M == 0)
CPSID{<q>} <iflags> // (Cannot be conditional)
CPSID (imod == 11 && M == 1)
CPSID{<q>} <iflags> , #<mode> // (Cannot be conditional)
CPSIE (imod == 10 && M == 0)
CPSIE{<q>} <iflags> // (Cannot be conditional)
CPSIE (imod == 10 && M == 1)
CPSIE{<q>} <iflags> , #<mode> // (Cannot be conditional)
if mode != '00000' && M == '0' then UNPREDICTABLE;
if (imod<1> == '1' && A:I:F == '000') || (imod<1> == '0' && A:I:F != '000') then UNPREDICTABLE;
enable = (imod == '10'); disable = (imod == '11'); changemode = (M == '1');
affectA = (A == '1'); affectI = (I == '1'); affectF = (F == '1');
if (imod == '00' && M == '0') || imod == '01' then UNPREDICTABLE;

Looks like crap, but it should be enough to decode the opcode. I just wished to be back in the days of 14kbit modems where information was blocked less strictly for older OSes. Or well, I guess I was just a teen with a brandnew PC those days.

Posted: **Mon Jul 29, 2019 2:05 pm**

Hmmmm, there are still unknown instructions popping up in the FIRM disassembly. But I think I might now have the relevant datasheets.

ARM DDI 0100I - the "Preface" lists new "ARMv6" opcodes (versus older ARMv5TE and ARMv5TEJ)
ARM DDI 0360F - the "Intruduction" lists new "MPCore" opcodes (versus the above ARMv6)

Are that the right two documents for figuring out differences between ARM9/NDS (with ARMv5TE) and ARM11/3DS?

Going by the above docs, Jazelle bytecode is automatically supported in all ARMv6 processors. Or are there are any ARMv6's that are excluding that feature? The instruction set name should be then something with "xJ" suffix to indicate excluded Jazelle support.

ARMv6 with the "MPCore" extension does probably also has an instruction set name? Ie. some one-letter suffix appended to the "ARMv6" string?

There is something called "ARMv6-M", but that is apparently referring to Cortex-M, unrelated to the MPCore stuff.

Posted: **Wed Aug 07, 2019 9:33 am**

nocash, is there a special dumper you used to dump the WiFi ROM? I have started working on WiFi stuff in my 3DS emulator, and I'm running into problems with the handshake protocol - NWM hangs after I send a WMI_READY reply when it does a WMI_SYNCHRONIZE command. So I'd like to see what's different on the 3DS firmware + ROM.

Posted: **Wed Aug 07, 2019 2:14 pm**

a way you could go would be recording the data from BMI_LZ_DATA commands to a file, then decompressing that. the compression looks ass-stupid, but I'm not sure whether I got it right.

getting it disassembled and all is another deal tho. I found an IDA plugin for the Xtensa arch, but not sure whether it can be applied to this use case, as it looked rather specific.

otherwise, I figure you can abuse WINDOW_READ shito to dump the wifi memory. not sure there's homebrew code for using this wifi device (on the DSi side, libnds has nothing for it, and dswifi is for the old DS wifi device), but, libnds has a SD driver which is used for SD/NAND access, you can probably hijack that and change the base I/O address and have a working base for talking to the wifi device.

Posted: **Wed Aug 07, 2019 3:29 pm**

Yes, WINDOW_READ_ADDR and WINDOW_DATA can be used for dumping the ROM (and RAM, including the decompressed firmware, if it is already uploaded to RAM). The wifisdio.a22 file in wifiboot contains code for that (and also for SDIO init that you may need before using WINDOW_DATA). I've used some dirty/hacky unreleased wifiboot variant for getting the dump transferred to PC, I should still have the code if you need it, or else you could use whatever other method (like writing the dump the SD card).

The WMI_READY_EVENT contains the firmware version (and this is one of the things that are sent by the RAM firmware, not by the ROM). On 3DS, the event data is 10h-bytes in size (unlike DSi), and the firmware version number mentioned in gbatek (=230000B3h) is for a fairly old NWM version, your NWM is probably newer, and might require to send a newer version number. The version number does also differ on which of the three firmwares you have uploaded (ie. for the firmware with the "Mac Filter" feature, it would be 230000D8h instead of 230000B3h). You can probably find your version in the somewhere in the decompressed firmware... it's most probably 230000xxh.

I would have thought that WMI_SYNCHRONIZE would occur a bit later than WMI_READY_EVENT, but that might be timed a bit differently in NWM versus DSi Launcher (which doesn't use SYNCHRONIZE at all as it's only uploading the firmware). Anyways, the initialization should look as so: BMI commands, then a handful of "weird" handshakes (that are neither BMI nor WMI commands), and then the WMI stuff, with WMI_READY_EVENT and WMI_REGDOMAIN_EVENT, and then (I think thereafter?) WMI_BITRATE, WMI_FRAMERATES and WMI_SYNCHRONIZE etc.
Btw. There are also SDIO logs from DSi browser (in the "DSi Wifi rev-engineering" thread), maybe some of that data is helpful for 3DS, too. Ah, and the DSi wifi-firmware upload... that can be logged in no$gba when having SD/MMC(=and SDIO) logging enabled in the TTY Debug Message window.

Posted: **Wed Aug 07, 2019 5:48 pm**

The instruction set for ARM11 mpcore is ARMv6K. It isn't really mentioned in the mpcore docs, but it's mentioned here: http://infocenter.arm.com/help/index.js ... CDJCJ.html The new opcodes are mentioned to exist in the mpcore docs, but not described how they work, I think the only resource for that is peeking at the ARMv7 (or newer) architecture reference manuals. Fortunately there are only a few new opcodes in v6K (SETEND, CLREX, STREX/LDREX-with-new-B/H/D suffix, and the HINT opcodes (TrueNop, YIELD, WFE, WFI, SEV). And, they are all ARM-only (there were no new THUMB opcodes added in v6K).

I've meanwhile implemented all new opcodes in my assembler/disassembler.... disassembling FIRM isn't so much fun though : /
The New3DS FIRMs have that self-decrypting ARM9 code, that won't stop hacking, but it's a bit distracting.
The Old3DS FIRMs are a bit easier to get by. But even there, it looks as if some ARM9 code gets relocated (to other ARM9 addresses? Or ARM7 addresses?) after loading - so absolute addresses in the disassembly don't match up with initial load addresses.
Hmmm, and the ARM9/ARM11 code in the GBA FIRM file seems to lack some important things like I2C bus access. There is a .code file inside of the GBA FIRM file - does that contain the "missing" code? Or does the GBA FIRM even load further code/modules from other eMMC folders?

Going for some easier (plain hardware) stuff... here's some new info on the GPIO registers:

Code: Select all

10147000h - GPIO_DATA0_DATA_IN (R?)
  0       Unknown (0=?, 1=Normal) HID-sysmodule, HID PAD state  ;\GPIO services
  1       Unknown (0=?, 1=Normal)                               ; bitmask 7h
  2       Hinge (0=Shell Open, 1=Shell Closed)  (IRQ:60h/62h?)  ;/
  3       Unused?
  4       Unused?  ;"Only used by Boot11" (uh, but bootrom tests only bit2)
  5-15    Unused?

10147010h - GPIO_DATA1_DATA_IN (R)
10147010h - GPIO_DATA1_DATA_OUT (W)
10147011h - GPIO_DATA1_DIRECTION (R/W)
10147012h - GPIO_DATA1_IRQ_EDGE (R/W)    ?
10147013h - GPIO_DATA1_IRQ_ENABLE (R/W)
  0       gpio:CDC Headphone (0=None, 1=Connected) (IRQ:64h) ;\GPIO services
  1       Unknown (0=?, 1=Normal)                  (IRQ:66h) ;/bitmask 18h
  2-7     Unused

10147014h - GPIO_DATA2_DATA_OUT (R/W)
  0       gpio:MCU, gpio:NWM: Wifi?     ;-GPIO services bitmask 20h
  1-15    Unused

10147020h - GPIO_DATA3_DATA_IN (R)
10147020h - GPIO_DATA3_DATA_OUT (W)
10147022h - GPIO_DATA3_DIRECTION (R/W)
10147024h - GPIO_DATA3_IRQ_EDGE (R/W)    ?
10147026h - GPIO_DATA3_IRQ_ENABLE (R/W)
  0       gpio:CDC, gpio:IR                         (IRQ:68h?) ;\
  1       gpio:IR             Boot11(uh, really?)   (IRQ:69h)  ;
  2       gpio:HID                                  (IRQ:6Ah?) ;
  3       gpio:HID, gpio:IR   used with ir:rst.     (IRQ:6Bh)  ; GPIO services
  4       gpio:IR send?  1=IR LED enable, 0=disable (IRQ:6Ch)  ; bitmask 3FFC0h
  5       gpio:IR receive?                          (IRQ:6Dh)  ;
  6       gpio:NFC                                  (IRQ:6Eh)  ;
  7       gpio:NFC                                  (IRQ:6Fh)  ;
  8       gpio:HID  HID-sysmodule, HID PAD state    (IRQ:70h?) ;
  9       gpio:MCU      (with interrupt 71h)        (IRQ:71h?) ;
  10      gpio:NFC                                  (IRQ:72h)  ;
  11      gpio:QTM   (Twlbg? and/or New3DS?)        (IRQ:73h??);/
  12-15   Unused (0)

10147028h - GPIO_DATA4_DATA_OUT_WIFI (R/W)
  0       gpio:MCU, gpio:NWM: Wifi Enable (1=On) ;-GPIO services bitmask 40000h
  1-15    Unused (0)

10147100h - Legacy RTC ?
Normally only 10147100h.bit15 is R/W, and the other bits/registers at 101471xxh
are all zero. But reportedly they can contain this...
  10147100h 2  RTC_CNT (?) ???
  10147110h 1  RTC_?       ???
  10147111h 1  RTC_?       ???
  10147120h 4  RTC_RAW     Byte-wise bit-swapped (bit7 is bit0, etc.) BCD RTC
                            (byte0 = seconds,
                             byte1 = minutes,
                             byte2 = hours,
                             byte3 = day(?))
  10147124h 4  RTC_?       RTC offset?
  10147130h 4  RTC_?       ???
  10147134h 4  RTC_?       ???
  10147140h 4  RTC_?       Some sort of byte-wise bit-swapped seconds counter
  10147150h 1  RTC_?       ???
  10147151h 1  RTC_?       ???
  10147160h 4  RTC_?       ???
  10147164h 4  RTC_?       ???
That is, apparently related to the "ARM7_RTC_xxx" registers at 100181xxh.

I haven't verifed the IRQ edge selection (but it's very most likely same as on DSi). Verified is switching the ports to output-direction with irq-enabled, and then toggling the data value - doing that (bit by bit) is triggering ARM11 interrupts. Except, the IRQ numbers with question marks didn't trigger (probably just because external hardware did hold the gpio pin at a fixed voltage).

Posted: **Sat Aug 10, 2019 12:52 pm**

nocash wrote:I would have thought that WMI_SYNCHRONIZE would occur a bit later than WMI_READY_EVENT, but that might be timed a bit differently in NWM versus DSi Launcher (which doesn't use SYNCHRONIZE at all as it's only uploading the firmware). Anyways, the initialization should look as so: BMI commands, then a handful of "weird" handshakes (that are neither BMI nor WMI commands), and then the WMI stuff, with WMI_READY_EVENT and WMI_REGDOMAIN_EVENT, and then (I think thereafter?) WMI_BITRATE, WMI_FRAMERATES and WMI_SYNCHRONIZE etc.
Btw. There are also SDIO logs from DSi browser (in the "DSi Wifi rev-engineering" thread), maybe some of that data is helpful for 3DS, too. Ah, and the DSi wifi-firmware upload... that can be logged in no$gba when having SD/MMC(=and SDIO) logging enabled in the TTY Debug Message window.

I see where my confusion comes from now. It's not sending WMI_SYNCHRONIZE, it's sending that weird handshake after BMI_DONE.

I'm not sure where WMI_REGDOMAIN_EVENT comes into play. It receives my WMI_READY_EVENT, and WiFi init completes as per the open-source Atheros driver, but NWM hangs after that. What is supposed to be sending WMI_REGDOMAIN_EVENT? Is it another handshake command, or does it immediately follow WMI_READY_EVENT? I tried to send WMI_REGDOMAIN_EVENT 1 million cycles after WMI_READY_EVENT, but it didn't change anything.

nesdev.org

3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering

Re: 3DS reverse engineering