> Date: Tue, 25 Jun 2024 10:29:48 +0200 > From: Jonas Karlman <jo...@kwiboo.se>
Hi Jonas, > Hi Etienne, > > On 2024-06-25 08:47, Etienne Dublé wrote: > > Hi Quentin, > > > > Le 24/06/2024 à 15:15, Quentin Schulz a écrit : > >> Hi Etienne, > >> > >> On 6/24/24 2:40 PM, ETIENNE DUBLE wrote: > >>> One of the PCI ranges was wrong in this device tree. > >>> When testing with a FriendlyElec Nanopi R5C board, the > >>> 2nd ethernet interface (labelled "wan") was not working > >>> in u-boot because of that. > >>> > >>> With the correct value (found in FriendlyElec's downstream > >>> u-boot repository), this 2nd ethernet interface now works. > >>> > >>> Signed-off-by: Etienne Dublé <etienne.du...@imag.fr> > >>> --- > >>> > >>> dts/upstream/src/arm64/rockchip/rk3568.dtsi | 2 +- > >> > >> dts/upstream is only for patches coming from **merged** Linux kernel > >> (i.e. releases or -rc releases or master branch from Linus Torvalds). > >> > >> We do not accept U-Boot-only patches in dts/upstream. > >> > >> Please submit the patch to the Linux kernel first and it will > >> eventually make it to that directory either via a > >> dts/update-dts-subtree.sh pull or dts/update-dts-subtree.sh pick. > >> Depending on maintainer's opinion, fixing the range in > >> arch/arm/dts/rk3568-u-boot.dtsi could be an option, but we really need > >> the patch sent to upstream Linux kernel community first. > >> > >> c.f. https://www.kernel.org/doc/html/v6.5/process/submitting-patches.html > > > > I see, I will look at it. > > In version 2 of the series I will remove this second patch and just > > mention that we are waiting for this problem to be fixed upstream, in > > the cover letter. > > 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. I do see similar issues on OpenBSD, where some configurations of the outbound address translation windows work fine and others don't. It does seem to depend on the PCIe device, but the only configuration that seems to work for everything is when the translation of the mmio windows is 1:1. So for OpenBSD we build U-Boot with a pacthed device tree. The downside of using a 1:1 translation for mmio is that this reduces the size of the 32-bit PCI mmio address space. Now I can't rule out that there are bugs in the OpenBSD driver for the RK3568 PCIe controller, but the driver seems to work fine on other PCIe controllers derived from the Synopsis DesignWare stuff. Etienne's diff isn't using 1:1 translation though. It just makes sure the lower 32 bits of the address are translated 1:1. I'll see if I can retest OpenBSD with such a setup. > 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. > > Regards, > Jonas > > > > > Cheers, > > Etienne > > > >
