AM4378: AM4378 not properly working with the ethernet phy

Hi,

There is a section in the TRM on ROM tracing that is used to debug Boot issues, this is section 5.2.12 Tracing. Trace Vector 5 shows if the ROM code is detecting the external PHY, this would also indicate if the correct boot mode was set. This is somewhat involved. More importantly to access these tracing registers will require a JTAG and using Code Composer Studio or similar JTAG based emulator. Does the customer board have a JTAG connector?

But, before going through those steps and since the network is proven out, what bit rate is the PHY set to auto-negotiate to? The TRM section 5.2.7.3.1 describes the operation as being limited to 10/100/ 

Best Regards,

Schuyler

Hey Schuyler,

They are in the process of setting up their JTAG connector.

During one test, they set the link partner (host PC) to 10/100 link, but they think most of the time it was allowing 10/100/1000 links.

Hi,

I have had trouble trying to set link speeds other than what was auto-negotiated. As a quick check I would recommend connecting the custom board using a 10/100 switch if one is available. 

Best Regards,

Schuyler

He is having the same issue with a 10/100 USB adapter

Just as a precaution, are there any strapping pins for the DP83867IS that need to be set? It’s configured so that it immediately comes up for their Linux device tree, but is there anything different that’s needed for the boot ROM?

Hi,

There probably are some strapping that needs to be set on the PHY since the boot ROM only supports 10/100Mbps. I was suggesting to use an 10/100Mbps external switch so the link speed auto-negotiates to 100Mbps as a test to get having to set link speeds. For production the PHY strapping would need to set to only advertise 10/100 speeds. 

I am not following the USB adapter issue being described here.

Best Regards,

Schuyler

Hi Schuyler,

They've been testing with a 10/100 USB to Ethernet adapter. And they just wanted to know if there’s something in the strap pins in addition to that.

They have a JTAG probe working. Here’s what they're seeing:

 - The PC never seems to hit the public boot ROM (0x40030000)

• PC seems to be looping over somewhere in the 0x000347fe region
  • 0x000347fe is hit over and over
  • 0x0003487c is where the PC jumps
• They don’t have access to the boot ROM source code, so we can’t really debug it from there

This is with a 10/100 USB to Ethernet hooked up to the Ethernet Jack. The link is established at 100Base-Tx, but it is advertising 10/100/1000.

• The CTRL_STS seems to specify SYSBOOT[7:6] as 0b11 for RGMII, but elsewhere it says RGMII is autodetected, which is it?
  • They've been testing with 0b00 and have tried 0b11
• The boot now seems to get stuck in 0x30080 which is an undefined exception handler, not sure why this occurs
• Resetting and manually stepping through the ROM results in triggering the pre-fetch abort exception handler instead, also strange

 After some adjustments, they had an update, with the sysboot pins in 0b11100 just doing EMAC and sysboot 6-7 0b11 they see the following:

 0x37896 is the PC that keeps getting hit

• Manually restarting and stepping through doesn’t seem to work

Boot Tracing Vectory Memory

0x40338E40        0000302E            00000000            04000000            00000000            00000028

Vector 5 shows that the 100Mbps link is detected, but also a GMII PHY? How’s that?

They do see the host search timeout eventually, so nothing real interesting there.

No activity on RGMII pins yet. So, still the same there.

Any suggestions at this point on what to look at?

Hi Schuyler, just following up on this.

Hi Lauren,

One suggestion is for the customer to look at the advisory 25 in the silicon errata. This errata mentions having the PHY not advertise half duplex mode. The next thing is to capture what the PHY is latching the options. To get this data may require changing the boot mode back to SD and stopping in u-boot and running mdio commands to look at what the PHY thinks it is set for.  Another option would be to also remove 1G advertisement as a means to understand how the PHY is coming up.

Best Regards,

Schuyler