コグノスケ


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

link もっと前
2022年1月26日 >>> 2022年2月8日
link もっと後

2022年1月28日

OpenOCD on Rapberry PiでJTAGデバッグ

目次: OpenOCD

SiFiveのHiFive1というボード(SiFiveのサイトへのリンク)をデバッグするときは、HiFive1のオンボードUSB-JTAGを使うことが多いと思います。

非常に便利ですがUSB接続ゆえに近くにPCが必要です。PCを作業机の横に置けば何の問題もないんですけど、我が家の場合は諸事情でちょっと困った配置になっています。

  • HiFive1は作業机の上(手の届く範囲)に置きたい
  • PCは隣の部屋(ファイルサーバーの近く、有線ネットワークが繋がる範囲)に置きたい

PCを作業机の横に持ってくる手も考えましたが、悪あがきとしてRaspberry Pi 3でOpenOCDを実行してサーバー代わりにしてみました。結果から言うと、思っていたよりうまく動いてくれました。嬉しい、Raspberry Pi偉い。

各機器の接続

各機器の接続関係はこんな感じです。各ソフトに改造は不要です。GDBのTCP経由でデバッグできる機能と、OpenOCDのGDB serverとして振る舞う機能の合わせ技で実現できます。

PC, HiFive1, Raspberry Piの接続
(通常)
PCのGDB <-(TCP local接続)-> PCのOpenOCD <-(USB)-> HiFive1

(今回)
PCのGDB <-(TCP接続)-> Raspberry Pi 3のOpenOCD <-(USB)-> HiFive1

こんな変な使い方まで想定内とは驚きです。GDBもOpenOCDも良くできています。

Raspberry Pi 3側のログ(OpenOCD)

Raspberry Pi 3ではOpenOCDを実行します。

OpenOCDログの一例
$ ./src/openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f ./tcl/board/sifive-hifive1-revb.cfg

Open On-Chip Debugger 0.11.0+dev-00551-gaad871805 (2022-01-16-22:30)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Info : J-Link OB-K22-SiFive compiled Nov 22 2019 12:57:38
Info : Hardware version: 1.00
Info : VTarget = 3.300 V
Info : clock speed 4000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Info : datacount=1 progbufsize=16
Info : Disabling abstract command reads from CSRs.
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40101105
Info : starting gdb server for riscv.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : Found flash device 'issi is25lp032' (ID 0x0016609d)
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections


Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1606 ms). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1523 ms). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1599 ms). Workaround: increase "set remotetimeout" in GDB
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1610 ms). Workaround: increase "set remotetimeout" in GDB
Warn : Error writing to GDB socket. Dropping the connection.
Info : dropped 'gdb' connection
Info : accepting 'gdb' connection on tcp/3333
Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1614 ms). Workaround: increase "set remotetimeout" in GDB

PC側からmonitor resetを実行すると「1,000ms以内に返事が来ない!タイムアウトしたぞ!」というWarningログが頻発します。HiFive1の反応が遅いのか、Raspberry Pi 3の判断が遅いのか、どちらかよくわかりません。両方かな……?

PC側のログ(GDB)

PCではGDBを実行します。例ではZephyrのバイナリを送っていますが、Zephyr以外でも手順は同じです。

GDBログの一例
$ riscv64-zephyr-elf-gdb build/zephyr/zephyr.elf

GNU gdb (crosstool-NG 1.24.0.378_e011758) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=riscv64-zephyr-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from build/zephyr/zephyr.elf...

(gdb) target remote 192.168.1.106:3333
Remote debugging using 192.168.1.106:3333
0x00001004 in ?? ()

(gdb) monitor reset halt
JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2)
keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1615 ms). Workaround: increase "set remotetimeout" in GDB

GDBもタイムアウトがどうのこうのと怒っています。特に異常動作はしないので放っておいても良いですけど、邪魔であればメッセージのおススメ通りにset remotetimeoutの値を伸ばすと良いでしょう。

Raspberry Pi 3の変なエラー

基本的には以上です動きました良かったね!で終わりなんですけど、Raspberry Pi 3のdmesgを見ていたら見慣れないエラーが出ていたのでメモしておきます。

Under-voltageエラー
[  253.885123] usb 1-1.5: new full-speed USB device number 6 using dwc_otg
[  254.021413] usb 1-1.5: New USB device found, idVendor=1366, idProduct=1051, bcdDevice= 1.00
[  254.021440] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  254.021475] usb 1-1.5: Product: J-Link
[  254.021490] usb 1-1.5: Manufacturer: SEGGER
[  254.021505] usb 1-1.5: SerialNumber: 000979016829
[  254.023795] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device
[  254.027758] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device
[  254.031278] usb-storage 1-1.5:1.5: USB Mass Storage device detected
[  254.032081] scsi host0: usb-storage 1-1.5:1.5
[  254.875197] Under-voltage detected! (0x00050005)    ★★★★これと★★★★
[  255.037642] scsi 0:0:0:0: Direct-Access     SEGGER   MSD Volume       1.00 PQ: 0 ANSI: 4
[  255.038948] sd 0:0:0:0: Attached scsi generic sg0 type 0
[  255.043115] sd 0:0:0:0: [sda] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB)
[  255.052887] sd 0:0:0:0: [sda] Write Protect is off
[  255.052914] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08
[  255.055179] sd 0:0:0:0: [sda] No Caching mode page found
[  255.055202] sd 0:0:0:0: [sda] Assuming drive cache: write through
[  255.148361]  sda:
[  255.166356] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  259.035120] Voltage normalised (0x00000000)    ★★★★これ★★★★

このエラーはRaspberry Pi 3とHiFive1のUSB端子を接続したときに出現します(私の環境だと接続のたびに必ず発生)。電力供給ラインであるUSBのVBus端子電圧が下がっているという意味ですかねえ……?可能性としてはHiFive1が起動時だけ一気に大電力を消費することが考えられますが、深追いしておらず真相はわかりません。

編集者:すずき(2023/09/24 09:18)

コメント一覧

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



2022年1月29日

HiFive1のJTAG周りについて

目次: OpenOCD

HiFive1のJTAGを使う際はJ-Linkの設定(tcl/interface/jlink.cfg)を使えばOKです。しかしSEGGER J-LinkのJTAG箱が見当たらないのに、なぜこの設定で動くのか若干気になりました。調べたら納得だったのでメモしておきます。

回路図を見るとマイコンでUSB-JTAG変換を実現しています。USB端子はNXP MK22FN128VLH10(MK22FN128VLH10 Product Information - NXP)に接続されており、このICからJTAGの信号(TDIなど)が出ています。JTAGの信号線はSiFive FE310に接続されています。

なぜ突然NXPのマイコンICが出てくるのか?J-Linkはどこから来た??と思いきや、実はこれSEGGER J-LinkのオンチップJTAG、J-Link-OBというシリーズの1つで使われているマイコンです(参考: J-Link OB Debug Probe - SEGGER)。SEGGER J-Linkは専用のICがあるわけではなく、NXPやSTのマイコンで実現しているんですね、なるほど。

カタログ上はCortex-M/Cortex-A用となっていますが、これはSEGGER独自の機能が使えるか使えないかを表しているのでしょう。JTAGは4つの信号線(TMS, TCK, TDI, TDO)でJTAGのプロトコルを理解するデバイスが相手であれば良くて、CPUの種類は特に気にしないはず……。

編集者:すずき(2023/09/24 09:18)

コメント一覧

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



2022年2月2日

AArch64向けLinuxデバッグ環境の構築

目次: GCC

目次: Linux

Linuxをデバッグするにはkgdbを使うと思いますが、QEMU + GDBでよりお手軽にデバッグができます。お手軽とは書いたものの、実際やったところQEMUでかなり苦戦したのでメモしておきます。

ツールチェーンの設定

対象のアーキテクチャはAArch64を選びました。お好きなアーキテクチャを使っていただいて構いませんが、Linuxのコンフィグをどうするべきかと、QEMUの動かし方を知っているアーキテクチャにしてください。せっかくLinuxをビルドしても動かせなくて詰みます。

ツールチェーンの構築の方法は昔の日記(2018年7月15日の日記参照)で構築手段をご紹介しています。crosstool-ngはデフォルトだとGDBがビルドされなかった気がするので、

crosstool-ngの設定
CT_DEBUG_GDB=y

Debug facilities  --->
  [*] gdb  --->

この変更が必要になると思います。

Linuxの設定

Linuxカーネルはlinux-nextを使いました。新し目のLTSカーネルなども十分動くはずです。コンフィグの変更点は下記のとおりです。

Linuxの設定
CONFIG_RANDOMIZE_BASE=n(gdbでデバッグするときは、アドレスをランダムに変えられると困るため)

Kernel Features  --->
  [ ] Randomize the address of the kernel image


CONFIG_DEBUG_INFO_REDUCED=n(yだとgdbで構造体などの情報が見えなくなるため)

Kernel hacking  --->
  Compile-time checks and compiler options  --->
    [*] Compile the kernel with debug info
      [ ]   Reduce debugging information


CONFIG_MODULES=n(モジュールのインストールが面倒なので)

[ ] Enable loadable module support  ----

デフォルトのコンフィグだと、やたらと色々なドライバをビルドするので時間がかかります。グラフィクス系のドライバなどの明らかに不要なドライバは外しても良いと思います。

QEMUの設定(失敗編)

QEMUは様々なハードウェアを模倣できます。そのなかにRaspberry Pi 3bがありましたのでこれを使います。initrdイメージはbuildrootで作りました。

QEMU Raspberry Pi 3bマシンでの起動例

qemu-system-aarch64 \
  -machine raspi3b \
  -kernel arch/arm64/boot/Image \
  -append "earlycon=pl011,0x3f201000 console=ttyAMA0" \
  -dtb arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb \
  -initrd ../buildroot/output/images/rootfs.cpio \
  -serial stdio \
  -s

起動してプロンプトまで表示されますが、キー入力を全く受け付けず操作不能になってしまいます。解決方法がわからなかったので諦めました。

ちなみに最近のlinux-nextを使う場合は、GPIOとpinctrlの初期化順を修正するパッチを当てないといけません。これを当てないとpinctrlが無効になってしまい、連鎖的にpinctrlに依存しているSDカードのドライバなども無効化され「rootfsがマウントできない!」とpanicになってしまいます。

この問題に気づくまでかなり時間がかかりました。バグだと思ってめっちゃ調べたのに、もうパッチがLKMLに投稿されていたという体験は、linux-nextを使っていると珍しくないですけどね。よりによってRaspberry Piだけで起きるバグをタイムリーに引くとは思わなかった……完全に油断してた。

QEMUの設定

Raspberry Piマシンの代わりにvirtマシンを使うことにしました。

今回はユーザーランドは動けばOKですから、Raspberry PiのディスクイメージRaspberry Pi OS Lite 64bit(公式ダウンロードサイト)を使用します。

QEMUで起動する場合virtioを使用します。QEMUのvirtマシンは残念ながらSDやmtdには対応していません。パラレルフラッシュはサイズが64MBまでのためにRaspberry Pi OSのイメージは大きすぎると言われ起動できません。

QEMU AArch64 virtマシンの起動例
qemu-system-aarch64 \
  -machine virt -cpu cortex-a53 -smp 1 \
  -kernel arch/arm64/boot/Image -append "rw root=/dev/vda2" \
  -drive file=2022-01-28-raspios-bullseye-arm64-lite_resize.img,format=raw,if=virtio \
  -serial stdio \
  -s

最後の -sオプションはGDBの接続をポート1234で待機するオプション -gdb tcp::1234の短縮形です。カーネルのブート部分などをデバッグする場合は、GDBを接続するまで停止していてほしいので -Sも一緒に付けると良いです。

デバッグしよう

前置きがだいぶ長くなりましたがこれでデバッグ環境が整いました。GDBをQEMUに接続するにはtarget remoteコマンドを使います。

QEMU + GDBによるLinuxカーネルデバッグ
$ aarch64-unknown-linux-gnu-gdb vmlinux

GNU gdb (crosstool-NG 1.24.0.501_5bf4485) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=aarch64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vmlinux...


(gdb) b start_kernel

Breakpoint 1 at 0xffff800009e10c64: file init/main.c, line 931.


(gdb) target remote :1234

Remote debugging using :1234
0x0000000040000000 in ?? ()


(gdb) c

Continuing.

Breakpoint 1, start_kernel () at init/main.c:931
931     {

実行、ブレーク、ソースコードの表示もできています。良い感じですね!

編集者:すずき(2024/07/16 17:51)

コメント一覧

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



2022年2月3日

ZephyrのDevice Tree Overlay

目次: Zephyr

ZephyrはプロジェクトごとにDevice Treeを上書きできます。Device Tree Overlayと呼ばれたりもしますね。やり方は違いますがLinuxでも似たような仕組みがあります。

具体的にはsamples/hello_worldの下にboardsというディレクトリを作成し、ボード名.overlayというファイルを作成するだけです。Zephyrのビルドシステムが勝手に検知してくれます。便利ですね。

今回はqemu_riscv64向けに作りますからファイル名はqemu_riscv64.overlayになります。

Overlayファイルを作成する場所
samples/hello_world/
├──CMakeLists.txt
├──README.rst
├──boards
│   └──qemu_riscv64.overlay    ★これ★
├──prj.conf
├──sample.yaml
└──src
    └──main.c
qemu_riscv64.overlayの例

/* samples/hello_world/boards/qemu_riscv64.overlay */

/ {
	resources {
		compatible = "test-overlay";
		value1 = <1>;
		value2 = <10>;
	};
};

Overlayが効いているかどうかはビルド後に生成されるzephyr/zephyr.dtsを見るとわかります。

(build)/zephyr/zephyr.dts
/dts-v1/;

/ {
	#address-cells = < 0x1 >;
	#size-cells = < 0x1 >;
	compatible = "riscv-virtio";
	model = "riscv-virtio,qemu";
	flash@20000000 {
		bank-width = < 0x4 >;
		reg = < 0x20000000 0x2000000 0x22000000 0x2000000 >;
		compatible = "cfi-flash";
	};

/* (略) */

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,sram = &ram0;
	};
	resources {    /* ★追加された★ */
		compatible = "test-overlay";
		value1 = < 0x1 >;
		value2 = < 0xa >;
	};
};

Overlayのcompatibleとプロパティは適当です。当然compatibleに対応するコードはありませんが、今の段階ではエラーにはなりません。

Overlayの次は

デフォルトで無効化されているデバイスを有効にする(status = "okay"; を足したい)くらいであれば、Overlayファイルの追加だけでも十分に役立ちます。

しかしZephyrはもう少し複雑な機能も提供しています。次回は独自のcompatibleを扱う方法をご紹介したいと思います。

編集者:すずき(2023/09/24 12:08)

コメント一覧

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



2022年2月4日

新しいニッケル水素電池の充電器を購入

目次: 電池

今までニッケル水素電池(以降Ni-MH電池)の充電にはPanasonic BQ-391を使っていました。が、端子の一部が青く錆びてきたため、先日、跡継ぎとしてPanasonic BQ-CC87を購入しました。Amazonで2400円くらいでした。BQ-CC87はUSBでの充電、USBの出力(つまりモバイルバッテリー)もできる1台2役の優れものです。

通常の充電器の使い方だと継ぎ足し充電は避けるべきですが、BQ-CC87は継ぎ足し充電もできる(Panasonicのサイトへのリンク)とのことで、とても良い商品だと思います。が……どうも我が家の電池達と相性が悪くて困っています。

出力側の困った現象

我が家にあるNi-MH電池は5種類あって、

  • Panasonic EVOLTA HHR-3MKS(単3 1900mAh)2本
  • Panasonic EVOLTA HHR-3MWS(単3 1900mAh)2本
  • Panasonic EVOLTA HHR-3MRS(単3 2000mAh)10本
  • Panasonic EVOLTA HHR-4MWS(単4 750mAh)2本
  • SANYO eneloop HR-3UTGA/B(単3 1900mAh)4本

どれを使ってもスマホやタブレットを充電しようとすると、一瞬だけ0.6Aくらい出力しますが、すぐに出力が停止します。運が良いと出力が続きますが、

  • 出力が0.4A程度しか出ない
  • 数秒で停止する
  • DC出力ボタンを押し続けると0.1Aくらいの出力で安定?する(スマホ側が諦めるのか?)

こんな感じでまともに動作しているように見えません。うーん。

故障ではない

最初は機械側を疑ったんですが、新しいNi-MH電池を新たに4本買い(Panasonic EVOLTA BK-4HCD, 単4 930mAh)、スマホの充電を試したところ1A出力できました。機械は壊れていないようです。

ここから推測できることは、単純に我が家にある電池がヘタっているor BQ-CC87で使うには気合が足りないってことです。

充電もできない

もうひとつ困ったことにBQ-CC87は充電する場合も我が家の電池と相性が悪く、すぐに止まってしまいます。その結果DC出力も充電もできない、どうしようもない状態の電池がどんどん増えてしまいます。

うちの電池そんなにダメなの?困ったね。

編集者:すずき(2022/11/26 19:28)

コメント一覧

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



2022年2月5日

射的

目次: 射的

以前、ガスブローバックタイプのエアガンを買ったのですが、家だとうるさいし狭いです。往来の人に危険が及ぶので公の場所(公園、河川敷など)で撃つのも厳禁!!です。というわけで単なる飾りと化していました。

さすがに置物にするのは勿体ないので、どこか撃てる場所はないだろうか?と思って探すと、秋葉原に7mのシューティングレンジのあるカフェ(バー?)がありました。末広町にあるトリガーハッピーというお店お店のサイトへのリンク)です。

やってみた感想は「当たるけど当たらない」ですね。

エアガンの出来はとても良く、狙った方向に飛ぶので正しく狙えば当たります。けど、狙っている私が明後日の方向に狙いを付けているのでぜーんぜん当たりません。7m先と思われる9個の的を倒すのに16秒くらいでした。たぶん早い人は半分くらいのタイムでクリアできるんじゃないかな……。

結果はさておき、普段できない遊びでなかなか面白かったです。また行ってみるかー。

編集者:すずき(2022/04/04 05:16)

コメント一覧

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



2022年2月6日

ZephyrのDevice Tree Overlayと独自のbindings

目次: Zephyr

前回の続きです。ZephyrのDevice Tree Overlay(2022年1月3日の日記参照)で独自のbindingsを定義(compatibleやプロパティの定義)する方法を紹介します。

前回はこんなノードを追加しました。

qemu_riscv64.overlayの例

/* samples/hello_world/boards/qemu_riscv64.overlay */

/ {
	resources {
		compatible = "test-overlay";
		value1 = <1>;
		value2 = <10>;
	};
};

ノードを追加しただけではエラーにはなりませんが、コードからvalue1の値を参照しようとするとビルドエラーになって怒られます。

詳細はZephyrのDevice Tree APIマニュアル(Devicetree API - Zephyr Project Documentation)が参考になります。

Hello worldでvalue1, value2の値を参照する

// samples/hello_world/src/main.c

#include <zephyr.h>
#include <sys/printk.h>

void main(void)
{
	printk("Hello World! %s\n", CONFIG_BOARD);

	printk("value1:%d\n", DT_PROP(DT_INST(0, test_overlay), value1));
	printk("value2:%d\n", DT_PROP(DT_INST(0, test_overlay), value2));
}
ビルド結果
$ ninja
...

zephyr/include/generated/devicetree_unfixed.h:308:34: error: 'DT_N_S_resources_P
_value1' undeclared (first use in this function); did you mean 'DT_N_S_resources
_PATH'?
  308 | #define DT_N_INST_0_test_overlay DT_N_S_resources
      |                                  ^~~~~~~~~~~~~~~~

このあとも大量に怒られる……。

Zephyrはコード内でデバイスツリーの値を参照すると、ビルド時に全て解決される仕組みです。そのためデバイスツリーに不都合な点があるとビルド時に猛烈に怒られます。Zephyrのデバイスツリー処理はPythonとマクロマジックが駆使されていて、コンパイルエラーのメッセージからエラーの原因がすぐにわからないのが難点ですね……。

Linuxは実行時に参照、書き換えが可能なので、ZephyrとLinuxの大きく異なる部分と言えましょう。

デバイスツリー定義yamlファイル

問題の解決にはdts/*.yamlを追加する必要があります。ファイル名はcompatible名.yamlになります。このファイルもOverlayファイル同様に追加するだけでビルドシステムが勝手に感知して処理してくれます。便利ですね。

test-overlay.yamlの位置
samples/hello_world/
├──CMakeLists.txt
├──README.rst
├──boards
│   └──qemu_riscv64.overlay
├──dts
│   └──bindings
│       └──test-overlay.yaml    ★これ★
├──prj.conf
├──sample.yaml
└──src
    └──main.c
test-overlay.yamlの例

# samples/hello_world/dts/bindings/test-overlay.yaml


description: |
    This binding provides AAA and BBB, something for CCC application in Zephyr.

compatible: "test-overlay"

properties:
    value1:
        type: int
        required: true
        description: |
          Identity of AAA of something. This is ...

    value2:
        type: int
        required: true
        description: |
          Identity of BBB of something. This is ...

追加したyamlファイルは非常にシンプルで、compatibleの名前と、value1, value2というint型のプロパティが必須だよ、ということを定義しただけです。

その他のbindingsの定義については、Zephyrのマニュアル(Devicetree bindings - Zephyr Project Documentation)をご覧ください。

ファイルを追加したら改めてビルド&実行しましょう。

bindings追加後のビルド&実行
$ ninja
...

[123/123] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
             RAM:       23700 B       256 MB      0.01%
        IDT_LIST:          0 GB         2 KB      0.00%


$ ninja run

[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv64
*** Booting Zephyr OS build v2.7.99-3416-g7dac931e3662  ***
Hello World! qemu_riscv64
value1:1
value2:10

うまく行きました。Device Tree Overlayとbindingsは同じCコードでボードごとに設定だけ変えたい場合に有用です。

この仕組みはtests下にあるコードでよく使われています。例えばGPIOのテストがわかりやすいでしょう。2つのポートが通信できるか?割り込みが正常に入るか?などがGPIOテストの内容です。

実際に動作させるにはボードごとに配線やピン設定が違いますから、ボードAはピン10と11を使う、ボードBは21と22を使う、というようにボードごとに違う設定を与える必要があります。

設定はコードに書かずにDevice Tree Overlayに逃がして、コードはテストしたい内容のみを記述することで設定もコードもすっきりする、ってわけです。

編集者:すずき(2023/09/24 12:08)

コメント一覧

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



link もっと前
2022年1月26日 >>> 2022年2月8日
link もっと後

管理用メニュー

link 記事を新規作成

<2022>
<<<01>>>
------1
2345678
9101112131415
16171819202122
23242526272829
3031-----

最近のコメント5件

  • link 24年10月1日
    すずきさん (10/06 03:41)
    「xrdpで十分動作しているので、Wayl...」
  • link 24年10月1日
    hdkさん (10/03 19:05)
    「GNOMEをお使いでしたら今はWayla...」
  • link 24年10月1日
    すずきさん (10/03 10:12)
    「私は逆にVNCサーバーに繋ぐ使い方をした...」
  • link 24年10月1日
    hdkさん (10/03 08:30)
    「おー、面白いですね。xrdpはすでに立ち...」
  • link 14年6月13日
    2048player...さん (09/26 01:04)
    「最後に、この式を出すのに紙4枚(A4)も...」

最近の記事3件

  • link 24年10月28日
    すずき (10/30 23:49)
    「[Linuxからリモートデスクトップ] 目次: Linux開発用のLinuxマシンの画面を見るにはいろいろな手段がありますが、...」
  • link 23年4月10日
    すずき (10/30 23:46)
    「[Linux - まとめリンク] 目次: Linux関係の深いまとめリンク。目次: RISC-V目次: ROCK64/ROCK...」
  • link 24年10月24日
    すずき (10/25 02:35)
    「[ONKYOからM-AUDIOのUSB DACへ] 目次: PCかれこれ10年以上(2013年3月16日の日記参照)活躍してく...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
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 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

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

合計:  counter total
本日:  counter today

link About www2.katsuster.net
RDFファイル RSS 1.0

最終更新: 10/30 23:49