Re: Looking for advise on debugging a non-boot kernel on qemu-system-sh4

[BALATON Zoltan]

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