コグノスケ

クロスビルド用ツールチェーン - その1

目次: GCC

先日（2019年3月27日の日記参照）クロスビルド向けLLVMのビルド方法がわかったので、今度はクロスビルド向けGCCのツールチェーン（超基本的なbinutils + GCC + glibcの組み合わせ）を作ろうとしていますが、さっぱりうまくいかないです。

そもそもどのバージョンの組み合わせならビルドが通るのか全くわかりません……。対象となるクロス環境（ARM向けなのか、RISC-V向けなのか）と、ホスト側のコンパイラバージョンが影響するようで、昔ビルドが通っていた組み合わせを引っ張り出してきても、今の環境だとビルドが通らないなんてことがおきます。

やりたいこと

ビルドできる組み合わせは頑張れば見つけられるとは思いますが、本来やりたいことはクロスビルド用のコンパイラのソースコードリポジトリをダウンロードし、自分でソースコードに何か変更を入れ、変更した内容も含めてビルドすることです（ダウンロードは最悪手動でも良いですけど）。

世の中にはクロスビルド用のツールチェーンを作成できるツールはいくつかありますが、いずれもtarballからのビルドを想定していて、改変を入れて再ビルドする方法が良くわかりません。

ツールが想定しているリリース用のビルドは、

• リリースバージョンのtarballか、ソースコードリポジトリのリリースタグを持ってきてビルド
• 実機で使える形、インストーラなどにパッケージング

開発用は、リリース用に加え、

• 最新のソースコードリポジトリを持ってくる
• ソースコードに素早くアクセス、改変
• 改変した部分だけ差分ビルド
• （必要なら）モジュールを足す

が必要ですが、意外とできないです……。

クロスビルド用ツールチェーンを作成できるツール

いくつかツールを調べてみました。

Yocto

ソースコードはアクセスしづらいです。例えばAGL（Yoctoを使っています）は、
agl/build/tmp/work-shared/gcc-8.2.0-r0/gcc-8.2.0/
に置かれます。何回見ても覚えられません。

ソースコードの改変はできますが、bitbakeはソースコードの変更を認識しないようです。bitbakeにモジュールを明示的に指定すれば良さそうです。もしくはパッチを作ってレシピに足してbitbakeするのがYocto的には正しいのかな？どちらにせよ面倒です。

新たにモジュールを足す方法は、レシピを足すだけなので簡単だと思いますが、それ以外が辛すぎます。開発用には向いていません。

crosstool-NG

ソースコードは、
crosstool-ng/.build/src/gcc-8.2.0/
にあります。アクセスしやすいです。

ソースコードの改変は反映されますが、差分ビルドはしないようで、./ct-ng buildとすると全てビルドしなおされます。ちょっと微妙です。

新たなモジュールの追加はどうやるのかわかりません。Yoctoなどとは違い、コンパイラなどのツールチェーンをビルドする専用ツールなので、Linuxカーネルやbusyboxはビルドしません。足すものはあまりないんじゃないでしょうか。

buildroot

ソースコードは、
buildroot/output/build/host-gcc-final-7.4.0/
にあります。Yoctoよりわかりやすいです。

ソースコードの改変は認識されていないように見えます。ソースコードを変更してmakeしても何もビルドされません。

新たなモジュールの追加方法は知らないですが、比較的簡単なのかな…？

ツールチェーン単体だとcrosstool-NGですし、将来的に追加するものを考えるとbuildrootが良さそうですけど。変更を反映して差分ビルドする方法ないのかな……？？

RISC-V SoC搭載ボード探し

目次: RISC-V

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とキャッシュフラッシュ

目次: Linux

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