Date: Mon, 10 Nov 1997 20:16:59 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tony@dell.com (Tony Overfield) Cc: tlambert@primenet.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <199711102016.NAA13623@usr05.primenet.com> In-Reply-To: <3.0.3.32.19971110035805.006cab94@bugs.us.dell.com> from "Tony Overfield" at Nov 10, 97 03:58:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> No, it's not impossible to do, it's just useless to do, IMHO, for the > job at hand. I don't see any reason to turn the bootloader into a > vm86() program that plays games like this just to copy to memory above > 1 MB, since it's far easier to just switch modes and copy it directly. I think you are missing the point. There's no argument that the boot loader should be a vm86() program. The only argument is that it should do the minimum possible work that can possibly be done before handing the machine over to the kernel. This is because the more the boot loader does, the more you will have to rewrite for each new platform you port to, and the less it does, the less you will have to rewrite. The point of accessing system information from the kernel where possible is to make the boot-loader/kernel interconnect as architecturally abstract as it can possibly be, so that the majority of the startup code can be shared between architectures. The procedural abstraction, if not the functional. Ideally, you will have C versions of as much assembly code as you can possible arrange to have, in order to make a "base level port" as easy as possible. You leave the machine specific assembly code as an exercise in tuning (memcpy/bcopy is one example of something where a C version should be available, but an assembly version, *if* available, should be preferentially used -- clearly the FreeBSD tree is not very porting-friendly from this standpoint). This includes minimal C code to return statically set system specific data that match the machine to which you are porting -- memory size, initial day/date, and so on -- every possible piece of information that you would want to ask a BIOS (or on a PReP box, PPCBug, or on a CHRP box, OpenFirmWare, or on a Mac 6100, the system ROMs). These C versions of the static initialization data and slow support routines constitute a gross simplification on a HAL, and can hopefully evolve into a real HAL over time. But what that *does* mean for the x86 is that the information you obtain from the BIOS is to be obtained by the kernel, not by the boot loader and passed to the kernel. The best you can hope for the boot loader to pass to the kernel is a HAL access function entry point and a (void *) context. You *could* use this to statically gather BIOS data, and then access it via the function entry (which would only pretend to be a HAL), but this is not a terribly portable nor desirable reference implementation to aspire to... besides which, it makes the bootloader large, an offense in itself. > >There are several other you can do using suspend/resume instructions and > >similar tricks > > Suspend instruction? I could have sworn I knew them all by heart. There are "ICEBP" equivalents on non-Intel processors to do register and processor state saves and restores; typically, they are used by laptops for thjings like "suspend to disk" modes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711102016.NAA13623>