私の最新の四半期アップデートでも触れたとおり、ごく普通のファームウェアアップデートで、愛用のStar Labs StarBook Mk VI (AMD)が高価な文鎮と化してしまいました。Star Labsの公式ドキュメントにあったcurl ... | bashのワンライナーをそのままコピー＆ペーストしただけでした。スクリプトは30秒ほど動作したあとデバイスの電源を切り、それ以来StarBookはまったく起動しなくなりました。画面は真っ黒のまま、キーボードのバックライトは点灯し、電源LEDも点いたまま、スピーカーからは時折パチパチという音がするだけでした。お決まりの再起動すれば直るというおまじないやバッテリーの取り外しを何度試しても、まったく直りませんでした。

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

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

1.8V

私のStarBook Mk VI (AMD)に搭載されているフラッシュチップは、裏蓋を外してシリコン上の印字を読み取ると、Winbond 25R128JWSQでした。SOIC-8パッケージのSPI NORフラッシュです。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が動く2台目のPC（USBメモリのライブ環境でも構いません。たとえば家電量販店のノートPCとFedoraライブUSBの組み合わせでも、店員さんに「決して爆弾を作っているわけではない」と上手く説明できれば何とかなります）、お使いのモデルに合った正しいファームウェアイメージ（詳細は後述します）、小さなプラスドライバー、そしてできればプラスチック製のヘラを用意してください。

ステップ1：StarBookを開ける

作業を始める前に、必ず電源を切り、充電器を外してください。ノートPCを裏返し、まずは上部の角にある長いプラスねじ2本を外し、続いて周囲の短いねじ8本を外して裏蓋を外します。蓋は慎重に持ち上げてください。

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

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

ステップ2：クリップを取り付ける

SOIC-8フラッシュチップにはpin 1の位置が決まっており、クリップ側のpin 1（通常はリボンの赤い線側）をそこに合わせる必要があります。向きを間違えると、チップはまったく認識されません。

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

ただし、これらを手作業で配線する必要はありません。クリップと1.8Vアダプタが8本すべてのラインを中継してくれるからです。唯一注意すべきは、クリップのpin 1とチップのpin 1を正しく合わせることだけです。

補足：私のチップでは、パッケージに灰色のドットが印字されていましたが、これはpin 1とは反対側の角にありました。pin 1の目印は、反対側にある小さなへこんだ（刻印された）ドットの方です。なぜ灰色のドットがあるのかは分かりませんが、そちらに合わせてしまうとクリップが逆向きになってしまいます。もしお手元のチップにも同様の印がある場合は、灰色の点ではなくへこみを探してください。

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

クリップを取り付けたら、CH341Aを2台目のPCに接続します。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アダプタで問題なく復旧できるにもかかわらず、その情報は公式ドキュメントのどこにも載っていません。だからこそ、私はこの記録を公開することにしました。次に同じ目に遭う誰かが、私のように一日を無駄にし、余計なストレスを抱えずに済むことを願っています。