boot2 broken ? (booting from pst fails)

[Toerless Eckert]

> > With boot2 being space challenged, why does it need to be a btx
> > client anyhow ?
> 
> Because then the code to read UFS can be in C instead of assembly. :)  Are
> you offering to rewrite the entire bootstrap in assembly and maintain it?

No, i was rather thinking about the good ol' mechanism of burning the sectors
for "loaders" into the boot1/boot2 bootstrap code, foregoing the need
to put UFS into boot2 and allowing it to be a simple real-mode loader.

loader itself would still be a btx client but btx then could be improved
to execute BIOS interrupts via a real-mode stub. If necessary this would
invoke copying of read/written buffers between real and virtual mode.

This construction gives the highest compatibility with existing
hardware while still maintain the flexbility of loader. The downside
of being required to burn the loader sectors into boot1/boot2 is in 
my option quite acceptable. I just think that maximizing compatibility
between FreeBSD and hardware especially on PC platform should be a design
goal. Right now the approach is just the other way around. With this
virtual mode in boot/loader FreeBSD has put itself into the position of
being potentially much _less_ compatible than othre operating systems.
We can argue aout the quantity, but quite frankly that's not even the
point.

> Well, considering there is no "official" standard for a BIOS (if you find
> one, please let us know)

Well, i found a couple of places listing INT functionality, like for
example the dev. documentation for grub, and there it says "real mode only"
but yes, nothing directly from the three rulers of the universe. I'd
still claim that "real mode only" for BIOS is rather a long time rule than
an urban legend ;-)

> policy of discouraging use of PM directly in BIOS routines.  In reality,
> very few BIOS's have these types of problems.  pst(4) is one of the few
> that doesn't work in this model. 

right, and there's not a single line in the boot/loader or pst() documentation
highlighting this situation.

> Also, I do know of at least one BIOS
> vendor I worked with recently to straighten out some kinks with BTX that
> specifically checks to see if they are in VM86 mode when executing in order
> to handle some special cases.

But here's the point: people buy PC hardware because it's cheap. Guess why
it's cheap. If i had the money to buy a sun with a comparable system with
raid, do you think i'd hang around with a PC ? Or for that matter with
a clone of forth in loader if i can have real open boot prom where i can
read and change the forth initialization routines of add-on cards instead
of having to hope that the binary BIOS oroutines f some PC cards is compatible
with the motherboard BIOS ? Heck, i had to return two motherboards because
they couldn't initialize raid, scsi and firewire being in the system at
the same time.

In a cheesy hardware environment like PC the right thing to do is to
minimize the expectations on what that stuff can do, especially the BIOS.
You don't have to be better on this than the competition (linux, *bsd, windows),
but you shouldn't be much more expectant. *BSDs strong point has always been
to be architecturally and implementation wise more advanced than Linux. Raising
the bar for hardware is NOT compliant with that goal if you ask me. It is
rather going for the easy catch of the nice loader/non-burned-sectors
but leaving interoperablity in the corner. That's really something i'd have
expected from Linux.

> Actually, some vendors have fixed their BIOS drivers in the past. :)  If
> Promise does not wish to fix their BIOS, then either buy some other product
> without these issues or use a standalone hard drive, CD, floppy, or network
> boot to load the kernel.

There aren't that many inexpensive raid5 controllers on the market (sure,
the list of the ones supported by freebsd is long, but check availablity,
price and actual speeds supported). If you build a RAID system, it is
logical to expect that you can also boot from it. Of course vendors suck.
If there was a single comparable product that would officially support
FreeBSD and be not more than 50% more expensive than this product, then
i'd have gone for that immediately. There is not. I am not aware of a single
Raid controller where the vendors website officially says freebsd supported.
And given that these BIOS incompatiblities are not documented in FreeBSD,
neither for pst, nor for the VM-issue of boot2/loader, i've only got that
much cycles to trying to find a working combination, right ?

> It might have been 4.0, yes.  4.0 came out in the previous millenium
> however, and we haven't really had major issues with it.

Well, don't worry for me, i've just got myself a nice PQI DOM module
to put the boot environment (and DOS tools *sigh*) onto, but don't think that
FreeBSD is not putting itself into a boot challenged corner just because
98% of people have a standard PC with boot devices supported by three
standard onboard BIOSses. After all, in the past *BSD was _the_ preferred
OS for all kind of embedded/OEM applications, but these kind of issues
can become a quick tie breaker towards the end of such system builders
going for Linux. 

Cheers
	Toerless