Date: Thu, 6 Nov 1997 20:06:00 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tony@dell.com (Tony Overfield) Cc: tlambert@primenet.com, jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <199711062006.NAA06945@usr03.primenet.com> In-Reply-To: <3.0.3.32.19971106040103.006ede20@bugs.us.dell.com> from "Tony Overfield" at Nov 6, 97 04:01:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >At least the "base memory" in the CMOS must be examined to determine > >memory which can not be given over to the kernel for it to scribble on. > > Well, I was obviously talking about extended memory, not base memory, > but I'll bite on this sucker bait anyway... ;-) > > I claim your argument is wrong. The INT 12h BIOS call will (and must) > always reflect any "keyhole allocations". The RTC value will *not* > reflect them. The BIOS call provides precisely the correct value, > unless you happen to think the kernel should steal the memory back > from the BIOS, which is, of course, extremely risky. 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. The BIOS calls didn't show the missing memory on these machines, so the test stayed. 8-). > Yes, but the bootloader already knows how much memory is there. It > knows this before the kernel is loaded. It can make sure there is > enough memory before the kernel is loaded. It can and does pass > that value to the kernel after it is loaded. The kernel then throws > it away and gets the wrong information from the CMOS. 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. > Speaking 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. 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. ;-). > I do remember your dreams > of running SCSI option ROM code in multi-use mode, but that's surely > a long way off. Actually, I just wanted to run EISA config and MCA config utilities. The SCSI link was I wanted to be able to modularly replace the free Adaptec driver with a binary-only HIM-based driver. That's even *more* interesting to me now that that's the only way to currently get RAID support on some Adaptec controllers. > 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-(. 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?199711062006.NAA06945>