loader: Support memory mode override configuration between hardware reboot

[R-YaTian]

The configuration is loaded from a file at startup and can be updated via custom command 0x101.
This provides a viable solution for issue #1862:
The NS module writes the content of cmdbuf[6] to offset 0x400 of the Firm Launch parameters so that the device can write it to 0x1FF80030 during boot.
However, when the NS module performs the auto-boot mechanism, it reads the target program’s exheader, compares the program’s memtype with the value at 0x1FF80030, and if they don’t match, the NS module will reboot again using the program’s memtype.
So we not only need to pass the expected appmemtype to the NS_RebootToTitle function, but also temporarily patch the exheader of the auto-boot target application. This way, when the NS module performs the comparison, we can “trick” it into launching the target application with our desired appmemtype. See also: devkitPro/libctru#592

[TuxSH]

Hi!

The configuration is loaded from a file at startup

Not a huge fan of this at all - why is this needed and why this location? Are there examples where something calling 0x101 is not sufficient?

In any case I've merged the libctru commit

[R-YaTian]

Hi!

The configuration is loaded from a file at startup

Not a huge fan of this at all - why is this needed and why this location? Are there examples where something calling 0x101 is not sufficient?

In any case I've merged the libctru commit

A series of tests have shown that simply calling 0x101 is not enough to change the appmemtype of a program via auto-boot if its exheader does not already configure appmemtype value other than 0. This is because the original g_memoryOverrideConfig only resides in memory during runtime, but changing an application’s appmemtype requires a full firmware reboot (eg: change to old3ds mode3 type), at which point the contents of g_memoryOverrideConfig are lost.
I also believe that reading a file during loader initialization and then writing it back after responding to an IPC command is a very dirty approach. However, aside from this, there doesn’t seem to be any other way to change an application’s memtype (without re-implementing the NS module). The main reason is that the official NS module code always checks and compares the kernel’s memtype against the application’s memtype.

[R-YaTian]

Closed since this is not a necessary change and also not a good solution.