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