eglantine-cirakg/src/core/arm, branch nx2

Merge remote-tracking branch 'origin/fix/dynarmic-invalidate-code-page' into test/linux-all-prs

2026-11-01T18:25:47+00:00

Initial linux aarch64 commit

2026-10-31T22:04:07+00:00

This adds an experimental aarch64 platform in Github Actions (with and without PGO) to compile for aarch64 on Linux. Signed-off-by: Omar Mahboubi

dynarmic: drop the cached code page when a range is invalidated

2026-10-31T12:06:22+00:00

MemoryReadCode keeps the last code page it read, and only an ISB, an IC instruction or a full cache clear reset it. InvalidateCacheRange did not, so blocks recompiled after a range was invalidated could still decode the old instructions when that page was the cached one. The gdbstub hits this on every breakpoint: inserting or removing one writes the instruction and invalidates its range, so breakpoints were skipped, fired after removal, or single steps ran from stale code.

nx2: run the guest counter at 31.25 MHz for Switch 2 titles

2026-10-30T06:31:58+00:00

The Switch 2 counter runs at 31.25 MHz and its SDK converts ticks with that constant: Mario Kart World's sdk builds 31,250,000 in nn::os::GetSystemTickFrequency, TickManager::ConvertToTimeSpan and TickManager::ConvertToTick (19.2 MHz appears nowhere). Eglantine counted at the Switch 1 rate for every title, so every tick-based time in a Switch 2 game was off by 1.63x: elapsed times read short, and a deadline of one 60 Hz frame converted to ticks waited ~27 ms. The wall clock now has a guest counter frequency, set at boot: 31.25 MHz for Switch 2 programs, 19.2 MHz otherwise, EDEN_NX2_CNTFRQ= to force one. CNTPCT reads, CNTFRQ_EL0, svcGetSystemTick, thread tick counts and the time services' tick conversions follow it, and the CNTPCT spin detection keeps its ~1.7 us threshold. Mario Kart World, title screen and attract demo, 180 s, same build: frame times unchanged (17-19 ms once warm), process CPU time 848 s instead of 930 s.

core: pause in guest loops that poll the system counter

2026-10-30T00:49:47+00:00

Title 1's main thread reads CNTPCT ~17 million times a second while it waits for the GPU (~23% of its samples are the counter read). On an SMT core that spin takes resources from the sibling thread, often the GPU thread. Two reads within ~1.7 us of each other now execute two PAUSE instructions first; the guest sees the same values. EDEN_NX2_CNTPCT_PAUSE=0 turns it off.

nx2: frame-locked input replay and quieter logs

2026-10-28T08:56:14+00:00

EDEN_NX2_KEY_RECORD records keyboard transitions as "f:code" against a global count of guest presents; EDEN_NX2_KEY_SCRIPT replays them on the same frames (or by seconds, as before), so a played session reproduces exactly. Debug aids: the PC/LR/SP of the first unmapped reads, NSO load addresses, EDEN_NX2_IPC_SUMMARY (request counts every 5 s), EDEN_NX2_FORCE_LOD0. Unmapped-access logging is rate limited and the per-draw/semaphore spam is demoted, so long sessions stay under the log size cap.

[nce] handles duplicate NCE interrupts (#4530)

2026-10-26T16:24:45+00:00

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md). - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- Another crash observed in Ender Magnolia: A deadlock caused between CPUCore_0/GPU/GPUFencingThread. CPUCore_0 waits for GPU work inside the NCE fault handler GPU waits for the syncpoint mutex GPUFencingThread holds that mutex while waiting for CPUCore_0 NCE interrupt lock The fix makes duplicate interrupts return before acquiring the lock, while the first request keeps its original behavior. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4530 Reviewed-by: CamilleLaVey Reviewed-by: Shinmegumi

Fix aarch and android builds (#4576)

2026-10-25T09:03:16+00:00

[patcher, ro, settings] runtime tls patch (#4492) optimization and nuke toggle (#4502) (#4523)

2026-10-15T10:13:17+00:00

- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions). - [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md) - [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability. ------------------- This is a follow up for the biomutant fix. By the time i knew it was shallow, coz i was running patchtext routine even for svc and modules, causing a routine which were needed to run 14 times to run 4000+ instead. Since some perf loss was reported in 30 sep nightly, and it caused ac3r to not boot, we had added a temp toggle, which is now being removed as optimizations + fix are in. Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4523 Reviewed-by: lizzie Reviewed-by: MaranBr

[dynarmic] Coalesce non-exclusive Write/Read fallback functions (#4158)

2026-09-18T23:39:46+00:00

the general idea is to have a common procedure form whom to call this way theres less "jumping around" for values of different sizes additionally this **should** allow for better codegen since most of the u8,u16,u32,u64 can be held within a u64 theoretically this means that you could deifne callbacks in suck a way that it's essentially as costly as a `mov r64, m64` but that's not doable due to the fact we have to do translations... Is this a good change? Primarily aimed for x86 and ARM to benefit, but I suppose LooooooongArch64 can benefit too. Signed-off-by: lizzie Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4158 Reviewed-by: crueter Reviewed-by: MaranBr Reviewed-by: CamilleLaVey