[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