boot time. Instead, read it a sector at a time. While this sounds
like a significant slowdown, I've not been able to measure any
signficant difference.
Submitted by: luigi
Reviewed by: jhb, sam (both a while ago)
MFC After: 3 days
it possible to make UFS1_ONLY and UFS2_ONLY versions which fit inside the
traditional 16 sectors.
Remove assorted now unneeded hackery.
UFS1_AND_UFS2 still needs another 150 bytes to work, and that is probably
not within our reach, ever.
Conditionalize the "XX bytes left" checks reference on UFS1/UFS12.
Conditionally build the necessary 64bit math for boot2 if UFS12.
Sponsored by: DARPA & NAI Labs.
Load 4 sectors more than we used to. This is harmless overhead for
the UFS1_ONLY case, but sufficient for boot2(UFS1+2).
Sponsored by: DARPA & NAI Labs
dedicated" mode. This was specifying that there are 256 (illegal!)
heads on the disk. If bioses store that in a byte, and it gets truncated
to 0, then that almost certainly causes the infamous divide-by-zero
nightmare.
This is also most likely the reason why the Thinkpad T20/A20 series
were locking up when FreeBSD was installed. This is also the most likely
reason why a boot1 being present causes an IA64 box to lock up at boot.
(removing the "part4" stuff from boot1.s fixes the IA64 boxes and would
most likely have fixed the T20/A20 and some TP600E series thinkpads)
the first sector of the emulated floppy to contain a valid MS-DOS BPB that
it can modify. Since boot1 is the first sector of boot.flp, this resulted
in the BIOS overwriting part of boot1: specifically the function used to
read in sectors from the disk.
Submitted by: Mark Peek <mark@whistle.com>
Submitted by: Doug Ambrisko <ambrisko@ambrisko.com>
PR: i386/26382
Obtained from: NetBSD, OpenBSD (the example BPB)
MFC after: 1 month
with the new binutils. Now that we have a decent assembler, all the old
m4 macros are no longer needed. Instead, straight assembly can be used
since as(1) now understands 16-bit addressing, branches, etc. Also,
several bugs have been fixed in as(1), allowing boot0.s to be further
cleaned up.
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>
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.
