LS1046A PHY-less SGMII in U-Boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LS1046A PHY-less SGMII in U-Boot

1,960 Views
thomasscarsbroo
Contributor II

Hi,

I have a custom LS1046A board. All 4 lanes on SERDES1 are configured as SGMII (0x3333 in the RCW) however there is no PHY on the board.

All lanes are currently showing the same behaviour, however I'll focus on SGMII.9

I have my own MDIO init function under boards/...../eth.c, in which I create and register a new mii_dev. I use the memac_mdio_read/write/reset functions, and have priv pointing to 0x1AF1030, which is MDIO9 for EMAC9 according to Table 5-17 in the DPAA reference manual.

I also set MDEV_PORT in SGMIIDCR1 (0x1EA1834) to 0x1.

I call

fm_info_set_phy_address(FM1_DTSEC9, 0x1)

fm_info_set_mdio(FM1_DTSEC9, mii_dev)         // Using the mii_dev created above

As far as I can tell this is in line with how LS1046AQDS sets up its SERDES, as I believe this has some 2.5G SGMII ports without PHY's (as given away by other users on this forum and by comment in the code).

If I then boot, and run mdio list, I get:

=> mdio list

Internal MDIO 9:

1 - Generic PHY <--> FM1@DTSEC9

However, if I run mdio read:

=> mdio read FM1@DTSEC9 0-0x1b

Reading from bus Internal MDIO 9

PHY at address 1:

0 - 0x0

1 - 0x0

2 - 0x0

3 - 0x0

4 - 0x0

5 - 0x0

6 - 0x0

7 - 0x0

8 - 0x0

9 - 0x0

10 - 0x0

11 - 0x0

12 - 0x0

13 - 0x0

14 - 0x0

15 - 0x0

16 - 0x0

17 - 0x0

18 - 0x0

19 - 0x0

20 - 0x0

21 - 0x0

22 - 0x0

However, performing a memory dump at 0x1AF1030 shows that there is some non-zero data.

Then, when I try to communicate I get:

FM1@DTSEC9: Tx error, txbd->status = 0x8800

FM1@DTSEC9: Tx buffer not ready, txbd->status = 0x8800

What am I missing?

Thanks,

Thomas

0 Kudos
3 Replies

1,487 Views
bpe
NXP Employee
NXP Employee

The interface between mEMAC and SerDes does not provide for
per-frame transmission acknowledgement thus MAC/FMAN cannot report
any PHY-level error in a BD. Based on the console output you provided,
your u-Boot complains about BD not being ready and displays a ready
BD immediately after that. This is not a normal situation, but it is
not related to SerDes. There can be a corrupt pointer or memory
structure overlap or something that is not visible without debugging.
My suggestion in this regard is to step through u-Boot code to see
how exactly it comes to the "Tx buffer not ready, txbd->status = 0x8800"
message. A good starting point is  drivers/net/fm/eth.c.

As of SGMII, please be aware, that connecting SGMII-to-SGMII without
PHYs in between is not recommended for your processor, although it is
possible. The recommended approach is to use 1000Base-KX mode instead,
which is specially designed for this kind  of connection.
Initialization steps can be found in LS1046ARM,  Section  31.8.1.3.


Have a great day,
Platon

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,487 Views
thomasscarsbroo
Contributor II

It might be worth noting, I am using LSDK 1809

Thomas

0 Kudos

1,487 Views
thomasscarsbroo
Contributor II

Found the first problem, priv needed to be pointing to 0x1AF1000, as it already accounted to the offset to the MDIO registers. I now get what appear to be sensible values back when querying the MDIO registers.

=> mdio read FM1@DTSEC9 0-0x1b

Reading from bus Internal MDIO 9

PHY at address 1:

0 - 0x1140

1 - 0xd

2 - 0x83

3 - 0xe400

4 - 0x4000

5 - 0x0

6 - 0x5

7 - 0x0

8 - 0x0

9 - 0x0

10 - 0x0

11 - 0x0

12 - 0x0

13 - 0x0

14 - 0x0

15 - 0x0

16 - 0x0

17 - 0x1

18 - 0x12d0

19 - 0x13

20 - 0x0

21 - 0x4

22 - 0x0

However, I am still not able to communicate out, I still get:

FM1@DTSEC9: Tx error, txbd->status = 0x8800

FM1@DTSEC9: Tx buffer not ready, txbd->status = 0x8800

Anyone know why this might be occuring?

0 Kudos