2015-03-31 22:32:35 +00:00
|
|
|
\ Copyright (c) 1999 Daniel C. Sobral <dcs@FreeBSD.org>
|
|
|
|
|
\ Copyright (c) 2011-2015 Devin Teske <dteske@FreeBSD.org>
|
1999-03-09 14:06:55 +00:00
|
|
|
\ All rights reserved.
|
|
|
|
|
\
|
|
|
|
|
\ Redistribution and use in source and binary forms, with or without
|
|
|
|
|
\ modification, are permitted provided that the following conditions
|
|
|
|
|
\ are met:
|
|
|
|
|
\ 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
\ notice, this list of conditions and the following disclaimer.
|
|
|
|
|
\ 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
\ notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
\ documentation and/or other materials provided with the distribution.
|
|
|
|
|
\
|
|
|
|
|
\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
\ SUCH DAMAGE.
|
|
|
|
|
\
|
1999-08-28 01:08:13 +00:00
|
|
|
\ $FreeBSD$
|
1999-03-09 14:06:55 +00:00
|
|
|
|
2015-04-01 01:54:28 +00:00
|
|
|
only forth definitions
|
|
|
|
|
|
2000-06-14 19:39:31 +00:00
|
|
|
s" arch-i386" environment? [if] [if]
|
|
|
|
|
s" loader_version" environment? [if]
|
2001-12-11 00:49:34 +00:00
|
|
|
11 < [if]
|
|
|
|
|
.( Loader version 1.1+ required) cr
|
2000-06-14 19:39:31 +00:00
|
|
|
abort
|
|
|
|
|
[then]
|
|
|
|
|
[else]
|
|
|
|
|
.( Could not get loader version!) cr
|
|
|
|
|
abort
|
|
|
|
|
[then]
|
|
|
|
|
[then] [then]
|
2000-06-07 22:19:49 +00:00
|
|
|
|
2001-05-29 23:49:10 +00:00
|
|
|
256 dictthreshold ! \ 256 cells minimum free space
|
|
|
|
|
2048 dictincrease ! \ 2048 additional cells each time
|
|
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
include /boot/support.4th
|
2012-10-08 23:02:35 +00:00
|
|
|
include /boot/color.4th
|
2013-11-07 21:52:04 +00:00
|
|
|
include /boot/delay.4th
|
2015-03-31 23:00:48 +00:00
|
|
|
include /boot/check-password.4th
|
1999-03-09 14:06:55 +00:00
|
|
|
|
2015-04-01 01:54:28 +00:00
|
|
|
only forth definitions
|
Enhance boot-conf.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
2000-09-08 21:11:57 +00:00
|
|
|
|
2013-11-04 20:28:10 +00:00
|
|
|
: bootmsg ( -- )
|
2015-03-31 23:00:48 +00:00
|
|
|
loader_color? dup ( -- bool bool )
|
|
|
|
|
if 7 fg 4 bg then
|
|
|
|
|
." Booting..."
|
2015-04-08 20:10:42 +00:00
|
|
|
if me then
|
2015-03-31 23:00:48 +00:00
|
|
|
cr
|
2013-11-04 20:28:10 +00:00
|
|
|
;
|
|
|
|
|
|
2011-12-30 06:24:59 +00:00
|
|
|
: try-menu-unset
|
2012-01-09 20:25:14 +00:00
|
|
|
\ menu-unset may not be present
|
|
|
|
|
s" beastie_disable" getenv
|
|
|
|
|
dup -1 <> if
|
|
|
|
|
s" YES" compare-insensitive 0= if
|
|
|
|
|
exit
|
|
|
|
|
then
|
|
|
|
|
else
|
|
|
|
|
drop
|
|
|
|
|
then
|
2011-12-30 06:24:59 +00:00
|
|
|
s" menu-unset"
|
2012-01-09 20:25:14 +00:00
|
|
|
sfind if
|
|
|
|
|
execute
|
|
|
|
|
else
|
|
|
|
|
drop
|
2011-12-30 06:24:59 +00:00
|
|
|
then
|
2012-11-06 19:26:36 +00:00
|
|
|
s" menusets-unset"
|
|
|
|
|
sfind if
|
|
|
|
|
execute
|
|
|
|
|
else
|
|
|
|
|
drop
|
|
|
|
|
then
|
2011-12-30 06:24:59 +00:00
|
|
|
;
|
|
|
|
|
|
2015-04-01 01:54:28 +00:00
|
|
|
only forth also support-functions also builtins definitions
|
|
|
|
|
|
Enhance boot-conf.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
2000-09-08 21:11:57 +00:00
|
|
|
: boot
|
2000-09-16 21:04:49 +00:00
|
|
|
0= if ( interpreted ) get_arguments then
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
|
First tackle at trying to handle the New Deal on kernels.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
2000-09-09 04:52:34 +00:00
|
|
|
\ Unload only if a path was passed
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
dup if
|
|
|
|
|
>r over r> swap
|
First tackle at trying to handle the New Deal on kernels.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
2000-09-09 04:52:34 +00:00
|
|
|
c@ [char] - <> if
|
|
|
|
|
0 1 unload drop
|
|
|
|
|
else
|
2000-10-09 11:29:40 +00:00
|
|
|
s" kernelname" getenv? if ( a kernel has been loaded )
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2013-11-04 20:28:10 +00:00
|
|
|
bootmsg 1 boot exit
|
2000-09-16 19:49:52 +00:00
|
|
|
then
|
2000-10-09 11:29:40 +00:00
|
|
|
load_kernel_and_modules
|
|
|
|
|
?dup if exit then
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2013-11-04 20:28:10 +00:00
|
|
|
bootmsg 0 1 boot exit
|
First tackle at trying to handle the New Deal on kernels.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
2000-09-09 04:52:34 +00:00
|
|
|
then
|
|
|
|
|
else
|
2000-10-09 11:29:40 +00:00
|
|
|
s" kernelname" getenv? if ( a kernel has been loaded )
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2013-11-04 20:28:10 +00:00
|
|
|
bootmsg 1 boot exit
|
2000-09-16 19:49:52 +00:00
|
|
|
then
|
2000-10-09 11:29:40 +00:00
|
|
|
load_kernel_and_modules
|
|
|
|
|
?dup if exit then
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2013-11-04 20:28:10 +00:00
|
|
|
bootmsg 0 1 boot exit
|
First tackle at trying to handle the New Deal on kernels.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
2000-09-09 04:52:34 +00:00
|
|
|
then
|
2000-09-16 20:20:44 +00:00
|
|
|
load_kernel_and_modules
|
2013-11-04 20:28:10 +00:00
|
|
|
?dup 0= if bootmsg 0 1 boot then
|
Enhance boot-conf.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
2000-09-08 21:11:57 +00:00
|
|
|
;
|
|
|
|
|
|
2011-12-30 06:24:59 +00:00
|
|
|
\ ***** boot-conf
|
|
|
|
|
\
|
|
|
|
|
\ Prepares to boot as specified by loaded configuration files.
|
|
|
|
|
|
Enhance boot-conf.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
2000-09-08 21:11:57 +00:00
|
|
|
: boot-conf
|
2000-09-16 21:04:49 +00:00
|
|
|
0= if ( interpreted ) get_arguments then
|
First tackle at trying to handle the New Deal on kernels.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
2000-09-09 04:52:34 +00:00
|
|
|
0 1 unload drop
|
2000-09-16 20:20:44 +00:00
|
|
|
load_kernel_and_modules
|
Enhance boot-conf.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
2000-09-08 21:11:57 +00:00
|
|
|
?dup 0= if 0 1 autoboot then
|
1999-03-09 14:06:55 +00:00
|
|
|
;
|
|
|
|
|
|
2015-04-01 01:54:28 +00:00
|
|
|
also forth definitions previous
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
|
Enhance boot-conf.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
2000-09-08 21:11:57 +00:00
|
|
|
builtin: boot
|
2000-06-07 22:10:05 +00:00
|
|
|
builtin: boot-conf
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
|
2000-06-07 22:10:05 +00:00
|
|
|
only forth definitions also support-functions
|
|
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
\ ***** start
|
|
|
|
|
\
|
|
|
|
|
\ Initializes support.4th global variables, sets loader_conf_files,
|
2013-11-04 20:28:10 +00:00
|
|
|
\ processes conf files, and, if any one such file was succesfully
|
|
|
|
|
\ read to the end, loads kernel and modules.
|
1999-03-09 14:06:55 +00:00
|
|
|
|
|
|
|
|
: start ( -- ) ( throws: abort & user-defined )
|
|
|
|
|
s" /boot/defaults/loader.conf" initialize
|
|
|
|
|
include_conf_files
|
2002-05-24 02:28:58 +00:00
|
|
|
include_nextboot_file
|
1999-03-09 14:06:55 +00:00
|
|
|
\ Will *NOT* try to load kernel and modules if no configuration file
|
|
|
|
|
\ was succesfully loaded!
|
|
|
|
|
any_conf_read? if
|
2013-11-07 21:52:04 +00:00
|
|
|
s" loader_delay" getenv -1 = if
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
load_xen_throw
|
2013-11-07 21:52:04 +00:00
|
|
|
load_kernel
|
|
|
|
|
load_modules
|
|
|
|
|
else
|
|
|
|
|
drop
|
|
|
|
|
." Loading Kernel and Modules (Ctrl-C to Abort)" cr
|
|
|
|
|
s" also support-functions" evaluate
|
loader: implement multiboot support for Xen Dom0
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
|
|
|
s" set delay_command='load_xen_throw load_kernel load_modules'" evaluate
|
2013-11-07 21:52:04 +00:00
|
|
|
s" set delay_showdots" evaluate
|
|
|
|
|
delay_execute
|
|
|
|
|
then
|
1999-03-09 14:06:55 +00:00
|
|
|
then
|
|
|
|
|
;
|
|
|
|
|
|
1999-05-14 18:59:27 +00:00
|
|
|
\ ***** initialize
|
|
|
|
|
\
|
|
|
|
|
\ Overrides support.4th initialization word with one that does
|
|
|
|
|
\ everything start one does, short of loading the kernel and
|
|
|
|
|
\ modules. Returns a flag
|
|
|
|
|
|
|
|
|
|
: initialize ( -- flag )
|
|
|
|
|
s" /boot/defaults/loader.conf" initialize
|
|
|
|
|
include_conf_files
|
2002-05-24 02:28:58 +00:00
|
|
|
include_nextboot_file
|
1999-05-14 18:59:27 +00:00
|
|
|
any_conf_read?
|
|
|
|
|
;
|
|
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
\ ***** read-conf
|
|
|
|
|
\
|
|
|
|
|
\ Read a configuration file, whose name was specified on the command
|
|
|
|
|
\ line, if interpreted, or given on the stack, if compiled in.
|
|
|
|
|
|
|
|
|
|
: (read-conf) ( addr len -- )
|
2009-01-05 20:09:54 +00:00
|
|
|
conf_files string=
|
1999-03-09 14:06:55 +00:00
|
|
|
include_conf_files \ Will recurse on new loader_conf_files definitions
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
: read-conf ( <filename> | addr len -- ) ( throws: abort & user-defined )
|
|
|
|
|
state @ if
|
|
|
|
|
\ Compiling
|
|
|
|
|
postpone (read-conf)
|
|
|
|
|
else
|
|
|
|
|
\ Interpreting
|
|
|
|
|
bl parse (read-conf)
|
|
|
|
|
then
|
|
|
|
|
; immediate
|
|
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
\ show, enable, disable, toggle module loading. They all take module from
|
|
|
|
|
\ the next word
|
1999-04-24 17:25:35 +00:00
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
: set-module-flag ( module_addr val -- ) \ set and print flag
|
|
|
|
|
over module.flag !
|
|
|
|
|
dup module.name strtype
|
|
|
|
|
module.flag @ if ." will be loaded" else ." will not be loaded" then cr
|
1999-04-24 17:25:35 +00:00
|
|
|
;
|
|
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
: enable-module find-module ?dup if true set-module-flag then ;
|
|
|
|
|
|
|
|
|
|
: disable-module find-module ?dup if false set-module-flag then ;
|
|
|
|
|
|
|
|
|
|
: toggle-module find-module ?dup if dup module.flag @ 0= set-module-flag then ;
|
1999-04-24 17:25:35 +00:00
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
\ ***** show-module
|
|
|
|
|
\
|
|
|
|
|
\ Show loading information about a module.
|
|
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
: show-module ( <module> -- ) find-module ?dup if show-one-module then ;
|
1999-03-09 14:06:55 +00:00
|
|
|
|
|
|
|
|
\ Words to be used inside configuration files
|
|
|
|
|
|
|
|
|
|
: retry false ; \ For use in load error commands
|
|
|
|
|
: ignore true ; \ For use in load error commands
|
|
|
|
|
|
|
|
|
|
\ Return to strict forth vocabulary
|
|
|
|
|
|
2000-09-16 21:04:49 +00:00
|
|
|
: #type
|
|
|
|
|
over - >r
|
|
|
|
|
type
|
|
|
|
|
r> spaces
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
: .? 2 spaces 2swap 15 #type 2 spaces type cr ;
|
|
|
|
|
|
|
|
|
|
: ?
|
|
|
|
|
['] ? execute
|
|
|
|
|
s" boot-conf" s" load kernel and modules, then autoboot" .?
|
|
|
|
|
s" read-conf" s" read a configuration file" .?
|
|
|
|
|
s" enable-module" s" enable loading of a module" .?
|
|
|
|
|
s" disable-module" s" disable loading of a module" .?
|
|
|
|
|
s" toggle-module" s" toggle loading of a module" .?
|
|
|
|
|
s" show-module" s" show module load data" .?
|
2013-11-17 18:12:17 +00:00
|
|
|
s" try-include" s" try to load/interpret files" .?
|
2000-09-16 21:04:49 +00:00
|
|
|
;
|
|
|
|
|
|
2013-11-17 18:12:17 +00:00
|
|
|
: try-include ( -- ) \ see loader.4th(8)
|
|
|
|
|
['] include ( -- xt ) \ get the execution token of `include'
|
|
|
|
|
catch ( xt -- exception# | 0 ) if \ failed
|
|
|
|
|
LF parse ( c -- s-addr/u ) 2drop \ advance >in to EOL (drop data)
|
|
|
|
|
\ ... prevents words unused by `include' from being interpreted
|
|
|
|
|
then
|
|
|
|
|
; immediate \ interpret immediately for access to `source' (aka tib)
|
|
|
|
|
|
2015-04-01 01:54:28 +00:00
|
|
|
only forth definitions
|
