[PATCH 3/3] imx: power-domain: Get rid of SMCCC dependency

[Adam Ford]

On Sun, Apr 17, 2022 at 10:16 AM Marek Vasut <marex at denx.de> wrote:
>
> On 4/17/22 15:21, Adam Ford wrote:
> > On Sat, Apr 16, 2022 at 9:13 PM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 4/17/22 03:01, Adam Ford wrote:
> >>
> >> Hi,
> >>
> >>>>> After the patch:
> >>>>>
> >>>>> U-Boot SPL 2022.04-00822-gc2a24a7ce5 (Apr 16 2022 - 15:45:29 -0500)
> >>>>> PMIC:  PFUZE100 ID=0x10
> >>>>> SEC0:  RNG instantiated
> >>>>> Normal Boot
> >>>>> Trying to boot from MMC2
> >>>>
> >>>> There should be some sort of output from ATF here, which version did you
> >>>> use during your tests ?
> >
> > When I look at the ATF from NXP, it appears the debug console is
> > disabled by default.  I think it's because the 8MQ has less OCRAM than
> > the rest of the 8M family, but I don't know.
>
> Hum, I see. I never used the NXP fork, I only ever used upstream.
>
> >>> I used the version from the imx8mq_evk.rst:
> >>>
> >>> Note: srctree is U-Boot source directory
> >>> Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
> >>> branch: imx_5.4.47_2.2.0
> >>>
> >>> This works with U-Boot master.  I realize it has the ATF power domain
> >>> code, but with the SMCC stuff removed, it should be irrelevant.
> >>>
> >>>>
> >>>> Did you set IMX_BOOT_UART_BASE correctly ?
> >>>>
> >
> > 0x30860000
> >
> >>>> Did you set ATF_LOAD_ADDR correctly ?
> >
> > ATF_LOAD_ADDR=0x00910000
>
> This should be OK.
>
> >>> If I didn't build it right, I don't think 'master' would have booted,
> >>> but it did.  I think I built it correctly.
> >>
> >> I find it odd that there is no print from the ATF, do check these twoU-Boot SPL 2022.04-00822-ge5aeb301b2 (Apr 17 2022 - 08:18:32 -0500)
> >
> > With the console enabled and your patch series applied:
> >
> > PMIC:  PFUZE100 ID=0x10
> > SEC0:  RNG instantiated
> > Normal Boot
> > Trying to boot from MMC2
> > NOTICE:  BL31: v2.2(release):rel_imx_5.4.47_2.2.0-0-gc949a888e-dirty
> > NOTICE:  BL31: Built : 08:16:33, Apr 17 2022
> >
> > <hang>
> >
> > It appears to me that both SPL and ATF are running.
> >
> > See below for bisect conversation...
> >> variables, I have seen hangs in ATF like this when they were not set right.
> >>
> >>>> Do you get a hang when you revert only this specific patch ?
> >>>
> >>> When I reverted the series, it booted again, but I can do a bisect
> >>> tomorrow to narrow down the specific patch in the series that causes
> >>> the issue.
> >>
> >> Please do, thanks.
> >
> > 28e5debc019b347436bdebd8978a971ce5a6582c is the first bad commit
> > commit 28e5debc019b347436bdebd8978a971ce5a6582c
>
> This commit does not exist in upstream ?
>
> u-boot$ git describe 28e5debc019b347436bdebd8978a971ce5a6582c
> fatal: 28e5debc019b347436bdebd8978a971ce5a6582c is neither a commit nor blob
>

I took your patch series from patchwork and applied it with git am on
top of the master.  I am guessing the number generated won't match
something upstream because we have different starting points.  I left
the description so you could see it corresponded to the patch in
question.  Would you prefer I use a specific branch instead?

> Can you try and force-deselect CONFIG_CLK=y (and possibly the same for
> SPL) ? I think that gets pulled in by this commit too, it might've not
> been selected on your board before. And if that's not easily possible,
> try and revert these three:
>
> 129f5102d29 ("clk: imx8m: reduce rate table duplication")
> 11c8ab01f3e ("clk: imx8mq: Add a clock driver for the imx8mq")
> a375c6f3fbe ("dt-bindings: imx8mq-clock: add mainline definitions")
>
> I would like to know whether pulling in the clock support might be the
> actual source of problems.

When I just reverted all three of those, it still hangs.  However,
when I removed CONFIG_CLK, it recovered.  I'll examine which clocks
may be missing or if there is some other clock dependency.

adam