**"Need Help: I have a Lenovo flex5 chromebook(akemi),Modifying MrChromebox Full Replacement BIOS for T-Wall 100°C, TDP Tweaks, PTT Unlock & Fullscreen UI"**

Dear MrChromebox Community,

I’m currently working on modifying the full replacement BIOS for my MrChromebox device, and I’m encountering some challenges in the customization process. I’ve followed the guides on MrChromebox.tech, but I need assistance with specific steps and validations. Here’s my setup and what I’m trying to achieve:

My Environment:

Local Machine: Windows PC with Xlaunch (for Linux GUI) and Xshell/Xftp installed.

Server: Ubuntu Linux server for command-line operations.

BIOS Files: I’ve downloaded the full replacement BIOS from MrChromebox.tech and successfully backed up my original ROM using a CH341A programmer.

Goals & Modifications I Need Help With:

1.

Synthesize the Full Replacement BIOS:

Inject my device’s original VPD data (Serial Number, MAC Address, etc.) and HWID into the MrChromebox Full ROM.

Validate the injection process using cbfstool and gbb_utility on my Ubuntu server.

2.

Deep BIOS Modifications (Need to be “hard-coded” into the ROM):

Temperature Wall (T-Wall): Change PROCHOT limit to 100°C (currently set to 90°C even after flashing the full ROM).

TDP Settings: Adjust PL1 to 35W and PL2 to 55W.

Intel PTT (Platform Thermal Technology): Enable this feature.

Intel XTU Unlock: Disable CFG Lock and Overclocking Lock to allow XTU to modify CPU parameters freely.

BIOS UI Fullscreen: Modify the BIOS Setup interface to display in fullscreen mode (no need for third-party help with this part; I’ll handle it externally through Xianyu services).

3.

Tools I’m Using/Planning to Use:

Windows Tools: UEFITool NE, UEFITool 0.28, Universal IFR Extractor, HxD (Hex Editor).

Linux Tools: cbfstool, gbb_utility, flashrom, ifdtool.

Challenges & Questions:

Synthesis Validation: How can I confirm that VPD and HWID injection was successful before flashing the modified ROM?

IFR Editing for Deep Mods: I need step-by-step guidance on how to extract the Setup module (likely named Setup or PlatformSetup), parse the IFR data using Universal IFR Extractor, locate the correct VarOffsets for T-Wall, TDP, PTT, and XTU Unlock, and modify the default values directly in the binary using HxD.

Potential Risks & Validation: I understand the risks of pushing PL1/PL2 beyond the stock 15W design (cTDP-up 25W). However, I’m willing to accept the risk. How can I test the stability of the modified BIOS before committing to a permanent flash? Are there any logs or monitoring tools I should use during stress tests?

What I’ve Done So Far:

Downloaded all necessary tools on both Windows and Ubuntu.

Backed up my original BIOS and verified the integrity with MD5 checks.

Injected VPD and HWID into the Full ROM using cbfstool and gbb_utility on the Ubuntu server.

Request for Assistance: Could someone please provide clear, step-by-step instructions or point me to relevant resources for:

1.

Validating the injected VPD/HWID.

2.

Locating and editing the specific Setup Variables (VarOffsets) for T-Wall, TDP, PTT, and XTU Unlock in the IFR data.

3.

Testing the modified BIOS safely (e.g., using QEMU emulation or a temporary flash to test functionality before a permanent write).

Any advice, tips, or troubleshooting guidance would be greatly appreciated. I’m comfortable with advanced command-line operations and hex editing, but the IFR manipulation part is new to me.

Optional Attachments:

setup_ifr.txt (IFR parsed text file for reference).

Output of cbfstool akemi_full.rom print showing injected VPD/HWID.

Thank you in advance for your help!

Best regards, [Your Forum Username]

P.S.: I’m unable to use tools like ThrottleStop due to concerns about game anti-cheat detections, so BIOS-level modifications are necessary.

following a LLM is going to lead you to tears. There’s no such thing as IFR or IFR mods with my coreboot+edk2 firmware.

why are you needing/wanting to flash via chip clip? that’s completely unnecessary unless the device is MDM locked

TDP and other adjustments you want are simply not wired up for your device, and would require code changes and recompiling

and you can’t test under qemu, it’s a completely different build target so not representative of what is built for your actual device

Hi Matt (MrChromebox),
First of all, thank you so much for taking the time to reply and correct me. You are absolutely right—I relied on an LLM to generate the modification steps, and it hallucinated the whole “IFR/HxD modding” process for your coreboot+edk2 payload. I sincerely apologize for the confusion and appreciate you saving me from going down a completely wrong and frustrating rabbit hole.
To answer your question about the chip clip (CH341A programmer):
Yes, the device is indeed MDM/Enterprise locked. It is permanently banned/enrolled. I cannot boot into ChromeOS at all, the official recovery USB fails with an enterprise enrollment error, and because of the MDM lock, CCD functionality (SuzyQable) is completely locked out. Hardware flashing via a chip clip is literally the only remaining method I have to bypass the lock, wipe the stock firmware, and install your UEFI Full ROM to revive this machine as a standard Windows PC.
Regarding the TDP, Temperature Wall, Intel PTT(only on), and Fullscreen UI adjustments:
I understand now that these parameters are not wired up in the current build and require actual source code modifications and recompiling of the coreboot/edk2 tree, rather than binary patching.
Since I really need to get this device working and want to do it the right way, could you point me in the right direction?
Is there a specific public Git branch or repository for the AKEMI (Hatch family) coreboot source that I should clone to attempt modifying the devicetree.cb and FSP UPDs myself?
Alternatively, would you be open to a paid custom build request for these specific tweaks, or could you recommend someone in the Chrultrabook community who takes on custom coreboot compilation jobs?
Thanks again for your incredible work on the firmware and for your patience with my AI-generated mistakes.
Best regards,

I’d just flash the release firmware externally, then you can flash the custom firmware internally via the script.

shoot me an email MrChromebox @ Gmail with your wishlist and I’ll see how feasible it is