Hacking What does "atmosphere=1" actually do for Hekate?

[AdmiralSpeedy]

I cannot find any actual explanation of what the "atmosphere=1" boot config entry does for Hekate. The readme on the Hekate repo just says "Enables Atmosphere patching" which means nothing to me. I did a search of the entire repo and I can see that Hekate checks this value a few different times in hos, fss, and secmon, but I don't understand what it actually does.

I ask this because I see most current guides omit this line, regardless of how they are booting Atmosphere (fusee primary or secondary), so I'd like to know what it actually does and if it's even necessary.

Honestly, the explanation of a lot of the Hekate configuration file is incredibly vague and I wish it was explained better, because there are several other entries that I don't understand. Part of the problem is the use of completely unexplained acronyms, such as PMU (which based on some Google results that brought up listings for replacement pats, I can only assume means "Power Management Unit"). Another example is "fullsvcperm=1" which is described as "Disables SVC verification (full services permission)". Again, based on some Googling I can only assume this enables access to all SVC system calls, but a bit more explanation of when/why you would/wouldn't want this enabled would be great (I assume it's for developers).

 

[M7L7NK7]

Atmosphere=1 enables the kernel patches that are needed by ams kips

 

[AdmiralSpeedy]

Atmosphere=1 enables the kernel patches that are needed by ams kips

What kips? The only kip patch included with Atmosphere is NOGC.

EDIT: Looking through the Atmosphere source, I do see it loads various kip files but booting Atmosphere without "atmosphere=1" still works fine, so I don't understand what it actually does.

EDIT 2: I think I figured it out after doing some more Googling and re-reading the Hekate config template. I guess the kips are included in fusee secondary, but if you don't use fusee primary or fss0 with fusee secondary, you need to set "atmosphere=1" and manually list the kips to load.

 

[ZachyCatGames]

Atmosphere (specifically ams.mitm I believe?) needs some kernel patches to function properly on Nintendo's kernel, `atmosphere=1` enables said patches (and using fss0 automatically enables it regardless of whether it's present or not and what it's set to)

 

[AdmiralSpeedy]

Atmosphere (specifically ams.mitm I believe?) needs some kernel patches to function properly on Nintendo's kernel, `atmosphere=1` enables said patches (and using fss0 automatically enables it regardless of whether it's present or not and what it's set to)

Makes sense but these leaves me wondering why anyone uses FSS0 over simply chain loading fusee primary? What benefit does this offer? The only thing I can find is a couple Wikis that say "FSS0 is mostly for developers" without further explanation (I don't even know what "FFS0" stands for).

 

[ZachyCatGames]

Makes sense but these leaves me wondering why anyone uses FSS0 over simply chain loading fusee primary? What benefit does this offer? The only thing I can find is a couple Wikis that say "FSS0 is mostly for developers" without further explanation (I don't even know what "FFS0" stands for).

when using fss0 hekate pulls atmosphere's kips, secure monitor, kernel (if experimental shit is enabled), etc out of the fusee secondary binary using information in fusee secondary's header, then hekate boots the system itself.

Chainloading fusee primary... well... chainloads fusee primary, which then chainloads fusee secondary, then fusee secondary boots the system.

Former is significantly faster to boot than the latter, otherwise, once you're in the OS there's zero differernce.

 

[AdmiralSpeedy]

once you're in the OS there's zero differernce.

From everything I've read, it sounds like there is a difference though, just nobody really explains it. The current sigpatches from ITotalJustice actually have two different releases because only one works with FSS0, while the other is intended for those who only boot fusee primary or chain load it with Hekate.

The patch files between those release are actually different, an the FSS0 version include an additional "patches.ini" as well as requiring "kip1patch=nosigchk" to set.

 

[ZachyCatGames]

From everything I've read, it sounds like there is a difference though, just nobody really explains it. The current sigpatches from ITotalJustice actually have two different releases because only one works with FSS0, while the other is intended for those who only boot fusee primary or chain load it with Hekate.

There's literally no difference.

hekate and fusee use difference patch formats, that's why there's two different releases.

 

[AdmiralSpeedy]

There's literally no difference.

hekate and fusee use difference patch formats, that's why there's two different releases.

I think I understand now after looking at the "patches.ini" file again, but I have one other question: The Hekate version of the patches include an "atmosphere" folder with "exefs_patches" and "kip_patches" folders, in addition to the "patches.ini" file. Are those included to be backwards compatible with booting just by fusee primary, because shouldn't Hekate only require the "patches.ini" file and "kip1patch=nosigchk" without all those atmosphere files?

 

[ZachyCatGames]

I think I understand now after looking at the "patches.ini" file again, but I have one other question: The Hekate version of the patches include an "atmosphere" folder with "exefs_patches" and "kip_patches" folders, in addition to the "patches.ini" file. Are those included to be backwards compatible with booting just by fusee primary, because shouldn't Hekate only require the "patches.ini" file and "kip1patch=nosigchk" without all those atmosphere files?

kip_patches wouldn't be used when using hekate, only fusee... no idea why they'd include them.
exefs_patches are applied by the loader sysmodule, not the bootloader.

 

[AdmiralSpeedy]

kip_patches wouldn't be used when using hekate, only fusee... no idea why they'd include them.
exefs_patches are applied by the loader sysmodule, not the bootloader.

I see. All this is so interesting and confusing to me lol (I'm a software developer myself but the Switch scene seems to love vague documentation), but thanks for the answers.