[Enhancement] - Resized file-based emuMMC

[Leerz]

1. SDmc Partitioning screen could use a little enhancement if we add + or - buttons on the side along with the scroller
2. Allow Trimmed SDfile Emummc (ie, manually set size instead of using the installed emmc size)
3. would it be good to Set loading screen/Splash screen to Launch menu with the BL configs

[CTCaer]

1. They do not fit. And if I make the bar smaller to fit them, the unalignment will trigger me. (Which will force me to add more code in order to have a container and align minus and plus at sides, so more work.)
   A more appropriate and real reason is that there's no need for precision. (And it's real, unlike my preference to choose powers of 2 for sizes)
2. Yeah I should add that at some point.
3. If I get that right, you mean take the autoboot config, read its bg and apply it there? If so, nope. What's the point even?

[Leerz]

1. They do not fit. And if I make the bar smaller to fit them, the unalignment will trigger me. (Which will force me to add more code in order to have a container and align minus and plus at sides, so more work.)
   A more appropriate and real reason is that there's no need for precision. (And it's real, unlike my preference to choose powers of 2 for sizes)
2. Yeah I should add that at some point.
3. If I get that right, you mean take the autoboot config, read its bg and apply it there? If so, nope. What's the point even?

Appreciate the response, and you're right.

1. I understand your decision for this, it just drives me nuts and it triggers me too not being able to hit 11 or 12gb on linux and android partitions since i could not hit the number too precisely , not a big deal :)
   ---perhaps making emummc partition allowed to be 32/29 gb on oled instead of always having it 58/64gb for rawnand

2. yay

3. ahh reason for this was for it to work like that of a windows/grub/ boot selection screen, the choices are there without interrupting the splash with vol- but will auto-select after the set bot delay. not a critical thing, but more of a nice to have

thank you for taking the time to review this and greets from MLA / PH :)

[Leerz]

another thought.
4. another enhancement to make an initialized emummc upon creation, perhaps a toggle on/off if it's a clone or an initialized one, meaning user partition would be blank/formatted, this could make emummc creation faster.

[Leerz]

hello again! sorry for bumping

Update on point 2 — I've been messing with this on my fork from a different angle.

Tried to add a "Fast Mode" option that shows up when creating a raw emuMMC on a full-size SD partition (where resized mode doesn't apply). Basically reuses the existing resized flow but at full size — system partitions get copied normally, USER gets same treatment as a trimmed emummc, GPT and MBR rewritten with recalculated CRCs, nand patrol cleared. Same code path as resized, just substituting emmc_storage.sec_cnt where resized uses resized_count for the size math:

u32 user_sectors = (fast_mode ? emmc_storage.sec_cnt : resized_count) - user_offset - 33;
i tested it and it's faster my 10-15 mins
it skips the USER 1:1 read from eMMC, which is the bottleneck — USER gets formatted right after anyway (on my workflow) so copying it from eMMC is wasted time. ~20 min down to ~5 on a 32GB.

Used resized_count == 1 as a sentinel value so I didn't have to change the function signature — real resized counts are always above 0x803000 so no chance of collision.

Only shows up on full-size partitions (resized_cnt == 0), resized and default 1:1 modes are unchanged. Scope is 3 files: fe_emummc_tools.h (sentinel define), fe_emummc_tools.c (the fast mode branch), gui_emummc_tools.c (the prompt).

Tested on a couple Switches, emuMMC boots fine, and Initialize Console in HOS settings completes clean at 100%.

Would you be open to a PR for this, or is there a cleaner way you'd prefer to see it done? thanks!!!

[CTCaer]

There's already partition based backup that bundles system partitions and user partition separately.

And you can do exactly this. Backup the partitions (and skipping USER) and then later restore these and do any of the factory reset options (full or game data).

HOS normally doesn't care if USER data mismatch, as long as you don't try to run a game.

[Leerz]

There's already partition based backup that bundles system partitions and user partition separately.

And you can do exactly this. Backup the partitions (and skipping USER) and then later restore these and do any of the factory reset options (full or game data).

HOS normally doesn't care if USER data mismatch, as long as you don't try to run a game.

Thanks, i'm aware of that, , however, that is a backup feature.

I was referring to the emummc creation itself.

[CTCaer]

I reread the whole convo and nope.

What you are trying to do for 4. (not 2.) is an imaginary issue (aka lazy user type of thing as I call these nowadays).
There's no point to that. You don't do this everyday.
And if you do, you still need to delete game data or initialize, so you don't gain much.
(You hunt via data management, and factory reset does a full write on USER).
Just get a better sd, it should take around 9-10min for 32GB with the cheapest proper one. Or just abort it when it reaches USER on existing emummc.
Also, reminder that the USER format on resized is not by choice, it's forced because of limitations. It's not a "feature".

As for 1. the -+ are even less needed btw in recent versions. I fixed the knob alignment and now it's precisely placed under the finger (it would offset near the sides before).
For 2. I still consider adding resized file based when I have time for it.

[Leerz]

I reread the whole convo and nope.

What you are trying to do for 4. (not 2.) is an imaginary issue (aka lazy user type of thing as I call these nowadays). There's no point to that. You don't do this everyday. And if you do, you still need to delete game data or initialize, so you don't gain much. (You hunt via data management, and factory reset does a full write on USER). Just get a better sd, it should take around 9-10min for 32GB with the cheapest proper one. Or just abort it when it reaches USER on existing emummc. Also, reminder that the USER format on resized is not by choice, it's forced because of limitations. It's not a "feature".

As for 1. the -+ are even less needed btw in recent versions. I fixed the knob alignment and now it's precisely placed under the finger (it would offset near the sides before). For 2. I still consider adding resized file based when I have time for it.

thanks for responding,
sorry yes i think there's a misunderstanding on my part, i should have just made a new post instead.

yes it isn't the same as point 2 anymore, i was working on within those lines, that's why i phrased it being as something else from my last bump.

i understand that the value on skipping user is not being seen, but for a shop owner that does several devices a day and working on customer devices with varying sdcard speeds. emummc creation speed matters in operation.

yes it gets formatted anyway in my workflow, but the workflow would be halved in time for my end, because the user partition is not copied 1:1
the data does get formatted, so there was no point for me to copy the whole user partition. that was the whole point of it.
emummc creation full can take 20-30 minutes (longer even on slow cards/yes it's not a 1bit mode issue),
formatting takes just as long.

if it only were as simple as replacing the card, everything would be simpler, there are factors to consider (customer's budget to pay). a sandisk ultra class 10 or those a1's could get slow after a year of use (from bad wear leveling).

i understand that there are TRICKS to cut the emummc creation time by forcefully closing the switch mid process, but that's inelegant, risks breaking the sdcard. this is the reason why i added the path to create an emummc creation fast mode,
works almost exactly as a resized emummc, and took the ", it's forced because of limitations. It's not a "feature". way as A feature. to correct the partition.

as for 1 (plus and minus) thank you! this is not needed now, the clamping effect on the drag works 100% better.!
as for 2, might still be a good option but you are right, this doesnt have a huge impact, some people still use the sdfile based emummc and swear to its performance / some users also say the wear leveling on sdfile based cards arent as bad as the ones that use sdRAW, but i cannot see a direct implication as to why that is. it's really just sandisk class 10's and a1's ultras.