Hi Pali, On Mon, Nov 8, 2021 at 2:02 PM Pali Rohár <p...@kernel.org> wrote: > > On Monday 08 November 2021 12:54:39 Tony Dinh wrote: > > On Mon, Nov 8, 2021 at 3:11 AM Pali Rohár <p...@kernel.org> wrote: > > > On Sunday 07 November 2021 18:08:56 Tony Dinh wrote: > ... > > > > > I think some more investigation is needed. Why did we need to do "pci > > > > > enum", and then "usb reset", in that order, to get the PCI bus and the > > > > > XHCI controller probed? there must be something missing in the process > > > > > somewhere between the Device uclass, the PCI uclass, and the pci_mvebu > > > > > uclass? > > > > > > > > I think I can see the order of enumeration. PCI must be enumerated > > > > first, and then XHCI being the controller on this host bus would come > > > > alive? I think we can live with 'pci enum' and 'usb reset' to get the > > > > USB 3.0 drives enumerated. However, it seems just a little bit > > > > unintuitive. > > > > > > 'pci enum' should be called internally by U-Boot during loading. So only > > > 'usb start' would be needed. > > > > > > But from your boot log it looks like that PCI enumaration was not done > > > and so calling 'pci enum' manually is needed. > > > > > > I will look into U-Boot code why it happens... > > Ok. Command 'pci enum' is just calling pci_init() function. > > So to avoid calling 'pci enum' manually, you need to put pci_init(); > function call into your board board_early_init_r() function.
Thanks! will do that. > Which files in board/** are you using for your Kirkwood board? I do not > see any 6281 in board/Marvell/*. This Pogoplug V4 board is still out-of-tree. I have not submitted patches to add support for it. I plan to do that in the near future, and it will be under board/cloudengines/. However, there is a show stopper right now that prevents me from going ahead to add this Pogoplug V4 board. A previous fdt patch has not been accepted, because Simon wanted this to be implemented with livetree calls: https://lists.denx.de/pipermail/u-boot/2021-August/457311.html It is working fine as a flat tree implementation. The other 2 Kirkwood boards that could be useful in PCIe testing are the Iomega iConnect (in mainline at board/iomega/iconnect/), and the Zyxel NAS325 (still out-of-tree). I am also stuck on this NAS325 board because of the fdt_support flattree vs. livetree implementation. Thanks, Tony > > > Anyway, based on your test, PCIe must work correctly :) > > > > Indeed, it's working perfectly :) I've also commented out the 2 calls > > to mvebu_mbus_add_window_by_id(), and no longer see the conflicts > > error. > > Perfect! > > > > > - if (mvebu_mbus_add_window_by_id(pcie->mem_target, pcie->mem_attr, > > - (phys_addr_t)pcie->mem.start, > > - PCIE_MEM_SIZE)) { > > > > - if (mvebu_mbus_add_window_by_id(pcie->io_target, pcie->io_attr, > > - (phys_addr_t)pcie->io.start, > > - MBUS_PCI_IO_SIZE)) { > > > > > > > Could you send config space dump of PCIe Root Port? Following U-Boot > > > command prints it on terminal: 'pci display.b 0.0.0 0 200' > > > > Sure, here is the log with the dump. > > Thanks! Checked and seems to be correct.