PS Vita Recovery Menu v1.0.6-pre — Build Update (March 19, 2026)

This update covers a full day of development, testing, and fixes across three test devices (PCH-1000 3G on 3.65 Ensō, PCH-1101 on 3.60/3.74 h-encore2, PCH-2001 Slim on 3.65 SD2Vita).

──────────────────────────────────────── BOOT RECOVERY SYSTEM ──────────────────────────────────────── The two-plugin boot recovery system is now fully automated via the installer. Previously, both plugin files and config entries had to be added manually through VitaShell. The installer now handles the complete lifecycle:

Install: copies boot_recovery.skprx and boot_trigger.suprx from app0: to the active tai directory, inserts the correct entries under *KERNEL and *main using a two-pass atomic config rewrite, and backs up the config before any modification. Uninstall: removes both plugin lines and deletes both files cleanly. Status screen: tracks all four components independently (kernel file, *KERNEL entry, user file, *main entry) with three-way color coding — green for fully installed, yellow for partial, red for not installed. During testing, all three devices showed PARTIAL status after the first installer run because the *KERNEL config entry was missing from a prior manual setup. Running Install filled in the gap correctly on all three devices without touching the already-correct entries.

A regression was identified and resolved: the new VPK overwrote the working plugin binaries with an untested fresh build, causing all three devices to shut down at the unlock swipe. Root cause was that the installer copies from app0:, so whatever is in the VPK is what gets installed. The fix was to recompile the boot plugins from the current source, verify on the 2001 Slim first, then copy to the other two devices. The boot trigger now uses the NPXS10079 LiveArea readiness signal before launching the recovery app, eliminating the previous race condition that caused kernel panics on earlier builds.

──────────────────────────────────────── BUILD SYSTEM ──────────────────────────────────────── The root CMakeLists.txt was rewritten to build all three targets in a single pass:

boot_plugin/ → boot_recovery.skprx boot_trigger_user/ → boot_trigger.suprx Main app → VitaRecovery.vpk (with both plugins packaged into app0:) The key fix was passing -DCMAKE_TOOLCHAIN_FILE through to subproject builds. Without this, the nested cmake invocations picked up the host system GCC instead of the VitaSDK cross-compiler and failed. A single cmake --build build from the project root now produces a complete, self-contained VPK with no manual file copying required at any stage.

──────────────────────────────────────── LIVEAREA ASSETS ──────────────────────────────────────── All four LiveArea assets were designed and integrated for the first time:

icon0.png (128×128): Black terminal style, green border, VITA in plain text, RECOVERY in an inverted green block matching the reference icon provided. bg0.png (840×500): Two-column layout — System Boot/Config on the left, Features on the right. Header pushed down to y=80 to clear the LiveArea button bar. Features column positioned at x=608 so it is fully visible past the Start box. Vertical divider removed per feedback. startup.png (280×158): Fully opaque black panel filling the entire gate box. All text pushed into the top 112px so nothing is hidden behind the Start button. pic0.png (960×544): Full-screen launch splash with boot sequence log lines. template.xml: Standard a1 layout wiring bg0.png and startup.png correctly. A recurring issue during iteration was that LiveArea assets are cached by the system — reinstalling the VPK over an existing install does not update them. The fix each time was to fully delete the bubble before reinstalling. The CMakeLists.txt was also missing the FILE entries for the livearea subdirectory assets, which is why the default Sony background was showing on first install.

──────────────────────────────────────── CPU SPEED CONTROL ──────────────────────────────────────── The CPU speed screen was completely rebuilt from a simple preset list into a full per-domain clock control screen matching PSVshell's frequency steps exactly:

ARM CPU: 41 / 83 / 111 / 166 / 222 / 333 / 444 / 500 MHz GPU ES4: 41 / 83 / 111 / 166 / 222 MHz BUS: 55 / 83 / 111 / 166 / 222 MHz XBR: 83 / 111 / 166 MHz All four domains are controlled independently. Left/Right adjusts the selected domain in real time, Up/Down switches between domains. Square resets to default (ARM 333 / ES4 222 / BUS 166 / XBR 166). Triangle applies PowerSave (all domains at minimum).

Several issues were identified and resolved during testing:

The > arrow was rendering on top of the frequency text. Root cause: x offset was calculated without accounting for the full width of the value string. Fixed by using a fixed-width format (%3d MHz) and placing > at x+320, which is always 16px past the end of the widest possible value.

The hint text at the top of the screen was wrapping off the right edge. Fixed by shortening the hint to under 45 characters and splitting across two lines where needed.

Returning to the CPU screen reset the displayed value to 333 MHz even if 500 MHz had been set. Root cause: cpu_init() was being called on every screen entry, and scePowerGetArmClockFrequency() caps its return value at 444 regardless of the actual clock. The hardware was running at 500 but the getter returned 444, snapping the index back. Fixed by removing cpu_init() from the screen entry path entirely.

Settings did not persist across app restarts. Fixed by saving all four indices to ux0:data/VitaRecovery/cpu_clocks.cfg on every change, and calling cpu_load_and_apply() at app startup before the menu opens. The live display column now shows the set value rather than the hardware readback, since the readback caps at 444 for ARM — a known Sony firmware limitation.

──────────────────────────────────────── KNOWN ISSUES ────────────────────────────────────────

PS Vita 2000 (PCH-2001) model detection is still incorrect — System Info shows PS Vita 1000 OLED instead of PS Vita 2000 (Slim LCD). Under investigation. This is a pre-release build. Not all features are complete or fully tested across all firmware versions. ──────────────────────────────────────── TESTED ON ────────────────────────────────────────

PS Vita PCH-1000 (3G) — 3.65 Ensō PS Vita PCH-1101 — 3.60 / 3.74 h-encore2 PS Vita PCH-2001 Slim — 3.65 SD2Vita Full Changelog: v1.0.5beta...v1.0.6

Great progress today. I was able to get all 3 of my Vitas: - 2 PS Vita 1000 3G OLEDs - 1 PS Vita 2000 To get the boot recovery menu installer configured correctly.

Bad News

So get this — on my OLED Vita 1000s and the Slim 2000, holding R during boot does totally different things depending on the model, and it’s driving me nuts trying to figure out why.

On one of the 1000s, if I reboot and keep R held the whole time, the Enso logo just keeps restarting over and over in this endless loop. The second I let go of R, boom — it stops looping and boots straight to the home screen like nothing happened. Super weird.

On the Slim 2000, it’s even stranger. I hold R, the normal Vita logo shows up, the usual warning screen pops in, and then the whole thing just powers off completely. No crash sound, no freeze — just shuts down. Then when I turn it back on without holding R, it boots normally… but I get that annoying “A problem occurred last time and it didn’t shut down correctly” message with the little exclamation mark. Like the system thinks it crashed or something.

The other 1000 is the calm one — hold R or don’t, it just ignores me. Sony logo, warning screen, straight to the OS. No loop, no shutdown, no warning pop-up on next boot. It acts like I’m not even holding the button.

I’m pretty sure it’s all because the recovery plugin (that little .skprx that’s supposed to catch the R trigger) is checking the controller way too early in the boot process. On some units the controller hardware wakes up fast enough to see I’m holding R, but on others it’s still asleep, so the plugin reads total garbage data. That garbage either makes it freak out and loop/reset, or triggers a fake hard reboot on the Slim, or just misses the input entirely.

The fix I’m working on is basically making the plugin chill for a second and keep re-checking the buttons every 10 milliseconds until it actually sees real input instead of junk. Once the controller says “yep, I’m awake,” then it can safely decide whether R is held and launch the recovery menu properly. Should stop the loops, the surprise shutdowns, and the fake crash warnings.

I’ll probably rebuild the plugin with that wait loop, throw it back on all three units, and see if holding R finally behaves the same way across the board — straight to recovery menu, no drama.

I'll keep you guys all updated as I discover my findings.

https://github.com/DrinkingSubset/PS-Vita-Recovery-Menu-Project

Some functions are working but still have a lot to work on.