RescueMei GitHub avatar

BC250-DXE-SMU-Core-Unlock

RescueMei

A DXE driver for AMD BC-250 that unlocks all 8 CPU cores early in boot by sending an SMU message when the core presence mask indicates only 7 cores are active.

Stars

7

7-day growth

No data

Forks

1

Open issues

0

License

No data

Last updated

2026-07-30

AI repository intelligence
FR-AI / ANALYSIS

Why it is worth attention

It embeds the core-unlock sequence directly into the BIOS as a DXE driver, making the unlock persistent across OS reinstalls, drive changes, and cold boots while incorporating safety checks to avoid enabling defective cores.

Who it is for

  • BC-250 hardware owners and operators
  • Firmware engineers modifying AMI BIOS
  • Miners and system integrators using BC-250 ASICs
  • Security researchers interested in SMU-based core activation

Use cases

  • Restoring full 8‑core functionality on BC-250 boards that have all cores functional but ship with a limited core mask
  • Integrating the unlock into a custom BIOS image to avoid relying on OS‑level tools
  • Automating core unlock in a fleet of BC-250 miners without manual flashing
  • Testing and verifying core stability after unlock using stress tests

Strengths

  • Operates extremely early in boot before any OS loads, minimizing boot time impact
  • Includes a safety guard that only triggers on the expected 0x77 mask and refuses to enable cores on anomalous masks
  • Provides both containerized and host‑based build scripts for easy integration into firmware workflows
  • Based on a proven reference implementation (rw‑r‑r‑0644) and produces a standard .ffs driver insertable with UEFITool

Considerations

  • Only intended for BC-250 boards that have been independently verified to have all 8 CPU cores functional
  • Requires flashing a modified BIOS, which carries a risk of bricking the board without a recovery programmer
  • Causes incorrect reported GPU clocks (visual only, no performance impact observed)

README quick start

CAUTION: ONLY USE THIS ON BC250s THAT HAVE BEEN VERIFIED TO HAVE ALL 8 CPU CORES FUNCTIONAL VIA ANOTHER METHOD FIRST

Credit to https://github.com/rw-r-r-0644 for creating an implementation of this unlock, which I used as a reference when making this driver

For how to use the patch to apply to the BC250_3.00_CHIPSETMENU.ROM BIOS, please see the bottom of this readme

Why a DXE Driver?

This is so it can run extremely early in the boot process and add a minimal amount of time to the boot of BC250s that are already known to have good cores. By placing this driver in the bios, it prevents drive failures, updates, or OS reinstalls from breaking the cpu core unlock.

Like the other methods of core unlock, for some reason it causes the reported GPU clocks to be wrong. I have not noticed any negative impact on GPU performance however, so it appears to just be a visual/reporting issue?

BC250-DXE-SMU-Core-Unlock

It is a standalone EDK II DXE driver for the AMD BC-250 that mirrors the SMU core-unlock sequence from rw-r-r-0664, from this repo: https://github.com/rw-r-r-0644/bc250-core-unlock

This build script generates an .ffs driver for insertion into an AMI BIOS DXE firmware volume with UEFITool.

Behavior

The driver reads the core presence mask at SMN 0x0115A870 via PCI config space on 00:00.0.

  • If the low byte is 0xFF: exit and boot normally.
  • If the low byte is 0x77: send SMU Queue 3 message 0x98, verify the mask becomes 0xFF, then issue a warm reboot.
  • If the low byte is anything else: exit and boot normally to avoid lockout on abnormal masks.

This should prohibit it from unintentionally enabling defective cores on unexpected core masks.

Files

Bc250CoreUnlockPkg/
  Bc250CoreUnlockPkg.dec
  Bc250CoreUnlockPkg.dsc
  Bc250CoreUnlockDxe/
    Bc250CoreUnlockDxe.inf
    Bc250CoreUnlockDxe.c
scripts/
  build_ffs.sh

Prerequisites for Building

Default containerized path

  • podman installed locally (or docker if you set CONTAINER_ENGINE=docker)
  • network access on first run to pull the Tianocore dev image and clone edk2

By default, the build helper uses the Tianocore Fedora 41 development container:

  • ghcr.io/tianocore/containers/fedora-41-dev:latest

It maintains a reusable edk2 checkout under:

.cache/edk2

Optional host build path

If you already have a working host-side EDK

Related repositories

Similar projects matched by category, topics, and programming language.

jamesob
Featured
jamesob GitHub avatar

local-llm

A comprehensive guide for building and configuring a high-end local machine to run state-of-the-art LLMs, with detailed hardware choices, BIOS tuning, and Docker-based model serving.

AI & Machine LearningLarge Language Models
1,660
bjan
Featured
bjan GitHub avatar

claudemux

Claudemux is a lightweight, dependency-minimal message bus that lets multiple Claude Code sessions communicate in real-time over tmux, enabling one session to ask another a question and receive the answer without manual intervention.

AI & Machine LearningAI Agents
9
0xwilliamortiz
Featured
0xwilliamortiz GitHub avatar

openclaude-improved

OpenClaude is an open-source CLI coding agent that runs on any platform and supports a wide range of LLM providers, offering the same tools and workflows as Claude Code.

AI & Machine LearningLarge Language Models
577