Hi Marek, On Fri, May 10, 2019 at 11:44 PM Marek Behun <marek.be...@nic.cz> wrote: > > On Fri, 10 May 2019 10:15:25 +0200 > Stefan Roese <s...@denx.de> wrote: > > > On 10.05.19 04:56, Marek Behún wrote: > > > The local device (host "bridge"?) on pci_mvebu controller reports > > > PCI_CLASS_MEMORY_OTHER in the class register. > > > > > > This does not work in U-Boot, because U-Boot then tries to autoconfigure > > > this device in pci_auto.c. This causes the real connected PCIe device > > > not to work (in U-Boot nor in Linux). > > > > What exactly does not work or is the issue here with the current > > implementation in Linux? I'm asking, since we have not noticed any > > issues here? > > > ath10k firmware fails to load for network device. > SATA device timeouts on a PCIe SATA expander. > As if some PCIe I/O did not work. The devices are still enumerated and > recognized by Linux, but simply won't work. Nor in U-Boot.
Is there a PCIe bridge involved in either of these? In the pre-history of Kirkwood (which I believe has the same or similar IP block for PCIe) I've hit platforms where the PCIe I/O fails because something about the host bridge interferes with a real bridge on the bus where a directly connected device worked fine. Marvell were shipping a patch that adds a fake PCIe bridge in their LSP and I think that is what was eventually ported to upstream Linux. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
