instead of 0x100000. As a side effect, an amd64 kernel now loads at
physical address 0x200000 instead of 0x100000. This is probably for the
best because it avoids the use of a 2MB page mapping for the first 1MB of
the kernel that also spans the fixed MTRRs. However, getmemsize() still
thinks that the kernel loads at 0x100000, and so the physical memory between
0x100000 and 0x200000 is lost. Fix this problem by replacing the hard-wired
constant in getmemsize() by a symbol "kernphys" that is defined by the
linker script.
In collaboration with: kib
ELF_MAXPAGESIZE for amd64 from 0x00100000 to 0x00200000. This caused
the kernel to be incorrectly linked, using the existing linker script,
resulting in a virtual address of 0xffffffff80000000 for the LOAD
program header.
The boot loader will load such a kernel at a real address of 0x00000000,
which either causes protection faults in btx, crashes the machine, or
(in case of a VMware guest) even makes it power down. :)
Fix this by partially synchronizing the amd64 linker script with
binutils own updated version, in particular replacing a hardcoded
value of 0x00100000 by CONSTANT(MAXPAGESIZE).
bootblocks in order to boot the kernel after this! Also note that this
change breaks BSDI BSD/OS compatibility.
Also increased default NKPT to 17 so that FreeBSD can boot on machines
with >=2GB of RAM. Booting on machines with exactly 4GB requires other
patches, not included.
the in-kernel linker to access the _DYNAMIC data for doing loadable elf
modules. The alpha kernel is already done this way, I've borrowed some of
the hacks from there.
This is primarily aimed at the 3-stage boot process which is intended to
be able to do pre-loading of kernel modules.
Note that the entry point isn't 0xf0100000 any more, it'll be a little
further on - but this value is stored in the headers. I don't think this
will be a problem, but I'm sure somebody will tell me if it is. :-)
I'm not sure if btxboot is going to like this, it doesn't do proper ELF
header checking and assumes that there are exactly two program header
entries and that they are both PT_LOAD entries - a bad assumption.
