Hacking Homebrew [Beta Release][Tester wanted] Kernel9 patch to speed up boot speed on high capacity SD card

  • Thread starter Thread starter Core_2_Extreme
  • Start date Start date
  • Views Views 12,822
  • Replies Replies 55
  • Likes Likes 25
I have just gotten around to replying to this thread. I have been using this patch for a few months with no issues whatsoever on my N3DS with a 400 GB SD card. Everything works perfectly. It's massively improved boot-up times and booting back into 3DS mode from GBA or DS mode.

I notice this also works when pressing the power button in either GBA or DS mode. No more waiting forever just to have the power off screen shown. You do still get the warning screen beforehand.

I'd also like the ability to turn off the warning in the final version of the patch (or maybe even added to official Luma).
 
As many people don't want to see the warning every time, I've added configuration for it (and clarification in warning message).
The patch itself stays the same as previous release.

 
May I ask to change the config file's name? I use fastboot3DS and boot this patch by default with option to boot stock Luma3DS when I have a button pressed, when I want to install or update something. The problem is that if I enable the option to hide the warning, stock Luma fails to parse the config file and goes into config screen, which overwrites the config file and on the next boot of this patch the warning appears again.
Post automatically merged:

I've made a pull request, since this is a pretty trivial change: https://github.com/Core-2-Extreme/Luma3DS_custom/pull/4
 
Last edited by Yamamoto,
  • Like
Reactions: Core_2_Extreme
Something weird has happened. As soon as I've pushed the amended commit and wrote a comment to the pull request, my (freshly made) Github account apparently got nuked together with the pull request itself. I'm not going to appeal or make a new one, so here is the patch file attached. No attribution needed, do whatever you wish.
 

Attachments

Something weird has happened. As soon as I've pushed the amended commit and wrote a comment to the pull request, my (freshly made) Github account apparently got nuked together with the pull request itself. I'm not going to appeal or make a new one, so here is the patch file attached. No attribution needed, do whatever you wish.
Thank you for providing it, I've pushed it.
 
A stable and reproducible bug: An error occurs when selecting "Save Settings" in the Roselina menu. I couldn't find an issue page on GitHub, so I'm reporting it here.
BA0972AA8B9EBFDFAB23E7918C3FC5D6.jpg
 
  • Like
Reactions: Core_2_Extreme
I've also noticed that the patch still asks to be applied if there is no sd card inserted. I didn't notice any issues, but maybe since it wouldn't be doing anything in that situation, it would just make sense to automatically not apply it.
 
  • Like
Reactions: Core_2_Extreme
I've also noticed that the patch still asks to be applied if there is no sd card inserted. I didn't notice any issues, but maybe since it wouldn't be doing anything in that situation, it would just make sense to automatically not apply it.
It still applies patch and effective if you insert SD card after booting it.
i.e.
Boot without SD card -> reject patch -> insert 2TB SD card in home menu -> take 1 minute to recognize SD card.
Boot without SD card -> accept patch -> insert 2TB SD card in home menu -> take few seconds to recognize SD card.
 
A stable and reproducible bug: An error occurs when selecting "Save Settings" in the Roselina menu. I couldn't find an issue page on GitHub, so I'm reporting it here.
Ok, I fixed it (I just added missing entry in config template).
Next version will include this fix.
 
It'd be cool if free space could be written to (by a module) a txt file somewhere on the SD card during a shutdown and then read on boot in place of scanning the card wholly replacing the FAT read while maintaining a relatively accurate measure of available storage space, but I don't know if this kind of thing would be possible because I don't know how early in the boot process this FAT read happens and if you can simply intercept and interrupt it in this way... 🤔

Either way, this is really cool.
Post automatically merged:

This is an interesting approach, though it is definitely heavy handed. Would it be possible to speed things up by storing the calculated space in a cache somewhere and just reading it from there during boot?

The cache could either be refreshed manually from the Luma3DS menu by the user, or automatically during shutdown. I'm assuming most people don't remove their SD cards every day so this option would keep it up to date well enough for most people.
And if its done during shut down (not reboot, full shut down) it also will likely not matter to people if the thing stays on for a 30s longer before the LEDs turn off, making it unobtrusive.
I'm now realizing I'm not the first person to think of this lol. It's a good idea that may come with its own risks and issues.
 
  • Like
Reactions: Core_2_Extreme
could you use some sort of menu to allow you to compute free space only when you want too and then just use that?
because i would love to have my 3ds know how much free space it has, but to be honest, i dont change my files that often so i dont need to have it always accurate, just sort of.

is that possible?
 
  • Like
Reactions: lightwo
(I fixed it)
could you use some sort of menu to allow you to compute free space only when you want too and then just use that?
because i would love to have my 3ds know how much free space it has, but to be honest, i dont change my files that often so i dont need to have it always accurate, just sort of.

is that possible?
 

Site & Scene News

Popular threads in this forum