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/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
