Hacking Guide to choose which Atmosphère patches to use on Switch FW 10+

[Cyan]

The different Atmosphère CFW patches for your Switch Firmwares​

Written by @Cyan and @Itsuki235
Last update: 2020 05 10
Available firmware version as of this guide Last update date: OFW 10.0.2, AMS 0.12.0, Hekate 5.2.1

If a new (custom) Firmware version is available, this guide may become outdated. Use with care and gather compatibility information in other places before proceeding.

This guide has an informative purpose only to help you understand the different patching methods. It only helps you understand and make your choice between other available hacking guides and patches.

Presentation

Since the Switch Horizon firmware v10.0.0 has been released, a lot of confusion has arisen with CFW patches.
This guide will try to explain what happened and what are your current choices for patches.

Seeing how much new forum threads asking the same questions about patches were created these past few days, I wanted to write this guide to explain and help people understand what's happening, what they are using and how to do so. I hope it will be helpful to you.


If you are only looking for patches, go to the patching Atmosphere section or use NeutOS. Links below.

Why do I need a new way to apply patches?

Horizon 10.0.0 moved the ES signature functions from ExeFS to a new "loader" module.
Following that change, Atmosphère implemented a "loader" sysmodule to replicate the functionality. Since ES and ACID check functions for CFW are now in that Atmosphère sysmodule, CFW 10 requires some way to patch that new module if you ever need ES patches to install and play unsigned apps.

Additional Background - The Boot Modes

Before 10.0.0, the patches were applied directly to Nintendo's sysmodules. New patches were required only on new firmware versions.
The patches are now applied to a Atmosphere Loader sysmodule, and therefore will require new patches on each new AMS revision to that sysmodule.

Previous patches were all released in ips format.
That new Loader sysmodule and atmosphere now have to be patched using two different methods:

1. ips patches and/or
2. a custom “loader.kip” sysmodule.

How to apply either of the two patch types above depends on which one of two methods is used to boot Atmosphere.

Update 2020 05 01: Since Hekate release v5.2.0, the "kip" modules can be live patched too, in the form of hekate patches.ini file (not ips). so, new packages could be provided without the kip file.


So you might wonder what are these two booting methods you should use and how to apply the patches correctly. There are 2 different methods to boot into Atmosphere.

1. Boot using fusée-primary
   This is the primary method of booting atmosphere supported by the developers.
   Example1: You send Atmosphère fusée-primary payload directly to the console in RCM.
   Example2: You send Hekate_CTR payload to the console in RCM, which boots Atmosphère using “payload=fusée-primary” functionality.
   The scenario in example 2 is the same way of launching Atmosphère as in Example1, except it's chain-loaded by Hekate.
   
   
2. Using Hekate to boot fusée-secondary
   Hekate can boot Atmosphère by extracting Atmosphere modules directly from fusée-secondary.bin, which can then be loaded or replaced independently.
   Example3: You send Hekate_CTR payload to the console in RCM, which boots Atmosphère using “fss0=fusée-secondary” functionality.
   
   Note that "sending" here refers to using your preferred Fusée Gelée payload sending method with your console in recovery mode: computer(TegraRCM), USB dongle, phone apps, etc.

So the three can be resumed like this :

Send Payload “Fusee-primary.bin” > boot Atmosphere (fusée-secondary)
Send Payload “Hekate” > chain-boot fusee-primary.bin > boot Atmosphere (payload=)
Send Payload “Hekate” > Hekate uses fusee-secondary to boot Atmosphere (fss0=)


A Special Note About EmuMMC and Hekate/Kosmos:
Hekate (and Nyx interface of Hekate) set by Kosmos ready-to-use package lets you choose how you want to boot your console (Stock, SysMMC or emuMMC) directly from its menu. But this choice can only be applied if you launch Atmosphère with fusée-secondary (“fss0=”).

If you have an emuMMC folder or partition and use fusée-primary (“payload=”) method to boot your console, Atmosphère will always follow its own setting to determine whether to use sysMMC or emuMMC regardless of the user choice in Hekate.
While an alternative may be to edit Atmosphere config files to force disable emuMMC and reboot the console, the typical method is to edit “emummc/emummc.ini” and set emummc!enabled=0 or 1. 0 means disabled. 1 Means enabled. You can edit the file yourself, or use existing homebrew directly from your Homebrew Launcher menu, such as emuMMC Toggler or EmuMmcConfig and reboot the payload (fusée-primary).If you use Hekate, you could name your boot choice “Atmosphere” only.


This loss of flexibility and user unfriendliness from Hekate boot menu when using fusee-primary.bin to launch AMS is why Kosmos uses the “fss0=” booting style for syntax.
Using fss0= with fusée-secondary potentially allows for the following boot modes directly from Hekate:

• Stock-like sysMMC
• sysCFW
• emuCFW

This increased flexibility, all in one menu would not be possible if booting using fusée-primary.bin

Patching Atmosphere

The patches you need can depend on which version of the Horizon OS you are launching with Atmosphère (whether it's > 9.2.0 or not), and which Boot method you are using.

FW < 10.0 (e.g OFW ≤ 9.2.0)

If you are booting a custom firmware before 10.0.0, the latest version of the patches also includes the patches needed for older custom firmware. So you don't need to find old packs. The new ips patch pack contains the patches needed for older firmwares too!

This is also true for AMS’s new “loader” sysmodule bundled with AMS v11.0+. It is only used on CFW v10.0.0 or newer so applying newer IPS patches to the newer sysmodle cannot break anything because it does not activate when not needed.

Previously maintained by The-4n here (historical)
Whether you use fusée-primary or fusée-secondary, the patches are the same.
You can also get the patches bundled for FW≥10 fusée-primary as they contain all previous ones.
​

FW >= 10

If booting using fusée-primary payload, with or without Hekate

If you are booting using fusee-primary, you need this subset of the ips patches. Choose one from the available packages

• Raugo (outdated)
  
  maintained by Raugo here.
  
  
• HarukoNX (outdated)
  
  Haruko is also providing the same package, but he called it "Fusée". Even if you are using Hekate to boot primary, do not use the "hekate" package!
  His Homebrew patch downloader will soon be updated to also detect and include the "fusée" package (for fusée-primary boot method). For the moment, use only the manual installation method.
  maintained by Haruko here.
  
  
• lbcap
  
  New maintained thread.
  maintained by lbCap Here
  

If using Hekate/Kosmos to boot fusée-secondary with “fss0=”

For the “fss0=” boot method, The ips patches used by Atmosphère alone are not enough, you need additional patches applied directly by Hekate.

• SDFiles (Still current? outdated or not?)
  
  SDFiles website has a full package of these patches.
  https://sdsetup.com/console?switch
  
  If the website doesn't work, update your Internet browser or use another one.
  
  
• HarukoNX (outdated)
  
  You can find either a package (which he called "hekate") with the files to copy to SD , or a homebrew updater to launch from your console Homebrew Launcher which detects and downloads the exact loader.kip and patches.ini files you need based on your currently installed Atmosphère version.
  
  Since Hekate v5.2.0 released in May 2020, the "loader.kip" module is not included anymore in Haruko package and is replaced with live hekate patches.
  
  maintained by Haruko here.
  
  The pack is not complete (yet) !
  It's missing FS patches for FW < 10.0, only ES patches are present !
  This does not contain ES patches for FW >= 10, only FS and Loader.
  Haruko claimed he didn’t include ES patches for FW≥10 for personal reason, but will eventually add them on a later update.
  
  Special Notes:
  - Bundled Loader.kip (not included anymore since May 2020) and hekate patches.ini files are not working with Blawar’s Tinfoil on CFW 10+ because of personal decision. This forces Tinfoil users to use either fusée-primary with ips patches, SX OS, or NeutOS.
  
  Loader.kip provided here is/was a modded version of Atmosphère's Loader sysmodule, which directly includes/included all the needed patches.
  Loading this modded module requires fss0= boot method in order to extract all kips from fusée-secondary.bin and replace the original with the modded one.
  As of May 1st 2020, Hekate can also patch the extracted kip modules, there is no more need of pre-compiled modded binary kip files. some packages you find on other website, or old packages might still include it. Either a modded kip file or a patches.ini file can achieve the same role.
  
  
• ShadowOne33
  
  new maintained thread.
  maintained by lbCap Here
  
  
  

Using another CFW for Patches

• NeutOS
  
  NeutOS was a fork of atmosphere with the stated purpose of being compatible with tinfoil. NeutOS has been discontinued in favor of ReiNX custom firmware.
  ReiNX has been updated on 2020 May 6th to support FW 9.x and 10.x, and contains all the needed patches to use tinfoil, therefore NeutOS didn't had any purpose on pursuing its support.
  The information here are provided for reference to people still using NeutOS.
  
  
  NeutOS is Atmosphere but with a different bootloader based upon the Shofel2 source code which is implemented in a very similar way to the bootloader used in SX OS.
  
  NeutOS already contains all the needed patches (ES, FS, Loader)
  https://github.com/borntohonk/NEUTOS/releases
  
  
  emuMMC:
  NeutOS "install guide" (provided with each revision's changelog) lets you boot the payload directly from the RCM menu without using hekate, therefore the EmuMMC choice is the same as using Atmosphère with Fusée-primary boot method. It means that you need to edit emuMMC/emummc.ini file to swap or choose between sysMMC or emuMMC!
  if you ever decide to use Hekate to boot NeutOS, be sure to use "payload=" method, not "fss0"!
  
  
• ReiNX
  
  Note: Currently, ReiNX doesn't support EmuMMC ! but this feature will be added quickly in future releases.
  
  If you need tinfoil on SysMMC, use ReiNX
  If you need tinfoil on emuMMC, use NeutOS (discontinued).
  in both cases, you can always use Atmosphère CFW with the Fusée-primary boot method (with primary patches).
  
  https://github.com/Reisyukaku/ReiNX/releases
  

How to change the boot method in Hekate

Atmosphère can be launched without using Hekate, directly by injecting fusée-primary payload into RCM, like officially intended.

If you use Hekate to launch Atmosphère, the boot menu displayed in Hekate can be edited to change the launch method (payload= or fss0=).
Open and edit SD:/bootloader/hekate_ipl.ini according to this: https://github.com/CTCaer/hekate

Guide by @toxic9 : https://gbatemp.net/threads/how-to-hekate-chainload-vanilla-atmos.563255:

Note: This guide uses fusée-primary method to boot Atmosphère, therefore changes the Hekate boot menu to display only two choices : Atmosphere (cfw) and Horizon (ofw).
Whether Atmosphère is booting on sysNAND or emuNAND depends on its own ini file, not hekate anymore.

If you plan to use Fusée-secondary with Haruko patches, you’ll have to keep the emuMMC boot choices from hekate menu, but remember that Blawar’s Tinfoil does not work with that boot method. It will detect and delete the files present on your SD card even if you are temporarily not using fusée-secondary boot method to use Tinfoil.

Hekate and boot method specific FAQ

• Why use Hekate to boot fusée-primary if you can boot Atmosphère directly?
  Even if Hekate is a powerful tool for advanced users, it is used in most hacking guides to perform the initial eMMC backup for safety reasons, and often bundled in ready-to-use CFW packages (such as SDMenu/Kosmos) as a boot menu.
  
  Hekate actually has many uses besides loading Atmosphere and so loading Atmosphere is just one of the many things that it does. Part of the reason to set it as main payload to benefit from all of those other functionalities without having to modify which payload.bin to push initially, such as easily creating and managing emuMMC, sys backup/restore management, launching arbitrary payloads occasionally (like Lockpick_RCM, Lakka, Android, etc.), viewing console hardware information including battery charge status and rate. It can also be used to set up an automatic chain-boot into any other payload present on the SD card, not only atmosphere, such as NeutOS or SX_Loader.bin.
  
  Chained payload can be on SD card and chosen from a menu on the console instead of being sent using Fusée hack (TegraRCM/dongle/android). On your dongle, you can keep Hekate payload and don't need to change it every time you want to send a different payload.
  
  
• What's the differences with using primary or secondary in Hekate?
  Fusée-secondary contains different sysmodules in it (kips files)
  
  - When using fusée primary, all the included kip modules are used. Additional kips files can be added from kips folder, ips patches can also be applied to change some included modules.
  - When using fusée secondary, hekate extracts each module from secondary before loading them independently, and allows the user to replace some extracted kips with any others.
  
  
• Why is this a problem with new Horizon 10.0.0 ?
  ips for loader.kip seems to work only when using the fusée-primary boot method.
  So, based on your booting method, you'll have to find and use different patching files.
  
  
• What is ACID? What about ACID patches?
  For .nsps, an ACID check checks the RSA key in the NPDM ACID section and the checks for the NPDM RSA signature in the Program NCA section.
  Files with valid ACID signatures mean the RSA key is untouched and hence the Program NCAs are unmodified (not altered).
  ACID patches just remove another signature check.
  ACID patches are part of "nosigchk" patches.
  Interestingly, NSPs can be dumped in such a way so as to not require ACID checks, but that would also mean there is no way to validate that they have not been modified.
  
  

General Guide FAQ, Error and help section

• Do I need a new patch every time Atmosphère updates the loader sysmodule?
  YES !
  
  You used to need new patches on every new Nintendo's Horizon OS firmware.
  Now that ES/ACID checks are inside an Atmosphère sysmodule, Every change done to that Atmosphère module will require a new set of patches for that specific Atmosphère version, and not only when Nintendo changes or updates its own modules on new Horizon OS firmware.
  Patches should now be released with Atmosphere version information, for example "2.0.0-10.0.0 for AMS 0.12.0"
  
  if you are on 10.0.0 but with AMS 0.12.1 it will NOT WORK! even if your firmware is matching FS sysmodule of the firmware 10.0.1.
  
  
• Why do you mention Tinfoil and no other apps?
  Blawar’s Tinfoil has very strict requirements and forces users to launch specific configurations so compatibility information is listed here. Other apps do not have arbitrary compatibility limitations so they are not mentioned before now.
  
  Alternative Title installers include Goldleaf, SX Installer and Awoo Installer.
  
  
• Is using NeutOS a good or bad idea?
  
  NeutOS is an unoffical Atmosphère fork and will need to be updated after each new official release.
  It is no different than waiting for ips patches after a new atmosphere release, and at least for now, NeutOS and Atmosphere are still binary compatible.
  Some could argue using recompiled binary sysmodules could be more riskier if no sources are provided (when only the kip is shared without info about its source).
  But that concern can also be applied to ips patches. I am sure very few people actually look at the patched addresses.
  It also comes with added convenience of not having to locate patches every time at the cost of a closed-source boot process.
  
  
  • Pros:
    • Includes all the patches “out of the box”
    • It is Atmosphere and contains all of Atmosphere’s functionality
    • Works with every versions of firmware that Atmosphere supports (10.0+)
    • Works with Blawar’s Tinfoil (subjective)
  • Cons:
    • It is Atmosphere but with some closed source changes to the bootloader
    • dependent on a fork of Atmosphère, not the official release.
    • not clear how long it will be supported for
    • Works with Blawar’s Tinfoil (subjective)
  So basically: Up to you.
  
  
  

More Q/A might be added here based on user's recurrent questions found on GBAtemp.

Disclaimer

This thread is purely meant to be informative. I'm in no way forcing users into using one boot method of CFW or configuration over another!
Users are free to use the booting and patching method they want now that they (hopefully) understand their choices better.

PLEASE DO NOT FIGHT OR ARGUE TO KNOW WHICH VERSION OF CFW OR CONFIG IS SUPERIOR OR START DEV WAR IN THIS THREAD.
Keep it civilized and helpful, answer user's concerns and provide neutral information. Other users only want their titles installed and don't care whether you hate or prefer one developer or one CFW over another!


If you spot any error in this guide, or any new update or changes to mention, please let me or Itsuki know about it.


Thanks
Special thanks to @Itsuki235 for your help on writing and fixing this guide.

 

[C7XL]

This is a great guide, only took less than 10 mins to read and very informative. Hopefully it’ll be updated over time.

 

[Cyan]

Thank you for the comment.
I wanted to keep it short and not give too much side information.

I hope I will have time to update it, if I ever get less interest in doing it I can always provide write access to someone else to maintain it.
Seeing Itsuki helps a lot of users and know very well the subject, I might already give him access as he helped me rewrite/fix few things.

itsuki: I removed one or two things from what you wrote to make it shorter, or less redundant.

 

[chippy]

You should see about getting it pinned

 

[Cyan]

I pinned it, but undid.
I'm not sure pinned threads are really that much read or looked at, (old) users are probably just skipping that part by habits.I thought I let it unpinned for few days.

 

[Itsuki235]

• If anything is wrong blame @Itsuki235
• For anything right, @Cyan takes credit.
• The stuff regarding Haruko's patches still needs to be fact-checked by @HarukoNX .
• Haruko's input when new patches are needed (new atmosphere ver, new loader module ver, new horizon ver) for each patches type (fs, es, acid, loader) would also be appreciated.
• The vandetta moe thing was a joke I inserted in the draft. It is okay to remove those words, ...please?
• The two forks for Awoo Installer are:
  • Awoo-Noir (different theme),
  • Tinleaf (different theme + removes a check that Awoo Installer performed to deliberately break compatability with SX OS, so it now works normally on SX OS).
  • Awoo-Installer also supports removing some of the moe under Options->Remove.
• On Kosmos and using "fss0=" style booting:
  • The sentence that starts with "This loss of functionality" under the Kosmos notes refers to sending fusee-primary.bin to boot compared to "fss0=" boot method (Kosmos uses the fss0= method by default). Being able to present the unique boot options listed there all in a single menu natively in Hekate does require that "fss0=" booting syntax for some of the boot modes.
  • The "fss0=" booting syntax will disable loading of all patches by default, which is why that syntax is not ideal for people trying to load software that requires a lot of patches: fs, es, acid, loader.
  • Remember that Kosmos's objective is to expose all of Atmosphere's functionality and that they do not officially support loading all patches, so "fss0=" functionality complicating the use of patches is not really their problem.
  • Also note that using the "fss0=" syntax for booting -in the [CFW EmuMMC] boot entry only- provided by Kosmos by default is 100% unnessary because it exhibits the exact same behavior as if using "payload=fusee-primary.bin" in that boot entry, and thus needlessly complicates loading patches for that boot entry. Tapping on [CFW EmuMMC] will load CFW SysNAND if no emuMMC is present, and the "fss0=" syntax cannot change or prevent that from happening.
• EDIT: Regarding CSE:
  • Context self enforcement (CSE) is the concept that a piece of software will try to execute, but then detect its environment and refuse to function/disable functionality if the environment it is running in is unsatisfactory.
  • One example would be a valid product key for a piece of software. A software that enforces CSE could disable itself or go into trial mode.
    • From the perspective of the underlying software code, this CSE mechanism unnecessary to perform the intended functionality of the software's code. It could perform its function(s), but the software developer has chosen to disable the functionality in some way.
  • Another CSE reason could be a missing dependency that the software requires to perform a specific functionality X. Without that library, the software could CSE and disable that functionality until that library is present.
    • From the perspective of the underlying software code, this CSE mechanism can be described as necessary because the software code to perform the program's intended functionality is missing. The software developer has chosen to check for this failure case and CSE either the specific feature that requires the currently-missing software library or disable the program entirely (this later case is required if core-functionality libraries are missing).

• Regarding Tinfoil 8.1.0 compatibility and CSE:
  • 100% all of Tinfoil's compatibility limitations are unnecessary CSE because, According to a trusted source, ALL of the compatibility checks can be disabled by having a valid SX OS license.
  • A valid SX OS license is a text file on the SD:/license.dat (or similar) at the root.
  • That text file does not provide software libraries to programs and therefore cannot be said to provide them to Tinfoil.
  • If that text file (license.dat) is present, tinfoil works in every environment that it can launch on and disables all unnecessary CSE.
  • Thus, if Tinfoil CSEs, a.k.a. murders itself/commits suicide, with the "fss0=" syntax, or if SD:/bootloader/patches.ini exists, or if a a custom .kip is loaded, it can be said that CSE is "unnecessary CSE" from the perspective of the software code. The developer simply chooses to disable the software when the software code itself has all the libraries it requires accessible and is running in an environment where the program itself can launch successfully (sigpatches).
  • From the perspective of how the technology works, it is not that "fss0=" style Atmosphere booting, patching.ini loading, kip loading are incompatible with Tinfoil, but rather than that it is Tinfoil's fault that is not compatible with all of those possible configuration choices for Atmosphere. Do not obscure this fact!
  • It is 100% Tinfoil's fault that Tinfoil does not work, not anything related Kosmos or anything else! The CSE not activating on Tinfoil 8.1.0 if license.dat is present proves it!
  • Kosmos does not do anything to create a situation where Tinfoil 8.1.0 cannot work. Tinfoil itself checks for any possible signs of a Kosmos-like configuration and destroys itself!
  • /Edit: I have /not tested/ the fss0= boot method against Tinfoil's context self enforcement code on OFW 9.2.0. Theoretically, it should launch, but then destroy itself (due to detecting SD:/bootloader/patches.ini), so it should be "compatible" per-say but that config is "not useful" due to Tinfoil's CSE code.
  • Opinion: Hekate supporting arbitrary naming styles and loading locations for "patches.ini" would be really cool "cat-and-mouse game" style feature, however Hekate_CTR does not explicitly provide support for fs, es, acid and loader patches, so the dev can argue that such a feature is not their problem/within the scope of their project.
  • For OFW 10+, Tinfoil will load successfully but then CSE if the SD:/atmosphere/kips/loader.kip is present prompting the need to use these loader_patches with vanilla atmosphere (OFW 10+ only) to get Tinfoil to work normally.

 

[Cyan]

I removed the "moe" part.
removing reference to fork of awoo, I don't need to link to them, but having them in your post is good

About "This loss of functionality", that's what I had in mind that it refers to "not using fss0" with menu directly in hekate, but maybe it's not very easy to understand for an external user. I'll see how to fix that, or add your comment.

 

[Itsuki235]

About "This loss of functionality", that's what I had in mind, but maybe it's not very easy to understand for an external user. I'll see how to fix that, or add your comment.

Yes, it was clear from the context, but the word order did not match, which messes up speed reading, so I went ahead and expanded on that to clarify the technical pros/cons of the "fss0=" booting style just in case.

 

[Cyan]

The "fss0=" booting syntax will disable loading of all patches by default, which is why that syntax is not ideal for people trying to load software that requires a lot of patches: fs, es, acid, loader.

It used to work fine with fss0, secondary and ips patches up to 9.2.0
so saying fss0 prevent patches is wrong. It's only affecting the patching of the new AMS loader sysmodule ?
maybe because it used to patch nintendo's module and now it needs to patch AMS' ?

edit:
I changed a little the "loss of ..." sentence.
user don't lose functionalities, AMS still has these functionalities. it's only a loss of flexibility, so I removed the "functionality" word.

edit2:
I looked at Haruko updater's source, and I see it properly checks the current AMS version to find proper patches, it doesn't just "update to latest".
I'll remove "to be confirmed" from the guide

 

[Itsuki235]

It used to work fine with fss0, secondary and ips patches up to 9.2.0
so saying fss0 prevent patches is wrong. it's only affecting the new loader sysmodule ?
maybe because it patched nintendo's module not AMS' ?

What I mean is that it will no longer load them automatically. So loading them is not disabled per-say, but the patches have to be manually specified to load by altering the relevant boot entry in "SD:/bootloader/hekate_ipl.ini".

They do work and patch loading (both IPS and *.kip) is not "prevented" by "fss0=" loading, but does require the syntax that HarukoNX provides in their GitHub repo because the loading is not automatic:

kip1patch=nosigchk
kip1=atmosphere/kips/*

 

[peteruk]

'sticky' would be a good idea

thank for your work on this guide, very useful

 

[tom2199]

• The two forks for Awoo Installer are:
  • Awoo-Noir (different theme),
  • Tinleaf (different theme + removes a check that Awoo Installer performed to deliberately break compatability with SX OS, so it now works normally on SX OS).
  • Awoo-Installer also supports removing some of the moe under Options->Remove.

You forgot Awoo-56709-Installer. It has a neutral theme as well and has no anti-SX code.

 

[MalayZN]

is 10.0.2 okay to update to as well?

 

[tom2199]

is 10.0.2 okay to update to as well?

yes

 

[scandal_uk]

Nice to see the correct info in the correct place, covering as many configs as possible - I like the diplomatic disclaimers at the end too!

Clearly this post won't descend into who's config/loader is the best etc..!

 

[Cyan]

I updated the guide to reflect new hekate and Haruko changes.
HakuroNX package doesn't include the loader.kip file anymore and is replaced with live patches.

He is now also providing a "fusée-primary" package. they seem to be a full bundle (from Raugo and/or other places) with all past and present FW ES/FS patches included, so use either Haruko or Raugo package if using fusée-primary.
His patch updater will also be updated to detect and include these patches, making it easier for everyone with either used boot method.

 

[MassiveRican]

So first off huge thanks to both @Cyan and @Itsuki235 for their concise, informative guide and breakdown. I now better understand what my options are, with a little extra searching I was able to see understand what FS & ES patches do as well.

I like to do many things, such as boot into clean Stock (no CFW), emuMMC CFW, Lakka & L4T Ubuntu/AndroidOS switching SD cards when necessary. So I'd like a bit of input as to which may be the best way to achieve what I want to and be able to boot into Tinfoil as well. I'd like to confirm if what I'm thinking may work but with the CSE that Itsuki235 explained I'm concerned it would give me problems regardless since I've experienced the Homebrew input problem in the past due to Scires/Blawar not umm.. being on the same page to say the least.

Current setup: Using Hekate 5.1.1/Kosmos on Firmware 9.1.0|AMS|E

So let's say I update to 10.0.2 and continue using Kosmos/Hekate, so I could boot into Lakka/Android/EmuMMC, would I be able to chainload into NeutOS with "payload=" to use tinfoil? Maybe not I'm thinking since atmosphere build provided by NeutOS is different to begin with, and according to Cyan "Tinfoil does not work with that boot method. It will detect and delete the files present on your SD card even if you are temporarily not using fusée-secondary boot method to use Tinfoil." Which to me is freaking crazy! Are you saying it will delete the kosmos/hekate/AMS files or Tinfoil itself? I'd like to figure out a way to use one SD card to be able to launch as much as I can without issue. Otherwise..

If that's the case then maybe my best bet is to just have another SD card for use with NeutOS and one for Hekate/Kosmos? Any suggestions as to another configuration that may work for me, maybe an active TInfoil Mod or Patches that will work to allow Tinfoil to boot? I like using Hekate/Kosmos. It's outrageous that entire setups need to be created just to use Blawar's tinfoil.. Drama aside it's sad to see things are this way, considering all the neat stuff his Tinfoil can do and how nice it looks.

 

[Itsuki235]

according to Cyan "Tinfoil does not work with that boot method. It will detect and delete the files present on your SD card even if you are temporarily not using fusée-secondary boot method to use Tinfoil."

That quoted sentence only applies if using Haruko's patches for fss0= style booting Atmosphere which include a loader.kip file. Tinfoil will CSE on that loader.kip file and quit running/offer to delete it.

If that's the case then maybe my best bet is to just have another SD card for use with NeutOS and one for Hekate/Kosmos? Any suggestions as to another configuration that may work for me? I like using Hekate/Kosmos.

Keep using Kosmos but alter the CFW (emuMMC) option to point to either Atmosphere's fusee-primary.bin (and use the linked Atmosphere patches) or NeutOS using the "payload=" syntax instead of the "fss0=" syntax.

For NeutOS the syntax would look like payload=payload.neutos.bin or for Atmosphere it would be payload=bootloader/payloads/fusee-primary.bin, or similar.

With that syntax, the loader.kip file will not be needed because NeutOS includes the patches found in the loader.kip in its bootloader so Tinfoil will not mind. The linked patches for vanilla atmosphere (for fusee-primary.bin) were updated to now include a version of those hacked kip_patches/loader_patches from NeutOS so it is also just drag-and-drop to install as well.

I like to do many things, such as boot into clean Stock (no CFW), emuMMC CFW, Lakka & L4T Ubuntu/AndroidOS switching SD cards when necessary. So I'd like a bit of input as to which may be the best way to achieve what I want to and be able to boot into Tinfoil as well.

Kosmos is the best way to do that by providing some preconfigured templates for how the bootloader/hekate_ipl.ini file should be configured. The only thing that needs to be changed is the "fss0=" syntax to "payload=" syntax and everything will work like you want it to.

 

[MushGuy]

Here's a question: If I install Kosmos and the patches from sdsetup.com, will Tinfoil work because of the patches that are downloaded from that site, or will it be the same with the sdsetup download?

 

[MassiveRican]

Here's a question: If I install Kosmos and the patches from sdsetup.com, will Tinfoil work because of the patches that are downloaded from that site, or will it be the same with the sdsetup download?

Seems like it won’t work as is with patches from SDsetup. You’ll have to chainload to Vanilla Atmos or NeutOS and change the syntax in Hekate_ipl.ini to Payload= when booting. Are you using emuMMC?

Edit: You’ll also need to use the linked patches for Vanilla Atmos if that’s what you chainload.

Sent from my iPhone using Tapatalk