change r2pro dts to public hw version (was "Board code with 2 dts" )

[Frank Wunderlich]

Am 10. April 2022 09:41:06 MESZ schrieb Oleksij Rempel <linux at rempel-privat.de>:

>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.

So i need to disable the delay-configuration and set rgmii-id. Do i need to set only on mac or on the phy too?

https://git.pengutronix.de/cgit/barebox/tree/drivers/net/designware_rockchip.c#n117

Set flags to RK3568_GMAC_{R,T}XCLK_DLY_DISABLE and disable second regmap write. Board has a realtek phy which is defined in dts only with this:

&mdio1 {	
rgmii_phy1: ethernet-phy at 0 {	
	compatible = "ethernet-phy-ieee802.3-c22";	
  reg = <0x0>;
	};
};

https://github.com/frank-w/barebox-r2pro/blob/b13021268148954a59682620ab284054b25448e4/arch/arm/dts/rk3568-bpi-r2-pro.dts#L373

Can i check if the phy is recognized on mdio-bus and initialized? I see it in the devlist,but not sure if this means that it is completely initialized.

>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

I more guess something like the last 2 is the problem as the delay-settings work in linux. But have not completely understood all parts. Imho pinmux is done on usage. So if i use

pinctrl-0 = <&gmac1m1_miim 		 &gmac1m1_tx_bus2 		 &gmac1m1_rx_bus2 		 &gmac1m1_rgmii_clk 		 &gmac1m1_rgmii_bus>;

The pinmux should be set,or am i wrong?

https://github.com/frank-w/barebox-r2pro/blob/b13021268148954a59682620ab284054b25448e4/arch/arm/dts/rk3568-pinctrl.dtsi#L705

Afaik gmac1 uses fixed 125MHz clock (it came from cru like gmac0) as clock_in_out is set to output.

assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&cru CLK_MAC1_2TOP>;

I basicly use the config from linux,which i had mostly taken from vendors repo.

As the first version (used the other gmac for wan-port) worked,i guess the phy and mac driver is right. Same for clock driver and constant values.

>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.

I have none and if i'm not sure if i can trace it right because it's decades ago i made something with one.

So i search ways to check it in software as far as possible. Maybe there are ways to read out registers to check if phy is available and compare values with linux.

regards Frank