cancel
Showing results for 
Search instead for 
Did you mean: 

BL32 does not start

kiichi
Associate III

Custom STM32MP151A board with 512MB DDR2.

I am trying to write via UART communication with STM32CubeProgrammer, but BL32 processing does not start.

What should I do to investigate the cause?

 

[2024-01-12 14:11:52.591] NOTICE: CPU: STM32MP151AAC Rev.Z
[2024-01-12 14:11:52.591] NOTICE: Model: STMicroelectronics custom STM32CubeMX board - openstlinux-5.15-yocto-kirkstone-mp1-v22.11.23
[2024-01-12 14:11:52.623] INFO: PMIC version = 0x21
[2024-01-12 14:11:52.623] WARNING: VDD unknown
[2024-01-12 14:11:52.623] INFO: Reset reason (0x14):
[2024-01-12 14:11:52.696] INFO: Pad Reset from NRST
[2024-01-12 14:11:52.696] INFO: FCONF: Reading TB_FW firmware configuration file from: 0x2ffe2000
[2024-01-12 14:11:52.696] INFO: FCONF: Reading firmware configuration information for: stm32mp_io
[2024-01-12 14:11:52.696] INFO: Using UART
[2024-01-12 14:11:52.696] INFO: Instance 8
[2024-01-12 14:11:52.696] INFO: Boot used partition fsbl1
[2024-01-12 14:11:52.696] NOTICE: BL2: v2.6-stm32mp1-r2.0(debug):v2.6-dirty(a1f02f4f)
[2024-01-12 14:11:52.696] NOTICE: BL2: Built : 13:14:26, Nov 23 2021
[2024-01-12 14:11:52.696] INFO: BL2: Doing platform setup
[2024-01-12 14:11:52.696] INFO: RAM: LPDDR2 32bits 360000kHz
[2024-01-12 14:11:52.696] INFO: Memory size = 0x20000000 (512 MB)
[2024-01-12 14:11:52.711] INFO: UART: read phase 3 at 0xc7000000 size 0x1000000
[2024-01-12 14:13:19.102] WARNING: UART: Bad packet number receive: 13500416, expected 1331
[2024-01-12 14:14:04.514] WARNING: UART: Bad packet number receive: 13500416, expected 2039
[2024-01-12 14:16:39.908] INFO: UART: Start phase 3
[2024-01-12 14:16:40.047] INFO: BL2: Loading image id 1
[2024-01-12 14:16:40.047] INFO: Loading image id=1 at address 0x2ffff000
[2024-01-12 14:16:40.047] INFO: Image id=1 loaded: 0x2ffff000 - 0x2ffff226
[2024-01-12 14:16:40.047] INFO: FCONF: Reading FW_CONFIG firmware configuration file from: 0x2ffff000
[2024-01-12 14:16:40.047] INFO: FCONF: Reading firmware configuration information for: dyn_cfg
[2024-01-12 14:16:40.047] INFO: FCONF: Reading firmware configuration information for: stm32mp1_firewall
[2024-01-12 14:16:40.047] INFO: BL2: Loading image id 4
[2024-01-12 14:16:40.047] INFO: Loading image id=4 at address 0x2ffc5000
[2024-01-12 14:16:40.047] INFO: Image id=4 loaded: 0x2ffc5000 - 0x2ffd9820
[2024-01-12 14:16:40.047] INFO: BL2: Skip loading image id 8
[2024-01-12 14:16:40.047] INFO: BL2: Skip loading image id 9
[2024-01-12 14:16:40.047] INFO: BL2: Loading image id 2
[2024-01-12 14:16:40.047] INFO: Loading image id=2 at address 0xc0500000
[2024-01-12 14:16:40.047] INFO: Image id=2 loaded: 0xc0500000 - 0xc0511688
[2024-01-12 14:16:40.047] INFO: BL2: Loading image id 16
[2024-01-12 14:16:40.047] INFO: Loading image id=16 at address 0x2ffc0000
[2024-01-12 14:16:40.047] INFO: Image id=16 loaded: 0x2ffc0000 - 0x2ffc4039
[2024-01-12 14:16:40.047] INFO: BL2: Loading image id 5
[2024-01-12 14:16:40.047] INFO: Loading image id=5 at address 0xc0100000
[2024-01-12 14:16:40.047] INFO: Image id=5 loaded: 0xc0100000 - 0xc01ece88
[2024-01-12 14:16:40.048] NOTICE: BL2: Booting BL32
[2024-01-12 14:16:40.048] INFO: Entry point address = 0x2ffc5000
[2024-01-12 14:16:40.048] INFO: SPSR = 0x1d3
[2024-01-12 14:16:40.284] PANIC at PC : 0x2ffc98b1
[2024-01-12 14:16:40.284]
[2024-01-12 14:16:40.284] Exception mode=0x00000016 at: 0x2ffc98b1

21 REPLIES 21
PatrickF
ST Employee

Usually this is due to DDR not working (missing HSE, missing supplies, bad configuration, PCB issues, etc...).

To test DDR, please have a look to
https://wiki.st.com/stm32mpu/wiki/STM32DDRFW-UTIL

Regards.

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.

BL32 is located from address 0x2ffc500, so I guess it has nothing to do with DDR ?.

Is, but as far as I know, BL32 is in charge of initializing the DDR and loading uBoot on it.
https://wiki.st.com/stm32mpu-ecosystem-v4/wiki/Boot_chain_overview#Overview_2

 

It is anyway highly recommended to ensure DDR is working (using DDRFWUTIL) as first step during board bring up.

Regards.

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.

Btw, did you exclude the classic pitfall around HSE bypass if you are using 24MHz crystal (VS our board using oscillator) ?
See https://community.st.com/t5/stm32-mpus/stm32mp1-bring-up-troubleshooting-guide/ta-p/49272

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.

I tried to access the following page, but it says "Page not found".

  -Check HSE source configuration issue
  ROM CODE makes auto detection of the HSE configuration (crystal or oscillator).

  If TF-A reconfigures wrongly it can stop after reconfiguration.

  See https://wiki.st.com/stm32mpu/wiki/Clock_device_tree_configuration_-_Bootloader_specific

Is there any other information that would be helpful?

Sincerely,
Kiichi

I have a question.

In EV1 board, “NOTICE: SP_MIN:” will be displayed on the console as shown below.

  [EV1 board]

 NOTICE: BL2: Booting BL32
 INFO: Entry point address = 0x2ffc5000
 INFO: SPSR = 0x1d3
 NOTICE: SP_MIN: v2.6-stm32mp1-r2.0(debug):v2.6-dirty(a1f02f4f) 
 NOTICE: SP_MIN: Built : 13:14:26, Nov 23 2021

I think it is displayed in the first processing of the sp_min_main() function.

 

On our custom board, "PANIC" is displayed on the console as shown below, and "NOTICE: SP_MIN:" is not displayed on the console.

 [costom board]

 NOTICE: BL2: Booting BL32
 INFO: Entry point address = 0x2ffc5000
 INFO: SPSR = 0x1d3
 PANIC at PC: 0x2ffc98b1
 Exception mode=0x00000016 at: 0x2ffc98b1

Is it correct to assume that the sp_min_main() function is not being executed?

Sincerely,
Kiichi

The following function terminates abnormally (NULL).
Please give me a hint as to the cause.

 

struct rdev *dt_get_cpu_regulator(void)
{
int node = fdt_path_offset(fdt, "/cpus/cpu@0");
 
if (node < 0) {
return NULL;
}
 
return regulator_get_by_supply_name(fdt, node, "cpu");
}

After correcting the device tree, the dt_get_cpu_regulator() function became normal. However then FAIL_ID = 0x4c0 occurs.

What's wrong with my device tree?

Any suggestion is appreciated! Thanks!

hi @kiichi 

"Illegal access to 0xe0000000" sound like there is some issue with DDR size in between all the modules. I think you have some definitions which still define 1GBytes of DDR whereas only 512MB are defined on other places.

Maybe this wiki could help, even if intended for 256MB, it could give you some hints where to look at:

https://wiki.st.com/stm32mpu/wiki/How_to_configure_a_256MB_DDR_mapping_from_STM32_MPU_Distribution_Package

 

Regards.

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.