3MB of physical memory for heap instead of range between 1MB and 4MB.
This makes this feature working with PAE and amd64 kernels, which are
loaded at 2MB. Teach i386_copyin() to avoid using range allocated by
heap in such case, so that it won't trash heap in the low memory
conditions.
This should make loading bzip2-compressed kernels/modules/mfs images
generally useable, so that re@ team is welcome to evaluate merits
of using this feature in the installation CDs.
Valuable suggestions by: jhb
provide enough room for decompression (up to 2.5MB is necessary). This
should be safe to do since we load i386 kernels after 8MB mark now, so
that 16MB is the minimum amount of RAM necessary to even boot FreeBSD.
This makes bzip2-support practically useable.
memory directly available to loader(8) and friends was limited to 640K on i386.
Those times have passed long time ago and now loader(8) can directly access
up to 4GB of RAM at least theoretically. At the same time, there are several
places where it's assumed that malloc() will only allocate memory within
first megabyte.
Remove that assumption by allocating appropriate bounce buffers for BIOS
calls on stack where necessary.
This allows using memory above first megabyte for heap if necessary.
means:
o Remove Elf64_Quarter,
o Redefine Elf64_Half to be 16-bit,
o Redefine Elf64_Word to be 32-bit,
o Add Elf64_Xword and Elf64_Sxword for 64-bit entities,
o Use Elf_Size in MI code to abstract the difference between
Elf32_Word and Elf64_Word.
o Add Elf_Ssize as the signed counterpart of Elf_Size.
MFC after: 2 weeks
devices can be opened multiple times simultaneously but we're
expected to be able to do so by the rest of the loader.
This fixes booting from disks attached to the on-board SCSI
controller of Sun Ultra 1 (previously this triggered a trap)
and probably also of AX1115 boards.
- While here, remove unused variables and add empty lines where
style(9) requires such.
Tested on: powerpc (grehan), sparc64
MFC after: 1 month
> Cause all flags passed by boot2 to set the respective loader(8)
> boot_* variable. The end effect is that all flags from boot2
> are now passed to the kernel.
the serial console speed (i386 and amd64 only). If the previous
stage boot loader requested a serial console (RB_SERIAL or RB_MULTIPLE)
then the default speed is determined from the current serial port
speed. Otherwise it is set to 9600 or the value of BOOT_COMCONSOLE_SPEED
at compile time.
This makes it possible to set the serial port speed once in
/boot.config and the setting will propagate to boot2, loader and
the kernel serial console.
/boot.config or on the "boot:" prompt line via a "-S<speed>" flag,
e.g. "-h -S19200". This adds about 50 bytes to the size of boot2
and required a few other small changes to limit the size impact.
This changes only affects boot2; there are further loader changes
to follow.
which serial device to use in that case respectively to not rely on
the OFW names of the input/output and stdin/stdout devices. Instead
check whether input and output refers to the same device and is of
type serial (uart(4) was already doing this) and for the fallback
to a serial console in case a keyboard is the selected input device
but unplugged do the same for stdin and stdout in case the input
device is nonexistent (PS/2 and USB keyboards) or has a 'keyboard'
property (RS232 keyboards). Additionally also check whether the OFW
did a fallback to a serial console in the same way in case the
output device is nonexistent. While at it save on some variables
and for sys/boot/sparc64/loader/metadata.c move the code in question
to a new function md_bootserial() so it can be kept in sync with
uart_cpu_getdev_console() more easily.
This fixes selecting a serial console and the appropriate device
when using a device path for the 'input-device' and 'output-device'
OFW environment variables instead of an alias for the serial device
to use or when using a screen alias that additionally denotes a
video mode (like e.g. 'screen:r1024x768x60') but no keyboard is
plugged in (amongst others). It also makes the code select a serial
console in case the OFW did the same due to a misconfiguration like
both 'input-device' and 'output-device' set to 'keyboard' or to a
nonexisting device (whether the OFW does a fallback to a serial
console in case of a misconfiguration or one ends up with just no
console at all highly depends on the OBP version however).
- Reduce the size of buffers that only ever need to hold the string
'serial' accordingly. Double the size of buffers that may need to
hold a device path as e.g. '/pci@8,700000/ebus@5/serial@1,400000:a'
exceeds 32 chars.
- Remove the package handle of the '/options' node from the argument
list of uart_cpu_getdev_dbgport() as it's unused there and future
use is also unlikely.
MFC after: 1 week
from OpenFirmware be 16 pages to avoid fragmentation in the list
of mappings returned when the kernel requests it in pmap_bootstrap.
This allows a static buffer to be used when obtaining the existing
mappings - very useful on the G5 when random physical pages can't
be grabbed because they can't be BAT-mapped.
MFC after: 3 days
variables to loader:
hint.smbios.0.enabled "YES" when SMBIOS is detected
hint.smbios.0.bios.vendor BIOS vendor
hint.smbios.0.bios.version BIOS version
hint.smbios.0.bios.reldate BIOS release date
hint.smbios.0.system.maker System manufacturer
hint.smbios.0.system.product System product name
hint.smbios.0.system.version System version number
hint.smbios.0.planar.maker Base board manufacturer
hint.smbios.0.planar.product Base board product name
hint.smbios.0.planar.version Base board version number
hint.smbios.0.chassis.maker Enclosure manufacturer
hint.smbios.0.chassis.version Enclosure version
These strings can be used to detect hardware quirks and to set appropriate
flags. For example, Compaq R3000 series and some HP laptops require
hint.atkbd.0.flags="0x9"
to boot. See amd64/67745 for more detail.
Note: Please do not abuse this feature to resolve general problem when it
can be fixed programmatically. This must be used as a last resort.
PR: kern/81449
Approved by: anholt (mentor)
and visible effect of the bug what that autoboot would boot a kernel
after only a couple of seconds had passed instead of waiting the
full 10 seconds it's supposed to wait by default.
Add my copyright notice, since one was missing and I reimplemented
the one and only function in this file.
MFC after: 1 week
