Am 09.04.22 um 19:08 schrieb Trent Piepho:
On Sat, Apr 9, 2022 at 9:02 AM Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote:>
In this case driver will set some default values:
priv->tx_delay = used cd;
priv->rx_delay = 0x10;
No idea what this values mean.
They are supposed to be delays in picoseconds, but sometimes driver
authors are lazy and just use whatever goes into their device's
registers. That creates a dts binding that only works for one
specific device.
According to RGMII 2.0 specification, delay should be 2.8 nanosecond or 2800 picoseconds. None of
used raw values fits to the specified range.
I would suggest to take an oscilloscope and measure rgmii clk and data lines. Make sure it is using
correct frequency and the clock skew (delay between clk and data)
have no oscilloscope here as i'm a private person and do this as hobby
i have private oscilloscope, no idea what to answer :)
I also have a scope, but mine does not do picoseconds! Those are expensive.
What you can do, is just write a test program that goes through every
delay value and measures how many packets it was able to send or
receive. The success rate will probably look something like this:
0% 0% 5% 99% 100% 100% 100% 100% 99% 0% 0%
If the first value is for delay = 0 and they go up by 1 , then
probably delay = 5 or 6 is the best value to use.
Normally we use phy-mode with predefined values:
- rgmii == tx/rx delay is 0
- rgmii-id == PHY configures tx and rx delays to closest possible values to 2.8ns
- rgmii-txid == PHY configures only tx delay to 2.8ns, rx is 0
- rgmii-rxid == same as rgmii-txid but for rx.
Using raw values or fine tuning this delays makes no sense in 99% cases.
Since the PHY and the driver, used on this boards, supports internal delay configuration, it makes
no sense to spend any time on this kind of investigation for this or any other board. All embedded
boards would work with "rgmii-id" and no delay on the MAC side. Which should be default MAC
configuration without additional device tree properties, except of buggy driver or MACs with
integrated not configurable delays, or boards with insanely long traces for rgmii clk.
As I already said, except of delays there can be other issue. For example:
- incorrect pinmux configuration
- incorrect RGMII clock source configuration
- incorrect MAC or PHY mode configuration (xMII instead of RGMII)
- incorrect reset or power up sequence affecting proper bootstrap configuration.
- incorrect MDIO configuration, for example CLK rate outside of range supported by the PHY.
- not properly configured SoCs internal clock dependencies.
- some missing "enable" bit on the PHY or the MAC side
Even if you don't like the fact, that for most of this cases, scope will reduce dramatically
investigation time. I'll need to repeat it, it will help to use the scope.
--
Regards,
Oleksij
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
