Date: Wed, 12 Jan 2000 20:37:27 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-stable@freebsd.org Subject: Re: fbsdboot.exe can't load elf kernels Message-ID: <20000112203727.G7734@speedy.gsinet> In-Reply-To: <200001120828.AAA00633@mass.cdrom.com>; from msmith@freebsd.org on Wed, Jan 12, 2000 at 12:28:20AM -0800 References: <Pine.BSF.4.21.0001121004110.2653-100000@assa> <200001120828.AAA00633@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 12, 2000 at 00:28 -0800, Mike Smith wrote:
>
> The ability to load and start a kernel != the ability to boot
> and run same.
>
> You cannot boot and run FreeBSD once DOS has been booted on the
> system. You should give up now before you waste any more of
> your or our time.
Sorry for butting in, but ...
What's that bad about pure(!) DOS running in an early stage? To
make it clear: I'm NOT talking about "memory managers" running
already, having scrambled descriptor tables or enabling i386
features (like virtual mode or special CPU's management
features).
I sometimes liked to have a config.sys boot menu allowing for
less experienced users (or even the experienced but lazy ones:)
to have a description and choose by aim and shoot besides having
a fallback config at timeout and a textual configuration which
can be adjusted by ANY system running on this particular machine
(to add choices, to change defaults, etc).
And I remember some hardware which had to see its DOS driver for
downloading images, doing nasty port access magic to enable
compatibility modes, activating certain features or doing
configuration another OS doesn't know about, etc. Without this
driver being run the hardware is outright unusable. (You might
call it broken hardware, but I DID have such stuff like a CMD640B
based EIDE controller in an Asus SP3 which was quite problematic
back in 1995. And I remember some sound cards needing their DOS
driver to configure and enable them, i.e. make them look like a
SoundBlaster and have it unlocked. And I could think of NIC
clones needing some sort of pushing to look like their idol.)
To cut it short: I ALWAYS appreciate a boot loader which works
from DOS, since the "native" loaders coming with the separate
OSes might not always fit or cope with the hardware or its
configuration.
To get this one more concrete (and please don't take this as a
rejection "your software doesn't work for me" -- it's just
"suboptimal" and "less comfortable as other systems are for me"):
FreeBSD is unable to boot from my usual workstation's JAZ since
it's the third SCSI drive on the machine. So I had to move to a
different computer for trying out FBSD. This keeps me from using
some of the workstation's special hardware and from comparing
FreeBSD to the other systems which are on the machine.
Installing on the spare machine I'm always caught by the aha1510
being unsupported since CAM has been introduced in 3.0(?). So I
cannot access the CDROM drive and have to do a network install.
If only I wouldn't have these little problems with the NICs I
tried in this machine. And it's slow and old (I guess that's why
it's available to "play with" :)
I think you get my point: I WISH I had a DOS based loader to
start an image which could provide a complete kernel with all the
nessecary drivers to get a grip to all the hardware needed to
operate the way I'm used to. Booting from a partition or without
intervention of DOS based software is not always an option.
Sometimes this "reduced choice of means" even leaves the machine
unable to make it to FreeBSD running at all :( And duplicating
the effort which has gone into the DOS software (if at all
possible and feasible) looks like the wrong way to go.
I will have a look at the ELF enabled fbsdboot.exe. And if it
works -- what's the problem in delivering this one with the
distro for those of us who need it desparately?
> There are good technical reasons why this is the case. If you
> don't understand them, please trust those of us that do.
Could you please give a pointer where to learn more about this IF
there's such a reason besides the "memory managers" at all? I'm
aware of the complexity HIMEM and EMM & Co add to this field.
But once they are eliminated -- is there still something speaking
against DOS based boot loaders? I could live with this
requirement to keep those managers away and I feel most other
people could so, too, if they cannot or don't want to avoid to
enter DOS.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000112203727.G7734>