Re: [Qemu-ppc] Booting AIX on qemu-system-ppc, kernel not started successfully

[Alexander Graf]

On 23.02.2012, at 05:50, Liang Guo <address@hidden> wrote:

> On Wed, Feb 22, 2012 at 3:15 PM, Thomas Huth <address@hidden> wrote:
>> Am Tue, 21 Feb 2012 19:47:12 +0800
>> schrieb Liang Guo <address@hidden>:
>> 
>>> On Mon, Feb 20, 2012 at 7:03 PM, Alexander Graf <address@hidden> wrote:
>>>>> (qemu) info registers
>>>>> info registers
>>>>> NIP 0000000000000040   LR 00000000000cfc2c CTR 00000000000cfc28 XER 
>>>>> 0000000000000000
>>>> 
>>>> NIP is 0x40. How did it manage to get that low? If I had to guess, I'd say 
>>>> this is due to a NULL pointer dereference. Try setting a breakpoint to 
>>>> address 0 with the gdb stub and see where it comes from. Most likely we're 
>>>> missing some stuff in the device tree and/or hypercall implementations.
>>> 
>>> I add a  breakpoint at *0x0, the nip becomes 0x40 without trigger the
>>> breakpoint.
>>> 
>>> For the kernel entry point is 0x00022E28, then it jumps to 0x22e88,
>>> the asm code as below:
>>> 
>>> (gdb) x/10i $pc
>>> 0x22e88:        mflr    r13
>>> 0x22e8c:        lil     r6,1
>>> 0x22e90:        mfmsr   r7
>>> 0x22e94:        .long 0x78c7f80e
>>> 0x22e98:        .long 0x7ce00164
>>> 0x22e9c:        ics
>>> 0x22ea0:        rlinm   r3,r3,0,0,31
>>> 0x22ea4:        rlinm   r5,r5,0,0,31
>>> 0x22ea8:        ai      r13,r13,-44
>>> 0x22eac:        .long 0xe82d0078
>>> 
>>> After 0x22e9c, NIP becomes to 0x40.
>>> 
>>> What the "ics" means ?
>> 
>> "ics" seems to be the same as "isync".
>> Given that
>>        .long 0x78c7f80e = rldimi  r7,r6,63,0
>>        .long 0x7ce00164 = mtmsrd  r7
>> I think that the code is trying to switch to 64-bit mode here.
>> Not sure why this could cause an exception, though.
>> 
>>  Thomas
>> 
>> 
> 0x22e9c is a middle point.
> 
> The AIX entry point is at 0x22e28,
> 
> (gdb) x/10i $pc
> 0x22e28:        bl      0x22e88
> 0x22e2c:        .long 0xe8c20009
> 0x22e30:        .long 0xf8c10009
> 0x22e34:        cmp     0,r2,r0
> 
> it jumps 0x22e88,
> (gdb) x/20i $pc
> 0x22e88:        mflr    r13
> 0x22e8c:        lil     r6,1
> 0x22e90:        mfmsr   r7
> 0x22e94:        .long 0x78c7f80e
> 0x22e98:        .long 0x7ce00164
> 0x22e9c:        ics
> 0x22ea0:        rlinm   r3,r3,0,0,31
> 0x22ea4:        rlinm   r5,r5,0,0,31
> 0x22ea8:        ai      r13,r13,-44
> 0x22eac:        .long 0xe82d0078
> 0x22eb0:        .long 0xe84d0080
> 0x22eb4:        l       r2,0(r2)
> 0x22eb8:        a       r2,r1,r2
> 0x22ebc:        lil     r5,-8
> 0x22ec0:        .long 0xe9050009
> 0x22ec4:        .long 0xf9010000
> 0x22ec8:        cal     r1,8(r1)
> 0x22ecc:        cmp     0,r1,r2
> 0x22ed0:        blt     0x22ec0
> 0x22ed4:        l       r5,152(r3)
> 
> in 0x22f34, $pc jump to 0x20,
> 
> (gdb) x/10i $pc
> 0x22f2c:        dcs
> 0x22f30:        ics
> 0x22f34:        ba      0x2c
> 0x22f38:        .long 0x0
> 0x22f3c:        .long 0x0
> 0x22f40:        .long 0x0
> 0x22f44:        .long 0x0
> 0x22f48:        .long 0x0
> 0x22f4c:        .long 0x0
> 0x22f50:        .long 0x0
> 
> After enter 0x2c, $pc loop in 0x40, 0x44, 0x48,0x4c, and never end.
> (gdb) x/20i $pc
> 0x2c:   .long 0xe8c20009
> 0x30:   .long 0xf8c10009
> 0x34:   cmp     0,r2,r0
> 0x38:   blt     0x2c
> 0x3c:   lil     r8,116
> 0x40:   .long 0x7c0040ac
> 0x44:   cmp     0,r8,r0
> 0x48:   a       r8,r8,r16
> 0x4c:   blt     0x40
> 0x50:   dcs
> 0x54:   lil     r8,116
> 0x58:   .long 0x7c0047ac
> 0x5c:   cmp     0,r8,r0
> 0x60:   a       r8,r8,r15
> 0x64:   blt     0x58
> 0x68:   dcs
> 0x6c:   ics
> 0x70:   ba      0x1c00f8
> 0x74:   oril    r0,r0,0
> 0x78:   .long 0x0
> 
> In IBM AIX Assembler Language Reference, I cannot find the "blt","a"
> does gdb use another assembler language, where can I find more
> information about it ?

It looks like the disassembler in gdb is configured for something odd, yeah. 
POWER1 maybe.

Try to run "log in_asm,cpu,int" on the qemu monitor right at the AIX entry 
point. The disassembly log should be in /tmp/qemu.log then.

Alternatively, you can of course try to use a gdb that works ;).

Alex

> 
> Thanks,
> 
> -- 
> Liang Guo
> http://bluestone.cublog.cn
>