Date: Tue, 22 Jul 1997 10:42:58 -0700 From: Jonathan Mini <j_mini@efn.org> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: Bruce Evans <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: <19970722104258.29583@micron.efn.org> In-Reply-To: <199707220740.RAA28361@genesis.atrad.adelaide.edu.au>; from Michael Smith on Tue, Jul 22, 1997 at 05:10:00PM %2B0930 References: <199707220708.RAA15780@godzilla.zeta.org.au> <199707220740.RAA28361@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. The solution to this is simple, and can be stolen from the old DOS-extenders. Basically, the first thing you do is make sure you don't clobber the old real-mode interrupt vector table. (actually, saving a copy somewhere would be the best solution) Once you have the interupt vector table, things become a lot easier. All the kernel needs to do is one of two things. (I'm a fan of the second solution, although it may not be advisable early in the boot phase. Don't ask me, I'm not familair with FreeBSD's boot cycle) : 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) 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 The "BIOS" task needs to be run at a fairly high priveledge level, altough I'm not a fan or running it at level 0. Possibly one of the two unused priveledge levels would be aceptable for BIOS calls. 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. -- 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?19970722104258.29583>