コグノスケ

自分のドメインとGmailとDNSのSPFレコード

目次: 自宅サーバー

Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース（Gmailユーザへメールが届かなくなる？Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説！ - NRIセキュア ブログ）を思い出しました。

自分のドメインからGmailにメールを送ることはほとんどないですが、全く送れないのも困りそうです。試しにGmailに自分のドメインのメールアドレスからメールを送ったところエラーが返ってきました。もうポリシーが変更されているのでしょうか？

とりあえずDNSの設定を変更してSPF（RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1）レコードを追加します。送信元がメールサーバーのIPと一致しなければ、全部受信拒否してOKという強気の設定にしました（バリュードメインの設定パネル用の書式で書いています）。

txt @ v=spf1 ip4:219.94.129.142 -all

設定後しばらく待って（少なくともDNSのTTLに指定した秒数以上）からGmailにメールを送ったところ正しく届いていました。良かった良かった。

設定の意味がわからないときは

SPFレコードの設定を解説してくれているブログ（送信ドメインを認証するためのSPFレコードに詳しくなろう - SendGridブログ）が参考になりました。

活きた設定例を見たいときはプロバイダ各社のSPFレコードを見ると良いと思います。SPFはTXTレコードの一種なので、TXTレコードをDNSに問い合わせます。

$ dig wakwak.com TXT
（略）

;; QUESTION SECTION:
;wakwak.com.                    IN      TXT

;; ANSWER SECTION:
wakwak.com.             86400   IN      TXT     "v=spf1 ip4:211.9.226.0/25 ip4:211.9.226.128/26 ip4:211.9.227.0/25 ip4:211.9.227.160/27 ip4:211.9.230.0/23 ip4:211.132.128.0/23 ip4:211.132.130.160/28 ip4:211.132.130.132/31 ip4:211.132.130.208/31 ip4:219.103.130.0/24 ip4:219.103.131.128/26 ~all"

;; AUTHORITY SECTION:
wakwak.com.             73658   IN      NS      ns2.wakwak.com.
wakwak.com.             73658   IN      NS      ns1.wakwak.com.

;; ADDITIONAL SECTION:
ns1.wakwak.com.         37518   IN      A       211.9.226.37
ns2.wakwak.com.         37518   IN      A       211.9.226.101

理由はわからないですが、プロバイダのSPFレコードを見るとディレクティブ（レコードの最後の部分）に~allを使っていることが多いです。

今回はkatsuster.netのSPFレコードのディレクティブを-all（ルールに合致しなければ全部受信拒否）にしましたが、世の中のプロバイダ同様に~all（ルールに合致しなくても受信拒否しない）でも良いのかもしれません。

M5Stamp C3のAD端子

目次: Arduino

M5Stamp C3で遊んでいるとプログラムが妙に遅くなることがあって気になります。AD端子が関わっているようです。原因を調べてメモしておきます。

まず全力を見るためdigitalWrite()でGPIO出力のHIGH <-> LOWを往復させるだけのスケッチ（Arduinoはボードで動かすプログラムのことをスケッチと呼ぶ）を作成し、出力がHIGH区間の幅（＝ループ1回の処理に掛かる時間）をオシロスコープで計測したところ約7.6usでした。

M5Stamp C3のピン配置図（M5Stack社のサイトから転載）

M5Stamp C3のピン配置図を見るとA/D変換に対応した端子は0, 1, 4, 5の4つです。先ほどのスケッチにA/D変換対応端子の読み出し（＝処理が遅くなる容疑者）を順に追加して、同様にループ1回の処理に掛かる時間を計測します。

• digitalWrite()のみ: 7.6us
• analogRead(0): 64.0us
• analogRead(0), (1): 118.0us
• analogRead(0), (1), (4): 176.0us
• analogRead(0), (1), (4), (5): 20.8"ms"

どういう訳かanalogRead(5)だけが異常に遅く、読み出し値も常に0で正常動作していないように見えます。とりあえずこの端子は使わないことにしましょうか……。

もうひとつのA/D変換対応端子の読み出しAPIであるanalogReadMilliVolts()の時間も計測しましょう。読みだした値をmV単位に換算する処理が必要なので、処理時間はanalogRead() < analogReadMilliVolts()になるはずです。

• analogRead(0): 64.0us
• analogReadMilliVolts(0): 80.0us

割り算が要るのでそこそこ重い処理だと思いますが、16us（160MHz換算で2560クロック）も掛かるんですね。迂闊に連打しない方が良さそうです。

M5Stackとesp32とArduino

目次: Arduino

M5Stackというボードが電子工作に便利らしいという話を聞き、M5 Core2とM5Stamp C3という小型のボードを買いました。Core2の方は機能豊富な分、お値段もそこそこ（8,000円くらい）します。M5Stampは安い（1,300円くらい）です。

開発環境

M5Stackのサイト（M5Stack document PLATFORMのページ）を見ると、AIなど特定用途向けを外すと開発環境は4つあるようです。多いなあ。派閥争い中でしょうか。

• UIFlow
• Arduino IDE
• Micropython
• .NET nanoFramework

1番目に表示されているUIFlowが一番おススメなのでしょうけど、残念ながらUIFlowはM5Stamp C3に対応していないようです。2番目に表示されていたArduino IDEにしました。Arduino IDEを使うなら素直にArduinoボードを買った方が良かったかな、まあいいか。

M5Stamp C3はデバッグできない

M5StackシリーズはいずれもEspressifのESP32ファミリーのSoC（IoT向けの小規模SoC）を採用しています。CPUとSRAM、一通りの低速系I/O I2C, SPI, I2Sなどの他に、Wi-FiやBluetoothに対応していて素晴らしいSoCです。無線技術に強いEspressifならではですね。

私が購入したM5Stamp C3はESP32-C3というSoCを採用しています。ESP32シリーズの中でC3は割と後発らしく、CPUが従来のXtensaではなくRISC-Vに変更されています。

新しいせいかCPUアーキを変更したせいか知りませんが、Arduino IDEでデバッグしようとしてもOpenOCDが繋がらないとエラーが出てデバッグできないです。ログを全部載せると長いので別ファイル（ ログ全部）にします。

Debug: 215 114 command.c:155 script_debug(): command - init
Debug: 216 115 command.c:155 script_debug(): command - target init
Debug: 217 115 command.c:155 script_debug(): command - target names
Debug: 218 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-flash-erase-start
Debug: 219 115 command.c:155 script_debug(): command - esp32c3 configure -event gdb-flash-erase-start reset init
Debug: 220 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-flash-write-end
Debug: 221 115 command.c:155 script_debug(): command - esp32c3 configure -event gdb-flash-write-end reset halt
Debug: 222 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-attach
Debug: 223 116 target.c:1659 handle_target_init_command(): Initializing targets...
Debug: 224 116 riscv.c:444 riscv_init_target(): riscv_init_target()
Debug: 225 116 semihosting_common.c:107 semihosting_common_init():  
Error: 226 131 esp_usb_jtag.c:642 esp_usb_jtag_init(): esp_usb_jtag: could not find or open device!    ★JTAGが見つからない？？
Debug: 227 131 command.c:545 run_command(): Command 'init' failed with error code -4
User : 228 131 command.c:608 command_run_line(): 
Error: 229 131 riscv.c:1755 riscv_get_gdb_arch(): Unsupported xlen: -1
Error: 230 131 esp_semihosting.c:67 target_to_esp_semihost_data(): Unknown target arch!
Debug: 231 131 riscv.c:490 riscv_deinit_target(): riscv_deinit_target()
Debug: 232 132 target.c:2225 target_free_all_working_areas_restore(): freeing all working areas

エラーの前後だけ切り出すとこんな感じです。JTAGデバイスが見つからんと言っているように見えますが、どうしたら良いか全くわかりません。しばらくはprintfデバッグするしかないようです。M5Stamp C3はM5Stackシリーズを初めて使う人が買うべきボードではなかった？？

ArduinoとESP32ライブラリ

M5Stackについて書かれたブログやコードを見ていると、外部ライブラリ（AdaFruit, Lovyan GFXとか）を使う場合と、Arduino-ESP32ライブラリを使う場合があるようです。

Arduino-ESP32ライブラリのドキュメントはEspressifが公開しています（Arduino-ESP32 2.0.14 documentation）。このライブラリはOSSでGitHubにてソースコードが公開されています（Arduino core for the ESP32 - GitHub）。

どうやってライブラリを入れ替えるのかわかりませんけど、Arduinoライブラリの中を見ることはできそうです。ありがたいですね。

Arduino-ESP32ライブラリはESP32 IDF（IoT Development Framework）というEspressif独自APIのライブラリを使用して実装されているようです。ドキュメントはやはりEspressifが公開しています（ESP-IDF Programming Guide）。GitHubにてソースコードも公開されています（Espressif IoT Development Framework - GitHub）。

このライブラリはちゃんと見てないですが、バイナリ（*.a）しかない部分もあって若干意味不明に見えます……。まあライブラリの表面だけだとしてもソースコードがあってありがたいです。きっと。

令和6年能登半島地震災害への寄付

正月も元日から日本を揺るがした能登半島の震災ですが、令和6年能登半島地震災害義援金（日本赤十字社のサイト）、受付が始まってましたので寄付しました。何かの助けになると良いな……。

寄付したと言いふらすのは行儀が良くないと昔は思っていましたが、言いふらしても誰も不幸にならないし「みんなやってる」「みんなやろう」も広まるし、悪いことはないので積極的に言うようにしています。

メモ: 技術系？の話はFacebookから転記しておくことにした。追記あり。

VSCodeでRISC-Vボードをデバッグその4 - SSH Remote ExtensionでGDBをボードにアタッチ

目次: Linux

前回はLinuxマシン単独でGDBを使ってRISC-Vボードのデバッグを行うところまでを設定しました。

今回はその続きで、Visual Studio Code（以降VSCode）とSSH Remote Extensionを使ってGDBをOpenOCDに接続しRISC-Vボードをデバッグします。

C/C++ Extension Packをインストール

C/C++デバッグ用のExtensionをSSH接続先にインストールします。C/C++ Extension Packをインストールしておくのが便利だと思います。

launch.json fileの作成

左側のActivity BarからRun and Debugを選択して（矢印1）、create a launch.json fileを押すと（矢印2）、デバッガを選べと言われるのでC++ (GDB/LLDB)を選択します（矢印3）。もしC++ (GDB/LLDB)が選択肢に現れない場合は、ソースコードウインドウを全部閉じてからもう一度やってください。

CMakeLists.txtを選択していた時に出るエラー

C言語ではないファイルを開いてRun and Debugやcreate a launch.json fileを押すと選択肢が変わるので注意してください。例えばCMakeLists.txtを開いてRun and Debugを押すと"CMake does not support automatic debugging for this file"とエラーが表示されるだけで何も起きません。

VSCodeは何もファイルを開いていなければ使用可能なデバッガを全て列挙し、開いているファイルがあればそのファイルに対して使用可能なデバッガだけを表示するようです。この仕様は初見だと分かりにくいですね……慣れたら便利なのかなあ？

Linuxマシン側の準備

詳細はその2（2023年12月30日の日記参照）にて紹介していますので、ダイジェストでお送りします。

ボードとSSH接続先のLinuxマシンを接続します。メニューの[Terminal] - [New Terminal]で1つ目の端末を開いてOpenOCDを起動します。

$ sudo openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f tcl/board/sifive-hifive1-revb.cfg

メニューの[Terminal] - [New Terminal]で2つ目の端末を開いてGDBを起動し、実行ファイルをロードします。launch.jsonの"program"で指定した実行ファイルをロードしてください。

$ riscv64-zephyr-elf-gdb build/zephyr/zephyr.elf

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load
(gdb) continue

UARTを見てRISC-Vボードが正常に動作していることを確認します。

$ pyserial-miniterm /dev/ttyACM0 115200 --raw

ここまで確認出来たらいよいよVSCodeからGDBを起動できます。長かったですね。

デバッガの設定

先ほど紹介したcreate a launch.jsonを選択するとGDBを起動する設定が生成されます。

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": []
}

が、バグっているのか何なのか、ほぼ何も書かれていないlaunch.jsonが生成されます。なぜ……？無いものは仕方ないので、

{
    "version": "0.2.0",
    "configurations": [        
        {
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/zephyr/zephyr.elf",
            "cwd": "${workspaceFolder}",
            "MIMode": "gdb",
            "miDebuggerPath": "/home/katsuhiro/work/zephyr-sdk/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gdb",
            "miDebuggerServerAddress": "localhost:3333",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
            ],
        },
    ]
}

上記のように変えます。デバッガのパス（miDebgguerPath）は適宜環境に合わせてください。

デバッガ起動

VSCodeのRun and Debugから先ほど作成した設定でデバッガを起動します。

デバッグ用のツールバー

デバッガが起動してOpenOCDに接続できるとVSCodeの上部に小さなツールバーが出てきます。出ない場合は下部にエラーメッセージが表示されるはず。

Pause後の画面の例

ツールバーのPauseボタン（左端）を押すと、HiFive1ボードの実行が停止して実行中のプログラムのソースコードが表示され、コールスタックの表示なども動作するはずです。ブレークポイントの設定や再開、ステップ実行などもできます。

私はCUIでもあまり困らないタイプですが、デバッガだけはGUIの方が見やすくて捗りますね。VSCodeのコード閲覧性が良いというのもありそうです。

できていない点

実質デバッガのアタッチしかできていません。ボードのリセット、実行ファイルのロードを端末から手動でやっている点が非常にイマイチです。

VSCodeのC/C++ Debugger Extensionは良く知らないので、VSCodeから実行する方法が判明したら追記しておきます。

羽田空港で大事故

早朝の便で東京に帰ってきました。

Twitterで羽田空港がどうこうと騒いでいる人がたくさんいて、何かあったのか？とニュースを見たら、羽田空港で日本航空機のエアバスA350と海上保安庁機のボンバルディアDHC8が滑走路上で衝突し、日航機が爆発炎上しているLive映像が流れていました。さっきまで居た羽田空港……だよな？炎上してる……。

A350は炎上してほぼ灰になったにも関わらず、400人もの乗客が全員脱出に成功して死者が一人も出なかったのは奇跡です。日本航空が日頃から安全を重視して取り組んでいる賜物だと思います。

それにしても2024年は1月1日から大災害、大事故が連続しており、何とも不安になるスタートですね……。

石川の大地震

鳥取4日目。2024年が明けました。今年もよろしくお願いいたします。

夕方、奥さんと外を散歩していたら風もないのに近所の家の窓がガタガタと10〜20秒？ほど揺れ続けました。何だ？と思う間に地震警報が発令され、能登半島で大地震があったことを知ったのでした。

地震の後のニュースでは（特にNHKの山内泉アナウンサーが顕著でした）逃げろ、高い場所に逃げろ、テレビなんか見てないで明るいうちに早く逃げろ！という切実な想いが伝わってきました。

ニュースは感情を煽らないのが通常です。しかし東日本大震災では避難を冷静に呼びかけたところ、津波の高さが想像できなかったのか避難が遅れて津波に巻き込まれて亡くなった人がたくさんいたそうです。

東日本大震災の悲しい教訓から、NHKは「今すぐ高いところに逃げること！」とやや感情的に呼びかけるようにした（「東日本大震災を思い出してください！」その時、ことばで命を守れるか。NHKアナウンサーたちの10年 - NHK）のだそうです。

NHKの取り組みは非常に良い取り組みだと思います。

VSCodeでRISC-Vボードをデバッグその3 - Linuxマシン側の準備（Akaria BSP）

目次: Linux

前回はLinuxマシンだけを使って、OpenOCDとGDBでRISC-Vボードをデバッグする方法を紹介しました。

今回はそのおまけです。VSCodeのデバッグの話を見たい方はその4をご覧ください。

デバッグ対象: Akaria NS31 on Arty 7

デバッグ対象は何でも良いと書きました。その例として、別のソフトウェア、別のボードを使うパターン（Akaria BSP + NS31 on Arty 7）を紹介します。

• CPU回路データ: NSITEXEサイトへのリンクから取得できます。
• FPGAへの書き込み: Vivadoサイトへのリンクから取得できます。書き込むだけならVivado Labソリューションで十分です。
• ツールチェーン: GitHubへのリンクから取得できます。アーカイブへの直接リンクはこちら（riscv64-unknown-elf, Ubuntu 22用）です。
• ソースコード: GitHubへのリンクから取得できます。

FPGAへの書き込み方は以前の日記（2023年4月24日の日記参照）でご紹介しました。そちらをご覧ください。

ツールチェーンのインストールをします。ディレクトリはどこでも良いですが、ここでは~/workで作業しているものとします。

$ cd ~/work
$ wget https://github.com/nsitexe/akaria-riscv-toolchain/releases/download/nsitexe-20231117/riscv64-unknown-elf_ubuntu22.tar.gz
$ tar xf riscv64-unknown-elf_ubuntu22.tar.gz
$ export PATH=~/work/riscv64-unknown-elf/bin:$PATH

$ riscv64-unknown-elf-gdb --version

GNU gdb (GDB) 13.0.50.20220805-git
Copyright (C) 2022 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.

次にAkaria BSPのビルドをします。

$ git clone https://github.com/nsitexe/akaria-bmetal
$ cd akaria-bmetal/
$ rm -r build
$ cmake -B build -G Ninja -DARCH=riscv \
    -DCROSS_COMPILE=riscv64-unknown-elf- \
    -DCC=gcc \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DCMAKE_INSTALL_PREFIX=test/sysroot/ \
    -DDEFCONF=riscv_nsitexe_ns31_arty

CMake Warning (dev) at CMakeLists.txt:3 (project):
  cmake_minimum_required() should be called prior to this top-level project()
  call.  Please see the cmake-commands(7) manual for usage documentation of
  both commands.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is GNU 13.2.0
-- The CXX compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/ccache/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/ccache/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The ASM compiler identification is GNU
-- Found assembler: /usr/lib/ccache/cc
---- CC is 'gcc'
---- Compiler is 'riscv64-unknown-elf-gcc'
---- CCASM is 'gcc'
---- Assembler is 'riscv64-unknown-elf-gcc'
---- DEFCONF is 'riscv_nsitexe_ns31_arty'
---- CONF dir is '/home/katsuhiro/work/akaria-bmetal/config'
---- ARCH dir is '/home/katsuhiro/work/akaria-bmetal/arch/riscv'
---- SOC dir is '/home/katsuhiro/work/akaria-bmetal/arch/riscv/nsitexe_ns31'
---- BOARD dir is '/home/katsuhiro/work/akaria-bmetal/board/riscv/nsitexe_ns31_arty'
---- arch  is riscv
---- march is 'rv32imafc_zicsr_zifencei'
---- mabi  is 'ilp32f'
-- Found Doxygen: /usr/bin/doxygen (found version "1.9.4") found components: doxygen dot
-- Configuring done (0.3s)
-- Generating done (0.0s)
-- Build files have been written to: /home/katsuhiro/work/akaria-bmetal/build


$ ninja -C build install

ninja: Entering directory `build'
[46/47] Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/bin/add_auxdata
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/lib/libbmetal_crt.a
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/bmetal.h
-- Up-to-date: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/generated
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/generated/autoconf.h
-- Installing: /home/katsuhiro/work/akaria-bmetal/test/sysroot/include/bmetal/generated/linker_gen.ld

テストアプリをビルドします。

$ cd ~/work/akaria-bmetal/test
$ make USE_NEWLIB=y

ビルドできました。1つ目の端末にてOpenOCDを起動します。

$ sudo openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f ./openocd-ns31.cfg

JTAGインタフェース用の設定ファイルtcl/interface/jlink.cfgはその2（2023年12月30日の日記参照）にてご紹介しています。SEGGER J-Link以外のインタフェースをご利用の場合は適宜変更をお願いします。

NS31 on Arty 7用の設定ファイルopenocd-ns31.cfgは以前の日記（2023年4月7日の日記参照）にてご紹介しています。

2つ目の端末にてGDBを使ってロード＆実行します。

$ riscv64-unknown-elf-gdb hello

(gdb) target remote :3333
(gdb) monitor reset halt
(gdb) load
(gdb) continue

UARTから出力されていることを確認します。

$ pyserial-miniterm /dev/ttyUSB1 9600 --raw

--- Miniterm on /dev/ttyUSB1  9600,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
hello world!
good bye world!

Zephyr + HiFive1のときとロード＆実行方法は一緒です。最初はとっつきにくいかもしれませんが、OpenOCDとGDBの組み合わせであれば他のソフトウェア、他のボードでもほぼ一緒の使い勝手で便利です。