Just for basic patches i guess. Not sure.
Even that would be a boon, I'd love to know how to set up a process or thread on ARM11 at some point (I'm hardly a reverse-engineer, so I can only do so much on my own).
Just for basic patches i guess. Not sure.
Oh lol... that 0x20 instead of 0x24 .Ok, i found the issue. The MPU settings patch offset was scewed.. and through some kind of black magic, it was still able to boot, but somehow effected DS stuff lol.. basically deus ex machina happened.
The ReiNand code isn't running at all after firmlaunch, just the thread code which was injected into FIRMLooking at the code, it seems he is patching what is already loaded into the RAM? If so that might be the problem if the patch code is triggering when it loads TWL_FIRM or AGB_FIRM as well.
Oh lol... that 0x20 instead of 0x24 .
The ReiNand code isn't running at all after firmlaunch, just the thread code which was injected into FIRM
What's the status of the bug that makes the 3d effect on a New 3DS not work correctly until you put ReiNand into sleep mode and back out of it again. Is there any way that bug will be fixed or is it just something to live with?
4 cfw teams? i only know 3, rei, cakes and rxtools. what's the 4th?Personally I suspect that the very nature of firmlaunchhax (which is how we run cfw on 9.2) is what prevents this, otherwise I am sure one of the 4 cfw teams would have solved it by now.
4 cfw teams? i only know 3, rei, cakes and rxtools. what's the 4th?
Gateway4 cfw teams? i only know 3, rei, cakes and rxtools. what's the 4th?
How is this throwing @Reisyukaku "under the bus"?someone on the rxTools team basically just threw you under the bus by releasing a nightly build with 9.6+ n3ds emunand support that requires key0x16.bin and key0x1B.bin files and directed people to the fact that your code had the keys hard coded at one point.
How is this throwing @Reisyukaku "under the bus"?
The rxTools update is a quick and dirty hack job they cobbled together using 9.6 NATIVE_FIRM to provide 10.5 emuNAND support (just as @Reisyukaku's was when it was first released).
In the month since, CakesFW, reiNAND and Gateway (in that order) have all released updates to do 9.6+ emuNAND support "properly" by using a 10.x NATIVE_FIRM. rxTools' proper update using 10.x NATIVE_FIRM is listed simply as "later".
rxTools' latest release is a major step backwards for the scene, so I'm not sure how it could be considered throwing rei under the bus. Perhaps our understanding of the phrase differs?
I'm not sure why anyone is still using it to be honest. Using (insert preferred alternative CFW here) and decrypt9 is the superior choice. With rxTools you need to reboot your 3DS to access the eponymous tools, whereas with another CFW all you need to do launch the HBL to run decrypt.
Hmmm that was far more rant-y than intended. Meh. /rant
Good thing I've since switched. No point in waiting around for a team that was handed a CFW, and only since implemented their pasta aspect. Not saying it's bad, but it's overrated at this point. Blah.Was more in reference to the whole "here's your update. Btw you need these two key files that I am not gonna host or give you any info on other than reinand used to have them hard coded in the source."
Anyway, so I take it the ds/gba has been fixed? Sorry, Im stupidly tired at this point.
What dictates a 'proper' way? Im pretty sure you cant even use gateway and proper in the same sentence even. Either way, mine wasnt as hacky as the rx codebase itself is. I just had keys in there. Otherwise, i couldnt agree more with the rest of what you said. I only support this project, and Cakes, and even NTR and the original pasta.. but i cant agree with RXtools.How is this throwing @Reisyukaku "under the bus"?
The rxTools update is a quick and dirty hack job they cobbled together using 9.6 NATIVE_FIRM to provide 10.5 emuNAND support (just as @Reisyukaku's was when it was first released).
In the month since, CakesFW, reiNAND and Gateway (in that order) have all released updates to do 9.6+ emuNAND support "properly" by using a 10.x NATIVE_FIRM. rxTools' proper update using 10.x NATIVE_FIRM is listed simply as "later".
rxTools' latest release is a major step backwards for the scene, so I'm not sure how it could be considered throwing rei under the bus. Perhaps our understanding of the phrase differs?
I'm not sure why anyone is still using it to be honest. Using (insert preferred alternative CFW here) and decrypt9 is the superior choice. With rxTools you need to reboot your 3DS to access the eponymous tools, whereas with another CFW all you need to do launch the HBL to run decrypt.
Hmmm that was far more rant-y than intended. Meh. /rant
Ah okay, I see what you mean.Was more in reference to the whole "here's your update. Btw you need these two key files that I am not gonna host or give you any info on other than reinand used to have them hard coded in the source."
Right you are, I should have put a little more thought into that claim.btw unless there was a major chance to decrypt9 that I missed, you have to reboot and then access the hbl from 9.2 or lower sysnand if you have updated your emunand. The copy of decypt9 I have been using red screens when launched from emunand because its on 9.3.
As you discovered, using 9.6 NATIVE_FIRM meant incompatibility with a few games.What dictates a 'proper' way?
@WulfyStylez recently briefly outlined the reason why this occurs, and the fix her team used to overcome it.What's the status of the bug that makes the 3d effect on a New 3DS not work correctly until you put ReiNand into sleep mode and back out of it again. Is there any way that bug will be fixed or is it just something to live with?
Actually I didnt discover anything.. I thought people were just meme-ingAs you discovered,...
@WulfyStylez recently briefly outlined the reason why this occurs, and the fix her team used to overcome it.
I have no idea if she provided enough information for CFW devs to patch it themselves though.
If svc_backdoor is available before doing firmlaunch, we could maybe use it to do the arm11 gpu/gsp initialisation.She said "at payload runtime", which I'm guessing it's the arm9 payload (all public cfws are basically arm9 payloads). I suppose RE'ing the GSP module (which runs on arm11 I think?) would be needed to understand how it de-initializes the GPU and screen, and replicate it from arm9.