Problems C6678 + PHY 88E1512

Hi Alberto,

We will check with factory team and get back to you as soon as possible. Thank you.

Simon Wheeler48 said:

If you are not using ndk, the 1512 has a software patch you have to apply. [...]

I have already applied the petch but without success.

I use a c6678 custom driver derived from the IBL. It works with EVM and another custom board equipped with 88E1111 (that require no configuration at all)

The new board is identical to the old custom one, but it has an 88E1512 in place of the old 88E1111, so I add a minimal PHY setup:

1. PHy initialization after HW reset, as required by Marvell errata
2. Set up SGMII mode and reset the PHY

Nothing else since the default seem to be ok (even if I see u-boot driver execute a lot of othert setup applicable to the 88E1111 also).

The curious behavior is that the communication between Marvell and C6678 is at least partially ok, since I'm able to receive without errors the first 28 bytes of every packet!.

For us, the initialisation patch was enough to get it working, but prior to that we did have a lot of messing around with SGMII line lengths on our board. This was 3 years ago, so i'm a little fuzzy on the detail (and not a hardware guy).

Have you looked at the SGMII status register?

Simon Wheeler48 said:

For us, the initialisation patch was enough to get it working,

So just to be sure I understand correctly, You confirm that the simple patch + SGMII mode init (just a single write in a MDIO register) should be enough..Other "complex" initialization as I see in u-boot are not necessary

Have you looked at the SGMII status register?

Yes but I have to recheck it since I'm not sure if I get the right register (in the data-sheet there is an error, I suppose), so I look on the C6678 side and there every things seems ok. I can receive partially corrected message, of fixed 28 bytes size but I can receive. The same SW (that is C66778 configuration) works without problem on another custom board.

We boot from a custom boot loader that does not touch the ethernet systems, so yes no more config is needed.

I vaguely remember getting stuck for a while on SGMII negotiation with only one side coming up, but if you are getting data through at all, seems unlikely thats the problem.

We run the 1512 patch first, then init the connected SGMII port with the code below:

The SGMII_ROW_xxxx defines just reference the SGMII register offsets from the base address. Should be easy to match against 'Keystone Architecture Gigabit Ethernet user guide sprugv9d'. SGMII register addresses are correct in that revision. The two SGMII ports have different address offsets.

/** Maximum size of an ethernet packet */
#define SYSTEM_MAX_ETH_PACKET_LENGTH (9504)

Status sgmii_ResetPort(UInt32 port)
{
Status status;
UInt32 attempts;
UInt32 value;

status = STATUS_SUCCESS;

/* Reset the MAC */
CSL_CPGMAC_SL_resetMac(port);

attempts = 0;
while((status == STATUS_SUCCESS) &&
(CSL_CPGMAC_SL_isMACResetDone(port) != TRUE))
{
attempts++;
if(attempts > SGMII_ATTEMPTS)
{
status = STATUS_TIMEOUT;
}
hal_DelayCycles(1000000); // 1ms
}

if(status == STATUS_SUCCESS)
{
/* Configure the MAC */

// CSL_CPGMAC_SL_enableGMII(port);
CSL_CPGMAC_SL_disableGMII(port);
CSL_CPGMAC_SL_enableExtControl(port);
CSL_CPGMAC_SL_setRxMaxLen(port, SYSTEM_MAX_ETH_PACKET_LENGTH);

}

if(status == STATUS_SUCCESS)
{
/* Reset the port before configuring it */
status = sgmii_WriteRow(port,
SGMII_ROW_SOFT_RESET,
SGMII_SOFT_RESET_SET);

if(status == STATUS_SUCCESS)
{
status = sgmii_ReadRow(port, SGMII_ROW_SOFT_RESET, &value);

while((status == STATUS_SUCCESS) &&
(value != SGMII_SOFT_RESET_CLEAR))
{
status = sgmii_ReadRow(port, SGMII_ROW_SOFT_RESET, &value);
}
}
}


/* Set advertised ability */

if(status == STATUS_SUCCESS)
{
status = sgmii_ReadRow(port,
SGMII_ROW_MR_ADV_ABILITY,
&value);
}

value &= 0xFFFF0000;

value |= 0x00000001;

if(status == STATUS_SUCCESS)
{
status = sgmii_WriteRow(port,
SGMII_ROW_MR_ADV_ABILITY,
value);
}

/* Set the device in slave mode with auto-negotiation */

if(status == STATUS_SUCCESS)
{
status = sgmii_ReadRow(port,
SGMII_ROW_SGMII_CONTROL,
&value);
}

value |= 0x00000001;

if(status == STATUS_SUCCESS)
{
status = sgmii_WriteRow(port,
SGMII_ROW_SGMII_CONTROL,
value);
}

return status;
}

Hi,

I tried to compare my code with your suggestion but without success. Both side, C6678 GEth and marvel 1512, say the links are up but I'm not able to transmit or correctly receive message.

Note that the C6678 statistics seem to be correct: it counts the right number of frame and octets both in TX and RX but:

- nothing go out on the cable (Wireshark)

- received packet len is wrong and vary from 28 to 32 byte (I'm not able to correlate the received len with the original)

- statistics (STATB) count the good number of frame and also octets (message shorter that 64 bytes are conted as 64)

I incorporate the full 1512 configuration from u-boot: the links go up and the u-boot driver reports no errors.

Maybe there is an HW problem or not deterministic initialization problem (a bug in my SW): in two "run" I successfully transmit ARP message but with a wrong ethernet Frame Check sequence, that is the last 4 byte that I cannot control and are added by device. After a reset and rerun, the tx stop working without SW modification...

I tried also the 1512 built-in packet generator: the C6678 receive the right number of packet but with wrong message size varying from 8 to 36 bytes (packet size = 64 bytes)

Hi,

I'have revolved the TX problem: uintil now I miss the existence of the PS_FLAGS.TO_PORT field in the packed send to the GBE switch. In the example source code I used to make my driver, this field was always 0.

By proper setting it to the desired port (1 or 2), the TX start working (I also remove the FCS error problem reported by WireShark by patching it with the right value for message shorter then 64 bytes).

Unfortunately I have no time to further investigate why TO_PORT=0 works  with other board based on the Marvel 88E111x, both when using PORT_1 or PORT_2 (but I have not toyed with  both).

I still having  the problem on the RX packets: evenyithing seems ok (phy status and C6678 port status and STATB info), but the packet received from the PA to the destination queue is always shorter then the real Ethernet packet.

The size is variable but always wrong (for instance 28 bytes instead of 48), while the contents is always correct according (with the declared len, the "trailing" missed byte are not trasfered from PA to the memory buffer).

I suppose I miss something in the C6678/PHY setup, but I'm not able to find the point (the save code work on a board with a config-less PHY as EVM).