STPMIC1 DDR voltage rails

[gil_he]

hello,

We are using OSD32MP153C-512M-BAA and are in an advanced stages of our product (soon released to customers).

We noticed now that in some power on incidents(once in 5-10 tries), Linux is not loading (the USB connection to the PC is not recognized by Windows).

Checking the board/Octavo revealed that all Octavo DDR voltages are zero (I used the Octavo power rails TPs for that).

VDD_DDR (BUCK2) = 0V. Other DDR voltages are derived from it (VTT_DDR and VREF_DDR).

By default BUCK2 is RANK0 meaning it is not turned on automatically (unless Octavo changed the BUCK2 rank in the STPMIC NVM).

What is turning on BUCK2 in the Octavo? Is it via I2C?

I assume it is done during the FSBL (TF-A).

What can cause this voltage not to turn on? (it is internal to the Octavo. The user cannot use it).

We took the TF-A STPMIC dts settings from the Octavo BRK TF-A dts.

Should we change anything there?

When I pull Octavo NRST to GND momentarily, BUCK2 is turned on and the Octavo/Linux are fully functional.

Please advise.

It is very urgent!

Thank you

Gil

[mwlinux]

Hi Gil,

try following code for tf-a.dts

&pinctrl_z {
i2c4_pins_z_mx: i2c4_mx-0 {
pins {
pinmux = <STM32_PINMUX(‘Z’, 4, AF6)>, /* I2C4_SCL */
<STM32_PINMUX(‘Z’, 5, AF6)>; /* I2C4_SDA */
bias-pull-up;
drive-open-drain;
slew-rate = <0>;
};
};

/* USER CODE BEGIN pinctrl_z */
/* USER CODE END pinctrl_z */
};

&i2c4{
pinctrl-names = “default”;
pinctrl-0 = <&i2c4_pins_z_mx>;
status = “okay”;

/* USER CODE BEGIN i2c4 */
i2c-scl-rising-time-ns = <185>;
i2c-scl-falling-time-ns = <20>;
clock-frequency = <400000>;

pmic: stpmic@33 {
compatible = “st,stpmic1”;
reg = <0x33>;
interrupts-extended = <&exti 55 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <2>;
status = “okay”;
secure-status = “okay”;

regulators {
compatible = “st,stpmic1-regulators”;
buck1-supply = <&vin>;
buck2-supply = <&vin>;
buck3-supply = <&vin>;
buck4-supply = <&vin>;
ldo1-supply = <&v3v3>;
ldo2-supply = <&vin>;
ldo3-supply = <&vdd_ddr>;
ldo4-supply = <&vin>;
ldo5-supply = <&vin>;
ldo6-supply = <&v3v3>;
vref_ddr-supply = <&vin>;
boost-supply = <&vin>;
pwr_sw1-supply = <&bst_out>;
pwr_sw2-supply = <&bst_out>;

vddcore: buck1 {
regulator-name = “vddcore”;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-initial-mode = <0>;
regulator-over-current-protection;
};

vdd_ddr: buck2 {
regulator-name = “vdd_ddr”;
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-initial-mode = <0>;
regulator-over-current-protection;
};

vdd: buck3 {
regulator-name = “vdd”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
st,mask-reset;
regulator-initial-mode = <0>;
regulator-over-current-protection;
};

v3v3: buck4 {
regulator-name = “v3v3”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-over-current-protection;
regulator-initial-mode = <0>;
};

v1v8_audio: ldo1 {
regulator-name = “v1v8_audio”;
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};

v3v3_hdmi: ldo2 {
regulator-name = “v3v3_hdmi”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};

vtt_ddr: ldo3 {
regulator-name = “vtt_ddr”;
regulator-always-on;
regulator-over-current-protection;
st,regulator-sink-source;
};

vdd_usb: ldo4 {
regulator-name = “vdd_usb”;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};

vdda: ldo5 {
regulator-name = “vdda”;
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <2500000>;
//regulator-boot-on;
regulator-always-on;
};

v1v2_hdmi: ldo6 {
regulator-name = “v1v2_hdmi”;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};

vref_ddr: vref_ddr {
regulator-name = “vref_ddr”;
regulator-always-on;
};

bst_out: boost {
regulator-name = “bst_out”;
};

vbus_otg: pwr_sw1 {
regulator-name = “vbus_otg”;
};

vbus_sw: pwr_sw2 {
regulator-name = “vbus_sw”;
regulator-active-discharge = <1>;
};
};
};
/* USER CODE END i2c4 */
};

This is correct that the voltage for DDR is turned off. The first stage bootloader should put on and configure DDR memory to work then load the second bootloader code into DDR memory and jump to the second bootloader (usually U-Boot). Why is DDR turned off, the answer is the CPU doesn’t know what kind of memory is connected 1.8V, 1.5V or maybe 1.35V. In the first stage bootloader, we decide what kind of memory is connected and how to configure it properly.

BR Michal

• This reply was modified 3 months, 3 weeks ago by mwlinux.
• This reply was modified 3 months, 3 weeks ago by mwlinux.
• This reply was modified 3 months, 3 weeks ago by mwlinux.

[gil_he]

Hi Michal,

Thank you for the prompt response.

So, we have the ROM code in the STM32MP that loads the FSBL, from the eMMC flash, in the internal RAM and executes it.

the FSBL initializes the clock and DDR, then loads the SSBL into the DDR and executes it.

In our case, BUCK2=0V (VDD_DDR).

FSBL should change the default voltage to 1.35V and enable it. I assume it does that via I2C4.

The TF-A dts file you shared is very similar to what we use (I attached what we use).

Is there any difference between the TF-a dts files that might cause this issue?

It seems we have something marginal here since it only happens once every 5-10 power ups.

In addition, NRST solves this.

NRST resets the ST as well as the STPMIC1.

thanks,

Gil

 

• This reply was modified 3 months, 3 weeks ago by gil_he.
• This reply was modified 3 months, 3 weeks ago by gil_he.

Attachments:

1. tf-a.zip

[gil_he]

Hi Michal,

I am thinking:

The FSBL initializes the clock and DDR, then loads the SSBL into the DDR and executes it.

Is there a known sequence that the FSBL follows when it initializes, before loading the SSBL?

Maybe we fail in some early stage of the FSBL init (clock initialization for example) and do not reach the stage where the DDR and DDR power (BUCK2) are initialized, and that is why BUCK2 is not defined as 1.35V and/or is not turned on?

thanks,

Gil

 

• This reply was modified 3 months, 3 weeks ago by gil_he.

[Neeraj Dantu]

Hey Gil,

A few questions on the board behavior:

1. When you observe DDR at 0V, do you see all the other power rails with RANK 0 coming up normally?

2. Is this ‘erratic’ boot observed on all the prototypes?

 

As   Michal suggests, it may be that TF-A execution is running into error. Can you post the boot log file when the failure is observed?

You are correct that TF-A would bring up DDR power rail and initialize the clocks and DDR interface. TF-A is being read from SD card. If you don’t observe any boot logs when boot fails, it could be that the SD interface may be failing to transfer TF-A. I would try using a different SD card to see if that fixes the issue.

If TF-A successfully initializes and runs, the logs could give you an indication of where execution if failing. See https://wiki.st.com/stm32mpu/wiki/How_to_debug_TF-A_BL2 for additional help on enabling traces.

Best,

Neeraj

[gil_he]

hello Neeraj,

RANK 0 voltages, that we actively use, include BUCK2 (VDD_DDR) and the voltages that derive from it, LDO3/VTT_DDR and VREF_DDR.

We don’t use the other power rails that are RANK 0: LDO1, LDO2, LDO6.

However, I measure 0V on all of them.

This “erratic” behavior was observed on at least 4-5 boards (out of the 18 we assembled).

We use an eMMC Flash which has FSBL, SSBL, Linux, etc., on it.

I managed to capture the boot log when the issue happens.

Enclosed a text file with failing (problematic power-up) and successful boot logs.

I can understand why RANK 0 voltages are not there. It didn’t reach the place where they are intialized and enabled.

I am not able to accurately pin point where, during boot, the system fails.

Is it during the SoC PROM execution?

Was it able to load FSBL1 from the eMMC Flash?

What is CMD13?

Is everything we see in the boot log is a result of the SoC running its PROM code?

Meaning initial access to eMMC fails?

thanks,

Gil

 

• This reply was modified 3 months, 2 weeks ago by gil_he.
• This reply was modified 3 months, 2 weeks ago by gil_he.
• This reply was modified 3 months, 2 weeks ago by gil_he.

Attachments:

1. power_up_log.txt

[Neeraj Dantu]

Gil,

From the bootlog of the failure, it looks like CMD13 issued by TF-A is not getting a response from the SD card. See detail here: https://chlazza.nfshost.com/sdcardinfo.html.

 

I found https://community.st.com/t5/stm32-mpus-products/stm32mp1-occasionally-emmc-boot-fail-with-quot-cmd13-failed/td-p/108285 on ST’s forums looks very close to what you are seeing. The issue you are encountering may be because power cycling of the regulator that supplied power to the SD card during TF-A execution.

The solution proposed by ST: https://community.st.com/t5/stm32-mpus-embedded-software/when-updating-from-arm-trusted-firmware-v2-4-stm32mp-r1-to-arm/td-p/94079 is a patch that disables this cycling. Can you try this solution and check if the issue still exists?

Best,

Neeraj

[gil_he]

Hi Neeraj,

I looked into the links you sent.

I compiled and sent few questions to the person who submitted the patch in ST.

That was five days ago and no reply from him.

Please take a look and see if you can assist.

************************************************************************
We encountered this issue just recently. Every few power-ons, the system is stuck and we get the messages as described at the beginning of the thread. Resetting the PMIC / STM32MP153C solves this.

At first you suggested to remove the line for vmmc-supply from the TF-A dts.

My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.

So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

Then you wrote “In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.”

I assume this is another justification to remove this line from the TF-A dts.

In my case, our custom board connects v3v3 (BUCK4) to both vmmc and vqmmc supplies.

So, should I remove both lines (vmmc-supply = <&v3v3>; vqmmc-supply = <&v3v3>) from the TF-A dts?

Then, you wrote: “After internal discussions, we will deploy a correction that will have the same effect as the previous solution. So you can go on with it on your side.”

And, suggested a fix: a patch, to be applied to “regulator_core.c” (a file in the TF-A package).

Can you describe what this patch does?

What do you suggest we do? Apply the patch or modify the TF-A dts file?

*****************************************************************

thank you

Gil

• This reply was modified 3 months, 1 week ago by gil_he.

[Neeraj Dantu]

Gil,

The patch has been integrated into newer releases of OpenSTLinux. So, I would use the patch as opposed to the DT work around.

Best,

Neeraj

[gil_he]

Hi Neeraj,

Thank you.

Can you please read what I enclosed below and comment on that? (from your knowledge).
(1)
My guess it that SDMMC initialization procedure in the TF-A powers the SDMMC device off/on (maybe to bring it to some initial state) and by removing this line, the TF-A code will not know which supply to toggle, so it will not perform it.
So, the instability/oscillations in BUCK4 (due to the off/on) will not happen, thus will not affect the eMMC.

(2)
Then you wrote “In case of v3v3 supply of the sdmmc, you cannot do a power cycle of the sdmmc at tf-a level (because you will switch off almost all the platform). But this is not an issue because the romcode has already done it before.”
I assume this is another justification to remove this line from the TF-A dts.

(3)
Can you describe what this patch does?
(From you knowledge of the patch syntax, if you are familiar with it). I enclosed the patch.

thank you

Gil

• This reply was modified 3 months ago by gil_he.

Attachments:

1. 0591c8f.diff_.zip

[Neeraj Dantu]

Gil,

(1) & (2) – Yes you are correct.

 

(3) – The patch is essentially checking whether the regulator was set as “always on” supply in the device tree. If it is configured as an always on regulator, it will not turn the regulator off even when a function call is made to turn it off.

Best,

Neeraj

[Author]

Posts