Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Kernel: reimplement memory management on physical FCRAM #4392
This PR consists several changes that are chained together, as listed below
Sorry that I can't split the commit according to this list, as they all depend on each other, and any intermediate commit would render the software unusable.
The original goal was part of global state elimination of the memory module, and decoupling kernel and video_core was part of it. However, this now turns into reimplementation of many parts in the memory system. As this touches the foundation of the entire system, it might break or fix games in many ways, so please do thorough test on all games with this PR as much as possible.
This code leaves a new global variable
This code change also have some (positive or negative) impacts in different aspects:
A little review of 3DS memory system, to help with those who are new to this part of code:
FCRAM (128MiB for O3DS, or 256MiB for N3DS) is the main memory chip in 3DS for general purpose usage. It is divided into three regions: APPICATION, SYSTM and BASE. A program is allowed to allocate memory in one of the three region. (For example games are always in the APPLICATION region). Inside one region, there are two kinds of memory that can be allocated: (regular) heap and linear heap.
(Regular) heap is allocated starting from the end of the memory region, and growing down. They are mostly for application private use, and sometimes for software-based memory sharing (with other process using SharedMemory, for example). They can be mapped to anywhere inside
Linear heap is allocated starting from the beginning of the memory region, and growing up. They are mostly for hardware-based memory sharing (with GPU, DMA etc.), but can also be used privately as well. They can be mapped to the linear heap virtual memory region (
Pushed a commit that should fix Smash. I also find a new question: is TLS page memory usage reported by GetProcessInfo? Because I found that smash also reserves another unnecessary page when allocating memory, which can be only explained by the fact that we reports an additional page in GetProcessInfo caused by TLS allocation.
Will do more hwtest soon.
Edit: GetProcessInfo would return larger value on hw than citra (> heap+linear+segments+TLS), and spawning more threads would add to that value more than just TLS page. HW value likely also includes other stuff like thread context region, so citra isn't accurate anyway. I'll leave things as is.
For archiving purposes:
Full log: citra_log.zip
Pokémon Virtual Console titles generate this log during booting: (The game still runs as usual though)
Full log: https://pastebin.com/fgbEfwEv
@Dragios As you showed to me yesterday, the master branch also has four lines of error about not mapping the shared memory. This PR simply replaced the log with some different text, so it is essentially not related to the PR.
I just tried a MHXX 1.4+v5 english patch and it works for me on this branch... now I am so confused.
As the original author of the patch doesn't release CIA directly, I suspect that there are some bad CIA packagers who released some faulty CIA, which contains some corrupted info inside. To those who use english patch and experienced the issue, does the patch you used work on 3DS? If not, I would simply not care about these patches.