Date: Wed, 23 Jul 1997 11:05:51 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: j_mini@efn.org Cc: msmith@atrad.adelaide.edu.au, 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: <199707230135.LAA04382@genesis.atrad.adelaide.edu.au> In-Reply-To: <19970722104258.29583@micron.efn.org> from Jonathan Mini at "Jul 22, 97 10:42:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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) > 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. > 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. > 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? > 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? > 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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707230135.LAA04382>