Date: Tue, 22 Jul 1997 22:51:27 -0700 From: Jonathan Mini <j_mini@efn.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: bde@zeta.org.au, imp@rover.village.org, freebsd-current@FreeBSD.ORG, pechter@lakewood.com, terry@lambert.org Subject: Re: Boot file system idea! Slick Message-ID: <19970722225126.52940@micron.efn.org> In-Reply-To: <199707230135.LAA04382@genesis.atrad.adelaide.edu.au>; from Michael Smith on Wed, Jul 23, 1997 at 11:05:51AM %2B0930 References: <19970722104258.29583@micron.efn.org> <199707230135.LAA04382@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith stands accused of saying : > Jonathan Mini stands accused of saying: > > Michael Smith stands accused of saying : > > > > > I particularly want this to be able to talk to the PnP and ESCD BIOS > > > functions in order to suck their brains before the kernel starts. The > > > alternative is for someone helpful (like yourself) to suggest how I > > > would go about calling a 16-bit protected mode BIOS interface from the > > > kernel. I can supply lots more disgusting details about the interface > > > if you like, but basically I don't grok x86 assembler well enough to > > > produce it from scratch. > > > > Hmmm. Amazingly enough, we both have a few common interests here. You're > > Hey, when have we ever been at odds? 8) Heh. Well. "Comrades in battle" comes to mind. > > > working a _little_ earlier in the boot process than I am, but I also want to > > see some BIOS call-back abilities in the FreeBSD kernel. It seems insane, but > > there are a few things that I would like to see FreeBSD support that it > > currently can't, due to it's inability to talk to any BIOS. > > Part of the problem here is that talking to the BIOS is _dangerous_, > particularly if you're talking to a real-mode BIOS. Very true. I _hate_ the way BIOS works. I hate a lot of other things about the initial IBM PC design and how we're stuck with it now. There are a few things we can do that will make it a "little" safer, such as run under a protected priveledge level and watch accesses -- i.e. restrict them to ranges, but that is not an option for a high-performance solution. > > 1) Simply drop back into real mode and (possibly) restore the real-mode > > interrupt vector table. Then run your code, and when it returns, jump > > back into protected mode. If you keep your mappings correct, this can > > be only mildly slow. (This is referred to as a DOS call-back) > > I don't want to think about this approach, really. Unless there is an > extreme need, going back to real mode isn't an option. IMHO, real mode should be used the wau Intel intended it in the i386 spec -- To set up the registers to switch into protected mode. Intel didn't even recommend using real mode during the bootstrap loading phase. I'm not certain life would be easer or not if BIOS handed us a Protected mode boot environment. IMHO, it could be very gastly bepending on how BIOS though we should run our OS. > > 2) My favorite method. Take your saved interrupt vector table and put > > it at the begining of a v86 TSS. Also, map in the appropriate amount of > > memory, and the ROM address space. Effectively, you get the effect of > > FreeBSD being a overly complex memory manager for DOS, since this is > > what QEMM and a few others do. The v86 TSS can be multitasked like a > > doscmd process, and several other things. The only problem is that > > If this is your favorite method, I assume that you have code implementing > it already? No. However, I will start writing code in the near future (less than a month) > > I would like to see something like this go into effect, since it > > would allow for things such as VESA VBE 2.0 support under > > FreeBSD. With VESA VBE, we would be able to solve the "how do I > > reset the video hardware?" problem that the syscons has for > > supporting graphics resolutions. I think a solution much prettier > > than linux's libsvga would be possible, if we were able to use VBE > > 2.0. > > Isn't there a 32-bit interface to the VESA BIOS? VBE 2.0 has a 32-bit interface, yes. However, the information requred to USE the interface has to be gotten via a standard 16-bit interrupt call. (Ugh. BIOS) Also, not all of the functions are available in the 32-bit API. You are requied to set up a set of descripters with the proper priveledges (it gives you a list of ports and memory blocks it needs access to) and you call an interrupt service with that info, then it returns with your table all filled with code to do the stuff you want. The evilness of it is that this table has to be in a real mode adressable segment. Once you do all this, you can remap (or copy) the table to anywhere you like, but you only get to access Functions 5 (Set Address Window), 7 (Set display start), and 9 (Set Primary Palette) As you can tell, the Protected mode interface is only for extra performance (a drop back into real-mode is really slow) for DOS games. Goo foresight of VESA. Within a short period, I will be looking into running stuff within v86 tasks. (My soul screams against it, it seems incredibly backwards and lame) > > > Jonathan Mini (j_mini@efn.org) > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970722225126.52940>