Date: Thu, 06 Nov 1997 15:02:55 -0600 From: Tony Overfield <tony@dell.com> To: Terry Lambert <tlambert@primenet.com> Cc: tlambert@primenet.com, jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <3.0.3.32.19971106150255.006d5438@bugs.us.dell.com> In-Reply-To: <199711062006.NAA06945@usr03.primenet.com> References: <3.0.3.32.19971106040103.006ede20@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 08:06 PM 11/6/97 +0000, Terry Lambert wrote: > >> The INT 12h BIOS call will (and must) >> always reflect any "keyhole allocations". >HP Vectra. AT&T 6386 WGS. Etc.. > >I did the original patch to 386BSD 0.1 to emit the warning message >that the RTC check compares to 640. Well, as I pointed out before, the RTC value causes a warning message, but no other action is taken. The BIOS value is always used, no matter what, which is IMO, the correct behavior. The RTC value provides nothing useful in a correctly designed system. >The BIOS calls didn't show >the missing memory on these machines, so the test stayed. 8-). I claim that even MS-DOS cannot work right if this is really true. I *do* believe that the RTC value could *also* show the memory reduction, but I simply don't believe that INT 12h didn't show it. I sure can't find any code in FreeBSD that avoids memory based on the RTC value. >The kernel should not be dependent on data from the boot loader, really. >If it is, it means that the boot loader can't be shared among OS's >without a *lot* of effort. Why not use a common bootinfo structure? >> peaking of vm86(), why not just use real-mode? It's easier and much >> better for compatibility while booting. > >Yes, and no. > >If I have a FreeBSD kernel HAL, then I need to avoid architecture >dependent things before I hit protected mode and can run as the >kernel-before-init-has-been-started. If you have a HAL, then the architecture dependent HAL driver is the code that should worry about the architecture dependent things. >Technically (yes, I know this is not quite sane), with an ELF-based >kernel, I can build a bootable CDROM that will boot on a PowerPC >(which takes the DOS MBR into account as data, and expects a DOS >partition table), an Alpha (which can do the same), and any other >reasonable machine that can identify, uniquely, it's boot code not >living at the front of a CDROM. We have to make an exception for >Intel because BIOS POST routines are brain damaged on Intel machines, >and don't expect non-Intel disks to be shared with them. > >The ELF comes in by using section flagging by architecture type; >this lets me have one binary that will run on multiple architectures. >In other words, one kernel file on the CDROM. > >This is just one example... don't take it reductio ad absurdum. ;-). Ok. This is interesting, but it doesn't argue for using the CMOS RTC memory values. In fact, I'm not sure what it argues for. It's absurd to think you can boot without an architecture specific boot loader, isn't it? >> The APM init code seems to have a good example of >> making real-mode BIOS calls from the kernel during initialization. > >It's not, really. It's far from general, and the memory contortions >are similar to those that the MACH based loader uses to get at INT 13. >8-(. Well, I guess I'm far too familiar with the contortions to be offended by them. :-/ - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971106150255.006d5438>