[PATCH v2 6/7] configs: rockchip: Enable ethernet driver on RK356x boards

[Diederik de Haas]

Hi Jonas,

On Mon Apr 7, 2025 at 12:31 AM CEST, Jonas Karlman wrote:
> On 2025-04-06 22:09, Diederik de Haas wrote:
>> On Thu Jul 11, 2024 at 9:38 PM CEST, Diederik de Haas wrote:
>>> Some time ago I reported to Jonas privately that I had a problem with
>>> my Quartz64 Model A and B and that I bisected it to this commit.
>>> I just verified that the problem is still present in 2024.07, so I
>>> guess it's time to report it to the (right) Mailing List.
>>>
>>> The problem: packet loss, varying, but sometimes massive
>>> Q64-A: The packet loss was usually between 8% and 30%
>>> Q64-B: Packet loss up to 80% sometimes and this also resulted (then) in
>>> its inability to receive a DHCP address.
>> 
>> I just build a ~2025.04-rc5 (i.e. 'master') version and tried it on my
>> Q64-B and the problem is still there.
>> Furthermore, there have now been several ppl on #quartz64 IRC channel
>> (on Pine64 IRC network) who have confirmed both the problem and the
>> 'solution'/workaround. Hopefully they'll also report here themselves.
>
> I did a quick test on my Q64-A and can confirm it sometime behaves
> strange when Ethernet has been initialized in U-Boot.
>
> At times my iperf3 test report ~0-1 Mbits/sec instead of the more normal
> ~941 Mbits/sec. After one (or more) "ifconfig eth0 down/up" cycle
> everything seemed to work okay again. However after one (or more) eth0
> down/up cycle the retries was no longer 0 and speed could instead be
> ~0-1 Mbits/sec.
>
> I will see if I can replicate this on other rk3566 boards beside Q64.
>
> Can you please try one or more "ifconfig eth0 down/up" cycle and see if
> that improves your packet loss issue?

I used ``ifdown end0`` and ``ifup end0``, but also with more direct
``ip`` calls and whether it *appears* to work, seems rather random.
I've noticed that ``ping -c50 <ip-address>`` is a reliable way to show
the problem. Often I'm in the 90-95%+ packet loss range, but I've had 1
time where it was 'only' 74%. But which packet number succeeds? I have
not found a way to predict that. If that happens to be packet nr 1, 2 or
3, that may give the *impression* that it (~) works.
That's also basically a requirement for DHCP to work ...

What was interesting is that network 'topology' may be a factor?
Most of my tests were ``ping -c50 192.168.2.1`` ie to my router, which
is also my (caching) DNS server and DHCP server (normally; I switched to
a static address for these tests).
I assumed that was the most basic test possible.
But 'technically' the route is Q64-B -> switch (192.168.2.5) -> router.
And when I did the ping from my PC, which is also connected to the
switch, the ping results were a bit better. Still bad (ie the 74% packet
loss), but not in the usual 95-100% I got with Q64-B -> router ping.

I have no idea (at all) if this could be relevant or this was just
another random score. When I use the 'fixed' U-Boot, packet loss is
consistently 0%, so I'm quite sure neither my switch or router could be
problematic. I have never noticed any networking problems (although
technically I'd only look when I notice an issue). Only with those Q64's
and an U-Boot with this commit in it.

Cheers,
  Diederik

> Regards,
> Jonas
>
>> 
>>> And the fix in my case has always been easy:
>>>
>>> diff --git a/configs/quartz64-a-rk3566_defconfig b/configs/quartz64-a-rk3566_defconfig
>>> index 1ea8e0f40cc..641452f9162 100644
>>> --- a/configs/quartz64-a-rk3566_defconfig
>>> +++ b/configs/quartz64-a-rk3566_defconfig
>>> @@ -67,9 +67,6 @@ CONFIG_SPI_FLASH_SFDP_SUPPORT=y
>>>  CONFIG_SPI_FLASH_GIGADEVICE=y
>>>  CONFIG_SPI_FLASH_MACRONIX=y
>>>  CONFIG_SPI_FLASH_WINBOND=y
>>> -CONFIG_PHY_MOTORCOMM=y
>>> -CONFIG_DWC_ETH_QOS=y
>>> -CONFIG_DWC_ETH_QOS_ROCKCHIP=y
>>>  CONFIG_NVME_PCI=y
>>>  CONFIG_PCIE_DW_ROCKCHIP=y
>>>  CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>>> diff --git a/configs/quartz64-b-rk3566_defconfig b/configs/quartz64-b-rk3566_defconfig
>>> index f61b2c181a1..aae5d66edeb 100644
>>> --- a/configs/quartz64-b-rk3566_defconfig
>>> +++ b/configs/quartz64-b-rk3566_defconfig
>>> @@ -65,9 +65,6 @@ CONFIG_SPI_FLASH_SFDP_SUPPORT=y
>>>  CONFIG_SPI_FLASH_GIGADEVICE=y
>>>  CONFIG_SPI_FLASH_MACRONIX=y
>>>  CONFIG_SPI_FLASH_WINBOND=y
>>> -CONFIG_PHY_REALTEK=y
>>> -CONFIG_DWC_ETH_QOS=y
>>> -CONFIG_DWC_ETH_QOS_ROCKCHIP=y
>>>  CONFIG_NVME_PCI=y
>>>  CONFIG_PCIE_DW_ROCKCHIP=y
>>>  CONFIG_PHY_ROCKCHIP_INNO_USB2=y
>>>
>>> IOW: a (partial) revert of commit 25f56459aebc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250407/8e7fcb81/attachment.sig>