SLVS
# slvs
Scalable Lowvoltage signaling
コモンモード電圧 0.8v
差動電圧 400mv, プラスマイナス200mv
コモンモード電流 6ma ？
因みに、LVDSのコモンモード電流3.5ma
# 表
| 項目 | LVDS | SLVS |
| --- | --- | --- |
| 差動振幅 | 700mv | 400mv |
# 参考
https://ednjapan.com/edn/spv/1109/20/news120_2.html
# メモ
みたままから、マークダウンに変更。
Xavierはじめ
背景
何故かXavier があったので、使ってみようかと。
用途
pcie epになるらしく情報収集。
xavier上のgpuはデバイスとして見えず、メモリデバイスとして見える。このメモリデバイスで何をする？
単純なGPUプールとならず、専用構成。
host - driver - pcirp - pciep - mem - driver
用途としては、
- mpi で計算
- gst plugin でパイプ処理
ぐらいかな。
gst shmsrc/sink
https://stackoverflow.com/questions/40260580/gstreamer-shmsrc-and-shmsink-with-h264-data
shmドライバを作れば使える？
メモリデバイスドライバrp/ep
メモリデバイス機能があるらしく、まずはrp/ep用ドライバ
- ch dev?
- blk dev?
- eth nvdia pio mode version
通信機能
- tx/rx buf
- buf management
- device management
- msi / intr : dev to host
- signal to dev
- ordering
とりあえず、基本機能は、
- queue
- lock, semaphore
- shared mem
- process management
嫌らしいのは、両側で作る必要がある所。host 制御ベースで手を抜きたい。
ホストは、queueにデータを積んで、結果を待つ。
デバイスは、queueからデータを取りだし、結果をホストに送る。
デバイスへの実行コードを送る為には、ファイルシステムを使いたいので、LAN経由で送る？
LANとpcieの機能分割を上手く設計する。
- LAN: 制御系
- pcie: データ系
機能ドライバ
pcie直結メリットはレイテンシと帯域。
- send/receive?
- ring buffer for video stream gst - mem - gst
インストール
やりたくたくないが、これが無いと始まらない。
画面はdp to dvi、kbdはusbaコネクタ、添付のusbc to a変換ケーブルで母艦とフロントusbc、lanを繋いで最後にac cable。マイクロsdカードを早目に確保しないとemmc 32gbでは直ぐに容量不足になりそう。
インストールはざっくり4ステップ
細かい手順
1.ホストPCとJetson AGX Xavierの電源の反対側にあるUSB-Cと接続されていることを確認。 2.電源アダプタがコンセントとJetson AGX Xavierと接続できていることを確認。 3.電源ボタン（3つ並んでいるボタンの一番左）を押して電源をONにする。 4.以下でJetson AGX Xavierをforce recovery mode（強制回復モード）にする。 •Force recovery ボタン（3つ並んでいるボタンの真ん中）を押下し続ける。 •リセットボタン（3つ並んでいるボタンの右側）を単押し（押して離す）をする。 •2秒後にForce recoveryボタンを離す。 5.最後にエンターキーを押すと書き込みが開始する。
次はpcieのep化
できると言うコメント。
下記のデータシートはログインが必要。
http://developer.nvidia.com/embedded/dlc/jetson-xavier-data-sheet
ep configuration
vidyas Which controller would you like to use in endpoint mode? FWIW, there are three controllers C0, C4 and C5 which can operate in end point mode (one at a time) and corresponding device-tree nodes are already available. Please enable pcie_ep@14180000 for C0 pcie_ep@14160000 for C4 pcie_ep@141a0000 for C5 and disable their corresponding root port nodes There is a platform driver (pcie-tegra-dw-ep.c) available to configure controller for endpoint mode of operation and also a client driver (tegra-pcie-ep-mem.c) to exercise the DMA functionality of end point controller. You can write your own client driver to satisfy your requirements and modify platform driver also accordingly.
Does it work like this: 1. I take tegra-pcie-ep-mem.c, compile it in X86 host. 2. get pcie-tegra-dw-ep.c to work on Xavier 3. hook it up via some kinds of pcie cable. 4. then I will be able to read/write xavier from X86 side? Yes. It would work. Please make sure that the cable you are using would route Tx from one end to Rx of another end. Also, since Xavier is self powered, there is no need to supply power from x86 to Xavier(EP) If Xavier can work in endpoint mode, does that mean I can wire PC PCIE directly to Xavier PCIE ? Maybe through own carrier board design or through Molex cable/PCIE card? Yes BTW, which controller of three is used as RC to link to GPU? If I configure this controller to EP mode, what will happen? GPU can't work properly? As far as I know, GPU is not supplied by default. So, whichever controller you have planning to connect GPU to cannot be operated in endpoint mode. Dual mode controller can work either in root port mode or endpoint mode but only one at a time (mutually exclusive) Once a controller is configured to operate in endpoint mode, you can reserve memory to be exposed through EP's BAR to host and thereby letting host (in this case x86) be able to directly write to Xavier's system memory. (OR) Xavier-EP's internal DMA engine can be used to push/pull data to/from x86's system memory (this is like how a typical PCIe endpoint works). You can go through Xavier TRM to learn more about it and also device tree documentation on how EP can be configured through device-tree entries.
next page
kernel/nvidia$ find -iname "pcie-tegra-dw-ep.c" ./drivers/pci/ep/pcie-tegra-dw-ep.c #27 Posted 05/15/2019 04:36 AM WayneWWW No idea what is your problem now. Please refer to https://devtalk.nvidia.com/default/topic/1050616/jetson-agx-xavier/the-bandwidth-of-of-virtual-ethernet-over-pcie-between-two-xaviers-is-low/1 #28 Posted 05/17/2019 02:45 AM
virtual ethernet on pcie
現状のvnetはpio modeで実装されており、100mbps程度の性能。
pcie dma test
パッチを当てて試験する手順書。
素晴らしい！
ep 側lspci
0005:01:00.0 RAM memory: NVIDIA Corporation Device 1ad5 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Dis+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- I- Latency: 0 Interrupt: pin A routed to IRQ 595 Region 2: Memory at 1c00000000 (64-bit, prefetchable) [size=128K] Region 4: Memory at <unassigned> (64-bit, non-prefetchable) Capabilities: <access denied> Kernel driver in use: tegra_ep_mem
pcie connection
https://devtalk.nvidia.com/default/topic/1042223/jetson-agx-xavier/xavier-pcie-endpoint-mode/
概要
USB まとめ
USB Version
- USB 1.0 12mbps
- USB 1.1 12mbps
- USB 2.0 480mbps
- USB 3.0 5gbps, 新端子
- USB 3.1 10gbps Type-C spec added.
- USB 3.2 10gbps x2, x2はType-C必須。
- USB4 20gbps x2
上記は最大転送性能であり、個々の機器の規格と転送速度は一致しない。また、3.1からはGen.表記が使われる。
| Name | Speed |
|---|---|
| USB 3.1 Gen.1 | 5gbps |
| USB 3.1 Gen.2 | 10gbps |
| USB 3.2 Gen.1 | 5gbps |
| USB 3.2 Gen.1x2 | 10gbps |
| USB 3.2 Gen.2 | 10gbps |
| USB 3.2 Gen.2x2 | 20gbps |
Speed
USB のスピード規格の名称
- Low speed
- Full speed 12mbps
- High speed 480mbps
- SuperSpeed 5gbps
- SuperSpeedPlus 10gbps
USB logo
端子タイプ
端子ピン数
USB 2.0まで
ピン数
- 4pin D+, D-, GV
USB-OTG
OTGはOn the goの略称。デバイス側をホストとして使用可能にする為、ID用のピンを一本追加。
- 5pin OTGID, D+,D-,GV(5V)
USB 3
5pin 追加。5Gbpsの転送のため、差動単方向伝送用のピンを追加。USB2迄とは別のピンで転送する。
- USB 2迄のピン。
- 追加ピン T+,T-,R+,R-,G の5本。
USB Type-C
24pin、大幅な変更。
- 8pin gv
- 8pin (T+R)x差動x2レーン)
- 2pin usb2 data
- 2pin usb2反転時の空き
- 2pin CC1,CC2/Vconn 接続向き検出, active cable用電源
- 2pin SBU1,2 サイドバンド
Type-C alt mode
USB type-c には、ケーブル信号を別の用途に使うalt modeがある。
主要なalt mode。
| Name | Signal |
|---|---|
| DP over USB-C | Display Port 1.2 |
| Thunderbolt3 | DP, PCIe |
| HDMI Alt mode | HDMI 1.4 |
| Virtuallink | DP1.4 |
Thunderbolt3対応PCは、DPoverUSB-C対応のディスプレイに接続できる事が多い。
なお、発表時期はそれぞれ
- 2014 DP alt mode
- 2014 MHL?
- 2016 HDMI alt mode
- ??? virtuallink
- ??? thunderbolt3
DP alt mode
DP alt modeでは、シングルモードのみ。HDMIに対応するデュアルモードはalt modeでは未対応。
USB 3.1 Spec
- (1)Universal Serial Bus 3.1 Specification
- (2)Universal Serial Bus Power Delivery Specification
- (3)Universal Serial Bus Type-C Cable and Connector Specification
(1) を満たせば3.1と言える。
USB PD
給電仕様
- USB 2.0 5V/0.5A 2.5W
- USB 3.0 5V/0.9A 4.5W
USB PD
- 5V/2A(10W)
- 12V/1.5A(18W)
- 12V/3A(36W)
- 30V/3A(60W)
- 20V/5A(100W)
参考
Type-C alt mode
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00495/110600008/?P=5
dell type-c
dell type-c
display
https://www.eizo.co.jp/eizolibrary/other/itmedia_usb-type-c/
usb logo
https://en.m.wikipedia.org/wiki/List_of_devices_with_video_output_over_USB-C
DL4US
USB-Type-C変換
はじめに
USB-Type C変換アダプタは、TypeC plug品を買いましょう。Type C receptacle品は規格外、危険な接続ができるため、禁止されている。
USB 端子のTypeとケーブル
端子
ケーブル
- A to B/miniB/microB ケーブル
- C to C ケーブル
USB 端子の背景
USBでは最初にホスト用のType-Aとデバイス用のType-Bが規格化された。ホストとホストや、デバイスとデバイスの様な誤接続を防ぐために考えられたもの。USB 2.0まではUSBは差動信号2pinと電源、Gndの4pinしかなく、差動信号をホストとデバイスが交互に使用する仕様であり、ホストとデバイスが確定していないと正しく通信できない。
一方、USB 3.1時に規格化されたType-Cはデバイス、ホストの両方に使える。これはType Cでコンフィグ・ピンを追加し、接続を正しく認識できる為、端子を分ける必要が無いからである。
よって、USB接続で許可されているものと、そうでないものは以下の通り。
- A-B ok
- C- A/B/C はok
- A - A ng
- B - B ng
AやB同士の接続は、従来のA to Bケーブル、あるいは標準のC to Cケーブルでは不可能である。しかし、不正なC変換アダプタにより可能になる。
例えば、CケーブルをA装置に接続する変換アダプタがあれば、下記の様にA同士を接続可能になる。
A - C変換 - Cケーブル - C変換 - A
これは両端がAである。電源アダプタはAであり、極めて危険である。
上記のC変換は、A側プラグ、C側レセプタクルである。
USB規格団体のUSB-IFは、Cレセプタクルの変換アダプタを規格化しない事で、この誤接続ができない様にしたものと思われる。Cプラグを持つのはCケーブルだけである。このCプラグをAやBのプラグに変換できなければ、必ずC装置に接続する事になる。そして、C装置なら、どの装置に繋いでも安全である。
一方、従来のABケーブルをC装置に繋いでも安全であり、ABケーブルの両端のABプラグをCプラグに変換する事は問題ない。つまり、ABレセプタクルのアダプタは問題無いが、Cレセプタクルのアダプタを使ってはいけない。
なお、CレセプタクルをCプラグに変換する延長ケーブルは、信号品質を別にすれば、CtoCであり問題ない。
規格品USB TypeC変換
- TypeC plug - microB receptacle
- TypeC plug - Std.A receptacle
規格外
- TypeC receptacle - Std.A plug
基準
USB Type-Cレセプタクルを搭載した変換アダプタは規格違反。
出展: USB Type-C Cable and Connector Specification Revision 1.2, Section 2.2
何故規格外なのか
TypeC receptacleの変換アダプタがあれば、下記の接続で、A to A のケーブルが作成可能。USBはホストがA、デバイスがBとなる規格であり、ホストとホストが接続されるAtoAという接続は規格外。また、ホスト側のAは電源供給ができる為、AtoA接続の場合、両端から電源供給され、危険である。
AアダプタC - Cケーブル - CアダプタA
TypeCはホスト？デバイス？
TypeCはホストとデバイスの両方が使える規格。従って、TypeC同士接続の場合は、どちらがホストかデバイスかを決める手順が定義されている？
一方、A/Bは決め打ちでホスト/デバイスが決まるため、AtoA接続の場合は、両端がホストとなり、規格違反。
また、C to A, C to B の場合、C側装置が相手を認識する事により、誤接続を検出でき、安全である。
例えば
https://www.sanwa.co.jp/product/cable/usb_type-c/index.html
後半に、C receptacle - A plug の変換アダプタが載っており、危ない。
そもそも
そもそもUSBはホストとデバイスのコネクタを分ける事でご接続を防止してきた。そこに、ホストとデバイス共通のTypeCが規格化された事により、誤接続を許容する規格となった。TypeCと共に、誤接続を検知する機能が盛り込まれたが、旧規格のA/B装置はその様な機能を持たない。TypeCの変換アダプタを経由する事により、旧規格装置のホスト同士やデバイス同士が接続される危険があり、変換アダプタを制限する事で、この危険を回避しようとしているのだろう。
規格外の変換アダプタにより、故障や発火事故が起こらない様、規格に則った変換アダプタを使用しましょう。
何故TypeCプラグのみが規格品
TypeCプラグへの変換アダプタがあれば、A/BデバイスをC装置に接続する事ができる。RがReceptacle, PがPlugを示す。
AR装置 - (AP—BP) - (アダプタBRtoCP) — CR装置/デバイス
B装置 - (BP — AP) - (アダプタAR toCP) — C装置/ホスト
ただし、このアダプタではCプラグをA/Bプラグに変換する事ができないため、必ずC装置が存在する必要がある。
一方、CのReceptacle からA/Bへの変換アダプタを許容すると、C装置がない場合、AR装置 - (AP- CR) - ケーブル- (CR-AP) - AR装置という、C装置が存在せずに、A同士が繋がる。
この接続が危険な事は記載済み。
結論
USB type-C 変換アダプタは、typeC plug の物を買いましょう。
参考
python process 関係
python プロセス基本モジュール
- os.kill( pid, signal.SIGKILL )
- os.killpg( os.getpgid(pid), signal.SIGKILL )
- os.getpgid( pid )
- os.fork()
- os.waitpid( pid, 0 )
os.system( 'echo Hello' )
subprocess.Popen()
p = subprocess.Popen( 'pwd', stdin=subprocess.PIPE, stdout=subprocess.PIPE, close_fds=True, shell=True)
- 戻り値 の使い方
p.stdout, p.stdin等。
利用例
import os from subprocess import Popen, PIPE from signal import SIGKILL def killproc(name): proc = Popen( f"ps aux | grep {name}", stdin=PIPE, stdout=PIPE, close_fds=True, shell=True) pout = proc.stdout greppid = proc.pid for line in pout.readlines(): pid = int( line.strip().split(' ')[1] ) if ( pid == greppid ): continue pgid = os.getpgid(pid) try: os.killpg( pgid, SIGKILL ) except: pass killproc('hello')
