PMIC Voltage change issue in stm32mp1 Arm trusted firmware.

[Navaneeth kumar]

Hello,

We are using stm32mp157A processer in my custom board.

We need to change voltage values in Arm trusted firmware (TFA 2.5) dtsi file .For that we changed voltages as per our custom board but it is not effected.

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;

};

we need 1.8v for this buck3 so we changed above node to 1.8v using below node.

vdd: buck3 {

regulator-name = "vdd";

regulator-min-microvolt = <1800000>;

regulator-max-microvolt = <1800000>;

regulator-always-on;

st,mask-reset;

regulator-initial-mode = <0>;

regulator-over-current-protection;

};

After changing also we are getting 3.3 volts.

So how can we change voltage from3.3 to 1.8 volts?

please help us in this regards.

.

[PatrickF]

Hi,

Here you are expecting to boot platform at 3.3V than switch to 1.8V.

I'm not expert of TF-A, but usually VDD does not change over time, so maybe this is not supported by TF-A.

If you want to have a platform with VDD=1.8V, please use STPMIC1B instead of STPMIC1A or reprogram the STPMIC1x NVM to have a default buck3 to 1.8V.

Regard.

[Navaneeth kumar]

Hello,

Thanks for your replay.

we are using STPMIC1B ,but we need to change values in TF-A software. why because after programming PMIC we need to flash software, with TF -A software the values are modified, so we need to change voltage in TF-A software.

Is there any approach to do this?

Regard.

[PatrickF]

Hi,

I did not fully catch your requirements and concerns, it seems you are trying to do something away from standard way of working of our SW deliveries..

If you are using STPMIC1B (with its default NVM content), buck3 will start at 1.8V, which seems what you ask for. So, no need to change TF-A DT (which should be 1.8V anyway to be aligned with STPMIC1B buck3).

TF-A is limited in size (as it reside in SYSRAM) and it has limited control from DT to mostly start DDR supplies and init DDR in order to being able load SSBL in DDR (uBoot usually).

TF-A is not flashing the software, it is a task managed by uBoot (which has larger control from DT and probably full control for STPMIC1 supplies).

I'm not SW expert, I guess that if TF-A is not working as you want, either you change your SW architecture to go back to a more usual way or you could change TF-A code to tailor to your SW architecture choice (but TF-A size is limited).

See https://wiki.st.com/stm32mpu/wiki/TF-A_BL2_overview

Regards.

[Kevin HUBER]

Hello @Navaneeth kumar​ ,

First question, on which ecosystem are you? Because ST didn't delivered TF-A 2.5.

On ecosystem 3.1, it was TF-A 2.4

then on ecosystem 4.0 - 4.1, TF-A version is 2.6.

Please can you clarify which OpenSTLinux version you are using?

---

Regarding your problem, please can you send us the dtb files that you generated during the build.

The files related to your board.

They are usually located in "deploy" folder of the TF-A and there are usually 3 files.

For example, for MP157F-DK2 board, the filenames are:

• stm32mp157f-dk2-bl32.dtb
• stm32mp157f-dk2-fw-config-optee.dtb
• stm32mp157f-dk2-fw-config-trusted.dtb

Please send us the files that you are able to find, it will help us to understand the problem.

Best Regards,

Kevin