I’ve noticed in the schematic that the Ethernet PHYs are being reset by PORz (via R39, R96, and R123). This would have been fine if POR were only asserted on a true power-on, but to work around the am572x reset errata it is currently being triggered for every kind of reset.
I know from experience with an earlier SoC with CPSW that resetting the processor while the switch is actively being used is not a problem as long as the switch is quickly reenabled during early initialization. The packet loss that occurs for a fraction of a second generally goes unnoticed.
On the other hand, if the PHYs are reset, then the link partners will receive link down, generally triggering a whole chain of indirect effects. In case of switches you’ll get spanning tree topology updates due to network partitioning. In case of hosts, some applications may close connections in response to the “network down” notification, on link up dhcp needs to be performed again, etc. Recovery takes significant time in this case. Needless to say, this is rather suboptimal.
I see a lot of options for ethernet reset have been included in the design. I hope some "DNI"s can be moved around in the next revision to remedy this situation.
(If an am572x revision becomes available which fixes the reset issues, that would of course also change the landscape.)
This is the way the board is designed. Feel free to swap the resistors and update the code to support the other reset option. Any change in the design as to a “next revision” will break compatibility with the TI EVM and the TI SW. As Jason Kridner is the TI employee here, that is Jason’s decision as to whether or not this is done.
Are you saying the X15 has been cast into stone even before the schematic
was made public, and user feedback will be ignored?
Feel free to swap the resistors and update the code to support the other
reset option. Any change in the design as to a "next revision" will break
compatibility with the TI EVM and the TI SW.
I don't see how it would break any code. For optimal switch behaviour,
software changes still would be needed to bring the switch up early and
keep it from being munged later on, but those happy with the current
situation wouldn't need to change anything.
I was just making a suggestion that in my view would improve the product,
and which appears to be a simple change (install R95 and C219 instead of
R96, and analogous for the other phy). It's possible I'm overlooking
something of course, especially with the complications surrounding reset,
but it is also possible that the impact on ethernet was simply overlooked
when the am572x reset workaround was installed.
What I am saying is that boards are being built as we speak. We are in production on the boards.
Yes the change is simple. I put the circuit in there when I designed the board two years ago. The feature has never been supported in SW. The issues we saw on the BBB due to this issue have not shown up in two years of working with this board. All the pins are tri-stated on power up, unlike on the AM3358.
As long as Jason is OK making the change and breaking the compatibility, I will be happy to create a new revision and make the change you desire when the next production cycle starts.
As I said, this is Jason Kridner’s decision. Feel free to contact him.
What I am saying is that boards are being built as we speak. We are in
production on the boards.
I understand that. I was making the suggestion for a future production run
of course.
Yes the change is simple. I put the circuit in there when I designed the
board two years ago. The feature has never been supported in SW. The issues
we saw on the BBB due to this issue have not shown up in two years of
working with this board. All the pins are tri-stated on power up, unlike on
the AM3358.
Ah, so that's the original reason the option was included in the design.
It is then a fortunate coincidence it can be reused.
As long as Jason is OK making the change and breaking the compatibility
Again, I don't see how any compatibility would be broken. It merely
restores behaviour as it would have been if POR were only triggered on a
true power-on reset. (As a corollary, if a future am572x revision fixes the
reset errata and the external workarounds can be removed then my suggested
change will also become unnecessary.)
Software won't notice the difference, especially not since it currently
soft-resets the PHY at least twice anyway. But software can always be fixed
later on.
As I said, this is Jason Kridner's decision. Feel free to contact him.
Can we discuss the production impacts on Monday? I think our goal is to address community needs. If that means forking from the TI EVM, there are worse things. We also have to respect the costs involved in changes.
My call would be to switch it for the X15 builds to make a Rev A2B,
but make sure to leave the EVM builds untouched (keep shipping A2As
for that). Of course, I don't know that this thread concluded on which
reset signal would be populated, so it would be good to see that.
We will need prototypes built to test the change. Maybe 5-10 depending on how much testing you plan to do.The thread was about removing the current one and going for the one that is not populated.
The current build is for 6,000 boards. I need to see when we could cut this in without causing a delay in production, We will also have to modify the production test procedure and change the test SW to allow us to test this new feature in production. I need ot figure out when I can get to that. It will be a while at best.
I suggest you order the prototypes now to get them modified with this change.
Just checking we're on the same page here... my specific suggestion is:
* remove R96 and R123 to disconnect the PHYs from ENET_PORZ
* install C219 and R95 to provide PHY 0 with an autonomous POR at power-on
* install C234 and R122 to provide PHY 1 with an autonomous POR at power-on
* optionally R39 between PORz and ENET_PORZ can be removed since it would
no longer connect to anything
A simpler alternative that should work fine too would be to remove only
R39, leaving R96 and R123 connected, and connecting one cap and one pull-up
to provide the POR for both PHYs.
My only slight concern is that the example in the PHY datasheet ("Reset
Circuit for triggering by Power Supply") also shows an explicit clamp
diode. Was this deemed unnecessary?
