Hi Sergey!
I think you wrote on Fr , 03 Mär 2000:
> Christian Gusenbauer wrote:
> >
> > Hi David!
> >
> > I'm sorry for you, but FBSDBOOT will never support ELF binaries :-(! As
> > developer of this utility I had a discussion about supporting ELF when ELF was
> > introduced into FreeBSD. The reason, why ELF support was not integrated is, that
> > the new boot loader and the kernel rely on the state of the hardware, BIOS
> > and BIOS extensions.
>
> Sorry for a stupid question but how was it able
> to boot with aout ? I think FBSDBOOT never worked
> after HIMEM.SYS and things like it were loaded,
> it always required a clear plain DOS to work.
No, that's not a stupid question - it's a kind of question I was waiting for
;-)! FBSDBOOT *did* work with memory managers like himem or 386max. It even
worked (sometimes) when called within Windows 3.1x (have a look at winboot in
the experimental directory)! You did not need a clean DOS boot.
The old aout kernel never relied on the memory layout. So it was possible for
me, to load the kernel and execute it. Just load the kernel at 1 MB and start
it - that's it!
> So maybe there is a chance that it can be
> adapted for ELF when started from a plain DOS ?
No, because booting DOS is the reason, why the new FreeBSD boot loader and/or
kernel can't be executed! They both assume, that they were started from the
BIOS using the INT 19h. And that's it. When you boot DOS or an other OS, this
assumption is no longer valid and booting FreeBSD fails.
> > Since booting DOS modifies the lower memory and hardware settings (eg. sets
> > registers, or modifies interrupt vectors) this state will not exist, when you
> > start FBSDBOOT. FBSDBOOT itself *can not* restore this state and therefore
> > fails to start up the ELF binary (loader and/or kernel).
>
> How about loading the kernel starting at 1MB
> and leaving the memory under 1MB unused ?
> Then you won't even have to restore the interrupt
> vectors: as long as DOS is left in its place all the
> interrupts should not get broken.
Yes, you're right. That is the same opinion I had, when I started playing
with ELF support for FBSDBOOT. But you really need a clean DOS boot (ie. no
drivers loaded, no TSRs loaded etc.) and then perhaps it's possible to boot
FreeBSD. I have a FBSDBOOT version, which loads ELF binaries. I tested various
kernel configurations and found out, that some kernels booted and some did not.
Especially using the VM86 option prevents the kernel from booting, even if you
booted a "clean" DOS.
> > Of course, there is a well known address in the BIOS, where the original
> > interrupt descriptor table is located, but restoring this table is not enough.
> > You also have to re-initialise the various devices (eg. Adaptec Controller). But
>
> I wonder why would you have to do that ? I guess
> this would be needed only after the ASPI driver was
> loaded. But if it was not then DOS just blindly calls
> the BIOS. And I guess for the boot code there
> shoul be no difference whether this is IDE
> BIOS or Adaptec BIOS.
Because I wanted to recreate the memory as it was when the BIOS finished the
initialisation phase and called the INT 19h interrupt to boot an OS. The first
step was to restore the interrupt descriptor table. This step was quite easy
;-). Then I had to call the BIOS extensions to initialise themself, because
some of them want to modify the interrupt table. Unfortunately, the Adaptec
BIOS init routine clears the low memory ...
> Well, maybe nowadays when the plain DOS is almost
> completely displaced by Windows 9x maybe future
> work on FBSDBOOT is not worth the effort in any
> case.
>
> -SB
Yes, that's my opinion, too. It's a kind of sisyphean task. You solve one
problem and get two new problems for free ;-)!
Ciao,
Christian.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
