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

Bin Meng bmeng.cn at gmail.com
Wed Feb 12 11:49:14 CET 2020


Hi Wolfgang,

On Wed, Feb 12, 2020 at 1:14 AM Simon Glass <sjg at chromium.org> wrote:
>
> +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

Please suggest whether I should get the above patch applied to fix the
issue you saw on your board.

>
> 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,
Bin


More information about the U-Boot mailing list