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@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@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...), 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