vmware bochs osr5 under linux

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@caldera.com>
Subject: Re: INT13 function FAh during boot?
Date: Wed, 24 Apr 2002 01:19:33 GMT
References: <c12f3009.0204221242.29c063c4@posting.google.com> <20020422173448.A9014@mammoth.ca.caldera.com> <c12f3009.0204230653.6be8199b@posting.google.com> 

Carl Sopchak wrote:

> I'll check out the VMWare thread.  Could provide useful info, even if
> it is not directly related to Int13/FAh.  Thanks for the pointer...

It might.  Also, your experiences with bochs might be helpful to the
people struggling with VMWare -- all indications are that VMWare has no
interest in trying to work with OpenServer, so maybe those people should
stop beating their heads against it and use something that tries to
work.

> As far as other issues trying to run OSR5 on bochs, I've got a hacked
> bios that gets around initial boot problems, but the kernel

What initial boot problems are you talking about?  Just the INT13:FA
problem?  That is, I believe, a bug in the bochs BIOS.  It should accept
any unknown BIOS call, returning with carry set (and as I said,
registers unchanged, but I'm not so sure about that.  Probably couldn't
hurt, though.)

Now, bochs probably has a really good reason not to do that: in order
to ferret out yet-unknown calls that they need to implement in order to
improve the emulation.  But that should be a setting that you control --
you should be able to set it to behave like a system that doesn't have
the service; or to balk, like it currently does.  You would only use the
latter setting if you were a bochs developer (or were trying to debug a
failure).

> initialization causes it to crash at F dptrinit (I once made it to F
> fdi_init).  I know I've run across the list describing these
> initialization steps, but can't put my finger on it.  Can anyone point
> me to it?

See http://osr5doc.ca.caldera.com:457/HANDBOOK/tshootD.kinilet.html for
documentation on the boot letter sequence.  But it only briefly covers
the "F" series, which is where you're likely to have the most trouble.
When it says "F xxinit", it's initializing driver "xx".  The ones that
are most likely to cause you trouble are hardware drivers.  The two you
mention are the drivers for older DPT SCSI and RAID host adapters, and
for the Future Domain 18x0 chipset (Future Domain 16x0, 600, 700, and
Adaptec 292x host adapters).

bochs probably emulates a single variety of SCSI host adapter, something
that has simple hardware and is easy to emulate.  As long as it isn't
one of those two, you can just disable those host adapter drivers.  The
syntax is:

  Boot
  : defbootstr disable=dptr,fdi_

OpenServer drivers have two names, which are _usually_ the same, but in
the case of that Future Domain driver they are different.  One is "fdhb"
and the other is "fdi_".  I'm not sure which you must specify in the
"disable" statement.  Actually it looks like there's no harm in
attempting to disable unrecognized drivers, so just give it:

  Boot
  : defbootstr disable=dptr,fdhb,fdi_

If it hangs at other "F xxinit" points, add those to your disable list.
Once you've successfully installed, the host adapter drivers that don't
apply to your system will be linked out of the kernel, so you won't have
to keep doing this.

> Bela, thanks for the info on the LAN boot proms.  Do you mind if I
> copy your response (with credit, of course) into the bochs bug report
> that I initiated on the bochs site?  I'm sure it would be helpful to
> their development.

That's fine with me.  Plus this message with the more details and
ranting.  ;-}

> If people are interested, I could keep this newsgroup updated on my
> attempts to get OSR5 running on Linux.  Let me know.

Yes, please do.  A fair number of people have asked about this sort of
thing, and everything's archived forever (until google gets bored with
it) in groups.google.com...

>Bela<
 

Take Control of Maintaining Your Mac

Take Control of Syncing Data in Snow Leopard

Take Control of Upgrading to Snow Leopard

Macworld Total Snow Leopard Superguide

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.