imx6solo: problem booting with uboot 2019

[vaudoitlaurent]

Hi,

on a custom board using imx6Solo, we had a nxp uboot 2014. We did not have any problem of launching the kernel

We have now bump to yocto warrior, using uboot 2019, and on some boards, we are not able to launch the kernel. (imx6 get stuck in the last step of uboot, just before jumping on the kernel).

After some analyse, i've seen that the pmu_reg_core register is not the same value between 2014 and 2019.

The difference is that on the uboot 2014, the voltage for VPU/GPU is set to default value.

On uboot 2019, the voltage for VPU/GPu is set to 0.

i've tried on a board which is not booting with uboot 2019 to change the value of the pmu_reg_core to activate voltage for VPU/GPU, and now the boards boot well.

We do not use VPU/GPU on this board.

Do you have an idea of what could be the problem

Thanks in advance for your help

Regards

Laurent

[igorpadykov]

Hi Laurent

reason may be that linux image uses gpu by default, so when voltage for VPU/GPu is set to 0

it does not boot. May be recommended to try nxp uboot/linux from NXP

source.codeaurora.org/external/imx  repository. Documentation:

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

Best regards
igor

[vaudoitlaurent]

Hi Igor,

thanks for the answer.

we allready use u-boot-imx and linux-imx from 

source.codeaurora.org/external/imx.

I went a little further yesterday, and problems seems coming from the GPC driver, when setting the PU power domain.

in this case i see that the regulator reg_pu  is enabled.

i see a write in the pmu_reg_core, but the crash occurs just after.

thing i do not understand is that in this case, it looks like the PU ldo ramp delay is not applied.

If i add some log after writing the pmu_reg_core, it seems that the problem does not occurs.

Laurent

[igorpadykov]

uboot and linux should be aligned as described in Release Notes of every BSP

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

For example Uboot v2019.04 should be used with L4.19.35 as described in L4.19.35_1.1.0_LINUX_DOCS  Documentation

https://source.codeaurora.org/external/imx/uboot-imx/tree/?h=imx_v2019.04_4.19.35_1.1.0

https://source.codeaurora.org/external/imx/linux-imx/tree/?h=imx_4.19.35_1.1.0

Best regards
igor

[vaudoitlaurent]

Hi @igorpadykov ,

this is the case, we use 

linux-imx 4.19.35 and u-boot-imx 2019-04

Laurent

[igorpadykov]

if only some boards are failing to boot, may be recommended to run ddr test on them,

then update uboot dcd header with new calibration settings found from test

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-6-7-DDR-Stress-Test-Tool/ta-p/11082...

https://source.codeaurora.org/external/imx/uboot-imx/tree/board/freescale/mx6sabresd/mx6solo_4x_mt41...

Best regards
igor

[vaudoitlaurent]

@igorpadykov 

DDR test as allready be passed.

the fact is that with old uboot (or uboot 2019 + activation of the VPU LDO), no boot problem.

with Uboot 2019 without activation of VPU LDO, the problem occurs.

what could be the link with the DDR?

moreover, when i try to debug, it seems that in the kernel, when the GPC enable the powerdomain1 (linked to the vpu regulator, i do not see some ramp up delay. if i add some time after the write of the ldo activation, the problem does not occurs).

[igorpadykov]

could you try to reproduce issue on NXP Sabre SD reference board.

>with Uboot 2019 without activation of VPU LDO, the problem occurs.

>what could be the link with the DDR?

if ddr configuration is marginal, small power supplies changes (due to activation of VPU LDO)

may cause problems.

Best regards
igor

[vaudoitlaurent]

@igorpadykov 

unfortunately, i do not have a sabreSD.

Also depending on the kernel defconfig it seems that problem occurs or not, but i'm not able to find the difference that could cause the crash.

i add in attachment the 2 defconfigs.

regarding the ddr, i will try a stress test and relaunch calibration.

Best regards

Laurent

[igorpadykov]

since issue happens only on some boards, it may be related to power supplies.

One can check VDD_PU_CAP with oscilloscope on good and bad boards.

Best regards
igor

[vaudoitlaurent]

Hi @igorpadykov 

i've put a scope on VDDPU_CAP.

I'm not a hw guy, i'm not really able to tell if the signal is correct or not, but what i see is that

with the scope, the problem occurency is musch lower.

without scope, problem is quite systematical

with scope, i have seen the problem 1 time on more than 10 boot.

Below a capture of the VDDPU_CAP part. seems there is a little difference witht he SABRE (less capacitors). Could it explain the problem?

Best regards

Laurent

[igorpadykov]

Hi Laurent

VDDPU_CAP should have capacitors as described in Table 2-6. Power and decouple recommendations

i.MX 6Solo/6DualLite Applications Processor Reference Manual

In general processor is quite sensitive to correct capacitors placement and values, so

recommended exactly follow hardware guide and sabre design.

Best regards
igor

[vaudoitlaurent]

Hi @igorpadykov 

we try to add some capacitor on VDDPU_CAP, to be more compliant with the sabresd DL.

This does not change anything.

I re run calibration and tried the value which are a little bit different than the one we have, but it doe snot change anything.

I also launch a ddr stress test which is running well. To be more in the same configuration, it could be interesting to start the VDDPU LDO during the ddr stress test, but i don't know how if it is possible to do this.

Best regards

Laurent

[vaudoitlaurent]

Hi again,

one thing i maybe missed to tell, is that the problem occurs more often when i load uboot from jtag.

If i flash uboot in emmc, the problem is much more lower the same board.

Laurent

[igorpadykov]

>we try to add some capacitor on VDDPU_CAP, to be more compliant with the sabresd DL.

>This does not change anything.

however from previous post : putting "scope on VDDPU_CAP, with the scope, the problem occurency is much lower."

This may be problem with poor soldering, one can resolder chip.

Best regards
igor

[vaudoitlaurent]

Hi again,

still on this problem i see:

if LDOPU set to 0 in PMU_REG_CORE => boot ko, PMU_MISC2 reg = 0x672f67

if LDOPU set to reset value in PMU_REG_CORE => boot ok, PMU_MISC2 reg = 0x676767

on PMU_MISC2, i see that when LDOPU is disabled, we get the brownout detection status bit set

i also see that bit 14 is 0

bit 14 is 1 when LDOPU is enabled. 

Bit 14 is marked as reserver in the reference manual, but maybe it can help Nxp people.

This problem is quite critical as our client is a little stuck

Thanks in advance for the help

Laurent

[vaudoitlaurent]

i add some new informations:

crash seems not occuring in last step of uboot, but in the kernel,

just after the gpc powerdomain 1 probe

imx-pgc-pd imx-pgc-power-domain.1: Linked as a consumer to regulator.5

is the last line i get before kernel panic.

regulator.45 seems vddpu regulator

Laurent