cancel
Showing results for 
Search instead for 
Did you mean: 

linux-5.4.31 stuck on boot in start_kernel()/arch_cpu_idle()

mrnuke
Associate II

I'm trying to build linux-5.4.31 for stm32mp1c-ev1 (tag: v5.4-stm32mp-r1). u-boot loads the kernel successfully, but then nothing happens. I've gone in with GDB, and noticed that the kernel is stuck in start_kernel(), and never leaves it.

What is the fix for this?

#0 cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:78

#1 0xc010a1a4 in arch_cpu_idle () at arch/arm/kernel/process.c:71

#2 0xc0158064 in cpuidle_idle_call () at kernel/sched/idle.c:154

#3 do_idle () at kernel/sched/idle.c:263

#4 0xc01583d8 in cpu_startup_entry (state=CPUHP_ONLINE) at kernel/sched/idle.c:355

#5 0xc0acb5b8 in rest_init () at init/main.c:451

#6 0xc0f00a40 in arch_call_rest_init () at init/main.c:573

#7 0xc0f00f10 in start_kernel () at init/main.c:785

#8 0x00000000 in ?? ()

5 REPLIES 5
mleo
Senior II

Hello @mrnuke​ ,

I only tried to build the kernel from downloaded file:

https://wiki.st.com/stm32mpu/wiki/STM32MP1_Developer_Package#Downloading_the_Linux_kernel

following this instructions (patches, configs, ..)

https://github.com/STMicroelectronics/meta-st-stm32mp/blob/dunfell/recipes-kernel/linux/linux-stm32mp/README.HOW_TO.txt

Could you try the same approach?

In the meantime I'll try rebuild the kernel from github.

Best regards,

Milan

mrnuke
Associate II

Hi @mleo​ .

I tried with the tarball. I did apply the patches and config fragments. I got identical results.

mleo
Senior II

Hi @mrnuke​ ,

What version ofu-boot do you use? (It might not be compatible).

And just to be sure, could you share with us complete log?

Regards,

Milan

mrnuke
Associate II

Hi @mleo​ ,

I tried both the u-boot from the meta-st-stm32mp build, and git.denx.de master (commit 99c6953809 ), with the same results.

I noticed that the problem exhibits when using u-boot SPL, but not with TF-A. I went ahead and bisected the stm branch and found the following commit to introduce the issue:

* 21165f3ebcd4 ARM: dts: stm32: move clocks/resets to SCMI resources for stm32mp15

This makes no sense to me. Is there a reason it would work with one bootloader, but not the other?

fpoussin
Associate III

I have the exact same problem with the v5.4-stm32mp-r1 github release

I am using vanilla uboot 2020.04

Booting a vanilla kernel works fine, only this one freezes.

Edit: reverting commit 21165f3ebcd4 fixes the problem