Undocumented voltage change in LDO1 from 1.8V to 3V on iMX8M-Mini

[stuart_maclean]

Hi Everyone,

I’m an embedded software engineer at Active Silicon and we have been developing a series of products based on the iMX8M-mini processor. In the prototype boards that we are currently developing the boot process for the Linux kernel halts when the BD71847 voltage regulator changes the LDO1 regulator from 1.8V to 3V.

We are using the imx-linux-warrior build. So the Linux kernel version is 4.19.35.

With respect to the iMX8M-mini EVK design LDO1 is attached to the NVCC_SNVS_1V8 line. This in turn goes to the NVCC_SNVS_1P8 point on the iMX8M-mini. According to the “iMX8M-mini Power Consumption Measurement Application Note” document the expected voltage is 1.8V from LDO1 (Figure 1).

https://www.nxp.com/docs/en/application-note/AN12410.pdf

Also with respect to EVK reference design (Document Number “SCH-31399 PDF: SPF-31399” on page 12: “i.MX8M Mini LPDDR4 EVK Power Sequence” table. 

Seq=1, PWR/Signal=NVCC_SNVS_1V8, Reg=LDO1, Min=1.62, Typ=1.8, Max=1.98, Max Current=10mA

However explicitly defined in the device tree for the EVK-LPDDR4 the LDO1 entry reads

ldo1_reg: regulator@6 {

reg = <6>;

regulator-compatible = "LDO1";

regulator-min-microvolt = <3000000>;

regulator-max-microvolt = <3300000>;

regulator-boot-on;

regulator-always-on;

};

In booting up the EVK with the Linux kernel  I can see the voltage change from the device tree on LDO1. i.e. From the boot up log

[    0.801319] Bus freq driver module loaded

[    0.814499] ldo1: Bringing 1800000uV into 3000000-3000000uV

[    0.818249] ldo2: Bringing 800000uV into 900000-900000uV

[    0.824986] ldo6: supplied by buck5

[    0.831572] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled

I can also see the voltage change on the NVCC_SNVS_1V8 line switch from 1.8V to 3V on my oscilloscope.

Now our electrical hardware engineers planned the circuit such that the NVCC_SNVS_1V8 line on our prototype was for 1.8V. As there is no mention or indication in any of the after mentioned documentation about the NVCC_SNVS_1V8 line having to carry 3V.

I was wondering if anyone can shed some light on this?

However as mentioned with our prototype board the boot process immediately stops when the LDO1 is switched from 1.8V to 3V. i.e. from the kernel log

[    0.746349] imx-sdma 30bd0000.dma-controller: no iram assigned, using external mem

[    0.752899] imx-sdma 30bd0000.dma-controller: Falling back to syfs fallback for: imx/sdma/sdma-imx7d.bin

[    0.762428] imx-sdma 302c0000.dma-controller: no iram assigned, using external mem

[    0.772049] imx-sdma 302b0000.dma-controller: no iram assigned, using external mem

[    0.781915] mxs-dma 33000000.dma-apbh: initialized

[    0.785323] Bus freq driver module loaded

[    0.798291] ldo1: Bringing 1800000uV into 3000000-3000000uV

then nothing.

I have tried modifying the device tree and tried a number of minimum voltages on the LDO1 regulator. Ranged from 1.6V to 2.9V. To which there were two specific outcomes.

The first (1.6V - 1.8V) saw the message 

[    5.305726] rtc rtc0: Timeout waiting for LPSRT Counter to change

being repeated over and over again. Looking at the source code and SNVS documentation (Chapter 6 - iMX8M Mini Application Processor Reference Manual) I see that the SNVS provides a real-time clock. It looks like the processor is accessing the SNVS hardware but the SNVS module doesn’t have enough voltage to drive the RTC clock and thus the scheduler.

The second behaviour (seen at 2.1V) looks like the RTC clock is barely working. The boot process initialises the SNVS hardware i.e.

[    1.081779] snvs_rtc 30370000.snvs:snvs-rtc-lp: rtc core: registered 30370000.snvs:snvs-rtc-lp as rtc0

but then halts. After that, for every couple of seconds, a kernel exception is raised coming from scheduler. Like the SNVS RTC clock is barely functional. i.e.

[   22.077436] rcu: INFO: rcu_preempt self-detected stall on CPU

Its look like the kernel’s scheduler is not working because the heart-beat from the SNVS is barely working.

For higher voltages (2.2V - 2.9V) the constraints inside the linux kernel stop this from being applied and a voltage of 1.8V is mantained.

So from what I can see the LDO1 MUST be driven at 3V in order for proper function of the iMX8M-mini. But as we have found out this is NOT documented anywhere so came some what of show stopper surprise for us. Why is this?

I’ve also attached a picture of the measurements of the NVCC_SNVS_1V8 line once it is set to 3V. We see a 32kHz wave which we believe is coming from the 32kHz crystal for the BD71847. Our hardware engineers trying to figure out how to resolve this problem with LDO1 which is mainly based of the EVK design. But if anyone has any suggestions or pointers to help us resolve this problem we would be extremely grateful to you.

Thanks for all the help,

Stuart MacLean

(Embedded Software Engineer) Active Silicon.

[stuart_maclean]

I am afraid to say that I tried the related patch. In fact, I tried it already before writing my forum post.

With this patch it applies a 1.6V output on LDO1. As mentioned in my original post we found that the SVNS RTC hardware was not responding. i.e. The kernel repeatedly posted the same timeout message as it got caught in an infinite loop.

[   22.077436] rcu: INFO: rcu_preempt self-detected stall on CPU

Looking at the source code I can see this coming from the SNVS driver.

From what we can determine, from trying different LDO1 voltages, the voltage needs to be set at 3V. When we set it to a lower voltage the kernel boot process always fall over. It falls over either because of the timeout problem mentioned above. Or, it falls over because the SNVS real-time clock is not ticking properly and so the OS scheduler throws the kernel exception. i.e. The following exception is thrown

[    5.305726] rtc rtc0: Timeout waiting for LPSRT Counter to change

This exception is thrown once every 5 seconds and the boot process no longer makes any progress.

So from what I can determine through experimentation is that the LDO1 is required to run at 3V and this IS NOT a bug. 

All the best,

Stuart

[jamesbone]

We have some a bug in our BSP, you can see that we have answered similar issue in the following link, and you can find the patches in our Git from CodeAurora

https://community.nxp.com/t5/i-MX-Processors/IMX8MM-PMIC-issue/m-p/1056424#M155375