link もっと前
   2019年 4月 27日 -
      2019年 4月 18日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

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

先日(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 が良さそうですけど。変更を反映して差分ビルドする方法ないのかな……??

[編集者: すずき]
[更新: 2019年 5月 7日 00:39]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

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 から転記しておくことにした。

[編集者: すずき]
[更新: 2019年 4月 20日 00:42]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

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

[編集者: すずき]
[更新: 2019年 4月 20日 00:29]
link 編集する

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
   2019年 4月 27日 -
      2019年 4月 18日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 8/23 23:38

カレンダー

<2019>
<<<04>>>
-123456
78910111213
14151617181920
21222324252627
282930----

最近のコメント 5件

  • link 19年07月18日
    hdk 「あっ、AAMはマニュアルのオペレーション...」
    (更新:07/25 00:02)
  • link 19年07月18日
    すずき 「AAM(ASCII Adjust AX ...」
    (更新:07/24 22:22)
  • link 19年07月18日
    hdk 「加算減算は符号のありなしどちらも命令が同...」
    (更新:07/24 07:25)
  • link 19年07月18日
    すずき 「OFをセットして例外を出したければINT...」
    (更新:07/20 11:02)
  • link 19年07月18日
    すずき 「MUL については、結果が倍のビット幅に...」
    (更新:07/20 10:56)

最近の記事 3件

link もっとみる
  • link 19年08月21日
    すずき 「[RockPro64 と linux-next とヘッドフォン] ...」
    (更新:08/23 23:38)
  • link 19年08月12日
    すずき 「[独自の apt サーバー - その 3 - apt の信頼シ] ...」
    (更新:08/12 12:13)
  • link 19年08月11日
    すずき 「[独自の apt サーバー - その 2 - apt-ftpa] ...」
    (更新:08/12 12:13)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報