Skip to content
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

Add EmuNAND support for TWL_FIRM, other related fixes #1696

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

aspargas2
Copy link
Contributor

@aspargas2 aspargas2 commented Dec 5, 2021

This pull request fixes reading sector 0 of most EmuNAND configurations (I wrote about that in more detail in #1687), fixes a minor bug in the exception display code, fixes loading certain old TWL_FIRM versions as external firms, adds support for handling arm9 exceptions in TWL_FIRM (mainly just useful for debugging other patches), and adds support for patching TWL_FIRM Process9 to use EmuNAND.

EmuNAND and exception support was tested on the Old3DS TWL_FIRM versions introduced in 3.0, 3.1, 4.0, 4.4, 4.5, 6.0, 6.2, and 11.8 and on the New3DS TWL_FIRM versions introduced in 8.1 and 11.8 (thanks to @ItsPizzaTime1501 for help with some of that). I'm pretty sure that covers all TWL_FIRM versions since 3.0, but let me know if I missed one. Here's a build of commit e5fb94d for anyone who'd like to do additional testing or just use these features.

It should be noted that this only affects NAND interaction done by TWL_FIRM's Process9. Once control has been handed off to devLauncher and the launched TWL app, SysNAND will be used as usual. To have TWL mode fully functional without any reliance on SysNAND, which was my original goal, NAND redirection patches for devLauncher would be required in conjunction with the changes in this PR. I intend to eventually try to create such patches, but for now I think the closest thing that exists is this.

@@ -77,15 +77,15 @@ void locateEmuNand(FirmwareSource *nandType)
if(!sdmmc_sdcard_readsectors(nandOffset + 1, 1, temp) && memcmp(temp + 0x100, "NCSD", 4) == 0)
{
emuOffset = nandOffset + 1;
emuHeader = nandOffset + 1;
emuHeader = 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've cherry-picked 56e44a6, could you please rebase?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -1,5 +1,5 @@
.section .large_patch.emunand, "aw", %progbits
.arm
.thumb
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain the rationale behind this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mentioned this in the commit message for 6ffef91 but I guess I should've explained more prominently: the free space region in kernel9 used for the emunand patch is too small in the TWL_FIRM kernel9s from firmware versions 3.0 and 3.1 to fit the old patch, so I ported the patch to thumb mode to make it fit.

I don't remember exactly how small the free space is in those versions or by how much the old arm-mode patch didn't fit, but I remember trying to cut down the size of the patch while keeping it in arm mode, and I was almost able to get it small enough, but I had to resort to some pretty ugly-looking hacks at that point, and it was still 4 or 8 bytes to big. I didn't see a strong reason to not just use thumb, so I just used thumb.

If you'd like me to go find the exact numbers for all this I can do so, it'll just take a little while for me to find it.

@NightScript370
Copy link
Contributor

Although I understand that retail DSiWare will still load their data off their NAND due to the lack of patches, will your commit (de7d576) allow us to install homebrew that do not rely on NAND (nds_hb_menu) only on EmuNAND, or would they also need a SysNAND installation as well (as per current requirements)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants