U-boot 2023.01 not booting anymore MCR3000 board - Bisected 50128aeb0f8 ("cyclic: get rid of cyclic_init()")

U-boot 2023.01 not booting anymore MCR3000 board - Bisected 50128aeb0f8 ("cyclic: get rid of cyclic_init()")

[Christophe Leroy]

Hi,

I'm trying to boot MCR3000 board with U-boot 2023.01 and it crashes in 
the weed in fdtdec_setup().

I bisected the issue to commit 50128aeb0f8 ("cyclic: get rid of 
cyclic_init()")

At the time being I don't understand what happens.

The problem is here below, idx is in the weed, I don't know why, any idea ?

     htab=0x4050288 <env_htab>, flag=flag@entry=0x0) at lib/hashtable.c:313
313		if (htab->table[idx].used) {
=> 0x04032098 <hsearch_r+120>:	1f 9d 00 14	mulli   r28,r29,20
    0x0403209c <hsearch_r+124>:	81 3f 00 00	lwz     r9,0(r31)
    0x040320a0 <hsearch_r+128>:	7d 49 e2 14	add     r10,r9,r28
    0x040320a4 <hsearch_r+132>:	7d 29 e0 2e	lwzx    r9,r9,r28
    0x040320a8 <hsearch_r+136>:	2f 89 00 00	cmpwi   cr7,r9,0
    0x040320ac <hsearch_r+140>:	41 9e 01 00	beq     cr7,0x40321ac 
<hsearch_r+396>
(gdb) stepi
0x0403209c	313		if (htab->table[idx].used) {
    0x04032098 <hsearch_r+120>:	1f 9d 00 14	mulli   r28,r29,20
=> 0x0403209c <hsearch_r+124>:	81 3f 00 00	lwz     r9,0(r31)
    0x040320a0 <hsearch_r+128>:	7d 49 e2 14	add     r10,r9,r28
    0x040320a4 <hsearch_r+132>:	7d 29 e0 2e	lwzx    r9,r9,r28
    0x040320a8 <hsearch_r+136>:	2f 89 00 00	cmpwi   cr7,r9,0
    0x040320ac <hsearch_r+140>:	41 9e 01 00	beq     cr7,0x40321ac 
<hsearch_r+396>
(gdb) print $r31
$1 = 0x4050288
(gdb) stepi
0x040320a0	313		if (htab->table[idx].used) {
    0x04032098 <hsearch_r+120>:	1f 9d 00 14	mulli   r28,r29,20
    0x0403209c <hsearch_r+124>:	81 3f 00 00	lwz     r9,0(r31)
=> 0x040320a0 <hsearch_r+128>:	7d 49 e2 14	add     r10,r9,r28
    0x040320a4 <hsearch_r+132>:	7d 29 e0 2e	lwzx    r9,r9,r28
    0x040320a8 <hsearch_r+136>:	2f 89 00 00	cmpwi   cr7,r9,0
    0x040320ac <hsearch_r+140>:	41 9e 01 00	beq     cr7,0x40321ac 
<hsearch_r+396>
(gdb)
0x040320a4	313		if (htab->table[idx].used) {
    0x04032098 <hsearch_r+120>:	1f 9d 00 14	mulli   r28,r29,20
    0x0403209c <hsearch_r+124>:	81 3f 00 00	lwz     r9,0(r31)
    0x040320a0 <hsearch_r+128>:	7d 49 e2 14	add     r10,r9,r28
=> 0x040320a4 <hsearch_r+132>:	7d 29 e0 2e	lwzx    r9,r9,r28
    0x040320a8 <hsearch_r+136>:	2f 89 00 00	cmpwi   cr7,r9,0
    0x040320ac <hsearch_r+140>:	41 9e 01 00	beq     cr7,0x40321ac 
<hsearch_r+396>
(gdb) print $r9
$2 = 0x0
(gdb) print $r28
$3 = 0x22b154f8
(gdb) print $r29
$4 = 0x9b55aaa6
(gdb) print idx
$5 = 0x9b55aaa6
(gdb) bt
#0  hsearch_r (item=..., action=action@entry=ENV_FIND, 
retval=retval@entry=0xff002890,
     htab=0x4050288 <env_htab>, flag=flag@entry=0x0) at lib/hashtable.c:313
#1  0x04026d1c in env_get (name=0x4042c81 "fdtcontroladdr") at 
env/common.c:122
#2  0x04026d74 in env_get_hex (varname=<optimized out>, 
default_val=default_val@entry=0x0)
     at env/common.c:81
#3  0x04031b68 in fdtdec_setup () at lib/fdtdec.c:1659
#4  0x04013188 in initcall_run_list (init_sequence=0x404bd90 
<init_sequence_f>)
     at include/initcall.h:46
#5  board_init_f (boot_flags=<optimized out>) at common/board_f.c:981
#6  0x040001e4 in in_flash () at arch/powerpc/cpu/mpc8xx/start.S:174

$ git log -1 --oneline
50128aeb0f8 (HEAD) cyclic: get rid of cyclic_init()

Reverting that commit on top of v2023.01 allows a successful boot.

Thanks
Christophe

Re: U-boot 2023.01 not booting anymore MCR3000 board - Bisected 50128aeb0f8 ("cyclic: get rid of cyclic_init()")

[Christophe Leroy]

Le 28/01/2023 à 11:08, Christophe Leroy a écrit :
> Hi,
> 
> I'm trying to boot MCR3000 board with U-boot 2023.01 and it crashes in 
> the weed in fdtdec_setup().
> 
> I bisected the issue to commit 50128aeb0f8 ("cyclic: get rid of 
> cyclic_init()")
> 
> At the time being I don't understand what happens.
> 
> The problem is here below, idx is in the weed, I don't know why, any idea ?
> 

I finaly identified the issue. It is a long lasting bug that was 
introduced when powerpc was migrated to generic board. The powerpc 
version of board_init_f() was not using boot_flags and the asm callers 
didn't take care of it.

But generic version of board_init_f() uses it, and it is random.

Everything goes well when boot_flags are set to 0.

I will send a patch shortly to fix it.

Christophe