On Sun, Apr 17, 2022 at 10:16 AM Marek Vasut <ma...@denx.de> wrote: > > On 4/17/22 15:21, Adam Ford wrote: > > On Sat, Apr 16, 2022 at 9:13 PM Marek Vasut <ma...@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