dm: core: Board failing to boot since commit 82de42fa1468 (parent data/probe)

[Simon Glass]

+Bin

Hi Wolfgang,

On Tue, 11 Feb 2020 at 06:59, Wolfgang Wallner
<wolfgang.wallner at br-automation.com> wrote:
>
> Hello Simon,
>
> Since commit 82de42fa1468 ("dm: core: Allocate parent data separate from
> probing parent") I have trouble booting my board (a custom Apollo Lake design
> booted via Coreboot + U-Boot).
>
> I think this is because the function ns16550_serial_ofdata_to_platdata() of
> the UART driver noew tries to access the PCI bus before it is probed.
> I'm aware of the comment which you have added to pci-uclass.c [1].
>
> So the correct way to fix this would be to adapt the uart driver in ns16550.c?

Why is the UART being used so early? Also, if you are booting from
coreboot you really shouldn't need to auto-config PCI at all, so
perhaps just disable CONFIG_PCI_PNP? But I understand that that
changes the build.

The way I fixed it is to allow the UART to stay at a fixed PCI address:

9e11293319 dm: pci: Allow disabling auto-config for a device

That's in u-boot-dm/coral-working

>
> regards, Wolfgang
>
> Detail information:
>
> As far as I understand the situation the following things happen:
>  * My debug UART is probed
>  * This triggers a call to ns16550_serial_ofdata_to_platdata()
>  * This function tries to read BAR0 from the PCI devices
>  * Reading BAR0 returns 0xffffffff, as the PCI bus has not been probed yet
>  * The serial driver tries to read from a non-existing register based on this
>    invalid BAR0 value and hangs indefinitely.
>
> This is confirmed by the warning which you have introduced a few commits ealier
> in commit 4886287ee4f9 ("pci: Print a warning if the bus is accessed before
> probing"):
>
>   "dm_pci_get_bdf() PCI: Device 'uart at 18,2' on unprobed bus 'pci'"
>
> [1] "A common cause of this problem is that this function is called in the
> ofdata_to_platdata() method of @dev. Accessing the PCI bus in that
> method is not allowed, since it has not yet been probed. To fix this,
> move that access to the probe() method of @dev instead."

Regards,
Simon