Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-06 Thread Oleksandr Tymoshenko 
Peter Jeremy (pe...@rulingia.com) wrote:
> On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko  wrote:
> >Could you try kernel with this patch? It's mostly debug output,
> >with one possible clock-related fix.
> >
> >https://people.freebsd.org/~gonzo/patches/rk3328-gmac-debug.patch
> 
> It's still not working for me.  I get the following:
> dwc0:  mem 0xff54-0xff54 irq 44 
> on ofwbus0
> setting RK3328 RX/TX delays:  24/36
> >>> RK3328_GRF_MAC_CON1 (0413):
> >>> gmac2io_gmii_clk_sel: 0x0
> >>> gmac2io_rmii_extclk_sel: 0x1
> >>> gmac2io_rmii_mode: 0x0
> >>> gmac2io_rmii_clk_sel: 0x0
> >>> gmac2io_phy_intf_sel: 0x1
> >>> gmac2io_flowctrl: 0x0
> >>> gmac2io_rxclk_dly_ena: 0x1
> >>> gmac2io_txclk_dly_ena: 0x1
> >>> RK3328_GRF_MAC_CON0 (0c24):
> miibus0:  on dwc0
> rgephy0:  PHY 0 on miibus0
> rgephy0: OUI 0x00e04c, model 0x0011, rev. 6
> rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto

Thanks for running the test. Register values seem OK :(
 
> >I have Rock64 v2, which, as you mentioned, has a known issue with GigE, so
> >my tests are not reliable. I'll try to get another RK3328 board for tests,
> >but it may take some time.
> 
> I've asked on -arm if anyone else has tried this on a Rock64 v2 or v3.
> 
> >If the clock fix doesn't help, I'll make
> >delays configuration run-time configurable with off by default until
> >more hardware is tested.
> 
> That sounds like a good way forward - maybe boot and run-time configurable.
> It's a pity that there doesn't seem to be any documentation on what the
> numbers represent (or what the "default" value is) - which means that
> actually adjusting the delay numbers would be very time consuming.

There are no "default" values AFAIK. They depend on the board schematics.
I was told that Rockhip partners use some kind of proprietary tool
which they feed with values based on the scematics (like trace lengths)
and tool calculates delays.

With boot-time or run-time configuration I think it's possible to
automate the search for good value. Something like this:
https://github.com/ayufan-rock64/linux-build/blob/master/recipes/gmac-delays-test/range-test

but with loader.conf modifications instead of DTB

-- 
gonzo
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-04 Thread Peter Jeremy 
On 2020-Jul-02 17:26:23 -0700, Oleksandr Tymoshenko  wrote:
>Could you try kernel with this patch? It's mostly debug output,
>with one possible clock-related fix.
>
>https://people.freebsd.org/~gonzo/patches/rk3328-gmac-debug.patch

It's still not working for me.  I get the following:
dwc0:  mem 0xff54-0xff54 irq 44 
on ofwbus0
setting RK3328 RX/TX delays:  24/36
>>> RK3328_GRF_MAC_CON1 (0413):
>>> gmac2io_gmii_clk_sel: 0x0
>>> gmac2io_rmii_extclk_sel: 0x1
>>> gmac2io_rmii_mode: 0x0
>>> gmac2io_rmii_clk_sel: 0x0
>>> gmac2io_phy_intf_sel: 0x1
>>> gmac2io_flowctrl: 0x0
>>> gmac2io_rxclk_dly_ena: 0x1
>>> gmac2io_txclk_dly_ena: 0x1
>>> RK3328_GRF_MAC_CON0 (0c24):
miibus0:  on dwc0
rgephy0:  PHY 0 on miibus0
rgephy0: OUI 0x00e04c, model 0x0011, rev. 6
rgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 
1000baseT-FDX-master, auto

>I have Rock64 v2, which, as you mentioned, has a known issue with GigE, so
>my tests are not reliable. I'll try to get another RK3328 board for tests,
>but it may take some time.

I've asked on -arm if anyone else has tried this on a Rock64 v2 or v3.

>If the clock fix doesn't help, I'll make
>delays configuration run-time configurable with off by default until
>more hardware is tested.

That sounds like a good way forward - maybe boot and run-time configurable.
It's a pity that there doesn't seem to be any documentation on what the
numbers represent (or what the "default" value is) - which means that
actually adjusting the delay numbers would be very time consuming.

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-02 Thread Oleksandr Tymoshenko 
Peter Jeremy (pe...@rulingia.com) wrote:
> On 2020-Jul-01 18:57:47 +1000, Peter Jeremy  wrote:
> >On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko  
> >wrote:
> >>Log:
> >>  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
> >>  
> >>  For 1000Mb mode to work reliably TX/RX delays need to be configured
> >>  between the TX/RX clock and the respective signals on the PHY
> >>  to compensate for differing trace lengths on the PCB.
> >
> >This breaks (at least) diskless booting on my Rock64.
> 
> I've studied the RK3328 TRM[1] and the RK3328 code following r362736
> matches[2] the GRF_MAC_CON0/1 documentation on p201-203 (though p574
> says the delay line is configured via GRF_SOC_CON3 - which doesn't
> match the documentation on GRF_SOC_CON3 on p175-177).  That suggests
> that the delay values in the FDT are incorrect.  Unfortunately, the
> TRM doesn't include any details on how to configure the delay values
> so it's difficult to adjust the numbers in the FDT.
> 
> One possible explanation I have is that there are (at least) 2
> different Rock64 variants.  Later versions have increased the RGMII
> bus voltage to improve GigE reliability.  I initially had problems
> with GigE reliability and mod'd my Rock64[3] to use the higher RGMII
> bus voltage - which made it rock solid at GigE.  It's possible that
> different variants need different delay values, due to different track
> skew or different driver behaviour at different bus voltages.
> 
> [1] Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf
> [2] There's one typo: RK3328_GRF_MAC_CON0_TX_MASK instead of
> RK3328_GRF_MAC_CON0_RX_MASK but the values are the same).
> [3] Move 1 resistor to change a pull-up to a pull-down

Hi Peter,

Could you try kernel with this patch? It's mostly debug output,
with one possible clock-related fix.

https://people.freebsd.org/~gonzo/patches/rk3328-gmac-debug.patch

I have Rock64 v2, which, as you mentioned, has a known issue with GigE, so
my tests are not reliable. I'll try to get another RK3328 board for tests,
but it may take some time. If the clock fix doesn't help, I'll make
delays configuration run-time configurable with off by default until
more hardware is tested.

-- 
gonzo
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-01 Thread Peter Jeremy 
On 2020-Jul-01 18:57:47 +1000, Peter Jeremy  wrote:
>On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko  wrote:
>>Log:
>>  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
>>  
>>  For 1000Mb mode to work reliably TX/RX delays need to be configured
>>  between the TX/RX clock and the respective signals on the PHY
>>  to compensate for differing trace lengths on the PCB.
>
>This breaks (at least) diskless booting on my Rock64.

I've studied the RK3328 TRM[1] and the RK3328 code following r362736
matches[2] the GRF_MAC_CON0/1 documentation on p201-203 (though p574
says the delay line is configured via GRF_SOC_CON3 - which doesn't
match the documentation on GRF_SOC_CON3 on p175-177).  That suggests
that the delay values in the FDT are incorrect.  Unfortunately, the
TRM doesn't include any details on how to configure the delay values
so it's difficult to adjust the numbers in the FDT.

One possible explanation I have is that there are (at least) 2
different Rock64 variants.  Later versions have increased the RGMII
bus voltage to improve GigE reliability.  I initially had problems
with GigE reliability and mod'd my Rock64[3] to use the higher RGMII
bus voltage - which made it rock solid at GigE.  It's possible that
different variants need different delay values, due to different track
skew or different driver behaviour at different bus voltages.

[1] Rockchip_RK3328TRM_V1.1-Part1-20170321.pdf
[2] There's one typo: RK3328_GRF_MAC_CON0_TX_MASK instead of
RK3328_GRF_MAC_CON0_RX_MASK but the values are the same).
[3] Move 1 resistor to change a pull-up to a pull-down

-- 
Peter Jeremy


signature.asc
Description: PGP signature

Re: svn commit: r362736 - head/sys/arm64/rockchip

2020-07-01 Thread Peter Jeremy 
On 2020-Jun-28 21:11:10 +, Oleksandr Tymoshenko  wrote:
>Log:
>  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
>  
>  For 1000Mb mode to work reliably TX/RX delays need to be configured
>  between the TX/RX clock and the respective signals on the PHY
>  to compensate for differing trace lengths on the PCB.

This breaks (at least) diskless booting on my Rock64.

During boot, I normally see:
regulator: shutting down unused regulators
uhub1: 1 port with 1 removable, self powered
uhub0: 2 ports with 2 removable, self powered
uhub2: 1 port with 1 removable, self powered
uhub3: 1 port with 1 removable, self powered
dwc0: link state changed to DOWN
NFS ROOT: 192.168.12.200:/tank/rock64
dwc0: link state changed to UP
Warning: no time-of-day clock registered, system time will not be set accurately
Warning: no time-of-day clock registered, system time will not be set accurately
start_init: trying /sbin/init

With r362736, I see:
setting RK3328 RX/TX delays:  24/36
...
regulator: shutting down unused regulators
uhub0: 1 port with 1 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub2: 1 port with 1 removable, self powered
uhub1: 1 port with 1 removable, self powered
dwc0: link state changed to DOWN
NFS ROOT: 192.168.12.200:/tank/rock64
dwc0: link state changed to UP
dwc0: link state changed to DOWN
dwc0: link state changed to UP
[Nothing further until I push the reset button]

The system doesn't respond to pings so I suspect the network is dead.
Normally, it runs 1000baseT .

-- 
Peter Jeremy


signature.asc
Description: PGP signature

svn commit: r362736 - head/sys/arm64/rockchip

2020-06-28 Thread Oleksandr Tymoshenko 
Author: gonzo
Date: Sun Jun 28 21:11:10 2020
New Revision: 362736
URL: https://svnweb.freebsd.org/changeset/base/362736

Log:
  Configure rx_delay/tx_delay values for RK3399/RK3328 GMAC
  
  For 1000Mb mode to work reliably TX/RX delays need to be configured
  between the TX/RX clock and the respective signals on the PHY
  to compensate for differing trace lengths on the PCB.
  
  Reviewed by:  manu
  MFC after:1 week

Modified:
  head/sys/arm64/rockchip/if_dwc_rk.c

Modified: head/sys/arm64/rockchip/if_dwc_rk.c
==
--- head/sys/arm64/rockchip/if_dwc_rk.c Sun Jun 28 18:56:32 2020
(r362735)
+++ head/sys/arm64/rockchip/if_dwc_rk.c Sun Jun 28 21:11:10 2020
(r362736)
@@ -57,6 +57,8 @@ __FBSDID("$FreeBSD$");
 #define RK3328_GRF_MAC_CON0_RX_SHIFT   7
 
 #defineRK3328_GRF_MAC_CON1 0x0904
+#define RK3328_GRF_MAC_CON1_RX_ENA (1 << 1)
+#define RK3328_GRF_MAC_CON1_TX_ENA (1 << 0)
 #defineRK3328_GRF_MAC_CON2 0x0908
 #defineRK3328_GRF_MACPHY_CON0  0x0B00
 #defineRK3328_GRF_MACPHY_CON1  0x0B04
@@ -71,7 +73,6 @@ static struct ofw_compat_data compat_data[] = {
{NULL,   0}
 };
 
-#ifdef notyet
 static void
 rk3328_set_delays(struct syscon *grf, phandle_t node)
 {
@@ -82,22 +83,26 @@ rk3328_set_delays(struct syscon *grf, phandle_t node)
if (OF_getencprop(node, "rx_delay", , sizeof(rx)) <= 0)
rx = 0x10;
 
+   if (bootverbose)
+   printf("setting RK3328 RX/TX delays:  %d/%d\n", rx, tx);
tx = ((tx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_TX_SHIFT);
rx = ((rx & RK3328_GRF_MAC_CON0_TX_MASK) <<
RK3328_GRF_MAC_CON0_RX_SHIFT);
 
SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON0, tx | rx | 0x);
+   SYSCON_WRITE_4(grf, RK3328_GRF_MAC_CON1, RK3328_GRF_MAC_CON1_TX_ENA | 
RK3328_GRF_MAC_CON1_RX_ENA | 
+   ((RK3328_GRF_MAC_CON1_TX_ENA | RK3328_GRF_MAC_CON1_RX_ENA) << 16));
 }
-#endif
 
 #defineRK3399_GRF_SOC_CON6 0xc218
+#define RK3399_GRF_SOC_CON6_TX_ENA (1 << 7)
 #define RK3399_GRF_SOC_CON6_TX_MASK0x7F
 #define RK3399_GRF_SOC_CON6_TX_SHIFT   0
 #define RK3399_GRF_SOC_CON6_RX_MASK0x7F
+#define RK3399_GRF_SOC_CON6_RX_ENA (1 << 15)
 #define RK3399_GRF_SOC_CON6_RX_SHIFT   8
 
-#ifdef notyet
 static void
 rk3399_set_delays(struct syscon *grf, phandle_t node)
 {
@@ -108,14 +113,15 @@ rk3399_set_delays(struct syscon *grf, phandle_t node)
if (OF_getencprop(node, "rx_delay", , sizeof(rx)) <= 0)
rx = 0x10;
 
+   if (bootverbose)
+   printf("setting RK3399 RX/TX delays:  %d/%d\n", rx, tx);
tx = ((tx & RK3399_GRF_SOC_CON6_TX_MASK) <<
-   RK3399_GRF_SOC_CON6_TX_SHIFT);
+   RK3399_GRF_SOC_CON6_TX_SHIFT) | RK3399_GRF_SOC_CON6_TX_ENA;
rx = ((rx & RK3399_GRF_SOC_CON6_TX_MASK) <<
-   RK3399_GRF_SOC_CON6_RX_SHIFT);
+   RK3399_GRF_SOC_CON6_RX_SHIFT) | RK3399_GRF_SOC_CON6_RX_ENA;
 
SYSCON_WRITE_4(grf, RK3399_GRF_SOC_CON6, tx | rx | 0x);
 }
-#endif
 
 static int
 if_dwc_rk_probe(device_t dev)
@@ -144,12 +150,10 @@ if_dwc_rk_init(device_t dev)
return (ENXIO);
}
 
-#ifdef notyet
if (ofw_bus_is_compatible(dev, "rockchip,rk3399-gmac"))
rk3399_set_delays(grf, node);
else if (ofw_bus_is_compatible(dev, "rockchip,rk3328-gmac"))
rk3328_set_delays(grf, node);
-#endif
 
/* Mode should be set according to dtb property */
 
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"