2020-10-05 04:49 PM
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
Solved! Go to Solution.
2020-10-15 02:43 AM
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
2020-10-07 01:58 AM
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
2020-10-07 02:07 AM
Also please share complete fdts/stm32mp153c-<project name>.dts
Thx
2020-10-07 11:21 AM
@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.
2020-10-07 12:26 PM
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
2020-10-07 11:50 PM
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
2020-10-08 08:59 AM
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
2020-10-08 09:17 AM
@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
2020-10-08 10:40 AM
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
2020-10-08 12:48 PM
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