Move the relocated boot1 and arg transfer space from 0x600/0x800 to
0x700/0x900. In theory this should make no difference, apart from the fact
that Buslogic controllers happen to use a few bytes at 0x600 for some sort
of scratch space for it's int 0x13 hook (!!!), causing the machine to crash
badly when the boot2 code makes it's callbacks into boot1 for disk IO.
Submitted by: Robert Nordier <rnordier@freebsd.org>
key? ( -- flag) \ check to see if there's a key to be read from input
ms ( u -- ) \ wait that many milliseconds
seconds ( -- u ) \ get number of seconds from midnight.
'words' now outputs the list page by page - this probably should go
through libstand's pager, but will have to wait for closer integration of
built-ins with Forth...
Submitted partially by: W Gerald Hicks <wghicks@bellsouth.net>
capabilities are: AF, AB, cm, ho, me, cd. The code is hidden behind
-DTERM_EMU - should it cause any problems, you can remove this define
to get back the old behaviour.
You'll find some examples how to use it in src/share/examples/bootforth.
Reviewed by: jkh
the first time block 0 is read. This fix initialises the block
numbers to -1 which isn't the most correct thing for a daddr_t but
it isn't likely to cause a problem in the boot blocks and it could
do with a more thought out fix later.
The bug is probably benign on the i386 but on the alpha it can
cause initial file opens to fail. This is the cause of the "can't
open /boot/boot.conf" errors.
It appears on the alpha because of a number of combining factors.
On the alpha the LABELSECTOR is 0 so block 0 needs to be read in
from the media. The first time this happens you get a false hit
because the bc_blkno field is zero initially. Also, the timestamp
check against this cache hit succeeds because on the alpha a hacked
getsecs() function can return 0 when it starts counting so that
the zero initial timestamp + BCACHE_TIMEOUT is greater than the
current time until getsecs() has counted passed BCACHE_TIMEOUT.
The overall effect is that the first open() that occurs gets a
false cache hit and returns garbage to the bd_strategy() function
which then fails the open() call. This false hit then stays in the
cache until BCACHE_TIMEOUT getsecs() ticks have passed; all open()
calls during this time fail.
This explains why you can generally access the media by the time
you get to interp() and start issuing commands but the earlier
attempts to run the boot scripts are failing.
It's possible that this is causing the problem switching to the
mfsroot floppy as well but I haven't confirmed that.
interface. Do some general consistency fixes and space optimizations.
Use of some freed-up space to defend against possible BIOS misfeatures.
boot2: Revise disk read interface to provide for boot1 changes. Free
up space for this.
o add fkey and fread
o eliminate fexists now that this can be expressed in HLL forth
( : fexists fopen dup -1 <> if fclose 1 else drop 0 then ; ) :-)
Once we get the ability to write files, it should be possible to do
stand-alone rescue work from the 3rd stage boot. :)
