最新の四半期アップデートでも触れたとおり、何の変哲もないファームウェアアップデートで、私のStar Labs StarBook Mk VI (AMD)が見事に文鎮と化してしまった。やったことといえば、Star Labsの公式ドキュメントに載っていたcurl ... | bashのワンライナーをコピー＆ペーストしただけだ。スクリプトは30秒ほど動作したあとデバイスをシャットダウンし、そこからStarBookは一切起動しなくなった。画面は真っ黒、キーボードのバックライトは点灯したまま、電源LEDも点きっぱなしで、スピーカーからは時折カチッという音がするだけだった。お決まりの電源を入れ直す儀式もバッテリーの取り外しも、何を試しても復活しなかった。

この状況から抜け出す唯一の方法は、SPIプログラマを使ってBIOSチップに外部から直接書き込み直すことだ。Star Labsもその方法を解説しているが、同社のガイドは同社製のプログラミングキットと専用のデバッグボード、FPCケーブルを使うことを前提にしている。そのキットは汎用プログラマよりはるかに高価で、メーカーや型番の記載もなく、執筆時点ではウェブショップで恒久的に在庫切れになっていた。手元にある唯一のコンピュータであるノートPCが起動不能になり、出先で立ち往生しているときには、まったく役に立たない。

幸いなことに、少なくともこの特定のモデルのStarBookであれば、そんなものは必要ない。この騒動をデバッグする過程で私が立てたGitHub issueで、Star LabsのSean自身が指摘していたように、このStarBookはSOIC-8パッケージのフラッシュチップを採用しており、電圧さえ守れば、安価な汎用のCH341Aプログラマと普通のSPIクリップで復旧できるのだ。

1.8V

私のStarBook Mk VI (AMD)のフラッシュチップは、バックプレートを外してシリコン上の刻印を読んだところ、SOIC-8パッケージのSPI NORフラッシュであるWinbond 25R128JWSQだった。Winbond製品では、末尾のJWというサフィックスが1.8V対応を示すらしい。

AliExpressやAmazonなどで3ドルほどで手に入る、あのありふれた黒いCH341Aプログラマは、SPIラインが3.3V（パラレルヘッダは5V）で動作する。これを1.8Vチップに直接挟めば、うまくいってもflashromの読み取り結果はゴミになる。最悪の場合は、フラッシュ自体やその周辺回路を壊してしまう。

対策は、CH341AとSOIC-8クリップの間に挟む小さな1.8Vアダプタボード（要するに電圧レギュレータ付きのレベルシフタ）だ。これらはキットとして販売されており、たとえばSeanがissueでリンクしていたKOOBOOK CH341A Programmer + 1.8V Adapterのコンボなどがそれにあたる。購入する際は、必ず1.8V対応と明記されているものを選んでほしい。

必要なもの

必要なのは、1.8V対応のSOIC-8アダプタ付きCH341Aプログラマ、SOIC-8テストクリップ（バネ式の「Pomonaタイプ」でも、安価なリボンケーブルタイプでもどちらでも使える）、プログラマを操作するためのLinuxが動くもう一台のコンピュータ（USBメモリなどからのライブ起動でもよい。たとえば家電量販店のノートPCとFedoraライブUSBでも、スタッフに爆弾を作っているわけではないと上手く説明できればなんとかなる）、正しいモデル用のファームウェアイメージ（詳細は後述）、小さなプラスドライバー、そしてできればプラスチック製のスパッジャーだ。

ステップ1: StarBookを開ける

作業を始める前に、必ず電源をすべて切り、充電器を抜いておくこと。ノートPCを裏返し、まず上部の角にある長いプラスねじ2本を外し、次に周囲の短いねじ8本を外してバックプレートを取り外す。プレートは慎重に持ち上げて外そう。

次に、バッテリーを固定している5本のねじを外す（1箇所は意図的にねじ穴が空のままになっている）。そしてバッテリーのコネクタをそっと抜く。

最後に、メインボード上のSOIC-8フラッシュチップを探す。上で説明した小さな8本足のWinbondチップだ。

ステップ2: クリップを接続する

SOIC-8フラッシュチップにはピン1が決まっており、クリップ側のピン1（通常はリボンの赤い線側の配線）に合わせなければならない。向きを間違えると、チップはそもそも認識されない。

参考までに、WinbondのSOIC-8フラッシュのピン配置は以下のとおりだ。

といっても、これらを手作業で配線する必要はない。クリップと1.8Vアダプタが8本すべてのラインを中継してくれるので、やるべきことはクリップのピン1をチップのピン1に合わせることだけだ。

補足: 私のチップでは、パッケージのピン1とは反対側の角に灰色のドットが塗られていた。ピン1を示しているのは、そのまったく反対側にある小さなくぼんだ（刻印された）ドットのほうだ。なぜ灰色のドットがあるのかはわからないが、そちらに合わせてしまうとクリップが逆向きになってしまう。もし自分のチップにも灰色の点があるなら、そちらではなく、くぼみを探してほしい。

ステップ3: flashromで書き込む

クリップを取り付けたら、CH341Aをもう一台のマシンに接続する。dmesgをざっと確認すれば、正しく認識されたかがわかる。

usb 3-6: New USB device found, idVendor=1a86, idProduct=5512, bcdDevice= 3.04
usb 3-6: Product: USB UART-LPT

まだインストールしていなければflashromをインストールする。

# Debian/Ubuntu
sudo apt install flashrom

# Fedora
sudo dnf install flashrom

何かを書き込む前に、flashromがクリップ経由でフラッシュと実際に通信できるか確認しよう。

sudo flashrom -p ch341a_spi

すべてが正しく装着されていれば、flashromはWinbondチップを（W25Q128JWのような名称で）認識するはずだ。もし代わりに次のように表示されたら、

No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

…慌てる必要はない。私の経験では、これはほとんどの場合、クリップの接触不良が原因だ。安物のクリップは扱いが難しく、私もチップが安定して認識されるまで、何度かクリップを揺らしたり付け直したりする必要があった。数回実行して安定的にチップが検出されるようになるまで、先に進まないようにしよう。

たとえファームウェアが壊れていても、上書きする前にバックアップを取っておくのが定石だ。チップを2回読み出してダンプを比較し、接触が確実か確認しよう。

sudo flashrom -p ch341a_spi -r backup1.rom
sudo flashrom -p ch341a_spi -r backup2.rom
cmp backup1.rom backup2.rom && echo "OK: reads match"

2回の読み取り結果が異なる場合は、クリップの接触が不安定なので、一度外して付け直してから再試行してほしい。

ファームウェアイメージについては、Star Labsが公開GitHubリポジトリでファームウェアを公開している。外部から書き込む場合は、EFI／fwupd用のアップデータではなく、完全なSPIイメージが必要だ。私のStarBook Mk VI (AMD)（製品SKUはB6-A）の場合、それはroms/B6-A.biosというイメージにあたる。flashrom用の完全なイメージは、モデル別のami-flashromディレクトリの下にも置かれている。自分のモデルに合ったものを選び、starbook.romのような分かりやすい名前にリネームしておこう。

最後に、ダウンロードしたイメージを次のflashromコマンドで書き込む。

sudo flashrom -p ch341a_spi -w starbook.rom

デフォルトではflashromは消去、書き込み、そして検証まで行う。Star Labsの公式コマンドでは-n -N（つまり--noverifyと--noverify-all）が追加されて検証パスがスキップされるが、書き込みが確実に成功したか確認するためにも、これらは付けずに検証させることをおすすめする。いずれにせよ、動作中は絶対にプログラマを取り外したり触れたりしないこと。正常に完了したら、クリップを外し、バッテリーを再接続し、バックプレートをねじで戻してから起動を試してみよう。

ステップ4: 復旧後の初回起動

私の環境では電源を入れ直すとStarBookは再び息を吹き返したが、すぐにブートエントリが見つからないという画面で止まった。新しいイメージを書き込むとEFIのブート変数も消去されるためだ。大した問題ではなく、ファームウェアにブートローダの場所を教え直せばよい。ブートメニューからSSDを選べば通常はブートエントリが再登録されるし、リカバリ／ライブシステムからgrub-installを実行してもよい（私はそうした）。あるいはEFIシェルに入ってブートローダを手動で起動してもよい。

fs0:
cd efi/fedora
grubx64.efi

所感

今回の一件で最も腹が立つのは、ファームウェアアップデートが失敗すること自体ではない。何かをフラッシュする以上、そのリスクは常にあるのだから。腹が立つのは、Star Labsの公式な復旧手順が、実際には誰も買うことができない独自キットに依存していることだ。汎用のCH341Aと1.8Vアダプタで問題なく復旧できるように見えるのに、その情報は公式ドキュメントのどこにも載っていない。だからこそ、私はこの記録を公開することにした。次に同じ目に遭う誰かの、一日分の時間とストレスを少しでも軽減できれば幸いだ。