GodMode9 bootloader mode

[Wolfvak]

Should the GM9 bootloader mode remain? The way it currently works is that whenever it's booted from a FIRM partition, it enters a special mode where it looks for files in specific hardcoded paths and tries to boot those - similar to how b9s loads from "sdmc:/boot.firm", for example.

Since we're recommending people to use fastboot3DS, it'd be nice to move some of the boot complexity over to a third party app. GM9 always initializes the screens, too, so it might look ugly to have your screen flash for a small time while the payload is booting, whereas fb3DS only initializes them when it's necessary.

What is being discussed here:

• Should the GM9 bootloader mode be removed? It's perfectly viable to just put fb3DS in FIRM0 and store the GM9 FIRM somewhere else, that way we always get access to GM9 on command if necessary.

What is NOT being discussed here:

• The FIRM booting functionality is not going to be removed - this is what allows a user to launch any arbitrary FIRM file (as long as some sanity checks pass on said file). You'll still be able to boot them, since it's a pretty important part of 3DS hacking (ntrboot_flasher, OpenFirmInstaller, others)

[Wolfvak]

Since I'm the one who originally suggested this, I suppose I should put forth an argument or two:

1. A bootloader should be fairly simple and auditable - it cannot crash under any circumstance. GM9 is a very complex beast, and it can crash/hang for seemingly "random" reasons (most of the time it turns out to be a badly formatted o damaged SD card) that are very difficult to debug. It's almost impossible to debug them if GM9 is the first thing that runs.

2. Currently GM9 always performs screen init on boot and doesn't turn off the LCD panels, and it looks very non-stock. This can look plain ugly at times, especially for users with very large SD cards (>64GB), where booting can easily take ~15 seconds or even more.

3. IMO It's very much out of scope - GM9 is a file manager with a ton of file format management utilities that are essential to the 3DS (CIA, FIRM, etc.) and a few that are useful in general computing (text viewer, hex editor). We already have FIRM booting functionality, but having it run on boot time without user intervention sounds like something that shouldn't be done by GM9.

[ghost]

First of all, I really do not like the push for FB3DS.

1. The config files are saved on the "3ds" folder on the SD card, which means that once you change your card you have to configure. It also mandates another folder (and other FIRM files) on the SD.
2. Screen init does not matter. When you boot, the screen is blank anyway.
3. It is never out of scope. GM9 is like the UEFI menu. You want it to be as versatile as possible.
4. If the NAND is corrupted, you can still boot up GM9 on FIRM0, and restore a backup.

My suggestion is to keep the code as is. If someone decides to use GM9 as the bootloader, they are smart enough to understand.

[fox8091]

@pthfdr-42
Regarding point 1, that's just plain wrong. fb3ds supports config on NAND. Point 3, GM9 is a file manager first and foremost. It's not "like the UEFI menu". The readme directly states that GM9 is a file manager. And for point 4, there is no way that NAND can be corrupted in such a way that GM9 as FIRM0 would still work while rendering other solutions such as b9s or fb3ds as non-working. GM9 as FIRM0 would still require a working SD to restore the NAND, and any SD big enough to hold a NAND backup can also hold GM9.

[Wolfvak]

Point 2 has been brought up a few times by users and I have to agree it's not that big of a deal but it still looks ugly.

About point 3, usually the UEFI menu doesn't actually include all these features in a single ROM, but rather dispatches separate binaries to perform subtasks (such diagnostics, upgrades). This is analogous to how we can boot FIRMs, even those that are embedded into the initial RAM disk. Besides, so far I've never seen an UEFI BIOS that can perform partitioning/filesystem formatting...

[ghost]

I am against removing features because "it is niche" or "no one uses it".
Just look at GTK3 and the compliants regarding to various deprecations.

[ghost]

I have already stated in the original issue, you can just keep the code there and skip the test (and claim that boot via GM9 is unsupported). Do not force advanced users to use fb3ds (since it is another FIRM).

I have seen many projects removed features because of "support issues". I hope that GM9 is not yet another one.

[fox8091]

@pthfdr-42 You can't just "leave it as is", it requires active maintenance. Especially with the rest of the codebase being restructured (such as #625).

[ghost]

All right... it seems that it is unavoidable.
Then maybe you should have a separate branch and a release before removing the bootloader.

[urherenow]

Or you can simply click 1 button and fork it yourself. Nobody is stopping you. Or you can simply build the current branch and not delete it from your computer.

[d0k3]

Oh well. Keep in mind, this is not decided. We explicitely asked the users on their opinion in the last release notes. We honestly didn't expect the bootloader to be important to users, cause there are better alternatives. We will think about that for a bit. Maybe simplification of the code is also an option.