Configuring ETZPC in the TF-A device tree issue

[Paradox]

Hi,

According to this link https://wiki.st.com/stm32mpu/wiki/ETZPC_device_tree_configuration#DT_configuration_-28board_level-29

it is possible to configure the ETZPC peripheral in the device tree of TF-A. I am using a distribution package, so I modified and built the tf-a-stm32mp recipe using devtool. However, by adding the lines mentioned in the wiki link into TF-A device tree, the STM freezes on boot and doesnt respond, the only way is to flash the backup image in fsbl2 partition. I have added following lines in the stm32mp157c-dk2.dts file in the fdts directory:

&etzpc {
	st,decprot = <
		DECPROT(STM32MP1_ETZPC_I2C5_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
	>;
};

I want to isolate the I2C5 peripheral for the Cortex M4 only, but without any luck. Is there any other configuration I am missing? Or perhaps it is the wrong file to edit?

[Fee · Accepted solution]

Hi,

I only did assign a peripheral to the Trustzone yet using OP-TEE so I don't know about doing it via TF-A (I assume it works the same like the wiki states).

When I did assosiate a peripheral which was used in Linux to the Trustzone it didn't boot too (was hanging up at some point and not responding any more cause the linux kernel couldn't address teh peripheral).

Are you maybe using the I2C5 peripheral in software running on the A7 cores?

The stm32mp157c-dk2.dts file should be the right one, be sure that you also put the things from the stm32mp157c-dk1.dts in there. As far as I understood it (by decompiling the binary device-tree blob) the macro overwrites the entries in the stm32mp157c-dk1.dts file (which is included in the *dk2.dts file). So it should look something like this in your dk2.dts:

&etzpc {
	st,decprot = <
		DECPROT(STM32MP1_ETZPC_USART1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
		DECPROT(STM32MP1_ETZPC_SPI6_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
		DECPROT(STM32MP1_ETZPC_I2C4_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
		DECPROT(STM32MP1_ETZPC_I2C6_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
		DECPROT(STM32MP1_ETZPC_RNG1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
		DECPROT(STM32MP1_ETZPC_HASH1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
		DECPROT(STM32MP1_ETZPC_CRYP1_ID, DECPROT_NS_RW, DECPROT_UNLOCK)
                DECPROT(STM32MP1_ETZPC_I2C5_ID, DECPROT_MCU_ISOLATION, DECPROT_UNLOCK)
	>;
};

Hope it helps you.

[Paradox]

Hello Fee,

thank you very much for reply. I have tried to add the last DECPROT line straight into the stm32mp157a-dk1.dts file since it is anyway imported by the dk2 dts. I managed to boot afterwards, it seems like the issue before was not including the other DECPROT lines in the dk2 file. However, now I am trying to confirm that the peripheral is really isolated and correctly assigned to the M4 exclusively. For that I have used resource manager, which should lead me to error handler if it is not properly assigned. The code is according to STM wiki like this:

ResMgr_Init(NULL, NULL);
if (ResMgr_Request(RESMGR_ID_I2C5, RESMGR_FLAGS_ACCESS_NORMAL | RESMGR_FLAGS_CPU1, 0, NULL) != RESMGR_OK)
{
	Error_Handler();
}

The interesting thing is, that no matter if the result does not equal RESMGR_OK (!=) or equals (==), the error handler is called in both cases. I really doubt that this is the correct behavior and I am unsure if it is correctly configured. Other peripherals, eg. I2C2 behave normally, the error handler is not called. If I understand it correctly, when it is properly isolated, the error handler should be called only when result is OK, because then it would be accessible by the A7. Is there any other way to check the isolation?

[Fee]

Hi Paradox,

I am not familiar with the ressource manager. What you could do is using the I2C5 in the linux device tree so it is probed. If the isolation is right you should see a error on the boot up (probably preventing linux to boot at all!).

You also could try to read out the according ETZPC peripheral registers in your program yourself.

[Paradox]

Hello Fee,

thank you very much for your advices, it is very much appreciated. I finally managed to confirm the isolation by enabling the I2C5 peripheral in the Linux device tree and then setting the isolation in TF-A. Afterwards, the kernel was unable to boot and it "panicked", where the error had something to do with the I2C probing, which is what I was hoping for. I would like to note that the aforementioned resource manager is very unreliable and it kept giving me different results, which is why I decided to abandon that way of verification completely. Maybe there was something wrong with my project which caused it to behave so weirdly, but anyway, now I have found a better solution.

Thank you very much again, hope you have a great day.