On 7/8/2021 19:43, Chris Johns wrote:
On 9/7/21 7:32 am, Kinsey Moore wrote:
On 7/8/2021 10:36, Kinsey Moore wrote:
The solutions to the remainder of the problem are:
1) Use a different, smarter PHY driver and avoid use of ukphy when multiple
interfaces are present
** This could possibly solve the general problem for ethernet interfaces and
replace the ukphy driver for new multi-interface hardware
** Lets nexus-devices.h contain all interfaces that exist on the hardware,
possibly applicable to Zynq7000 and versal as well
The problem here is some PHYs are covered by NDAs and a PHY that uses just the
IEEE defined registers, ie UKPHY, is a good solution for a number of cases.
I do not think the PHY drivers are the issue here.
Now that I've had time to identify the root cause of the spurious PHY
detections, I agree. I thought I had seen the PHY presence detection
code in ukphy when it was actually in mii.c.
4) Embed FDT somewhere that defines what interfaces get configured
** Pulls in extra dependencies
** Doesn't solve the test issue without generation/embedding of a FDT
** Allows the application to have exactly what it wants via a relatively
standard mechanism
** Lets nexus-devices.h contain all interfaces that exist on the hardware,
possibly applicable to Zynq7000 and versal as well
I wonder if it is worth considering how a user would add and remove interfaces
using this approach before we head down this path?
Eventually having this path as an option would be nice, but I don't
think that it should be required and thus is a non-starter for basic
functionality.
I'm starting to lean toward option #1. It allows all interfaces to be defined
and the primary interface for testing can be selected by the existing test
configuration in config.inc. Applications can check the available interfaces
for connectivity or they can prune the nexus devices in their own copy instead
of pulling in nexus-devices.h.
I looked a little further into what it would take to make a smarter version of
ukphy and ukphy isn't actually the issue here. The code in mii.c that detects
whether a PHY exists at all has a bug in it where PHY read timeouts aren't
detected and handled and so the 0xffffffff result of the failed read slips
through the bad-PHY check. I'm working up and verifying the patch for that now.
Fixing that should hopefully allow for all interfaces to be enabled without
issue.
The mii.c only comes into play when the probe passes and we are attaching the
device.
I was thinking of a MII probe call ...
#if __rtems__
int mii_probe()
{
for (phy = 0; phy < 31; phy++) {
WR4(sc, CGEM_PHY_MAINT,
CGEM_PHY_MAINT_CLAUSE_22 | CGEM_PHY_MAINT_MUST_10 |
CGEM_PHY_MAINT_OP_READ |
(phy << CGEM_PHY_MAINT_PHY_ADDR_SHIFT) |
(reg << CGEM_PHY_MAINT_REG_ADDR_SHIFT));
/* Wait for completion. */
tries=0;
for (tries = 0; tries < 5; ++tries) {
if ((RD4(sc, CGEM_NET_STAT) & CGEM_NET_STAT_PHY_MGMT_IDLE) != 0) {
return OK;
}
DELAY(2);
}
}
return NOT_FOUND;
}
#endif
This only works if the MAC can be accessed this early in a boot and dos not need
anything else to be enabled. Maybe the enables are easy as well, I have not
looked.
For an interface with no PHY and not being used the MII probe delay is 192msec
which I think is just OK, maybe (??), but more than I would like.
I have a patch set just about ready that resolves the test configuration
leakage, resolves the issue in mii.c that's causing spurious PHY
detection (and the interfaces with no PHYs go away because they fail to
attach), and resolves another bug with the default network test
configuration exposed by having multiple interfaces with the functional
one being later in the sequence. Only the functional interface(s) appear
in the output of ifconfig.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
