FreeBSD-boot
David van Deijk
> > 3.0 3.1 3.2 3.3 3.4. I have looked into the source and could not
> > find ELF support but only aout. Are you able to tell me wheter this is
> > because of me or that i am right in this elf-aout thingy .
> > ThanX in advance.
>
> try to load /boot/loader with FBSDBOOT.exe, and then boot
> elf kernel from loader
I did try this and he started running /boot/loader @ 0x0100000 and stopped doing anything to my great disappointment.
> I am don't tried to go this way, because of I have no DOS.
>
> > Dag dag David.
>
> --
> TSB Russian Express, Moscow
> Vladimir B. Grebenschikov, vo...@express.ru
>
>
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
David van Deijk
I have encountered Problems using the FBSDBOOT.exe since version
3.0 3.1 3.2 3.3 3.4. I have looked into the source and could not
find ELF support but only aout. Are you able to tell me wheter this is
because of me or that i am right in this elf-aout thingy .
ThanX in advance.
Dag dag David.
Vladimir B. Grebenschikov
> I have encountered Problems using the FBSDBOOT.exe since version
> 3.0 3.1 3.2 3.3 3.4. I have looked into the source and could not
> find ELF support but only aout. Are you able to tell me wheter this is
> because of me or that i am right in this elf-aout thingy .
> ThanX in advance.
try to load /boot/loader with FBSDBOOT.exe, and then boot
elf kernel from loader
I am don't tried to go this way, because of I have no DOS.
> Dag dag David.
--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, vo...@express.ru
To Unsubscribe: send mail to majo...@FreeBSD.org
John Baldwin
On 01-Mar-00 David van Deijk wrote:
> Dear hackers,
>
> I have encountered Problems using the FBSDBOOT.exe since version
> 3.0 3.1 3.2 3.3 3.4. I have looked into the source and could not
> find ELF support but only aout. Are you able to tell me wheter this is
> because of me or that i am right in this elf-aout thingy .
> ThanX in advance.
fbsdboot.exe doesn't work anymore, and it never will. DOS screws up too
many things while it is booting (interrupt vectors, etc.) for the loader
and/or kernel to even have a chance of booting.
> Dag dag David.
--
John Baldwin <j...@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Christian Gusenbauer
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.
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).
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
you can't control the behaviour of the BIOS init routines; eg. the Adaptec BIOS
clears the lower memory and thus the FBSDBOOT code :-(!
I'm sorry, but I think FBSDBOOT is died with aout :-(!
Ciao,
Christian.
Sergey Babkin
>
> 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.
So maybe there is a chance that it can be
adapted for ELF when started from a plain DOS ?
> 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.
> 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.
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
Christian Gusenbauer
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.
Mike Smith
> 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 ?
We weren't using anything like as much volatile system state back then.
> So maybe there is a chance that it can be
> adapted for ELF when started from a plain DOS ?
For the umpteenth time, NO. This can't be done.
> 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.
Now you're starting to think. 8)
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ msm...@freebsd.org
\\ and he'll hate you for a lifetime. \\ msm...@cdrom.com