Yes, but is mostly still based around emuNAND.does reinand support A9HL ?
sysNAND will use the 10.2 FIRM.
Yes, but is mostly still based around emuNAND.does reinand support A9HL ?
ok , so i am now on 9.2 sysnand and 10.7 RaiNAND emunandYes, but is mostly still based around emuNAND.
sysNAND will use the 10.2 FIRM.
No, both will be restored to the exact same state they were in before the OTP dump.ok , so i am now on 9.2 sysnand and 10.7 RaiNAND emunand
so if i do all OTP thing, it will make my sysnand 10.2 and emunand 10.7 ?
By FIRM, I mean you won't be able to run Decrypt9, etc, on your sysNAND. (Not like it matters, as you can run it with A9LH).ok , so i am now on 9.2 sysnand and 10.7 RaiNAND emunand
so if i do all OTP thing, it will make my sysnand 10.2 and emunand 10.7 ?
ok thanks, i did this guide on my O3DSBy FIRM, I mean you won't be able to run Decrypt9, etc, on your sysNAND. (Not like it matters, as you can run it with A9LH).
Your sysNAND will stay on 9.2 if you so choose.
Why's that? EmuNAND's quite useless with A9LH now.ok thanks, i did this guide on my O3DS
https://github.com/Plailect/Guide/wiki/OTP-Info
and now i can only access AuRaiNAND on 10.7,sysnand is also on 10.7 which i don't want
is there any other guide ? i already have emunand , so i can skip part 1-2 ?
hmm, updating the sysnand in A9LH is safe ?Why's that? EmuNAND's quite useless with A9LH now.
If you don't want sysNAND on 10.7, don't switch your NANDs around.
Yes, updating sysNAND (with AuReiNAND, not just A9LH) is safe. As AuReiNAND blocks FIRM files, which is where A9LH is stored.hmm, updating the sysnand in A9LH is safe ?
i still don't understand how A9LH work.
why temporary? what's the difference with what rei wants to do and this method?That's not directly related to the method Rei wanted to use, but it should be a good temporary solution to those who keep asking for region free.
why temporary? what's the difference with what rei wants to do and this method?
is rxTools using this method that rei wants to implement or does it use this dirty method as well?Because that method is dirty and can be removed with system updates, unless you edit the version number to resist updates, and we don't know what will happen if we start keeping old NS modules around (Home Menu should be fine). It's much cleaner to have unaltered titles on the NAND and then patch them at run-time. I'm pretty sure Rei wanted to make an ARM11 process (basically, it's code that runs in the background) that did region free and such.
is rxTools using this method that rei wants to implement or does it use this dirty method as well?
sorry, didn't catch you well enough there. yes to what rei wants or yes to the dirty method?As far as I understand, RxTools uses a similar method, yes, but RxTools' code is so confusing and convoluted to me that I don't know for sure (sorry for any authors that might read it, but it's true, at least for me).
sorry, didn't catch you well enough there. yes to what rei wants or yes to the dirty method?
Only people I think use the method i was speaking of, is SALT. I just dont really have time or patience for it, lol.. I know some others that are researching it, so i think im gonna take the backseat till they figure it out.. i'm burnt out from doing all my own leg work, lol. In the mean time im working on ctrulib/homebrew stuff and school.is rxTools using this method that rei wants to implement or does it use this dirty method as well?
IIRC, all they do is search FCRAM from ARM9 for the code they want to patch.is rxTools using this method that rei wants to implement or does it use this dirty method as well?
IIRC, all they do is search FCRAM from ARM9 for the code they want to patch.
