コグノスケ

RISC-V の SoC を見ていた

Linux が動くくらいの RISC-V の SoC 搭載ボードを探していたのですが、どうやらまだ市販されてなさそうでした……。

代わり（？）に SiFive の高性能 RISC-V SoC である HiFive Unleashed（リンク）のマニュアルを眺めていました。

HiFive Unleashed は高性能と紹介されていることが多いですが、現状 RISC-V は Arduino くらいの小規模 SoC がほとんどで、それらと比較して高性能、と言っているのだと思われます。

特に珍しい機能もないですし、最近のテレビやタブレット向けの巨大な ARM 系 SoC と比べると、どうしてもショボく見えてしまうのは仕方ないでしょう。

ああ、でも Errata の章があるのは珍しいかもしれません。

ROCK-2: High 24 address bits are ignored

Workaround
Do not access out-of-bound addresses in software.

I2C-1: I2C interrupt can not be cleared

Workaround
Poll the I2C controller state to wait for TIP (transaction in progress) to go low.

などの豪快なバグがある様子が伺えます。特に ROCK-2 の Workaround は全然 Workaround になっておらずのが面白いです。アクセス違反をするな、と言ってアクセス違反がなくなるなら OS の苦労はないでしょ。かなり悲惨なバグです。

ボードには修正した SoC を載せるのか、バグった SoC を強引に搭載するのか、どちらなんでしょうね……。

メモ: 技術系の話は Facebook から転記しておくことにした。

Linux の DMA

昨今のキャッシュを持った CPU では、DMA を行う際に CPU のキャッシュのフラッシュ（ダーティデータをメインメモリに書きだす、パージともいう）やインバリデート（キャッシュから消しさる、クリーンともいう）が必須です。

しかしアーキテクチャや CPU の実装によってキャッシュの操作方法は異なるため、Linux では DMA API というレイヤでアーキテクチャの差分を隠蔽しています。

Linux で DMA を行うドライバを書くときの一番単純な作法（＝単一の領域に DMA を行う、スキャッターギャザーなどはしない）は、

dma_alloc

バッファ確保

dma_map_single

バッファを CPU のメモリ空間にマップし、CPU から見えるようにする

dma_sync_single_for_cpu

CPU からバッファをアクセスする準備

CPU からバッファにデータを書き込む

dma_sync_single_for_device

デバイスからバッファをアクセスする準備

デバイスから DMA を行いデータを読み込む

dma_unmap_single

バッファのマップをやめる

dma_free

バッファ解放

ざっくりいってこのような感じです。先ほど述べた通り、Linux の DMA API にキャッシュのフラッシュやインバリデート関数はありません。ハード依存の操作をなるべく減らし、多数のアーキテクチャに対応しやすくなっているんですね。

実際はいつフラッシュしているのか？

そうはいっても、実際にどこでキャッシュフラッシュしているか、気になると思います。昔、Linux 4.4 を調べた情報を引っ張り出してきました。アーキテクチャは AArch64 つまり 64bit の ARM コアです。

AArch64 の場合、キャッシュ操作をしているのは dma_sync_single_for_cpu() と dma_sync_single_for_device() です。前者がインバリデート、後者がフラッシュ＋インバリデートを行っています。

前者の dma_sync_single_for_cpu() を追いかけてみると、

dma_sync_single_for_cpu()

関数ポインタ経由で ops->sync_single_for_cpu() を呼びます。AArch64 の場合 ops には通常 swiotlb の DMA 操作関数が入っています。ですので __swiotlb_sync_single_for_cpu() が呼ばれます

__swiotlb_sync_single_for_cpu()

コヒーレントバッファでない（キャッシュフラッシュがいる）場合 __dma_unmap_area() を呼びます

__dma_unmap_area()

__dma_inv_range() を呼びます

__dma_inv_range()

キャッシュをインバリデートします

こんな感じですね。しつこいですが AArch64 の実装を見ただけですので、将来的に変わるかもしれないし、他のアーキテクチャでは仕組みが違います。

直接フラッシュしたがるおじさん

昔の Linux ではキャッシュ操作関数をドライバから使うことができました。その記憶からなのか、たまにフラッシュやインバリデートのようなアーキテクチャ依存の操作を直接呼びたがる人がいます。

今の Linux ではキャッシュ操作関数は当然ありますが、ドライバからは呼べない、つまり呼ぶことを推奨していません。もちろんオープンソースなので改造すれば何でもできますけど、メンテナンス性や再利用性、移植性を下げるだけで、損しかないでしょう。