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