I know that feel bro [emoji14](Trying to copy files without using C printing functions hurts my brain...)
I know that feel bro [emoji14](Trying to copy files without using C printing functions hurts my brain...)
I managed it in the end. It was ridiculousI know that feel bro [emoji14]
I've put checks in along the way to see whether things like write operations were successful, but they only return their success or failure once the operation has been attempted.Just wondering: what kind of risks are there with this project? Im full aware the installation has the same risks as installing a9lh, but I more mean the settings that write to the ctrnand. Does changing those types of things risk brick at all? Even with unlikely situations like an sd read error or god knows what. I just want to know exactly what Im getting into. I dont really understand a9lh on a technical level, just the basic idea of it.
Thanks for such a detailed response! The last paragraph pretty much nulled 90% of my fears. As excited as I am for this, I will be waiting for a stable release, since this will be installed on my majoras mask console and I dont want to take any unnecessary risks. I have been watching this thread multiple times a day and it just gets better and better! Really glad you didn't give up when you had trouble gaining NAND access. This project is exactly what I have been looking / asking for since I first learned of 3DS hacks! Please keep up the FANTASTIC work!I've put checks in along the way to see whether things like write operations were successful, but they only return their success or failure once the operation has been attempted.
Having said that, the actual risks with regard to CTRNAND write operations are pretty much the same as they would be if you were writing to a memory stick or SD card. Although SysNAND seems scary, it's actually just flash memory with encrypted FAT partitions. Once they're decrypted, writing to them is technically the same as copying a file to a memory stick.
If the write were to fail, the risks are that the file being written would be corrupted. Like with any storage device, the filesystem (in this case FAT) takes care of writing the file to the correct place, so a failure should result in only that file becoming corrupt.
In theory I suppose it is possible that a catastrophic failure could corrupt the filesystem or overwrite the wrong part of the filesystem, but I can't think of any situation in which that would happen, and the likelihood of such an event would be the same as if you were copying the files to a memory stick.
In short, the SECOND most dangerous thing about installing 3DSafe is the process of installing it, and thanks to SafeA9LHInstaller that's pretty safe. The MOST dangerous thing is that because this is pre-release software, so it hasn't been tested by a large group of users yet (AFAIK). I use it constantly so I'm pretty sure that there's nothing devastating in terms of bugs.
One final point to make, is that writing to CTRNAND is a different part of NAND. Even corrupting CTRNAND should leave A9LH alone, so you should always be able to boot Decrypt9 and restore a NAND backup should the worst happen.
No worries buddy! I'm glad you're excited about this project. If it helps, as long as you have a NAND backup there's actually no way you can permanently brick your 3DS. The very worst case scenario if you did somehow brick is that you would have to send your 3DS off for hardmodding so you can re-flash the NAND. Hard modding costs very little and there are several trusted members here who can do it for you.Thanks for such a detailed response! The last paragraph pretty much nulled 90% of my fears. As excited as I am for this, I will be waiting for a stable release, since this will be installed on my majoras mask console and I dont want to take any unnecessary risks. I have been watching this thread multiple times a day and it just gets better and better! Really glad you didn't give up when you had trouble gaining NAND access. This project is exactly what I have been looking / asking for since I first learned of 3DS hacks! Please keep up the FANTASTIC work!
It's a full Luma payload with the config loading/saving removed and hard coded to boot SysNAND. I understand about not wanting to write large files to NAND many times, but I have never heard of limited read cycles on a NAND. If that were the case then simply booting the 3ds would eventually wear out the NAND. Realistically the emergency payload is a 42kb file which only needs to be written to NAND once, so it's really not going to damage your NAND.May i ask what is an adapted luma payload? Does it mean a stripped down version of luma without all the extra features, just like what luma's a9lh fork used to boot without an sd?
Or is it a full luma cfw? I heard aurora did not want to include the full luma in the nand because it can cause unnecessary wear to the nand chip, since it has a limited of read and write cycles.
Also, if the pin is removed, will it boot straight into the home menu, much like stock a9lh? If yes, how do you go to the options?
And if not is there an option to disable options menu from popping up each boot?
ThanksThe no-SD boot it was I waited for,good work,I'll wait for the stable release ,once is uploaded I'll install it right away!
Keep up the good work!
I don't know if I can check for the home button but I'll look into it. If not, would a d-pad key be ok? I don't think Luma uses it for switching payloads.I love that work, if it become a stable release I will install it (:
But, like it's mentioned here, will be there an option to boot straight into arm9loadhax.bin (mostly Luma) if PIN is toogled to OFF?
and show options-menu only if you want it - that would be awesome as hell ^^.
(But key combo is not good at all, cause if you use Luma3DS payloads...but what is, if ..and only if you press/hold Home-Button at boot/power-on
it shows the options Menu of 3dsSafe? Is that even possible..because the Home-Button doesn't have any effect at all at this early boot-stage or?)
He's fine, thanks buddyHope the dog is ok
NANDs have thousands of rewrite cycles, maybe more. Updating this a few times isn't going to contribute significantly to wear on the NAND.Will constantly updating this payload mess up 3DS' Nand? Should I wait for a final release?
It's a full Luma payload with the config loading/saving removed and hard coded to boot SysNAND.
I tried SaltFW but it wouldn't boot. It worked if I put the payload on SD card and booted it from 3DSafe that way, but once it was on NAND, it just hung on a black screen when I tried to boot it. Luma worked, so I used that.Can I use any a9lh payload? It seems like SaltFW is perfectly suited for this.
Is there any reason you made that modified Luma payload instead of just using an existing minimal CFW like SaltFW?
Yes, it's stored on CTRNAND so it can boot without the SD card.This emergency payload is copied into the CTRNAND filesystem, right?
I tried SaltFW but it wouldn't boot. It worked if I put the payload on SD card and booted it from 3DSafe that way, but once it was on NAND, it just hung on a black screen when I tried to boot it. Luma worked, so I used that.
Yes, it's stored on CTRNAND so it can boot without the SD card.
I do agree that waiting for more testing to be done is wise. I'll be asking for confirmation from testers shortly so I can confirm that it works in a range of devices and regions.Wow, thanks for the prompt response!
I'm a little uncertain about installing a prerelease a9lh fork that hasn't been so rigorously tested, as the last thing i need is another bricked 3DS, but 3DSafe seems like it's bringing a lot of useful features to the table.
I kind of have to wonder now why ShadowNAND decided to implement its miniCFW all in the stage2 payload rather than just booting it out of a binary in CTRNAND. ShadowNAND's approach seems like a lot more work for less functionality.
Anyway great work, and cheers I look forward to making the most of this software.
Thank you for the reminder. I completely forgot about about this. I'll add it asap.@mashers Just a reminder, weren't you going to add instructions for people installing from a9lh v1? I'm pretty sure the only difference is that they would need the file aeskeydb.bin at the root of their SD, since v1 didn't use it, but I don't see that anywhere in your guide.