[Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction

[Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction

[Tero Kaarlela]

Hi,

    I took a look at qemu in_asm & cpu debugging with OS/2 bootloader 
under Qemu -prep. And there is something weird happening in my opinion:

This happens after boot.cfg has been gone through and kernel bootstrap 
task should start:

IN:
0xf0107068:  .long 0x10009d81
0xf010706c:  tdi    0,r0,27776
0xf0107070:  bl    F011EDF0    <<= Shouldnt this branch to F011EDF0 
instead of going on???
0xf0107074:  .long 0xb2c
0xf0107078:  cmpwi    r0,-32191

After this code branches back to 0x0f0107068(this block start) And does 
this same block again 42 times. Then:

----------------
nip=00000300 super=1 ir=0
translate opcode f01072ac (3c 16 0a)
invalid/unsupported opcode: 3c - 16 - 0a (f01072ac) 0x00000300 0
IN:
0x00000300:  lhau    r3,4336(r18)

----------------
nip=00000700 super=1 ir=0
translate opcode f0000730 (3c 18 1c)
invalid/unsupported opcode: 3c - 18 - 1c (f0000730) 0x00000700 0
IN:
0x00000700:  addic    r0,r7,240


Here is CPU debug from same:

---------------- excp: 0108
nip=0xf0107068 LR=0xf0107010 CTR=0xf01071e0 XER=0x20000000 MSR=0x00010031
GPR00: f01072ac f0000060 00000000 f0170004 00000001 40000000 00000010 
f0004100
GPR08: f0107010 84000023 f0107068 f01071e0 f0000000 f0000300 00000000 
20000000
GPR16: 00000004 38603000 60000000 00000000 0000b588 00000000 001990c7 
00195000
GPR24: 00000000 0000000c 00000041 40010031 00000010 00000000 f0000300 
f0170004
CR: 0x84000023  [ L  G  -  -  -  -  E  EO ] TB: 0x00000000 dd2f1962
FPR00: 6162636465666d00 0000000000000000 0000000000000000 0000000000000000
FPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
SRR0 0xf0102700 SRR1 0x00010031 DECR=0x22d0b634
reservation 0x00000000
invalid/unsupported opcode: 3c - 16 - 0a (f01072ac) 0x00000300 0
---------------- excp: 0007
nip=0x00000300 LR=0xf0107010 CTR=0xf01071e0 XER=0x20000000 MSR=0x00010001
GPR00: f01072ac f0000060 00000000 f0170004 00000001 40000000 00000010 
f0004100
GPR08: f0107010 84000023 f0107068 f01071e0 f0000000 f0000300 00000000 
20000000
GPR16: 00000004 38603000 60000000 00000000 0000b588 00000000 001990c7 
00195000
GPR24: 00000000 0000000c 00000041 40010031 00000010 00000000 f0000300 
f0170004
CR: 0x84000023  [ L  G  -  -  -  -  E  EO ] TB: 0x00000000 dd2fbe70
FPR00: 6162636465666d00 0000000000000000 0000000000000000 0000000000000000
FPR04: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
FPR12: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
SRR0 0xf0107068 SRR1 0x00000031 DECR=0x22d014be
reservation 0x00000000
invalid/unsupported opcode: 3c - 18 - 1c (f0000730) 0x00000700 0


So any ideas what might be reason for this?


Tero Kaarlela

Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction

[Tero Kaarlela]

I have just realized that when running in LE mode in_asm dump is not 
useful because it shows code in BE-format. I'll try to make it print in 
LE format. And those invalid opcodes is this because after OS/2 crashes 
Qemu tries to start its own code but crashes because before this 
Processor should be returned to BE-format?


Tero

Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction

[J. Mayer]

On Wed, 2005-05-25 at 21:59 +0300, Tero Kaarlela wrote:
> I have just realized that when running in LE mode in_asm dump is not 
> useful because it shows code in BE-format. I'll try to make it print in 
> LE format. And those invalid opcodes is this because after OS/2 crashes 
> Qemu tries to start its own code but crashes because before this 
> Processor should be returned to BE-format?

It should display insns in little-endian format, if you're up to date.
Take a look at the code in disas.c and ppc-dis.c, you'll see the case is
handled.

But the 0x3c opcode is valid ... on POWER2 (namely stfq).
Then I guess you choose a platform which is a RS/6000 with a POWER2, not
a PowerPC.
I'm afraid POWER1 & POWER2 won't be emuled soon, if they'll ever be...
Please check this point.

Another point:
>     I took a look at qemu in_asm & cpu debugging with OS/2 bootloader 
> under Qemu -prep. And there is something weird happening in my opinion:
> 
> This happens after boot.cfg has been gone through and kernel bootstrap 
> task should start:
> 
> IN:
> 0xf0107068:  .long 0x10009d81
> 0xf010706c:  tdi    0,r0,27776
> 0xf0107070:  bl    F011EDF0    <<= Shouldnt this branch to F011EDF0 
> instead of going on???

As this is a subroutine call, I guess this routine as already been called from somewhere else.
As Qemu only displays blocks at translation time, you don't have any dump any more
when calling a routine twice.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction

[Tero Kaarlela]

J. Mayer wrote:

>On Wed, 2005-05-25 at 21:59 +0300, Tero Kaarlela wrote:
>  
>
>>I have just realized that when running in LE mode in_asm dump is not 
>>useful because it shows code in BE-format. I'll try to make it print in 
>>LE format. And those invalid opcodes is this because after OS/2 crashes 
>>Qemu tries to start its own code but crashes because before this 
>>Processor should be returned to BE-format?
>>    
>>
>
>It should display insns in little-endian format, if you're up to date.
>Take a look at the code in disas.c and ppc-dis.c, you'll see the case is
>handled.
>  
>
     Yes I  used out of date binaries(0.6.1 + patches). My mistake sorry.

>But the 0x3c opcode is valid ... on POWER2 (namely stfq).
>Then I guess you choose a platform which is a RS/6000 with a POWER2, not
>a PowerPC.
>I'm afraid POWER1 & POWER2 won't be emuled soon, if they'll ever be...
>Please check this point.
>
     Bootloader check PVR at very early stage of boot accepted ones are:

        601
        603
        604
 
      If something else is reported bootloader goes to indefiniteve loop.

>Another point:
>  
>
>>    I took a look at qemu in_asm & cpu debugging with OS/2 bootloader 
>>under Qemu -prep. And there is something weird happening in my opinion:
>>
>>This happens after boot.cfg has been gone through and kernel bootstrap 
>>task should start:
>>
>>IN:
>>0xf0107068:  .long 0x10009d81
>>0xf010706c:  tdi    0,r0,27776
>>0xf0107070:  bl    F011EDF0    <<= Shouldnt this branch to F011EDF0 
>>instead of going on???
>>    
>>
>
>As this is a subroutine call, I guess this routine as already been called from somewhere else.
>As Qemu only displays blocks at translation time, you don't have any dump any more
>when calling a routine twice.
>
  After compiling CVS version lines above look like this:

IN:
0xf0107068:  lwz    r12,16(r29)
0xf010706c:  lwz    r3,8(r12)
0xf0107070:  lwz    r11,328(r29)
0xf0107074:  cmpwi    r11,0
0xf0107078:  beq    F01070A4

invalid/unsupported opcode: 3c - 16 - 0a (f01072ac) 0x00000300 0
IN:
0x00000300:  .long 0xf01072ac

invalid/unsupported opcode: 3c - 18 - 1c (f0000730) 0x00000700 0
IN:
0x00000700:  .long 0xf0000730

Could this be because OS/2 can't handle this much ram(128mb). OS/2 has 
always been very specific about maximum memory(ie. versions 1.x can't 
boot on machines that report more than 16mb ram. this is one of the 
reasons 1.x versions dont boot under Qemu and thats why many BIOSES have 
option "boot to OS/2). During 1995 when OS/2 PPC was made 16mb was much 
and 32mb was huge amount of memory.

Tero Kaarlela