# デバッグ方法を構成する

以下の方法で、カーネルをデバッグする方法の高度な分類を把握し、Qualcomm Linuxカーネル固有のデバッグ機能で特定された問題を報告します。

詳細については、[Qualcomm Linux デバッグガイド](https://docs.qualcomm.com/doc/80-70020-12/topic/landing_page.html) を参照してください。

## printkを使用してデバッグする

`printk` 手法を使用して、Linuxカーネルでメッセージの出力とトレースのデバッグを行います。

`include/linux/printk.h` で定義されたprintkの周囲のラッパーは、ログステートメントにログレベルを追加できます。例：

pr_emerg("At line %d: Func: %s\n", __LINE__, __func__);
    pr_info("At line");
    Copy to clipboard

詳細については、[Message logging with printk](https://www.kernel.org/doc/html/next/core-api/printk-basics.html) を参照してください。

## デバイスツリーをコンパイルする

デバイスツリーをデバッグするには、以下を実行します。

1. `devtool modify linux-qcom-custom` コマンドを使用して、カーネルコードをクローンします。
2. デバイスツリーを変更します。
3. `bitbake dtb-qcom-image` コマンドでDTBをビルドします。
4. `fastboot` コマンドを使用して、`build-qcom-wayland/tmp-glibc/deploy/images/qcs6490-rb3gen2-vision-kit/dtb-qcom-image-qcs6490-rb3gen2-vision-kit.rootfs.vfat` （dtb.binと同じです）を `dtb_a` および `dtb_b` パーティションにフラッシュします。
5. デバイスを再起動します。

## カーネルモジュールをデバッグする

カーネルモジュールをデバッグするには、以下を実行します。

1. `devtool modify linux-qcom-custom` コマンドを使用して、カーネルコードをクローンします。
2. 以下の `menuconfig` コマンドを使用して、カーネルモジュール署名構成 `CONFIG_MODULE_SIG` を無効にします。

CONFIG_MODULE_SIG
        Copy to clipboard

CONFIG_MODULE_SIG_FORCE
        Copy to clipboard

注釈

これは1回限りの手順です。
3. カーネルまたはモジュールを変更します。
4. `bitbake esp-qcom-image` コマンドを使用してカーネルモジュールを再ビルドします。
5. `tmp-glibc/deploy/images/qcs6490-rb3gen2-vision-kit/linux-qcs6490-rb3gen2-vision-kit.efi` カーネルイメージを `/tmp` ディレクトリのデバイスにプッシュし、名前を `vmlinuz` （カーネルバイナリ）に変更します。
6. `cp /tmp/vmlinuz /boot/ostree/poky-<SHA>/vmlinuz-6.6.52-03343-gdfbbed24a2c5-dirty` コマンドを使用してカーネルを更新します。
7. `build-qcom-wayland/tmp-glibc/deploy/images/qcs6490-rb3gen2-vision-kit/modules--6.6-r0-qcs6490-rb3gen2-vision-kit-<DATE>.tgz` カーネルモジュールを `/tmp` ディレクトリのデバイスにプッシュします。
8. `mount -o remount,rw /` コマンドと `mount -o remount,rw /usr` コマンドを使用してルートを再マウントします。
9. `tar -xzf modules--6.6-r0-qcs6490-rb3gen2-vision-kit-<DATE>.tgz` コマンドを使用して解凍します。
10. `cp -rf /tmp/lib/modules/6.6.65-debug-04076-g029659012248-dirty/ /lib/modules/` コマンドを使用してカーネルモジュールを更新します。
11. デバイスを再起動します。

## ログレベルを使用してデバッグする

`/linux/printk.h` で定義されたその他の任意のログレベルを使用してメッセージを出力します。コンソールログは、printkで使用されているログレベルと、デバイスで選択されているログレベルを使用して制御されます。

ユースケースに応じてログレベルを選択してください。頻繁に使用される機能で低いログレベルが選択されている場合、多数のログが発生する可能性があります。

以下の例は、カーネル出力レベルのログを示しています。

pr_info("At func %s\n", __func__);
    pr_notice("At func %s\n", __func__);
    pr_warn("At func %s\n", __func__);
    pr_err("At func %s\n", __func__);
    pr_crit("At func %s\n", __func__);
    pr_alert("At func %s\n", __func__);
    pr_emerg("At func %s\n", __func__);
    Copy to clipboard

## debugfsファイルシステムを有効にしてマウントする

debugfsは、カーネル開発者がカーネル情報をユーザー領域に提供するためのファイルシステムです。

debugfsは、カーネルデータの構造と変数、トレースイベント、デバッグメッセージ、統計情報にアクセスするために使用します。

- カーネル構成に `CONFIG_DEBUG_FS` が設定されていることを確認してください（デフォルトで有効になっています）。
- 設定されていない場合は、`menuconfig` を使用してカーネル構成を有効にします。
- debugfsがデフォルトでマウントされていない場合は、マウントします。

mount -t debugfs none /sys/kernel/debug
        Copy to clipboard

## カーネルプローブでデバッグする

Kprobeを使用すると、任意のカーネルルーティンに割り込んで、処理を中断せずにデバッグとパフォーマンスの情報を収集できます。

カーネルコードアドレスはハンドラールーティンによってトラップされ、ブレークポイントにヒットすると呼び出されます。Kprobeは、さまざまなスケジュールイベントでのトレースの生成時にスケジューラーをデバッグする際に、システムの動作を把握するために便利です。

詳細については、[Kernel Probes](https://www.kernel.org/doc/html/next/trace/kprobes.html) を参照してください。

## プロファイリングとトレーシング用にftraceを構成する

ftraceは、システム全体のプロファイリングとランタイム・トレーシングを有効にするトレーシング・ユーティリティを提供します。

ftraceの詳細については、[機能トレース](https://docs.qualcomm.com/bundle/publicresource/topics/80-70020-12/debugging_linux_kernel.html#function-tracer) を参照してください。

### メモリ・マップ入出力トレースを有効にする

Qualcomm Linuxカーネルのメモリ・マップI/O（MMIO）トレースから得られる情報により、ドライバーとMMIOデバイスとのインタラクションと、これに関連付けられるハードウェアの状態を把握できます。

汎用MMIOトレースは `__raw_{read,write}{b,l,w,q}` アクセサーを使用して、メモリ・マップ・レジスタでの読み書きを行います。

以下のような場合では、デバイスが停止するか、未定義の動作によりデバイスがクラッシュします。

> 
> 
> 表：デバイスのクラッシュの理由
> 
> 
> | 理由 | 説明 |
> | --- | --- |
> | 非クロックのアクセス | レジスター領域へのアクセスが非クロックの場合、デバイスはクラッシュします。 |
> | 保護されたレジスター領域 | レジスター領域が保護されていて、保護されていない領域へのアクセス用に設定されていない場合、例外が発生します。例えば、例外レベルEL3のアクセスのみが許可され、EL2/EL1のアクセスができなくなります。 |
> | xPU制御 | xPUメモリ保護ユニットは、特定のクライアントについて、特定のメモリやレジスター領域へのアクセスを制御します。 |

先のシナリオの場合は、インスタント再起動、同期エラー（SError）/ネットワーク・オン・チップ（NoC）の問題、あるいは相互接続の停止が発生します。`CONFIG_TRACE_MMIO_ACCESS` は、そのようなMMIOレジスターへのアクセスをログに記録するためのftraceトレースイベントを表します。これにより、トレースイベント、フィルタリング機能、コンソールでftraceログをダンプする機能を早期に導入できます。

以下は、MMIOトレースが有効になっている場合のトレースバッファのサンプル出力です。

# List all rwmmio trace events
      cat /sys/kernel/tracing/available_events | grep rwmmio
    
    # Enable all rwmmio trace events
      cat /sys/kernel/tracing/available_events | grep rwmmio >> /sys/kernel/tracing/set_event
    
    # List all traces
      cat /sys/kernel/tracing/trace
    rwmmio_read: gic_peek_irq+0xd0/0xd8 readl addr=0xffff800010040104
    rwmmio_write: gic_poke_irq+0xe4/0xf0 writel addr=0xffff800010040184
    rwmmio_read: gic_do_wait_for_rwp+0x54/0x90 readl addr=0xffff800010040000
    rwmmio_write: gic_set_affinity+0x1bc/0x1e8 writeq addr=0xffff800010046130
    Copy to clipboard

Last Published: Jan 01, 2026

[Previous Topic
カーネルログを取得する](https://docs.qualcomm.com/bundle/publicresource/80-70020-3JA/topics/capture-the-kernel-logs.md) [Next Topic
デバイスからコンテンツにアクセス](https://docs.qualcomm.com/bundle/publicresource/80-70020-3JA/topics/access-content-from-the-device.md)