How to use I2C1 in TF-A to control STPMIC1?

[NBhat.1]

In our custom board we are using I2C1 to control and configure STPMIC1. I'd like to use I2C1 in TF-A so PMIC can be configured to power DDR during boot. I2C1 is not supported by default in TF-A, but looks like there is a way to do it as described in

https://wiki.st.com/stm32mpu/wiki/PMIC_hardware_components#TF-A

I followed the procedure described in the above link, but still when I include the reference to &i2c1 in my stm32mp153c-<project>.dts it throws the following build error

| Building stm32mp1

| Error: fdts/stm32mp153c-<project name>.dts:355.1-6 Label or path i2c1 not found

| FATAL ERROR: Syntax error parsing input tree

Am I missing something?

Thanks,

Nikhil

[Olivier GALLIEN]

Hi @NBhat.1​ ,

Could you please tell me if you are using ecosystem release V1.2 Openstlinux-20-02-19 ( Kernel 4.19, Yocto Thud) or V2.0 Openstlinux-5.4-dunfell-mp1-20-06-24 ( Kernel 5.4, Yocto Dunfell) ?

Thanks,

Olivier

[Olivier GALLIEN]

Also please share complete  fdts/stm32mp153c-<project name>.dts

Thx

[NBhat.1]

@Community member​ 

We are using V2.0 Openstlinux-5.4-dunfell-mp1-20-06-24 ( Kernel 5.4, Yocto Dunfell) . Since we were having build issue with I2C1 in TF-A, we moved to I2C4 on PH11 and PH12 pins. We also have pmic node under i2c4 as described in https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.2-stm32mp/fdts/stm32mp15xx-dkx.dtsi, however on bootup we don't see DDR getting powered (no voltage on VDD_DDR).

Also, when the board boots from SDcard, this is all we see in the terminal window, does this look right or are we missing something in the clock tree configuration:

NOTICE: CPU: STM32MP153CAA Rev.B

NOTICE: Model: STMicroelectronics custom STM32CubeMX board

INFO:  Reset reason (0x15):

INFO:   Power-on Reset (rst_por)

INFO:  PMIC version = 0x21

INFO:  Using SDMMC

INFO:   Instance 1

INFO:  Boot used partition fsbl1

NOTICE: BL2: v2.2-r1.0(debug):v2.2-dirty

NOTICE: BL2: Built : 13:36:23, Oct 22 2019

Attached is the dts file. You will need to unzip before using it.

[TWest.2]

@Community member​ 

Last night we traced the output on the I2C and the driver is clearly talking coherently to the PMIC:

There is no reason why it is stopping after just the BUCK1 test. It conforms to the configuration file requirements, so that test should pass, and it should move on to BUCK2, but it does not.

We are using https://github.com/STMicroelectronics/arm-trusted-firmware/tree/v2.2-stm32mp/drivers/st/pmic that is 5months old, however there is a patch file that is applied to this and we believe the patch file has a bug or something. While it is difficult to look at the patch file and see what changed, one thing is very clear that the enumeration-loop of the different regulators has been re-organized significantly. I wish there was a way to look at the post-patch pmic.c file so we could follow the new logic of node-by-node PMIC enumeration! (do you know a way of seeing the post-patch source file?). But clearly something in this code was changed significantly and is not working.

We are dead in the water here until we get some support on what is going on in the post-patch pmic.c. Our hardware and config look very clean, so we are at a loss what to do next.

Terry West, CEO, Serious Integrated

[TWest.2]

We made our first breakthrough. Not there yet, but much better.

We did not have the Hash and RNG (random number generated) in the device tree enabled. by enabling that, we get much further. It is very frustrating there is no error message or anything that this is required...

​

NOTICE: CPU: STM32MP153CAA Rev.B

NOTICE: Model: STMicroelectronics custom STM32CubeMX board

INFO:   Reset reason (0x15):

INFO:     Power-on Reset (rst_por)

INFO:   PMIC version = 0x21

INFO:   Using SDMMC INFO:     Instance 1

INFO:   Boot used partition fsbl1

NOTICE: BL2: v2.2-r1.0(debug):v2.2-dirty

NOTICE: BL2: Built : 13:36:23, Oct 22 2019

INFO:   Using crypto library 'stm32_crypto_lib'

INFO:   BL2: Doing platform setup

INFO:   RAM: DDR3-DDR3L 16bits 400000Khz

INFO:   Memory size = 0x10000000 (256 MB)

INFO:   BL2 runs SP_MIN setup

INFO:   BL2: Loading image id 4

INFO:   Loading image id=4 at address 0x2ffed000

INFO:   Image id=4 loaded: 0x2ffed000 - 0x2ffff000

INFO:   BL2: Loading image id 5

INFO:   Loading image id=5 at address 0xc0100000

INFO:   STM32 Image size : 848538

INFO:   Image id=5 loaded: 0xc0100000 - 0xc01cf29a

ERROR:  BL2: Failed to load image (-80)

and we now have VDD_DDR at 1.35V and VTT_DDR at 0.675V, so the PMIC is alive!

but... obviously the image is not loading into DDR3... any ideas now on this issue?

Terry & Nikhil

[TWest.2]

Turns out error -80 is:

EAUTH (80) Authentication error!

​"A certificate or image could not be authenticated when Trusted board boot is enabled"

So we did a quick build turning this

TRUSTED_BOARD_BOOT := 1

to 0. But it did not work, so we’re doing a full re-build with that := 0 and we’ll know in about 2 hours if that worked.

Basically the error was saying “yes, you’re loading code, but it is not trusted because there is no certificate/not signed so we’re not going to run it�?.

Please let us know if just turning off this TRUSTED_BOARD_BOOT := 0 is all we need to do to run in non-trusted mode for now. 

 

We just need to get UBOOT up and running then the kernel and graphics and then we hit our first big shipment milestone and that shows the hardware is solid.

Terry

[Olivier GALLIEN]

​Hi @TWest.2​ , @NBhat.1​ ,

Since the problem was too complex to be addressed trough community I manage to get you in direct touch with local ST people @Greg DAVIS​ .

I'm confident that this will help to get you out of the situation shortly.

No more need to udpate this post along your investigation.

Once fixed, we will share here solution for benefit of all the community

BR,

Olivier

[Olivier GALLIEN]

Hi @TWest.2​ , @NBhat.1​ ,

Thanks to local support you finally succeed to boot.

As summarize for community :

>> ERROR:  BL2: Failed to load image (-80)

Was due to missing &nvmem_layout in your board device, giving pkh_otp address to be used by TF-A.

Even if not really a bug, it has been decided to prevent this issue in next TF-A release. ( delivered in next V2.1 ecosystem release )

Note that this is not answering initial post.

Do you still target to use I2C1 instead of I2C4 ?

Olivier

[NBhat.1]

HI @Community member​ ,

We decided to use I2C4 to control PMIC.

Thanks,

Nikhil