Skip to main content
R
RGlie.1
Visitor II
June 17, 2021
Solved

barebox I2C4 access

  • June 17, 2021
  • 3 replies
  • 1615 views

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

    This topic has been closed for replies.
    Best answer by AFato.1

    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"?

    3 replies

    A
    AFato.1
    Visitor II
    June 21, 2021

    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).

    R
    RGlie.1Author
    Visitor II
    June 21, 2021

    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

    A
    AFato.1Answer
    Visitor II
    June 30, 2021

    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"?

    R
    RGlie.1Author
    Visitor II
    July 1, 2021

    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

    Terms & ConditionsAccessibility statement