Can the console charge in hekate?
Yes but it seems to not charge as fast as it does in horizon.
Can the console charge in hekate?
At a very slow rate, less than idle power drain. Battery goes down in RCM mode while plugged in.Can the console charge in hekate?
Only use FAT32.the black boxes ,can seem to get them to pop up no more , only the fancy GUI now?.. anyway to get them back on newer custom firmware?..
also couple questions..
I'm on sysNAND : 6.2.0
then AWS emuMMC 7.0.2
using exFAT partition right now.. -( but i heard this has many issues, or can create them?)..
I'm trying to figure which is better and smoother for playing games on the switch on the formats listed above *between FAT32 and exFAT* .. but most of all, i just want to really know which is more stable..
or does this exFAT format or both??, become more stable on higher *Custom-firmware(s)* u go on here?...
okay great, could u possibly guide me through putting back from exFAT to FAT32 so i don't accenditally brick my console , also could i just Transfer my stuff to microSD card when after i format to fat32?..Only use FAT32.
I keep seeing people say this, but other than a vague "exFAT is bad" I haven't really seen anyone yet say why. I've been using exFAT with my Switch since day one and I've only ever had it show up as "dirty" once which was fixed simply by running chkdsk and this was almost definitely caused by pulling out the memory card before the system was truly fully shut down (mostly back before the recent Atmosphere update when it didn't actually shut down once you hit power off.) I've been using FAT32 since the day it first came out and over the years several times I've lost entire file allocation tables with the secondary table being woefully out of date and significant portions of data being lost in the process and once I even basically lost everything as the secondary FAT was basically empty. (And yes, I know the data was still technically there and via a long, convoluted process I could have restored it all, but unless there is something just incredibly important in there it usually isn't worth it so back then I just ended up reinstalling and all.)Only use FAT32.
FAT32 is recommended. Do what you want.All you have to do is copy and paste the files onto something else -- a USB drive for example -- via your computer, reformat just that partition (make sure not to use something like the SD formatter that would repartition the whole drive -- a partition manager such as but not limited to MiniTool Partition Manager can do this pretty easily if you want something you can be sure won't erase that emuMMC partition) and then copy the files back over. No matter how you do this you absolutely cannot brick your console. Your worst case scenario is just if you messed up the layout of the memory card you'd lose the emuMMC and installed games -- which sucks, but isn't a brick. If you really want to be sure, you can backup your emuMMC via Hekate or any partition imager on a computer (even just dd in *nix is fine) before messing with the formatting. BTW, it's a LOT of files if you have very much installed (Nintendo splits stuff up a lot, plus a few things like RetroArch just simply use a lot of files if you have it.) Count on it taking a long time. Your mileage may vary, but you might get slightly faster results from making an archive (eg zip, rar, etc) instead of copy and paste if you set it to not compress or to compress very very little (so there is no significant CPU or memory bottleneck) and then extracting that to the new partition after formatting.
As for which is better, I don't think you'll see much of a real speed difference either way. Supposedly exFAT is more optimized towards modern flash drives, but I doubt it makes much difference on an embedded device like this. Your biggest speed advantages will come in making sure the partitions are properly aligned and that you use a 32KB cluster size (64KB may be better, but supposedly some things have problems? That may all be solved by now though. I don't think it makes a huge difference anyway, so 32KB should be fine for fairly optimal results.) The main advantage of exFAT versus FAT32 is large file (>= 4GiB) support and a supposedly better handling of improper removals (though in practice it may be about the same really.) The main disadvantage is... I don't actually know what it is in this specific context beyond that people will fuss at you if you use it.
I keep seeing people say this, but other than a vague "exFAT is bad" I haven't really seen anyone yet say why. I've been using exFAT with my Switch since day one and I've only ever had it show up as "dirty" once which was fixed simply by running chkdsk and this was almost definitely caused by pulling out the memory card before the system was truly fully shut down (mostly back before the recent Atmosphere update when it didn't actually shut down once you hit power off.) I've been using FAT32 since the day it first came out and over the years several times I've lost entire file allocation tables with the secondary table being woefully out of date and significant portions of data being lost in the process and once I even basically lost everything as the secondary FAT was basically empty. (And yes, I know the data was still technically there and via a long, convoluted process I could have restored it all, but unless there is something just incredibly important in there it usually isn't worth it so back then I just ended up reinstalling and all.)
I'm not saying FAT32 is bad and exFAT is better nor am I really saying the opposite -- in fact it really kind of feels like each has its ups and downs and overall they're closer to even. FAT32 is better supported in open source software and the like but older and more limited whereas exFAT has >=4GiB file support and is just generally more modern all around. In fact, the main evil of it is mostly just its sheer proprietary nature and the ridiculous licensing SD Association does that costs companies so much money that they do messy stuff like what Nintendo did for instance. But this is a specialized application, not your daily driver across multiple USB flash drives or something of that sort, so whatever is most optimized for the needs of the application matters more than principle here. (Plus Nintendo has already dealt with the licensing stuff and that isn't our problem. This isn't like some Kickstarter where they simply can't afford to pay it or something.) I know some early homebrew did have troubles back when it basically tried to do stuff on its own, but does any at all today? Homebrew has already come a long way since the early Switch hacking days.
If people are going to say this over and over, at least they could provide a reason.
Well, thanks for the answer. Though I still disagree with that as I've found that the backup table in FAT32 is unreliable at best anyway. Frankly, as far as I'm concerned, that secondary FAT is virtually worthless. In an emergency you might be able to restore a few things, but generally the conditions that cause the first to fail make the second so damaged that you have to start over anyway. What we REALLY need is a proper journalizing filesystem, but I suppose there's no way that can happen. It's sort of too bad when you think about it. If Nintendo had used, oh, say, EXT4 and just simply setup a UMS connection (or even MTP or that photo protocol, whatever it was called) when plugging it into a PC or something of that sort it would have been pretty much just as effective for their intended use scenarios (which is pretty much just transferring stuff like screenshot images or videos to a PC.) Plus they wouldn't have had to pay SD Association a single dime extra beyond whatever bare minimum licensing might be (if any) involved it having a microsd slot.It's because HOS doesn't properly terminate file access or something and can leave handles hanging open when the program (homebrew, in this case) doesn't shutdown properly, or something. I'm not an expert, it's something i read a long while ago somewhere in a discussion between CTCaer and SciresM, i think.
This eventually leads to file table getting corrupted, since exFAT has only one file allocation table (insted of the two redundant ones for FAT32) and it can't be corrected from a backup table.
It's a slow and erratic process and doesn't always have to be immediately noticeable, when less-used file parts get garbled somewhere. But eventually it hits something important and errors will pop up.
Never had issues with exfat so far on my sd card..
It does.Does Hekate work with the last revision?? that one being 8.1.0
Yeah just take a full backup now (don't forget BOOT0/1 as well as rawnand). Any backup is good for in case anything goes wrong in future. If you ever want a "clean" nand for online etc, deleting stuff now wouldn't help, but you could use the method to build a new nand based on your backup.I got excited after I received my RCMLoader One and proceeded to get to where I have NSPs installed and forgot to do a backup first
What should I do to make a backup now? Do I just do the backup as usual or do I have to delete some stuff?