Linux kernelのbspとupstream
19
Porter ボボボボボボボボボ ボボボボボボボボボボボボボボ wata2ki
-
Upload
wata2ki -
Category
Engineering
-
view
241 -
download
2
Transcript of Linux kernelのbspとupstream
Porterボードのカーネルのベースバージョンを上げてみた
wata2ki
自己紹介 名前 : wata2ki (watatuki) ◦元はハードウェアで画像処理をやっていましたが、現
在は組み込み屋をやっています 画像処理をやっていた当時は、ニューラルネットワークが画像処理
で実用化できるような形で使われるなんて予想していませんでした。。。
◦最近は Jetson-TK1/TX1 向けのアンオフィシャル Yocto BSP を作り、そのうえでディスクトップ環境や別ボード向けのディストロを動かして遊んでいます
◦GitHub https://github.com/watatuki
発表概要
今日は、 Renesas 社の Porter ボードの BSP についてくるカーネルのバージョンアップに挑戦した時の内容について発表します
Porter Board :R-Car M2 SoC ・ ARM®Cortex-A15 Dual Core 1.5 GHz・ PowerVR SGX544MP2 (3D)・ 2 GB DDR3 memory (dual channel)
Debug Ethernet (100 Mbps)
Storage connection ・ one SATA rev. 3.1 port・ one SD card slot・ one microSD card slot
Etc…
背景 背景
◦ ARM のボードコンピュータで Linux を動かす場合、 Linux のカーネルは、ベンダーの BSP と upstream カーネルのどちらかを使うことになる BSP カーネル
そのボード (SoC) のほぼ全ての機能を使うことができるが、特定のバージョンのカーネルにボード用の修正を加えたものなので、 Linux カーネルのバージョンアップに追従してくれない Renesas 社の Porter ボードの場合は 3.10.31LTSI Nvidia 社の Jetson TK1 ボードの場合は、 3.10.40
Upstream カーネル Linux のメインラインそのものなので、カーネルの修正・改良はすべて入っ
ているが、使える機能が制限される ほとんどの場合 GPU は使えない (Nvidia は頑張れば 3D 描画くらいはできる ) カーネルにドライバが入っていても、動くかどうかわからない / 動かし方が
わからない
◦ つまり、どちらも最良の選択肢にはなりえない
目的 目的◦ 現状分析から、 ARM のボードコンピュータで Linux を動かす場
合の目指す姿は 2 種類 BSP カーネルのマイナーバージョンを最新まで上げて使う
最新機能は取り込めないが、バグフィクスは最新まで取り込める マイナバージョンアップなのでカーネルのソースが大きく変わることはな
く、バッチを当てやすい Upstream カーネルに BSP カーネルの修正を適用して使う
最新機能もバグフィックスも取り込める BSP カーネルとのバージョン差が増えれば増えるほど、カーネルのソース
が変わってしまい、パッチを当てるのが難しくなる
◦ Upstream カーネルを使う方法は、バージョン間の変更を理解してパッチを当てないといけないため、職人芸になってしまう
◦ 今回は、職人芸要素の低いマイナーバージョンアップに取り組む
Porter ボードの BSP Kernel BSP の Kernel バージョンは 3.10.31-LTSI◦ 3.10.x は LTS に選ばれており、サポートが長いことで有名な
REL7 に採用されていることから、他のバージョンよりも長期間のメンテナンスが期待できる 次の LTS に選ばれた 3.14 は 2016/9/11 に EOL になってしまっ
たが、 3.10 は 2016/10/2 現在メンテナンスが続いている
◦ 3.10.x の最新バージョンは 3.10.103(2016/8/28 時点 ) BSP は 3.10.31-LTSI から分岐しており、それ以降のメンテナン
スパッチが当たっていない 当たっていないパッチの数は 3536 ある
ARM 固有のパッチは BSP に取り込まれているケースもあるが、共通部は手薄
ext4 の Fix と予想されるパッチだけでも 53 個ある
注 . REL: Red Hat Enterprise Linux
余談ですが LTSI って何？？◦ Linux Foundation のプロジェクト◦ LTS をベースにして、さらなる長期サポートと機能追加
パッチのバックポートを行う◦ 1 年につき 1 バージョンを LTSI に選定し 2 年間のサ
ポートを行う これまでに LTSI になったのは、 3.0-LTSI, 3.4-LTSI, 3.10-
LTSI, 3.14-LTSI, 4.1-LTSI
◦興味をもったらここを参照 http://ltsi.linuxfoundation.org/
BSP カーネルの構成分析 BSP カーネルを構成するパッチは 3 種類に分類できる◦ LTS メンテナンスパッチ
Kernel.org で行われた 3.10.x のマイナーバージョンアップで当てられたパッチ
現在のカーネルは、 3.10 から 3.10.31 までが当たっている状態◦ LTSI パッチ
L.F. の LTSI 開発で当たったパッチ 現在のカーネルは、 3.10.31-LTSI のパッチが当たっている状態
◦ BSP パッチ Upstream や LTSI に含まれていない、そのボード用のパッチ 何が当たっているのかわからない
これらの整合をとって、 3.10.103 までのパッチを当てる必要がある
パッチ当て方針 1 BSP カーネルに 3.10.32 から 3.10.103 までのパッチを単純
に当てていく◦ 手順
1. Kernel.org にある linux-stable の 3.10.y ブランチをチェックアウト2. git format-patch を使って 3.10.31 のバージョン付与以降のパッチを抽出3. git am で抽出したパッチを当てる
Upstream 3.10.31
3.10.32 patch
3.10.33 ～3.10.103 patch BSP patch
Upstream 3.10.31
linux-stable
LTSI(3.10.31) patch
BSP KernelUpdate kernel
BSP patch
Upstream 3.10.31
LTSI(3.10.31) patch
3.10.32 patch
3.10.33 ～3.10.103 patch
BSP から持ってくる
メンテナンスパッチを持ってくる
パッチ当て方針 1 結果 パッチのコンフリクトが多発し、パッチ当てに失敗◦ LTSI パッチとメンテナンスパッチが衝突
LTSI パッチは 3.11 以降のカーネルからの新機能バックポートを含んでいる バックポートによる進化とメンテナンスによる BugFix が同じソースに対す
る異なる変更を引き起こしてしまう 実際には必要としない AMD K6 用のメンテナンスパッチが、 LTSI とバッティン
グ BeyTrail（Ｉｎｔｅｌ ATOM) のバックポート (LTSI) と、 UART のメンテナンス
パッチが同一ソースを別方向に変更しており、パッチのマージが困難
◦ BSP パッチに含まれる ARM 固有部の BugFix の衝突 BSP として必要と判断された、コアのワークアラウンドや ARM 固有部の
BugFix がバックポートされているため、メンテナンスパッチでバックポートされたパッチが当たらない このパターンは、 git am -3 を使うことである程度自動検出が可能 自動検出できない場合でも、修正対象ファイルの git log をパッチの subject で検索
すると、同じ内容のパッチが当たっていることを見つけることができる
パッチ当て方針 2 BSP カーネルから、 BSP 変更部分を抽出し、最新の LTSI
にマージする◦ 手順
1. BSP カーネルから BSP の変更を抽出してパッチを作る2. 最新の LTSI カーネル (3.10.102-ltsi) を作成3. git am で抽出した BSP のパッチを当てる
Upstream 3.10.31
3.10.32 ～3.10.102 patch
BSP patch
Upstream 3.10.31
linux-stable+LTSI
LTSI(3.10.31) patch
BSP KernelUpdate kernel
Upstream 3.10.31
BSP から持ってくる
最新の LTSI から持ってくる
LTSI(3.10.102) patch
3.10.32 ～3.10.102 patch
LTSI(3.10.102) patch
BSP patch
パッチ当て方針 2 結果 苦労はあったが、パッチ当てに成功◦ 方針 1 で多発したパッチの衝突はほとんど発生しなかった
3.10.102 LTSI を起点としているため、方針 1 で問題となったバックポートによる進化とメンテナンスによる BugFix の衝突は解決済み
BSP パッチと 3.10.102 LTSI との衝突は方針 1 と同様に発生したが、ごく少数で済んだ
◦ 方針 2 は BSP パッチの抽出が課題 コミットログからは BSP パッチとそれ以外の分別が困難
LTSI にも R-Car のパッチが含まれているため、パッチが当たるファイルでの分別ができない
コミットログの内容や、 Auther で判断できないか調査したが、結局できなかった
BSP パッチを抽出するために、ブランチの起点を軸としたパッチの総当たり検索で BSP の抽出を行った
パッチあて方針 2 BSP パッチ抽出詳細 (1) BSP は LTSI から作られているため、 LTSI の分岐点以降のパッチをチェックの対象
にする◦ LTSI で一番最初に当たるのは Makefile にある EXTRAVERSION に -ltsi を設定するパッチな
ので、このパッチを探す 調査の結果 BSP は LTSI3.10.28 で fork し、 LTSI3.10.31相当になるようパッチがマージされていること
が判明 BSP パッチとマージしたパッチは順番に並んでいないため、分別の必要がある
Upstream3.10.28
Upstream3.10.31
BSP3.10.31
branch
LTSI3.10.28
LTSI3.10.31
branch
branch
Upstream3.10.29 ～ 31 のパッチと、 LTSI のパッチを BSPのブランチにマージ
LTSI 3.10.31相当のカーネルに BSP 固有のパッチが入っている状態
パッチあて方針 2 BSP パッチ抽出詳細 (2) パッチを抽出するために、以下の仮説を立てた
◦ BSP パッチ抽出 (1) で抽出したパッチの集合は MP◦ 抽出したい BSP 固有のパッチの集合は BP◦ Upstream の 3.10.29 ～ 3.10.31 のパッチの集合は UP◦ Upstream3.10.31 に対して LTSI 3.10.31 で追加されたパッチの集合は LP◦ MP(n) に対して UP,LP との diff をとり、一致するものを除外した結果は BP に等しい、すな
わち UP LP BP=MP∪ ∪ である
Upstream3.10.28
Upstream3.10.31
BSP3.10.31
branch
LTSI3.10.28
LTSI3.10.31
branch
branch
MPUP
LP
BP
UP LP∪
パッチあて方針 2 BSP パッチ抽出詳細 (3) パッチの比較をどのように行うか
◦ パッチの数は、 MP が 5201 パッチ、 UP が 210 パッチ、 LP が 2497 パッチあるため、目視比較は難しい◦ BSP カーネルから抽出したパッチ MP(1) と、 LTSI カーネルから抽出した同じパッチ LP(1) の内容に差分
が出る From に書かれているハッシュが変わってしまっている。 LTSI カーネルは、 linux-stable に LTSI パッチを git apply で当
てるため変わってしまうと考えられる。 Subject も抽出するパッチ数に連動して変わってしまう。 format-patch のオプションで消せなくはないが、今度は順番
がわからなくなってしまうため、消すに消せない。
◦ 先頭から 4 行を比較対象から除外することで、パッチ本体のみの比較を行う (python を使用 )
From 3b25797bc5edbf30e096aa45a8543c1f12128283 Mon Sep 17 00:00:00 2001From: Greg Kroah-Hartman <[email protected]>Date: Sun, 12 Feb 2012 23:09:28 -0800Subject: [PATCH 0001/5201] LTSI Makefile addition
Change the extra version to have -ltsi to have a chance to realize whatkernel version we are using.
Signed-off-by: Greg Kroah-Hartman <[email protected]>--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefileindex addf1b0..5738a9b 100644--- a/Makefile
From 1f71f3bbdeb3a4ebdca89858ae35b6fded47fea9 Mon Sep 17 00:00:00 2001From: Greg Kroah-Hartman <[email protected]>Date: Sun, 12 Feb 2012 23:09:28 -0800Subject: [PATCH 0001/2497] LTSI Makefile addition
Change the extra version to have -ltsi to have a chance to realize whatkernel version we are using.
Signed-off-by: Greg Kroah-Hartman <[email protected]>--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefileindex addf1b0..5738a9b 100644--- a/Makefile
BSP カーネルから抽出したパッチ
LTSI カーネルから抽出したパッチ
パッチあて方針 2 BSP パッチ抽出詳細 (4) Python による機械比較による BP 抽出
◦ MP5201 パッチのうち 2637 パッチの除外に成功 目標値は 2497+210=2707 パッチなので、 97.4%
◦ 除外に失敗したパッチの分析 先頭 4 行を除くと、パッチ内の index 行に差が出てしまっており、同一のパッチと判断で
きなかった
UP が 210 パッチと少なかったため、 subject 行の改行が異なる位置で入ってしまい、 5行目が不一致になってしまった
残りの 70 パッチに関しては目視チェックにより除外できた
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.cindex 0bb5ccc..7aa26b5 100644--- a/sound/soc/soc-jack.c
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.cindex 0bb5cccd..7aa26b5 100644--- a/sound/soc/soc-jack.c
Date: Fri, 15 Nov 2013 14:53:14 -0800Subject: [PATCH 2531/5201] usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix()
Date: Fri, 15 Nov 2013 14:53:14 -0800Subject: [PATCH 018/210] usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix()
勉強会で Index 行の差は、そのパッチの前に当たっているパッチに依存しているとのコメントをいただきました。Index 行は diff から外してしまってよいようです。
パッチあて方針 2 BSP パッチの適用詳細 最新の LTSI(3.10.102LTSI) に対して BSP パッチ BP を適用する
◦ Linux-stable3.10.102 に対して 3.10.102 用の LTSI パッチを適用し、 3.10.102LTSI を作成
◦ 3.10.102LTSI に対して、抽出した BP を当てることで、 3.10.31 から 3.10.102 までのメンテナンスを取り込んだ BSP カーネルを作成する
Upstream3.10.102
Upstream3.10.103
BSP3.10.102
branch
LTSI3.10.102
branch
BP
BSP3.10.31
この間の差は、カーネルのメンテナンスパッチのみになる
この差の取り込みに関しては、今後の課題
パッチあて方針 2 BSP パッチの適用結果詳細 目標とした 3.10.102LTSI ベースの BSP カーネル作成は成功
失敗と課題◦ LTSI パッチの抽出を誤って 3.10.31 ではなく 3.10.28 で行ってしまった
ため、その間に追加された 10 パッチが最初にコンフリクトしてしまった 目視抽出で除外して対応
◦ 抽出した BSP カーネルに、 3.10.31 以降に追加された一部のパッチが取り込まれていたため、そのパッチがコンフリクト (49 パッチ ) これも数が少なかったため、 git のログと照合して 3.10.102LTSI 時点で当たっ
ているものを除外◦ Porter ボードは BSP カーネルに Yocto のレシピでパッチを当てて対応し
ていたため、これを当てないと動作しなかった 不足しているパッチを適用して対応
◦ どうしても当たらないパッチが一つだけ残ってしまった 変更行が衝突しており、有効な解決策がなく保留
まとめ 今回のまとめ
◦ 今回は Renesas 社の Porter ボード用 BSP カーネルを題材として、 Upstreamカーネルのメンテナンスを取り込む簡単な方法を検討、試験した。
◦ ファイルサーチと diff ライブラリのある python 使うことで、 97% のパッチを機械的に分別でき、手作業による分別を 3%未満に抑えることができた。 今回の失敗をフィードバックすることで 99% のパッチを機械的に分別できる見込み
残課題◦ LTS のメンテナンスに対して遅れがちな LTSI カーネルの最新版へのアップ
デートには成功したが、 LTS の最新には到達できていない (3.10.102~3.10.103のパッチを取り込めていない）ため、これに対する方策が必要 単純にパッチを当てれば済む可能性もあるが、現時点では未実施
試しにやったらあっさり当たってしまいました。現状 3.10.104 までのパッチを当てることに成功しています。
◦ 変更前後のリグレッションテストの方法が確立できていない LTP等で同一コンフィグ設定でテストする等
