Booting rel_imx_4.1.15_1.1.0_ga on imx6sx

[eriktideman]

We are running a custom board with imx6sx and kernel version rel_imx_4.1.15_1.1.0_ga and gets the following errors in dmesg when booting:

[	0.431765] anatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector.
[	0.431791] anatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22
[	0.432465] anatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector.
[	0.432490] anatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22

The device tree for regulator vddsoc and vddcore are the same as in the board support package (SABRESD):

			reg_arm: regulator-vddcore@140 {
				compatible = "fsl,anatop-regulator";
				regulator-name = "cpu";
				regulator-min-microvolt = <725000>;
				regulator-max-microvolt = <1450000>;
				regulator-always-on;
				anatop-reg-offset = <0x140>;
				anatop-vol-bit-shift = <0>;
				anatop-vol-bit-width = <5>;
				anatop-delay-reg-offset = <0x170>;
				anatop-delay-bit-shift = <24>;
				anatop-delay-bit-width = <2>;
				anatop-min-bit-val = <1>;
				anatop-min-voltage = <725000>;
				anatop-max-voltage = <1450000>;
			};

			reg_soc: regulator-vddsoc@140 {
				compatible = "fsl,anatop-regulator";
				regulator-name = "vddsoc";
				regulator-min-microvolt = <725000>;
				regulator-max-microvolt = <1450000>;
				regulator-always-on;
				anatop-reg-offset = <0x140>;
				anatop-vol-bit-shift = <18>;
				anatop-vol-bit-width = <5>;
				anatop-delay-reg-offset = <0x170>;
				anatop-delay-bit-shift = <28>;
				anatop-delay-bit-width = <2>;
				anatop-min-bit-val = <1>;
				anatop-min-voltage = <725000>;
				anatop-max-voltage = <1450000>;
			};

Why does the regulator driver complain about the internal regulators vddasoc and vddcore? As our board is running the standard device tree mapping for these regulators the errors should not be related to our design.

[eriktideman]

But you are linking to a two years old patch for imx6dl, kernel 3.10? From what I can see in the reference schematics for imx6sxsabresd it has been using the pfuze200 since revision B (released 2014/08/28). Does this mean that the power regulator in the reference design for imx6sx is not supported in the BSP for the imx6sx?

We will look at the patch you linked and consider to turn on ldo, thanks!

[igorpadykov]

actually mentioned patch just gives idea, why it may not working

with pfuze200. SCH-27962 REV C uses VDDARM_IN and VDDSOC_IN

connected together, which will not allow datasheet requirements for ldo bypass

mode.

[eriktideman]

Okay, thanks for pointing us in the right direction!

[igorpadykov · Accepted solution]

according to comments below if pfuze200 is used (as SCH-27962 REV C)

then only ldo-on mode is possible, since VDDARM_IN and VDDSOC_IN

uses one regulator

linux-2.6-imx.git - Freescale i.MX Linux Tree

[eriktideman]

It took me some time to get my hands on one of our reference design boards but I can now confirm that the very same error message is also given on the reference board imx6sabresd revision 6SX SABRE-SDB SCH-27962 REV C with bootloader: u-boot-imx6sxsabresd_sd.imx, kernel: zImage and device-tree: zImage-imx6sx-sdb.dtb from demo package L4.1.15_1.0.0-ga_images_MX6SXALL.tar.gz. What impacts does this have on the regulators and can we ignore it or should we use the old 3.14 driver for the anatop regulator?

Error:

anatop_regulator 20c8000.anatop:regulator-vddcore@140: Failed to read a valid default voltage selector.

anatop_regulator: probe of 20c8000.anatop:regulator-vddcore@140 failed with error -22

anatop_regulator 20c8000.anatop:regulator-vddsoc@140: Failed to read a valid default voltage selector.

anatop_regulator: probe of 20c8000.anatop:regulator-vddsoc@140 failed with error -22

[igorpadykov]

do such errors appear on MX6SX Sabre SD board with Demo images?

[eriktideman]

We have all three of the mentioned regulators("vddsoc", "vddarm", "vddpcie-phy"), as specified in imx6sx.dtsi. The regulator driver is not complaining about vddpcie-phy but about vddarm and vddsoc. The driver has a special if statment that matches the name "vddpcie-phy" but no such statement exists for "vddarm" and "vddsoc".

[igorpadykov]

as you said before:

"name for the driver is not  equal "vddpu" or "vddpcie-phy". As the names  of the regulators

"vddarm" and "vddsoc" missmatches the driver throws error"

and you have "reg_pcie_phy", then why this error occurs ?

I believe you can debug it more.

[eriktideman]

Yes it exists, we are including the unmodified imx6sx.dtsi in our device tree.

[igorpadykov]

please check that you have reg_pcie_phy: regulator-vddpcie-phy@140

in

linux-2.6-imx.git - Freescale i.MX Linux Tree

[eriktideman]

Is this really what we want to do? We are following the reference designs power layout and bypassing the internal LDO. Enabling it would increase power consumption I guess? And if we are using the same power circuit then why would we want to change LDO mode?

Loading demo images wont work on our board as the emmc and sd card are located at other pins.

From what I can see in the driver for the regulator it has been updated from your 3.14 kernel release compared to 4.1.15. Previously we used the 3.14 kernel and we did not get the error message.

3.14 anatop-regulator driver:

	/* Only core regulators have the ramp up delay configuration. */
	if (sreg->control_reg && sreg->delay_bit_width) {
	rdesc->ops = &anatop_core_rops;

	ret = regmap_read(config.regmap, rdesc->vsel_reg, &val);
	if (ret) {
	dev_err(dev, "failed to read initial state\n");
	return ret;
	}

	sreg->sel = (val & rdesc->vsel_mask) >> sreg->vol_bit_shift;
	if (sreg->sel == LDO_FET_FULL_ON) {
	sreg->sel = 0;
	sreg->bypass = true;
	}

	} else {
	rdesc->ops = &anatop_rops;
	}

4.1.15 anatop-regulator driver:

	/* Only core regulators have the ramp up delay configuration. */
	if (sreg->control_reg && sreg->delay_bit_width) {
	rdesc->ops = &anatop_core_rops;

	ret = regmap_read(config.regmap, rdesc->vsel_reg, &val);
	if (ret) {
	dev_err(dev, "failed to read initial state\n");
	return ret;
	}

	sreg->sel = (val & rdesc->vsel_mask) >> sreg->vol_bit_shift;
	if (sreg->sel == LDO_FET_FULL_ON) {
	sreg->sel = 0;
	sreg->bypass = true;
	}

	/*
	* In case vddpu was disabled by the bootloader, we need to set
	* a sane default until imx6-cpufreq was probed and changes the
	* voltage to the correct value. In this case we set 1.25V.
	*/
	if (!sreg->sel && !strcmp(sreg->name, "vddpu"))
	sreg->sel = 22;

	/* set the default voltage of the pcie phy to be 1.100v */
	if (!sreg->sel && !strcmp(sreg->name, "vddpcie-phy"))
	sreg->sel = 0x10;

	if (!sreg->sel) {
	dev_err(&pdev->dev, "Failed to read a valid default voltage selector.\n");
	return -EINVAL;
	}
	} else {
	rdesc->ops = &anatop_rops;
	}

The 3.14 driver does never throw any such error but as the code for 4.1.15 shown it does it when there is a core regulator with ldo_bypass enabled and the name for the driver is not  equal "vddpu" or "vddpcie-phy". As the names  of the regulators "vddarm" and "vddsoc" missmatches the driver throws error and exits for those regulators. Is this a bug in the driver or has the support for LDO-bypass changed in 4.1.15?

[eriktideman]

The kernel code that we are using is the latest kernel release from Freescale's git repository, linux-2.6-imx.git - Freescale i.MX Linux Tree . The differences between the kernel verison, L4.1.15_1.0.0, that you recommend and the one we are using, L4.1.15_1.1.0, are minor and do not change anything regarding how the regulators operate. The changes do infact mostly affect imx6ul and gpu.

Diff between the different kernel versions:

Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt

arch/arm/boot/dts/Makefile

arch/arm/boot/dts/imx6ul-14x14-ddr3-arm2.dts

arch/arm/boot/dts/imx6ul-14x14-evk-usb-certi.dts

arch/arm/boot/dts/imx6ul-14x14-evk.dts

arch/arm/boot/dts/imx6ul-14x14-lpddr2-arm2.dts

arch/arm/boot/dts/imx6ul-9x9-evk.dts

drivers/media/platform/mxc/subdev/mx6s_capture.c

drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c

drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_debugfs.c

drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_os.c

drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_sync.c

drivers/usb/chipidea/ci_hdrc_imx.c

drivers/usb/chipidea/core.c

include/linux/mtd/map.h

Therefore,it should not matter if we are running L4.1.15_1.0.0 or L4.1.15_1.1.0, as the code for the regulators are the same.

We are using ldo-bypass in our design and the the device tree states:

&gpc {

        fsl,ldo-bypass = <1>;

};

Also during U-boots startup it outputs:

...

switch to ldo_bypass mode!

Starting kernel ...  

...

...

But I agree with you, the problem could be related to ldo-bypass. Looking at the code for the regulator it seems like having ldo-bypass enabled should remove the error. I will investigate further why our device does not enter ldo-bypass correctly.

[igorpadykov]

could you try ldo enabled mode, not "ldo_bypass" mode.

Had you tried Demo binary images.

~igor

[igorpadykov]

Hi Erik

what BSP is used, could you try latest

Board Support Packages (35)

L4.1.15_1.0.0_iMX6SX (REV L4.1.15_1.0.0)

http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/i.mx-applications-process...

and use "ldo" configuration as described in attached Release Notes p.4

Table 3. Kernel and device tree configurations

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------