[PATCH v2 00/26] dm: Change the way sequence numbers are implemented

Simon Glass sjg at chromium.org
Tue Dec 15 17:50:46 CET 2020


Hi Michael,

On Tue, 15 Dec 2020 at 01:58, Michael Walle <michael at walle.cc> wrote:
>
> Hi Simon,
>
> Am 2020-12-15 05:28, schrieb Simon Glass:
> > On Sat, 12 Dec 2020 at 11:38, Simon Glass <sjg at chromium.org> wrote:
> >> On Sat, 12 Dec 2020 at 10:53, Michael Walle <michael at walle.cc> wrote:
> >> > Am 2020-12-12 16:39, schrieb Simon Glass:
> >> > >> Sequence numbers looks good, but PCI still doesnt work on my board.
> >> > >
> >> > > Thanks for trying this out.
> >> > >
> >> > > I suppose you have a different problem from what I found in v1. Can
> >> > > you please send the output of these things before and after the
> >> > > change?
> >> > >
> >> > > dm tree
> >> > > dm uc
> >> > > pci
> >> > > pci 1
> >> > > (e.g. for other buses)
> >> > > pci 0 long
> >> >
> >> [..]
> >>
> >> >
> >> > > Which board is it? I suppose there is a chance I have one.
> >> >
> >> > Kontron SMARC-sAL28 (kontron_sl28 defconfig) (a LS1028A SoC)
> >>
> >> Thanks for the info. I was worried that the renumbering might cause
> >> problems but saw no issues on my x86 board.
> >>
> >> If you look at the sequence numbers for PCI they have changed. They
> >> also correspond to the bus numbers, and PCI uses the sub bus number to
> >> route access to sub bus, so I suspect one of your buses is not getting
> >> traffic.
> >>
> >> At present the only fix is to add all buses into the DT. I'll take a
> >> look and see what else I can do.
> >
> > I've pushed an experimental tree to u-boot-dm/seq3-working
> >
> > Are you able to take a look and send the same output as last time?
>
> While it seems to work better now; this looks strange
>
>    PCIe0: pcie at 3400000 Root Complex: no link
>    PCIe1: pcie at 3500000 Root Complex: x1 gen1
>    PCIe0: pcie at 3400000 Root Complex: no link
>    PCIe1: pcie at 3500000 Root Complex: x1 gen1

>From what I can tell, ls_pcie_probe() is being called twice for each PCIe bus.

This can normally only happen if, when probing a device, the uclass
/child pre/post--probe itself probes the same device.

But I'm not sure what has changed about the PCI init sequence to cause this.

>
> > I am trying to change how PCI allocation happens, so that it follows
> > the PCI rules. Hopefully the change makes sense to you but I would
> > appreciate any insights you may have.
>
> Sorry I haven't found time to look into this, yet.

[..]

Regards,
Simon


More information about the U-Boot mailing list