Stuck at Data Abort at: 0x2fff3e20 DFSR = 0x00000206 DFAR = 0x3664647f in custom board bring up.

[damien1]

We are bringing up a custom board with LPDDR2 and no STPMIC. I have been following the bring up guide and have gotten past disabling I2C4 and fixing the HSE clock issue in the device tree. I have merged in quite a few things from dev kit 'working' devicetrees as well.

I am stuck at the following TF-A error though.

Data Abort at: 0x2fff3e20 DFSR = 0x00000206 DFAR = 0x3664647f

Abort at: 0x2ffe93a0

I have used devtool to modify the tf-a recipe and increase the DEBUG level but nothing I do makes any difference. I just get this error.

Attached is the flattened ftd from the TF-A build dir along with the cubemx generated set of devicetrees for tf-a.

[PatrickF]

Hi @damien1​ 

Could you provide complete serial console log ?

Are you booting from USB (using CubeProgrammer) or directly from Flash (e.g. SD-Card) ?

You might have a memory mapping issue as at STM32MP15 area pointed by DFAR = 0x3664647f there is nothing, so it sound logical to get a data abort.

Maybe your TF-A does not fit in SYSRAM for whatever reason (e.g. LOG_LEVEL too high).

You could also look at

https://wiki.st.com/stm32mpu/wiki/TF-A_BL2_overview

https://wiki.st.com/stm32mpu/wiki/How_to_debug_TF-A_BL2

Regards.

[damien1]

Hi, I had actually used devtool to modify the underlying recipe to increase the log level in case there was info I was missing. I have now reset the recipe and removed my .bbappend however the error persists.

NOTICE:  CPU: STM32MP157FAD Rev.Z
NOTICE:  Model: STMicroelectronics custom STM32CubeMX board - openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23
 
Data Abort at: 0x2fff3ef6 DFSR = 0x00000206 DFAR = 0x3664647f
 
Abort at: 0x2ffe93a0

Here is the serial trace. I'm flashing using the CLI version of CubeProgrammer using USB DFU with my board in USB mode Boot[2..0] = 000. I'm using the generated TSV file and the deploy/images root dir as the inputs to cubeprogrammer.

[PatrickF]

Hi @damien1​ 

strange to see a fail so fast during the boot.

Maybe something left regarding STPMIC1 controls in the SW.

Did you have run DDRFWUTIL? Useful to check DDR behavior, but could also be another way to run a basic SW than TF-A. DDRFWUTIL could be debug using CubeIDE (In Development boot BOOTt[2..0] = 0b100).

https://wiki.st.com/stm32mpu/wiki/STM32DDRFW-UTIL

https://github.com/STMicroelectronics/STM32DDRFW-UTIL/blob/main/README.md

Regards.

[damien1]

I've traced it through now and it is throwing this error in the initial code written in assembler. Part of the bl1_entrypoint.S

Decoding the DFSR = 0x206 yields the issue is a permission fault level 2. The DFAR register address of 0x3664647f looks to be in RAM Aliases. I'm not sure what this memory space is used for.

Why does the TF-A BL1 try and use memory in this range?

Thinking it could be something I'm doing I've refetched the entire distribution package, reinstalled CubeMX, created a new project, created new devicetrees, built everything fresh and still have the issue.

I'm really stuck.

[damien1 · Accepted solution]

Ok, I have figured it out. I had added 'fixed-regulator' definitions into my device tree and was referencing these in the &pwr_regulator nodes. For reasons unknown this caused BL1 to try and read memory it wasn't supposed to and was resulting the Data Abort. I stripped my device tree right back to basics. Turns out all I needed to add on top of what CubeMX provides is the &clk_hse { st, digbypass; }; element at the very bottom.

Some of the guides out there tell you to copy device tree nodes from the dev kit devictrees as CubeMX isn't sufficient for generating working devicetree's. I feel the guides / notes may be dated now given the current state of the ecosystem.