FAQs
English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

2401930_ja-JP

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2401930_ja-JP

2401930_ja-JP

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）を観察すべきでしょうか？他に提供できる情報はありますか?

ありがとう！

Re: LX2162A USXGMII link never completes

はい。のために SerDes1 、 0x1ea10b0 正しい住所は PCCC :

  • LX162A CCSRマップリスト SerDes 1 で 0x1EA_0000–0x1EA_FFFF 。
  • SerDesのメモリマップには、 プロトコル構成レジスタC / PCCC オフセットで 0x10B0 。
  • したがって：
    0x1EA0000+0x10B0=0x1EA10B0

あなたのUブートにはこう書かれていました:


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

 

予想どおりに観測している SerDes1 PCCC 登録する。

重要な注意点は命名法です。私はそれらの分野を物理的とは表現しません。 SerDesレーンA/B/C/D 現在の設定の場合。LX2162A SerDes1プロトコルテーブルでは、プロトコル 3 地図 物理レーンH / レーン0 に USXGMII / XFI.3 、その後レーンG/レーン1から .4 、レーンF/レーン2から .5 、そしてレーンE/レーン3から .6 。PCCCフィールド名など SXGMIIA_XFI 、 SXGMIIB_XFI などは PCS/プロトコル制御フィールドであり、必ずしも物理レーン文字と同じ命名規則ではありません。

価値 0x88889991 上位ニブルは次のようにデコードされます。


PCCC = 0x88889991
ビット31:28 = 0x8 -> SXGMIIA_XFI = 1、CFG = 000
ビット 27:24 = 0x8 -> SXGMIIB_XFI = 1、CFG = 000
ビット 23:20 = 0x8 -> SXGMIIC_XFI = 1、CFG = 000
ビット 19:16 = 0x8 -> SXGMIID_XFI = 1、CFG = 000
ビット15:12 = 0x9 -> SXGMIIE_XFI = 1、CFG = 001
ビット11:8 = 0x9 -> SXGMIIF_XFI = 1、CFG = 001

 

重要な部分は _XFI 少し。RMは定義する 0 として USXGMIIモード そして 1 として XFI/SFIモード これらの分野については 。つまり、あなたが読んでいる値は、関連するUSXFI/SXGMIIのPCSインスタンスが依然として XFI/SFI として選択されていることを強く示唆しています。USXGMIIとして選ばれているわけではありません。

これはあなたの症状と一致します。Linux/restoolは報告するかもしれませんが DPMAC_ETH_IF_USXGMII PCCCが関連する _XFI selectビットを 1 保持しているなら、基盤となるSerDes/PCSの選択は実質的にXFI/SFIモードのままです。RMはまた、10G-SXGMIIを有効にするにはソフトウェアが設定しなければならないと明記しています PCCC[SGMIIa_XFI] = 0 。

あなたのMCログ抽出結果も問題なさそうです。AN13329では、MCFBAL/MCFBAHを以下のように読むように指示されています。 0x8340020 MCファームウェアベースを構築し、オフセットでログバッファ構造をダンプします。 0x01000000 ; この構造体には、マジックナンバー、ログバッファオフセット、およびログバッファ長が含まれます。 。あなたの 0x21e1000000 ダンプには予想どおりの結果が表示されます 0x4d430100 魔法とログオフセットへのポイント 0x01400000 これは、後であなたがダンプした内容と一致します。 0x21e1400000 。

次に私が撮影したいもの：

  1. PCCCの各段階におけるスナップショット

    md.l 0x1ea10b0 1

    それを捉える：

    • リセット直後／可能であればMC起動前に、
    • MCブート後、
    • DPC/DPL適用後、
    • Linuxが起動した後、
    • DPMACのプローブ/設定が完了した後。

  2. 隣接するプロトコル設定レジスタ

    md.l 0x1ea10a0 1 # PCC8
 md.l 0x1ea10a4 1 # PCC9
 md.l 0x1ea10b0 1 # PCCC

    PCC8/PCC9は他のSGMII構成フィールドを含み、PCCCはSXGMII/XFIセレクタレジスタ です。

  3. USXGMIIを強制しようとしたときにどのPCCCフィールドが変わるか確認してください 実験用にU-Bootを安全に挿入できるなら、候補ビットをクリアしてすぐに読み返してみてください _XFI 。例えば、dpmac3が最初のSXGMII/USXFI制御フィールドに対応する場合、ビット31をクリアすることが実験的な確認となる。

    mw.l 0x1ea10b0 0x08889991 1
 md.l 0x1ea10b0 1

    すぐに読み返せば 0x88889991 その場合、書き込みがブロック/上書きされているか、現在のブロック状態ではそのフィールドに書き込みができません。もしMCやLinuxが動くまで固定されるなら、MC/LinuxはXFI/SFIモードを復元している可能性が高いです。

  4. RCW SerDesの完全デコード あなたは既に SerDes1=3, SerDes2=11 ; dpmac3 レーンが利用可能であることと一致します USXGMII / XFI.3 SerDes1プロトコル3の下で 。ただし、MCファームウェアはプロトコルセット全体に基づいてキーを生成することが多いため、エスカレーションを行う際には、完全なRCW文字列と生のRCWダンプを含めてください。

  5. MCファームウェア + DPC/DPLアーティファクト あなたのMCは 10.39.0 、 含む：

    • MCファームウェアバージョン、
    • DPCソース、
    • DPLソース、
    • ちょうど dpmac@3 ブロック、
    • restool dpmac info dpmac.3 、
    • 各ステップ後のPCCC値。

私の現在の読めたデータ: はい、 0x1ea10b0 正しいSerDes1 PCCCアドレスであり 0x88889991 関連するPCSセレクタはまだXFI/SFIモードのようです。 これは、XFIがSFPケージを介して動作し、USXGMIIが期待されるPCS構成を受け入れ/保持しないという状況と一致しています。
Tags (1)
0 Kudos
Was this article helpful? Yes No
No ratings
Version history
Last update:
‎08-18-2026 04:29 AM
Updated by: