SCO OS 5.0.7 on Qemu - SCO

This is a discussion on SCO OS 5.0.7 on Qemu - SCO ; Hi everybody. This time of the year allows me to experiment with things that otherwyse I woulnd't have the time play with; during the last few days I gave Qemu 0.8.0 + kqemu (running on SuSE Linux 10) a try. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: SCO OS 5.0.7 on Qemu

  1. SCO OS 5.0.7 on Qemu

    Hi everybody.

    This time of the year allows me to experiment with things that otherwyse
    I woulnd't have the time play with; during the last few days I gave Qemu
    0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
    and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.

    I started with a 300MB memory allocation and by creating a virtual disk
    of 2GB; when I booted from the CD, I was able to get to the boot: prompt
    but, after depicting the usual dots, I ended up having a blank screen
    instead of the "laundry list" of devices.

    Qemu is able to emulate an old Cirrus Logic board and, since
    I was aware of the OSS653A patch (the initial VGA recognition
    supplement) so I tried to add it as a BTLD driver (which worked fine)
    but again I ended up with a blank screen.

    So I gave OSS661A a try and I was able to get to the laundry list but I
    had a "WARNING: hd: no root disk controller was found".

    This is strange since Qemu is able to emulate a simple IDE/EIDE
    controller; the CD-ROM interface the installed detect is the real
    /dev/cdrom device under Linux and the HD is an ATA-2 2GB HD configured
    as ata0/master.

    I tried with "defbootstr Sdsk=wd(0,0,0) link=invd prompt" but that gave
    me a panic during the hd_config stage.

    So I downloaded the WD supplement from SCO's FTP site and tried to use
    it using the

    link="invd wd"

    bootstring. The loader correctly prompted me to replace the existing
    "wd" driver but, again, I ended up having a "no root disk controller was
    found".

    The laundry list reported

    adaptec 0x0170-0x0177 15 - type=IDE ctlr=secondary drv=wd

    which is the secondary IDE controller but failed to report the primary
    (which is/should be at 0x1F0 - IRQ 14). I tried again by telling the
    loader to search for a "wd" adapter here:

    adapter=wd(0x1F0,14,0)

    but unsuccessfully.

    Has anyone tried the above ?

    I'm pretty sure that (again - and he will be more than welcome :-) Bela
    will jump ip, scare me to death and provide a simple solution...

    Happy New Year to everybody,
    Roberto

    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  2. Re: SCO OS 5.0.7 on Qemu

    Rob wrote:
    > Hi everybody.
    >
    > This time of the year allows me to experiment with things that otherwyse
    > I woulnd't have the time play with; during the last few days I gave Qemu
    > 0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
    > and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.
    >
    > I started with a 300MB memory allocation and by creating a virtual disk
    > of 2GB; when I booted from the CD, I was able to get to the boot: prompt
    > but, after depicting the usual dots, I ended up having a blank screen
    > instead of the "laundry list" of devices.
    >
    > Qemu is able to emulate an old Cirrus Logic board and, since
    > I was aware of the OSS653A patch (the initial VGA recognition
    > supplement) so I tried to add it as a BTLD driver (which worked fine)
    > but again I ended up with a blank screen.
    >
    > So I gave OSS661A a try and I was able to get to the laundry list but I
    > had a "WARNING: hd: no root disk controller was found".
    >
    > This is strange since Qemu is able to emulate a simple IDE/EIDE
    > controller; the CD-ROM interface the installed detect is the real
    > /dev/cdrom device under Linux and the HD is an ATA-2 2GB HD configured
    > as ata0/master.
    >
    > I tried with "defbootstr Sdsk=wd(0,0,0) link=invd prompt" but that gave
    > me a panic during the hd_config stage.
    >
    > So I downloaded the WD supplement from SCO's FTP site and tried to use
    > it using the
    >
    > link="invd wd"
    >
    > bootstring. The loader correctly prompted me to replace the existing
    > "wd" driver but, again, I ended up having a "no root disk controller was
    > found".
    >
    > The laundry list reported
    >
    > adaptec 0x0170-0x0177 15 - type=IDE ctlr=secondary drv=wd
    >
    > which is the secondary IDE controller but failed to report the primary
    > (which is/should be at 0x1F0 - IRQ 14). I tried again by telling the
    > loader to search for a "wd" adapter here:
    >
    > adapter=wd(0x1F0,14,0)
    >
    > but unsuccessfully.
    >
    > Has anyone tried the above ?
    >
    > I'm pretty sure that (again - and he will be more than welcome :-) Bela
    > will jump ip, scare me to death and provide a simple solution...
    >
    > Happy New Year to everybody,
    > Roberto
    >


    Just to add some more tests.

    I've tried with SCO OS 5.0.6 w/wo the wd supplement and OSS661A but I
    got the same results.

    I've tried by configuring Qemu as to have the HD image file on the
    secondary/slave position but, when booting, OS5 reports it as a tape device.

    I've also tried with SCO OS6 (booted with the USE_VESA_BIOS=YES
    parameter) but the installation process is unable to detect the CD-ROM
    (and I'm unable to switch into console mode to find what the IDE driver
    detected).

    Best,
    Rob

    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  3. Re: SCO OS 5.0.7 on Qemu

    Hi,

    Rob schrieb:
    > Hi everybody.
    >
    > This time of the year allows me to experiment with things that otherwyse
    > I woulnd't have the time play with; during the last few days I gave Qemu
    > 0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
    > and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.
    >

    I tried yesterday to install OpenServer 6 under Parallels Workstation
    (www.parallels.com) virtual machine... with no success. Good old OS/2
    works out of the box. You can download a 45-day full functional demo
    which is available for Windows or Linux platforms. Intel-VT is supported.

    > I started with a 300MB memory allocation and by creating a virtual disk
    > of 2GB; when I booted from the CD, I was able to get to the boot: prompt
    > but, after depicting the usual dots, I ended up having a blank screen
    > instead of the "laundry list" of devices.


    The boot prompt is functional. Then I got the graphical startup screen.
    System stops after loading the kernel and displaying the copyright text
    screen. It seems the virtualized ide hba is not detected.

    I should try with OSR 5.0.7?

    Andreas Kohl

  4. Re: SCO OS 5.0.7 on Qemu

    Andreas Kohl wrote:
    > Hi,
    >
    > Rob schrieb:
    >
    >>Hi everybody.
    >>
    >>This time of the year allows me to experiment with things that otherwyse
    >>I woulnd't have the time play with; during the last few days I gave Qemu
    >> 0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
    >>and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.
    >>

    >
    > I tried yesterday to install OpenServer 6 under Parallels Workstation
    > (www.parallels.com) virtual machine... with no success. Good old OS/2
    > works out of the box. You can download a 45-day full functional demo
    > which is available for Windows or Linux platforms. Intel-VT is supported.
    >
    >
    >>I started with a 300MB memory allocation and by creating a virtual disk
    >>of 2GB; when I booted from the CD, I was able to get to the boot: prompt
    >>but, after depicting the usual dots, I ended up having a blank screen
    >>instead of the "laundry list" of devices.

    >
    >
    > The boot prompt is functional. Then I got the graphical startup screen.
    > System stops after loading the kernel and displaying the copyright text
    > screen. It seems the virtualized ide hba is not detected.
    >
    > I should try with OSR 5.0.7?
    >
    > Andreas Kohl


    Andreas,

    try by booting OS6 with the USE_VESA_BIOS=YES parameter; IOW, when the
    OS6 prompt depicts the "countdown" to boot, type the above command and
    hit ENTER. Once you're done, type "go" followed by ENTER.

    on OS6 I was able to get to the point where the installation script asks
    for the CD-ROM (which did not get recognized).

    I wish you luck,
    Rob

    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  5. Re: SCO OS 5.0.7 on Qemu

    Roberto Zini wrote:

    > This time of the year allows me to experiment with things that otherwyse
    > I woulnd't have the time play with; during the last few days I gave Qemu
    > 0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
    > and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.
    >
    > I started with a 300MB memory allocation and by creating a virtual disk
    > of 2GB; when I booted from the CD, I was able to get to the boot: prompt
    > but, after depicting the usual dots, I ended up having a blank screen
    > instead of the "laundry list" of devices.
    >
    > Qemu is able to emulate an old Cirrus Logic board and, since
    > I was aware of the OSS653A patch (the initial VGA recognition
    > supplement) so I tried to add it as a BTLD driver (which worked fine)
    > but again I ended up with a blank screen.
    >
    > So I gave OSS661A a try and I was able to get to the laundry list but I
    > had a "WARNING: hd: no root disk controller was found".
    >
    > This is strange since Qemu is able to emulate a simple IDE/EIDE
    > controller; the CD-ROM interface the installed detect is the real
    > /dev/cdrom device under Linux and the HD is an ATA-2 2GB HD configured
    > as ata0/master.


    This is much the same problem that OSR5 has previously had with VMware
    and then with MS Virtual PC. The OSR5 "wd" IDE driver has code in it to
    work around the quirks of _ancient_ "wd" family disk controllers. I'm
    talking about things like the Western Digital WD1003 (16-bit ISA
    controller used in PC/AT class machines), and even older relatives.
    These workarounds have been conditioned over the years to work correctly
    with _real_ MFM/RLL/ESDI/IDE/ATA/etc controllers, but they tend to
    trigger oddities in emulators.

    The driver is partly at fault (for pushing the "hardware" in weird,
    unexpected directions); and the emulator is partly at fault (for not
    emulating every quirk of the real hardware it's supposed to represent).

    > I tried with "defbootstr Sdsk=wd(0,0,0) link=invd prompt" but that gave
    > me a panic during the hd_config stage.


    Although "wd" has a SCSI interface, that is only used for ATAPI devices
    (mostly CD/DVD drives, also tapes and a few other oddball items). IDE
    hard disks are _not_ in any way seen as SCSI under OSR5. Here you told
    the kernel to look for a SCSI disk on a "wd" HBA. This is a valid
    formulation to access an ATAPI device that represents itself as a hard
    disk, e.g. an ATAPI Zip. It goes nowhere with a true IDE hard disk.

    > So I downloaded the WD supplement from SCO's FTP site and tried to use
    > it using the
    >
    > link="invd wd"
    >
    > bootstring. The loader correctly prompted me to replace the existing
    > "wd" driver but, again, I ended up having a "no root disk controller was
    > found".
    >
    > The laundry list reported
    >
    > adaptec 0x0170-0x0177 15 - type=IDE ctlr=secondary drv=wd
    >
    > which is the secondary IDE controller but failed to report the primary
    > (which is/should be at 0x1F0 - IRQ 14). I tried again by telling the
    > loader to search for a "wd" adapter here:
    >
    > adapter=wd(0x1F0,14,0)
    >
    > but unsuccessfully.


    "wd", in its role as a pseudo-SCSI HBA, announces "%adapter" lines for
    controllers on which it finds ATAPI devices. Your primary controller
    has only a hard disk (which it isn't going to see as SCSI), so it
    doesn't announce the HBA. If the hard disk itself is found, you get a
    "%disk" line that announces the same I/O addresses etc.

    No "adapter=", "Sdsk=" or any other OSR5 SCSI subsystem-related
    bootstrings are going to help here. What you need is to get the IDE
    controller and hard disk detection over the hump.

    > I'm pretty sure that (again - and he will be more than welcome :-) Bela
    > will jump ip, scare me to death and provide a simple solution...


    Hmmm, well, let's scare you with this: I'm starting a new job Monday, at
    VMware. I suspect that I should not do a whole lot of very visible
    support work on open source products that compete directly with my
    employer. But what the heck, at the moment this falls under "learning
    about emulation" -- it will make me more effective at my job.

    Next step I recommend:

    Boot
    : defbootstr link=invd wd.debug=ugi

    This makes the "wd" driver print as much debug output as it can; which
    isn't very much, but should give us a vague sense of how far it's
    getting.

    The sequence of operations that happen is, very crudely, something like
    this:

    wd_ctlrpres():
    see if a ST506/IDE controller is present
    /* if we got this far, the driver does think a controller exists,
    but it also wants to know if it's one of the ancient weird ones
    that it knows won't work, so: */
    subject it to several weird tests
    return false if those weird tests fail

    wd_drivepres():
    see if a ST506/IDE hard disk is present
    /* same deal */
    subject it to several weird tests
    return false if those weird tests fail

    You're going to get some debug output that may or may not clarify this.
    If you're lucky, debug output will suggest an easy workaround. If not,
    the next step will be to boot with "defbootstr link=invd maindebug".
    That invokes scodb (kernel debugger) early in the kernel's life, then
    you can set breakpoints inside "wd" and trace the recognition code, see
    where it goes wrong.

    ================================================== ===========================

    BTW, are you sure it's "invd" and not "ivga"? "invd" works around a
    fairly specific nVidia BIOS behavior; "ivga" is much more generic. (The
    issues are completely different and could possibly both occur on the
    same system, though I've never heard of that.) "ivga" works around a
    far more common BIOS problem: incorrect setting of the CMOS video type
    value. In fact, I see that Qemu uses the Bochs video BIOS, and that
    this very bug was fixed in version 0.5c of that BIOS. See
    http://www.nongnu.org/vgabios/. That page has compiled BIOS images; you
    should be able to download a newer one into your Qemu/bios directory.
    (Update both vgabios.bin and vgabios-cirrus.bin, I'm not sure how to
    tell which one Qemu will use on your machine.) Then you shouldn't need
    "ivga".

    On further examination, I suspect that Qemu's BIOS may have both issues!
    So you may really mean you are using "invd". Why would it not need
    "ivga"? Because it gets lucky -- the wrong value that it leaves in CMOS
    isn't wrong enough to bother OSR5.

    But you said "oss653a", which is the "ivga" supplement, so in the end my
    guess is that you're using "ivga" and just typed "invd" into your post
    by mistake.

    ================================================== ===========================

    I've been running OSR5 under VMware Workstation for several years now.
    There were some problems at first. These days I have great success with
    it. VMware now makes a "player" available for free, lets you run
    previously built virtual machines. You could probably install OSR5 onto
    that, giving you another free virtual machine that can run OSR5 (without
    all these issues). But without source -- so if your real goal here was
    to study the emulation mechanics themselves, that won't do.

    There, is that scary enough? ;-}

    >Bela<


  6. Re: SCO OS 5.0.7 on Qemu

    Bela Lubkin wrote:
    > Roberto Zini wrote:
    >
    >
    >>This time of the year allows me to experiment with things that otherwyse
    >>I woulnd't have the time play with; during the last few days I gave Qemu
    >> 0.8.0 + kqemu (running on SuSE Linux 10) a try. I was able to install
    >>and successfully use Windows XP and I wanted to give SCO OS 5.0.7 a run.
    >>
    >>I started with a 300MB memory allocation and by creating a virtual disk
    >>of 2GB; when I booted from the CD, I was able to get to the boot: prompt
    >>but, after depicting the usual dots, I ended up having a blank screen
    >>instead of the "laundry list" of devices.
    >>
    >>Qemu is able to emulate an old Cirrus Logic board and, since
    >>I was aware of the OSS653A patch (the initial VGA recognition
    >>supplement) so I tried to add it as a BTLD driver (which worked fine)
    >>but again I ended up with a blank screen.
    >>
    >>So I gave OSS661A a try and I was able to get to the laundry list but I
    >>had a "WARNING: hd: no root disk controller was found".
    >>
    >>This is strange since Qemu is able to emulate a simple IDE/EIDE
    >>controller; the CD-ROM interface the installed detect is the real
    >>/dev/cdrom device under Linux and the HD is an ATA-2 2GB HD configured
    >>as ata0/master.

    >
    >
    > This is much the same problem that OSR5 has previously had with VMware
    > and then with MS Virtual PC. The OSR5 "wd" IDE driver has code in it to
    > work around the quirks of _ancient_ "wd" family disk controllers. I'm
    > talking about things like the Western Digital WD1003 (16-bit ISA
    > controller used in PC/AT class machines), and even older relatives.
    > These workarounds have been conditioned over the years to work correctly
    > with _real_ MFM/RLL/ESDI/IDE/ATA/etc controllers, but they tend to
    > trigger oddities in emulators.
    >
    > The driver is partly at fault (for pushing the "hardware" in weird,
    > unexpected directions); and the emulator is partly at fault (for not
    > emulating every quirk of the real hardware it's supposed to represent).


    Once more, Bela, thank you for taking the time to read this and for the
    above explanation.

    >
    >
    >>I tried with "defbootstr Sdsk=wd(0,0,0) link=invd prompt" but that gave
    >>me a panic during the hd_config stage.

    >
    >
    > Although "wd" has a SCSI interface, that is only used for ATAPI devices
    > (mostly CD/DVD drives, also tapes and a few other oddball items). IDE
    > hard disks are _not_ in any way seen as SCSI under OSR5. Here you told
    > the kernel to look for a SCSI disk on a "wd" HBA. This is a valid
    > formulation to access an ATAPI device that represents itself as a hard
    > disk, e.g. an ATAPI Zip. It goes nowhere with a true IDE hard disk.
    >


    OK.

    >
    >>So I downloaded the WD supplement from SCO's FTP site and tried to use
    >>it using the
    >>
    >> link="invd wd"
    >>
    >>bootstring. The loader correctly prompted me to replace the existing
    >>"wd" driver but, again, I ended up having a "no root disk controller was
    >>found".
    >>
    >>The laundry list reported
    >>
    >> adaptec 0x0170-0x0177 15 - type=IDE ctlr=secondary drv=wd
    >>
    >>which is the secondary IDE controller but failed to report the primary
    >>(which is/should be at 0x1F0 - IRQ 14). I tried again by telling the
    >>loader to search for a "wd" adapter here:
    >>
    >> adapter=wd(0x1F0,14,0)
    >>
    >>but unsuccessfully.

    >
    >
    > "wd", in its role as a pseudo-SCSI HBA, announces "%adapter" lines for
    > controllers on which it finds ATAPI devices. Your primary controller
    > has only a hard disk (which it isn't going to see as SCSI), so it
    > doesn't announce the HBA. If the hard disk itself is found, you get a
    > "%disk" line that announces the same I/O addresses etc.
    >
    > No "adapter=", "Sdsk=" or any other OSR5 SCSI subsystem-related
    > bootstrings are going to help here. What you need is to get the IDE
    > controller and hard disk detection over the hump.
    >
    >
    >>I'm pretty sure that (again - and he will be more than welcome :-) Bela
    >>will jump ip, scare me to death and provide a simple solution...

    >
    >
    > Hmmm, well, let's scare you with this:


    You already did (but I was prepared :-)

    > I'm starting a new job Monday, at
    > VMware. I suspect that I should not do a whole lot of very visible
    > support work on open source products that compete directly with my
    > employer. But what the heck, at the moment this falls under "learning
    > about emulation" -- it will make me more effective at my job.


    Well, I wish you luck for your new life; I'm pretty sure folks at VmWare
    will gain from your expertise and knowledge but __please__ don't forget
    us poor guys still stuck to OSes from SCO :-)

    >
    > Next step I recommend:
    >
    > Boot
    > : defbootstr link=invd wd.debug=ugi
    >


    Well, I used the following:

    defbootstr link="invd wd" wd.debug=ugi

    From inside the emulator I'm able to "switch" the floppy disk emulated
    image since I had to use 2 BTLDs (one for the invd driver and one for
    the newer wd one).

    > This makes the "wd" driver print as much debug output as it can; which
    > isn't very much, but should give us a vague sense of how far it's
    > getting.
    >
    > The sequence of operations that happen is, very crudely, something like
    > this:
    >
    > wd_ctlrpres():
    > see if a ST506/IDE controller is present
    > /* if we got this far, the driver does think a controller exists,
    > but it also wants to know if it's one of the ancient weird ones
    > that it knows won't work, so: */
    > subject it to several weird tests
    > return false if those weird tests fail
    >
    > wd_drivepres():
    > see if a ST506/IDE hard disk is present
    > /* same deal */
    > subject it to several weird tests
    > return false if those weird tests fail
    >
    > You're going to get some debug output that may or may not clarify this.
    > If you're lucky, debug output will suggest an easy workaround. If not,


    Well, I did that; problem is that debug messages fill up the screen so
    I'm not sure if the easy workaround you suggested actually appeared or not.

    Anyway, what I can see on the screen is (hand written so prone to errors):

    wd: if incorrect, add wd.udma=33 (or 66 or 100) to your bootstring.
    wd 0/0: IDENTIFY DEVICE: Status 58, Error 00
    wd 0/0: non-ATAPI device present
    wd: Drive max supported mode = 4, BIOS selected mode = 5
    wd: Drive using BIOS selected UDMA mode 5
    wd 0/0: Common UDMA Mode 4, Max MBoard mode 6, Max dev supt 4
    wd: Possible UDMA timing mismatch, bootstring may be required
    wd: add wd.udma=auto for driver attempted auto sense or
    wd: wd.udma=off to use Programmed I/O (PIO) instead of UDMA
    wd 0/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
    wd 1/0: IDENTIFY_DEVICE: Status 41, Error 04
    wd 1/0: ATAPI_IDENTIFY: Status 48, Error 00, ATAPI = yes
    wd 1/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
    %adapter 0x0170-0x177 15 - type=IDE ctlr=secondary dvr=wd
    ....
    ....
    WARNING: hd: no root disk controller was found
    hd: a Boot-Time Loadable Driver may be required
    %cd-rom - - type=IDE unit=0 ctlr=sec cfg=mst dvr=Srom->wd

    I've tried by rebooting with "wd.debug=ui wd.udma=auto" but
    unsuccessfully; however, the following messages appeared (**):

    wd: if incorrect, add wd.udma=33 (or 66 or 100) to your bootstring.
    wd 0/0: IDENTIFY DEVICE: Status 58, Error 00
    wd 0/0: non-ATAPI device present
    wd: Drive max supported mode = 4, BIOS selected mode = 5
    ** wd: Reprogram ATA drive to UDMA mode 4 **
    wd 0/0: Common UDMA Mode 4, Max MBoard mode 6, Max dev supt 4
    wd: Possible UDMA timing mismatch, bootstring may be required
    wd: add wd.udma=auto for driver attempted auto sense or
    wd: wd.udma=off to use Programmed I/O (PIO) instead of UDMA
    wd 0/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
    wd 1/0: IDENTIFY_DEVICE: Status 41, Error 04
    wd 1/0: ATAPI_IDENTIFY: Status 48, Error 00, ATAPI = yes
    wd 1/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
    %adapter 0x0170-0x177 15 - type=IDE ctlr=secondary dvr=wd
    ....
    ....
    WARNING: hd: no root disk controller was found
    hd: a Boot-Time Loadable Driver may be required


    Next, I used wd.udma=off and some more lines appeared before the "wd: if
    incorrect..." one:

    wd: didn't find any specific known PCI IDE controller, trying by class
    wd: PCI bus/dev/func 0/1/1, vend/dev 8086/7010, prog_if 80, BMIBA 0000C001
    wd: unknown but possibly usable PCI IDE controller; assuming UDMA 133
    wd: if incorrect, add wd.udma=33 (or 66 or 100) to your bootstring
    wd 0/0: IDENTIFY DEVICE: Status 58, Error 00
    wd 0/0: non-ATAPI device present
    wd 0/0: Max MBoard UDMA mode=6, Max drive UDMA mode=4
    wd 0/0: BIOS selected UDMA mode=5 for drive
    ** wd 0/0: UDMA disabled by bootstring **
    wd 0/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
    wd 1/0: IDENTIFY_DEVICE: Status 41, Error 04
    wd 1/0: ATAPI_IDENTIFY: Status 48, Error 00, ATAPI = yes
    wd 1/1: IDENTIFY_DEVICE: Status 00, Error 00 (no device)
    %adapter 0x0170-0x177 15 - type=IDE ctlr=secondary dvr=wd
    ....
    ....
    WARNING: hd: no root disk controller was found
    hd: a Boot-Time Loadable Driver may be required

    Again, I tried with wd.udma=33: the drive tried by reprogram the ATA
    drive to UDMA mode 2 and again I had a UDMA timing mismatch. The same
    went with wd.udma=66 and wd.udma=100.


    > the next step will be to boot with "defbootstr link=invd maindebug".
    > That invokes scodb (kernel debugger) early in the kernel's life, then
    > you can set breakpoints inside "wd" and trace the recognition code, see
    > where it goes wrong.


    Well, without further guidance, this is outside of my limited scope :-(

    >
    > ================================================== ===========================
    >
    > BTW, are you sure it's "invd" and not "ivga"? "invd" works around a
    > fairly specific nVidia BIOS behavior; "ivga" is much more generic. (The
    > issues are completely different and could possibly both occur on the
    > same system, though I've never heard of that.) "ivga" works around a
    > far more common BIOS problem: incorrect setting of the CMOS video type
    > value. In fact, I see that Qemu uses the Bochs video BIOS, and that
    > this very bug was fixed in version 0.5c of that BIOS. See
    > http://www.nongnu.org/vgabios/. That page has compiled BIOS images; you
    > should be able to download a newer one into your Qemu/bios directory.
    > (Update both vgabios.bin and vgabios-cirrus.bin, I'm not sure how to
    > tell which one Qemu will use on your machine.) Then you shouldn't need
    > "ivga".
    >
    > On further examination, I suspect that Qemu's BIOS may have both issues!
    > So you may really mean you are using "invd". Why would it not need
    > "ivga"? Because it gets lucky -- the wrong value that it leaves in CMOS
    > isn't wrong enough to bother OSR5.
    >
    > But you said "oss653a", which is the "ivga" supplement, so in the end my
    > guess is that you're using "ivga" and just typed "invd" into your post
    > by mistake.


    Well, I'm pretty sure about that. Just to refresh my flaky memory, I
    went up again today and I started by using oss653a (link=ivga) but I
    ended up with a blank screen.

    So I gave oss661a.btld a try (link=invd) and I was able to get to the
    laundry list and actually "see" its content so it's the invd which did
    the trick.

    Concerning the vgabios, I used the default one (01 Dec 2004) and I also
    tried version 0.5d which, with Windows XP/2003, gave me some graphic
    problems (4 colours, low resolution); nonetheless, even version 0.5d of
    the VGA bios had problems with OS 5.0.7 so I ended up by reverting to
    the original one and using the oss661a BTLD.

    >
    > ================================================== ===========================
    >
    > I've been running OSR5 under VMware Workstation for several years now.
    > There were some problems at first. These days I have great success with
    > it. VMware now makes a "player" available for free, lets you run
    > previously built virtual machines. You could probably install OSR5 onto
    > that, giving you another free virtual machine that can run OSR5 (without
    > all these issues). But without source -- so if your real goal here was
    > to study the emulation mechanics themselves, that won't do.


    I think that, unless you have more ideas, I'll stick to VmWare Player
    for Linux (and this should sound good for you, right? :-); studyng the
    emulation mechanics is way above my knowledge for now.

    >
    > There, is that scary enough? ;-}
    >


    As usual, from you :-)

    >
    >>Bela<


    Thanks,
    Roberto

    --
    Roberto Zini - r.zini<@AT@>strhold.it
    ---------------------------------------------------------------------
    "Has anybody around here seen an aircraft carrier?"
    (Pete "Maverick" Mitchell - Top Gun)

  7. Re: SCO OS 5.0.7 on Qemu

    Roberto Zini wrote:

    > > Next step I recommend:
    > >
    > > Boot
    > > : defbootstr link=invd wd.debug=ugi

    >
    > Well, I used the following:
    >
    > defbootstr link="invd wd" wd.debug=ugi
    >
    > From inside the emulator I'm able to "switch" the floppy disk emulated
    > image since I had to use 2 BTLDs (one for the invd driver and one for
    > the newer wd one).


    I thought we had determined that the newer "wd" wasn't helping things.
    In any case, you can merge BTLDs. They are EAFS filesystems. Just
    extract their contents and make a new EAFS large enough to hold all the
    files, lay them down in the same tree structure as on the original (same
    place relative to the filesystem root).

    > Well, I did that; problem is that debug messages fill up the screen so
    > I'm not sure if the easy workaround you suggested actually appeared or not.
    >
    > Anyway, what I can see on the screen is (hand written so prone to errors):


    Here's a composite version with items relating to drives other than 0/0
    removed:

    > wd: didn't find any specific known PCI IDE controller, trying by class
    > wd: PCI bus/dev/func 0/1/1, vend/dev 8086/7010, prog_if 80, BMIBA 0000C001
    > wd: unknown but possibly usable PCI IDE controller; assuming UDMA 133
    > wd: if incorrect, add wd.udma=33 (or 66 or 100) to your bootstring.


    This tells us that it sees a PCI IDE controller, but doesn't know the
    specific model. This is normal for the driver. It assumes unknown IDE
    controllers support UDMA133. This is pretty safe because it's only
    going to use that information to see whether it needs to reduce the
    drive's programmed UDMA speed. Presumably if the controller _doesn't_
    support 133, the BIOS will already have programmed the drive to a
    supported (lower) speed, so the driver won't need to do that.

    > wd 0/0: IDENTIFY DEVICE: Status 58, Error 00
    > wd 0/0: non-ATAPI device present


    This shows that it _has_ recognized an IDE hard disk at that position.

    > wd: Drive max supported mode = 4, BIOS selected mode = 5
    > wd: Drive using BIOS selected UDMA mode 5
    > wd 0/0: Common UDMA Mode 4, Max MBoard mode 6, Max dev supt 4
    > wd: Possible UDMA timing mismatch, bootstring may be required
    > wd: add wd.udma=auto for driver attempted auto sense or
    > wd: wd.udma=off to use Programmed I/O (PIO) instead of UDMA


    This stuff doesn't make very much sense, but I think it is still normal
    for the driver. It's telling us that the drive claims it only supposed
    UDMA4 (66), but the BIOS has programmed it for UDMA5 (100), and the
    driver is going to operate it that way. This seems to happen on most
    systems and they work, so I think this is more a mis-description of the
    situation than a real problem.

    > WARNING: hd: no root disk controller was found
    > hd: a Boot-Time Loadable Driver may be required


    .... and somewhere between there and here, it decided there was something
    wrong, yet did _not_ comment on it. :-(

    There's one additional bit of verbosity you can turn on. Boot the
    emulator with:

    Boot
    : defbootstr link="invd wd" wd.debug=ui maindebug

    You will eventually get a scodb prompt. Enter:

    debug> wd_noise=1
    debug> q

    Boot now proceeds as normal, but certain "wd" driver messages that are
    normally suppressed will now print.

    I suggest you boot a normal physical system this way (use the install
    CD) to see what, if any, extra output this produces on a boot that's
    succeeding. Then do it under Qemu and see if it produces any extra
    failure messages.

    > > the next step will be to boot with "defbootstr link=invd maindebug".
    > > That invokes scodb (kernel debugger) early in the kernel's life, then
    > > you can set breakpoints inside "wd" and trace the recognition code, see
    > > where it goes wrong.

    >
    > Well, without further guidance, this is outside of my limited scope :-(


    If we get there, it'll be under my guidance, don't worry...

    > Well, I'm pretty sure about that. Just to refresh my flaky memory, I
    > went up again today and I started by using oss653a (link=ivga) but I
    > ended up with a blank screen.
    >
    > So I gave oss661a.btld a try (link=invd) and I was able to get to the
    > laundry list and actually "see" its content so it's the invd which did
    > the trick.
    >
    > Concerning the vgabios, I used the default one (01 Dec 2004) and I also
    > tried version 0.5d which, with Windows XP/2003, gave me some graphic
    > problems (4 colours, low resolution); nonetheless, even version 0.5d of
    > the VGA bios had problems with OS 5.0.7 so I ended up by reverting to
    > the original one and using the oss661a BTLD.


    Hmmm, OK then. "invd" removes some assumptions about video mode tables
    in the video BIOS image (at the expense of breaking vidi(C)).

    > I think that, unless you have more ideas, I'll stick to VmWare Player
    > for Linux (and this should sound good for you, right? :-); studyng the
    > emulation mechanics is way above my knowledge for now.


    Well, that's fine with me. ;-}

    I am still curious about the inability to light up the IDE driver in
    Qemu...

    >Bela<


+ Reply to Thread