livaの雑記帳

livaの雑記帳

OSとか作ってみたい

最近思ったこと(クソ記事)

最近、すごいもやもやしていたのだけど、何となくすっきりしてきたので、それを書き出してみる。

先に予告しておくけど、あんまり読む価値は無いと思う。すごく自明な結論が出るので。

 

 

 

 

いろいろ手を動かしたりしている割には成果が出ないよなー、どうやったらもうちょっと成果が出るのかなー、というモヤモヤが最近すごい強くなっていた。

 

しばらく悩んでいたんだけど、サボってるわけでもないのに、成果が出ないというのは、取り組む方向性や取り組み方がおかしいという事に気付いたので、分析してみる事にした。

 

まずは方向性の話。

方向性というか、自分が今どうしたいのか、という事について考えてみた。

まあ方向性といってもいろいろある。

たとえば研究ではメニーコアを上手く活用するOSのモデルを作りたくて、その一例として【詳細は略】を実装して評価したい。

あと、去年学部生実験のTAをやった結果、結構面白かったので、これも続けたい。学生に対してどうやって効率的にOSを学ばせるか、というのはある程度方向性は見えた気がするので、後は頑張って授業計画を作るだけ。成功するかどうかはわからん。

 

で、まあ研究とかはさておき、結局自分が本当に目指すものって何だろう、という話。

これは難しい。正直、書くのは恥ずかしいんだけど、「なんか意義のあるOSとか作れたらいいよね」というくらいのモヤッとした雰囲気でここ最近は生きていた気がする。

でも、そんなモヤッとしたものではOSを作るための情熱なんて湧いてこない。とりあえず自分が今作っている物に対して、「これができたら自分でも使ってみたい」くらいの強い思いがほしい。

でもさあ、自分でOSを作る事に対して目的を持つのって難しいよね。ちょっとしたアイディアなら既存OS上でやった方が評価される。自分でOSを作りたいなら、デバイスやソフトウェアの互換性を考えなきゃいけないけど、そんなことをやるのは道のりが遠すぎる。

結局、「これを実現したい」よりも「自分でOSを書きたい」の方が先行して、手段が目的化している。

 

少し話が逸れたけど、結局のところ自分の目指す方向性がよく見えてなくて、だから成果も出ないし、承認欲求不足にもなる。これは良くない。

 

次にやり方の話。

これまでどんなことをやってきたかというと、自分のOS向けに10G NICやUSBのデバドラを実装したりしてきた。なんでこれをやってたかというと、上にも書いた通り、「フルスクラッチで意味のあるOSを作るためには互換性が重要」で、よく使われるデバイスをサポートしようと思ったから。

でも、「君のOSはすごいけど、デバイスサポートが貧弱だからなぁ」と言われているならまだしも、現時点でこんなことをやってるの、順序が違う。

正確には、作ってる時は必要に迫られていた。10G NICのサポートは当時やってた未踏で必要だったし、以前はPS/2キーボードが動かなかった(ただのバグなんだけど、当時は本気でPS/2が動かないと信じていた)からUSBのサポートが必要だった。
今にして思えば、順序が逆転してるなあ、という話。

階段は一段一段上っていくべきで、今すべきことはもっと他にある。

 

 

とまあこんな具合にいろいろ破綻していた。

 

じゃあどうしようか、と考えてみて、自分が何をしたいのか、探してみた。

まず、自分でOSを書くに当たって、非本質的なデバドラ開発をしなきゃいけないのを何とかしたい。これまでいろいろデバドラ書いてきて、その無意味さを痛感したからこそ思うこと。OSを書いて何かやりたいことがあるなら、それに専念したい。これはたぶん学部生実験で取り入れようとしているアイディアそのまんまだから、そのうち達成される。というか達成されないとまずい。

次に、マルチコア環境でCPUリソースをもっと全力で活用したい。

え、研究と何が違うのかって?同じですね。これまでは研究の先になんかもっとすごい成果を見出そうとか思ってたのが、研究目標と自分の目標が同一化されただけ。

 

なんか前者に関しても最初の方で書いた話そのまんまで、結局はこれまでの規定路線のままで行く、という凄く自明な結論。ここまで読んだ人、怒らないでね。一番最初に「これはポプテピピック的なクソ記事ですよ」って予告したよ?

 

綺麗な感じにまとめてみる。

モヤモヤしてたので、自分の中で一回転ぐるっとして、今やっていることをきちんと動機付けして心の中に落ち着けた、という話でした。

Pull Requestのレビューはpatchファイルでやるのが吉

凄くくだらない事を書く。

 

githubで送られてきたPull Requestをレビューするのが辛い。

何が辛いかというと、本質的な部分をレビューしたいのに、変数名の変更みたいな非本質的な要素が無限にあって、つらい。

 

良さげなレビューツールとか無いのかなー、と思ったけど、パッと見なさ気。

これまではgithub上で見ていたのだけど、見終わった所とか非本質的な部分とか、見えなくしたいじゃん?ファイル単位では折りたためて、それはそれで良いんだけど、ブラウザが落ちたり、タブうっかり消しちゃうと全部吹っ飛ぶから辛い。

 

というわけで、レビューに対するモチベが下がってたのだけど、凄く簡単な解決方法があった。

patchファイルを作ればいいじゃないか!

 

pull requestをローカルに引っ張ってきて(やり方はググればいくらでも出てくるから割愛)、git diffする。

git diff master.. > pr.patch

 

後は好みのエディタで開けば、まあ殆どのエディタは色つけされるから、この時点でgithubのweb UI並のdiff表示はできる。(web UI並の事ができるとは言っていない。詳しくは後述)

 

で、見たくない所は編集で消していけば良い。

 

ファイル単位で見る見ないを考えたければ、patchutilsを入れて、

splitdiff -ad pr.patch

とでもすればよろし。

 

今思いついた衝撃で書いたんだけど、まあ当たり前と言えば当たり前なので、こっそりやっている人も多いと思う。

 

 

 

1つだけ問題があって、コメントしたい時にgithubのUI上で該当箇所を探さないといけない。辛い。

 

追記:

git diff -M develop.. なら、ファイルのリネームも追えるからgithubのレビューUIより優秀なんじゃね??

HiKey960上でM.2 SSDの性能をゆるーく測定した。

この記事の続き。

raphine.hatenablog.com

 

 

fioでベンチを取ってみる。

やり方は以下と同様。

raphine.hatenablog.com

 

上の記事内にあるUFS(HiKey960内蔵のFlashストレージ)の結果をこちらにも転記。

job数が4なので実際の速度はこの4倍。

 

UFS

seq read: 105133KB/s

seq write: 82215KB/s

rand read: 45770KB/s

rand write: 73260KB/s

 

Intel 600p

seq read: 92065KB/s

seq write: 157842KB/s

random read: 90901KB

random write: 171452KB/s

 

WD BLACK PCIE SSD

seq read: 103880KB/s

seq write: 148405KB/s

random read: 75669KB/s

random write: 118210KB/s

 

後者2つについて、KabyLake Core I7 Intel NUC上でも測ってみた。

Intel 600p

seq read: 119766KB/s

seq write: 317519KB/s

random read: 106444KB/s

random write: 310068KB/s

 

WD BLACK PCIE SSD

seq read:152664KB/s

seq write:256802KB/s

random read:137912KB/s

random write:203073KB/s

 

とりあえずポイントとしては、

  • UFSよりM.2 SSDはだいぶ早い
  • ただし、x86に挿した時程の性能は出ない

 

後者については、HiKey960のM.2はPCIe Gen2だから(NUCはGen3)帯域がボトルネックになっているんじゃないかなと。もしかするとCPUが弱いから、という可能性も無きにしも非ずだけど・・・

HiKey960のM.2コネクタがSSDを認識するようになった

この記事の続き。

raphine.hatenablog.com

この記事を書いた時点では、AOSP(Hisilicon謹製のクローズドソースなブートローダから起動する)ではPCIバイスが認識されるけど、UEFIからDebianを起動すると認識されなかった。UEFIがきちんとPCIを初期化しないからっぽい、と。

 

で、結論としては、昨日hisiliconの中の人が出したUEFIへのパッチによってDebianでも認識するようになりました。

 

手元にあるSSDのうち、NVMe SSDとして使えたのは、

逆に、Samsung 960 EVOは lspci でPCIバイスとして表示されるし、/dev/nvme0も現れてNVMeコントローラとしても認識されるのだけど、/dev/nvme0n1が現れなかった。(正確には最初は現れてたのだけど、いろいろ実験してたらなぜか現れなくなった)

 

 

 

というわけで、以下やり方。

 

まず、キモとなるのはhisiliconの中の人から出てきた以下のPull Request。github.com

 

この記事執筆時はこのPull Requestはmergeされていない(追記:マージされてた!)が、たぶんそのうち最新のUEFI prebuild imageを使えば動くようになるはず。

とりあえず現時点ではprebuild imageが無いので、自分でUEFIをビルドする。

 

やり方は基本的にこれと同じ。

github.com

 

僕はUbuntuが提供しているg++-aarch64-linux-gnuパッケージを使っていたのだけど、これだとコンパイルがこけるっぽいので、linaroが提供している最新のコンパイラをインストールする。

 

まずは以下を実行して、出てきたパッケージを全て消す。

$ dpkg -l | grep aarch64-linux-gnu

 

次に、以下からそれっぽいtar.xzファイルをダウンロード。展開してパスを通す。

Linaro Releases

 

UEFIコンパイルをする。

# apt install uuid-dev -y

$ git clone https://github.com/hzhuang1/arm-trusted-firmware.git -b fix_psci --depth=1

$ git clone https://github.com/96boards-hikey/edk2 -b testing/hikey960_v2.5 --depth=1

$ git clone https://github.com/96boards-hikey/OpenPlatformPkg -b testing/hikey960_v1.3.4 --depth=1

$ git clone https://git.linaro.org/uefi/uefi-tools --depth=1

$ git clone https://github.com/96boards-hikey/l-loader -b testing/hikey960_v1.2 --depth=1

$ BUILD_PATH=$(pwd)

$ cd ${BUILD_PATH}/edk2

$ ln -sf ../OpenPlatformPkg

$ BUILD_OPTION=RELEASE

$ export AARCH64_TOOLCHAIN=GCC5

$ export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools

$ export EDK2_DIR=${BUILD_PATH}/edk2

$ EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN}

$ cd ${EDK2_DIR}

$ ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey960

赤文字にしている部分がポイント。hisiliconの中の人による修正済みブランチを落としてくる。

 

公式のマニュアルでは、tools-images-hikey960のルートのファイルを用いてるが、partition tableの整合が取れてなくてUEFIから自動でgrubを起動できないので、以下で配布されている物を使うのが良いと思う。

builds.96boards.org

 

適当なディレクトリ上に、上のページから全てファイルを落としてくる。

同じディレクトリにビルドしたUEFIも置く。

$ ln -sf ${BUILD_PATH}/l-loader/l-loader.bin

$ ln -sf ${BUILD_PATH}/l-loader/fip.bin

 

recovery mode(よく分からない人はこれでも読んで)で起動し、以下のコマンドを実行する。hikey_idtを実行途中、裏のpicocomで「Press ESCAPE for boot options」と出た瞬間に「f」を押さなければいけない事に注意。

./hikey_idt -c config -p /dev/ttyUSB1

fastboot flash ptable prm_ptable.img

# fastboot flash xloader sec_xloader.img

# fastboot flash fastboot l-loader.bin

# fastboot flash fip fip.bin

 

あとはbootやお好みでsystem、userdataとか焼く。Debianのビルド方法についてはこれとか参考になるかと。(注:この記事ではSDカードにOSを焼いているが、UFSに焼きたければ、この記事の参照元のブログの記事とか参考になるかと)

あと、この記事で解説しているパッチを当てる事。リポジトリ同じ

 

ところで、Debianをビルドした際の個人的ハマリポイントを書いておく。

コンパイラを適当なディレクトリに落として、.bashrcで$PATHを追記するという雑なやり方をしていた所、Debianのビルド時にコンパイラが見つからなくてこけた。

visudoで「Defaults       secure_path="〜〜〜(略)〜〜〜"」という行をコメントアウトすると上手く行く。

 

 

Debianが上手くインストールできたら、M.2 SSDを挿してHikey960を起動する。

この時点で、/dev/nvme0は見えているはず。

 

# apt update

# apt install nvme-cli -y

 

これで/dev/nvme0n1が見えるようになる。(再起動が必要かも) 

HiKey960のM.2コネクタはSSDを認識するのだろうか<その2>

raphine.hatenablog.com

 

これの続き。

 

Western DigitalSSD等を買ってきて検証した結果、問題はSSDにあらずという事が分かった。

 

今手元にあるSSDは三種類。

 

www.samsung.com

www.intel.co.jp

 

あと、これ。

WD Black PCIe SSD | Western Digital(WD)

 

で、結果としては、androidからなら三種類とも認識した。

カーネルを自前ビルドした物に差し替えても認識。

問題はDebianなのかなぁ(でもカーネルの問題だし、ありえなくない?)、などと悩んでいたのだけど、ふと、UEFIの問題なんじゃないかと気づく。

 

前の記事で貼ったコミュニティページを良く読むと、なんかそれらしい事が書いてある。

discuss.96boards.org

 

でも、問題は未だ解決されておらず。これ、もしかして詰んだ?

 

とりあえずUEFIを使わずにDebianをブートできないか検討してみよう。

 

 

追記:動きがあるっぽい。

653 – PCI devices cannot be detected with ARM-TF/UEFI

 

続きを書いた。

raphine.hatenablog.com

Hikey960をfactory imageのAOSPに戻す

Debian入れてたけど、一度初期化したくなったので。

 

まずはBase Firmwareの初期化。

このリポジトリをダウンロードしてくる。

github.com

 

DIPスイッチをRecovery-modeに設定してUSBケーブル2本を作業マシンと接続。(詳細は上のリポジトリのREADMEを参照)

接続前は/dev/ttyUSB*が何も見えなかった(既に何かある場合は、該当機器を抜いておくのが良いかと)のが、/dev/ttyUSB0と/dev/ttyUSB1が見えるようはず。

 

この状態なら以下のコマンドでOK

# ./recovery-flash.sh 

 

正常なログはこんな感じ。

Config name: config

Port name: /dev/ttyUSB1

0: Image: ./sec_usb_xloader.img Downalod Address: 0x20000

1: Image: ./sec_uce_boot.img Downalod Address: 0x6a908000

2: Image: ./sec_fastboot.img Downalod Address: 0x1ac00000

Serial port open successfully!

Start downloading ./sec_usb_xloader.img@0x20000...

file total size 99584

downlaod address 0x20000

Finish downloading

Start downloading ./sec_uce_boot.img@0x6a908000...

file total size 23680

downlaod address 0x6a908000

Finish downloading

Start downloading ./sec_fastboot.img@0x1ac00000...

file total size 3430400

downlaod address 0x1ac00000

Finish downloading

< waiting for device >

target reported max download size of 471859200 bytes

sending 'ptable' (196 KB)...

OKAY [  0.011s]

writing 'ptable'...

OKAY [  0.039s]

finished. total time: 0.051s

target reported max download size of 471859200 bytes

sending 'xloader' (151 KB)...

OKAY [  0.010s]

writing 'xloader'...

OKAY [  0.216s]

finished. total time: 0.226s

target reported max download size of 471859200 bytes

sending 'fastboot' (3346 KB)...

OKAY [  0.094s]

writing 'fastboot'...

OKAY [  0.035s]

finished. total time: 0.130s

target reported max download size of 471859200 bytes

sending 'nvme' (128 KB)...

OKAY [  0.009s]

writing 'nvme'...

OKAY [  0.035s]

finished. total time: 0.044s

target reported max download size of 471859200 bytes

sending 'fw_lpm3' (212 KB)...

OKAY [  0.013s]

writing 'fw_lpm3'...

OKAY [  0.014s]

finished. total time: 0.027s

target reported max download size of 471859200 bytes

sending 'trustfirmware' (145 KB)...

OKAY [  0.010s]

writing 'trustfirmware'...

OKAY [  0.016s]

finished. total time: 0.026s

FAILEDとか出てたら失敗してる。

 

次にOS(AOSP)を焼く。

builds.96boards.org

hikey960-linaro-20XX.XX.XX-factory-XXXXXXX.zipってのをダウンロードして展開する。

 

僕がダウンロードしたのはこのver。

http://builds.96boards.org/snapshots/hikey960/linaro/aosp-master/364/

 

これのflash-all.shを動かせば良いはずなのだが、中に記述されているファイル名が実際のファイルと異なっていて動かない。

hisi-XXXX.imgというのが幾つかあるが、その先頭の「hisi-」を削除する。

 

# ./flash-all.sh

 失敗する場合は最初から(recovery-flash.shの辺りから)やり直すと良い。

 

後はAuto Power up Modeにして起動するだけ。 

HiKey960のM.2コネクタはSSDを認識するのだろうか<その1>

HiKey960用にSSDを買ってきた。

www.samsung.com

 

挿した。

結局、こうなった。

 

だが、SSDを認識しない。lspciしても何も出てこない。

 

調べてみた。

discuss.96boards.org

 

4.9カーネルだと認識しないからソースコードを書き換えないといけないらしい。mainlineだと修正されているから問題ないよ、と。

でも僕が使ってるの、4.13なんだよなー。正確にはこのリポジトリ

 

更に調べてみる。

PCIeドライバのこの箇所で落ちる。

kirin_pcie->gpio_id_reset = of_get_named_gpio(dev->of_node,
                                             "reset-gpio", 0);

dtsiファイルを見てみると、reset-gpio「s」と書かれている

これ、mainlineじゃないにしても17/11/03のバージョンでしょ?修正されてないんかい・・・

 

このバグについての対応方法をまとめる。バージョン問わず適応可能。

 

まず、ドライバファイル(drivers/pci/dwc/pcie-kirin.c)を見る。

一番下の方にある、kirin_pcie_matchという変数を見る。

static const struct of_device_id kirin_pcie_match[] = {
  { .compatible = "hisilicon,kirin960-pcie" },
  {},
};

compatible stringがどうなっているか確認。ここでは"hisilicon,kirin960-pcie"

 

このすぐ上にkirin_pcie_probe()という関数がある。

kirin_pcie->gpio_id_reset = of_get_named_gpio(dev->of_node,
                                             "reset-gpio", 0);

kirin_pcie->gpio_id_resetに代入している部分。of_get_named_gpioの引数の文字列を確認。ここでは"reset-gpio"。

 

arch/arm64/boot/dts/hisilicon/hi3660.dtsiの、pcieに関する項目を見る。

こんな感じの項目。

pcie@f4000000 {
  compatible = "hisilicon,kirin960-pcie";
  reg = <0x0 0xf4000000 0x0 0x1000>,
           <0x0 0xff3fe000 0x0 0x1000>,
           <0x0 0xf3f20000 0x0 0x40000>,
           <0x0 0xf5000000 0x0 0x2000>;
  reg-names = "dbi", "apb", "phy", "config";
  bus-range = <0x0 0x1>;
  #address-cells = <3>;

compatibleエントリを先程のcompatible stringと一致させる。

このエントリの最後の方にこんな感じのもあるはず。

  clock-names = "pcie_phy_ref", "pcie_aux",
                           "pcie_apb_phy", "pcie_apb_sys",
                           "pcie_aclk";
  reset-gpios = <&gpio11 1 0 >;
}; 

 reset-gpiosか、reset-gpioになっていると思うので、ドライバのソースコードの文字列に合わせる。

 

カーネルをビルドする。基本的なインストールの流れは以下の記事とか参照してもらえれば。

raphine.hatenablog.com

 

1点だけ追加で作業が必要。

dt.imgというのを作り、焼かなければならない。

 

dt.imgの作り方は、

tools-images-hikey960/gen_boot_dts_imgs-sample.sh at master · 96boards-hikey/tools-images-hikey960 · GitHub

の通り。

 

丁寧に書くと、このリポジトリをcloneして、作ったdtbファイルを配置し、

./build-from-source/mkdtimg -d hi3660-hikey960.dtb -s 2048 -c -o dt.img 

 とする。

 

内蔵ストレージにdt.imgを焼く。

↓この記事の通りに諸々ディスクイメージを焼いて、

raphine.hatenablog.com

最後に

fastboot flash dts dt.img

とすればよろし。

 

この記事ではやってないが、systemパーティションも焼くなら、systemパーティションの前に焼いた方が良いかも。(なぜかsystemの後にdtsを焼いたら上手く動かなかった)

 

リビルドしたカーネルで起動し、pciutilsを入れると(Debianならapt install pciutils)、

root@linaro-installer:~# lspci
00:00.0 PCI bridge: Device 19e5:3660 (rev 01)

 

PCI Host bridgeは認識できる。

 

だが、Samsung 960 EVOをどうやっても認識しない。

 

dmesgの抜粋はこんな感じ。

[    0.326870] OF: PCI: host bridge /soc/pcie@f4000000 ranges:

[    0.326880] OF: PCI:   MEM 0xf6000000..0xf7ffffff -> 0x00000000

[    1.330718] kirin-pcie f4000000.pcie: Link Fail

[    1.330790] kirin-pcie f4000000.pcie: PCI host bridge to bus 0000:00

[    1.330794] pci_bus 0000:00: root bus resource [bus 00-01]

[    1.330799] pci_bus 0000:00: root bus resource [mem 0xf6000000-0xf7ffffff] (bus address [0x00000000-0x01ffffff]) 

[    1.330824] pci 0000:00:00.0: [19e5:3660] type 01 class 0x060400

[    1.330877] pci 0000:00:00.0: reg 0x10: [mem 0xf6000000-0xf6ffffff 64bit]

[    1.330964] pci 0000:00:00.0: supports D1 D2

[    1.330967] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot

[    1.331172] pci 0000:00:00.0: BAR 0: assigned [mem 0xf6000000-0xf6ffffff 64bit]

[    1.331187] pci 0000:00:00.0: PCI bridge to [bus 01]

[    1.331376] pcieport 0000:00:00.0: Signaling PME with IRQ 66

[    1.331440] pcieport 0000:00:00.0: AER enabled with IRQ 66

 Link Failってなんじゃ!!

 

調べてみるが、イマイチ要領を得ない。

Suspend - Resume in Hikey960 platform - HiKey 960 - 96Boards

https://bugs.96boards.org/show_bug.cgi?id=595

https://bugs.96boards.org/show_bug.cgi?id=653

 

Intel 600pなら繋がるというウワサ。ほんまかいな。

Hikey 960: M.2/SATA? - HiKey 960 - 96Boards

 

こんなのを見つけた。

add PCIe driver for Kirin PCIe [LWN.net]

 

Sandisk SSDなら認識するっぽい?中の人が書いているんだから、そうなんだろう。

いやでも、型番書いてよ!!!

 

Sandisk SSDで調べてみる。

価格.com - 規格サイズ:M.2 (Type2280) SANDISK(サンディスク)のSSD 人気売れ筋ランキング

Sandisk & M.2 & PCIeインターフェースなSSDは存在しない。上のリンクは全てSATAインターフェース。

ちなみに、hikey960のM.2はPCIeがそのまま露出してるだけっぽいので、SATAインターフェースのSSDを繋いでもたぶん認識しない。

 

詰んだ・・・。てかhisilliconの人は何を使ってるんだよ。

 

暫くさじを投げてたのだが、じっーーーーっと見てたらPCI Vendor IDとDevice IDを見つけた。

[1b4b:1093] 

 

これで製品特定できるんじゃね?

The PCI ID Repositoryで調べたが、出てこない。

 

グーグルに調べてもらったら出てきた。

 

ひとつめ。

[vfio-users] GPU Pass Through with KVM

02:00.0 Non-Volatile memory controller [0108]: Lite-On Technology Corporation M8Pe Series NVMe SSD [14a4:22f1] (rev 01)

           Subsystem: Marvell Technology Group Ltd. Device [1b4b:1093]

           Kernel driver in use: nvme

           Kernel modules: nvme

 パット見、1b4b:1093ってのは内部コントローラっぽい?

これですかね。

www.goplextor.com

Sandiskじゃあないなぁ。まあでももしかしたら動くかもしれない。

 

ふたつめ。

Zorin Group Forum • View topic - [CLOSED] No connections

03:00.0 Non-Volatile memory controller [0108]: Sandisk Corp Device [15b7:5001]
   Subsystem: Marvell Technology Group Ltd. Device [1b4b:1093]
   Kernel driver in use: nvme
   Kernel modules: nvme

おおおお!Sandisk!これか???

 

IDで検索した。確かにVendor ID 15b7はSandiskっぽい。

http://pci-ids.ucw.cz/read/PC/15b7/5001

なるほど、WD Black NVMe SSDとな。・・・WD?

ググってみる。

 

WD Black PCIe SSD | Western Digital(WD)

Western Digitalじゃねぇか!!!

 

 

おわり。

 

 

追記:続き。

raphine.hatenablog.com