cancel
Showing results for 
Search instead for 
Did you mean: 

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

NBhat.1
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions
Olivier GALLIEN
ST Employee

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

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

12 REPLIES 12
Olivier GALLIEN
ST Employee

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
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

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

Thx

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

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

Also, when I connect the JTAG debugger, the PC is stuck at 0x2FFD695C

PC: (R15) = 2FFD695C, CPSR = 600000D3 (SVC mode, ARM FIQ dis. IRQ dis.)

Current:

   R0 =59067722, R1 =40010000, R2 =08A000C0, R3 =00000F02

   R4 =2FFE6E73, R5 =00000000, R6 =2FFD8973, R7 =2FFD6760

   R8 =2FFD6958, R9 =00000016, R10=2FFD6000, R11=00000000, R12=2FFE8B50

   R13=2FFC1BC8, R14=0000F28D, SPSR=052DA178

USR: R8 =2FFD6958, R9 =00000016, R10=2FFD6000, R11=00000000, R12=2FFE8B50

   R13=D6EEF6C5, R14=8CFDF2EE

FIQ: R8 =7DEFE9D9, R9 =CAD67617, R10=6ED96AC3, R11=E9B973FB, R12=8EC575E9

   R13=D8A7E7C6, R14=BEF1FFC7, SPSR=01088E35

IRQ: R13=2FFC18F0, R14=7FEEB89C, SPSR=290F4827

SVC: R13=2FFC1BC8, R14=0000F28D, SPSR=000001D3

ABT: R13=2FFC0570, R14=2D38F7EC, SPSR=A805DC24

UND: R13=2FFC05F0, R14=6BFE5034, SPSR=59067722

Hi @Community member,

Your help is really appreciated. We can't figure out why it's not configuring PMIC over I2C4. We have traces connected to I2C4 SCL and SDA on the board, and all we see is that it reads from Buck 1 (value 0x61) and reads PMIC version number from reg 0x6 (value 0x21). Doesn't look like the pmic node from the device tree is being used in setting up Buck2 for DDR. Are we missing some configuration in the device tree or some where else? We are stuck!

Thanks,

Nikhil

Hello @Community member​ ,

Did you get a chance to look at my replies. Any suggestions on how to go further with PMIC configuration and platform setup? What does it mean if all we see during boot is following messages and it stops after that?

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

and PC: (R15) = 2FFD695C

Thank you,

Nikhil

TWest.2
Associate II

@Community member​ 

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

0693W000004JAFUQA4.jpg

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
Associate II

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
Associate II

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