barebox I2C4 access

[RGlie.1]

Hello,

we try to access the I2C4-Bus under barebox, we use:

CPU: STM32MP151CAA Rev.Z

TF-A: v2.4-r1.0-nofip(release):b5d0088b9-dirty

barebox: barebox 2021.04.0-02204-gaa9b7b34b8e-dirty

In the TF-A the I2C4 is unlocked by:

DECPROT(STM32MP1_ETZPC_I2C4_ID, DECPROT_NS_RW, DECPROT_UNLOCK)

When I start the board the TF-A initializes the PMIC successfully via

I2C4-bus.

The Pinmux for I2C4 is:

   i2c4_pins_a: i2c4-0 {

      pins {

         pinmux = <STM32_PINMUX('H', 11, AF4)>, /* I2C4_SCL */

               <STM32_PINMUX('H', 12, AF4)>; /* I2C4_SDA */

         bias-disable;

         drive-open-drain;

         slew-rate = <0>;

      };

   };

the bus setup is:

&i2c4 {

   pinctrl-names = "default";

   pinctrl-0 = <&i2c4_pins_a>;

   i2c-scl-rising-time-ns = <185>;

   i2c-scl-falling-time-ns = <20>;

   clock-frequency = <100000>;

   status = "okay";

   secure-status = "okay";

   pmic: stpmic@33 {

      compatible = "st,stpmic1";

      reg = <0x33>;

      interrupts-extended = <&exti_pwr 55 IRQ_TYPE_EDGE_FALLING>;

      interrupt-controller;

      #interrupt-cells = <2>;

      status = "okay";

      secure-status = "okay";

regulators {

...

};

};

};

Settings in TF-A and barebox are identical.

I we try to access the I2C4-bus nothing happens,

that means the signals SDA and SCL remain on high-level.

On the other bus I2C2 I can access all I2C-devices without problems.

Are we missing some settings to get I2C4 working ?

best regards

Ralf

[AFato.1]

What happens if you boot Linux afterwards? Can it access i2c4?

The other boards supported upstream in barebox use the stpmic on i2c4, so this works in general. What's different at your side is secure-status. Does this perhaps mean that the peripheral is only accessible to the secure world? barebox runs after TF-A and doesn't have direct access to secure world peripherals (if it did, it would defeat the point of having secure world peripherals in the first place).

[RGlie.1]

Hello,

under Linux I can access I2C4 without problems.

I suppose in TF-A the call

DECPROT(STM32MP1_ETZPC_I2C4_ID, DECPROT_NS_RW, DECPROT_UNLOCK)

unlocks the access to the nonsecure world and we can use I2C4 under barebox.

greetings

Ralf

[AFato.1 · Accepted solution]

Just to be sure: You are using upstream TF-A right, not ST's fork?

We have barebox with v2.4 TF-A working here, but without using ETZPC.

My guess would be that while you unlock the i2c peripheral, rcc (clock and reset controller) remains exclusive to TF-A.

Could you try with secure-status = "disabled"?

[RGlie.1]

Hello,

thanks to your answer we are now able to boot via tf-a 2.5 and barebox the linux kernel.

With

&rcc {

   secure-status = "disabled";

...

};

we are able to access i2c4.

Thank you,

greetings Ralf