so do the raw emmc size depands on what i have on my switch (like if used 10 gb it will be 10gb) or it will always be 32 gb regardless of what i have downloaded on my switch
thanks for helping
thanks for helping
I'm all sorted now with my NAND backups. So many problems caused by a fake SD Card that I should have recognized far sooner.
I didn't want to believe I had an expensive crummy card. SanDisk customer service had me read the numbers on the back and confirmed they did not manufacture it.
The bright side is it was exactly this NAND backup process that let me figure out I had a bad SD card sooner than later, as I probably wouldn't have verified the memory without all the NAND validation errors.
The .bin write was very fast this time. maybe 15 minutes? the verification took about 45 minutes, I believe.
I ended up compiling and using the version with all the latest commits from 2018-jun-27, and I think some of the speed was because I now have a proper high speed SDXC and not some rip off card.
I am eager to see some of the work from NAND restore. While very dangerous for many users, I think this is one of the most important fail-safes in the scene right now.
I believe that people who dump a nand before using any CFW, stay offline, and restore their NAND prior to taking OFW back online will keep off the ban list.
Pros and Cons exist of course, but still important work.
Thanks for your continued development in this area, CTCaer!
I didn't want to believe I had an expensive crummy card. SanDisk customer service had me read the numbers on the back and confirmed they did not manufacture it.
The bright side is it was exactly this NAND backup process that let me figure out I had a bad SD card sooner than later, as I probably wouldn't have verified the memory without all the NAND validation errors.
The .bin write was very fast this time. maybe 15 minutes? the verification took about 45 minutes, I believe.
I ended up compiling and using the version with all the latest commits from 2018-jun-27, and I think some of the speed was because I now have a proper high speed SDXC and not some rip off card.
I am eager to see some of the work from NAND restore. While very dangerous for many users, I think this is one of the most important fail-safes in the scene right now.
I believe that people who dump a nand before using any CFW, stay offline, and restore their NAND prior to taking OFW back online will keep off the ban list.
Pros and Cons exist of course, but still important work.
Thanks for your continued development in this area, CTCaer!
Is it possible to add simple step by step instructions on your github readme.md how one can use this to enable homebrew launching?
New version v3.0 released!
OP's guide was updated to reflect all the new changes.
Check OP for more info about changes and features. For even more info, check repo's commit history!
OP's guide was updated to reflect all the new changes.
Check OP for more info about changes and features. For even more info, check repo's commit history!
Last edited by CTCaer,
- Joined
- May 28, 2018
- Messages
- 645
- Trophies
- 0
- Location
- Barstow, on the edge of the desert
- XP
- 1,884
- Country
As long as you don't boot the OFW you should be fine, otherwise I wouldn't risk it because nintendont could easily check if that pin is grounded or not (even if it is in a floating/undefined state if not pulled to ground).
- Joined
- Jun 24, 2007
- Messages
- 12,037
- Trophies
- 3
- Location
- In the Murderbox!
- Website
- www.twitch.tv
- XP
- 16,225
- Country
No, that's what I have a primary console for. My 3.0.0 hasn't been used before and will be hacked once I feel the time is right.
It could be implemented in hekate if you provide the files in sd card.
But overall I don't know if the IRAM constrains will allow that. (Current injecting methods) allow only for a ~123 KB payload.
We'll see..
A chainloading capability?I'm always open to nice suggestions.
One small binary with the very basic stuff like hw init, FatFS + some chainloading logic. This one gets injected by a fusee loader.
An other binary blob with all the hekate-ipl features that you offload onto your sd card and which gets auto loaded by the first binary if it is detected on your sd card.
So if we have a DIY fusee loader device (a Trinket M0 for example) we only have to flash it once. If you want to update hekate, then all you have to do is to replace the bin located on your sd card.
This would be an awesome solution for internal modchips.
This would also make an other cool feature possible. If there is no sd card inserted or there is no hekate/cfw stuff on it, the console resets and boots the ofw. This would prevent you from ever booting into horizon with a inserted sd card with homebrew stuff on it.
Does this make any sense? Is it doable?
Similar threads
