Revert "hoc-clk: add live vdd2, live boost clock and basic pwm dimming"
This reverts commit 15b7df8ef1.
This commit is contained in:
souldbminersmwc
@@ -1,26 +0,0 @@
|
||||
# Building Atmosphère
|
||||
Building Atmosphère is a very straightforward process that relies almost exclusively on tools provided by the [devkitPro](https://devkitpro.org) organization.
|
||||
|
||||
## Dependencies
|
||||
+ [devkitA64](https://devkitpro.org)
|
||||
+ [devkitARM](https://devkitpro.org)
|
||||
+ [Python 2](https://www.python.org) (Python 3 may work as well, but this is not guaranteed)
|
||||
+ [LZ4](https://pypi.org/project/lz4)
|
||||
+ [PyCryptodome](https://pypi.org/project/pycryptodome) (optional)
|
||||
+ [hactool](https://github.com/SciresM/hactool)
|
||||
|
||||
## Instructions
|
||||
1. Follow the guide located [here](https://devkitpro.org/wiki/Getting_Started) to install and configure all the tools necessary for the build process.
|
||||
|
||||
2. Install the following packages via (dkp-)pacman:
|
||||
+ `switch-dev`
|
||||
+ `switch-glm`
|
||||
+ `switch-libjpeg-turbo`
|
||||
+ `devkitARM`
|
||||
+ `devkitarm-rules`
|
||||
+ `hactool`
|
||||
|
||||
3. Install the following library via python's package manager `pip`, required by [exosphere](components/exosphere.md):
|
||||
+ `lz4`
|
||||
|
||||
4. Finally, clone the Atmosphère repository and run `make` under its root directory.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,103 +0,0 @@
|
||||
exosphere, storage requirements:
|
||||
|
||||
Nonvolatile memory:
|
||||
0xE000
|
||||
|
||||
Volatile memory: 0x2000
|
||||
|
||||
Physical Address Space:
|
||||
-0x7C010000-0x7C012000 - boot code/volatile memory
|
||||
-0x7C012000-0x7C01E000 - program region
|
||||
-0x7C01E000-0x7C01F000 - global data/context
|
||||
-0x7C01F000-0x7C020000 - L2/L3 page table
|
||||
|
||||
-0x7C020000-0x7C040000 - Mariko-only program region
|
||||
-0x7C040000-0x7C048000 - Mariko-only program stack
|
||||
-0x7C048000-0x7C050000 - Reserved Mariko TZRAM (SE context carveouts, etc)
|
||||
|
||||
Virtual Address Space:
|
||||
|
||||
L1: 0x40 bytes.
|
||||
|
||||
L1 Entries:
|
||||
-0 (0x000000000-0x040000000): Empty
|
||||
-1 (0x040000000-0x080000000): Identity Mapping/Empty
|
||||
-2 (0x080000000-0x0C0000000): DRAM Mapping/Empty
|
||||
-3 (0x0C0000000-0x100000000): DRAM Mapping/Empty
|
||||
-4 (0x100000000-0x140000000): Empty
|
||||
-5 (0x140000000-0x180000000): Empty
|
||||
-6 (0x180000000-0x1C0000000): Empty
|
||||
-7 (0x1C0000000-0x200000000): Virtual Region
|
||||
|
||||
L2 Page and L3 page are both0x7C01F000
|
||||
|
||||
L2 Entries:
|
||||
-0x040000000 (Identity IRAM Table)
|
||||
- Entry Used: 0x000
|
||||
-0x07C000000 (Identity TZRAM Table)
|
||||
- Entry Used: 0x1E0
|
||||
-0x1F0000000 (Virtual Region Table)
|
||||
- Entry Used: 0x180
|
||||
|
||||
L3 Entries:
|
||||
- Identity TZRAM mapping (0x7C010000-0x7C020000)
|
||||
- Entry Used: 0x010-0x01F
|
||||
- Identity IRAM mapping (0x40020000-0x40040000)
|
||||
- Entry Used: 0x020-0x03F
|
||||
- Virtual Device region (0x1F0040000-0x1F0080000)
|
||||
- Entry Used: 0x040-0x07F
|
||||
- Read Only TZRAM Alias (0x1F00A0000-0x1F00B0000)
|
||||
- Entry Used: 0x0A0-0x0AF
|
||||
- Program region (0x1F00C0000-0x1F00CC000)
|
||||
- Entry Used: 0x0C0-0x0CB
|
||||
- Mariko Program region (0x1F00D0000-0x1F00F0000)
|
||||
- Entry Used: 0x0D0-0x0EF
|
||||
- Mariko Program stack (0x1F00F4000-0x1F00FC000)
|
||||
- Entry Used: 0x0F4-0x0FB
|
||||
- Secure DRAM Storage (0x1F0100000-0x1F0110000)
|
||||
- Entry Used: 0x100-0x10F
|
||||
- Debug DRAM Storage (0x1F0110000-0x1F0114000)
|
||||
- Entry Used: 0x110-0x113
|
||||
- SC7 IRAM Work Space (0x1F0120000-0x1F0130000)
|
||||
- Entry Used: 0x120-0x12F
|
||||
- SC7 IRAM Firmware (0x1F0140000-0x1F0141000)
|
||||
- Entry Used: 0x140-0x140
|
||||
- Debug Code (0x1F0150000-0x1F0154000)
|
||||
- Entry Used: 0x150-0x153
|
||||
- Reserved For Debug (0x1F0160000-0x1F0170000)
|
||||
- Entry Used: 0x160-0x16F
|
||||
- Boot Code (0x1F01C0000-0x1F01C2000)
|
||||
- Entry Used: 0x1C0-0x1C1
|
||||
- AMS IRAM Page (0x1F01F2000-0x1F01F2000)
|
||||
- Entry Used: 0x1F2-0x1F2
|
||||
- AMS User Page (0x1F01F4000-0x1F01F4000)
|
||||
- Entry Used: 0x1F4-0x1F4
|
||||
- SMC User Page (0x1F01F6000-0x1F01F6000)
|
||||
- Entry Used: 0x1F6-0x1F6
|
||||
- Volatile (Data) (0x1F01F8000-0x1F01F9000)
|
||||
- Entry Used: 0x1F8-0x1F8
|
||||
- Volatile (Stacks) (0x1F01FA000-0x1F01FB000)
|
||||
- Entry Used: 0x1FA-0x1FA
|
||||
- Global Data (0x1F01FC000-0x1F01FD000)
|
||||
|
||||
|
||||
NV Global Data needs:
|
||||
Exosphere + Emummc Config (<=0x200)
|
||||
Boot Config[0x400]
|
||||
RSA Context(0x100)
|
||||
Old Device Keys[0x20][0x10];
|
||||
Old Master Keys[0x20][0x10];
|
||||
Imported Rsa Keys[4][0x200];
|
||||
CPU Ctx[4][0x100];
|
||||
|
||||
Total: 0x1700
|
||||
|
||||
Global Data Page (accessible via X18):
|
||||
0x000-0x200: Exosphere Config
|
||||
0x200-0x400: Emummc Config
|
||||
0x400-0x800: Sealed AES Keys
|
||||
0x800-0xC00: Boot Config
|
||||
0xC00-0xFFF: CPU contexts. Can be replaced, but this fits exactly so minimizes program space waste.
|
||||
|
||||
Volatile Global Data needs:
|
||||
Random Cache 0x400 bytes
|
||||
@@ -1,4 +0,0 @@
|
||||
# emummc
|
||||
emummc is a collaborative project that provides eMMC storage emulation.
|
||||
|
||||
Please refer to the project's repository [here](https://github.com/m4xw/emuMMC) for detailed instructions and documentation.
|
||||
@@ -1,76 +0,0 @@
|
||||
# exosphère
|
||||
exosphère is a customized reimplementation of the Horizon OS's Secure Monitor.
|
||||
The Secure Monitor follows the same design principle as Arm's TrustZone and both terms can be used interchangeably in this context. It runs at the highest privilege mode (EL3) available to the main processor and is responsible for all the sensitive cryptographic operations needed by the system as well as power management for each CPU.
|
||||
|
||||
## Extensions
|
||||
exosphère expands the original Secure Monitor design by providing custom SMCs (Secure Monitor Calls) necessary to the homebrew ecosystem. Currently, these are:
|
||||
```
|
||||
uint32_t smc_ams_iram_copy(smc_args_t *args);
|
||||
uint32_t smc_ams_write_address(smc_args_t *args);
|
||||
uint32_t smc_ams_get_emummc_config(smc_args_t *args);
|
||||
```
|
||||
|
||||
Additionally, exosphère expands the functionality of two SMCs provided by the Horizon OS for getting/setting configuration items. The following custom configuration items are provided by exosphère:
|
||||
```
|
||||
CONFIGITEM_EXOSPHERE_VERSION = 65000,
|
||||
CONFIGITEM_NEEDS_REBOOT = 65001,
|
||||
CONFIGITEM_NEEDS_SHUTDOWN = 65002,
|
||||
CONFIGITEM_EXOSPHERE_VERHASH = 65003,
|
||||
CONFIGITEM_HAS_RCM_BUG_PATCH = 65004,
|
||||
CONFIGITEM_SHOULD_BLANK_PRODINFO = 65005,
|
||||
CONFIGITEM_ALLOW_CAL_WRITES = 65006,
|
||||
```
|
||||
|
||||
### smc_ams_iram_copy
|
||||
This function implements a copy of up to one page between DRAM and IRAM. Its arguments are:
|
||||
```
|
||||
args->X[1] = DRAM address (translated by kernel), must be 4-byte aligned.
|
||||
args->X[2] = IRAM address, must be 4-byte aligned.
|
||||
args->X[3] = Size (must be <= 0x1000 and 4-byte aligned).
|
||||
args->X[4] = 0 for read, 1 for write.
|
||||
```
|
||||
|
||||
### smc_ams_write_address
|
||||
This function implements a write to a DRAM page. Its arguments are:
|
||||
```
|
||||
args->X[1] = Virtual address, must be size-bytes aligned and readable by EL0.
|
||||
args->X[2] = Value.
|
||||
args->X[3] = Size (must be 1, 2, 4, or 8).
|
||||
```
|
||||
|
||||
### smc_ams_get_emummc_config
|
||||
This function retrieves configuration for the current [emummc](emummc.md) context. Its arguments are:
|
||||
```
|
||||
args->X[1] = MMC id, must be size-bytes aligned and readable by EL0.
|
||||
args->X[2] = Pointer to output (for paths for filebased + nintendo dir), must be at least 0x100 bytes.
|
||||
```
|
||||
|
||||
### CONFIGITEM_EXOSPHERE_VERSION
|
||||
This custom configuration item gets information about the current exosphere version.
|
||||
|
||||
### CONFIGITEM_NEEDS_REBOOT
|
||||
This custom configuration item is used to issue a system reboot into RCM or into a warmboot payload leveraging a secondary vulnerability to achieve code execution from warm booting.
|
||||
|
||||
### CONFIGITEM_NEEDS_SHUTDOWN
|
||||
This custom configuration item is used to issue a system shutdown with a warmboot payload leveraging a secondary vulnerability to achieve code execution from warm booting.
|
||||
|
||||
### CONFIGITEM_EXOSPHERE_VERHASH
|
||||
This custom configuration item gets information about the current exosphere git commit hash.
|
||||
|
||||
### CONFIGITEM_HAS_RCM_BUG_PATCH
|
||||
This custom configuration item gets whether the unit has the CVE-2018-6242 vulnerability patched.
|
||||
|
||||
### CONFIGITEM_SHOULD_BLANK_PRODINFO
|
||||
This custom configuration item gets whether the unit should simulate a "blanked" PRODINFO. See [here](../features/configurations.md) for more information.
|
||||
|
||||
### CONFIGITEM_ALLOW_CAL_WRITES
|
||||
This custom configuration item gets whether the unit should allow writing to the calibration partition.
|
||||
|
||||
## lp0fw
|
||||
This is a small, built-in payload that is responsible for waking up the system during a warm boot.
|
||||
|
||||
## sc7fw
|
||||
This is a small, built-in payload that is responsible for putting the system to sleep during a warm boot.
|
||||
|
||||
## rebootstub
|
||||
This is a small, built-in payload that provides functionality to reboot the system into any payload of choice.
|
||||
@@ -1,8 +0,0 @@
|
||||
# fusée
|
||||
fusée is a custom bootloader used to start the Atmosphère environment.
|
||||
|
||||
## fusée
|
||||
fusée is the first piece of Atmosphère's code that runs on the hardware.
|
||||
It is distributed as a standalone payload designed to be launched via RCM by abusing the CVE-2018-6242 vulnerability.
|
||||
|
||||
This payload is responsible for all the low-level hardware initialization required by the Nintendo Switch, setting up the cryptosystem, mounting/emulating the eMMC, injecting/patching system modules, and launching the exosphère component.
|
||||
@@ -1,11 +0,0 @@
|
||||
# libraries
|
||||
This is a collection of libraries for doing operating system development for the Nintendo Switch.
|
||||
|
||||
## libmesosphere
|
||||
libmesosphere is a work-in-progress C++ library implementing functionality for the Horizon Kernel.
|
||||
|
||||
## libstratosphere
|
||||
libstratosphere is a work-in-progress C++ library for development of system modules for the Nintendo Switch.
|
||||
|
||||
## libvapours
|
||||
Common boilerplate code for various purposes.
|
||||
@@ -1,3 +0,0 @@
|
||||
# mesosphère
|
||||
mesosphère is a work in progress customized kernel reimplementation.
|
||||
The Horizon OS's kernel follows microkernel design principles and runs at the EL1 level. It is currently subdivided into a loader (kernel_ldr) and the main kernel code.
|
||||
@@ -1,40 +0,0 @@
|
||||
# ams_mitm
|
||||
This module provides methods to intercept services provided by other system modules. It is further sub-divided according to the service it targets.
|
||||
|
||||
## bpc_mitm
|
||||
bpc_mitm enables intercepting requests to power control services. It currently intercepts:
|
||||
+ `am` system module (to intercept the Reboot/Power buttons in the overlay menu)
|
||||
+ `fatal` system module (to simplify payload reboot logic significantly)
|
||||
+ [nx-hbloader](https://github.com/switchbrew/nx-hbloader) (to allow homebrew to take advantage of the feature)
|
||||
|
||||
## fs_mitm
|
||||
fs_mitm enables intercepting file system operations. It can deny, delay, replace, or redirect any request made to the file system. It enables LayeredFS to function, which allows for replacement of game assets.
|
||||
|
||||
## hid_mitm
|
||||
hid_mitm enables intercepting requests to controller device services. It is currently disabled by default. If enabled, it intercepts:
|
||||
+ [nx-hbloader](https://github.com/switchbrew/nx-hbloader) (to help homebrew not need to be recompiled due to a breaking change introduced in the past)
|
||||
|
||||
Note that hid_mitm is currently deprecated and might be removed entirely in the future.
|
||||
|
||||
## ns_mitm
|
||||
ns_mitm enables intercepting requests to application control services. It currently intercepts:
|
||||
+ Web Applets (to facilitate nx-hbloader web browser launching)
|
||||
|
||||
## set_mitm
|
||||
set_mitm enables intercepting requests to the system settings service. It currently intercepts:
|
||||
+ `ns` system module and games (to allow for overriding game locales)
|
||||
+ All firmware debug settings requests (to allow modification of system settings not directly exposed to the user)
|
||||
|
||||
### Firmware Version
|
||||
set_mitm intercepts the `GetFirmwareVersion` command, if the requester is `qlaunch` or `maintenance`.
|
||||
It modifies the `display_version` field of the returned system version, causing the version to display
|
||||
in settings as `#.#.#|AMS #.#.#|?` with `? = S` when running under system eMMC or `? = E` when running under emulated eMMC. This allows users to easily verify what version of Atmosphère and what eMMC environment they are running.
|
||||
|
||||
### System Settings
|
||||
set_mitm intercepts the `GetSettingsItemValueSize` and `GetSettingsItemValue` commands for all requesters.
|
||||
It does so in order to enable user configuration of system settings, which are parsed from `/atmosphere/system_settings.ini` on boot. See [here](../../features/configurations.md) for more information on the system settings format.
|
||||
|
||||
## dns_mitm
|
||||
dns_mitm enables intercepting requests to dns resolution services, to enable redirecting requests for specified hostnames.
|
||||
|
||||
For documentation, see [here](../../features/dns_mitm.md).
|
||||
@@ -1,4 +0,0 @@
|
||||
# boot
|
||||
This module is a reimplementation of the Horizon OS's `boot` system module, which is responsible for initializing and configuring hardware.
|
||||
|
||||
Atmosphère's reimplementation displays its own black and white splash screen and battery icons as replacements for the original assets used during display initialization.
|
||||
@@ -1,4 +0,0 @@
|
||||
# boot2
|
||||
This module is a reimplementation of the Horizon OS's `boot2` system module, which is responsible for launching all the other necessary system modules.
|
||||
|
||||
Atmosphère's reimplementation allows launching user provided system modules from the SD card. See [here](../../features/configurations.md) for more information.
|
||||
@@ -1,4 +0,0 @@
|
||||
# creport
|
||||
This module is a reimplementation of the Horizon OS's `creport` system module, which is responsible for managing crash reports.
|
||||
|
||||
Atmosphère's reimplementation redirects writing of generated crash reports to the SD card under the folder `/atmosphere/crash_reports/`. It also prevents the automatic uploading of said crash reports.
|
||||
@@ -1,42 +0,0 @@
|
||||
# dmnt
|
||||
This module is a reimplementation of the Horizon OS's `dmnt` system module, which provides a debug monitor.
|
||||
|
||||
## Extensions
|
||||
Atmosphère implements an extension to provide cheat code functionality.
|
||||
|
||||
### Cheat Service
|
||||
A HIPC service API is provided for interacting with the cheat code manager through the service `dmnt:cht`. See [here](../../features/cheats.md) for more information on the cheat code format.
|
||||
|
||||
The SwIPC definition for `dmnt:cht` follows:
|
||||
```
|
||||
interface ams::dmnt::cheat::CheatService is dmnt:cht {
|
||||
[65000] HasCheatProcess() -> sf::Out<bool> out;
|
||||
[65001] GetCheatProcessEvent() -> sf::OutCopyHandle out_event;
|
||||
[65002] GetCheatProcessMetadata() -> sf::Out<CheatProcessMetadata> out_metadata;
|
||||
[65003] ForceOpenCheatProcess();
|
||||
[65004] PauseCheatProcess();
|
||||
[65005] ResumeCheatProcess();
|
||||
|
||||
[65100] GetCheatProcessMappingCount() -> sf::Out<u64> out_count;
|
||||
[65101] GetCheatProcessMappings(u64 offset) -> sf::OutArray<MemoryInfo> &mappings, sf::Out<u64> out_count;
|
||||
[65102] ReadCheatProcessMemory(u64 address, u64 out_size) -> sf::OutBuffer &buffer;
|
||||
[65103] WriteCheatProcessMemory(sf::InBuffer &buffer, u64 address, u64 in_size);
|
||||
[65104] QueryCheatProcessMemory(u64 address) -> sf::Out<MemoryInfo> mapping;
|
||||
|
||||
[65200] GetCheatCount() -> sf::Out<u64> out_count;
|
||||
[65201] GetCheats(u64 offset) -> sf::OutArray<CheatEntry> &cheats, sf::Out<u64> out_count;
|
||||
[65202] GetCheatById(u32 cheat_id) -> sf::Out<CheatEntry> cheat;
|
||||
[65203] ToggleCheat(u32 cheat_id);
|
||||
[65204] AddCheat(CheatDefinition &cheat, bool enabled) -> sf::Out<u32> out_cheat_id;
|
||||
[65205] RemoveCheat(u32 cheat_id);
|
||||
[65206] ReadStaticRegister(u8 which) -> sf::Out<u64> out;
|
||||
[65207] WriteStaticRegister(u8 which, u64 value);
|
||||
[65208] ResetStaticRegisters();
|
||||
|
||||
[65300] GetFrozenAddressCount() -> sf::Out<u64> out_count;
|
||||
[65301] GetFrozenAddresses(u64 offset) ->sf::OutArray<FrozenAddressEntry> &addresses, sf::Out<u64> out_count;
|
||||
[65302] GetFrozenAddress(u64 address) -> sf::Out<FrozenAddressEntry> entry;
|
||||
[65303] EnableFrozenAddress(u64 address, u64 width) -> sf::Out<u64> out_value;
|
||||
[65304] DisableFrozenAddress(u64 address);
|
||||
}
|
||||
```
|
||||
@@ -1,4 +0,0 @@
|
||||
# eclct.stub
|
||||
This module is a reimplementation of the Horizon OS's `eclct` system module, which collects error reports.
|
||||
|
||||
Atmosphère's reimplementation is a stub to remove any and all functionality pertaining to error report collection.
|
||||
@@ -1,4 +0,0 @@
|
||||
# erpt
|
||||
This module is a reimplementation of the Horizon OS's `erpt` system module, which is responsible for managing error reports.
|
||||
|
||||
Atmosphère's reimplementation redirects writing of generated error reports to the SD card under the folder `/atmosphere/erpt_reports/`.
|
||||
@@ -1,4 +0,0 @@
|
||||
# fatal
|
||||
This module is a reimplementation of the Horizon OS's `fatal` system module, which is responsible for managing fatal reports.
|
||||
|
||||
Atmosphère's reimplementation prevents error report creation and draws a custom error screen, showing registers and a backtrace. It also attempts to gather debugging info for any and all crashes and tries to save reports to the SD card under the folder `/atmosphere/fatal_reports/`.
|
||||
@@ -1,4 +0,0 @@
|
||||
# jpegdec
|
||||
This module is a reimplementation of the Horizon OS's `jpegdec` system module, which is responsible for JPEG format decoding.
|
||||
|
||||
Atmosphère's reimplementation allows two sessions instead of 1, so homebrew can use it for software JPEG decoding in addition to the OS itself.
|
||||
@@ -1,106 +0,0 @@
|
||||
# loader
|
||||
This module is a reimplementation of the Horizon OS's `ldr` system module, which is responsible for creating processes from executable NSO images and registering their access control.
|
||||
|
||||
## Extensions
|
||||
Atmosphère extends this module to allow executables to be replaced or patched by files stored on the SD card. Note that a few services are required for SD card access and therefore cannot be replaced or patched in this manner.
|
||||
|
||||
### Exefs Replacement
|
||||
Atmosphère's reimplementation allows replacing executable files in the file system.
|
||||
|
||||
#### Partition Replacement
|
||||
It is possible to replace the full exefs partition at once with a PFS0 file. In that case, Atmosphère will load the following file:
|
||||
```
|
||||
/atmosphere/contents/<program id>/exefs.nsp
|
||||
```
|
||||
|
||||
#### File Replacement
|
||||
When a process is created, loader will search for several NSO filenames in the program's exefs directory.
|
||||
These filenames are, in this order:
|
||||
- rtld
|
||||
- main
|
||||
- subsdk0
|
||||
- subsdk1
|
||||
- ...
|
||||
- subsdk9
|
||||
- sdk
|
||||
|
||||
Each NSO that is found will be loaded into the process contiguously. The process's entrypoint is at the first NSO to be loaded, usually `rtld` or `main`.
|
||||
|
||||
Additionally, when a process is loaded, loader will search for a `main.npdm` file in the exefs directory specifying the program's permissions.
|
||||
|
||||
Atmosphère extends this functionality by also searching for these files on the SD card. When searching for a file, loader will first check if it exists on the SD card. If it does, that file will be used instead. Otherwise, it will use the copy located in the exefs, if that is present. The following directory will be searched:
|
||||
```
|
||||
/atmosphere/contents/<program id>/exefs/
|
||||
```
|
||||
|
||||
This allows the replacement of applets, system modules, or even games with homebrew versions.
|
||||
|
||||
##### File Stubbing
|
||||
In order to prevent an NSO from being loaded even if it exists in the exefs, loader will also check if a stub file exists. If such a file exists, the NSO will not be loaded. The files should be named like `rtld.stub`, `main.stub`, etc. and may be empty.
|
||||
|
||||
##### Technical Semantics
|
||||
|
||||
loader's semantics for content override can (as you may observe from reading the above) be complicated to understand. The following is an abbreviated description of the very technical semantics by which loader decides what content to read when trying to read a file for a program id.
|
||||
|
||||
* If an external content filesystem exists for the program id, the external content filesystem is used directly with no further redirection.
|
||||
* Otherwise, if the program ID is being overridden with [nx-hbloader](https://github.com/switchbrew/nx-hbloader/releases) (see Homebrew Support below), the nsp filesystem for hbl is used directly with no further redirection.
|
||||
* Otherwise, if content redirection is enabled for the program ID (controlled by a configurable button combination) and a loose file exists on the SD card, the loose file is used.
|
||||
* Otherwise, if a stub file exists, a "Not Found" error is returned.
|
||||
* Otherwise, if an SD card executable filesystem ("exefs.nsp") exists, it is used without further redirection.
|
||||
* Finally, the "real"/base code file system is used without further redirection.
|
||||
|
||||
In addition, there are a few other technical details relevant to Atmosphere's redirection:
|
||||
* When overriding with nx-hbloader, the real code filesystem must exist. When "main.npdm" (a program capabilities descriptor file) is read, the content from the real code filesystem is read in order to determine whether an applet or an application is being overridden. This allows nx-hbloader to automatically support both applet and application environments.
|
||||
* When overriding applications, the real code filesystem must exist and contain valid content. This is required to perform accurate-to-Nintendo content verification procedures.
|
||||
* When programs are launched, both a program id and a "storage id" are specified by the launch requester. When the storage id specified is "none" (normally always invalid), Atmosphere assumes that a custom system module is attempting to be launched. This removes the aforementioned requirement on base content validity; the above procedure is still used to determine how to redirect content, however reads to the "real"/base code file system may return "Not Found" errors if the real/base code file system does not exist.
|
||||
|
||||
### NSO Patching
|
||||
When an NSO is loaded, Atmosphère's reimplementation will search for IPS patch files on the SD card in the following locations.
|
||||
```
|
||||
/atmosphere/exefs_patches/<patchset name>/<nso build id>.ips
|
||||
```
|
||||
|
||||
This organization allows patch sets affecting multiple NSOs to be distributed as a single directory and also allows patches from multiple patch sets to be stacked. Patches will be searched for in each patch set directory. The name of each patch file should match the hexadecimal build ID of the NSO to affect, except that trailing zero bytes may be left off. Because the NSO build ID is unique for every NSO, this means patches will only apply to the files they are meant to apply to.
|
||||
|
||||
Patch files are accepted in either IPS format or IPS32 format.
|
||||
|
||||
Because NSO files are compressed, patch files are not made between the original version of a compressed NSO and the modified version of such an NSO. Instead, they are made between the uncompressed version of an NSO and the modified (and still uncompressed) version of that NSO. This also means that a patch file cannot be manually applied to the compressed version of an NSO; it must be applied to the uncompressed version. Atmosphère's reimplementation will correctly apply these patches while loading the process regardless of whether the NSO it finds is compressed or not.
|
||||
|
||||
When authoring patches, [hactool](https://github.com/SciresM/hactool) can be used to find an NSO's build ID and to uncompress NSOs. Recent versions of the [ReSwitched IDA loaders](https://github.com/reswitched/loaders) can be used to load uncompressed NSOs into IDA in such a way that you can [apply patches to the input file](https://www.hex-rays.com/products/ida/support/idadoc/1618.shtml). From there, any IPS tool can be used to create the patch between the original NSO and the patched NSO. Note that if the NSO you are patching is larger than 16 MiB, you will have to use a tool that supports IPS32.
|
||||
|
||||
### Homebrew Support
|
||||
Atmosphère provides first class support for [nx-hbloader](https://github.com/switchbrew/nx-hbloader/releases) and [nx-hbmenu](https://github.com/switchbrew/nx-hbmenu/releases).
|
||||
|
||||
Launching of the nx-hbloader process is controlled by configurable button inputs. See [here](../../features/configurations.md) for more detailed information.
|
||||
|
||||
In addition, loader has extensions to enable homebrew to launch web applets. This normally requires the application launching the applet to have HTML Manual content inside an installed NCA. Atmosphère's reimplementation will automatically ensure that the commands used to check this succeed, and will redirect the relevant file system to the `/atmosphere/hbl_html/` subdirectory.
|
||||
|
||||
### IPC Commands
|
||||
Atmosphère's reimplementation extends the HIPC loader services' API with several custom commands.
|
||||
|
||||
The SwIPC definition for the `ldr:pm` extension commands follows:
|
||||
```
|
||||
interface ams::ldr::pm::ProcessManagerInterface is ldr:pm {
|
||||
...
|
||||
[65000] AtmosphereHasLaunchedProgram(ncm::ProgramId program_id) -> sf::Out<bool> out;
|
||||
[65001] AtmosphereGetProgramInfo(ncm::ProgramLocation &loc) -> sf::Out<ProgramInfo> out_program_info, sf::Out<cfg::OverrideStatus> out_status;
|
||||
[65002] AtmospherePinProgram(ncm::ProgramLocation &loc, cfg::OverrideStatus &override_status) -> sf::Out<PinId> out_id;
|
||||
}
|
||||
```
|
||||
|
||||
The SwIPC definition for the `ldr:dmnt` extension commands follows:
|
||||
```
|
||||
interface ams::ldr::dmnt::DebugMonitorInterface is ldr:dmnt {
|
||||
...
|
||||
[65000] AtmosphereHasLaunchedProgram(ncm::ProgramId program_id) -> sf::Out<bool> out;
|
||||
}
|
||||
```
|
||||
|
||||
The SwIPC definition for the `ldr:shel` extension commands follows:
|
||||
```
|
||||
interface ams::ldr::shell::ShellInterface is ldr:shel {
|
||||
...
|
||||
[65000] AtmosphereRegisterExternalCode(ncm::ProgramId program_id) -> sf::OutMoveHandle out;
|
||||
[65001] AtmosphereUnregisterExternalCode(ncm::ProgramId program_id);
|
||||
}
|
||||
```
|
||||
@@ -1,4 +0,0 @@
|
||||
# ncm
|
||||
This module is a reimplementation of the Horizon OS's `ncm` system module, which is responsible for content management.
|
||||
|
||||
Atmosphère's reimplementation is currently opt-in only. See [here](../../features/configurations.md) for more information.
|
||||
@@ -1,4 +0,0 @@
|
||||
# pgl
|
||||
This module is a reimplementation of the Horizon OS's `pgl` system module, which is responsible for launching programs and was introduced by firmware version `10.0.0`.
|
||||
|
||||
Currently, Atmosphère's reimplementation doesn't backport this module's functionalities to firmware versions lower than `10.0.0`.
|
||||
@@ -1,30 +0,0 @@
|
||||
# pm
|
||||
This module is a reimplementation of the Horizon OS's `pm` system module, which is responsible for tracking running processes on the system, and managing resource limits.
|
||||
|
||||
## Extensions
|
||||
Atmosphère extends this module with extra IPC commands and memory restriction changes.
|
||||
|
||||
### IPC Commands
|
||||
Atmosphère's reimplementation extends the HIPC loader services' API with several custom commands.
|
||||
|
||||
The SwIPC definition for the `pm:dmnt` extension commands follows:
|
||||
```
|
||||
interface ams::pm::dmnt::DebugMonitorServiceBase is pm:dmnt {
|
||||
...
|
||||
[65000] AtmosphereGetProcessInfo(os::ProcessId process_id) -> sf::OutCopyHandle out_process_handle, sf::Out<ncm::ProgramLocation> out_loc, sf::Out<cfg::OverrideStatus> out_status;
|
||||
[65001] AtmosphereGetCurrentLimitInfo(u32 group, u32 resource) -> sf::Out<s64> out_cur_val, sf::Out<s64> out_lim_val;
|
||||
}
|
||||
```
|
||||
|
||||
The SwIPC definition for the `pm:info` extension commands follows:
|
||||
```
|
||||
interface ams::pm::info::InformationService is pm:info {
|
||||
...
|
||||
[65000] AtmosphereGetProcessId(ncm::ProgramId program_id) -> sf::Out<os::ProcessId> out;
|
||||
[65001] AtmosphereHasLaunchedProgram(ncm::ProgramId program_id) -> sf::Out<bool> out;
|
||||
[65002] AtmosphereGetProcessInfo(os::ProcessId process_id) -> sf::Out<ncm::ProgramLocation> out_loc, sf::Out<cfg::OverrideStatus> out_status;
|
||||
}
|
||||
```
|
||||
|
||||
### Extra System Memory
|
||||
Atmosphère's reimplementation shrinks the APPLET memory pool by 24 MiB by default, giving this memory to the SYSTEM pool. This allows custom system modules to use more memory without hitting the SYSTEM memory limit.
|
||||
@@ -1,16 +0,0 @@
|
||||
# ro
|
||||
This module is a reimplementation of the Horizon OS's `ro` system module, which is responsible for loading dynamic libraries and was introduced by firmware version `3.0.0`.
|
||||
|
||||
Atmosphère's reimplementation backports this module's functionalities to firmware versions lower than `3.0.0` where said functionalities were provided by the `ldr` system module instead.
|
||||
|
||||
## Extensions
|
||||
Atmosphère extends this module to allow libraries to be patched by files stored on the SD card.
|
||||
|
||||
### NRO Patching
|
||||
When an NRO is loaded, Atmosphère's reimplementation will search for IPS patch files on the SD card in the following locations.
|
||||
```
|
||||
/atmosphere/nro_patches/<patchset name>/<nro build id>.ips
|
||||
```
|
||||
This organization allows patch sets affecting multiple NROs to be distributed as a single directory. Patches will be searched for in each patch set directory. The name of each patch file should match the hexadecimal build ID of the NRO to affect, except that trailing zero bytes may be left off. Because the NRO build ID is unique for every NRO, this means patches will only apply to the files they are meant to apply to.
|
||||
|
||||
Patch files are accepted in either IPS format or IPS32 format.
|
||||
@@ -1,47 +0,0 @@
|
||||
# sm
|
||||
This module is a reimplementation of the Horizon OS's `sm` system module, which is responsible for service management.
|
||||
|
||||
## Extensions
|
||||
Atmosphère extends this module with extra IPC commands and new services.
|
||||
|
||||
### Debug Monitor
|
||||
Atmosphère's reimplementation provides an interface `sm:dmnt` to allow a debug monitor to query the service manager's state.
|
||||
|
||||
The SwIPC definition for `sm:dmnt` follows:
|
||||
```
|
||||
interface ams::sm::DmntService is sm:dmnt {
|
||||
[65000] AtmosphereGetRecord(ServiceName service) -> sf::Out<ServiceRecord> record;
|
||||
[65001] AtmosphereListRecords(u64 offset) -> sf::OutArray<ServiceRecord> &records, sf::Out<u64> out_count;
|
||||
[65002] AtmosphereGetRecordSize() -> sf::Out<u64> record_size;
|
||||
}
|
||||
```
|
||||
|
||||
### IPC Commands
|
||||
Atmosphère's reimplementation extends the HIPC loader services' API with several custom commands.
|
||||
|
||||
The SwIPC definition for the `sm:` extension commands follows:
|
||||
```
|
||||
interface ams::sm::UserService is sm: {
|
||||
...
|
||||
[65000] AtmosphereInstallMitm(ServiceName service) -> sf::OutMoveHandle srv_h, sf::OutMoveHandle qry_h;
|
||||
[65001] AtmosphereUninstallMitm(ServiceName service);
|
||||
[65002] Deprecated_AtmosphereAssociatePidTidForMitm();
|
||||
[65003] AtmosphereAcknowledgeMitmSession(ServiceName service) -> sf::Out<MitmProcessInfo> client_info, sf::OutMoveHandle fwd_h;
|
||||
[65004] AtmosphereHasMitm(ServiceName service) -> sf::Out<bool> out;
|
||||
[65005] AtmosphereWaitMitm(ServiceName service);
|
||||
[65006] AtmosphereDeclareFutureMitm(ServiceName service);
|
||||
|
||||
[65100] AtmosphereHasService(ServiceName service) -> sf::Out<bool> out;
|
||||
[65101] AtmosphereWaitService(ServiceName service);
|
||||
}
|
||||
```
|
||||
|
||||
The SwIPC definition for the `sm:m` extension commands follows:
|
||||
```
|
||||
interface ams::sm::ManagerService is sm:m {
|
||||
...
|
||||
[65000] AtmosphereEndInitDefers(os::ProcessId process_id, sf::InBuffer &acid_sac, sf::InBuffer &aci_sac);
|
||||
[65001] AtmosphereHasMitm(ServiceName service) -> sf::Out<bool> out;
|
||||
[65002] AtmosphereRegisterProcess(os::ProcessId process_id, ncm::ProgramId program_id, cfg::OverrideStatus override_status, sf::InBuffer &acid_sac, sf::InBuffer &aci_sac);
|
||||
}
|
||||
```
|
||||
@@ -1,2 +0,0 @@
|
||||
# spl
|
||||
This module is a reimplementation of the Horizon OS's `spl` system module, which is responsible for providing secure platform services such as cryptographic operations.
|
||||
@@ -1,21 +0,0 @@
|
||||
# stratosphère
|
||||
stratosphère provides customization of the Horizon OS at the system level. This includes a reimplementation of several system modules and additional, custom system modules that extend or add a variety of features.
|
||||
|
||||
## Modules
|
||||
The modules currently provided by stratosphère are:
|
||||
+ [ams_mitm](modules/ams_mitm.md)
|
||||
+ [boot](modules/boot.md)
|
||||
+ [boot2](modules/boot2.md)
|
||||
+ [creport](modules/creport.md)
|
||||
+ [dmnt](modules/dmnt.md)
|
||||
+ [eclct.stub](modules/eclct.stub.md)
|
||||
+ [erpt](modules/erpt.md)
|
||||
+ [fatal](modules/fatal.md)
|
||||
+ [jpegdec](modules/jpegdec.md)
|
||||
+ [loader](modules/loader.md)
|
||||
+ [ncm](modules/ncm.md)
|
||||
+ [pgl](modules/pgl.md)
|
||||
+ [pm](modules/pm.md)
|
||||
+ [ro](modules/ro.md)
|
||||
+ [sm](modules/sm.md)
|
||||
+ [spl](modules/spl.md)
|
||||
@@ -1,3 +0,0 @@
|
||||
# thermosphère
|
||||
thermosphère is a work in progress hypervisor implementation.
|
||||
This aims to provide functionality at the EL2 level which remains unused by the Horizon OS.
|
||||
@@ -1,5 +0,0 @@
|
||||
# troposphère
|
||||
troposphère provides customization of the Horizon OS at the application level.
|
||||
|
||||
## reboot_to_payload
|
||||
Sample application to perform a system reboot into a payload of choice.
|
||||
@@ -1,18 +0,0 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
This document serves as a place to store answers for common questions received about Atmosphère.
|
||||
|
||||
## What does "June 15th" mean?
|
||||
When Atmosphère began development in February 2018, "June 15" was given as the estimate/target date for a first release, to coincide with the planned disclosure of a vulnerability.
|
||||
|
||||
This deadline was missed, hard.
|
||||
|
||||
People made rather a lot of fun of me (SciresM) for this.
|
||||
|
||||
Several months later, when the first Atmosphère release occurred, I captioned it "Happy June 15th!" and pretended like I hadn't missed the first deadline.
|
||||
|
||||
This amused me a lot, and so the practice has been kept up for every single release since.
|
||||
|
||||
Depending on who you ask, you may be told that this is a dumb joke and it is not funny.
|
||||
|
||||
This is incorrect. It is definitely a dumb joke, but it is also hilarious.
|
||||
@@ -1,512 +0,0 @@
|
||||
# Cheats
|
||||
Atmosphère supports Action-Replay style cheat codes, with cheats loaded off of the SD card.
|
||||
|
||||
## Cheat Loading Process
|
||||
By default, Atmosphère will do the following when deciding whether to attach to a new application process:
|
||||
|
||||
+ Retrieve information about the new application process from `pm` and `loader`.
|
||||
+ Check whether a user-defined key combination is held, and stop if not.
|
||||
+ This defaults to "L is not held", but can be configured with override keys.
|
||||
+ The ini key to configure this is `cheat_enable_key`.
|
||||
+ Check whether the process is a real application, and stop if not.
|
||||
+ This guards against applying cheat codes to the Homebrew Loader.
|
||||
+ Attempt to load cheats from `/atmosphere/contents/<program_id>/cheats/<build_id>.txt`, where `build_id` is the hexadecimal representation of the first 8 bytes of the application's main executable's build id.
|
||||
+ If no cheats are found, then the cheat manager will stop.
|
||||
+ Open a kernel debug session for the new application process.
|
||||
+ Signal to a system event that a new cheat process has been attached to.
|
||||
|
||||
This behavior ensures that cheat codes are only loaded when the user would want them to.
|
||||
|
||||
In cases where `dmnt` has not activated the cheat manager, but the user wants to make it do so anyway, the cheat manager's service API provides a `ForceOpenCheatProcess` command that homebrew can use. This command will cause the cheat manager to try to force itself to attach to the process.
|
||||
|
||||
In cases where `dmnt` has activated the cheat manager, but the user wants to use an alternate debugger, the cheat manager's service API provides a `ForceCloseCheatProcess` command that homebrew can use. This command will cause the cheat manager to detach itself from the process.
|
||||
|
||||
By default, all cheat codes listed in the loaded .txt file will be toggled on. This is configurable by the user by editing the `atmosphere!dmnt_cheats_enabled_by_default` [system setting](configurations.md).
|
||||
|
||||
Users may use homebrew programs to toggle cheats on and off at runtime via the cheat manager's service API.
|
||||
|
||||
## Cheat Code Compatibility
|
||||
Atmosphère manages cheat code through the execution of a small, custom virtual machine. Care has been taken to ensure that Atmosphère's cheat code format is fully backwards compatible with the pre-existing cheat code format, though new features have been added and bugs in the pre-existing cheat code applier have been fixed. Here is a short summary of the changes from the pre-existing format:
|
||||
|
||||
+ A number of bugs were fixed in the processing of conditional instructions.
|
||||
+ The pre-existing implementation was fundamentally broken, and checked for the wrong value when detecting the end of a conditional block.
|
||||
+ The pre-existing implementation also did not properly decode instructions, and instead linearly scanned for the terminator value. This caused problems if an instruction happened to encode a terminator inside its immediate values.
|
||||
+ The pre-existing implementation did not bounds check, and thus certain conditional cheat codes could cause it to read out-of-bounds memory, and potentially crash due to a data abort.
|
||||
+ Support was added for nesting conditional blocks.
|
||||
+ An instruction was added to perform much more complex arbitrary arithmetic on two registers.
|
||||
+ An instruction was added to allow writing the contents of register to a memory address specified by another register.
|
||||
+ The pre-existing implementation did not correctly synchronize with the application process, and thus would cause heavy lag under certain circumstances (especially around loading screens). This has been fixed in Atmosphère's implementation.
|
||||
|
||||
## Cheat Code Format
|
||||
The following provides documentation of the instruction format for the virtual machine used to manage cheat codes.
|
||||
|
||||
Typically, instruction type is encoded in the upper nybble of the first instruction u32.
|
||||
|
||||
### Code Type 0x0: Store Static Value to Memory
|
||||
Code type 0x0 allows writing a static value to a memory address.
|
||||
|
||||
#### Encoding
|
||||
`0TMR00AA AAAAAAAA VVVVVVVV (VVVVVVVV)`
|
||||
|
||||
+ T: Width of memory write (1, 2, 4, or 8 bytes).
|
||||
+ M: Memory region to write to (0 = Main NSO, 1 = Heap, 2 = Alias, 3 = Aslr, 4 = non-relative).
|
||||
+ R: Register to use as an offset from memory region base.
|
||||
+ A: Immediate offset to use from memory region base.
|
||||
+ V: Value to write.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x1: Begin Conditional Block
|
||||
Code type 0x1 performs a comparison of the contents of memory to a static value.
|
||||
|
||||
If the condition is not met, all instructions until the appropriate End or Else conditional block terminator are skipped.
|
||||
|
||||
#### Encoding
|
||||
`1TMCXrAA AAAAAAAA VVVVVVVV (VVVVVVVV)`
|
||||
|
||||
+ T: Width of memory read (1, 2, 4, or 8 bytes).
|
||||
+ M: Memory region to read from (0 = Main NSO, 1 = Heap, 2 = Alias, 3 = Aslr, 4 = non-relative).
|
||||
+ C: Condition to use, see below.
|
||||
+ X: Operand Type, see below.
|
||||
+ r: Offset Register (operand types 1).
|
||||
+ A: Immediate offset to use from memory region base.
|
||||
+ V: Value to compare to.
|
||||
|
||||
#### Conditions
|
||||
+ 1: >
|
||||
+ 2: >=
|
||||
+ 3: <
|
||||
+ 4: <=
|
||||
+ 5: ==
|
||||
+ 6: !=
|
||||
|
||||
#### Operand Type
|
||||
+ 0: Memory Base + Relative Offset
|
||||
+ 1: Memory Base + Offset Register + Relative Offset
|
||||
---
|
||||
|
||||
### Code Type 0x2: End Conditional Block
|
||||
Code type 0x2 marks the end of a conditional block (started by Code Type 0x1 or Code Type 0x8).
|
||||
|
||||
When an Else is executed, all instructions until the appropriate End conditional block terminator are skipped.
|
||||
|
||||
#### Encoding
|
||||
`2X000000`
|
||||
|
||||
+ X: End type (0 = End, 1 = Else).
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x3: Start/End Loop
|
||||
Code type 0x3 allows for iterating in a loop a fixed number of times.
|
||||
|
||||
#### Start Loop Encoding
|
||||
`300R0000 VVVVVVVV`
|
||||
|
||||
+ R: Register to use as loop counter.
|
||||
+ V: Number of iterations to loop.
|
||||
|
||||
#### End Loop Encoding
|
||||
`310R0000`
|
||||
|
||||
+ R: Register to use as loop counter.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x4: Load Register with Static Value
|
||||
Code type 0x4 allows setting a register to a constant value.
|
||||
|
||||
#### Encoding
|
||||
`400R0000 VVVVVVVV VVVVVVVV`
|
||||
|
||||
+ R: Register to use.
|
||||
+ V: Value to load.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x5: Load Register with Memory Value
|
||||
Code type 0x5 allows loading a value from memory into a register, either using a fixed address or by dereferencing the destination register.
|
||||
|
||||
#### Load From Fixed Address Encoding
|
||||
`5TMR00AA AAAAAAAA`
|
||||
|
||||
+ T: Width of memory read (1, 2, 4, or 8 bytes).
|
||||
+ M: Memory region to write to (0 = Main NSO, 1 = Heap, 2 = Alias, 3 = Aslr, 4 = non-relative).
|
||||
+ R: Register to load value into.
|
||||
+ A: Immediate offset to use from memory region base.
|
||||
|
||||
#### Load from Register Address Encoding
|
||||
`5T0R10AA AAAAAAAA`
|
||||
|
||||
+ T: Width of memory read (1, 2, 4, or 8 bytes).
|
||||
+ R: Register to load value into. (This register is also used as the base memory address).
|
||||
+ A: Immediate offset to use from register R.
|
||||
|
||||
#### Load from Register Address Encoding
|
||||
`5T0R2SAA AAAAAAAA`
|
||||
|
||||
+ T: Width of memory read (1, 2, 4, or 8 bytes).
|
||||
+ R: Register to load value into.
|
||||
+ S: Register to use as the base memory address.
|
||||
+ A: Immediate offset to use from register R.
|
||||
|
||||
#### Load From Fixed Address Encoding with offset register
|
||||
`5TMR3SAA AAAAAAAA`
|
||||
|
||||
+ T: Width of memory read (1, 2, 4, or 8 bytes).
|
||||
+ M: Memory region to write to (0 = Main NSO, 1 = Heap, 2 = Alias, 3 = Aslr, 4 = non-relative).
|
||||
+ R: Register to load value into.
|
||||
+ S: Register to use as offset register.
|
||||
+ A: Immediate offset to use from memory region base.
|
||||
---
|
||||
|
||||
### Code Type 0x6: Store Static Value to Register Memory Address
|
||||
Code type 0x6 allows writing a fixed value to a memory address specified by a register.
|
||||
|
||||
#### Encoding
|
||||
`6T0RIor0 VVVVVVVV VVVVVVVV`
|
||||
|
||||
+ T: Width of memory write (1, 2, 4, or 8 bytes).
|
||||
+ R: Register used as base memory address.
|
||||
+ I: Increment register flag (0 = do not increment R, 1 = increment R by T).
|
||||
+ o: Offset register enable flag (0 = do not add r to address, 1 = add r to address).
|
||||
+ r: Register used as offset when o is 1.
|
||||
+ V: Value to write to memory.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x7: Legacy Arithmetic
|
||||
Code type 0x7 allows performing arithmetic on registers.
|
||||
|
||||
However, it has been deprecated by Code type 0x9, and is only kept for backwards compatibility.
|
||||
|
||||
#### Encoding
|
||||
`7T0RC000 VVVVVVVV`
|
||||
|
||||
+ T: Width of arithmetic operation (1, 2, 4, or 8 bytes).
|
||||
+ R: Register to apply arithmetic to.
|
||||
+ C: Arithmetic operation to apply, see below.
|
||||
+ V: Value to use for arithmetic operation.
|
||||
|
||||
#### Arithmetic Types
|
||||
+ 0: Addition
|
||||
+ 1: Subtraction
|
||||
+ 2: Multiplication
|
||||
+ 3: Left Shift
|
||||
+ 4: Right Shift
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x8: Begin Keypress Conditional Block
|
||||
Code type 0x8 enters or skips a conditional block based on whether a key combination is pressed.
|
||||
|
||||
#### Encoding
|
||||
`8kkkkkkk`
|
||||
|
||||
+ k: Keypad mask to check against, see below.
|
||||
|
||||
Note that for multiple button combinations, the bitmasks should be ORd together.
|
||||
|
||||
#### Keypad Values
|
||||
Note: This is the direct output of `hidKeysDown()`.
|
||||
|
||||
+ 0000001: A
|
||||
+ 0000002: B
|
||||
+ 0000004: X
|
||||
+ 0000008: Y
|
||||
+ 0000010: Left Stick Pressed
|
||||
+ 0000020: Right Stick Pressed
|
||||
+ 0000040: L
|
||||
+ 0000080: R
|
||||
+ 0000100: ZL
|
||||
+ 0000200: ZR
|
||||
+ 0000400: Plus
|
||||
+ 0000800: Minus
|
||||
+ 0001000: Left
|
||||
+ 0002000: Up
|
||||
+ 0004000: Right
|
||||
+ 0008000: Down
|
||||
+ 0010000: Left Stick Left
|
||||
+ 0020000: Left Stick Up
|
||||
+ 0040000: Left Stick Right
|
||||
+ 0080000: Left Stick Down
|
||||
+ 0100000: Right Stick Left
|
||||
+ 0200000: Right Stick Up
|
||||
+ 0400000: Right Stick Right
|
||||
+ 0800000: Right Stick Down
|
||||
+ 1000000: SL
|
||||
+ 2000000: SR
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0x9: Perform Arithmetic
|
||||
Code type 0x9 allows performing arithmetic on registers.
|
||||
|
||||
#### Register Arithmetic Encoding
|
||||
`9TCRS0s0`
|
||||
|
||||
+ T: Width of arithmetic operation (1, 2, 4, or 8 bytes).
|
||||
+ C: Arithmetic operation to apply, see below.
|
||||
+ R: Register to store result in.
|
||||
+ S: Register to use as left-hand operand.
|
||||
+ s: Register to use as right-hand operand.
|
||||
|
||||
#### Immediate Value Arithmetic Encoding
|
||||
`9TCRS100 VVVVVVVV (VVVVVVVV)`
|
||||
|
||||
+ T: Width of arithmetic operation (1, 2, 4, or 8 bytes).
|
||||
+ C: Arithmetic operation to apply, see below.
|
||||
+ R: Register to store result in.
|
||||
+ S: Register to use as left-hand operand.
|
||||
+ V: Value to use as right-hand operand.
|
||||
|
||||
#### Arithmetic Types
|
||||
+ 0: Addition
|
||||
+ 1: Subtraction
|
||||
+ 2: Multiplication
|
||||
+ 3: Left Shift
|
||||
+ 4: Right Shift
|
||||
+ 5: Logical And
|
||||
+ 6: Logical Or
|
||||
+ 7: Logical Not (discards right-hand operand)
|
||||
+ 8: Logical Xor
|
||||
+ 9: None/Move (discards right-hand operand)
|
||||
+ 10: Float Addition, T==4 single T==8 double
|
||||
+ 11: Float Subtraction, T==4 single T==8 double
|
||||
+ 12: Float Multiplication, T==4 single T==8 double
|
||||
+ 13: Float Division, T==4 single T==8 double
|
||||
---
|
||||
|
||||
### Code Type 0xA: Store Register to Memory Address
|
||||
Code type 0xA allows writing a register to memory.
|
||||
|
||||
#### Encoding
|
||||
`ATSRIOxa (aaaaaaaa)`
|
||||
|
||||
+ T: Width of memory write (1, 2, 4, or 8 bytes).
|
||||
+ S: Register to write to memory.
|
||||
+ R: Register to use as base address.
|
||||
+ I: Increment register flag (0 = do not increment R, 1 = increment R by T).
|
||||
+ O: Offset type, see below.
|
||||
+ x: Register used as offset when O is 1, Memory type when O is 3, 4 or 5.
|
||||
+ a: Value used as offset when O is 2, 4 or 5.
|
||||
|
||||
#### Offset Types
|
||||
+ 0: No Offset
|
||||
+ 1: Use Offset Register
|
||||
+ 2: Use Fixed Offset
|
||||
+ 3: Memory Region + Base Register
|
||||
+ 4: Memory Region + Relative Address (ignore address register)
|
||||
+ 5: Memory Region + Relative Address + Offset Register
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xB: Reserved
|
||||
Code Type 0xB is currently reserved for future use.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xC-0xF: Extended-Width Instruction
|
||||
Code Types 0xC-0xF signal to the VM to treat the upper two nybbles of the first dword as instruction type, instead of just the upper nybble.
|
||||
|
||||
This reserves an additional 64 opcodes for future use.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xC0: Begin Register Conditional Block
|
||||
Code type 0xC0 performs a comparison of the contents of a register and another value. This code support multiple operand types, see below.
|
||||
|
||||
If the condition is not met, all instructions until the appropriate conditional block terminator are skipped.
|
||||
|
||||
#### Encoding
|
||||
```
|
||||
C0TcSX##
|
||||
C0TcS0Ma aaaaaaaa
|
||||
C0TcS1Mr
|
||||
C0TcS2Ra aaaaaaaa
|
||||
C0TcS3Rr
|
||||
C0TcS400 VVVVVVVV (VVVVVVVV)
|
||||
C0TcS5X0
|
||||
```
|
||||
|
||||
+ T: Width of memory write (1, 2, 4, or 8 bytes).
|
||||
+ c: Condition to use, see below.
|
||||
+ S: Source Register.
|
||||
+ X: Operand Type, see below.
|
||||
+ M: Memory Type (operand types 0 and 1).
|
||||
+ R: Address Register (operand types 2 and 3).
|
||||
+ a: Relative Address (operand types 0 and 2).
|
||||
+ r: Offset Register (operand types 1 and 3).
|
||||
+ X: Other Register (operand type 5).
|
||||
+ V: Value to compare to (operand type 4).
|
||||
|
||||
#### Operand Type
|
||||
+ 0: Memory Base + Relative Offset
|
||||
+ 1: Memory Base + Offset Register
|
||||
+ 2: Register + Relative Offset
|
||||
+ 3: Register + Offset Register
|
||||
+ 4: Static Value
|
||||
+ 5: Other Register
|
||||
|
||||
#### Conditions
|
||||
+ 1: >
|
||||
+ 2: >=
|
||||
+ 3: <
|
||||
+ 4: <=
|
||||
+ 5: ==
|
||||
+ 6: !=
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xC1: Save or Restore Register
|
||||
Code type 0xC1 performs saving or restoring of registers.
|
||||
|
||||
#### Encoding
|
||||
`C10D0Sx0`
|
||||
|
||||
+ D: Destination index.
|
||||
+ S: Source index.
|
||||
+ x: Operand Type, see below.
|
||||
|
||||
#### Operand Type
|
||||
+ 0: Restore register
|
||||
+ 1: Save register
|
||||
+ 2: Clear saved value
|
||||
+ 3: Clear register
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xC2: Save or Restore Register with Mask
|
||||
Code type 0xC2 performs saving or restoring of multiple registers using a bitmask.
|
||||
|
||||
#### Encoding
|
||||
`C2x0XXXX`
|
||||
|
||||
+ x: Operand Type, see below.
|
||||
+ X: 16-bit bitmask, bit i == save or restore register i.
|
||||
|
||||
#### Operand Type
|
||||
+ 0: Restore register
|
||||
+ 1: Save register
|
||||
+ 2: Clear saved value
|
||||
+ 3: Clear register
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xC3: Read or Write Static Register
|
||||
Code type 0xC3 reads or writes a static register with a given register.
|
||||
|
||||
#### Encoding
|
||||
`C3000XXx`
|
||||
|
||||
+ XX: Static register index, 0x00 to 0x7F for reading or 0x80 to 0xFF for writing.
|
||||
+ x: Register index.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xC4: Begin Extended Keypress Conditional Block
|
||||
Code type 0xC4 enters or skips a conditional block based on whether a key combination is pressed.
|
||||
|
||||
#### Encoding
|
||||
`C4r00000 kkkkkkkk kkkkkkkk`
|
||||
|
||||
+ r: Auto-repeat, see below.
|
||||
+ kkkkkkkkkk: Keypad mask to check against output of `hidKeysDown()`.
|
||||
|
||||
Note that for multiple button combinations, the bitmasks should be OR'd together.
|
||||
|
||||
#### Auto-repeat
|
||||
|
||||
+ 0: The conditional block executes only once when the keypad mask matches. The mask must stop matching to reset for the next trigger.
|
||||
+ 1: The conditional block executes as long as the keypad mask matches.
|
||||
|
||||
#### Keypad Values
|
||||
Note: This is the direct output of `hidKeysDown()`.
|
||||
|
||||
+ 00000000 00000001: A
|
||||
+ 00000000 00000002: B
|
||||
+ 00000000 00000004: X
|
||||
+ 00000000 00000008: Y
|
||||
+ 00000000 00000010: Left Stick Pressed
|
||||
+ 00000000 00000020: Right Stick Pressed
|
||||
+ 00000000 00000040: L
|
||||
+ 00000000 00000080: R
|
||||
+ 00000000 00000100: ZL
|
||||
+ 00000000 00000200: ZR
|
||||
+ 00000000 00000400: Plus
|
||||
+ 00000000 00000800: Minus
|
||||
+ 00000000 00001000: Left
|
||||
+ 00000000 00002000: Up
|
||||
+ 00000000 00004000: Right
|
||||
+ 00000000 00008000: Down
|
||||
+ 00000000 00010000: Left Stick Left
|
||||
+ 00000000 00020000: Left Stick Up
|
||||
+ 00000000 00040000: Left Stick Right
|
||||
+ 00000000 00080000: Left Stick Down
|
||||
+ 00000000 00100000: Right Stick Left
|
||||
+ 00000000 00200000: Right Stick Up
|
||||
+ 00000000 00400000: Right Stick Right
|
||||
+ 00000000 00800000: Right Stick Down
|
||||
+ 00000000 01000000: SL Left Joy-Con
|
||||
+ 00000000 02000000: SR Left Joy-Con
|
||||
+ 00000000 04000000: SL Right Joy-Con
|
||||
+ 00000000 08000000: SR Right Joy-Con
|
||||
+ 00000000 10000000: Top button on Poké Ball Plus (Palma) controller
|
||||
+ 00000000 20000000: Verification
|
||||
+ 00000000 40000000: B button on Left NES/HVC controller in Handheld mode
|
||||
+ 00000000 80000000: Left C button in N64 controller
|
||||
+ 00000001 00000000: Up C button in N64 controller
|
||||
+ 00000002 00000000: Right C button in N64 controller
|
||||
+ 00000004 00000000: Down C button in N64 controller
|
||||
|
||||
### Code Type 0xF0: Double Extended-Width Instruction
|
||||
Code Type 0xF0 signals to the VM to treat the upper three nybbles of the first dword as instruction type, instead of just the upper nybble.
|
||||
|
||||
This reserves an additional 16 opcodes for future use.
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xFF0: Pause Process
|
||||
Code type 0xFF0 pauses the current process.
|
||||
|
||||
#### Encoding
|
||||
`FF0?????`
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xFF1: Resume Process
|
||||
Code type 0xFF1 resumes the current process.
|
||||
|
||||
#### Encoding
|
||||
`FF1?????`
|
||||
|
||||
---
|
||||
|
||||
### Code Type 0xFFF: Debug Log
|
||||
Code type 0xFFF writes a debug log to the SD card under the folder `/atmosphere/cheat_vm_logs/`.
|
||||
|
||||
#### Encoding
|
||||
```
|
||||
FFFTIX##
|
||||
FFFTI0Ma aaaaaaaa
|
||||
FFFTI1Mr
|
||||
FFFTI2Ra aaaaaaaa
|
||||
FFFTI3Rr
|
||||
FFFTI4X0
|
||||
```
|
||||
|
||||
+ T: Width of memory write (1, 2, 4, or 8 bytes).
|
||||
+ I: Log id.
|
||||
+ X: Operand Type, see below.
|
||||
+ M: Memory Type (operand types 0 and 1).
|
||||
+ R: Address Register (operand types 2 and 3).
|
||||
+ a: Relative Address (operand types 0 and 2).
|
||||
+ r: Offset Register (operand types 1 and 3).
|
||||
+ X: Value Register (operand type 4).
|
||||
|
||||
#### Operand Type
|
||||
+ 0: Memory Base + Relative Offset
|
||||
+ 1: Memory Base + Offset Register
|
||||
+ 2: Register + Relative Offset
|
||||
+ 3: Register + Offset Register
|
||||
+ 4: Register Value
|
||||
@@ -1,125 +0,0 @@
|
||||
# Configurations
|
||||
Atmosphère provides a variety of customizable configurations to better adjust to users' needs.
|
||||
|
||||
## stratosphere.ini
|
||||
This is the configuration file used by fusée for configuring user-space system modules.
|
||||
This file is located under the `/atmosphere/config/` folder on your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
|
||||
|
||||
### Configuring "nogc" Protection
|
||||
"nogc" is a feature provided by fusée-secondary which disables the Nintendo Switch's Game Card reader. Its purpose is to prevent the reader from being updated when the console has been updated, without burning fuses, from a lower firmware version. More specifically, from firmware versions 4.0.0 or 9.0.0 which introduced updates to the Game Card reader's firmware. By default, Atmosphère will protect the Game Card reader automatically, but you are free to change it.
|
||||
|
||||
To change its functionality, add the following line to the `stratosphere` section and change the value of `X` according to the following list:
|
||||
```
|
||||
[stratosphere]
|
||||
nogc = X
|
||||
```
|
||||
```
|
||||
1 = force-enable nogc, so Atmosphère will always disable the Game Card reader.
|
||||
0 = force-disable nogc, so Atmosphère will always enable the Game Card reader.
|
||||
```
|
||||
|
||||
## Adding a Custom Boot Splashscreen
|
||||
Atmosphère provides its own default splashscreen which is displayed at boot time. However, this can be replaced at will.
|
||||
|
||||
Boot splash screens must be 1280x720 resolution.
|
||||
|
||||
A script can be found inside the source tree (`/utilities/insert_splash_screen.py`) for inserting a custom splash screen into a release binary.
|
||||
|
||||
To do so, execute the following command on the script:
|
||||
`python insert_splash_screen.py <path to your splash screen image> <path to /atmosphere/package3 on your SD card>`
|
||||
|
||||
## emummc.ini
|
||||
This is the configuration file used for the [emummc](../components/emummc.md) component.
|
||||
This file is located under the `/emuMMC/` folder on your SD card.
|
||||
|
||||
Please refer to the project's repository [here](https://github.com/m4xw/emuMMC) for detailed instructions and documentation.
|
||||
|
||||
## exosphere.ini
|
||||
This is the configuration file used by exosphère.
|
||||
This file is located in the root of your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
|
||||
|
||||
### Configuring Debugging Modes
|
||||
By default, Atmosphère signals to the Horizon kernel that debugging is enabled while leaving usermode debugging disabled, but this can cause undesirable side-effects. If you wish to change this behavior, go to the `exosphere` section and change the value of `X` according to the following list.
|
||||
```
|
||||
[exosphere]
|
||||
debugmode = X
|
||||
debugmode_user = X
|
||||
```
|
||||
```
|
||||
1 = enable
|
||||
0 = disable
|
||||
```
|
||||
|
||||
### Blanking PRODINFO
|
||||
Atmosphère provides a way for users to blank their factory installed calibration data (known as PRODINFO) in either emulated or system eMMC environments. You can find more detailed information on this inside the respective template file. Usage of this configuration is not encouraged.
|
||||
|
||||
## override_config.ini
|
||||
This file is located under the `/atmosphere/config/` folder on your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
|
||||
|
||||
### Overrides Format
|
||||
Overrides are parsed from the `/atmosphere/config/override_config.ini` file during the boot process.
|
||||
|
||||
By default `override_config.ini` is not configured. It can be used to select the behavior of certain buttons and bind them to functionalities such as launching the Homebrew Menu or enabling the cheat code manager.
|
||||
|
||||
You can modify the override_key entries in `override_config.ini` with this list of valid buttons:
|
||||
| Formal Name | .ini Name |
|
||||
| ----------- | --------- |
|
||||
| A Button | A |
|
||||
| B Button | B |
|
||||
| X Button | X |
|
||||
| Y Button | Y |
|
||||
| Left Stick | LS |
|
||||
| Right Stick | RS |
|
||||
| L Button | L |
|
||||
| R Button | R |
|
||||
| ZL Button | ZL |
|
||||
| ZR Button | ZR |
|
||||
| + Button | PLUS |
|
||||
| - Button | MINUS |
|
||||
| Left Dpad | DLEFT |
|
||||
| Up Dpad | DUP |
|
||||
| Right Dpad | DRIGHT |
|
||||
| Down Dpad | DDOWN |
|
||||
| SL Button | SL |
|
||||
| SR Button | SR |
|
||||
|
||||
To invert the behavior of the override key, place an exclamation point in front of whatever button you wish to use. It will launch the actual game while holding down that button, instead of going into the Homebrew Menu. For example, `override_key=!R` will run the game only while holding down R when launching it, otherwise it will boot into the Homebrew Menu. Afterwards you may reinsert your SD card into your Switch and boot into Atmosphère as you normally would. You should now be able to boot into the Homebrew Menu by launching your designated program of choice.
|
||||
|
||||
## system_settings.ini
|
||||
This file is located under the `/atmosphere/config/` folder on your SD card and a default template can be found inside the `/atmosphere/config_templates/` folder.
|
||||
|
||||
### Settings Format
|
||||
Atmosphère provides a way to override the firmware debug settings used by the system. These can be parsed from the `/atmosphere/config/system_settings.ini` file during the boot process. This file is a normal ini file, with some specific interpretations.
|
||||
|
||||
The standard representation of a setting's identifier takes the form `name!key`. This is represented within `system_settings.ini` as a section `name`, with an entry `key`. For example:
|
||||
```
|
||||
[name]
|
||||
key = ...
|
||||
```
|
||||
|
||||
Settings can have variable types (strings, integral values, byte arrays, etc). To accommodate this, `system_settings.ini` must store values as a `type_identifier!value_store` pair. A number of different types are supported, with identifiers detailed below.
|
||||
Please note that a malformed value string will cause a fatal error to occur on boot. A full example of a custom setting is given below (setting `eupld!upload_enabled = 0`), for posterity:
|
||||
```
|
||||
[eupld]
|
||||
upload_enabled = u8!0x0
|
||||
```
|
||||
|
||||
#### Supported Types
|
||||
* Strings
|
||||
* Type identifiers: `str`, `string`
|
||||
* The value string is used directly as the setting, with null terminator appended.
|
||||
* Integral types
|
||||
* Type identifiers: `u8`, `u16`, `u32`, `u64`
|
||||
* The value string is parsed via a call to `strtoul(value, NULL, 0)`.
|
||||
* Setting bitwidth is determined by the identifier (8 for 1 byte, 16 for 2 bytes, and so on).
|
||||
* Raw bytes
|
||||
* Type identifiers: `hex`, `bytes`
|
||||
* The value string is parsed as a hexadecimal string.
|
||||
* The value string must be of even length, or a fatal error will be thrown on parse.
|
||||
|
||||
## Content Specific Flags
|
||||
Atmosphère supports customizing CFW behavior based on the presence of `flags` on the SD card.
|
||||
|
||||
The following flags are supported on a per-program basis, by placing `<flag_name>.flag` inside `/atmosphere/contents/<program_id>/flags/`:
|
||||
+ `boot2`, which indicates that the program should be launched during the `boot2` process.
|
||||
+ `redirect_save`, which indicates that the program wants its savedata to be redirected to the SD card.
|
||||
@@ -1,53 +0,0 @@
|
||||
# DNS.mitm
|
||||
As of 0.18.0, atmosphère provides a mechanism for redirecting DNS resolution requests.
|
||||
|
||||
By default, atmosphère redirects resolution requests for official telemetry servers, redirecting them to a loopback address.
|
||||
|
||||
## Hosts files
|
||||
|
||||
DNS.mitm can be configured through the usage of a slightly-extended `hosts` file format, which is parsed only once on system startup.
|
||||
|
||||
In particular, hosts files parsed by DNS.mitm have the following extensions to the usual format:
|
||||
+ `*` is treated as a wildcard character, matching any collection of 0 or more characters wherever it occurs in a hostname.
|
||||
+ `%` is treated as a stand-in for the value of `nsd!environment_identifier`. This is always `lp1`, on production devices.
|
||||
|
||||
If multiple entries in a host file match a domain, the last-defined match is used.
|
||||
|
||||
Please note that homebrew may trigger a hosts file re-parse by sending the extension IPC command 65000 ("AtmosphereReloadHostsFile") to a connected `sfdnsres` session.
|
||||
|
||||
### Hosts file selection
|
||||
|
||||
Atmosphère will try to read hosts from the following file paths, in order, stopping once it successfully performs a file read:
|
||||
|
||||
+ (emummc only) `/atmosphere/hosts/emummc_%04lx.txt`, formatted with the emummc's id number (see `emummc.ini`).
|
||||
+ (emummc only) `/atmosphere/hosts/emummc.txt`.
|
||||
+ (sysmmc only) `/atmosphere/hosts/sysmmc.txt`.
|
||||
+ `/atmosphere/hosts/default.txt`
|
||||
|
||||
If `/atmosphere/hosts/default.txt` does not exist, atmosphère will create it to contain the defaults.
|
||||
|
||||
### Atmosphère defaults
|
||||
|
||||
By default, atmosphère's default redirections are parsed **in addition to** the contents of the loaded hosts file.
|
||||
|
||||
This is equivalent to thinking of the loaded hosts file as having the atmosphère defaults prepended to it.
|
||||
|
||||
This setting is considered desirable, because it minimizes the telemetry risks if a user forgets to update a custom hosts file on a system update which changes the telemetry servers.
|
||||
|
||||
This behavior can be opted-out from by setting `atmosphere!add_defaults_to_dns_hosts = u8!0x0` in `system_settings.ini`.
|
||||
|
||||
The current default redirections are:
|
||||
|
||||
```
|
||||
# Nintendo telemetry servers
|
||||
127.0.0.1 receive-%.dg.srv.nintendo.net receive-%.er.srv.nintendo.net
|
||||
```
|
||||
|
||||
## Debugging
|
||||
|
||||
On startup (or on hosts file re-parse), DNS.mitm will log both what hosts file it selected and the contents of all redirections it parses to `/atmosphere/logs/dns_mitm_startup.log`.
|
||||
|
||||
In addition, if the user sets `atmosphere!enable_dns_mitm_debug_log = u8!0x1` in `system_settings.ini`, DNS.mitm will log all requests to GetHostByName/GetAddrInfo to `/atmosphere/logs/dns_mitm_debug.log`. All redirections will be noted when they occur.
|
||||
|
||||
## Opting-out of DNS.mitm entirely
|
||||
If you wish to disable DNS.mitm entirely, `system_settings.ini` can be edited to set `atmosphere!enable_dns_mitm = u8!0x0`.
|
||||
@@ -1,21 +0,0 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) Atmosphère-NX
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
@@ -1,32 +0,0 @@
|
||||
# Atmosphère
|
||||
Atmosphère is a work-in-progress customized firmware for the Nintendo Switch. Its design principle consists of a multi-layered approach where each layer replaces/modifies a different component of the Nintendo Switch's system.
|
||||
|
||||
## Components
|
||||
Atmosphère provides six core components, mimicking to some degree the various layers of the Earth's atmosphere:
|
||||
+ [fusée](components/fusee.md)
|
||||
+ [exosphère](components/exosphere.md)
|
||||
+ [thermosphère](components/thermosphere.md)
|
||||
+ [mesosphère](components/mesosphere.md)
|
||||
+ [stratosphère](components/stratosphere.md)
|
||||
+ [troposphère](components/troposphere.md)
|
||||
|
||||
Additionally, Atmosphère also provides the following secondary components:
|
||||
+ [emummc](components/emummc.md)
|
||||
+ [libraries](components/libraries.md)
|
||||
|
||||
## Features
|
||||
Atmosphère provides several original features which add or expand functionalities for the customized firmware environment:
|
||||
+ [Cheats](features/cheats.md)
|
||||
+ [Configurations](features/configurations.md)
|
||||
|
||||
## Building Atmosphère
|
||||
A guide to building Atmosphère can be found [here](building.md).
|
||||
|
||||
## Upcoming Features
|
||||
A list of planned features for Atmosphère can be found [here](roadmap.md).
|
||||
|
||||
## Release History
|
||||
A changelog of previous versions of Atmosphère can be found [here](changelog.md).
|
||||
|
||||
## Frequently Asked Questions
|
||||
Answers to one or more frequently asked questions may be found [here](faq.md).
|
||||
@@ -1,60 +0,0 @@
|
||||
# Planned Features
|
||||
atmosphère has a number of features that are either works-in-progress or planned. Please note that while time-estimates are given, they are loose, and things may be completed sooner or later than advertised.
|
||||
|
||||
The following descriptions were last updated on January 14th, 2021
|
||||
|
||||
## tma reimplementation
|
||||
* **Description** tma ("target manager agent") is a system module that manages communication between the Switch and a client PC. Atmosphere's implementation will allow homebrew on the switch to communicate with a connected PC to do various operations such as exchanging data or interacting with files. It will also serve as the communicator for Atmosphère's planned debugger. This will also include PC-side software for interacting with the Switch.
|
||||
* **Development Status**: Planned. Switch-side code is fully implemented but needs heavy refactoring/rebasing, as the code was originally authored in 2018.
|
||||
* **Estimated Time**: 2021-2022.
|
||||
|
||||
## dmnt.gen2 reimplementation
|
||||
* **Description**: A reimplementation of the Switch's debug monitor, dmnt will provide an interface for debugging applications or system modules running on the Switch. This will include a gdbstub for debugging actively-running system components or applications.
|
||||
* **Development Status**: Planned
|
||||
* **Estimated Time**: 2021-2022
|
||||
|
||||
## fs reimplementation
|
||||
* **Description**: Following mesosphère's completion, atmosphère will have reimplemented all components of the BootImagePackage firmware except for the filesystem services system module. Reimplementing fs will allow for fixing Nintendo bugs (such as corruption when using exFAT filesystems and encoding inconsistencies with UTF-8 and Shift-JIS).
|
||||
* **Development Status**: Planned.
|
||||
* **Estimated Time**: 2021-2022.
|
||||
|
||||
## settings reimplementation
|
||||
* **Description**: A planned reimplementation of the settings system module, and with it a removal of the settings mitm. This will greatly simplify atmosphère's boot process, and will allow much more flexible control over the various system settings.
|
||||
* **Development Status**: Pending development by Adubbz.
|
||||
* **Estimated Time**: Unclear, pending developer availability.
|
||||
|
||||
## thermosphère
|
||||
* **Description**: A general-purpose hypervisor, thermosphère will enable the virtualization of the Switch's operating system; this is planned to enable debugging of the Switch's kernel.
|
||||
* **Development Status**: Pending development by TuxSH.
|
||||
* **Estimated Time**: Unclear, pending developer availability.
|
||||
|
||||
## other planned features
|
||||
* **Description**: General system stability improvements to enhance the user's experience.
|
||||
* **Development Status**: Undergoing active development by all members of the atmosphère team.
|
||||
* **Estimated Time**: June 15th.
|
||||
|
||||
# Completed features
|
||||
|
||||
The following features were previously included under the planned features section and are now complete.
|
||||
|
||||
Please note that this is not an exhaustive list of features present in atmosphère, and only serves to indicate what from the above has been completed.
|
||||
|
||||
## system updater homebrew
|
||||
* **Description**: A user homebrew making use of the new system updater api, so that users can actually use the new api in practice.
|
||||
* **Completion Time**: July 2020
|
||||
|
||||
## system updater api
|
||||
* **Description**: A planned extension api for stratosphere (tenatively `ams:su`), this will provide an interface for homebrew to safely install system upgrades or downgrades. This will allow for much more easily transitioning safely between different versions of the operating system.
|
||||
* **Completion Time**: June 2020
|
||||
|
||||
## exosphere re-write
|
||||
* **Description**: exosphère, atmosphère's reimplementation of Horizon's Secure Monitor, was the first component authored for the project in early 2018. It is written in C, and in a style very different from the rest of atmosphère's code. In addition, exosphère was written to conform to constraints that no longer apply in an environment where it is not launched from the web browser, and where using a custom firmware image to orchestrate wake-from-sleep is possible. exosphère currently uses all but 1 KB of the space available to it, putting it at risk of breaking as future firmware updates are supported. A re-write will solve these issues.
|
||||
* **Completion Time**: June 2020
|
||||
|
||||
## mesosphere
|
||||
* **Description**: mesosphère is a reimplementation of the Horizon operating system's Kernel. It aims to provide an open-source reference for Nintendo's code.
|
||||
* **Estimated Time**: September 2020
|
||||
|
||||
## ams-on-mariko
|
||||
* **Description**: Atmosphere cannot run as-is on Mariko hardware. A large number of changes are needed in many components. Although secure monitor support is complete in exosphere, additional work is needed on the bootloader and stratosphere sides as well. Mariko support will also require further design thought; atmosphere's debugging design heavily relies on reboot-to-payload and (more generally) the ability to perform warmboot bootrom hax at will. This is not possible on Mariko, and will require a new design/software support for whatever solution is chosen.
|
||||
* **Completion Time**: January 2021
|
||||
Reference in New Issue
Block a user