カテゴリー: CPU

投稿日:

Win10 2.5インチSATA起動ディスクをNVMe起動ディスクに移行した

2025/04/14追記: Win10RyzenノートをWin11Intel 12thノートにシステムディスクを移植した にてディスクが見つからない場合のドライバ追加方法などについても記載

元々は、Intel CPUのNEC Mate でインストールしたWindows 8.1 ProのシステムディスクがWindows 10 Proになったあと、AMD Athlon 220GEのmicroATXマザーパソコンに移動して使用していた。

Beelink SER5 Proに移行するにあたり、引き続きこのシステムディスクが利用できないかを実験した。

さすがに元の起動ディスクをそのまま実験するのは怖かったので、別のディスクにコピーしてから実施した。

1) 元環境をClonezillaで起動してシステムディスクをコピー

USBメモリにClonezillaを書き込んで「device-device」でシステムディスクを別の2.5インチSSDにコピーした。

(最初はdevice-imageでNASにバックアップしようとしてたのだが、何故か途中で失敗することが多発したのでdevice-deviceに変更した)

以降の作業はコピーしたSSDで実施した。

2) 元環境でMBR変換

Windows 10のインストールUSBを用意して、リカバリモードのコマンドプロンプトを開く

「mbr2gpt /convert /disk:0 /allowfullos」を実行

最後が「failed」と出ていたが、追加対処が必要という意味

普通に再起動して、Windows10を起動

管理者権限でコマンドプロンプトを開いて「reagentc /disable」「reagentc /enable」を実行してシャットダウン

BIOS設定を変更してUEFI onlyで起動する設定に変更して、起動してくることを確認

参考にしたページ:ライフボードBLOG「MBR OSをGPT OSに変更する方法(Windows10　64bit)」
(The BASIC/ざべ で知った会社、まだあったんだ、と思ったなど)

3) 元環境でchkdsk実行

clonezillaでファイルシステムの問題が出ることがあったので、「chkdsk /f /b」を実行して再起動

再起動時にちょっと長めのファイルシステムチェックが行われるので、終わるまで待つ

4) 新環境をClonezillaで起動してシステムディスクをコピー

まず、ClonezillaのUSBメディアで起動したあと、元環境の2.5インチSSDをUSBケースに入れて接続

「device-device」で2.5インチSSDからnvme SSDへのコピーを実施

5) 新環境を内蔵NVMeのみで起動

USBメディアを取り外して、コピーしたNVME SSDのみで起動。

起動後、足らないデバイスドライバがあれば追加

6) 作業終了

投稿日:

Beelink SER5 ProにWindows 10を入れた

いまAthlon 220GEで使っているmicroATXマザーのパソコンを小型化しようかなーと探していたら、Ryzen 7 5800H搭載のBeelink SER5 PROが 47430円というお値段で売っていた

コレは安い！ということで1台購入

Windows 11 Proがインストールされていたが、初回起動時はsysprepウィンドウが開いて再起動がかかった

そのあと、通常のセットアップが開始された

ミニPC界隈でWindowsのライセンスがボリュームライセンスになっているのは駄目なのでは？という話があったのでslmgr /dli を実行してみると「VOLUME_MAK channel」表記

ただ、これって、sysprep実行し場合の仕様では？という話もあったので、とりあえずWindows 10 Proで再インストールしてみたところ、下記の様に「RETAIL channel」として認識されていることを確認できた。

Windows 10 Proインストール後は、こんな感じのデバイス認識状況だった

デバイスが2つ認識されていないが、どちらもAMDチップセット関連のもの

ネットワークにつなげたら片方は自動的にドライバが適用されて消えた

もう1つの方は、AMDのドライバダウンロードページから「AMD Software: Adrenalin Edition」をインストールすればいいのだが、種別選択がわかりにくすぎる

「Processors with graphics」の「AMD Ryzen Processors」の「Ryzen 7」というものを上から順に見ていくもなかなか見つからない

「Ryzen 7 Mobile Processors with Radeon Graphics」にてようやく発見

AMD Software: Adrenalin Edition インストール後は全てのドライバが適用された。

Beelink SER5 ProのBIOS画面はこんな感じ

2023/06/19追記

SER 5 PRO添付のACアダプタが19V3.42Aで5.5/2.1φという東芝/富士通系DC19V仕様であったため、手持ちの東芝19V4Aアダプタを流用して１ヶ月使っていたのですが、最近になって使用中にいきなりスリープスタンバイに入る処理が開始されてしまう、という謎な現象が発生しだしました。

スリープから復帰するとオーディオデバイスが警告出して使えなくなってる、とか、USBにハードディスクつないでも使えないとかいう状況も併発していました。

このため、純正の19V3.42Aアダプタに戻して使用しています。

投稿日:

ストレージがないSurface Pro 4を手に入れた

秋葉原のPC SHOP OraOrA!でSurface Pro 4の内蔵ストレージなし、液晶が微妙なものが５千円で売っていた

USBメモリから起動できるのかな？と許可をもらってから持っていたWindows10インストール用USBメディアをさして電源を入れてみたところ、ちゃんと起動するし、液晶は左右がなんか黄色がかっている、というぐらいでまあ許容範囲だな、と買ってみた。

Surface Pro 4の仕様と機能

USBコネクタが１つしかないというのが難点なので、USBハブを用意していろいろセットアップ試行開始

Linux編

GPD Pocket用にArchlinux+Steam環境を作ったUSBメモリがあったので、それで起動してみた

・・・標準状態ではタッチパネルもWiFiも使えない状態でした。

Linux Surface を確認すると、WiFiはArchlinux標準の「linux-firmware-marvell」をインストールすると対応すると

タッチパネルはLinux Surfaceで提供しているパッケージ群をインストールすることで対応できる、と

で・・・インストールしてみると、kritaで筆圧が使える形で使えるようになった。

Chrome OS編

Google純正Chrome OS Flexで起動を試みるんですが、起動に失敗しました

\EFI\BOOT\mmx64.efi - Not Found

EFI\BOOTには boot〜.efi と grub〜.efi の２種類がある。

boot〜.efiをmmx64.efi にコピーして試すと変なループになった

grub〜.efi をmmx64.efi にコピーしたら起動が始まった。

WiFiとオーディオ出力はちゃんと動いているもののタッチパネルは動かない状態。

仕方がないので純正Google OSリカバリイメージを改造するbrunchを使ってみたら、初期状態では同じものの、edit-brunch-config で iptsモジュールを追加することでタッチパネルが使える状態となりました。

Androidアプリも使える状態でまあ普通に使える感じでした。

というわけで、ひとまずChrome OS+brunchでしばらく使うようにします。

液晶の問題

しばらく使ってると液晶が上下にぶるぶる揺れる、という感じになる、という問題が・・・

調べてみるとSurface Pro 4のよくある症状であるようです。

「Surface Pro 4の画面揺れをSurface Pro 5の液晶と交換して修理と再発防止をする方法」によると液晶パネルが熱をもつと発生するもので、根本対処は問題がでない液晶パネルに替えるしか無いらしい。

Surface Pro 5の液晶に替える、という手もあるらしい

いまは無い内蔵ストレージは M.2 NVMeストレージ が使えるらしいので、一緒に作業してみてもいいのかな・・・と

さて、どうしていくかなと

2023/07/10追記

ジャンクでマザーボードが抜かれているSurface Pro 5というのが1000円だったので2枚買って、解体チャレンジしてみましたが、2枚とも液晶が割れていました。

このため、手持ちのNVMe SSDをさしてから元のぶれぶれ液晶に戻して使っています。

投稿日:

VisionFive 2のU-boot/SPLをv2.5.0からv2.11.5にアップデートする話

Vision Five 2を最近使っていなかったので、SDK v2.5.0のU-boot/SPLのままで、OSも「Welcome to Armbian 23.05.0.0070 Lunar with bleeding edge Linux 5.15.0-starfive2」といわれてる感じになってた。

いまのU-Boot/SPLバージョンを https://github.com/starfive-tech/VisionFive2/releases で確認するとSDK v2.11.5というバージョンだった。

そして、https://debian.starfivetech.com/ で配布しているDebianも202303版でHDMIディスプレイに起動メッセージが出力されるようになった模様。

なので、U-boot/SPLを最新にしてみるか、とv2.11.5をダウンロードしてきて実行！

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

・・・「u-boot-spl.bin.normal.out won’t fit into /dev/mtd0!」とはどういうこと？

Updating SPL and U-Boot of Flash を確認すると「Method 2 only supports versions equal to or later than VF2_v2.5.0.」と書いてあるので、サポートされてるはず？

とりあえずv2.6.0でやってみるか、と試すと、案の定成功

osakanataro@visionfive2:~/v2.6.0$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 124k/124k (100%)
Verifying data: 124k/124k (100%)
osakanataro@visionfive2:~/v2.6.0$ sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 682/682 (100%)
Writing data: 2727k/2727k (100%)
Verifying data: 2727k/2727k (100%)
osakanataro@visionfive2:~/v2.6.0$

一回再起動

osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

まだ駄目なので、v2.8.0を適用

osakanataro@visionfive2:~/v2.8.0$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.8.0$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 127k/127k (100%)
Verifying data: 127k/127k (100%)
osakanataro@visionfive2:~/v2.8.0$ sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 683/683 (100%)
Writing data: 2731k/2731k (100%)
Verifying data: 2731k/2731k (100%)
osakanataro@visionfive2:~/v2.8.0$

再起動しないでv2.10.4の適用も試してみたところ成功した。

osakanataro@visionfive2:~/v2.10.4$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.10.4$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
Erasing blocks: 32/32 (100%)
Writing data: 127k/127k (100%)
Verifying data: 127k/127k (100%)
osakanataro@visionfive2:~/v2.10.4$ sudo flashcp -v visionfive2_fw_payload.img /dev/mtd1
Erasing blocks: 684/684 (100%)
Writing data: 2734k/2734k (100%)
Verifying data: 2734k/2734k (100%)
osakanataro@visionfive2:~/v2.10.4$

もしやv2.11.5もいくか？と再チャレンジしてみたが駄目

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

再起動してみても相変わらず駄目

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$

これはkernelもアップデートしないと駄目か？

しばらくarmbianのapt update/upgradeを実施・・・

osakanataro@visionfive2:~/v2.11.5$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~/v2.11.5$ sudo flashcp -v u-boot-spl.bin.normal.out /dev/mtd0
u-boot-spl.bin.normal.out won't fit into /dev/mtd0!
osakanataro@visionfive2:~/v2.11.5$ uname -a
Linux visionfive2 5.15.0-starfive2 #1 SMP Mon Feb 20 02:51:35 UTC 2023 riscv64 riscv64 riscv64 GNU/Linux
osakanataro@visionfive2:~/v2.11.5$

駄目かぁ…

RVspaceのフォーラム「Flashcp => /dev/mtd0 2.11.5」では/dev/mtdのパーテーション切り直せばなんとかなる？

githubのissue「Can not upgrade to firmware v2.11.5 #37」ではreleaseのとこにあるsdimageなどからブートすればアップデートできる、という話

とりあえずrvspaceのやつをやってみる

osakanataro@visionfive2:~/v2.11.5$ sudo mtdpart del /dev/mtd 2
mtdpart: error!: Cannot open /dev/mtd
         error 2 (No such file or directory)
osakanataro@visionfive2:~/v2.11.5$ sudo ls -l /dev/mtd*
crw------- 1 root root 90, 0  4月 18 22:29 /dev/mtd0
crw------- 1 root root 90, 1  4月 18 22:29 /dev/mtd0ro
crw------- 1 root root 90, 2  4月 18 22:29 /dev/mtd1
crw------- 1 root root 90, 3  4月 18 22:29 /dev/mtd1ro
crw------- 1 root root 90, 4  4月 18 22:29 /dev/mtd2
crw------- 1 root root 90, 5  4月 18 22:29 /dev/mtd2ro
brw-rw---- 1 root disk 31, 0  4月 18 22:29 /dev/mtdblock0
brw-rw---- 1 root disk 31, 1  4月 18 22:29 /dev/mtdblock1
brw-rw---- 1 root disk 31, 2  4月 18 22:29 /dev/mtdblock2
osakanataro@visionfive2:~/v2.11.5$

/dev/mtd というデバイスは無かった…

「Updating SPL and U-Boot of SD Card and eMMC」だとオフィシャルdebianイメージだと起動に使うSDカードに直接新しいのを書き込んで更新という手も取れるらしい

armbianだとSDカードは1パーテーションであるため、この手法は使えなかった

また、Debian 202303イメージを直接ブートしてみる、というのをやってみたが、U-Bootのところで起動に失敗した。

で・・・結局のところv2.11.5のsdcard.img をmicrosdに書き込んで起動すると、mtdデバイスのパーテーション切り直しと、U-Boot/SPLの更新が自動的に行われて、HDMIディスプレイにもコンソール出力が出るようになりました

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
#
# ls -l /dev/mtd*
crw-------    1 root     root       90,   0 Jan  1 00:00 /dev/mtd0
crw-------    1 root     root       90,   1 Jan  1 00:00 /dev/mtd0ro
crw-------    1 root     root       90,   2 Jan  1 00:00 /dev/mtd1
crw-------    1 root     root       90,   3 Jan  1 00:00 /dev/mtd1ro
crw-------    1 root     root       90,   4 Jan  1 00:00 /dev/mtd2
crw-------    1 root     root       90,   5 Jan  1 00:00 /dev/mtd2ro
brw-rw----    1 root     disk       31,   0 Jan  1 00:00 /dev/mtdblock0
brw-rw----    1 root     disk       31,   1 Jan  1 00:00 /dev/mtdblock1
brw-rw----    1 root     disk       31,   2 Jan  1 00:00 /dev/mtdblock2
#

が・・・・armbianで起動しなおすと/proc/mtdの結果が違う

osakanataro@visionfive2:~$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00001000 "spl"
mtd1: 00300000 00001000 "uboot"
mtd2: 00100000 00001000 "data"
osakanataro@visionfive2:~$

armbian内蔵のu-boot/splが更新されないと駄目？？

投稿日:

Windows 11 on ARMをRK3588SのOrange Pi 5で動かす

しばらく前から、Rockchip RK3588を積んだRock 5B上でWindows 11 on ARMを動かす、というものが公開されていた。

元々は2022年11月にRock 5の販売元であるradxaのフォーラムの「Windows / UEFI on Rock 5 (Mega thread)」(https://github.com/edk2-porting/edk2-rk35xx)で公開されていたものが、2023年3月にtwitterでMario BălănicăさんがROCK 5B向けで動かしているツイートをしてから開発が加速(https://github.com/mariobalanica/edk2-rk35xx)

そこにOrange Pi公式が乗っかったことでOrange Pi 5向け対応も行われるようになった形です。

しばらくは具体的な導入手法はなく、UEFIのみ提供されている状態でしたが、3月下旬にWoRプロジェクトのWebに「Preliminary installation guide for RK3588 boards」と手順が公開され試しやすくなりました。

2023/04/12現在でのOrange Pi 5での制限事項

全体的なもの

・M.2コネクタ利用不可
・HDMI出力のみ対応(Type-C出力は使用できない)
・オンボードNICが使えない

USBコネクタに関する制限事項

・USB 3.0(青コネクタ)の上側のポートはUSBストレージ用に使う
・USB 3.0(青コネクタ)の下側のポートはキーボードなどで使えると書いてあるのだがうまく動かず
・USB 2.0(縦配置のやつ)にUSBハブをつなげてキーボード/マウス/USB NICをつなげると良い
・Type-CコネクタもUSB 2.0扱いで使えるらしいのだがうまく動かず

Windowsのインストール先について

・microSDから起動することもできるっぽいのだが成功せず
・USB 3.0(青コネクタ)の上側ポートにつけたUSBストレージからの起動には成功
・速いストレージを使わないと起動がすごく遅い

セットアップ手法について

WoRの「Preliminary installation guide for RK3588 boards」のWindows手順ではメディア作成関連がいまいち分かりづらかったので、Ubuntu 20.04環境で設定を行った

用意するもの
・USB接続で速いディスク
・UbuntuマシンとOrange Pi 5を繋ぐUSB-A/Cケーブル(SPI書き込みの際に使用)
・USB NIC(Windows11標準で認識するもの)
・USB ハブ(キーボード/マウス/NICをつなぐにはポートが足らないので)

手順概要

1) Ubuntuに前提条件パッケージをインストール

以下のworkliが要求しているパッケージをインストール

# apt install gawk xmlstarlet jq wget wimtools ntfs-3g curl cabextract chntpw genisoimage zenity

rkdeveloptoolが要求するパッケージをインストール

# apt install libudev-dev libusb-1.0-0-dev dh-autoreconf

2) rkdeveloptool をコンパイルしてインストール

基本としてはrockchip wikiのRkdeveloptool に記載のやりかたで https://github.com/rockchip-linux/rkdeveloptool のレポジトリをcloneしてコンパイルするんだけど、実はwikiは記載が足らないので、githubの方に記載のコマンドでコンパイルして、 /usr/local 以下のインストールする。

$ git clone https://github.com/rockchip-linux/rkdeveloptool.git
$ cd rkdeveloptool
$ aclocal
$ autoreconf -i
$ autoheader
$ automake --add-missing
$ ./configure
$ make
$ make install

3) workli.sh を入手

githubの https://github.com/buddyjojo/workli のreleases から workli.sh をダウンロード

ver 1.0時点では、GUIダイアログで選択させる系のつくりになっているためX-Window環境が必要

4) workli.shを実行してSPI/SD選択まで進める

まず、日本語でメッセージが出力されていると、デバイスが識別できなかったので英語で動作させる

$ export LANG=C
$ sudo bash workli.sh

また、sudoを実行する必要があるので、環境によっては下記の様な実行が必要となる

$ export LANG=C
$ xhost +
$ sudo  XAUTHORITY=~/.Xauthority  bash workli.sh

ブートローダ/UEFIをSPIかSDのどちらかにするところまできたら、SPIを選択

5) Orange Pi 5をUbuntuマシンにつなげる

Orange Pi 5に電源ケーブルを繋がない状態で、HDMIコネクタの右側のType-CをUbuntuマシンにつなげ

Orange Pi 5の基盤上にあるMaskromボタンを押しながら、HDMI左側の電源用Type-Cコネクタに電源をつなげる

そうすることで、Ubuntuマシン上にOrange Pi 5がデバイスとして認識される

6) workli.shのプロセスを進める

windowsイメージのダウンロードも自働で行ってくれる

7) USBストレージをUbuntuマシンにつなげる

UbuntuマシンにつなげていたOrange Pi 5を外して、代わりにWindowsをインストールするUSBストレージをつなげる

8) workli.sh でUSBストレージにWindowsをインストールする

9) 書き込んだUSBストレージをOrange Pi 5につなげてOrange Pi 5を起動

まずは下記のようなOrange PiのロゴのUEFIが表示される

しばらくすると下記のようなコマンドプロンプトが表示されて再起動

Orange Piのロゴが表示されたあと、下記の様なブルースクリーンが表示され、再起動する・・・というのを２回くらうと、先に進むのでしばらく放置する

しばらく待つと下記の様な「準備しています」表示になる。

そのうち下記の様なWindows 11の初期セットアップ画面が表示される

Windows 11の場合、Proであってもインターネット接続が必須とされているのを回避するため、Shiftキー+F10キーでコマンドプロンプトを開いて「oobe\bypassnro」を実行する。

実行すると再起動がかかるので、しばらく待ってWindows 11の初期セットアップを進める

Windows 11が起動する

2023/04/12時点ではデバイスマネージャの認識は以下の様な形となっていた

Windows のarm64ビットとして動作していることが確認できる。

また、ラズパイ4の時と同様に古い32ビットWindowsアプリも動作することが確認出来る。