Testing pci_mvebu.c with Kirkwood SoCs

[Tony Dinh]

Hi Pali,

On Mon, Nov 8, 2021 at 2:02 PM Pali Rohár <pali at 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 <pali at 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.