Hekate won’t recognize my 1T Lexar sd card formatted by GUIformat with 32k allocation size(FAT32).

[Galel]

It would give the “ Missing LP0 library! Missing or old Minerva library! Update your bootloader folder” error when injected, even with all the required files in the bootloader folder updated.

When formatted to FAT32 by GUIformat with 64k allocation size, everything seems working extremely well so far.

[Masamune3210]

what happens if you let hekate format the card itself?

[CTCaer]

You should stop using guiformat already. It has major bugs that doesn't seem that they will fix them any time now. Use a proper partition manager or hekate to partition/format.

[Galel]

what happens if you let hekate format the card itself?

I haven’t tried that before, thanks for mentioning that.

[Galel]

You should stop using guiformat already. It has major bugs that doesn't seem that they will fix them any time now. Use a proper partition manager or hekate to partition/format.

Thanks for your reply. Just a small question though, is it okay to just leave my card formatted by GUIformat with 64 cluster size? Dose 64k allocation size affect something?

[Masamune3210]

Just format it with hekate if you want peace of mind

[Galel]

Just format it with hekate if you want peace of mind

Thanks for the advise! I’m just curious about whether the allocation size plays an important role. Does it affect homebrew compatibility or something else? What’s Hecate’s default cluster size when formatting a 1T card? Thanks for your patience!

[urherenow]

The answer is that not all cards are exactly the same. Some work better with 32k, and some with 64k. GitHub is for development collaboration and actual bug reporting, not a help forum. This issue was already closed anyway.

[CTCaer]

That info is incorrect btw.

For FAT32 you use 64KB no matter what. Except if used in phones that have issues when cluster is not 32KB.

For exFAT depends on card size. 128KB (for 128GB and lower) or 256KB (for 128GB and up) cluster. (Yeah 128GB is defined 2 times because both sizes are fine for it.)

hekate always uses FAT32 64KB, along with other tricks to increase performance up to 30%.

[urherenow]

Unless you are referring to Hekate, and only Hekate, you are wrong, not me. Gamecube, for example, always uses 32kb clusters.

https://www.techwalla.com/articles/what-cluster-size-should-be-used-when-making-large-fat32-partitions

and m4xw completely disagrees with you too. Should be 32k, not 64.

https://gbatemp.net/threads/best-cluster-size-for-fat32-64gb-sd-card.531059/

Now that I think about it, you might be the reason I think some people say it works better with 64. Sometimes I absorb information without a filter. It's a curse.

[CTCaer]

You have no clue on what you are talking about.

Any article that suggests 32KB on FAT32 is also clueless and bases that info on 90's/2000's tech and expectations. Back when storage on cards was so low that big clusters were hurting max stored capacity when many small files were used. Plus that many devices had compatibility issues with non-32KB clusters because of bad drivers.

Also referencing a console that doesn't natively use a FAT filesystem anywhere...

Next time make sure you did actual research, like benchmarking tests, and not reference some bs blog. Even Microsoft's own suggestions are wrong with today's standards. They still use the same values as in 1996.

As for @m4xw he can say who actually told him back then what's the best cluster for fat32. (hint: FATFS driver, sometimes, had issues with higher or lower clusters than 32KB. That was fixed in 2018, but m4 didn't know that.)

And lets not talk about the partitioning. Where the whole industry thinks that SD cards are floppy disks or HDDs and never considered actually utilizing the damn SSR register. In my knowledge I only know 2 tools on any OS or other environments that actually format a SD card proper based on AUs. SD Association's official formatter tool and hekate. And hekate goes even further by modifying the FAT data start also.

To sum up: FAT based filesystems like FAT32 and exFAT completely base their perf on cluster size. Each one needs its own value. In single cluster ops scenarios, 64KB cluster can even net you 100% perf gains on read/writes. These scenarios include random read/writes. On scenarios where a small cache (like HOS) is utilized it can net you 30-40% perf gains.

And ofc there are diminishing returns on cluster sizes. HOS (PrFILE2 driver) for example, on exFAT 256KB vs 64KB, can only benefit at best 1-2% on reads and 5-10% on writes.

The only driver that can actually mitigate the issue because of smart and big caching is the Windows driver. And still can't cope on actual random real world scenario or fragmented file ops.

[urherenow]

Thanks for the info, but you're disregarding the fact that not all cards are made the same, and they contain their own microcontroller(s). You're disregarding the many people on gbatemp that fixed their problems by using 32k cluster. And others that seemed happy switching to 64. I know, it's not your fault if some cheap-ass manufacturer doesn't make their card (or fake) compatible with written specifications. But it's a fact that it happens. You know darn well, for example, that for the longest time (and maybe still, I'm not sure the fixes you recently made) that Samsung EVO cards did not play nice with the Switch at all.

https://www.bunniestudios.com/blog/?p=3554#:~:text=These%20algorithms%20are%20too%20complicated,set%20of%20disk%20abstraction%20algorithms.

This is outdated info I guess: https://gist.github.com/joshenders/4376942

but note: "I'm not certain, since I can't find a GameCube disk specification, but I don't think the 32KB cluster size is an attempt to imitate the on-disk storage format of retail GameCube discs; which may or may not be 32KB. Retail Wii discs however, actually DO use 32KB clusters"

So I guess I should have said Wii, not Gamecube. So if Microsoft is under the wrong impression, and Nintendo seems to have the same impression, then... well, I'll just leave it at that.

[CTCaer]

Again wrong. Card capabilities are irrelevant except their capacity. Where a < 4GB card makes sense to format it to 32KB if you want to store many small files. Or where the target platform has a tiny ram and can't fit the cluster. Filesystems are a virtual thing. Aka software. The microcontrollers only help on block level. And if the block count is small they can't do much. It's the reason even the most expensive SD card has garbage read/writes when used with small block count or random read/writes. You are again just randomly spewing stuff without actual knowledge of Nands, their microcontrollers and the MMC protocols. And don't go talking about fake sd cards. That point is automatically invalidated, if someone has common sense.

People that had issues didn't actually fix them because they had random clusters but because they actually properly formatted/partitioned the sd card. I know exactly what issues the SDMMC and FatFS drivers had. And for the record, FatFS doesn't work with out of spec formatted FAT32/exFAT. It immediately asserts on header breakage and spews Error 13 as its "generic" fat error. And that behavior will never change.

Samsung EVO cards did not play nice with the Switch at all

Where do you even base that? Samsung, since start, was the only validated vendor, with every single test, where its cards never had issues with Switch. I actually added UHS support to every single Switch payload, back in May 2018, and know that well enough. Only Sandisks had and specifically Sandisk U1 and every other vendor that used the same microcontroller from Sandisk. These Samsung Evo cards don't even care if you don't power cycle them and just hard init them. You should stop confusing improperly partitioned and formatted cards with actual hw issues.

Basically you are still forgetting with whom you are conversing. The sandisk U1 issues were because their microcontrollers are garbage and the only platforms that had issues on SDR104 were rcm payloads, l4t linux/android and uboot. All fixed by me.

As for the Wii thing you again have no clue. Confusing actual volatile advanced filesystems with simple non-volatile partitions. And these blocks or logical sectors (certainly not clusters), in these cases, are chosen based on the available hardware cache or crypto block size. Like why HOS uses FAT32 and 16KB clusters on eMMC (it uses 16KB crypto "blocks"). And that kills performance even if eMMC has incredible access times, compared to sd cards. eMMC on HOS has 33% total performance loss on reads and 45-71% on writes.

Also Nintendo does not have the same impression. It properly aligns partitions and uses exFAT 128GB for 32GB and up cards, so that point is mute. They partition the cards properly and universally (one scheme fits all, like what hekate does).

If you continue to spew random GBAtemp theories and misinformation, this issue will be locked. If you want to actually learn what is what with the Switch HW and SD cards or why FAT based filesystems are garbage you can just ask or state the theory and ask, without having it as gospel.

[urherenow]

Just based off of my observations. Just google Switch samsung EVO. Some fixed their issues with a full format in windows (exFat) while too many to count just got a different card. This isn't just on temp, it's all over reddit as well.

[CTCaer]

Searching that in google and reddit as site and going through 20 pages of results, these are the findings:

Archive bits: 12
Fake: 4
Sd card reader issue: 3
Trying flashing android oreo disk image bigger than sd: 5

So you just made me lose more time with another misinformation. And it was annoying because the most threads actually suggested these cards.

Now I'm not gonna get into on how easy it is and how to identify the issues or why format works most of the times, because you are clearly unwilling to actually learn something from all that.