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

[Oleksij Rempel]

Am 09.04.22 um 10:35 schrieb Frank Wunderlich:
>
>> Gesendet: Samstag, 09. April 2022 um 10:04 Uhr
>> Von: "Oleksij Rempel" <linux at rempel-privat.de>
>> An: frank-w at public-files.de, "Ahmad Fatoum" <a.fatoum at pengutronix.de>
>> Cc: barebox at lists.infradead.org
>> Betreff: Re: change r2pro dts to public hw version (was "Board code with 2 dts" )
>>
>> Am 08.04.22 um 19:19 schrieb Frank Wunderlich:
>>> Am 8. April 2022 19:00:03 MESZ schrieb Oleksij Rempel <linux at rempel-privat.de>:
>>>> Hi Frank
>>>>
>>>> Am 08.04.22 um 13:03 schrieb Frank Wunderlich:
...
>>> Thanks for first lookup.
>>>
>>> Imho delays are read here,so source supports these properties:
>>>
>>> https://git.pengutronix.de/cgit/barebox/tree/drivers/net/designware_rockchip.c#n272
>>
>> ack
>>
>>> And default values are different too. Have not compared source with linux,but there it works with this values....
>>> If understand you right,the rgmii should be possible with the delays.
>>
>> rgmii can't work properly without correctly configured delays.
>> IMO, the best way is to disable delays on the MAC side and let configure proper delays by PHY, by
>> setting phy-mode = "rgmii-id"
>
> tried this but same result
>
> +++ b/arch/arm/dts/rk3568-bpi-r2-pro.dts
> @@ -165,8 +165,8 @@
>          /* Reset time is 20ms, 100ms for rtl8211f */
>          snps,reset-delays-us = <0 20000 100000>;
>
> -       tx_delay = <0x3c>;
> -       rx_delay = <0x2f>;
> +       //tx_delay = <0x3c>;
> +       //rx_delay = <0x2f>;

In this case driver will set some default values:
priv->tx_delay = 0x30;
priv->rx_delay = 0x10;

No idea what this values mean.

>          status = "okay";
>   };
> @@ -400,6 +400,7 @@
>          rgmii_phy1: ethernet-phy at 0 {
>                  compatible = "ethernet-phy-ieee802.3-c22";
>                  reg = <0x0>;
> +               phy-mode = "rgmii-id";
>          };
>   };
>
> barebox at BPI R2PRO:/ dhcp eth1
> eth1: 1000Mbps full duplex link detected
> WARNING: eth1: No MAC address set. Using random address 72:a4:02:4a:e9:38
> T T T T T T T T T T eth1: link down
> eth1: 1000Mbps full duplex link detected
> T T T T T T T T T T dhcp: Connection timed out
>
> also tried to set the phy-mode on gmac instead of phy
>
>          phy-handle = <&rgmii_phy1>;
> -       phy-mode = "rgmii";
> +       phy-mode = "rgmii-id";
>          pinctrl-names = "default";
>
> same result ;(

Except of clk delay, there can be wrong clk direction and/or frequency. Or pinctrl, or clk driver issue.

>>>
>>> Is there any way to debug this (or try different values)? Just to get which value is wrong.
>>
>> By this way of testing, you will get range of values which would work good enough with some random
>> packet drops. It is better to measure it.
>
> if i get it working this way, how to read out the delays?

in this case I would try to do a register dump

>>> The only way i'm thinking about is creating different dtbs and loading then for testing from uboot. But which values to try...i don't know which direction is broken and can try only some "random" values.
>>
>> 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 hope this is not the problem that i load barebox from uboot.
>>> regards Frank
>>
>> u-boot can affect inital configuration. Most drivers are developed with clean HW in mind, not
>> preconfigured by other system. In the best case, the driver will do some kind of soft reset.
>
> currently uboot does not support rk3568 ethernet, so i guess it should not affect.

--
Regards,
Oleksij