Date: Mon, 14 Apr 2003 22:08:59 +0200 (MEST) From: Toerless Eckert <eckert@i4.informatik.uni-erlangen.de> To: jhb@FreeBSD.org (John Baldwin) Cc: eckert@i4.informatik.uni-erlangen.de Subject: Re: boot2 broken ? (booting from pst fails) Message-ID: <200304142009.WAA26011@faui40p.informatik.uni-erlangen.de> In-Reply-To: <XFMail.20030414151449.jhb@FreeBSD.org> from John Baldwin at "Apr 14, 2003 3:14:49 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200304142009.WAA26011>