汎用カーネルイメージ(GKI)には、デバイスがパーティションをマウントできるようにするために必要なドライバーサポートが含まれていない場合があります。デバイスがパーティションをマウントして起動を続行できるようにするために、第1段階のinit
が拡張され、RAMディスクに存在するカーネルモジュールがロードされます。 ramdiskは、汎用ramdiskとベンダーramdiskに分割されます。ベンダーカーネルモジュールはベンダーRAMディスクに保存されます。カーネルモジュールがロードされる順序は構成可能です。
モジュールの場所
ramdiskは、第1段階のinit,
およびA / Bおよび仮想A / Bデバイス上のリカバリ/ fastbootdイメージ用のファイルシステムです。これは、ブートローダーによって連結される2つのcpioアーカイブで構成されるinitramfs
です。ベンダーのramdiskとしてvendor-bootパーティションに保存されている最初のcpioアーカイブには、次のコンポーネントが含まれています。
-
/lib/modules/
ある第1段階のinit
ベンダーカーネルモジュール。 -
/lib/modules/
にあるmodprobe
設定ファイル:modules.dep
、modules.softdep
、modules.alias
、modules.options
。 -
/lib/modules/
にある、第1段階の初期化中にロードするモジュールとその順序を示すmodules.load
ファイル。 -
/lib/modules/
A / Bおよび仮想A / Bデバイス用のベンダーリカバリカーネルモジュール modules.load.recovery
は、/lib/modules
、ロードするモジュールと、A / Bおよび仮想A / Bデバイスの順序を示し/lib/modules
。
2番目のcpioアーカイブは、boot.imgのramdiskとしてGKIで提供され、最初のアーカイブの上に適用され、 first_stage_init
とそれが依存するライブラリを含みます。
第1段階の初期化でのモジュールのロード
第1段階のinit
は、RAMディスクの/lib/modules/
からmodprobe構成ファイルを読み取ることから始まります。次に、/ /lib/modules/modules.load
/ modules / /lib/modules/modules.load
(またはリカバリの場合は/lib/modules/modules.load.recovery
)で指定されたモジュールのリストを読み取り、次の/lib/modules/modules.load.recovery
に従って、これらの各モジュールを順番にロードしようとします。以前にロードされたファイルで指定された構成。要求された順序は、ハードまたはソフトの依存関係を満たすために逸脱する場合があります。
ビルドサポート、第1段階の初期化
ベンダーのBOARD_VENDOR_RAMDISK_KERNEL_MODULES
コピーするカーネルモジュールを指定するには、それらをBOARD_VENDOR_RAMDISK_KERNEL_MODULES
にリストします。ビルドはこれらのモジュールでdepmod
を実行し、結果のmodprobe構成ファイルをベンダーのdepmod
に配置します。
ビルドはmodules.load
ファイルも作成し、ベンダーのramdiskcpioに保存します。デフォルトでは、 BOARD_VENDOR_RAMDISK_KERNEL_MODULES
リストされているすべてのモジュールが含まれています。そのファイルの内容を上書きするには、次の例に示すように、 BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
使用します。
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD := \ device/vendor/mydevice-kernel/first.ko \ device/vendor/mydevice-kernel/second.ko \ device/vendor/mydevice-kernel/third.ko
ビルドサポート、完全なAndroid
Android 10 BOARD_VENDOR_KERNEL_MODULES
リリースの場合と同様に、 BOARD_VENDOR_KERNEL_MODULES
リストされているカーネルモジュールは、Androidプラットフォームビルドによって/vendor/lib/modules
ベンダーパーティションにコピーされ/vendor/lib/modules
。プラットフォームビルドは、これらのモジュールでdepmod
を実行し、 depmod
出力ファイルを同じ場所のベンダーパーティションにコピーします。 /vendor
からカーネルモジュールをロードするメカニズムは、Androidの以前のリリースの場合と同じです。これらのモジュールをロードする方法とタイミングはユーザーが決定しますが、通常、これはinit.rc
スクリプトを使用して行われます。
ワイルドカードと統合カーネルビルド
デバイスのカーネルビルドをAndroidプラットフォームのビルドと組み合わせるベンダーは、上記のBOARD
マクロを使用して、デバイスにコピーするカーネルモジュールを指定すると問題が発生する可能性があります。ベンダーがデバイスのプラットフォームビルドファイルにカーネルモジュールをリストすることを避けたい場合は、ワイルドカード( $(wildcard device/vendor/mydevice/*.ko
)を使用できます$(wildcard device/vendor/mydevice/*.ko
統合された場合、ワイルドカードは機能しないことに注意してください。カーネルビルド。makeが呼び出されてマクロがmakefileで展開されると、カーネルモジュールがビルドされていないため、マクロは空になります。
この問題を回避するために、ベンダーはカーネルビルドに、各パーティションにコピーされるカーネルモジュールを含むzipアーカイブを作成させる場合があります。そのzipアーカイブのパスをBOARD_VENDOR_KERNEL_MODULES_ARCHIVE
BOARD_*_KERNEL_MODULES_ARCHIVE
に設定します。 *
はパーティションの名前です( BOARD_VENDOR_KERNEL_MODULES_ARCHIVE
など)。 Androidプラットフォームビルドは、このzipアーカイブを適切な場所に抽出し、モジュールでdepmod
を実行します。
カーネルモジュールのzipアーカイブには、プラットフォームビルドが必要なときにアーカイブを生成できるようにするmakeルールが必要です。
回復
以前のAndroidリリースでは、リカバリに必要なカーネルモジュールはBOARD_RECOVERY_KERNEL_MODULES
指定されていBOARD_RECOVERY_KERNEL_MODULES
。 Android 11では、リカバリに必要なカーネルモジュールは引き続きこのマクロを使用して指定されます。ただし、リカバリカーネルモジュールは、汎用のramdisk cpioではなく、ベンダーのramdiskcpioにコピーされます。デフォルトでは、 BOARD_RECOVERY_KERNEL_MODULES
リストされているすべてのカーネルモジュールは、第1段階のinit
中にロードされinit
。これらのモジュールのサブセットのみをロードする場合は、そのサブセットの内容をBOARD_RECOVERY_KERNEL_MODULES_LOAD
で指定します。
関連ドキュメント
ベンダーのブートパーティション(このページに記載されているベンダーのRAMディスクを含む)の作成については、ブートパーティションを参照してください。