On Thu, 21 Oct 2021, John Paul Adrian Glaubitz wrote:
Hi Zoltan!
On 10/21/21 14:12, BALATON Zoltan wrote:
Adding -d in_asm shows it seems to loop early in the kernel but not sure where.
Maybe try to compare addresses with System.map to find out where it's getting
stuck (but System.map was not included in your installer image).
Here is the System.map if that helps [1].
Also if it works on earlier kernel you might try to bisect which kernel commit
caused the problem. Maybe knowing that helps to tell where to look further.
If nothing else helps, I will try that.
Adrian
[1] https://people.debian.org/~glaubitz/System.map-5.14.0-3-sh7751r.gz
I could not find any addresses that look like those in the map but I now
see it seems to reboot on encountering an invalid instruction maybe before
(during) uncomressing the kernel:
start:
0xac800000: mov.l 0xac80007c,r1 ! 0x500000f0
[,,,]
0x8c80085e: mov.l r1,@(4,r8)
0x8c800860: bra 0x8c800b84
0x8c800862: mov r6,r0
----------------
IN:
0x8c80058c: .word 0x0000
----------------
IN:
0xac800000: mov.l 0xac80007c,r1 ! 0x500000f0
and then this repeats. I wonder what's that zero opcode is and why is it
there. Previously before it gets zero there was running it and there was
still code there:
IN:
0x8c800ad4: mov.l r1,@(36,r9)
0x8c800ad6: mov.l @(28,r9),r1
0x8c800ad8: mov.l @(8,r15),r5
0x8c800ada: mov.l r1,@(32,r9)
0x8c800adc: mov.l @(24,r9),r1
0x8c800ade: mov.l r1,@(28,r9)
0x8c800ae0: mov.l @(20,r9),r1
0x8c800ae2: mov.l r1,@(24,r9)
0x8c800ae4: mov.l 0x8c800c44,r1 ! 0x8c80058c
0x8c800ae6: jsr @r1
0x8c800ae8: mov r8,r4
----------------
IN:
0x8c80058c: mov.l r8,@-r15
0x8c80058e: mov.l r9,@-r15
0x8c800590: mov.l r10,@-r15
0x8c800592: mov.l r11,@-r15
0x8c800594: mov.l @r4,r2
0x8c800596: mov.l 0x8c800718,r1 ! 0xffffff
0x8c800598: mov.l r12,@-r15
0x8c80059a: cmp/hi r1,r2
0x8c80059c: bt.s 0x8c8005ba
0x8c80059e: mov.l r13,@-r15
So somthing seems to overwrite it. Maybe you can try building an
uncompressed kernel or one using a different compression and see if that
does the same, at least that way we can see if it's in the decompressing
or later. I think it's past linux/arch/sh/boot/compressed/head32.S and
maybe somewhere in decompress_kernel but not sure which decompression it
uses. Kernel config is also missing to check but I probably give up at
this point and let you experiment some more.
Regards,
BALATON Zoltan