-
Notifications
You must be signed in to change notification settings - Fork 545
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Request] Boot into a title with TitleID in "tid" file, if exists #779
Comments
I have a better idea about the buttons: Instead of B, use L to skip it and delete it. And use R to use it but not delete it. |
Yeah, that's better. |
👍 |
This could be a way to skip the Home menu on boot and go straight to a game, or boot whatever is on the flashcard (how the DS used to), or if you want to, go straight to the Homebrew Launcher on boot. |
I think that having to rely on writing and reading a file potentially on every boot is not a very elegant solution & it is not good for the SD card. I would try to find another place to place the tid/mediatype in that persists after a reboot (but not a shutdown) |
write it to nand |
It's not good for NAND either. |
Isn't NAND written to, whenever the 3DS is used/booted? |
+1 with fincs here, please don't. |
At the very least it should be an option & implemented for 3DS titles as well. The problem is that you need to boot into a different memory mode on O3DS... |
Perhaps ITCM/DTCM? However, that can't be accessed from ARM11... I don't know. |
Seems like an arm11 version of the boot9strap build that had bootonce support... |
Since I'm assuming this would only be used in a reboot and not coldboot, why not read it into RAM from some other place, and manipulate it from there? Perhaps it can be stored on the TWLNAND partition if it is used after exiting TWL_FIRM. |
Actually writing that to ITCM should be fine if you find a safe location. Don't unnecessarily write to the SD card. Small files like that which are often written to are not good for the flash. |
Yeah, seems like writing to and reading from NAND on every reboot a little more than it already does would just wear out the NAND quicker than usual. Hopefully there are super safe locations in RAM where something like this could be stored, which would help with the idea of it only being a reboot thing and not a coldboot thing. A little bit of research shows that some areas of memory aren't wiped on reboots (but obviously are lost after a shutdown and are empty on a coldboot), so maybe we could hide it in one of those regions? |
Closing, tracker cleanup |
I thought of another way an app like TWLoader can be booted after exiting TWL_FIRM.
Luma should boot into a title with TitleID specified in a file called "tid" if the file exists, instead of the HOME Menu, then the "tid" file can be deleted after it's read.
For example, if an NTR/TWL-mode homebrew app wanted to boot an app like Face Raiders, the app can write it's TitleID in the "tid" file, then attempt to reboot into HOME Menu, but if the "tid" file is found, it'll boot Face Raiders instead of the HOME Menu.
Also, "tid" file can be skipped and deleted, and HOME Menu will boot, if B button is held.
The text was updated successfully, but these errors were encountered: