2351981_ja-JP

[#1]

eth1上のls1021a-twrでSGMIIを確実に設定できません

こんにちは、

現在使用しているもの：

• U-Boot : if_v2404.04
• Linuxカーネル： 5.15
• どちらもNXP QorIQソフトウェアスタックからのものです。

当社は、既存製品向けにLS1021A TWRプラットフォームをベースにした新しい通信ボードを開発しています。この新しい通信ボードでは、 eth1インターフェースはSGMIIを介してMAC-to-MAC/PHYレス構成で外部イーサネット・スイッチICにコネクテッドされています。既存の通信ボードでは、代わりにMarvell PHYを使用して、eth1上のSGMIIを介してホストプロセッサに接続されています。

私たちは、共通のU-Bootを使用して両製品をサポートしつつ、Linuxがさまざまなeth1トポロジーを正しく処理できるように努めています。

最新号

当初、新しい通信ボードを動作させるために、以下のDTS変更を行いました。

1) U-Boot DTSの回避策

U-Bootでは、arch/arm/dts/ls1021a-twr.dtsiでenet0とenet1の両方に同じTBIハンドルを使用するように強制しました。

&enet0 {

tbi-handle = <&tbi0>;

phy-handle = <&sgmii_phy0>;

phy-connection-type = "sgmii";

ステータス = "正常";

};

&enet1 {

tbi-handle = <&tbi0>;

phy-handle = <&sgmii_phy1>;

phy-connection-type = "sgmii";

ステータス = "正常";

};

2) LinuxカーネルのDTSの変更

カーネルDTS（arch/arm/boot/dts/ls1021a-twr.dts）では、eth1が独自のTBIハンドルと固定リンク記述を使用するように変更しました。

&enet0 {

tbi-handle = <&tbi0>;

phy-handle = <&sgmii_phy0>;

phy-connection-type = "sgmii";

ステータス = "正常";

};

&enet1 {

tbi-handle = <&tbi1>;

/* phy-handle = <&sgmii_phy1>; */

phy-connection-type = "sgmii";

固定リンク = <1 1 1000 0 0>;

ステータス = "正常";

};

3) カーネルのGianfarの変更

また、gianfar.cも修正しました。eth1ではTBIオートネゴシエーションを無効にしつつ、通常のPHY接続CASEではオートネゴシエーションを有効にしたままにする。

static void gfar_configure_serdes(struct net_device *dev)

{

/* 初期化 */

/* eth1のみで無効化 */

char *eth1 = "eth1";

if (strcmp(eth1, priv->ndev->name) == 0) {

printk(KERN_INFO "インターフェース %s で tbi オートネゴシエーションをオフにします",

priv->ndev->name);

phy_write(tbiphy, MII_BMCR,

BMCR_FULLDPLX | BMCR_SPEED1000);

} それ以外 {

phy_write(tbiphy, MII_BMCR,

BMCR_ANENABLE | BMCR_ANRESTART |

BMCR_FULLDPLX | BMCR_SPEED1000);

    }

}

上記の回避策により、プロセッサは新しい通信ボード上の外部スイッチと通信できるようになりました。

---

私たちが変えるべきこと

U-Bootは2つの製品間で共有する必要があり、既存の製品ではeth1に実際のPHYが接続されているため、U-Bootが通常のインターフェースごとのTBIバインディングを使用する必要があります。

U-Bootでは、インターフェースを次のように記述する必要があります。

&enet0 {

tbi-handle = <&tbi0>;

phy-handle = <&sgmii_phy0>;

phy-connection-type = "sgmii";

ステータス = "正常";

};

&enet1 {

tbi-handle = <&tbi1>;

phy-handle = <&sgmii_phy1>;

phy-connection-type = "sgmii";

ステータス = "正常";

};

しかし、U-Bootでこの変更を行うと、プロセッサは新しいMAC間/固定リンク通信ボード上のイーサネットスイッチとの通信を停止してしまう。

---

現在の理解

1. 最初の回避策では、U-Boot がtbi1 を初期化せず、Linux が後で tbi1 を初期化し、eth1 の TBI オートネゴシエーションを無効にすることで、固定リンク MAC 間接続が機能するようになります。
2. U-Bootを正しいポートごとのTBIマッピング（eth0 -> tbi0、eth1 -> tbi1）に戻すと、動作が変わり、固定リンクボードがスイッチと通信しなくなります。
3. 上記で説明した最初の U-Boot 回避策では、既存の製品 (eth1 が Marvell PHY over SGMII を使用している場合) では eth1 が動作しません。eth1 は U-Boot で正しく初期化される必要があるようです。そうでないと、インターフェースは正しくトラフィックを送信しません。

---

追加の技術的背景

eth0で実際のPHYを使用し、eth1で固定リンク/MAC間SGMII接続を使用するインターフェースの場合の推奨される処理方法について理解したいと考えています。

---

質問

1. LS1021Aにおいて、U-Boot DTSの回避策に頼らずに、eth1上の固定リンク/PHYレスSGMII接続でTBIオートネゴシエーションを無効化またはバイパスするための推奨される方法は何ですか？
2. Linuxが後でeth1に固定リンクを使用する場合でも、U-Bootは常にDTS（eth0→tbi0、eth1→tbi1）に従ってポートごとのTBIを正確に初期化するべきでしょうか？
3. PHY接続と固定リンクの切り替え時に、gfar_configure_serdes()を実行する前にLinuxからTBIをリセットまたは再初期化する推奨方法はありますか？
4. 固定リンク／MAC間SGMIIの場合、PCS／TBIは通常のgfar_configure_serdes()フローを通じてプログラムすべきでしょうか、それとも別の初期化フローが推奨されますか？

Re: Cannot configure SGMII reliably on ls1021a-twr on eth1

ご回答ありがとうございます。

これらの変更を加え、さらにテストを試みましたが、依然として同じ問題が発生しています。

両方のデバイスに同じubootイメージを使用したいので、enet1はPHY接続とPHYレス接続の両方で同じubootを使用することになります。

uboot から enet1 の定義を削除して、enet の設定を完全にカーネルで処理するように試みましたが、これは固定 PHY の場合はうまくいきましたが、PHY が接続されている場合はうまくいきませんでした。PHY構成は正しく機能しているようですが、TBI構成が機能していないようです。

1. この状況をどのように対処するのが良いと思いますか？
2. ubootでenetインターフェースが全く設定されていなかった場合、カーネルでenetインターフェースを設定するために他に何か必要なことはありますか？

よろしくお願い申し上げます。

Re: Cannot configure SGMII reliably on ls1021a-twr on eth1

1. fixed-link は、Linux dts で以下のように宣言できます。

&enet1 {
phy-mode = "sgmii";
管理対象 = "固定リンク";
固定リンク

{ speed = <1000>; full-duplex; pause; }

;
ステータス = "正常";
};

2. はい、U-Boot はポートごとの TBI を初期化する必要がありますが、固定リンクの場合は TBI の自動ネゴシエーションを無効にする必要があります。

3. リンクが修復されたら、gfar_configure_serdesでPCS/TBIをリセットする必要があります。例：
if (is_fixed_link)

{ phy_write(phydev, MII_BMCR, BMCR_RESET); udelay(10); phy_write(phydev, MII_BMCR, BMCR_FULLDPLX | BMCR_SPEED1000); ... // 自動ネガを無効にする }

ありがとう

Re: Cannot configure SGMII reliably on ls1021a-twr on eth1

1.ハードウェアのバリアント両方で同じU-Bootイメージを使用しながら、enet1を完全に削除するのではなく、U-Boot内で最小限の初期化状態にしておくことをお勧めします。
具体的には：

a. U-Bootでenet1のMACとPCS/TBIの初期化を保持する。
b.U-Bootでは、PHY固有の設定（遅延調整、LED設定、ベンダー固有のレジスタなど）は避けてください。
c.Linuxカーネルのデバイスツリーにenet1が使用するかどうかを決定させる。

固定リンク（PHYなしの場合）、または
phy-handle を介した実際の外部 PHY。

2. はい、いくつかの追加的な考慮事項が適用されますが、それはある程度に限られます。
U-BootでENETインターフェースが全く設定されていない場合でも、以下の条件を満たせばLinuxカーネルはMACとPHYを初期化できます。

デバイスツリーはインターフェースを正しく記述しています（ステータス＝「okay」、適切なphy-mode、有効なphy-handleまたはfixed-link）。
クロック、pinctrl、およびMDIOは適切に定義されています。
PHY自体はカーネルドライバによってアクセス可能であり、サポートされています。

しかし、Linuxドライバは通常、PCS/TBI（またはSerDes）ブロックを完全に初期化しません。多くのSoC、特にSGMII/RGMII構成の場合、カーネルはPCS/TBIがブートローダーによって既に使用可能なモードになっていることを前提としています。

よろしくお願いします。