[PATCH 2/3] rockchip: fix wrong PCI range address in rk3568 dtsi

Etienne Dublé etienne.duble at imag.fr
Tue Jun 25 12:12:36 CEST 2024


Hello Jonas,

Le 25/06/2024 à 10:29, Jonas Karlman a écrit :
> I do not understand the need for such/this patch. The changed address is
> the internal io address that is shared with the pci controller and
> devices.
>
> Do you have any issue in linux or is it only in U-Boot?, I suspect this
> change is only a workaround to an issue only found in U-Boot.

On my board (Nanopi R5C with two RTL-8125B interfaces) both RTL-8125B 
interfaces work in Linux, and only the first one works in u-boot.
But Linux is apparently using the second PCI region and u-boot is using 
the third (with the suspected address). These PCI regions are of the 
same type.

> The rtl8169 driver or pci system of U-Boot may be of fault and should
> probably be fixed instead of changing io addresses to work around issues
> in software. E.g rtl8169 has a static ioaddr that is shared between all
> drivers, something that may cause issues.

I am not an expert, but I really believe the issue comes from this 
address in the device tree.
We have these pcie entries in rk3568.dtsi:

----
         pcie3x1: pcie at fe270000 {
[...]
                 ranges = <0x01000000 0x0 0xf2100000 0x0 0xf2100000 0x0 
0x00100000>,
                          <0x02000000 0x0 0xf2200000 0x0 0xf2200000 0x0 
0x01e00000>,
                          <0x03000000 *0x0* *0x40000000* 0x3 0x40000000 
0x0 0x40000000>;
[...]
         }
[...]
         pcie3x2: pcie at fe280000 {
[...]
                 ranges = <0x01000000 0x0 0xf0100000 0x0 0xf0100000 0x0 
0x00100000>,
                          <0x02000000 0x0 0xf0200000 0x0 0xf0200000 0x0 
0x01e00000>,
                          <0x03000000 *0x0* *0x40000000* 0x3 0x80000000 
0x0 0x40000000>;
[...]
         }
----

Again, I am not an expert, but it seemed suspicious to me that those two 
entries were sharing the same PCI address.
So I verified in the downstream repository of the board vendor 
(https://github.com/friendlyarm/uboot-rockchip/blob/nanopi5-v2017.09/arch/arm/dts/rk3568.dtsi#L1754C21-L1754C31), 
and the second address there was replaced with "*0x0* *0x80000000*".
Then, updating this was enough to make the second interface work in u-boot.

Like you, I initially suspected the code of rtl8169.c, which has many 
global & static variables, so I actually spent quite a lot of time on 
refactoring it, moving things to the private struct, but could never 
make it work until I found this suspecting PCI address.

Cheers,
Etienne

-- 
Etienne Dublé
CNRS / LIG - Bâtiment IMAG
700 avenue Centrale - 38401 St Martin d'Hères
Bureau 426 - Tel 0457421431



More information about the U-Boot mailing list