I’ve been reverse-engineering the InsydeH2O firmware of a Lenovo IdeaPad Gaming 3 15ARH05 with a Ryzen 7 4800H.

What started as a failed attempt to reveal the Advanced BIOS using Fn+R+N turned into a complete firmware-research project.

I extracted Lenovo’s official BIOS update, recovered the 16 MiB ROM, parsed the AMD PSP directory, reconstructed the firmware IFR and identified the hidden form-set visibility mechanism inside H2OFormBrowserDxe.

The latest result: I have now successfully exposed the hidden Advanced, AMD PBS and AMD CBS menus on the physical laptop using a runtime SREP patch—without flashing a modified BIOS.

The amount of tuning hidden by Lenovo is much larger than I expected.

Memory overclocking

The exposed AMD CBS pages include:

• Memory Clock Speed from 667 MHz to 1800 MHz
• Primary timings such as Tcl, Trcdrd, Trcdwr, Trp and Tras
• Additional secondary and tertiary timing fields
• AddrCmdSetup, CsOdtSetup and CkeSetup
• CAD bus drive strengths from 120 to 20 ohms
• RttNom, RttWr and RttPark
• RZQ/1 through RZQ/7 termination ratios
• UCLK divider control: UCLK = MEMCLK or MEMCLK/2
• Memory-channel interleaving and interleave size
• DRAM map inversion
• MBIST, aggressor testing and Data Eye controls
• ECC, parity, Write CRC, data scrambling and TSME options

CPU, fabric and power controls

I also found:

• FCLK frequency control
• VDDR_SOC overclock VID
• Global CPU C-state control
• Core Performance Boost
• L1/L2 stream hardware prefetch controls
• P-state policy
• CPPC controls
• STAPM configuration
• SmartShift and SmartShift A+A
• APU-only, sustained, fast and slow PPT limits
• Configurable system profiles from 10 W up to 54 W
• Fan policy, forced PWM and fan-table controls
• Temperature-tracking options
• SVM, SVM Lock and SMM Code Lock

There are also PCIe PSPP/GPP policies, Above 4G MMIO, SATA/AHCI/RAID, ACPI C2/C3, HPET and a large number of platform-specific PBS controls.

I photographed and documented the complete successful session here:

https://github.com/root-hunter/lenovo_bios

>Important: a visible control is not automatically a working or safe control.

I have confirmed that these forms render on FCCN19WW, but I have not validated every value or established safe tuning ranges. Some options—particularly SoC VID, memory training, impedance, power limits and unsupported POR profiles—can cause instability, loss of display or a complete no-boot condition.

Before making real changes, I intend to prepare a verified SPI backup and recovery path.

For the experienced Renoir tuners here: which controls would you test first, and what would be your safest validation sequence?

I’m particularly interested in determining:

• Whether the Ryzen 7 4800H will actually accept memory clocks above the stock configuration
• Whether FCLK and UCLK can be kept synchronized
• Which PPT/STAPM limits are genuinely enforced
• Whether the exposed 54 W profile changes sustained boost behavior
• Which memory timings can be adjusted without triggering failed training

Technical feedback, recovery advice and reproducible test suggestions are very welcome.

I have been reverse-engineering the InsydeH2O firmware used by the Lenovo IdeaPad Gaming 3 15ARH05 (82EY / IP3GAMING-15ARH).

The project started because this model exposes only a very limited BIOS interface, while common unlock sequences such as Fn+R+N do not appear to work reliably on this generation.

So far, I have:

• extracted Lenovo’s official FCCN21WW Windows update package;
• recovered the complete 16 MiB update ROM;
• parsed its AMD PSP directory;
• decompressed and executed the x86 reset-stage image;
• traced its reset loop under QEMU;
• extracted the Setup Utility and reconstructed its IFR;
• confirmed the existence of a separate hidden Advanced form set;
• recovered its GUID, variable stores, offsets and option inventory;
• tested an experimental SREP runtime patch without permanently modifying the firmware.

The hidden menu contains controls for:

• PCIe GPP and power policies;
• SATA/AHCI and RAID configuration;
• TPM and fTPM;
• USB controllers and individual ports;
• ACPI features;
• SVM, SVM Lock and SMM Code Lock;
• DASH and AMD remote KVM;
• Above 4 GB MMIO.

One particularly interesting result is that the Advanced form set is not surrounded by a top-level IFR SuppressIf condition. My current hypothesis is that Lenovo/Insyde hides it through a visibility table or registration logic inside H2OFormBrowserDxe, rather than through a simple “unlock” setup variable.

I also recovered this form-set GUID:

C6D4769E-7F48-4D2A-98E9-87ADCCF35CCC

However, the runtime SREP patch has not exposed the menu yet. The laptop currently runs FCCN19WW, while the analyzed update is FCCN21WW, so differences in modules, patterns or variable semantics may explain the failure.

The repository documents the full process, hashes, extraction commands, QEMU findings, IFR inventory, experimental SREP configuration and suggested next steps:

https://github.com/root-hunter/lenovo_bios

Update: the hidden Advanced BIOS menu has now been successfully unlocked on the test machine using SREP. This is a runtime unlock and does not require flashing a modified BIOS image.

The method remains experimental and model/firmware-specific. Hidden settings can still cause a brick, boot failure or no-display condition, so do not change unfamiliar options without a verified SPI backup and recovery plan.

I would especially appreciate help from anyone who:

• owns the same 15ARH05 / 82EY model and can reproduce the unlock;
• can test it on other FCCN firmware versions;
• has experience with InsydeH2O, SREP or H2OFormBrowserDxe;
• can help validate and document the exposed settings safely.

Issues, corrections and reproducible test results are welcome.

Hey r/Roms 👋

I’ve been working on an experimental project that may be interesting for people who test, organize, preserve, or manage their own game backups:

PPSSPP running directly in the browser through WebAssembly.

Demo: https://root-hunter.github.io/ppsspp-web/

Source: https://github.com/root-hunter/ppsspp-web
https://github.com/root-hunter/ppsspp-wasm

The idea is simple:

open the webpage → load a local PSP file from your device → test it directly in the browser.

No desktop install, no APK, no extension. Just a WebAssembly/browser build.

Important clarification:

This project does not include, host, link to, or provide any ROMs, ISOs, CSOs, BIOS files, or copyrighted content. It is only an unofficial browser/WebAssembly emulator experiment. You need to use your own legally obtained/dumped files.

Why I think this could be useful:

• quick local testing from a browser
• no native install required
• useful for checking files across devices
• potential for a portable PWA-style emulator workflow
• browser-based save/settings experiments
• possible compatibility/performance matrix across browsers/devices

What I’d like feedback on:

• browser compatibility
• ISO/CSO loading behavior
• save/load reliability
• controller support
• performance on low-end devices
• Android browser behavior
• desktop Chrome/Firefox/Edge differences
• storage options like IndexedDB or OPFS
• UI improvements for managing local files

This is still experimental and not an official PPSSPP release, but I’m trying to see how far a browser-based emulator workflow can go.

Question for the community:

Would a browser-based emulator be useful for quick testing and managing your own local backups, or do you think native emulators will always be the better option?

Hey r/browsers 👋

I’ve been working on an experimental project to test how far modern browsers can go as runtimes for complex native-style applications.

The project is an unofficial browser/WebAssembly build of PPSSPP:

Demo: https://root-hunter.github.io/ppsspp-web/

Source: https://github.com/root-hunter/ppsspp-web
https://github.com/root-hunter/ppsspp-wasm

The idea is not just “emulation in a tab”, but using a real, demanding workload to compare browser behavior across platforms:

• WebAssembly performance
• WebGL rendering
• audio latency
• controller/gamepad input
• local file handling
• browser storage
• memory limits
• mobile browser behavior
• tab throttling/background behavior
• PWA potential

This is still experimental and very browser/device dependent, but that’s exactly why I think it’s interesting.

I’d like to understand which browsers handle this kind of workload best, and where the current web platform still struggles compared to native apps.

Important clarification:

This is not an official PPSSPP release. It does not include games, BIOS files, ISOs, CSOs, or copyrighted software. Users need to provide their own legally dumped files.

I’d love feedback from people who test multiple browsers regularly:

• Which browser would you expect to perform best?
• Chrome / Edge / Firefox / Safari?
• Desktop vs Android?
• Any specific flags or APIs worth testing?
• Is WebGPU worth exploring for this kind of project?
• Would OPFS / IndexedDB improve storage and save handling?
• Are there browser-specific limitations I should document?

My goal is to build a public compatibility/performance matrix for browsers and devices if enough people test it.

Curious to hear what the browser community thinks:
are browsers ready to be serious runtimes for this kind of native-style app?