Panic during custom board bring-up

[SKris]

We are trying to bring-up our custom board and every step of the way we see panic messages, we need some direction in understanding what went wrong.

Our board has the following:

Processor: STM32MP157FACx

QSPI NAND flash memory is our boot device (AS5F18G04SND)

PMIC: STPMIC1B

DDR memory LPDDR - 32-bit - 128MB memory.

All the device trees were generated using the latest CubeMx.

Issue1:

We had he first panic when flashing partition 1. When the PMIC node in device tree was set as below for buck 1 it fails in flashing partition 1.

vddcore:buck1{

regulator-name = "vddcore";

regulator-min-microvolt = <1200000>;

regulator-max-microvolt = <1200000>;

regulator-always-on;

regulator-initial-mode = <0>;

regulator-over-current-protection;

};

However if I change it to the one below with the max voltage set to 1.35V it completes flashing partition 1 and fails in partition 3.

vddcore:buck1{

regulator-name = "vddcore";

regulator-min-microvolt = <1200000>;

regulator-max-microvolt = <1350000>;

regulator-always-on;

regulator-initial-mode = <0>;

regulator-over-current-protection;

};

We do not want to max voltage as 1.35V because our clock frequency will not be running at 800MHz. We will be limiting it to ~400MHz, so a 1.2V should be ideal.

Can someone help me understand why the ROM code causes panic when the buck 1 max voltage is not 1.35V?

Issue2:

When flashing partition 3, it causes the next panic where it is exiting to normal world, however its trying to access memory address beyond the DDR memory (size is 128MB = 0x8000000).

INFO:  SP_MIN: Preparing exit to normal world

ERROR:  Illegal access to 0xc8000000:

ERROR:     FAIL_ID = 0x4c0

ERROR:     Non-Secure

ERROR:     Privilege

ERROR:     Read

PANIC at PC : 0x2ffc9b61

Exception mode=0x00000016 at: 0x2ffc9b61

The DDR device tree was also generated by the latest CubeMx, so I'm assuming it should have done correctly, we are not able to figure out what is happening here.

Any help is much much appreciated.

Thanks!

[Olivier GALLIEN]

Hi @SKris​ ,

Issue 1 :

You are using STM32MP157FACx and so your dts tree might call stm32mp15xd.dtsi in which you have :

&cpu0_opp_table {
		opp-800000000 {
			opp-hz = /bits/ 64 <800000000>;
			opp-microvolt = <1350000>;
			opp-supported-hw = <0x2>;
		};
		opp-400000000 {
			opp-hz = /bits/ 64 <400000000>;
			opp-microvolt = <1200000>;
			opp-supported-hw = <0x2>;
			opp-suspend;
		};
};

This means that TF-A will switch system to 800Mhz requiring 1.35V.

I don't know how you get regulator-max-microvolt = <1200000>; but it's wrong.

To work @400Mhz you can change this to keep only the opp-400000000 and remove opp-suspend.

or call stm32mp15xa.dtsi instead which will define single 650Mhz operation point.

Issue 2 :

Seems you have a problem with density definition of your memory.

Which version of CubeMX are you using and which version of OpenSTLinux ?

If version lower than Ecosystem 3.1, did you define and include a file such as stm32mp15-ddr-128m-fw-config.dts ?

Can you share dts ?

Thanks

Olivier

[SKris]

Hi Olivier,

Thanks for getting back.

Issue 1:

I had redefined opp_table in my device tree to use 400MHz and 300MHz, so it was set to use 400MHz @1.2V, which did not work, assuming that my device tree changes overwrite stm32mp15xd.dtsi opp_table. Correct me if I'm wrong.

Note: The device tree I have attached here has all my changes reverted, so you will see max voltage set back to 1.35V and the opp_table to default values. We had to do that to move forward to flashing partition 3.

Issue 2:

We are using Ecosystem 3.1 and the latest CubeMx generated 3 device trees in tf-a folder:

stm32mp15-mx.dtsi

stm32mp157f-nff-mx.dts

stm32mp157f-nff-mx-fw-config.dts

The contents of stm32mp157f-nff-mx-fw-config.dts are below:

#define DDR_SIZE 0x8000000 /* 128MB */

#include "stm32mp15-fw-config.dts"

Our Yocto build for tf-a uses the latest patch file which has the new DDR configuration changes. I have attached the only the main tf-a device tree here (stm32mp157f-nff-mx.dts) for your reference.

Also our DDR memory (size is 128MB = 0x8000000) and the logs shows its accessing memory out of bounds as below. I am assuming the DDR_SIZE in device tree should have taken care of all these, but looks like its not. Also I'm wondering why would it access the DDR memory at this point, is it checking if it can access it before flashing the rest of the partitions in the NAND?

INFO:  SP_MIN: Preparing exit to normal world

ERROR:  Illegal access to 0xc8000000:

Thanks.