Immediate runtime exception in BL31

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Immediate runtime exception in BL31

Jump to solution
274 Views
minersrevolt
Contributor III

I have a custom board built around the S32G3. I am attempting to get into U-Boot. I can successfully load into BL2 and complete execution of that entire codebase. As soon as it goes into BL31 I get a runtime exception @ 0xff6000424. 

Adding a breakpoint at the start of bl31_main.c the application will immediately crash and go here.

Any idea why this might be the case?

0 Kudos
Reply
1 Solution
217 Views
alejandro_e
NXP TechSupport
NXP TechSupport

For what I can see, the address to load the BL31 is defined in bl31/bl31.ld.S, as BL31_BASE

alejandro_e_0-1726086946883.png

this comes from the following nested definitions:

plat/nxp/s32/s32cc/include/s32cc_platform_def.h:134:#define BL31_BASE (S32_PMEM_START)
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:129:#define S32_PMEM_START (S32_PMEM_END - S32_PMEM_LEN + 1)
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:127:#define S32_PMEM_END (BL33_BASE - 1)
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:112:#define BL33_BASE (S32_DDR0_END - S32_BL33_IMAGE_SIZE - \
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:94:#define S32_DDR0_END 0xffffffff

 

note that this last definition depends on S32_PLATFORM_DDR0_END

alejandro_e_1-1726087186168.png

 

It could be that the top of your ram does not match address 0xffffffff and this is generating the problem. You could define your own S32_PLATFORM_DDR0_END to match your RAM addresses, this in turn, would change S32_DDR0_END as you can see in the image above.

 

Let me know if this information was useful

View solution in original post

3 Replies
240 Views
alejandro_e
NXP TechSupport
NXP TechSupport

Hello @minersrevolt ,

We are unable to provide full support for custom designs through this channel. With that said, to be able to help you I need to know if you are using an specific BSP version as base to setup your system or are you using the latest components available in the nxp-auto-linux GitHub? 

I can also recommend to post your problem in the arm community since it is related to the arm trusted firmware.

0 Kudos
Reply
235 Views
minersrevolt
Contributor III

I am using the bsp40.0-2.5 release of the arm-trusted firmware. Additionally the BL2 loads BL31 at 0xff600000 but cannot find in the AT-F code base where this is called out. Simply a single define for a board that I am not using anywhere. 

0 Kudos
Reply
218 Views
alejandro_e
NXP TechSupport
NXP TechSupport

For what I can see, the address to load the BL31 is defined in bl31/bl31.ld.S, as BL31_BASE

alejandro_e_0-1726086946883.png

this comes from the following nested definitions:

plat/nxp/s32/s32cc/include/s32cc_platform_def.h:134:#define BL31_BASE (S32_PMEM_START)
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:129:#define S32_PMEM_START (S32_PMEM_END - S32_PMEM_LEN + 1)
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:127:#define S32_PMEM_END (BL33_BASE - 1)
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:112:#define BL33_BASE (S32_DDR0_END - S32_BL33_IMAGE_SIZE - \
plat/nxp/s32/s32cc/include/s32cc_platform_def.h:94:#define S32_DDR0_END 0xffffffff

 

note that this last definition depends on S32_PLATFORM_DDR0_END

alejandro_e_1-1726087186168.png

 

It could be that the top of your ram does not match address 0xffffffff and this is generating the problem. You could define your own S32_PLATFORM_DDR0_END to match your RAM addresses, this in turn, would change S32_DDR0_END as you can see in the image above.

 

Let me know if this information was useful