Godmode9: System Info as in Decrypt9

[Jisagi]

As the title already tells, some kind of system info page as in decrypt9 would be really nice to have. Especially to help people debugging their problems or helping in general a few of the provided data in D9 were very helpful.
Possible data to show:

• id0/id1 sd path
• existance of an emunand
• entrypoint
• serial
• region

[AnalogMan151]

• id0/id1 sd path: Can be shown via scripting variable. echo $[SYSID0]/$[SYSID1]

• Existence of emuNAND: If SYSID1 is not "Unknown" or if drive E exists, emuNAND is present.

• Entry point: What entry points would like you like supported? If you're booting from NTRBoot, you'd know it, if you're booting from B9S GodMode9 acts normally and if you install it as FIRM it acts as a boot loader unless a key is held during boot, making it also obvious which boot method you're using.

• Serial: Already present in the Home > More... > System Info screen.

• Region: Already present in the Home > More... > System Info screen.

[Jisagi]

Ok, i wasn't aware that the id0/id1 part is visible via scripting, but that's not the point i was adressing.
I forgot that serial and region where in the already existing sysinfo and it would be nice if the initially mentioned date were also in there.
I know on what to look when i need to know if i have an emunand but helping people on discord is way easier when they have everything on one or two screen. Then they can just make a screenshot and we can get all necessary information.
Same applies to entrypoint. Rather than just debugging multiple thing with multiple steps a one page info would be a hell of a lot easier.

[d0k3]

Okay, I already added some more info to the system info feature, but right now in a branch and thus not reachable for the common user.

As for entrypoint - fully agreeing with @AnalogMan151 here. Seriously, someone loading GM9 from an entrypoint other than a FIRM payload (OldLoader, FIRM0 install, NTRBOOT) knows about that stuff. It's not like you accidentially switch to one of these not very noob friendly entrypoints. The entrypoint info is also hardly accessible at that point (especially since stuff changed since D9), so, won't be added.

Same for EmuNAND info - you got an EmuNAND / RedNAND if you have a drive 4:, otherwise you don't. Common users (except hardcore GW users, eww) typically don't use EmuNANDs / RedNANDs anymore, so I don't see any much of a point in adding that info (again, at a place in the code where that info is hardly accessible).

[fox8091]

@d0k3 Entrypoint would likely be useful for scripting, and EmuNAND as well. However, I see that it's a lot of work, so feel free to do as you see fit. 😄

[d0k3]

Well... you can detect the EmuNAND in scripting, via the method I mentioned above.

Entrypoint is... ugly. We can safely detect we're not coming from FIRM0/FIRM1 or ntrboot (= GM9 flashed to card), everything else is wonky. GM9 does a decent job at boot, but doing it again at a later point is basically asking for trouble (have a look at the source if you want to know why). I may look into the entrypoint thing nonetheless if you can give me a usage scenario that makes sense.

EDIT: In addition to the above. The reverse of the above is not true - we cannot safely detect we're actually coming from FIRM0 / FIRM1 or ntrboot. It's basically all heuristics.

[fox8091]

Honestly, I can't think of a reasonable one off the top of my head, but couldn't you just store the entrypoint to a (C) variable and then expose it via a scripting variable?