7월 말, BC250 커뮤니티에 또 큰 소식이 나왔습니다.
이번에는 GPU 40CU가 아니라 CPU입니다. 출고 상태에서 6코어 12스레드로 동작하던 BC250의 비활성 코어 2개를 깨워, 8코어 16스레드로 사용할 수 있는 파이썬 스크립트가 공개됐어요.
저는 앞서 BC250 40CU 언락 소식을 보고 실제 보드를 샀고, 팬 덕트와 데비안 머신까지 직접 만들었습니다. 그래서 이번 8코어 언락은 남의 이야기가 아니었어요.
“이제 CPU까지 완전체로 만들 수 있는 건가?”
처음에는 파이썬 스크립트만 실행해 보려 했습니다. 그런데 콜드 부팅 때 풀린다는 제약이 자꾸 눈에 걸렸고, 결국 영구 적용 바이오스까지 직접 만들기 시작했어요. 결과부터 말하면 그 과정에서 제 BC250은 현재 벽돌이 됐습니다.
다만 먼저 분명히 할 게 있습니다.
공개된 파이썬 언락 스크립트가 제 바이오스 칩을 죽인 것은 아닙니다. 벽돌은 제가 별도로 영구 적용 바이오스를 만들고 반복해서 플래싱하던 과정에서 발생했습니다.
이 글에서는 먼저 원본 파이썬 방식의 원리와 다운로드, 실행, 검증 방법을 자세히 정리하겠습니다. 제 보드의 사망기는 그다음에 곁다리로 붙일게요.
SMU 메시지를 이용해 코어 존재 마스크를 바꾼 뒤 재부팅하면 8코어 16스레드가 인식됩니다. 기본 방식은 콜드 부팅 후 초기화됩니다.
이번에 공개된 것은 무엇인가요?
rw-r-r-0644가 2026년 7월 29일 GitHub에 bc250-core-unlock을 공개했습니다. 최초 커밋 설명도 간단합니다.
bc250 core unlock: enable the 2 disabled cpu cores
BC250의 Cyan Skillfish APU에는 물리적으로 Zen 2 CPU 코어 8개가 있지만, 출고 상태에서는 2개가 비활성화되어 6코어 12스레드로 동작합니다. 이번 스크립트는 이 비활성 코어를 다시 켜 8코어 16스레드로 부팅하게 만듭니다.
핵심은 세 가지예요.
- 바이오스 파일을 플래싱하지 않고 리눅스에서 파이썬 스크립트로 적용합니다.
- 스크립트 실행 직후가 아니라 다음 재부팅에서 8코어가 인식됩니다.
- 웜 리부팅에서는 유지되지만 전원을 완전히 끄는 콜드 부팅 뒤에는 기본값으로 돌아갑니다.
원본 저장소는 모든 바이오스 버전에서 동작한다고 설명하지만, 그렇다고 모든 BC250의 비활성 코어까지 정상이라는 뜻은 아닙니다. 이건 뒤에서 다시 짚겠습니다.
0x77을 0xFF로 바꾸면 왜 8코어가 되나요?
BC250의 코어 활성 상태는 SMN 레지스터 0x5A870에 있는 코어 존재 마스크로 표현됩니다. 출고 상태의 많은 보드에서는 이 값의 하위 8비트가 0x77입니다.
2진수로 보면 다음과 같습니다.
0x77 = 0b01110111
0xFF = 0b11111111
0x77에는 0으로 꺼진 비트가 두 개 있고, 0xFF는 8개 비트가 모두 1입니다. 그래서 코어 존재 마스크를 0xFF로 바꾸면 펌웨어가 다음 부팅에서 8개 코어를 모두 열거할 수 있습니다.
문제는 CPU 쪽에서 이 레지스터에 직접 값을 써도 기록이 무시된다는 점입니다. 단순히 setpci나 일반적인 SMN 쓰기만으로는 해결되지 않아요.
개발자는 SMU 펌웨어를 분석하다 메시지 큐 3의 0x98 처리기에 주소 검증이 빠져 있고, 이 메시지가 전달받은 SMN 주소에 고정값 0x000000FF를 기록한다는 사실을 발견했습니다. 완전한 임의 쓰기는 아닙니다. 그런데 코어 마스크를 모두 켜는 데 필요한 값이 하필 정확히 0xFF였어요.
스크립트는 이 동작을 이용합니다.
SMU Queue 3 message 0x98
↓
SMN 0x5A870에 0xFF 기록
↓
재부팅
↓
AGESA가 8코어 열거
↓
8코어 16스레드로 부팅
우연히 남은 디버그용 처리기와 필요한 마스크 값이 정확하게 맞아떨어진 셈입니다. 하드웨어 역공학에서 가끔 나오는 묘한 순간이죠.
실행 전에 먼저 확인할 것들
이 방법은 바이오스를 직접 덮어쓰지 않지만, 제조사가 지원하는 정식 기능도 아닙니다. 비활성 코어가 실제 불량일 가능성을 생각해야 해요.
먼저 현재 CPU 구성을 확인합니다.
lscpu
nproc
출고 상태라면 보통 다음처럼 확인됩니다.
CPU(s): 12
Core(s) per socket: 6
Thread(s) per core: 2
또한 다음 조건이 필요합니다.
- BC250에서 동작 중인 리눅스
- Python 3
- 관리자 권한
0000:00:00.0PCI 장치의 설정 공간 접근cyan-skillfish-governor-smu서비스가 설치된 환경이라면 실행 전에 해당 서비스 중지
파이썬 외부 패키지는 필요하지 않습니다. 스크립트는 os, struct, sys, time 같은 표준 라이브러리만 사용해요.
중요한 작업을 돌리는 보드라면 먼저 데이터를 백업해야 합니다. 코어가 불안정하면 단순 재부팅뿐 아니라 계산 오류나 데이터 손상으로 이어질 가능성도 있습니다.
방법 1: Git으로 저장소 전체 받기
가장 편한 방법은 GitHub 저장소를 복제하는 것입니다.
git clone https://github.com/rw-r-r-0644/bc250-core-unlock.git
cd bc250-core-unlock
파일이 있는지 확인합니다.
ls -l
bc250-unlock-cores.py와 README.md가 보이면 됩니다.
Git이 없다면 데비안과 우분투 계열에서 먼저 설치할 수 있습니다.
sudo apt update
sudo apt install -y git python3
방법 2: 파이썬 스크립트만 직접 받기
저장소 전체가 필요 없다면 원본 파일 하나만 받을 수도 있습니다.
mkdir -p ~/bc250-core-unlock
cd ~/bc250-core-unlock
curl -fLO https://raw.githubusercontent.com/rw-r-r-0644/bc250-core-unlock/main/bc250-unlock-cores.py
다운로드한 파일을 바로 실행하기 전에 내용을 확인하는 편이 좋습니다.
less bc250-unlock-cores.py
이 스크립트는 /sys/bus/pci/devices/0000:00:00.0/config를 열어 PCI 설정 공간의 0xB8과 0xBC 창을 통해 SMN과 SMU 레지스터에 접근합니다. 인터넷에서 받은 스크립트를 관리자 권한으로 실행하는 만큼, 최소한 이 경로와 쓰기 대상은 확인하고 넘어가는 게 맞습니다.
실제 8코어 언락 실행 방법
먼저 실행 권한을 줍니다.
chmod +x bc250-unlock-cores.py
SMU governor 서비스가 실행 중이라면 중지합니다.
sudo systemctl stop cyan-skillfish-governor-smu
이제 관리자 권한으로 스크립트를 실행합니다.
sudo ./bc250-unlock-cores.py
정상적인 출고 마스크를 가진 보드라면 대략 이런 흐름이 나옵니다.
core presence mask: 0x00000077
after write : 0x000000FF
OK. reboot to bring up all 8 cores (16 threads).
이 출력이 나와도 아직 현재 커널에는 CPU 12개만 보일 수 있습니다. 코어 열거는 다음 부팅에서 이뤄지기 때문이에요.
바로 재부팅합니다.
sudo reboot
스크립트 실행이 실패해 재부팅하지 않을 계획이라면 중지했던 서비스를 다시 시작합니다.
sudo systemctl start cyan-skillfish-governor-smu
재부팅 뒤 8코어가 들어왔는지 확인합니다
부팅이 끝나면 다시 확인합니다.
lscpu
nproc
정상적으로 적용됐다면 논리 CPU가 16개로 표시됩니다.
CPU(s): 16
Core(s) per socket: 8
Thread(s) per core: 2
조금 더 단순하게 확인하려면 /proc/cpuinfo의 프로세서 항목 수를 셀 수도 있습니다.
grep -c '^processor' /proc/cpuinfo
기대 결과는 16입니다.
이미 마스크가 0xFF인 상태에서 스크립트를 다시 실행하면 다음 재부팅에서 8코어를 인식하라는 안내만 출력하고 종료합니다. 불필요한 쓰기를 반복하지 않는 구조예요.
마스크가 0x77이 아니면 멈춰야 합니다
현재 스크립트는 하위 8비트가 0x77도 0xFF도 아니면 기본적으로 작업을 거부합니다.
non-0x77 presence mask detected, high probability of defective cores - STOPPING!
이 검사가 중요합니다. 여러 보드에서 자주 발견되는 0x77은 각 CCX의 같은 위치가 대칭으로 비활성화된 형태입니다. 실제 불량을 무작위로 골라낸 결과라면 비활성 위치도 더 다양하게 나타날 가능성이 높으므로, 0x77은 제품 구성 목적으로 제한했을 가능성을 보여줍니다.
하지만 어디까지나 가능성입니다.
스크립트에는 이 검사를 무시하는 -f 옵션도 있습니다. 저는 권하지 않습니다. 비표준 마스크는 실제 불량 코어를 피해서 잡힌 흔적일 수 있고, 이를 강제로 모두 켜면 충돌이나 계산 오류는 물론 데이터 손상까지 생길 수 있어요.
0x77이 아니면 언락보다 중단이 먼저입니다.
8코어가 보인다고 끝난 것은 아닙니다
부팅에 성공했다고 새 코어가 완전히 정상이라는 뜻은 아닙니다. 저장소도 mprime이나 stress-ng를 몇 시간 실행하고 dmesg에서 MCE를 확인하라고 명시합니다.
데비안과 우분투 계열에서는 stress-ng를 설치할 수 있습니다.
sudo apt update
sudo apt install -y stress-ng
처음에는 짧게 30분 정도 확인합니다.
sudo stress-ng --cpu 16 --cpu-method all --verify --timeout 30m --metrics-brief
문제가 없더라도 실사용 전에 몇 시간 단위로 다시 돌리는 편이 안전합니다. 그다음 커널 로그에서 하드웨어 오류를 확인합니다.
sudo dmesg -T | grep -iE 'mce|machine check|hardware error|edac'
확인해야 할 증상은 다음과 같습니다.
- 부하 중 재부팅이나 멈춤
- 특정 워커의 계산 검증 실패
- MCE 또는 Machine Check 로그
- 고온에서만 나타나는 불안정
- 반복 작업에서 결과가 달라지는 계산 오류
불안정하면 전원을 완전히 끄면 됩니다. 콜드 부팅으로 마스크가 기본 상태로 돌아오므로 다시 6코어 12스레드로 시작할 수 있습니다.
웜 리부팅은 유지되고 콜드 부팅은 풀립니다
원본 방식은 휘발성입니다.
- 리눅스에서 스크립트 실행
- 마스크가
0xFF로 변경 - 재부팅 후 8코어 활성화
- 웜 리부팅에서는 상태 유지
- 전원을 완전히 끈 뒤 다시 켜면
0x77로 복귀
전원을 완전히 끌 때마다 언락 과정을 다시 수행해야 해서 번거롭지만, 안정성을 모르는 첫 단계에서는 이 휘발성이 오히려 안전장치가 됩니다. 새 코어가 불안정하면 콜드 부팅 한 번으로 출고 상태에 돌아갈 수 있거든요.
안정성 검증 전부터 부팅 자동화를 넣거나 영구 바이오스로 넘어가는 것은 순서가 반대입니다. 먼저 소프트웨어 방식으로 충분히 검증해야 해요.
영구 적용 방식도 이미 공개됐습니다
현재는 이 과정을 바이오스에서 자동 실행하는 RescueMei/BC250-DXE-SMU-Core-Unlock도 공개돼 있습니다.
여기에는 시간 순서가 하나 있습니다. 제가 영구 적용 롬을 만들기 시작했을 당시에는 이 DXE 저장소가 아직 공개되기 전이었습니다. 그때 나온 것은 bc250-core-unlock 파이썬 스크립트뿐이었고, 저는 그 코드를 바탕으로 영구 적용 방식을 직접 만들고 있었습니다. 제 보드가 벽돌이 된 뒤에 현재의 공개 DXE 방식이 나왔어요.
다만 여기서 말하는 영구 적용은 코어 마스크 자체를 영구적으로 바꾸는 방식이 아닙니다. 콜드 부팅을 하면 마스크는 여전히 0x77로 돌아오고, 바이오스에 삽입한 DXE 드라이버가 부팅 초기에 다시 0xFF를 기록합니다. 그다음 웜 리부팅을 일으켜 8코어를 열거해요.
정확한 표현은 바이오스 자동 재적용 방식에 가깝습니다.
DXE 드라이버의 판단 순서는 다음과 같습니다.
코어 마스크 확인
↓
0xFF이면 그대로 부팅
0x77이면 SMU Queue 3 메시지 0x98 실행
그 외 값이면 아무것도 건드리지 않고 부팅
↓
0xFF 기록 확인
↓
웜 리부팅
↓
8코어 16스레드로 부팅
운영체제를 다시 설치하거나 SSD를 교체해도 언락이 사라지지 않는다는 장점이 있습니다. 반면 바이오스 자체를 수정해 플래싱해야 하므로 실패했을 때의 위험은 파이썬 방식보다 훨씬 큽니다.
저장소 첫 줄도 이 점을 강하게 경고합니다.
다른 방법으로 8개 CPU 코어가 모두 정상이라고 검증한 BC250에서만 사용해야 합니다.
방법 1: 준비된 xdelta 패치로 영구 적용 롬 만들기
가장 단순한 경로는 저장소의 Patch 디렉터리에 들어 있는 델타 패치를 사용하는 것입니다. 이 패치는 정확히 BC250_3.00_CHIPSETMENU.ROM을 기준으로 만들어졌습니다.
데비안과 우분투 계열에서는 먼저 필요한 도구를 설치합니다.
sudo apt update
sudo apt install -y git xdelta3
저장소를 받습니다.
git clone https://github.com/RescueMei/BC250-DXE-SMU-Core-Unlock.git
cd BC250-DXE-SMU-Core-Unlock/Patch
기준 롬 파일을 이 Patch 디렉터리에 넣고 이름을 정확히 맞춥니다.
BC250_3.00_CHIPSETMENU.ROM
먼저 원본 롬의 MD5를 확인합니다.
md5sum BC250_3.00_CHIPSETMENU.ROM
저장소가 요구하는 기준값은 다음과 같습니다.
d298267029fbbe9d29b0bfa0db5fbf9e BC250_3.00_CHIPSETMENU.ROM
값이 다르면 패치를 진행하면 안 됩니다. 파일명이 같더라도 내용이나 바이오스 버전이 다른 롬일 수 있어요.
해시가 맞으면 스크립트를 실행합니다.
chmod +x ApplyDeltaPatch.sh
./ApplyDeltaPatch.sh
스크립트는 원본 MD5를 먼저 검사하고, xdelta3로 패치를 적용한 뒤 결과물의 MD5까지 다시 확인합니다. 성공하면 다음 파일이 생성됩니다.
BC250_3.00_MeiMeiDXE.ROM
정상 결과물의 MD5는 다음과 같습니다.
6475614980a40a23c412d4deb5273876 BC250_3.00_MeiMeiDXE.ROM
패치 파일 자체의 MD5도 저장소에 공개돼 있습니다.
18a48098f95da36f45b93b07ea72a18b BC250_3.00_CHIPSETMENU-to-BC250_3.00_MeiMeiDXE.xdelta
세 값이 모두 맞아야 플래싱 후보로 볼 수 있습니다.
방법 2: DXE 드라이버를 직접 빌드해 삽입하기
더 깊이 들어가면 EDK II로 DXE 드라이버를 직접 빌드할 수도 있습니다. 기본 빌드 경로는 Podman 컨테이너를 사용합니다.
git clone https://github.com/RescueMei/BC250-DXE-SMU-Core-Unlock.git
cd BC250-DXE-SMU-Core-Unlock
bash scripts/build_ffs.sh
스크립트는 Tianocore Fedora 41 개발 컨테이너를 받고, .cache/edk2에 EDK II 작업 트리를 준비한 뒤 다음 두 파일을 만듭니다.
Build/Output/Bc250CoreUnlockDxe.efi
Build/Output/Bc250CoreUnlockDxe.ffs
바이오스에 넣는 것은 .ffs 파일입니다. UEFITool로 AMI BC250 바이오스를 열고 DXE 펌웨어 볼륨에 드라이버 파일로 삽입한 뒤 수정 롬을 저장합니다.
기존 EDK II 빌드 환경이 있다면 컨테이너 없이도 만들 수 있습니다.
export NO_CONTAINER=1
export EDK2_DIR=/path/to/edk2
bash scripts/build_ffs.sh
이 직접 빌드 경로는 패치 파일을 적용하는 것보다 자유롭지만, 펌웨어 볼륨 선택과 FFS 삽입을 잘못하면 부팅 불능 롬이 나올 수 있습니다. 단순히 빌드에 성공했다는 사실은 안전한 바이오스가 만들어졌다는 뜻이 아닙니다.
플래싱 전에 갖춰야 할 복구 조건
영구 적용 롬을 실제로 플래싱하기 전에는 최소한 다음 조건이 필요합니다.
- 파이썬 방식으로 해당 보드의 8코어 안정성 검증 완료
- 현재 보드에서 직접 읽은 원본 16MB 바이오스 덤프 보관
- 두 번 읽은 원본 덤프의 해시 일치 확인
- CH347 같은 3.3V SPI 프로그래머 준비
- J4004 핀 배열과
BIOS_A1대상 칩 확인 - 실패하면 플래시 칩을 떼어 교체할 수 있는 장비와 작업 능력
외부 프로그래머가 있다는 사실만으로 복구가 보장되지는 않습니다. 플래시 칩이 전기적으로 응답하지 않거나 납땜 패드가 손상되면 칩 교체 작업까지 가야 합니다.
언락 뒤 GPU 클럭이 이상하게 표시될 수 있습니다
현재 알려진 문제도 하나 있습니다. CPU 코어를 언락한 뒤 pp_dpm_sclk와 hwmon의 freq1_input이 GPU 클럭을 약 18~60MHz처럼 비정상적으로 표시할 수 있습니다.
저장소 분석에서는 SMU 자체 클럭 조회값과 TSC는 정상으로 보였고, 기존 코어와 새 코어에서 모두 같은 표시 문제가 나타났습니다. 그래서 현재로서는 실제 GPU가 초저클럭으로 떨어졌다기보다 amdgpu 쪽 파생 값이나 표시 경로가 깨진 문제일 가능성이 큽니다.
다만 원인은 아직 확정되지 않았습니다. 숫자가 이상하다고 바로 성능 저하로 단정하지 말고 실제 벤치마크와 SMU 쪽 값을 함께 봐야 합니다.
40CU 언락과 CPU 8코어 언락은 별개입니다
두 기능은 함께 적용할 수 있지만 원리는 다릅니다.
| 구분 | CPU 8코어 언락 | GPU 40CU 언락 |
|---|---|---|
| 출고 상태 | 6코어 12스레드 | 24CU |
| 목표 상태 | 8코어 16스레드 | 최대 40CU |
| 핵심 방식 | SMU로 코어 존재 마스크 변경 | WGP와 CU 라우팅 변경 |
| 기본 지속성 | 콜드 부팅 후 초기화 | 적용 방식에 따라 다름 |
| 주요 위험 | 불량 CPU 코어와 MCE | 불량 CU와 화면 깨짐, 불안정 |
WinnieLV/bc250-cu-live-manager에는 40CU 관리와 CPU 언락을 한 화면에서 실행하는 기능도 들어갔습니다. 그래도 최초 발견과 원리 설명은 bc250-core-unlock의 파이썬 스크립트가 출발점입니다.
저는 공개 DXE 방식이 나오기 전에 직접 롬을 만들었습니다
제 보드의 벽돌은 RescueMei/BC250-DXE-SMU-Core-Unlock을 적용하다 발생한 일이 아닙니다. 해당 방식이 공개되기 전, 파이썬 스크립트만 나온 상태에서 시작한 별개의 실험이었어요.
파이썬 방식은 실행하고 재부팅하면 되지만, 전원을 완전히 끌 때마다 다시 적용해야 합니다. 저는 이 휘발성이 계속 눈에 걸렸습니다.
“어차피 SMU 메시지 한 번이면 되는 것 아닌가? 부팅 초기에 자동으로 보내면 영구 적용할 수 있지 않을까?”
그래서 공개된 파이썬 스크립트가 하는 일을 역공학하고, 같은 동작을 바이오스 부팅 과정에 직접 넣는 쪽으로 넘어갔습니다. 롬을 만들고 플래싱하고, 원하는 상태가 아니면 다시 수정해 올리는 작업을 여러 번 반복했어요.
그러다 어느 순간 BC250이 부팅되지 않았습니다.
처음에는 잘못 만든 바이오스가 올라간 일반적인 벽돌이라고 생각했습니다. CH347 프로그래머도 미리 사뒀거든요. 보드의 J4004 단자에 연결해 순정 롬을 다시 쓰면 된다고 봤습니다.
그런데 플래시 칩이 아예 읽히지 않았습니다.
J4004에 CH347을 연결해도 반응이 없었습니다
제가 확인한 내용은 이렇습니다.
- J4004 단자와 바이오스 플래시 칩 다리 사이 통전 확인
- 바이오스 칩 전원 핀에서 3.3V 확인
- CH347이 공급하는 3.3V로 읽기 실패
- J4004의 3.3V 핀을 분리하고 보드 자체 전원을 인가한 상태에서도 읽기 실패
바이오스 내용만 깨졌다면 부팅은 안 되더라도 플래시 칩의 JEDEC 식별자는 읽혀야 합니다. 쓰기 방지나 잘못된 롬 데이터도 제조사와 모델 식별 명령까지 없애지는 않거든요.
그래서 지금은 단순 롬 손상보다 BIOS_A1 플래시 칩 자체의 사망을 의심하고 있습니다. 아직 확정은 아닙니다. 칩을 보드에서 떼어 오프보드로 읽기 전에는 보드 내부 SPI 버스 충돌 가능성을 완전히 제외할 수 없어요.
결국 바이오스 칩 교체 준비까지 왔습니다
현재 주문하고 기다리는 부품은 다음과 같습니다.
- SOP8 208mil 프로그래머 소켓
- Winbond W25Q128JVSQ 16MB 3.3V 플래시 칩
- 열풍기
- 플럭스
- 0.5mm Sn63/Pb37 플럭스 코어 실납
부품이 도착하면 기존 BIOS_A1을 떼어 소켓에서 직접 읽을 계획입니다.
- 분리한 칩에서 JEDEC 식별자가 나오면 인서킷 통신 문제
- 식별자는 되지만 데이터가 깨졌다면 순정 롬 재기록
- 분리 상태에서도 식별자가 안 나오면 플래시 칩 사망 확정
- 사망이 확인되면 새 W25Q128JVSQ에 순정 16MB 롬을 기록하고 교체
새 칩은 보드에 먼저 납땜하지 않을 생각입니다. 소켓에서 식별, 삭제, 순정 롬 기록, 전체 검증, 재판독 해시 확인까지 끝낸 뒤 장착할 예정이에요.
이번 경험에서 가장 중요한 구분은 이것입니다.
파이썬 언락은 휘발성 SMN 마스크 변경이고, 제 보드의 벽돌은 별도로 영구 적용 바이오스를 만들고 플래싱하던 과정에서 발생했습니다.
둘을 같은 위험으로 묶으면 안 됩니다. 원본 파이썬 스크립트는 바이오스 칩을 덮어쓰지 않습니다. 저는 파이썬 스크립트로 8코어 16스레드가 인식되는 것까지 직접 확인한 다음, 영구 적용 바이오스를 만들다가 보드가 죽었습니다.
지금 BC250 사용자가 선택할 현실적인 순서
제 경험까지 포함해 순서를 다시 정리하면 이렇습니다.
- 현재 CPU 구성이 6코어 12스레드인지 확인합니다.
bc250-core-unlock원본 코드를 직접 검토합니다.- 마스크가
0x77인지 확인한 뒤 파이썬 스크립트를 실행합니다. - 재부팅 후 8코어 16스레드 인식을 확인합니다.
stress-ng나mprime으로 몇 시간 검증합니다.dmesg에서 MCE와 하드웨어 오류를 확인합니다.- 콜드 부팅 후 다시 풀리는 휘발성 상태로 충분히 사용해 봅니다.
- 영구 적용은 복구 장비와 원본 전체 덤프, SPI 칩 교체 능력까지 갖춘 뒤에만 검토합니다.
저라면 지금은 7번에서 멈춥니다.
소프트웨어 방식은 귀찮지만 되돌리기 쉽습니다. 반대로 영구 바이오스는 편하지만 한 번 삐끗하면 운영체제도, 원격 접속도, 화면도 없는 기판 한 장이 남습니다. 저는 그 차이를 책상 위의 벽돌로 확인하고 있어요.
정리하면
BC250 CPU 8코어 언락은 실제로 공개됐고, 원리도 상당히 명확합니다. 파이썬 스크립트가 SMU 메시지 큐 3의 0x98 처리기를 이용해 코어 존재 마스크를 0x77에서 0xFF로 바꾸고, 다음 부팅에서 8코어 16스레드를 열거하게 만듭니다.
다운로드와 실행도 어렵지 않습니다. 다만 성공 화면보다 중요한 것은 비표준 마스크에서 멈추는 것과 언락 뒤 장시간 안정성을 확인하는 일입니다.
저는 파이썬 방식으로 8코어 언락을 확인한 뒤 영구 적용 바이오스를 만들다가 복구 작업까지 왔습니다. 아직 결말은 나지 않았어요. 기존 플래시 칩을 떼어 직접 읽고, 필요하면 새 칩으로 교체한 뒤 부팅이 살아나는지 확인해야 합니다.
8코어 언락 소식으로 시작한 실험이 결국 납땜 작업까지 이어졌습니다. BC250은 여전히 재미있는 장난감이지만, 이번에는 그 재미의 비용을 꽤 제대로 치르고 있네요.
댓글