Closes#2137.
Even though (when running TWL/AGB FIRM) the SoC is in O3DS mode, and the GPU also is,
as well as most other components behaving as such (external RAM, L2C not usable, etc.),
this is NOT the case for the LCD and adaptive backlight logic which retains FULL N3DS
functionality, including a feature where the window is blended with a given color depending
on the overall relative luminance of that window.
However, Nintendo's own code mistakenly assumes the opposite, and clearly so ("if GPU in N3DS mode"
checks, not passing N3DS extra adaptive backlight (ABL) to TWL/AGB_FIRM). This has implications:
- Powersaving (ABL) settings in TWL/AGB_FIRM is inconsistent with *both* O3DS (because the new RGB blend
LUT has been set to its current value by NATIVE_FIRM) and N3DS (because "pwn_cnt" and "inertia" are missing
their N3DS-only bits)
- "rave party" when booting into TWL/AGB_FIRM or O3DS NATIVE_FIRM without these regs (well, the LUT)
initialized. Easiest way to do so is by leveraging the "DSi autooboot" feature Luma provides. It is worth
noting at least the LUT survives hardware reboots (if Nintendo were using DSi software that was using
TLNC-based reboots, they wouldn't have noticed).
Only touch the autoboot path, for now
For stuff like testing PASLR, *hax2x, khc3ds, etc.
Also fix a corner-case bug when changing the 3dsx app from itself to
itself, if its TID corresponds to the default.
This stubs checks in SvcCreateThread and SvcSetProcessIdealProcessor
that applied when creating threads on core2 and core3. This allows
non-sysmodules to create threads on core3.
Please note, core2 access was already being automatically granted to
3dsx apps for a long time (this is controlled through a kernel flag),
and other apps that needed it had that flag too.
This commit thus changes nothing for all these applications.
Do not create threads on core3 unless you know exactly what you're doing.
On N3DS, gsp (GPU sysmodule) depends on qtm (head-tracking sysmodule) which
runs many threads at very high priority on core3. Running code that needs the
GPU (including printf) on core3 can thus result in thread starvation /
deadlock.
If you just need an extra application core, just use core2 as it is intended
for that exact purpose and is by default completely idle.
Closes#1668
- Stop spamming mcu reads... use the GPIO pin to know if there's a MCU interrupt, instead
- Wait for the MCU interrupts to be raised when powering up LCD+backlights
- Also turn off LCD+backlight when needed
Always display the configuration menu if booted from NTRCARD (because it's painful to get to otherwise -- even if b9s has a 2s delay), with the mention "Booted from NTRCARD" in the title.
