mirror of
https://github.com/Atmosphere-NX/Atmosphere.git
synced 2024-11-26 22:02:15 +00:00
Bump version to 0.8.0
This commit is contained in:
parent
ed37706915
commit
bcdfc53d7d
2 changed files with 34 additions and 2 deletions
|
@ -18,7 +18,7 @@
|
||||||
#define ATMOSPHERE_VERSION_H
|
#define ATMOSPHERE_VERSION_H
|
||||||
|
|
||||||
#define ATMOSPHERE_RELEASE_VERSION_MAJOR 0
|
#define ATMOSPHERE_RELEASE_VERSION_MAJOR 0
|
||||||
#define ATMOSPHERE_RELEASE_VERSION_MINOR 7
|
#define ATMOSPHERE_RELEASE_VERSION_MINOR 8
|
||||||
#define ATMOSPHERE_RELEASE_VERSION_MICRO 5
|
#define ATMOSPHERE_RELEASE_VERSION_MICRO 0
|
||||||
|
|
||||||
#endif
|
#endif
|
|
@ -1,4 +1,36 @@
|
||||||
# Changelog
|
# Changelog
|
||||||
|
## 0.8.0
|
||||||
|
+ A custom `fatal` system module was added.
|
||||||
|
+ This re-implements and extends Nintendo's fatal module, with the following features:
|
||||||
|
+ Atmosphère's `fatal` does not create error reports.
|
||||||
|
+ Atmosphère's `fatal` draws a custom error screen, showing registers and a backtrace.
|
||||||
|
+ Atmosphère's `fatal` attempts to gather debugging info for all crashes, and not just ones that include info.
|
||||||
|
+ Atmosphère's `fatal` will attempt saving reports to the SD, if a crash report was not generated by `creport`.
|
||||||
|
+ Title flag handling was changed to prevent folder clutter.
|
||||||
|
+ Instead of living in `atmosphere/titles/<tid>/%s.flag`, flags are now located in `atmosphere/titles/<tid>/flags/%s.flag`
|
||||||
|
+ The old format will continue to be supported for some time, but is deprecated.
|
||||||
|
+ Flags can now be applied to HBL by placing them at `atmosphere/flags/hbl_%s.flag`.
|
||||||
|
+ Changes were made to the mitm API, greatly improving caller semantics.
|
||||||
|
+ `sm` now informs mitm services of a new session's process id, enabling custom handling based on title id/process id.
|
||||||
|
+ smhax is no longer enabled, because it is no longer needed and breaks significant functionality.
|
||||||
|
+ Users with updated HBL/homebrew should see no observable differences due to this change.
|
||||||
|
+ Functionality was added implementing basic protections for NAND from userland homebrew:
|
||||||
|
+ BOOT0 now has write protection for the BCT public key and keyblob regions.
|
||||||
|
+ The `ns` sysmodule is no longer allowed to write the BCT public keys; all other processes can.
|
||||||
|
+ This should prevent system updates from removing AutoRCM.
|
||||||
|
+ No processes should be allowed to write to the keyblob region.
|
||||||
|
+ By default, BIS partitions other than BOOT0 are now read-only, and CAL0 is neither readable nor writable.
|
||||||
|
+ Adding a `bis_write` flag for a title will allow it to write to BIS.
|
||||||
|
+ Adding a `cal_read` flag for a title will allow it to read CAL0.
|
||||||
|
+ An automatic backup is now made of CAL0 on boot.
|
||||||
|
+ `fs.mitm` maintains a file handle to this backup, so userland software cannot read it.
|
||||||
|
+ To facilitate this, `fs.mitm` now mitms all sessions for non-system modules; content overriding has been made separate from service interception.
|
||||||
|
+ Please note: these protections are basic, and sufficiently malicious homebrew ++can defeat them++.
|
||||||
|
+ Please be careful to only run homebrew software from sources that you trust.
|
||||||
|
+ Support was added for system version 6.2.0; our thanks to @motezazer for his invaluable help.
|
||||||
|
+ By default, new keys will automatically be derived without user input.
|
||||||
|
+ Support is also present for loading new keys from `atmosphere/prod.keys` or `atmosphere/dev.keys`
|
||||||
|
+ General system stability improvements to enhance the user's experience.
|
||||||
## 0.7.5
|
## 0.7.5
|
||||||
+ DRAM training was added to fusee-secondary, courtesy @hexkyz.
|
+ DRAM training was added to fusee-secondary, courtesy @hexkyz.
|
||||||
+ This greatly improves the speed of memory accesses during boot, resulting in a boot time that is ~200-400% faster.
|
+ This greatly improves the speed of memory accesses during boot, resulting in a boot time that is ~200-400% faster.
|
||||||
|
|
Loading…
Reference in a new issue