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

[Jonas Karlman]

Hello Etienne,

On 2024-06-25 12:12, Etienne Dublé wrote:
> 
> 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.

Ahh, linux is still missing a patch to be able to use full address ranges
as a root complex.

Will re-run some tests on my R5C on both u-boot and linux to see if I can
replicate your issue.

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

The issue may be that U-Boot is not fully capable of having overlapping
bus addresses for multiple pci controllers.

To my knowledge these addresses should be internal to the pci controller
and its devices.

The addresses below tells us that system memory address 0x340000000+,
and 0x380000000+ is mapped to bus address 0x40000000+ of each pci
controller.

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

The bus addresses should be isolated to each pci controller if I am not
mistaken, so changing the bus address was probably just done as a
workaround because of some other unknown bug.

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

Hum, could be an issue in pci core of U-Boot that expect unique bus
addresses across all pci controllers.

Will run some quick tests on my R5C later.

Regards,
Jonas

> 
> Cheers,
> Etienne
>