Choosing A for poweroff is not a good idea. Very quickly pressing A makes that tool actually work.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.
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: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).
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#L134nocash 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 will hang if all the ARM11 cores don't enter wait for interrupt state. The part where it changes it is line 123.
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.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).
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