i.MX6 fails to restart from linux reboot command

[yurirellosa]

Hello all,

From the kernel console when I type "reboot", sometimes restart will fail in the middle of u-boot message.

When I set the cpufreq governor to "userspace" and frequency to 792Mhz, it will not fail.

But setting the frequency to 396Mhz will most fail.

Is there somehow a failure during startup if cpu is not maximum frequency or PMIC is not on maximum voltage?

I can make it always be at 792Mhz before start, but I am wondering what would be the reason behind failing to restart.

Best Regards,

Yuri

[Yuri · Accepted solution]

The minimal recommended  core voltages (VDD_ARM_IN and VDD_SOC_IN in the bypass mode)

according to the recent Datasheet(s) are 1.15 V. This fact is reflected in the recent BSP (L3.14.28)

configuration. Please use it. 

Regards,

Yuri.

[yurirellosa]

Hello,

Are you referring to Datasheet(Rev. 4, 07/2015) -> 4.1.3 Operating Ranges on Page 20?

It says that "LDO bypassed for operation up to 396 MHz" has minimum of "0.925 V", in which we get "0.969 V".

But is this out of the question as our u-boot is set to boot at 792Mhz?

CPU:   Freescale i.MX6D rev1.5 at 792 MHz

So instead we should follow the minimum "1.150 V"

Is my understanding correct?

If it is possible, if there is a specific patch, can you point me to its location?

Upgrading from L3.10.17 to L3.14.28 may not be as easy for us. Thank you!

Best Regards,

Yuri

[Yuri]

Hello,

   Strictly speaking,  for the case when VDD_ARM_IN is separated from VDD_SOC_IN,

it is possible  to apply the value of 0.925V till 396 MHz. Nevertheless, taking into account that

the 396 MHz is boundary value and results of tests, Linux designers in L3.14.28 prefer to apply
more safe parameters for CPUFREQ working points.

You may try to change the working point for 396 MHz.

"For CPU frequency working point settings, see:

• arch/arm/boot/dts/imx6q.dtsi for i.MX 6Quad

• arch/arm/boot/dts/imx6dl.dtsi for i.MX 6DualLite

• arch/arm/boot/dts/imx6sl.dtsi for i.MX 6SoloLite

• arch/arm/boot/dts/imx6sx.dtsi for i.MX 6SoloX.

Regards,

Yuri.

[Yuri]

Hello,

  perhaps it makes sense to pass the DDR stress test during long time
with incrementing frequencies

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[yurirellosa]

Hi,

Is this the right link? --> https://community.freescale.com/docs/DOC-96412

Best Regards,

Yuri

[BiyongSUN]

In your hardware, please check if you connect the WDOG_B to the pmic reset .

[yurirellosa]

The PMIC is PF0100 and WDOG2_B is definitely connected to PF0100's PWRON pin.

I would think that it is not the pin connection problem, as changing CPU frequency/voltage seems to remedy the problem.

Also on u-boot it usually stops at the log message below.

U-Boot 2014.10-gfdabf9e-dirty (Jul 31 2015 - 14:23:06)

CPU:   Freescale i.MX6D rev1.5 at 792 MHz

Reset cause: WDOG

Board: MX6-PAD

I2C:   ready

DRAM:  1 GiB

MMC:   FSL_SDHC: 0, FSL_SDHC: 1

In:    serial

Out:   serial

Err:   serial

Sometimes, it differs with the hardware, it stops around "DRAM: 1GiB"

[BiyongSUN]

What is voltage of all power rails that? have you measure that?

Does the WDOG_B is issued to reset the pmic when you run the reset command?

Need to confirm with you. Do you know the WDOG_B will get asset when you run reset command? Do you know that?

[yurirellosa]

Yes, we have already measured the pins connected to PMIC during restart.

The data is as below, and as you can see the only difference is with VDDCORE. So we think that perhaps the problem has something to do with this.

PINS	792MHz	396MHz
VDDCORE	1.144	0.969
VDDSOC	1.167	1.167
GEN_1V5	1.488	1.488
GEN_1V8	1.781	1.782
GEN_3V0	2.841	2.841
PMIC_5V	4.96	4.96

On "reset" command I am aware that it is suppose to assert WDOG_B. But other than a POR reset, there seems to be no change in the WDOG_B signal.

When you reset is it more proper for [Reset cause] to be [POR] rather than [WDOG]?

Perhaps we are not setting wdog properly in the kernel?

Below are the related device tree settings

wdog2: wdog@020c0000 {

  compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";

  reg = <0x020c0000 0x4000>;

  interrupts = <0 81 0x04>;

  clocks = <&clks 0>;

  status = "okay";

};

wdt_int {

  pinctrl_wdt_int_1: wdt_intgrp-1 {

  fsl,pins = <

  /* Internal Watch-dog timer */

  MX6QDL_PAD_DISP0_DAT9__WDOG2_B 0x1b008

  >;

  };

};

&gpc {

  fsl,cpu_pupscr_sw2iso = <0xf>;

  fsl,cpu_pupscr_sw = <0xf>;

  fsl,cpu_pdnscr_iso2sw = <0x1>;

  fsl,cpu_pdnscr_iso = <0x1>;

  fsl,ldo-bypass = <0>; /* use ldo-bypass, u-boot will check it and configure */

  fsl,wdog-reset = <1>; /* watchdog select of reset source */

  pu-supply = <&reg_pu>; /* ldo-bypass:use pu_dummy if VDDSOC share with VDDPU */

  status = "okay";

};

Thanks!