lanconf32 shuts the ethernet link down

PAgra · ‎07-04-2016

Hello everybody,

I'm trying to use the lanconf32 tool on a board equipped with a Rangeley C2000 Atom processor with embedded MAC and an external Marvell PHY (88E1112).

The iqvlinux.ko driver is a v.1.1.5.3. Inserting and removing it works well.

Our kernel is based on a CentOS 6.3 32bits.

The lanconf32 utility detects the ethernet interface, but as soon as I select one of the interface, the initialization procedure shuts it down (both LEDs are now off).

Following transmit or receive tests fails, as the lanconf32 utility reports "No link".

Am I missing anything in the procedure ?

Any hints ?

Thanks in advance.

Best regards,

Patrick Agrain

PAgra · ‎07-04-2016

Add-on: the lanconf32 version is 1.26.17.11

CarlosAM_INTEL · ‎07-04-2016

Hello PatrickA ,

Thank you for contacting the Intel Embedded Community.

In order to better understand this situation, we would like to address the following questions:

Could you please tell us if this situation happens with Wind River Linux BSPs or Linux Based on Yocto Project?

Could you please tell us if the External Phy is doing auto-negotiate or parallel detect in this case?

Please let us know the information that should answer these questions.

By the way, please dump all the LAN register (not just MAC register) before and after the cited condition occurs. You can use the Lanconf tool to do this.

Best Regards,

Carlos_A.

PAgra · ‎07-06-2016

Hi Carlos,

Thanks for taking time to investigate my issue.

Unfortunately, we do not use either the Wind River nor the Yocto SDK. We have our own compilation chain.

Here is the dump of the PHY (M88E1112) registers (it was not performed with lanconf):

Running interfaces:

PHY0: ID:0x01410c90 Rev.:07

(0:0) 0x1140 Copper Control

(0:1) 0x796d Copper Status

(0:2) 0x0141 PHY Identifier 1

(0:3) 0x0c97 PHY Identifier 2

(0:4) 0x01e1 Copper Auto-Negotiation Adv

(0:5) 0x45e1 Copper Link Partner Ability

(0:6) 0x0007 Copper Auto-Negotiation Exp

(0:7) 0x2801 Copper Next Page Transmit

(0:8) 0x0000 Copper Link Partner Next Page

(0:9) 0x0f00 1000BaseT Control

(0:10) 0x4000 1000BaseT Status

(0:15) 0xf000 Extended Status

(0:16) 0x6060 Copper Specific Control 1

(0:17) 0x6c08 Copper Specific Status 1

(0:18) 0x0000 Copper Specific Interrupt Enable

(0:19) 0x1c10 Copper Specific Status 2

(0:21) 0x0000 Copper Specific Receive Error Counter

(0:26) 0x0040 Copper Specific Control 2

(2:0) 0x1040 MAC Control

(2:16) 0x5968 MAC Specific Control 1

(2:17) 0x0440 MAC Specific Status 1

(2:18) 0x0000 MAC Specific Interrupt Enable

(2:19) 0x0000 MAC Specific Status 2

(2:26) 0x0000 MAC Specific Control 2

(3:16) 0x021e LED[1:0] Function Control

(3:17) 0x44a0 LED[1:0] Polarity Control

(3:18) 0x4105 LED Timer Control

(4:16) 0x0100 NV MEM Address

(4:17) 0x2000 NV MEM Read Data and Status

(4:18) 0xa000 NV MEM Write Data and Control

(4:19) 0x0000 NV MEM Write Data and Control

(4:20) 0x0000 NV MEM Address

(5:16) 0x0000 VCT MDIO(0) Status

(5:17) 0x0000 VCT MDIO(1) Status

(5:18) 0x0000 VCT MDIO(2) Status

(5:19) 0x0000 VCT MDIO(3) Status

(5:20) 0x0000 VCT Skew

(5:21) 0x0000 VCT Pair Swap & Polarity

(5:26) 0x0002 VCT DSP Distance

(6:16) 0x0000 Packet Generation

(6:17) 0x0000 CRC Checker

After lanconf32 has initialized one interface (e.g. eth0). Dumped with lanconf32, driverless mode:

(0:0) 0x1040 Copper Control

(0:1) 0x796d Copper Status

(0:2) 0x0141 PHY Identifier 1

(0:3) 0x0c97 PHY Identifier 2

(0:4) 0x01e1 Copper Auto-Negotiation Adv

(0:5) 0x45e1 Copper Link Partner Ability

(0:6) 0x0005 Copper Auto-Negotiation Exp

(0:7) 0x2801 Copper Next Page Transmit

(0:8) 0x0000 Copper Link Partner Next Page

(0:9) 0x0f00 1000BaseT Control

(0:10) 0x4000 1000BaseT Status

(0:15) 0xf000 Extended Status

(0:16) 0x6060 Copper Specific Control 1

(0:17) 0x6c08 Copper Specific Status 1

(0:18) 0x0000 Copper Specific Interrupt Enable

(0:19) 0x0000 Copper Specific Status 2

(0:21) 0x0000 Copper Specific Receive Error Counter

(0:26) 0x0040 Copper Specific Control 2

(2:0) 0x1040 MAC Control

(2:16) 0x5968 MAC Specific Control 1

(2:17) 0x0440 MAC Specific Status 1

(2:18) 0x0000 MAC Specific Interrupt Enable

(2:19) 0x0000 MAC Specific Status 2

(2:22) 0x0002

(2:26) 0x0000 MAC Specific Control 2

(2:29) 0x0002

(2:30) 0x2390

(3:1) 0x0001

(3:16) 0x021e LED[1:0] Function Control

(3:17) 0x44a0 LED[1:0] Polarity Control

(3:18) 0x4105 LED Timer Control

(3:22) 0x0003

(3:29) 0x0003

(4:16) 0x0100 NV MEM Address

(4:17) 002000 NV MEM Read Data and Status

(4:18) 0xa000 NV MEM Write Data and Control

(4:19) 0x0000 NV MEM Write Data and Control

(4:20) 0x0000 NV MEM Address

(4:22) 0x0004

(4:29) 0x0004

(4:30) 0x4014

(5:16) 0x0000 VCT MDIO(0) Status

(5:17) 0x0000 VCT MDIO(1) Status

(5:18) 0x0000 VCT MDIO(2) Status

(5:19) 0x0000 VCT MDIO(3) Status

(5:20) 0x0000 VCT Skew

(5:21) 0x0000 VCT Pair Swap & Polarity

(5:22) 0x0005

(5:26) 0x0002 VCT DSP Distance

(5:29) 0x0005

(5:30) 0x4800

(6:16) 0x0000 Packet Generation

(6:17) 0x0000 CRC Checker

(6:22) 0x0006

(6:29) 0x0006

(6:30) 0x8200

After lanconf32 has initialized one interface (e.g. eth0). Dumped with lanconf32, iqvlinux.ko inserted:

(0:0) 0x1940 Copper Control

(0:1) 0x7949 Copper Status

(0:2) 0x0141 PHY Identifier 1

(0:3) 0x0c97 PHY Identifier 2

(0:4) 0x0de1 Copper Auto-Negotiation Adv

(0:5) 0x0000 Copper Link Partner Ability

(0:6) 0x0004 Copper Auto-Negotiation Exp

(0:7) 0x2801 Copper Next Page Transmit

(0:8) 0x0000 Copper Link Partner Next Page

(0:9) 0x0e00 1000BaseT Control

(0:10) 0x4000 1000BaseT Status

(0:15) 0xf000 Extended Status

(0:16) 0x5860 Copper Specific Status 1

(0:17) 0x8050 Copper Specific Status 1

(0:18) 0x0000 Copper Specific Interrupt Enable

(0:19) 0x0040 Copper Specific Status 2

(0:21) 0x0000 Copper Specific Receive Error Counter

(0:26) 0x0040 Copper Specific Control 2

(2:0) 0x1840 MAC Control

(2:16) 0x5968 MAC Specific Control 1

(2:17) 0x0440 MAC Specific Status 1

(2:18) 0x0000 MAC Specific Interrupt Enable

(2:19) 0x0000 MAC Specific Status 2

(2:22) 0x0002

(2:26) 0x0000 MAC Specific Control 2

(2:29) 0x0002

(2:30) 0x2390

(3:1) 0x0000

(3:16) 0x021e LED[1:0] Function Control

(3:17) 0x44a0 LED[1:0] Polarity Control

(3:18) 0x4105 LED Timer Control

(3:22) 0x0003

(3:29) 0x0003

(4:16) 0x0100 NV MEM Address

(4:17) 002000 NV MEM Read Data and Status

(4:18) 0xa000 NV MEM Write Data and Control

(4:19) 0x0000 NV MEM Write Data and Control

(4:20) 0x0000 NV MEM Address

(4:22) 0x0004

(4:29) 0x0004

(4:30) 0x4014

(5:16) 0x0000 VCT MDIO(0) Status

(5:17) 0x0000 VCT MDIO(1) Status

(5:18) 0x0000 VCT MDIO(2) Status

(5:19) 0x0000 VCT MDIO(3) Status

(5:20) 0x0000 VCT Skew

(5:21) 0x0000 VCT Pair Swap & Polarity

(5:22) 0x0005

(5:26) 0x0002 VCT DSP Distance

(5:29) 0x0005

(5:30) 0x4800

(6:16) 0x0000 Packet Generation

(6:17) 0x0000 CRC Checker

(6:22) 0x0006

(6:29) 0x0006

(6:30) 0x8200

Concerning your last request:

"Could you please tell us if the External Phy is doing auto-negotiate or parallel detect in this case?"

Could you please give me a way how to answer this ?

Note: We have the same behavior on:

- Our own CPU board (C2338 + PHY M88E1112)

- a RCC-VE board ( C2358 + PHY M88E1543 )

Kind regards,

Patrick Agrain

CarlosAM_INTEL · ‎07-08-2016

Hello PatrickA ,

Thanks for your update.

Our suggestions to use the mentioned to try to reproduce the cited circumstance using one of the listed Operating Systems is because they are the validated ones as is stated on page 2 of the http://www.intel.com/content/dam/www/public/us/en/documents/platform-briefs/atom-c2000-product-family-based-platforms-brief.pdf Platform Brief: The Intel® Atom™ processor C2000 product family .

Due to this fact, could you please verify if this situation persists using any validated Operating System (OS)?

Thanks again for your help to solve this inconvenience.

Best Regards,

Carlos_A.

PAgra · ‎08-26-2016

Hi Carlos,

Just a few words to close this topic.

Guys from Intel Business Portal investigates this and point out that the lanconf32 tool was disabling the link for our platform.

They also give us a workaround:

Use the lanconf32 to re-program the register at offset 0x00 (MAC) from 0x1940 to 0x1140.

After that the link is up again.

Hope it helps.

Regards,

Patrick

PAgra · ‎08-26-2016

Hmm, I think it's the opposite... 0x1140 --> 0x1940... ;-)

CarlosAM_INTEL · ‎08-26-2016

Hello PatrickA .

Thanks for your update that may help other customers.

Best Regards,

Carlos_A .