なひたふJTAG日記

令和5年も当ブログをご覧いただき、ありがとうございました。

今年は事業再構築補助金で半導体真贋判定装置を作ったり、東大で非常勤の研究員としてテラヘルツ波の研究をしたり、大忙しでした。

事業再構築補助金では、半導体不足を解決するために流通在庫の怪しいICを真贋判定できる装置を作ったら、完成した5月ごろになって半導体不足が急に回復してきてしまって、全く引き合いがなくなってしまいました。

今年1年間で作った基板や装置は、

① IC真贋判定装置

② 超小型ZYNQボードとArtix-7ボード、

③ Cosmo-Z Mini2

でした。

各月で何をしていたかを振り返ってみると、

1月

• ZCU111でRFSoCのADCとDACを動かす
• 真贋判定装置の開発
• Cosmo-Z Miniの設計開始
• ネプコンジャパンにFPGA真贋判定装置を出展(この時点では動いていない)

2月

• Cosmo-Zの拡張DACボードがついに完成
• Cosmo-Zの64chロックインアンプ作成
• FPGA真贋判定装置を静展示ではなく、動くように開発をはじめる

3月

• 電子情報通信学会で発表(テラヘルツ波通信)
• 300GHz帯の実験局の免許を取得

4月

• FPGA真贋発生装置がついに動き出す！
• Cosmo-Z Mini2のフロントエンドOPアンプの実験

5月

• いろいろなICをどんどん真贋判定できるようになってくる
• Cosmo-KのデザインをVivado 2022.2用にアップデート
• FT232HのMPSSE JTAGについて調べる

6月

• Cosmo-Z Mini2がついに完成
• RECONF件でRFSoCでテラヘルツ波通信をするときのためのナイキストフィルタについて発表
• 決算してみたら2022年度は大赤字だった

7月

• 事業再構築補助金の交付申請(1回目)
• 超小型のZYNQボードを設計しはじめる
• ACRi ウェビナーで講演

8月

• 特電Artix-7ボードのAPIをPythonに対応
• 交付申請が差し戻される

9月

• Cosmo-Zのチュートリアルのページなどを作り始める
• MITOUJTAGのSPI ROMライタがUltraScale+に対応
• 事業再構築補助金の交付申請(2回目)

10月

• 極小のZYNQボードを作る
• 事業再構築補助金の交付決定
• 真贋判定装置用の基板を次々と設計して発注

11月

• FPGA真贋判定装置がひとまず完成(?)
• 事業再構築補助金期間終了し実績報告
• Design Solution ForumにFPGA真贋判定装置を出展

12月

• Raspberry Pi 5やOpenOCDと戯れる

こうして1年を振り返ってみると、半導体真贋判定装置、Cosmo-Z Mini、テラヘルツ波くらいしかやっていなかったですね。

2022年度に半導体不足で製品が作れず大赤字になって債務超過に陥り、なんとか信金から借りたお金も4月ごろから納期2年と言われていたFPGAが急に届いたための不意の仕入れ費用に消えていって、にっちもさっちもどうにもブルドッグだったのですが、6月に神田明神の大祓いに行ってから急に注文がドバっときて九死に一生を得ました。

11月ごろからまた資金難でピンチになってきましたが、Trenzの超高額ボードが売れそうなので何とか生きています。

来年はばっちり行きたいですね。

Raspberry Piの公式のフォーラムでRaspi5のJTAGについての話題を見つけました。

Raspberry Pi 5 JTAG configuration

OpenOCDを使ってJTAGデバッグできるよという内容なのですが、SWDを使っているとのこと。SWDというのはJTAGとは全く別のプロトコルでJTAGデバッグではありません。ARMのデバッグユニット（DAP）にアクセスするためのARMのデバッグ通信規格です。まぁ、世間一般にはJTAGと思われてしまっているところはあります。

で、実際にやってみると、

なんと！つながるではないですか！！！

dap info 0で情報もモリモリ出てきます。

なお、enable_jtag_gpio=1 を設定することでUARTのコネクタがSWDに変わります。

Raspi5はUARTの3pinコネクタが新たに追加されましたが、このコネクタはデフォルトではUARTですが、enable_jtag_gpio=1 を設定するとSWDに変わるというわけです。すると、UARTはどこに行ってしまうんですかね・・

うーん。BCM2712はやっぱりデバッグ機能はあるんだな～というわけです。

じゃあ、なぜJTAGでデバッグができないのかというと、BCM2712のJTAGポートから見えているデバイスがARMじゃないからなんでしょう。BCM2712のJTAGポートで見つかるデバイスのIDCODEは0x2A03217Fですが、下3桁の17FというのはBroadcomのベンダのコードです。

だから、ARMだと思ってDAPを探そうとしてもダメなのでしょう。

Raspi5のJTAGはJ15から取り出せますが、J15の左端(TP48)のピンの役割が不明でした。

もしかすると、ここをLかHに固定すればBCM2712のJTAGがARMのJTAGに切り替わるのかと思って試してみたのですが、それもだめでした。

結論を言うと、今のところ、BCM2712のJTAGにはBroadcomのIDCODEを持ったデバイスが見えていてARMではありません。IRの長さも32bitあり、ADIv5の方法ではJTAGデバッグはできませんでした。

RasPi4でARM JTAGデバッグ機能にアクセスできるようになってきたので、Raspi5でも同様のことができないかどうかを試してみました。

Raspi4と5のJTAGで大きく異なるのは、IRの長さやIDCODEです。

• Raspi4のBCM2711はIRが4bitで、IDCODEは0x4ba00477
• Raspi5のBCM2712はIRが32bitで、IDCODEは0x2a03217f

です。

IRが4bitのARMではIDCODE命令のコードは0xeですが8bitのARMでは0xfeです。では、32bitは・・・ARMのデバッグ仕様書には記載されていません。本当にこれはARMのコアなのかと疑いたくなのですが、IRの長さは紛れもなく32bitあります。

様々な命令を発行しまくって調べてみると、確かに0xffffff0eや0xfffffffeのときにIDCODEを返してくるので、これで正しいのでしょう。

下4bitは0xeでいいのだとしても、上位28bitに何を入れればいいのかわかりません。

32bitの命令空間は広大なのですが、プログラムを組んで28bitを総当たりで調べてみることにしました。

まず、プログラムを組んでRaspi 5 のCPUのJTAG Instructionを順番に与えていって、何bitのDRがつながっているかを総当たりで調べてみます。

何かいろいろ反応しているようで、0xffffff10とか0xffffff18とかバウンダリスキャンレジスタが見えているのではないかと思えるようなビット列が見えています。（492490492というのは010010010010010010010000010010010010ですから、3bitごとに1が立つ、つまりバウンダリスキャンレジスタのコントロールセルが見えているのでしょう。）

いろいろ試してみるのですが、下4bitが6でもEでもIDOCDEが見えています。IRデコーダは3bitしかないのでしょうか。しかし上28bitも見ているような気もします。

INSTを変えてみるとDRの長さがいろいろ変わってくる（何も出力しないパターンもある）のですが、35bitのレジスタがつながることはないのかと思って、下4bitが0x0aである(DPACC)に相当すると思われる0x0000000aから0xfffffffaまでの268,435,456通りの命令コードを送ってみました。

DRに35bitレジスタが実装されていれば、「0x00000000 & "101" & ダミー32bit」 みたいなデータを与えると、「ダミー32bit & レジスタ読み出し値 & ACC」が読み出されるわけです。これを様々なINSTを送った後でDR SCANして試してみるわけです。

結果としては、35bitのレジスタが接続されることはありませんでした。

BCM2712のJTAGには、ARMのデバッグ仕様とは異なる実装がされているか、何かのセキュリティが働いていてJTAGデバッグを禁止している可能性が高いと言えます。

ARMのデバッグのための命令DPACC、APACCを使うと35bitのレジスタが接続され、下3bitがA[3:2]になったりR/#Wのフラグになったりするのですが、データの部分は32bitシフトして考えなければならないので、SVFプレイヤーを使って操作するのが大変面倒でした。

そういえば、SVFにはHDRやTDRといった命令があってチェーンの先頭や末尾に任意のビット列を付け加えられるんだったなと思いだし、HDRコマンドで下3bitを送るようにしたら、ものすごく見通しが良くなりました。

結果もこのように、32bitのデータ部分だけが抜きだされて読むことができます。

いろいろ試してみてわかったことは、

まず、CTRL/STATレジスタに0x50000000を書いてデバッグ機能を有効にすること。そして、SELECTレジスタとAPACCを使って任意のMEM-APにアクセスするわけですが、

Raspi4(BCM2711)のMEM-APのBASE(0xf8)は0x80020003で、IDR(0xfc)は0x24770002であるということです。このあたりの値はCPUの実装によって異なってくると思うので、この値が読み出せたらひとまず成功ということでしょう。

Debug Register Fileを読み書きしたい場合はTAR(0x04)にアドレスを設定してDRW(0x0c)を読み書きするか、Bank1のBD0～BD3にアクセスするかなのですが、BDを使うと4ワード連続でアクセスできるようですが、DRW経由で1ワードずつ読み出せば足りるので、BD0～3は使わなくてもよさそうです。

それから、BASEADDR[0]の内容は0x003E0003だったので、OpenOCDでdebug info 0としたときの内容とも一致しているので、アクセス方法としては正しいのだろう。

こういった値を読み出すためのアクセス方法がわかってくると、ARMのデバッグに書かれているこの複雑な図の意味がわかってきます。

この図はどういうことなのかというと、

• 1段目のDPACCレジスタは、DPACC命令の後でJTAGのDRを読み書きしてアクセスする
• 2段目のMemory Access Port(MEM-AP)は、DPACCのSELECTレジスタとAPACCで指定するA[3:2]でアドレスを指定して読み書きする。0x00~0xfcまでのアドレスしかない。
• 3段目のDebug Register Fileは、MEM-APのTARレジスタでアドレスを指定してDRWレジスタを通じて読み書きする。
  
  

ということです。3段目のレジスタのアドレスは実装依存なので、MEM-APのDebug Access Base(0xf8 BASE)に書かれている値がROM Tableの先頭アドレスになっていて、そのROM Tableの+0x000にProcessor 4KB baseが、+0x004にETM 4kB baseのアドレスが書かれているので、そのアドレスを取得してアクセスするのだろうと思われます。

実際にTARに0x00000000～0x00000010を書き込んで読んでみると、OpenOCDでdap info 0をしたときの
[L01] ROMTABLE[0x0] = 0x00010003
のような結果と同じ値が読み出されました。

ROM TableのETM addressが0x00000000だから、おそらくETMのレジスタを読み出しているのだろうと思われます。

それから、CSWのAddrIncを01にすれば、DRWを読み出すたびにアドレスがインクリメントされることを発見しました。

// CIDRの読み出し
HDR 3 TDI (2); // Write A[3:2] = 01 TAR
SDR 32 TDI (80020ff2) ; // address
HDR 3 TDI (7); // Read
SDR 32 TDI (00000000) ; // read DRW
SDR 32 TDI (00000000) PRINT ; // read DRW
SDR 32 TDI (00000000) PRINT ; // read DRW
SDR 32 TDI (00000000) PRINT ; // read DRW
SDR 32 TDI (00000000) PRINT ; // read DRW

CIDRのように連続したアドレスに配置されたレジスタも読み出す場合に便利かもしれません。

仕様のとおりの値が読み出せたのですが、あまり面白い値ではありませんでした。

プロセッサのコアの数とか、そういう値がどこかにあるといいんですが・・・

Raspberry Pi 5をデバッグする前に、まずは情報の多いRaspberry Pi 4からやってみようと思い、ネットで調べていたところ、hikaliumさんのブログと、西永さんのスライドがみつかったので、ADIv5の仕様書とともに熟読しながらARMのデバッグインタフェース仕様を勉強しております。

まず、Raspi 4はJTAGを有効にするには/boot/config.txtの末尾の[all]セクションに

[all]
enable_jtag_gpio=1

という記述をします。CPUがこの記述が読んでJTAGを有効にするタイミングは起動してから数秒後なので、リセット直後はJTAGは使えません。OSの起動がある程度進んだ段階でJTAGが見えるようになります。

OpenOCDを使ったFTDI接続ではcfgファイルがたくさんあってどれを使ってよいかわからなくなりますが、FTDIデバイスのJTAG接続はTCK=bit0,TDI=bit1,TDO=bit2,TMS=bit3と相場が決まっているので、だいたいどれを使ってもOKです。

JTAGにはTRSTというリセット信号があって、これをどこのビットに配置するかはケーブルのよってさまざまなのですが、どうやらRaspi4はTRSTをトグルしなくても正常に接続できるようです。ただし、TRSTは基板上でプルダウンされているようなので、トグルする必要はないのですがプルアップしておく必要はあります。

結論を言えばFTDIのデバイスでOpenOCDを使ってARMをデバッグする際にはMPSSEのピン配列にしておけば、だいたいどんなcfgファイルでも通るはずです。

hilaliumさんのブログにあるスクリプトを、自分のMPSSEの初期化コードに書き換えて接続してみました。

4つのコアに接続できているのがわかります

接続できたら、TELNETで4444番ポートに接続してdap info 0を行ってみました。

Open On-Chip Debugger
> dap info 0
AP # 0x0
                AP ID register 0x24770002
                Type is MEM-AP APB2 or APB3
MEM-AP BASE 0x80020003
                Valid ROM table present
                Component base address 0x80020000
                Peripheral ID 0x01000bfa97
                Designer is 0x0bf, Broadcom
                Part is 0xa97, Unrecognized
                Component class is 0x1, ROM table
                MEMTYPE system memory not present: dedicated debug bus
        ROMTABLE[0x0] = 0x003e0003
                Component base address 0x80400000
                Peripheral ID 0x04001bb4a4
                Designer is 0x23b, ARM Ltd
                Part is 0x4a4, Cortex-A72 ROM (ROM Table)
                Component class is 0x1, ROM table
                MEMTYPE system memory not present: dedicated debug bus
        [L01] ROMTABLE[0x0] = 0x00010003
                Component base address 0x80410000
                Peripheral ID 0x04001bbd08
                Designer is 0x23b, ARM Ltd
                Part is 0xd08, Cortex-A72 Debug (Debug Unit)
                Component class is 0x9, CoreSight component
                Type is 0x15, Debug Logic, Processor
                Dev Arch is 0x47706a15, ARM Ltd "Processor debug architecture (v8.0-A)" rev.0
        [L01] ROMTABLE[0x4] = 0x00020003
                Component base address 0x80420000
                Peripheral ID 0x04004bb906
                Designer is 0x23b, ARM Ltd
                Part is 0x906, CoreSight CTI (Cross Trigger)
                Component class is 0x9, CoreSight component
                Type is 0x14, Debug Control, Trigger Matrix
        [L01] ROMTABLE[0x8] = 0x00030003
                Component base address 0x80430000
                Peripheral ID 0x04001bb9d8
                Designer is 0x23b, ARM Ltd
                Part is 0x9d8, Cortex-A72 PMU (Performance Monitor Unit)
                Component class is 0x9, CoreSight component
                Type is 0x16, Performance Monitor, Processor
                Dev Arch is 0x47702a16, ARM Ltd "Processor Performance Monitor (PMU) architecture" rev.0
        [L01] ROMTABLE[0xc] = 0x00040002
                Component not present
        [L01] ROMTABLE[0x10] = 0x00110003
                Component base address 0x80510000
                Peripheral ID 0x04001bbd08
                Designer is 0x23b, ARM Ltd
                Part is 0xd08, Cortex-A72 Debug (Debug Unit)
                Component class is 0x9, CoreSight component
                Type is 0x15, Debug Logic, Processor
                Dev Arch is 0x47706a15, ARM Ltd "Processor debug architecture (v8.0-A)" rev.0
        [L01] ROMTABLE[0x14] = 0x00120003
                Component base address 0x80520000
                Peripheral ID 0x04004bb906
                Designer is 0x23b, ARM Ltd
                Part is 0x906, CoreSight CTI (Cross Trigger)
                Component class is 0x9, CoreSight component
                Type is 0x14, Debug Control, Trigger Matrix
        [L01] ROMTABLE[0x18] = 0x00130003
                Component base address 0x80530000
                Peripheral ID 0x04001bb9d8
                Designer is 0x23b, ARM Ltd
                Part is 0x9d8, Cortex-A72 PMU (Performance Monitor Unit)
                Component class is 0x9, CoreSight component
                Type is 0x16, Performance Monitor, Processor
                Dev Arch is 0x47702a16, ARM Ltd "Processor Performance Monitor (PMU) architecture" rev.0
        [L01] ROMTABLE[0x1c] = 0x00140002
                Component not present
        [L01] ROMTABLE[0x20] = 0x00210003
                Component base address 0x80610000
                Peripheral ID 0x04001bbd08
                Designer is 0x23b, ARM Ltd
                Part is 0xd08, Cortex-A72 Debug (Debug Unit)
                Component class is 0x9, CoreSight component
                Type is 0x15, Debug Logic, Processor
                Dev Arch is 0x47706a15, ARM Ltd "Processor debug architecture (v8.0-A)" rev.0
        [L01] ROMTABLE[0x24] = 0x00220003
                Component base address 0x80620000
                Peripheral ID 0x04004bb906
                Designer is 0x23b, ARM Ltd
                Part is 0x906, CoreSight CTI (Cross Trigger)
                Component class is 0x9, CoreSight component
                Type is 0x14, Debug Control, Trigger Matrix
        [L01] ROMTABLE[0x28] = 0x00230003
                Component base address 0x80630000
                Peripheral ID 0x04001bb9d8
                Designer is 0x23b, ARM Ltd
                Part is 0x9d8, Cortex-A72 PMU (Performance Monitor Unit)
                Component class is 0x9, CoreSight component
                Type is 0x16, Performance Monitor, Processor
                Dev Arch is 0x47702a16, ARM Ltd "Processor Performance Monitor (PMU) architecture" rev.0
        [L01] ROMTABLE[0x2c] = 0x00240002
                Component not present
        [L01] ROMTABLE[0x30] = 0x00310003
                Component base address 0x80710000
                Peripheral ID 0x04001bbd08
                Designer is 0x23b, ARM Ltd
                Part is 0xd08, Cortex-A72 Debug (Debug Unit)
                Component class is 0x9, CoreSight component
                Type is 0x15, Debug Logic, Processor
                Dev Arch is 0x47706a15, ARM Ltd "Processor debug architecture (v8.0-A)" rev.0
        [L01] ROMTABLE[0x34] = 0x00320003
                Component base address 0x80720000
                Peripheral ID 0x04004bb906
                Designer is 0x23b, ARM Ltd
                Part is 0x906, CoreSight CTI (Cross Trigger)
                Component class is 0x9, CoreSight component
                Type is 0x14, Debug Control, Trigger Matrix
        [L01] ROMTABLE[0x38] = 0x00330003
                Component base address 0x80730000
                Peripheral ID 0x04001bb9d8
                Designer is 0x23b, ARM Ltd
                Part is 0x9d8, Cortex-A72 PMU (Performance Monitor Unit)
                Component class is 0x9, CoreSight component
                Type is 0x16, Performance Monitor, Processor
                Dev Arch is 0x47702a16, ARM Ltd "Processor Performance Monitor (PMU) architecture" rev.0
        [L01] ROMTABLE[0x3c] = 0x00340002
                Component not present
        [L01] ROMTABLE[0x40] = 0x00000000
        [L01]   End of ROM table
        ROMTABLE[0x4] = 0x00000000
                End of ROM table

重要そうだと思われる内容が出てきます。

MEM-AP BASE が0x80020003で、ROMTABLE[0]が0x003e0003だそうです。

この情報は、JTAGを使ってDPやAPにアクセスした際に正しい値が読み出されているかどうかを比較するために使えそうです。

そして、次にMITOUJTAGを使ってSVFプレイヤーでARM DAPを操作する命令を送り込んでみました。

// READ IDCODE
SIR 4 TDI (E);
SDR 32 TDI (000000007) PRINT ; // read 0x0c2
// SET CSYSPWRUPREQ and CDBGPWRUPREQ
SIR 4 TDI (A) ;  // DPACC
SDR 35 TDI (280000002) ; // write 500000000 => 280000000 CSYSPWRUPREQ and CDBGPWRUPREQ
SDR 35 TDI (000000003) ; // read CTRL/STAT
// READ AP0 CSW
SIR 4 TDI (A) ;  // DPACC
SDR 35 TDI (000000004) ; // write select 0x000000f0 APSEL=0 APBANKSEL=0
SIR 4 TDI (B) ;  // APACC
SDR 35 TDI (000000001)  ; // read 0x00
SDR 35 TDI (000000001) PRINT ; // read 0x00
// READ IDR
SIR 4 TDI (A) ;  // DPACC
SDR 35 TDI (000000784) ; // write select 0x000000f0 APSEL=0 APBANKSEL=F
SIR 4 TDI (B) ;  // APACC
SDR 35 TDI (000000007)  ; // read 0x0c
SDR 35 TDI (000000007) PRINT ; // read 0x0c
// IDR 123B80012 => 24770002

結果は以下のよおりです。

2023/12/27 22:53:49 Line 3 : TDO(captured)='4BA00477'
2023/12/27 22:53:49 Line 15 : TDO(captured)='400000212'
2023/12/27 22:53:49 Line 23 : TDO(captured)='123B80012'

解説すると、最初にJTAGの命令0x0Eを送ってIDCODEを取得します。

次にDPACCを発行し、CTRL/STATレジスタのCSYSPWRUPREQとCDBGPWRUPREQビットを立てます。

その次に、DPACCでSELECTレジスタに0を書き込んで、APSEL=0 APBANKSEL=0とします。これで0x00～0x0cが読み書きできるようになるので、APACCを発行してレジスタ0x00(CSW)を読みます。結果は400000212と表示されているのですが、右に3bitシフトして0x80000042と読むべきです。

それからまたDPACC命令を発行し、SELECTレジスタに0x000000f0を書き込み、APBANK=Fにして0xfc(IDR)を読み出します。

結果は0x123B80012となっていますが、3bit右にシフトすれば24770002となります。これはRaspi4で使われているBCM2411のIDCODEなのでしょう。477という部分がJTAGのIDCODEと一致していますね。

SVFプレイヤーでARMのDebug Interfaceを操作するのは、3bitシフトがしんどいのですが、なんとかIDRまで読めました。

OpenOCDを使ってRaspberry Pi 5のデバッグができるかどうか試してみました。

使用したのはFT232Hを使った自作のMPSSE-JTAGケーブル。GPIOL0とL1にTRSTとSRSTを割り当てています。まずはZadigという極悪ツールでFTDIのドライバをlibusbに置き換えて接続します。

設定のcfgファイルはこんな感じです。

adapter driver ftdi
ftdi vid_pid 0x0403 0x6014
ftdi layout_init 0x0008 0x0ffb
ftdi layout_signal nTRST -data 0x0010 -noe 0x0100
ftdi layout_signal nSRST -data 0x0020 -noe 0x0200
adapter_khz 1000
transport select jtag
reset_config trst
telnet_port 4444
jtag newtap rp5 tap -irlen 32 -expected-id 0x2a03217f 
dap create rp5.dap -chain-position rp5.tap
target create rapi0 cortex_a -dap rp5.dap -coreid 0 -dbgbase 0x80090000け

結果ですが、IDCODEが0x2a03217fであるという検証と、IR CAPTUREが0x001dであるという検証は通りますが、次のDAPの部分でエラーが出てしまいます。

Invalid ACK (0) in DAP response って何でしょうね。adi_v5_jtag.cの中にあるエラーメッセージであるように見えます。

PCI Expressはマザーボードから送られてくるリファレンスクロックに同期して動作するのが標準的な動作なのですが、リファレンスクロックを使わずに、ボード上に乗せた発振器をベースにした非同期動作も規格上は可能です。なお、リファレンスクロックを使う動作のことをslot clockingといいます。

XILINX(AMD)のPCI Expressコアは非同期クロックを使って動作できるようですが、非同期クロックは使えないという記述もあります。

例えばPG054には以下のような記述があります。

実際に、XILINXのXDMAコアで非同期コアが使えるかどうか試してみることにしました。

コアのIPを開くとMISCの中に、Enable Slot Clock Configurationというチェックボックスがあります。デフォルトでこれがチェックされているのでオフにします。

これで論理合成を行うと、コアの中のPCIE_ASYNC_ENがtrueにセットされ、非同期動作が利用できるようになるようです。

しかしながら、現実的にはうまくいきません。

PCI ExperssにはSSC(スペクトラム拡散クロック)とASPM(電源管理の何か)があるためです。

ASPMはPCの総合的な電源管理の仕組みでBIOSより下にあるものなのですが、通信データがない場合に低消費電力状態に落とすという動作があります。これはWindowsの電源管理の中でオフにすることはできます。

スペクトラム拡散によってPCI Expressのデータレートは速くなったり遅くなったりするのですが、XILINXのギガビットトランシーバはリファレンスクロックが一定速度であれば、データレートの変化に追従することができません。そのため、SSCとASPMをオフにしないと使えないというわけです。

しかし、SSCについてはBIOS(UEFI)で無効にできなければどうすることもできません。

実際に実験してみたようすを動画にしました。

一番左端のLEDがPCI Expressのリンクアップを示すもので、一瞬だけリンクアップしてもすぐに切れてしまうことがわかります。

結論としては、XILINXのPCIeコアでは非同期クロックは使えないと思ったほうがよいでしょう。

Raspberry Pi 5のJTAGポートを解明しました。

Raspi5のJTAGポートはGPIOを使うのではなく、裏面にある未実装のJ15とJ19から出ています。

J15はBCM2712のJTAGポートで、ここにつなぐとCPUが見つかります。

見つかったデバイスのJTAG IDCODE は2A03217F でした。

なお、使用したツールはMITOUJTAGです。

BCM2712のJTAGの仕様は全く分からないのですが、IRの長さは32bitであると思われます。

適当な命令を送りこむといい感じでクラッシュしてくれます。

ARMに対応したデバッガをつなげばCPUのプログラムをデバッグできるのかもしれません。

また、RP1のJTAGポートはJ19で、ここにつなぐと、

RP1と思われるデバイスが認識されました。

IRの長さはおそらく8bitです。IDCODEは20001927であるようです。

適当なコマンドを送りこんでいると、無線LANが自分自身しか見えなくなったりしました。

JTAGで滅茶苦茶なデータを送ると何かの影響は与えているようですね。

さて、J15、J19からどうやって配線を取り出したかというと、J15、J19の近くにあるテストポイントから取り出しました。

ピンの割り当ては

• TP48・・・BCM2712のTRST
• TP49・・・BCM2712のTDI
• TP50・・・BCM2712のTDO
• TP51・・・BCM2712のTMS
• TP52・・・BCM2712のTCK
• TP53・・・RP1のTDI
• TP54・・・RP1のTDO
• TP55・・・RP1のTMS
• TP56・・・RP1のTCK

でした。

I/O電圧は3.3Vで良いようです。

また、8ピンのコネクタのピン配置は左から順に ?,TRST,TDI,GND,TDO,TMS,GND,TCKです。一番左のピンが何であるかはわかりません。RTCKかもしれません。

秋月に行ってRaspberry Pi debug probeを購入し、さっそく遊んでみました。

SDカードも挿さない状態でデバッグプローブをつないで電源を入れると、何やらもがいている様子。

USBやSDカードから起動しようとしていますね。

SDカードよりも前にオンボードのROMか何かにブートローダーが書かれている模様です。

Raspberry Pi Imagerツールを使ってSDカードを作成し、

起動してみると、起動時のメッセージがコンソールに現れました。

BL31というところがちょっと長いのですが、無事にloginプロンプトが出てログイン出来ました。

意外とあっさりしています。カーネルが何々ドライバを発見したというようなメッセージは出ません。dmesgでは見れます。

nmcli device wifi で周囲のWiFiを見てみるといろいろ見えていますね。Raspi5はまだ技適がありませんが特例を届け出ているのでご安心ください。

さて、デバッグプローブがあればこのようにログインできるのですが、デバッグプローブがない場合、どうやってホスト名やユーザ名パスワードを設定すればよいのかと疑問に思っていました。

おそらく、Raspberry PiのSDカードを作成するツールで、

サービスのところでOS Customizationという設定項目があるので、ここでホスト名とユーザ名、パスワード、WIFIのSSIDとパスワードを設定し、

次のサービスでSSHを有効化します。

なお、WIFIのSSIDとパスワードは使用しているPCのWIFIの設定が自動的にコピーされます。

Raspberry Pi 5に電源を入れ、WIFIが無事に接続されたことを祈りながら設定したホスト名に対してSSHでログインします。

こういうやり方でもログインはできますが、やはりデバッグプローブは便利です。

さて、私としてはJTAGの機能がどうしても気になってしまいます。config.txtに

enable_jtag_gpio=1

を書けばGPIOのポートからJTAGが使えるようになるという話はあったのですが、どうやらそれはRaspi 4までの話で、Raspi 5ではJTAGが使えるようにはなりません。

こういうピン配置だと思ってJTAGケーブルをつないでみたのですが何も認識されませんし、TDIから入れたデータがTDOから出てこないので、全く反応がないということです。

※このピン配置の画像の元はKSYさんのサイトから引用

ただし、enable_jtag_gpio=1を書くとデバッグコンソールのUARTが使えなくなる(BL31から後の部分が出てこなくなる)ので、enable_jtag_gpio=1の記述はCPUに何らかの変化を及ぼしているようではあります。

また、enable_jtag_gpio=1を書いた時にはraspinfoで見てみるとARM_TCKやARM_TMSという記述が出てくるので、何らかの影響は及ぼしているのだろうなと思われます。ただし、それはRaspi4までの時のようにGPIO24,25,26あたりに出てくるのではなさそうです。

なんとなく、Raspberry Pi 5のJTAGポートは、裏面の実装されていないJ15かTP47,48,49,50,51,52に出ているのではないかと思って探していたら、開発者からの言及がありました。

https://www.raspberrypi.com/news/james-adams-and-eben-upton-on-designing-raspberry-pi-5/

ほんのちょびっとしか書かれていないのですが、要するに、裏面の未実装コネクタJ15とJ19は2712とRP1のJTAGデバッグ用だということです。明日はこのピン配置を解明して、JTAGで接続することを試みていきたいと思います。

Digikeyに注文していたRaspberry Pi 5が届きました。

箱にはFCCとCEのマークがあります。

USB Type-Cケーブルをつないで電源を入れるとLEDが赤から緑に変わります。この電源USBをパソコンから取ったとしても、パソコンには何かのデバイスとして認識されることはなく、ただの電源コネクタとして使われているようです。

Linuxにシリアル通信でコンソールでログインがしたかったのですが、Raspberry pi debug probeが必要であることに気が付いたので今日は動作のテストはできませんでした。

その代わり、X線CTスキャンを使って観察してみました。

スケスケーで見えていますね。

基板は管電圧100kVで見るのがよさそうです。メタルなパッケージのICの中まで透けています。

右下の部分は無線モジュールですがアルミ缶の中まで見えています。BGAのピッチは0.4mmでしょうか。細かいですね。

3Dに再構築してもあまり面白いことはありませんでした。

一番気になるのはこのアンテナの部分です。

上が反射器で下のGND間の2つのコンデンサの部分で八木アンテナみたいな構造なのかと思ったのですが、もっと洗練された凄いしくみのようです。

裏面にはAbraconによってライセンスされた技術であることが書かれています。

このアンテナはどうやら2GHz~6GHzくらいまで使えるアンテナで、詳しい記事は下記のページにあります。

https://antennatestlab.com/antenna-examples/raspberry-pi-model-3b-antenna-evaluation-gain-pattern

どういう原理かわかりませんが、解析してみたいですね。

技適のない機器の使うための特例申請では、海外の規格の準拠ができていれば比較的楽に手続きができるのですが、そうでない機器の場合は無線従事者が技術基準に適合しているかどうかを確認して工事設計書を書くといった作業が必要になります。

工事設計書というのは、無線局の開設を申請するときに書くこういう書類なのですが、かなり大変です。

で、FCCやCEがない装置を使いたい場合に、無線従事者が書類を書くということをマネタイズできるかどうか、アンケートしてみました。

結果は、

10000円未満なら利用したいという人が４割くらいでした。無料で利用したいという人や利用したくないという人が半分を占めていて、10000円以上でも利用するという人は10%くらいでした。

実際にこういう書類を書くとなると半日はかかるので5~10万円はほしいところです。ビジネスで無線機器を利用したい人の中には5万円でもいいという人はいるかもしれませんが、申請のときに無線従事者の資格と氏名と登録番号を書かなければならないので、無線従事者の番号が顧客に知られてしまいます。

無線関係の申請はいずれも資格と氏名と番号でできてしまうので、一度知られてしまうと、その番号を使って他人が自由に何でも届け出できてしまうというセキュリティー上の問題点があります。

他人のために書類を作成するということは司法書士の資格が必要ではないかという懸念もあります。

よって、マネタイズするのはあきらめたほうがいいでしょう。

DigikeyでRaspberry Pi 5が買えるようになったわけですが、技適が通っていないため、案の定、技適警察が湧くという事態になりました。

さて、技適が通っていない装置でも180日を限度として実験に使える「技適未取得機器を用いた実験等の特例制度」という制度があります。この制度を使って届け出をすれば使用することができるようになります。

https://www.tele.soumu.go.jp/j/sys/others/exp-sp/index.htm

やり方をざっくり説明すると、電子証明書を取得して総務省のWebサイトで申請するという簡単なものですが、FCCやCEなど外国の認証を得ている装置か否かで変わってきます。認証を得ていない場合は無線従事者による確認作業が必要になってきます。

Raspberry Pi 5はFCCを取っているという話もありますが、実物が届いてみないことにはわからないので、ここでは「無線従事者による確認」の方法で届け出を行ってみました。

■ユーザ登録から電子証明書の取得まで

まず、総務省のWebサイトから新規ユーザ登録を行います。

メールアドレスや会社情報、氏名などを入力しってください。本当に本人かどうかを証明するための本人確認までサクサク進むと思います。個人の場合はマイナンバーカードを用いた電子署名がよさそうですが、ここでは法人で行きます。

法人の場合は商業登記電子証明書を用いた電子証明書を使うのが最も簡単です。申請ページから法務省の「商業登記電子認証ソフト」のページにリンクが張られているので、そこへ行ってダウンロードしてきます。

商業登記電子認証ソフトを起動します。

西暦2000年ごろを彷彿とさせる素敵なUI/UXのソフトですね。

まず、鍵ペアファイルおよび証明書発行申請ファイルの作成をクリックすると、情報入力画面になるので、記入します。

「※必須」と書かれていない部分は空欄で構いませんし、パスワードはこれっきりしか使わないので深く考える必要はありません。

作成実行を行うと、SHINSEIというファイルと、鍵ペアファイルと、申請書のpdfが出来上がります。SHINSEIファイルはUSBメモリに書き込むかCD-ROMに焼きます。

申請書のpdfはこんな感じなので、

足りない所を手書きで書き、SHINSEIファイルの入ったUSBメモリを持って、登記所へ行きます。

登記所では1300円分の印紙(証明書の有効期限が3カ月分の場合)を購入し、申請書に貼り付けてUSBメモリと一緒に窓口に出します。

下の写真のような紙が戻ってくるので、

ここに記載されたシリアル番号を、先ほどのソフトに入力します。

電子証明書が生成されるので、総務省のWebサイトから本人確認を進めます。

電子証明書が求められるので、先ほどのソフトで生成した.p12ファイルを送信します。

これでユーザ登録と認証は完了です。

法務局へ行ってシリアル番号の書かれた紙をもらってくるというのが、本人認証の肝になるようです。

■開設の届出

総務省の「技適未取得機器を用いた実験等の特例制度」のページへログインして開設の届出をクリックします。

ここで、<<機器名>>を用いた<<具体的な機能・アプリ等>>の動作試験をクリックし、

• 科学若しくは技術の発達のための実験
• 電波の利用の効率性に関する試験
• 電波の利用の需要に関する調査

に適合するような具体的な実験内容を記入します。審査されて許可・承認がされるようなものではないのですが、科学若しくは技術の発達に資するような計画を書いてください。

次に、どのような無線の規格を使うかをチェックボックスで選択するのですが、

Raspberry Pi 5は、IEEE 802.11 b/g/n/ac 2.4/5GHz とBluetooth 5.0, Bluetooth Low Energy が使えるようですが、乗っているCypress CYW43455というチップはデータシートを見ると、もっといろいろなプロトコルをサポートしているようです。

ここでは実験が目的で、設定次第ではIEEE 802.11aとか出てしまうかもしれないので、CYW43455の出せる限りのプロトコルをチェックしておきます。

シリアル番号は自分で振った値でもよいはずです。機器の製造者、機器の形式、設置場所の住所を記入します。使用開始日は届け出を行ってからすぐに使えるので当日でも構いません。無線LANを使うなら屋内にしておいたほうが無難でしょう。

もし、FCCやCEなど外国の法令に適合していて技術基準に適合するような旨の記載があれば、左側をクリックして外国の法令を記入し、完了です。

もし、外国の法令に適合する記載がまだなければ、右側をクリックします。

ここでは、無線従事者免許証を持つものが技術基準に適合するかどうかを判断することになります。利用できる資格は上のもので、1アマは使えますが2～4アマは使えません。（1アマ強い）

具体的には、使用しているチップの出せる電波の周波数や形式、スプリアス、強度などを細かくしらべていって、法令や規格の範囲内かどうかをデータシート上で確認していきます。実際に規格内の電波が出るのかどうかを測定するのが実験の目的でもあります。

そして、工事設計書というのを書きます。無線局の工事設計書のひな形は

https://www.tele.soumu.go.jp/j/download/proc/

からダウンロードできます。ひな形は実験局のものを使えばよいと思います。

どの周波数で何ワット出て、アンテナの形状からEIRPは何ワットで・・みたいなことを書いていきます。

無線LANは規格によってOFDMだったりPSKだったりQAMだったりDSSSだったりと変調方式が変わってくるし、このICは規格ごとに出力パワーが少しずつ変わってくるので、最大パワーを出したと仮定して埋めていきます。

この工事設計書を書くのが一番大変かもしれません。

それから、「確認した、電波法の技術基準の別（該当する無線設備規則の条項）」というのを書くのですが、なんのこっちゃと思うかもしれません。その欄の下に「無線設備規則の条項の番号を記入してください。（例：第49条の20第3号）と書かれているので」これがヒントとなります。第49条の20第3号というのがまさにWLAN 5Gの上のほうのことですから、その周辺を探せばWLAN 2.4Gと5GHzの下も見つかります。

これで届け出ボタンが押せるようになるので、押すと、

というメールが送られてきて、技適未取得の機器を晴れて使えるようになります。なお、利用できるのは最長でも180日で、終了後に廃棄するか無線機能を使えなくしなければなりません。終了時には必ず廃止届を出す必要があります。

まとめると、

■本人認証で必要なもの

　・法人・・・本人認証で登記所に行く必要がある。USBメモリと1300円

　・個人・・・マイナンバーカードとスマホでいけるはず（未確認）

■外国の認証に通っている一般的な規格品？

　・FCCやCEなど外国の法令が通っていて、一般的な無線LANなどの規格品であれば左側コースでオンラインで簡単申請

■外国の認証に通っていないか、わからない

　・無線従事者の確認、工事設計書の作成、準拠する無線設備規則の適示が必要

最後に。この方法が使えるのは「技適未取得の機器」に限ります。もしRaspberry Pi 5が正式に技適を取ってしまったら、この特例の届け出はできなくなります。誰かが技適を取ったとしても、技適取得前に届出しておけば最長180日まで使えますが、技適前に製造された機器なので期間終了後(廃止届出後)は無許可の状態になるので使えなくなります。

なんと、DigikeyでRaspi5の4GBモデルが買えるようになっています。

https://www.digikey.jp/ja/products/detail/raspberry-pi/SC1111/21658261

製品型番はSC1111。

1万円弱で在庫は2700個程度です。あまり数が減らないのは一人１個までだからかな。

RS232Cで制御する機器(1軸ステージ)をZYNQのLinuxからコントロールしたいので、ZYNQ LinuxからUSBシリアル変換器を扱う方法を調べました。

やりたいことは、Cosmo-Z MiniにUSBシリアルケーブルをつないで1軸ステージを動かすことです。

まず、LinuxはUSBに新たなハードウェアがつながるとlsusbコマンドで何がつながっているかが表示されます。

root@cszmini:~# lsusb
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

しかし、ここで表示されたからといって使えるわけではありません。そのハードウェアが使えるかどうかはカーネルのコンパイル時にあらかじめ指定してあるかどうかで決まります。カーネルのコンパイル時に指定していなければ絶対に使えません。

なお、USBシリアル変換ケーブルにはCP210xやPL2303系、FTDI系などいろいろありますが現在のLinuxではすべてサポートされています。しかし、デフォルトでは有効になっていません。

これらを使うためカーネルのコンパイルで有効にするやり方ですが、まず、

cat /proc/config.gz | gunzip -c > .config

とやって、現在のコンフィグ情報をファイルに落とします。

これをLinuxをコンパイルするPCのLinux構築フォルダにコピーして、

make ARCH=arm menuconfig

でメニューコンフィグを出して、Device Driverの、

USBの

USB Serial Converter Supportを出します。

まず、ここが[ ]なので、[*]にします。

中に入ったら上から3つくらいを有効[*]にします。（する必要があるかどうかはわからないけど一応）

CP2104やFTDIなどのメジャーどころと、

そしてPL2303も有効にします。

こうして

make ARCH=arm UIMAGE_LOADADDR=0x8000 uImage

でコンパイルして新しくできたuImageでLinuxを起動すればサクッと認識されます。

認識されるとdmesgのメッセージにも残りますが、/dev/ttyUSB0としてドライバが作られます。

このドライバに対して

echo "Hello" > /dev/ttyUSB0

とすれば文字列が出力されます。

逆に、

cat /dev/ttyUSB0 

で受信文字列が表示されるのですが止まらなくなってしまうので、もう一工夫が必要なようです。

echo "Hello" > /dev/ttyUSB0

で出力された信号をオシロで見てみると、デフォルトでは9600bpsになっていました。

速度を変更するにはsttyコマンドを使って、

stty -F /dev/ttyUSB0 speed 115200

とすればよいようです。

変更すると115200bpsになりました。

C言語で扱うサンプルプログラムを書いてみました。

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <termios.h>
#include <unistd.h>
int main()
{
    int fd = open("/dev/ttyUSB0",O_RDWR);
    if(fd < 0) return -1;
    struct termios term;
    cgetattr(fd, &term); // 現在の設定を得る
    cfsetspeed(&term, B115200); // 115200baudに設定
    cfmakeraw(&term); // RAWモード
    tcsetattr( fd, TCSANOW, &term ); // 設定は即時反映させること
    ioctl(fd, TCSETS, &term); // 設定を反映
    write(fd, "Hello", 5);
    usleep(100000); // 送受信待ち
    char buf[256];
    int len = read(fd, buf, sizeof(buf)); // 受信
    buf[len] = '\0';
    printf("Recv: '%s' %dBytes\n",buf,len);
    close(fd);
}

ポイントとしては、

① ボーレートを設定するB115200というのはマクロ定義された値

② RAWモードにしないと、受信したときに送信を延々と繰り返してしまうので、必須

③ 受信のreadはブロックしない。長めの長さを与えておいてもOK。(受信文字列の組み立ては自分でやるということ)

です。

XILINXのSDKの古いバージョンが必要になったのでインストールしようとしたのですが、古くてWebインストールがサポートされなくなり、フルインストールのファイルを探してきて自分でインストールしなければならなくなったようです。

しかし、XILINXの古いファイルのダウンロード(SDK/PetaLinuxアーカイブ)にはWebインストーラしかありません。

いろいろ試行錯誤の末、

https://account.amd.com/en/forms/downloads/xef-vivado.html?filename=

の後ろに欲しいファイルの名前を直接書けばいいのではないかと思い、やってみました。

https://account.amd.com/en/forms/downloads/xef-vivado.html?filename=Xilinx_Vivado_SDK_2018.3_1207_2324.tar.gz

そうしたら、大正解。

無事にダウンロードでき、解凍してインストールできました。

フルインストールなのでVivadoやVivado HLSも一緒に入ってしまいます。Vivadoを抜いてXSDKだけインストールすることはできないようです。

容量が大きくて困るのですが、仕方ありません。