good old "DDR addr bus test: can't access memory @ 0xc0000004"

[petkan]

Hi everyone.  I'm tasked with porting ST's most recent TF-A, u-boot and kernel to a custom stm32mp151c-based board.  It runs 2021 version of the above SW components just fine.

It seems, however, that at some point the device-tree bindings changed and i can't just use the old DT in the latest TF-A.  I banged into shape the i2c section so TF-A can see STPMIC, regulators, etc. and it worked.  Up to the point:

INFO: RAM: DDR3-DDR3L 16bits 533000kHz
ERROR: DDR addr bus test: can't access memory @ 0xc0000004

I've put some debug printouts so i know the RAM size is properly read from DT.  The puzzling bit is that stm32mp_ddr_test_data_bus() passes successfully, while stm32mp_ddr_test_addr_bus() doesn't.

As i said, this board has been used in production environment for about four years now and most certainly don't have issues with the RAM.  This is software issue and if somebody can point me to whatever change in TF-A and/or its DT could have caused that, would be much appreciated.

 

thanks,

Petko

[Erwan SZYMANSKI]

Hello @petkan ,
The gap you have between the 2021 Ecosystem version and the latest one is really large. The BSP bootchain itself changed, now OP-TEE is a mandatory component to boot the platform.
I think you have to take the latest device-trees ST gives as reference (OpenSTLinux 6.0.0) for its Evaluation and Discovery kit to check the new deltas with your 2021 software.

Do you generate your build image with Yocto ?

Kind regards,
Erwan.

[petkan]

Hey Erwan, thanks for the quick response.  I already figured OP-TEE is mandatory and that i need to go with a new DT.  Which i did - i based it on stm32mp157c-ed1.dts (of the tf-a-stm32mp-v2.10.5-stm32mp-r1 release), which seems recent enough.

I extracted the TF-A sources from the SDK (not Yocto) and i am building the binary image with 'make'. :)  The image size is comparable with what can be found in the SDK so i guess no big chunk of the firmware is missing.  TF-A is running OK until it hit DDR setup.  Could this be related to access permissions?

I don't have good understanding if OP-TEE is already running at this point.  Does the minimal OP-TEE run from SRAM, while the rest of TF-A continues forward with initializing the rest of the peripherals?

 

thanks,

Petko

[Erwan SZYMANSKI]

Hello @petkan ,
For sure, OP-TEE is not launched at this very early TF-A step.

I ask myself, did you well update your own DDR device tree, as the logs I see seems to be very similar from the one we have by default in our ecosystem (see TF-A file stm32mp15-ddr3-1x4Gb-1066-binG.dtsi). Did you well update this DDR information with your own DDR specs (generated with the STM32CubeMX DDR Tool) ? By updating I mean include your own DDR dtsi in your sources and include it in your own board device tree.

Kind regards,
Erwan.

[petkan]

Hey,

The issue got resolved.  It was not due to DT misconfiguration, but a write to PMIC's master control register in drivers/st/pmic/stm32mp_pmic.c.  There's a call to stpmic1_powerctrl_on() which once commented out fixed the problem for this particular platform.

I am not sure why that is, because the project i'm on is on a very tight schedule.  Decided to mention it here as it might be of use for somebody else.

 

thanks,

Petko