modify live DT with OF_LIVE breaking phy_connect?

[Tim Harvey]

On Mon, Oct 14, 2024 at 1:20 PM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Tim,
>
> On Thu, 10 Oct 2024 at 16:05, Tim Harvey <tharvey at gateworks.com> wrote:
> >
> > On Tue, Oct 8, 2024 at 6:56 PM Simon Glass <sjg at chromium.org> wrote:
> > >
> > > Hi Tim,
> > >
> > > On Mon, 7 Oct 2024 at 14:16, Tim Harvey <tharvey at gateworks.com> wrote:
> > > >
> > > > Greetings,
> > > >
> > > > I have a need to adjust the U-Boot device-tree live with some board
> > > > revision specific fixups. It would seem I need to enable OF_LIVE to do
> > > > so but when I do this on imx8mm U-Boot proper seems to fail
> > > > phy_connect() called from the network device probe.
> > > >
> > > > The board I'm working with is an imx8mm-venice board and using
> > > > imx8mm_venice_defconfig (without OF_LIVE) results in:
> > > > U-Boot 2024.10-00735-gc530f6079c70 (Oct 07 2024 - 12:58:38 -0700)
> > > >
> > > > CPU:   Freescale i.MX8MMQ rev1.0 1600 MHz (running at 1200 MHz)
> > > > CPU:   Industrial temperature grade (-40C to 105C) at 44C
> > > > Reset cause: POR
> > > > Model: Gateworks Venice GW73xx-0x i.MX8MM Development Kit
> > > > DRAM:  4 GiB
> > > > Core:  226 devices, 32 uclasses, devicetree: separate
> > > > WDT:   Started watchdog at 30280000 with servicing every 1000ms (60s timeout)
> > > > MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> > > > Loading Environment from MMC... Reading from redundant MMC(2)... OK
> > > > In:    serial at 30890000
> > > > Out:   serial at 30890000
> > > > Err:   serial at 30890000
> > > > SEC0:  RNG instantiated
> > > > Net:   GPY111 eth0: ethernet at 30be0000 [PRIME]
> > > > GSC     : boot watchdog disabled
> > > > Thermal protection:enabled at 96C
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > Yet as soon as I enable OF_LIVE:
> > > >
> > > > U-Boot 2024.10-00735-gc530f6079c70 (Oct 07 2024 - 12:59:35 -0700)
> > > >
> > > > CPU:   Freescale i.MX8MMQ rev1.0 1600 MHz (running at 1200 MHz)
> > > > CPU:   Industrial temperature grade (-40C to 105C) at 49C
> > > > Reset cause: POR
> > > > Model: Gateworks Venice GW73xx-0x i.MX8MM Development Kit
> > > > DRAM:  4 GiB
> > > > Core:  214 devices, 32 uclasses, devicetree: separate
> > > > WDT:   Started watchdog at 30280000 with servicing every 1000ms (60s timeout)
> > > > MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> > > > Loading Environment from MMC... Reading from redundant MMC(2)... OK
> > > > In:    serial at 30890000
> > > > Out:   serial at 30890000
> > > > Err:   serial at 30890000
> > > > SEC0:  RNG instantiated
> > > > Net:   Could not get PHY for mdio: addr 0
> > > > Could not get PHY for FEC0: addr 0
> > > > Could not get PHY for mdio: addr 0
> > > > Could not get PHY for FEC0: addr 0
> > > > No ethernet found.
> > > > ^^^ phy_connect failing
> > > >
> > > > Any idea what I'm missing here?
> > > >
> > > > Are there other ways I should be modifying the live dt in U-Boot?
> > >
> >
> > Hi Simon, thanks for the response.
> >
> > > I am not sure, but the best option would be to debug the PHY stuff and
> > > try to see what is going wrong.
> > >
> > > Since the number of devices is smaller, I suspect that there is some
> > > code which doesn't use the ofnode API. But it is hard to say what is
> > > going on.
> > >
> >
> > ok, I will look into that
> >

I did manage to get livetree working on imx8mm (the documentation in
livetree.rst was very helpful). There are several imx drivers like
pinctrl that need livetree conversion updates which I'll submit when I
get a handle on this.

> > > For modifying the devicetree, you can do it just before relocation
> > > using the flattree if you like. The reason livetree is better is that
> > > the nodes don't move around when changes are made.
> > >
> >
> > Where is relocation done in this case where I'm using SPL and U-Boot
> > proper for imx8m based boards?
>
> It is always done at the end of board_init_f() in U-Boot proper.
>

Is the reason modification needs to be done before relocation simply
that it can't be expanded without relocating it again?

> >
> > If I want to utilize dt overlays in U-Boot proper can you point me to
> > what is needed or some examples?
>
> You could use a FIT in SPL and select the correct DT there, avoiding
> needing to change it in U-Boot. But if it is really run-time behaviour
> and not described by different models, then that won't work.
>
> There is board_fix_fdt() where you can find some examples. We should
> really tidy up all the DT stuff...
>

ok thanks - I see good documentation in fdt-fixup.rst and several
boards using this.

> >
> > I'm intending to detect the presence of an add-in card that has a port
> > expander on it so as to allow that port expander to be accessed via
> > U-Boot. As a bit of a hack I'm currently using flat dt (!OF_LIVE) and
> > putting the port expander in the board dt and attempting to disable it
> > via dt modification in board_init(). As a better approach I could
> > attempt to add it to dt but using an overlay would make so much more
> > sense.
>
> Disabling it in board_init() seems OK to me. Unfortunately this is the
> sort of problem which can be solved many ways.
>

This method seems to make the most sense for my use case. However
board_init() is called after relocation so I assume that is where you
are saying you can only change it at this point if using livetree?

If I add a normally disabled io-expander in the dt and during
board_init() I enable it (using ofnode_path() and
ofnode_set_enabled()) I find that when trying to probe it
uclass_find_device_by_ofnode() won't find it as it thinks its
disabled. If I instead enable the io-expander in the dt and
dynamically disable it based on runtime-detection I find that the
disabled gpio device is probed when a 'gpio status' is done which
causes a failure.

I assume what's going on is that the enabling/disabling needs to be
done before the device bind but I'm not clear how to facilitate that.

Thanks,

Tim