最近、 LLCONモジュールの機能の1つを既に説明しました。これは、Androidデバイスのディスプレイにkmsgログを表示することでした。 次は、kmsgログをコピーするための同様のメカニズムを説明します。 画面にログを表示することは、あらゆる種類のエラーを検索するにはあまり便利ではありません。
そもそも、SoCの再起動時にAndroidデバイスのRAMがクリアされないという事実に注目する価値があります。 この機能は、/ proc / last_kmsgファイルの外観を保証するメカニズムを使用します。 ただし、SoCを強制的に再起動するには、電源ボタンを長時間押す必要があります。これには、RAMの内容を完全または部分的に変更する必要があります。 この場合、RAMの内容が変更されないように、デバイスをUSBケーブルでPCに接続することをお勧めします（少なくとも私のデバイスでは動作します）。
したがって、最初に起動するとき、テストカーネルはRAMの一部の領域を予約して、kmsgバッファーの内容をそこに複製する必要があります。 通常、このビジネスに1 MiBのメモリを割り当て、物理アドレスとして0x7f200000を使用します。 デバイスに2つのGiB SDRAMがインストールされています。
つまり Androidデバイスでこの機能を有効にするには、カーネルコマンドラインに追加のパラメーターを追加します。
llcondmp=0x7f200000,0x100000
llcondmpパラメーターをBoardConfigに追加する例
BOARD_KERNEL_CMDLINE := androidboot.hardware=qcom BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive BOARD_KERNEL_CMDLINE += msm_rtb.filter=0x37 BOARD_KERNEL_CMDLINE += user_debug=31 debug ignore_loglevel BOARD_KERNEL_CMDLINE += llcondmp=0x7f200000,0x100000
LLCONモジュールを含むテストカーネルは、起動時にこのパラメーターを起動し、指定されたRAMの領域を予約する必要があります。 この場合、この特別に準備されたメモリ領域にkmsgログを複製するメカニズムが含まれます。 さらに、この複製は、printk関数の呼び出し内で（つまり、即時かつ透過的に）実行されます。 この状況により、テスト対象のデバイスをSoCで緊急再起動しても、kmsgログを受信できます。
SoCを再起動した後、何らかの方法でこのメモリ領域の内容を読み取る必要があります。 これを行うには、ブートローダーが安定して動作するものをロードする必要があります。これは、ストックカーネルに基づいたTWRPである可能性があります。 ただし、このTWRPは、RAMに同じ領域を予約して、その内容が変更されないようにする必要があります。 つまり まず、TWRPの特別なバージョンを作成してフラッシュする必要があります。
TWRPで使用されるカーネルがRAMの0x7f200000 ... 0x7f2FFFFFセクションを予約するには、このカーネルのDeviceTreeを編集する必要があります。 DeviceTree自体を編集するプロセスでは、別の記事を書く必要があるため、変更自体をdtsファイルで指定します。
/dts-v1/; /memreserve/ 0x7f200000 0x100000; /* */ /include/ "msm8226-v2.dtsi" /include/ "msm8226-qrd.dtsi"
しかし、TWRPはこれで終了していません。 ramdiskにviewmemユーティリティを追加する必要があります。これにより、物理メモリの内容をディスクにダンプできます。 このユーティリティのソースは、 viewmemからダウンロードできます。
完成したviewmem binarはどこで入手できますか
ソースからのTWRPアセンブリに煩わされたくない場合は、テストカーネルのビルドに使用される同じプロジェクトにviewmemソースを追加することをお勧めします。 既製のバイナリviewmemファイルは、目的のTWRPイメージに単純に埋め込まれます。
TWRPの特別なバージョンを準備したら、デバイスに注入する必要があります。 カスタムカーネルをテストするには、このTWRPを「ブート」セクションにアップロードすることをお勧めします。 デフォルトでは、ブートローダーが制御を転送するのはその内容です。 ここでは、この出版物の主題からまったく抜け出さないように、セクションの画像の記入方法については説明しません。
始めるには、デバイスにインストールされているTWRPの特別なバージョンの操作を試してみる価値があります。 viewmemユーティリティの動作を確認することもできます（以下の使用例を参照）。 また、このTWRPを再起動するには、「再起動」メニューセクションで「システム」を選択します。 TWRPは「ブート」セクションにあります。
これで、LLCONモジュールを備えた特別なTWRPとテストカーネルがあり、SoCがフリーズまたは強制的に再構築されます。 そして、これはテストコアのこの動作の理由を見つけるのに十分です。 テストしたカーネルのイメージを「リカバリ」セクションにアップロードすることをお勧めします。 したがって、問題のあるカーネルのテストを開始するには、[再起動]メニューセクションの[回復]項目を選択します。 これは、デバイスを再起動すると、ブートローダーが「リカバリ」セクションの内容に制御を移すことを意味します。 次に、テストされたカーネルでエラーが発生するまで待つ必要があります。 エラー自体がSoCの再起動を引き起こす場合、何もする必要はありません。 事前に準備されたTWRPが自動的に起動します。 エラーが原因でフリーズした場合は、電源ボタンを押したままハードウェアの再起動を待ちます（最も重要なことは、USBケーブルを忘れないでください）。
まず、ADB接続を使用してTWRPを起動し、メモリからディスクにkmsgログをコピーします。
adb shell viewmem 0x7f200000 0x100000 > /sdcard/kmsg_llcon.txt exit
ここで、SDカードからkmsg_llcon.txtファイルをコピーして、その内容の調査を開始する必要があります。
私はすでにこのデバッグ方法を3回使用しています。
- Innos D10Fデバイス用のカスタムカーネルバージョン3.4の作成（2014）。
- Innos D9デバイス用のカスタムカーネルバージョン3.4の作成（2015）;
- Innos D10Fデバイス用のカスタムカーネルバージョン3.10の作成（現在のプロジェクト）。
そのため、Androidコアを開発する場合、デバッグに使用されるUART、 JTAG 、 EmbeddedICE DCC、およびその他のツールなしで完全に実行できます。
注：前回の出版物「 AndroidデバイスのブートアニメーションをちらつきのあるLinuxカーネルログに置き換える 」でLLCONモジュールのソースコードを探してください。