[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tero Kaarlela
Subject: Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction
Date: Sun, 29 May 2005 17:02:03 +0300
User-agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.0.1) Gecko/20020919 IBM Web Browser for OS/2

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
    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:


     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:

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 
when calling a routine twice.

 After compiling CVS version lines above look like this:

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
0x00000300:  .long 0xf01072ac

invalid/unsupported opcode: 3c - 18 - 1c (f0000730) 0x00000700 0
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]