OP-TEE on STM32MP153CAB board

[UVV]

Could you please clarify the pinctrl_z assignment in the device tree?

The thing is, OP-TEE panics in shared_resources.c:142 <get_gpioz_nbpin> when I don't define in the device tree something like this:

&pinctrl_z {
    st,package = <STM32MP_PKG_AC>;

    gpioz: gpio@54004000 {
        status = "okay";
        ngpios = <8>;
        gpio-ranges = <&pinctrl_z 0 400 8>;
    };
};

Even though this is an assignment for AC package, and not the AB I have.

[james-cc]

Yes I saw this too with our STM32MP157DAB device which also does not have gpioz pins.

I ended up patching the optee firmware in `core/arch/arm/plat-stm32mp1/shared_resources.c` and changed the gpioz_nbpin initialisation to 0 rather than -1.  I have an empty `&pinctrl_z` section in the dt.

The warnings "I/TC: WARNING: apply pinctrl for secure pin xx that is non-secure" are getting annoying too, so I fear another patch.

---

[MScor.1]

Just reporting that we have the same issue on a custom board based on the STM32MP151AAB, and that your patch works, thank you @james-cc 

A bit concerning that a bug that breaks the bootchain for a whole class of MPU packages wouldn't have been spotted, I guess OpenSTLinux doesn't get boot-tested on MPUs in that package type?

[MScor.1]

Oh, a similar situation is present in the `stm32mp157-pinctrl` kernel driver, too; it's not as serious there because you just get an error in the logs and then everything goes ahead.

We are currently silencing that warning by having the dummy `pinctrl_z` node that @UVV suggested.