Re: SCO OS 5.0.7 on Qemu
- From: Bela Lubkin <filbo@xxxxxxxxxx>
- Date: 14 Jan 2006 15:54:44 -0500
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<
.
- References:
- SCO OS 5.0.7 on Qemu
- From: Rob
- Re: SCO OS 5.0.7 on Qemu
- From: Bela Lubkin
- Re: SCO OS 5.0.7 on Qemu
- From: Rob
- SCO OS 5.0.7 on Qemu
- Prev by Date: Re: transparent printer with pc
- Next by Date: Re: OSR507, TuneUp 6.0.0P, MP4 - Undefined symbol
- Previous by thread: Re: SCO OS 5.0.7 on Qemu
- Next by thread: Re: Remote printing problem with Open Server 5.0.6
- Index(es):
Relevant Pages
|
