2397364_ja-JP

Yes

ls1021a eTSEC 送信タイムアウト

私はLS1021A IoTと、このCPUをベースにしたプロトタイプ基板を持っています。どちらの場合も、弊社独自のブートローダーを使用しています。

IOTボードでは完璧に動作しますが、私のボードではイーサネットポートで送信タイムアウトが発生します。数回のpingが送信され、その後送信タイムアウトが発生し、さらにpingが送信されます。このため、TFTPはほとんど利用できません。

もちろん、ハードウェアの違いはあります。私たちのMACはBCM54616Sに接続され、その後LAN9514に接続されています。自動交渉の上限は100FDです。ループバックモードでもTXタイムアウトが発生します。

データを送信するためには、ボードのTBI PHYでビットSGMII_ANビットを設定しなければなりませんでしたが、IOTでは不要でした(IOTは1000FDで交渉可能です)。

なぜTXがこんなに断続的に起こるのか分かりません。この速度制限と関係があるのでしょうか?

Re: ls1021a eTSEC tx timeout

こんにちは、

100FD SGMIIの場合、プロトタイプ基板上のブートローダーで以下の項目を確認してください。

LS1021AのeTSECをSGMII 100Mbpsに設定する
- ECNTRL[TBIM] = 1
- ECNTRL[SGMIIM] = 1
- ECNTRL[R100M] = 1
- MACCFG2[I/F Mode] = 01 （10/100モードの場合）
  LS1021Aのリファレンスマニュアルには、SGMII 100Mbpsの場合、 R100M = 1設定することが明記されています。
内部のTBI PHYをリセットしプログラムするRMは、SGMIIがTBIレジスタセットを使用していること、そしてSGMIIを含むすべてのインターフェースモードでTBIをリセットすることが重要であると述べています。
SGMII_ANビットは設定したままにしてください。TBI のSGMII_ANビットは「1 に設定する必要があります」と記載されています。このビットを設定した後にしか基板が送信しないのは驚くことではありません。このPHY/MACモードのブートローダー初期化が不完全であることを示唆しています。
100 Mbps での 1G スタイルの SGMII AN 動作に頼らないでください。LS1021A では、100 Mbps SGMII 動作時に「SGMII リンクが正常ではありません」というメッセージが表示されたり、リンクのサイクル後に断続的にパケットが送信されないという報告が知られていますが、1G 動作では問題ありません。それは、あなたのTXタイムアウトの正確な根本原因を証明するものではありませんが、100FD SGMIIの設定が有力な容疑者であることを示唆しています。

ループバックの結果が重要です。もし「ループバックモード」が外部PHYループバックやSGMII側ループバックであれば、100FDのSGMII/TBIセットアップは関与可能です。内部MAC/eTSECループバックの場合、外部BCM54616S/LAN9514パスはほとんど関係ないので、eTSECの初期化、ディスクリプタリングの処理、キャッシュの一貫性、およびTXの停止/エラー状態に焦点を当てます。

デバッグを行うには、タイムアウトが発生したときにeTSEC TXの停止状態を確認してください。RMは、eTSECがTxBDリングからの送信フレームを処理しなくなったときに送信停止ビットを設定すると述べています。繰り返し可能な原因には、バスエラー、無効なBD/データアドレス、修正不能なBD/データ読み取りエラー、長さ 0 の Ready = 1 などのTxBDプログラミングエラーなどがあります。また、見ているかどうかも確認してください IEVENT_BSY ;NXPの資料では、BSYはバッファ不足やソフトウェアがBDリングに十分速く対応できないことによるRXフレームのドロップと説明されており、これは純粋なSGMIIの電気的症状ではなくソフトウェア/BDリングの症状です。

推奨される分離シーケンス:

1. 必要に 応じて、 外部 PHY を 100FD に 強制し 、 銅線に対する自動ネゴシエーションを無効にします 。2. LS1021Aの MAC / eTSEC を SGMII 100Mbps に 強制的に設定する ： TBIM = 1 、 SGMIIM = 1 、 R100M = 1 、 MACCFG2 I / F モード = 10 / 100。3. SGMII モードを設定した後、 TBIを リセット / 再初期化します 。4. TBI SGMII_AN = 1 に設定します 。 5. TBI リンク / AN ステータス 、 eTSEC ECNTRL / MACCFG2 、 および PHY SGMII 側 ステータス を確認します 。6.タイムアウト時に、 IEVENT 、 TXハルトレジスタ、 DMAステータス、およびTXBDリングの内容をダンプします。

敬具

Re: ls1021a eTSEC tx timeout

言い忘れていましたが、私のポートはSGMIIモードに設定されています。

Re: ls1021a eTSEC tx timeout

こんにちは、

詳細な調査結果をありがとうございます。ご指摘いただいた回避策（1ミリ秒の遅延、手動によるDMAフラッシュ、 dma-coherent削除）の組み合わせは、キャッシュエイリアスの問題の典型的なパターンです。以下に、根本原因の説明と推奨される解決方法を示します。

根本原因：TX記述子領域上のキャッシュされた仮想エイリアス

LS1021A ENET DMAはキャッシュ整合性のないバス・マスタであり、CPUキャッシュの可視性を持たずにDDRを直接読み込みます。LS1021A上のgianfarの正しい運用モデルは、非コヒーレントなソフトウェア管理モデルです。すなわち、ディスクリプタをキャッシュされていないメモリに割り当て、CPUがディスクリプタフィールドを更新するたびに明示的な dma_sync_* 呼び出しを行います。

LPAEの変更によって最も可能性が高いのは、記述子の物理アドレス範囲のページテーブルエントリに、誤ったキャッシュ属性（デバイスまたは通常のキャッシュ不可ではなく、通常のライトバック）が付与されたことです。これにより、同じ物理メモリに対して異なるキャッシュ性を持つ2つの仮想エイリアスが作成されます。割り当てパス( dma_alloc_noncoherent経由)はキャッシュされていない状態をマッピングしますが、send関数のパケットごとのTXディスクリプタ更新パスはキャッシュされたエイリアス経由でアクセスします。CPUは更新されたディスクリプタフィールドをキャッシュラインに書き込みますが、それらはDDRに到達せず、ENET DMAは古いデータを読み取ってアンダーランを起こします。

なぜあなたの３つの回避策はすべて同じ欠陥を隠蔽しているのか

1 ms遅延/メッセージ挿入:低負荷時にCPU書き込みバッファが自然に消耗する十分なレイテンシを追加します。タイミング依存で、トラフィックや周波数の変化により故障します。
send 関数でdma_flush手動で指定すると、DMA がディスクリプタを読み取る前に、PoC へのキャッシュのクリーンアップが強制されます。これは正しい動作ですが、領域が実際にキャッシュされていない場合は不要です。
enet デバイスノードからdma-coherent削除すると、カーネルは送信前に各 TX ディスクリプタに対してdma_map_single() / dma_sync_single_for_device()を呼び出し、明示的にキャッシュをクリアします。これも正しく、LS1021A-IOT が送信パスのフラッシュなしで確実に動作した理由を説明しています。

送信パスのフラッシュがないことが、欠けている要素です。LS1021A-IOTはdma-coherent削除しても動作しました。これは、カーネルのDMAマッピングレイヤーが同期を自動的に挿入したためです。一方、プロトタイプにはそのパスがありません。LPAEの変更により、同期を再導入することなく記述子領域のキャッシュ属性が変更されたためです。

DDR3LとDDR4/周波数の違い

これは根本原因ではありません。異なるDRAMの種類や周波数が書き込みレイテンシやバッファのドレインタイミングを変えるため、プロトタイプでは故障がより目立つのですが、根本的な欠陥はアーキテクチャ的なもので、十分な負荷がかかると両方の基板に存在します。

推奨される修正方法

正しく、かつ矛盾のない解決策は、以下の2つを組み合わせることです。

enetデバイスノードから dma-coherent 離しておきましょう(非コヒーレントモデル)。これにより、カーネルDMAレイヤーは、 dma_alloc_noncoherentを介して割り当てられたディスクリプタのDMA所有権が転送される前に、 dma_sync_single_for_device()自動的に発行します。
TX 送信パスにおいて、各パケットに TX 記述子フィールド ( status 、 data_length 、 data_pointer ) が書き込まれる箇所に、明示的なdma_sync_single_for_device()呼び出しを追加します。これは手動で追加したフラッシュですが、 TDARを書く前に正式にはdma_sync_single_for_device(dev, desc_dma_addr, sizeof(txbd), DMA_TO_DEVICE)として配置する必要があります。これにより、MMUがディスクリプタ領域をどのように属性付けしても、モデルは明示的かつ正確になります。
別途、ENET記述子に使用される物理アドレス範囲に割り当てられたAttrIndx / TEX+C+Bフィールドについて、LPAE MMUライブラリの変更を監査します。ディスクリプタプールは、Device-nGnRnE（厳密な順序付け）またはNormal Non-cacheableとしてマッピングする必要があります。Normal Writebackは使用しないでください。カーネルの ptdump デバッグインターフェースで、割り当て後にディスクリプタプールの仮想アドレスを確認することで、実際に使われている属性を検証できます。

あなたが追加したDMAフラッシュは回避策ではなく、正しい仕組みです。本当の欠陥は、そもそも送信パスにそれが存在していなかったことであり、LPAEの変更によってその領域の実効的なキャッシュ可能性が変わったため、この欠陥が露呈した。

よろしくお願いします。

Re: ls1021a eTSEC tx timeout

送信機能にメッセージを追加したり、1ミリ秒の遅延を設けたりすることで、データの損失なく正しく転送することが可能になります。

送信関数内のTXディスクリプタにDMAフラッシュを追加したところ、改善されました。ただし、ディスクリプタはキャッシュされていないメモリに割り当てられるため、これは必要ないはずです。LPAEサポートを追加したMMUライブラリの欠陥かもしれません。

そういえば、ずいぶん前にenetデバイスノードのdma-coherentプロパティを削除したところ、LS1021A-IOTが動作するようになったことを思い出しました。これは、ディスクリプタ用にキャッシュされていないメモリを割り当てながら、DMAフラッシュを強制的に実行します。しかし、送信関数には、各パケットのTX記述子を更新するキャッシュフラッシュ機能がありませんでした。なぜ私のプロトタイプでは動作しないのか分かりません(周波数の違い、DDR3LとDDR4の違い,...)