2401930_ja-JP

Yes

LX2162A USXGMIIリンクが完了しない

みなさん、こんにちは。

私はSolidrun社製のLX2162A SoMを所有しています。Clearfogの開発キットを使用していますが、近いうちにカスタムキャリアに移行する予定です。

Solidrunは基本的なRCW/DCP/DPLを提供しており、その機能は確認済みです。私の場合、DPC3のDPCはSFPケージで動作し、SFP DACケーブルと様々なSFPモジュールでXFIリンクが接続されています。

RCW "rcw_2000_650_2900_3_11_0_auto" は SerDes1=3、SerDes2=11 に設定され、私は QorIQ カーネル (lf-6.6.52-2.2.0) と mc-utils (10.39.0) を使用していますが、両方に Solidrun のパッチが適用されています。U-Bootやその他のものもパッチが適用されています。すべてのパッチはここから取得されます： https://github.com/SolidRun/lx2160a_build/tree/develop-ls-6.6.52-2.2.0

私はMaxLinear GPY245-EKV-1（および-2）開発キットを持っており、PHYをデバイスに接続するためにDACケーブル経由のUSXGMIIを必要としています。どうやらこれはごく普通のことらしい。最終的にはこのPHYチップはSerDes2=7のレーン6とレーン7に統合される予定ですが、テストのためにはClearfogのSFPケージを使用する必要があります。

Clearfog SFP (mac3) <-> DAC CABLE <-> GPY245-EVK-2 SFP

私は、dpmac3がDPC経由でこのUSXGMIIリンクを使用するように設定しようとしているだけです。

mac@3 {
    link_type = "MAC_LINK_TYPE_PHY";
    enet_if = "USXGMII";
};

（MAC_LINK_TYPE_BACKPLANEも試してみました）

「restool dpmac info dpmac.3」で確認済み「DPMAC イーサネットインターフェース:DPMAC_ETH_IF_USXGMII」と表示されます。

LinuxではMaxLinearドライバーを追加し、いくつかの点を修正しました:

gpy_update_interface() の修正 (LKML、Daniel Golle)。これはUSXGMIIインターフェースで-EINVALを戻す際にクラッシュphy_state_machine。
pcs-lynx.c の lynx_pcs_config_usxgmii() 関数にパッチを適用しました。mdiobus_c45_modify() を介して MII_BMCR (BMCR_ANENABLE | BMCR_ANRESTART) も書き込む必要があります。この関数はこれまで MII_ADVERTISE しか書き込んでおらず、レプリケータブロック自体で AN を有効にしたことがなかったためです。このギャップは、このフォーラムの別の投稿（「LS1028A 10g-qxgmii phy 起動」）と一致しており、同じ症状（MMD31.0/Replicator）が報告されています。コントロールレジスタが0に固定され、ビット12を手動で設定した後、ANが作動しました。

こちらがDPMAC3 Linuxデバイスツリーのエントリーです:

&dpmac3 {
    managed = "in-band-status";
    phy-mode = "usxgmii";
    phy-handle = <&gpy245_p0>;
    phys = <&serdes_1 7>;
    status = "okay";
};

ここで、`gpy245_0`はMDIOノードです。PHYへのMDIOトラフィックは正常に動作しています。

lynx_pcsドライバーにリードバックを表示するプリントアウトを追加しました:

mdio_bus 0x0000000008c0f000:00: USXGMII:
wrote ADV=0xd601 BMCR=0x1a00
readback ADV=0x6b00 BMCR=0x0800 BMSR=0x0000  LPA=0x0000

質問：

このPCSインスタンスのMDIO_MMD_VEND2レジスタへの書き込みが持続しないような場合、LX2162AファミリSoCのUSXGMIIが設定を受け入れる前に、SerDes/PCSブロックの有効化、プロトコル固有の初期化など、追加のステップが必要になるのでしょうか?プロトコル3はdpmac3上のUSXGMII向けに完全に検証済みですか、それとも主にXFI向けに設計・テストされていますか？

その他の質問：

GPY245とUSXGMIIについて、私はよく理解していないのかもしれません。これをQXGMIIと呼ぶ人もいますが、LX2162Aが本当に動作するのかはわかりません。

Solidrunに問い合わせる必要があるかもしれないが、彼らのパッチはどれもLX2162Aの性能を制限するものではないようだ。

ありがとう！

Re: LX2162A USXGMII link never completes

LX2162A側は、あなたが使っているパス上でUSXGMIIをサポートするドキュメントがありますが、あなたが示している症状はLinux pcs-lynxの書き込みが欠けているというより、選択したPCSインスタンスがまだUSXGMIIアプリケーションモードに入っていないか、MCファームウェアが間違った10G PCSセレクタをプログラムしているように見えます。

SerDes1プロトコル3の場合、LX2162Aリファレンスマニュアルでは4つのSerDes1レーンすべてがUSXGMII / XFIとして記載されており、最初のレーンにはUSXGMII / XFI.3と記載されています。これはClearfog SFPパス上でテストしているDPMAC3のユースケースに対応しています。将来のカスタムキャリアのターゲットとして、SerDes2プロトコル7はレーン6とレーン7をUSXGMII / XFI.13およびUSXGMII / XFI.14として記録しています。

重要な注意点は、USXGMII / XFI のエントリが自動的に「USXGMII」になるわけではないということです。リファレンス・マニュアルには、USXGMIIとXFIのレーン内のデフォルトはXFIと書かれています。モードは、プロトコル構成レジスタCであるPCCCによって選択され、そのSXGMII*_XFIビットによって0b = USXGMII、1b = XFI/SFIが選択されます。まず最初に確認すべきは、LinuxのBMCR書き込み自体ではなく、DPMAC3の特定のSXGMIIインスタンスがMC/DPC初期化後にPCCC XFIセレクトビットがクリアされているかどうかです。

この正確な故障クラスは、LinuxのPCS**ドライバ**ではなくMCファームウェアに起きている前例もあります。あるLX2162Aチケットでは、USXGMII構成でMCがPCCCの10G**インターフェースセレクタ**を間違ったクリアしている様子があり、MCのファームウェアエンジニアリングビルドバージョン10.35.101で問題が解決されました。別のチケットでは、MCの設定はMCファームウェアによって行われ、NXPはMCをバイナリとして提供していると記載されています。MC 10.39.0 を使用しているため、その特定の古い修正は適用されていないはずですが、発生している障害モードは依然として「MC が意図した PCS を USXGMII モードにしなかった」または「間違った PCS インスタンスが処理されている」というエラーと一致しています。

次に私がすること：

Linuxが何かを変える前にPCCCを読んでください。
RCW + MC + DPL/DPCのロード後、LinuxのPCSドライバーが動作する前に、PCCCを読み取り、該当するSXGMII*_XFIビットが0であることを確認します。DPMAC3 / USXGMII/XFI.3 用、最初のSXGMIIセレクタを期待してください。MAC13/14のセレクタではありません。そのビットが1のままの場合、レーンは依然としてXFI/SFIであり、VEND2/USXGMII PCS書き込みはアクティブなUSXGMII PCSパスに適用されません。

MDIOアクセスが意図したPCS管理ポートに届いているか確認してください。
SXGMIIプロトコル制御レジスタにはMDIOアクセスをマッチングするためのMDEV_PORTフィールドがあり、マニュアルにはMDIOがSGMII/PCSターゲットにアクセスするまで、ソフトウェアは変更後少なくとも3プラットフォームクロックを待つ必要があると記載されています。もしMDIOアドレスデコードが間違っていると、書き込みが「永続しない」ように見えることがあります。これは異なる、またはリセット/デフォルトのPCSウィンドウを読み取っているからです。

USXGMII ANレジスタが意味を持つのは、モード選択が正しく行われた後のみであることを確認してください。
USXGMII PCS CONTROLレジスタのビット12にはAUTO_NEGOTIATION_ENABLEがあり、DEV_ABILITY / PARTNER_ABILITYはRWレジスタです。DEV_ABILITY下位ベンダーの任意の速度フィールドはゼロでなければならず、ゼロは自動交渉失敗を引き起こす可能性があります。しかし、PCCCが依然としてXFIを選択する場合、これらのBMCR/能力書き込みは本当の根本的な問題ではない。

GPY245ボードのドキュメントに明確に記載されていない限り、QXGMIIを別の必須外部プロトコルとして扱わないでください。
LX2162Aドキュメントには、PD_QXGMやRST_QXGMなどのリセット/電源停止制御ビットを含むQXGMIIプロトコルコンバータレジスタが含まれています。NXPコミュニティの資料LS1028Aでは10G_QXGMII Lynx SerDesドライバーパスも言及されています。しかし、選んでいるDPMACインターフェースLX2162Aドキュメントは依然としてUSXGMII / XFIであり、NXPのドキュメントにはLX2160クラスのデバイスがUSXGMIIをサポートし、「SXGMII」は同じ意味ではないと別途記載されています。言い換えれば、「QXGMII」という言及は、ドライバ/コミュニティの議論において、あなたが設定したUSXGMIIモードとは必ずしも異なるMAC-to-PHY契約ではなく、内部のコンバータ/ドライバの命名パスを指している可能性があります。

このClearfog SFPテストでは、DPCはシンプルなものにしてください。
MAC_LINK_TYPE_PHY enet_if = 「USXGMII」のモデルは、MDIO上で管理される外部PHYのより自然なモデルです。バックプレーン/KRスタイルのフローを意図的に使用していない限り、MAC_LINK_TYPE_BACKPLANE が PHY 側の USXGMII 設定を修正するとは期待できません。

プロトコル3が「主にXFI専用」であるとは結論付けません。リファレンス・マニュアルでは、プロトコル3をDPMAC3のSerDes1レーン用にUSXGMII / XFIとして記載しています。取得した資料から確認できないのは、「プロトコル3 + DPMAC3 + USXGMIIはGPY245で検証された」という別の検証文です。より強力な証拠に基づく主張は、ハードウェアモードは存在し、PCCCがUSXGMIIを選択しない限りデフォルトでXFIに移行すること、そしてMCファームウェアで誤った10G PCSセレクタをプログラムする前例が存在することが知られています。

具体的な読み上げ内容については、以下をご覧ください。

ADV=0xd601 BMCR=0x1a00 を書き込んだ

リードバック ADV=0x6b00 BMCR=0x0800 BMSR=0x0000 LPA=0x0000

これは、PCSインスタンスがUSXGMIIで完全に有効化・選択されていないか、MDIOマネジメントウィンドウが意図したPCSインスタンスに対応していない場合に予想される結果です。Linux側の書き込みを追加する前に、まずPCCCとMCログを確認したほうがいいでしょう。

LX2162Aプロトコル3はDPMAC3上のUSXGMII / XFIについて文書化されていますが、USXGMIIはMC/PCCCがUSXGMII PCSを選択することに依存しています。VEND2/BMCR書き込みが永続化されない場合は、まずDPMAC3の正しいPCCCビットがクリアされていること、およびMDIOが正しいSXGMII PCSインスタンスをアドレス指定していることを確認してください。

Re: LX2162A USXGMII link never completes

@yipingwang詳細なご回答、本当にありがとうございます！

あなたの言うことはすべて納得でき、プラットフォームについてもっと学び始めています。AN13329.pdfに記載されているアドバイスを実践し始めました。いくつかのアドレスや機能がうまくいかず(おそらくバージョンの不一致です)、少なくとも以下に示すようにMCログは入手できます:

=> md 0x8340020 10
08340020: e0000006 00000021 00060000 00000000  ....!...........
08340030: 00000000 00000000 00000000 00000000  ................
08340040: 00000000 00000000 00000000 00000000  ................
08340050: 00000000 00000000 00000000 00000000  ................

=> md 0x21e1000000
21e1000000: 4d430100 00000000 01400000 00300000  [email protected].
21e1000010: 00000073 00000000 00000000 00000000  s...............
21e1000020: 00000000 00000000 00000000 00000000  ................
21e1000030: 00000000 00000000 00000000 00000000  ................

=> md 0x21e1400000 50 
21e1400000: 202c575b 54414c50 4d524f46 5520205d  [W, PLATFORM]  U
21e1400010: 20545241 6e697270 61662074 64656c69  ART print failed
21e1400020: 6c61202c 6564206c 20677562 61746164  , all debug data
21e1400030: 6c697720 6562206c 69727020 6465746e   will be printed
21e1400040: 206f7420 66667562 0a2e7265 6e6e7552   to buffer..Runn
21e1400050: 20676e69 6120434d 202c7070 74696177  ing MC app, wait
21e1400060: 20676e69 20726f66 6e657665 2e207374  ing for events .
21e1400070: 000a2e2e 00000000 00000000 00000000  ................
21e1400080: 00000000 00000000 00000000 00000000  ................
21e1400090: 00000000 00000000 00000000 00000000  ................
21e14000a0: 00000000 00000000 00000000 00000000  ................
21e14000b0: 00000000 00000000 00000000 00000000  ................
21e14000c0: 00000000 00000000 00000000 00000000  ................
21e14000d0: 00000000 00000000 00000000 00000000  ................
21e14000e0: 00000000 00000000 00000000 00000000  ................
21e14000f0: 00000000 00000000 00000000 00000000  ................
21e1400100: 00000000 00000000 00000000 00000000  ................
21e1400110: 00000000 00000000 00000000 00000000  ................
21e1400120: 00000000 00000000 00000000 00000000  ................
21e1400130: 00000000 00000000 00000000 00000000  ................

私はubootを介してPCCCを操作しようと試みました。関連する事項は以下のとおりです。

crc32+ MC firmware version 10.39.0
fsl-mc: Booting Management Complex ... SUCCESS
fsl-mc: Management Complex booted (version: 10.39.0, boot status: 0x1)
Autoboot in 3 seconds

=> mmc read 0x80d00000 0x6800 0x800
=> fsl_mc apply dpl 0x80d00000    
fsl-mc: Deploying data path layout ... SUCCESS

=> md.l 0x1ea10b0 1   
01ea10b0: 88889991                             ....

0x1ea10b0が正しいアドレスであることを心から願っています。LX2162ARM.pdfによると、それが正しい住所である可能性はあり、ビットを解読すると次のようになります:

A (lane 0)	bit 31	1 = XFI/SFI
B (lane 1)	bit 27	1 = XFI/SFI
C (lane 2)	bit 23	1 = XFI/SFI
D (lane 3)	bit 19	1 = XFI/SFI

正しいレジスタアドレス（PCCC）を観察すべきでしょうか？他に提供できる情報はありますか?

ありがとう！