gnu/lib/libobjc and sys/boot/i386/boot2, so it also works when using
absolute paths and/or options, as in CC="/absolute/path/clang -foo".
Approved by: rpaulo (mentor)
problems compiling it, but it just gets too big at the moment, even
with -Os. This is not applicable to gptboot, though.
Submitted by: Dimitry Andric <dimitry at andric.com>
out that "on amd64, libstand.a is compiled for i386, but is still installed
under ${WORLDTMP}/usr/lib instead of ${WORLDTMP}/usr/lib32. Even if it
would be installed there, ld on amd64 is set up incorrectly with a
${TOOLS_PREFIX}/usr/lib/i386 default path, so it wouldn't link. The reason
it does link under gcc is that gcc passes -L${WORLDTMP}/usr/lib twice,
even for -m32 builds, which is also incorrect, but accidentally works in
this case."
Submitted by: Dimitry Andric <dimitry at andric.com>
GCC forwards the -N flag directly to ld. This flag is not documented and
not supported by (for example) Clang. Just use -Wl,-N.
Submitted by: Pawel Worach
locate a high memory area for the heap using the SMAP.
- Read the number of hard drive devices from the BIOS instead of hardcoding
a limit of 128. Some BIOSes duplicate disk devices once you get beyond
the maximum drive number.
MFC after: 1 month
gptzfsboot. I got the segment and offset fields reversed in the structure,
but I also succeeded in crossing the assignments so the actual EDD packet
ended up correct.
MFC after: 1 week
safely allocate a heap region above 1MB. This enables {gpt,}zfsboot()
to allocate much larger buffers than before.
- Use a larger buffer (1MB instead of 128K) for temporary ZFS buffers. This
allows more reliable reading of compressed files in a raidz/raidz2 pool.
Submitted by: Matt Reimer mattjreimer of gmail
MFC after: 1 week
heap when using a range above 1MB.
Previously the loader would always use the last 3MB in the first memory
range above 1MB for the heap. However, this memory range is also where the
kernel and any modules are loaded. If this memory range is "small", then
using the high 3MB for the heap may not leave enough room for the kernel
and modules.
Now the loader will use any range below 4GB for the heap, and the logic to
choose the "high" heap region has moved into biosmem.c. It sets two
variables that the loader can use for a high heap if it desires. When a
high heap is enabled (BZIP2, FireWire, GPT, or ZFS), then the following
memory ranges are preferred for the heap in order from best to worst:
- The largest memory region in the SMAP with a start address greater than
1MB. The memory region must be at least 3MB in length. This leaves the
region starting at 1MB purely for use by the kernel and modules.
- The last 3MB of the memory region starting at 1MB if it is at least 3MB
in size. This matches the current behavior except that the current loader
would break horribly if the first region was not at least 3MB in size.
- The memory range from the end of the loader up to the 640k window. This
is the range the loader uses when none of the high-heap-requesting options
are enabled.
Tested by: hrs
MFC after: 1 week
video console which doesn't take any input from keyboard and hides
all output replacing it with ``spinning'' character (useful for
embedded products and custom installations).
Sponsored by: Sippy Software, Inc.
This adds zfsloader which will be called by zfsboot/gptzfsboot code rather
than the tradional loader. This eliminates the need to set the
LOADER_ZFS_SUPPORT variable in order to get a ZFS enabled loader.
Note however, that you must reinstall your bootcode (zfsboot/gptzfsboot)
in order for the boot process to use the new loader.
New installations will no longer be required to build a ZFS enabled
loader for a working ZFS boot system. Installing zfsboot/gptzfsboot is
sufficient for acknowledging the use of CDDL code and therefore the ZFS
enabled loader.
Based on a previous patch from jhb@
Reviewed by: jhb@
MFC after: 2 weeks
fully support booting from large volumes.
Tested by: Emil Smolenski ambsd of raisa.eu.org
Submitted by: Matt Reimer mattjreimer of gmail (most of the C bits)
MFC after: 1 week
- Teach it to read gang blocks. (essentially untested)
If you see "ZFS: gang block detected!", please let
me know, so we can either remove the printf if it
works, or fix it if it doesn't.
- If multiple partitions exist on a disk, probe them all.
We also need to reset dsk->start to 0 to read the right
sector here.
- With GPT, we can have 128 partitions.
- If the bootfs property has ever been set on a pool
it seems that it never goes away. zpool won't allow
you to add to the pool with the bootfs property set.
However, if you clear the property back to default
we end up getting 0 for the object number and read
a bogus block pointer and fail to boot.
- Fix some error printfs. The printf in the loader is
only capable of c,s and u formats.
- Teach printf how to display %llu
Reviewed by: dfr, jhb
MFC after: 2 weeks
short read requests, so the result was that a /boot.config smaller than 512
bytes was ignored. boot2 uses fsread() instead of xfsread() to read
/boot.config already, so this makes zfsboot more like boot2.
Submitted by: Johny Mattsson johny-freebsd of earthmagic org
Reviewed by: dfr
MFC after: 3 days
slicei, Apple EFI hardware), the bootloader will fail to recognize the GPT
if it finds anything else but the EFI partition. Change the check to continue
detecting the GPT by looking at the EFI partition on the MBR but
stopping successfuly after finding it.
PR: kern/134590
Submitted by: Christoph Langguth <christoph at rosenkeller.org>
Reviewed by: jhb
MFC after: 2 weeks
Approved by: re (kib)
- Do not iterate int 15h, function e820h twice. Instead, we use STAILQ to
store each return buffer and copy all at once.
- Export optional extended attributes defined in ACPI 3.0 as separate
metadata. Currently, there are only two bits defined in the specification.
For example, if the descriptor has extended attributes and it is not
enabled, it has to be ignored by OS. We may implement it in the kernel
later if it is necessary and proven correct in reality.
- Check return buffer size strictly as suggested in ACPI 3.0.
Reviewed by: jhb
open partition. This fixes access to partitions whose starting offset
is >= 2 TB.
Submitted by: "James R. Van Artsdalen" james jrv.org
MFC after: 3 days
- First three fields of system UUID may be little-endian as described in
SMBIOS Specification v2.6. For now, we keep the network byte order for
backward compatibility (and consistency with popular dmidecode tool)
if SMBIOS table revision is less than 2.6. However, little-endian format
can be forced by defining BOOT_LITTLE_ENDIAN_UUID from make.conf(5) if it
is necessary.
- Replace overly ambitious optimizations with more readable code.
- Update comments to SMBIOS Specification v2.6 and clean up style(9) bugs.
as 'real memory' instead of Maxmem if the value is available.
Note amd64 displayed physmem as 'usable memory' since machdep.c r1.640
to unconfuse users. Now it is consistent across amd64 and i386 again.
While I am here, clean up smbios.c a bit and update copyright date.
Reviewed by: jhb
booting because the CD driver did not use bounce buffers to ensure
request buffers sent to the BIOS were always in the first 1MB. Copy over
the bounce buffer logic from the BIOS disk driver (minus the 64k boundary
code for floppies) to fix this.
Reported by: kensmith
in make.conf or src.conf.
- When GPT is enabled (which it is by default), use memory above 1 MB and
leave the memory from the end of the bss to the end of the 640k window
purely for the stack. The loader has grown and now it is much more
common for the heap and stack to grow into each other when both are
located in the 640k window.
PR: kern/129526
MFC after: 1 week
the disklabel in the 2nd sector for boot code. Even with both UFS1
and UFS2 supported, there's enough bytes left that we don't have to
nibble from the disklabel.
Thus, the entire 2nd sector is now reserved for the disklabel, which
makes the bootcode compatible again with disklabels that have more
than 8 partitions -- such as those created and supported by gpart.
i386: 135 bytes available
amd64: 151 bytes available
Ok'd by: jhb
The old BTX passed the general purpose registers from the 32-bit client to
the routines called via virtual 86 mode. The new BTX did the same thing.
However, it turns out that some instructions behave differently in virtual 86
mode and real mode (even though this is under-documented). For example, the
LEAVE instruction will cause an exception in real mode if any of the upper
16-bits of %ebp are non-zero after it executes. In virtual 8086 mode the
upper 16-bits are simply ignored. This could cause faults in hardware
interrupt handlers that inherited an %ebp larger than 0xffff from the 32-bit
client (loader, boot2, etc.) while running in real mode.
To fix, when executing hardware interrupt handlers provide an explicit clean
state where all the general purpose and segment registers are zero upon
entry to the interrupt handler. While here, I attempted to simplify the
control flow in the 'intusr' code that sets up the various stack frames
and exits protected mode to invoke the requested routine via real mode.
A huge thanks to Tor Egge (tegge@) for debugging this issue.
Submitted by: tegge
Reviewed by: tegge
Tested by: bz
MFC after: 1 week
and re-enable it as default.
In particular:
+ re-enable the 'update' flag in the Makefile (of course!);
+ commit Warner's patch "orb $NOUPDATE,_FLAGS(%bp)"
to avoid writing to disk in case of a timeout/default choice;
+ fix an off-by-one count in the partition scan code that would
print the wrong name for unknown partitions;
+ unconditionally change the boot prompt to 'Boot:' instead of 'Default:'
to make room for the extra code/checks/messages. Some of the changes
listed below are also made to save space;
+ rearrange and fix comments for known partition types. Right now we
explicitly recognise *BSD, Linux, FAT16 (type 6, used on many USB keys),
NTFS (type 7), FAT32 (type 11).
Depending on other options we also recognise Extended (type 5),
FAT12 (type 1) and FAT16 < 32MB (type 4).
+ Add an entry "F6 PXE" when the code is built with -DPXE (which is
a default now). Technically, F6 boots through INT18, so the prompt 'PXE'
is a bit misleading. Unfortunately the name INT18
is too long and does not fit in - we could use ROM perhaps.
The reason I picked 'PXE' is that on many (I believe) new systems
INT18 calls PXE.
Apart from the choice of the name for PXE/ROM/INT18, this should close
pending issues on the 1-sector boot0 code and we should be able to
move the code to RELENG_7 when it reopens.
No boot0cfg changes are necessary.
MFC after: 3 weeks
boot0.S changes:
+ import a patch from Christoph Mallon to rearrange the various
print functions and save another couple of bytes;
+ implement the suggestion in PR 70531 to enable booting from
any valid partition because even the extended partitions that
were previously in our kill list may contain a valid boot loader.
This simplifies the code and saves some bytes;
+ followwing up PR 127764, implement conditional code to preserve
the 'Volume ID' which might be used by other OS (NT, XP, Vista)
and is located at offset 0x1b8. This requires a relocation of the
parameter block within the boot sector -- there is no other
possible workaround.
To address this, boot0cfg has been updated to handle both
versions of the boot code;
+ slightly rearrange the strings printed in the menus to make
the code buildable with all options. Given the tight memory
budget, this means that with certain options we need to
shrink or remove certain labels.
and especially:
make -DVOLUME_LABEL -DPXE the default options.
This means that the newly built boot0 block will preserve the
Volume ID, and has the (hidden) option F6 to boot from INT18/PXE.
I think the extra functionality is well worth the change.
The most visible difference here is that the 'Default: ' string
now becomes 'Boot: ' (it can be reverted to the old value
but then we need to nuke 1/2 partition name or entries to
make up for the extra room).
boot0cfg changes:
+ modify the code to recognise the new boot0 structure (with the
relocated options block to make room for the Volume id).
+ add two options, '-i xxxx-xxxx' to set the volume ID, -e c
to modify the character printed in case of bad input
PR: 127764 70531
Submitted by: Christoph Mallon (portions)
MFC after: 4 weeks
of the boot0.S code, with a number of compile-time selectable options,
the most interesting one being the ability to select PXE booting.
The code is completely compatible with the previous one, and with
the boot0cfg program. Even the actual code is largely unmodified,
with only minor rearrangements or fixes to make room for the new
features.
The behaviour of the standard build differs from the previous
version in the following, minor things:
+ 'noupdate' is the default, which means the code does not
write back the selection to disk. You can enable the feature
at runtime with boot0cfg, or changing the flags in the Makefile.
+ a drive number of 0x00 (floppy, or USB in floppy emulation) is
now accepted as valid. Previously, it was overridden with 0x80,
meaning that the partition table coming from the media was
used to access sectors on a possibly different media.
You can revert to the previous mode building with -DCHECK_DRIVE,
and you can always use the 'setdrv' option in boot0cfg
+ certain FAT or NTFS partitions are listed as WIN instead of DOS.
+ the 'bel' character on a bad selection is replaced by a '#' to
make it clear that the system is not hang even if the machine
does not have a speaker. This can be reverted back at compile
time, or at runtime with an upcoming boot0cfg option.
Additional features are available as compile time options,
and may be become the default if deemed useful. In particular:
+ INT18/PXE boot (make -DPXE)
This option enables booting through INT 18h (which on certain
BIOSes can be hooked to PXE) by pressing F6. There is unfortunately
no room to print the additional menu option.
Also, to make room for the code, the 'Default: ' string is
changed to 'Boot: '
+ print current drive number (make -DTEST)
Prints a line indicating the current drive number.
This is useful to figure out what is going on for machines/bioses
which remap drives in sometimes surprising ways.
+ disable numeric keys in console mode (make -DONLY_F_KEYS)
Not really a significant option, but it is needed to make
room for the -DTEST mode.
+ disable floppy support (make -DCHECK_DRIVE)
Revert to the old behaviour of only accepting 0x80 and above
as valid drive numbers.
MFC after: 6 weeks
instead of "puts" which prints whatever is at %si, followed by a CRLF.
It was not noticed during tests because at that point %si points
to a partition entry whose first byte is 0x80, which is both a
terminator for the string and a non printable character.
Submitted by: Christoph Mallon
boot code. The bug was introduced in rev.1.13, and went unnoticed
because FreeBSD's boot1 does not use it, but other systems might.
(I have been struggling for almost a full day trying to figure out
why a syslinux'ed partition would not boot when started with the
FreeBSD /boot/boot0, only to realize that the bug was ours!)
The space for the two extra bytes (push %si and pop %si) is reclaimed
by removing an extra CRLF that is printed before booting.
The bug is not a major one but if there is time it might be a good
thing to merge it into the upcoming releases.
to gptboot, i.e. installed in a freebsd-boot partition using /sbin/gpart or
/sbin/gpt.
Tweak the /boot/loader ZFS support so that it can find ZFS pools that are
contained in GPT partitions.
This bring huge amount of changes, I'll enumerate only user-visible changes:
- Delegated Administration
Allows regular users to perform ZFS operations, like file system
creation, snapshot creation, etc.
- L2ARC
Level 2 cache for ZFS - allows to use additional disks for cache.
Huge performance improvements mostly for random read of mostly
static content.
- slog
Allow to use additional disks for ZFS Intent Log to speed up
operations like fsync(2).
- vfs.zfs.super_owner
Allows regular users to perform privileged operations on files stored
on ZFS file systems owned by him. Very careful with this one.
- chflags(2)
Not all the flags are supported. This still needs work.
- ZFSBoot
Support to boot off of ZFS pool. Not finished, AFAIK.
Submitted by: dfr
- Snapshot properties
- New failure modes
Before if write requested failed, system paniced. Now one
can select from one of three failure modes:
- panic - panic on write error
- wait - wait for disk to reappear
- continue - serve read requests if possible, block write requests
- Refquota, refreservation properties
Just quota and reservation properties, but don't count space consumed
by children file systems, clones and snapshots.
- Sparse volumes
ZVOLs that don't reserve space in the pool.
- External attributes
Compatible with extattr(2).
- NFSv4-ACLs
Not sure about the status, might not be complete yet.
Submitted by: trasz
- Creation-time properties
- Regression tests for zpool(8) command.
Obtained from: OpenSolaris
boot an amd64 kernel. If not, then fail the boot request with an error
message. Otherwise, the boot attempt will fail with a BTX fault when
trying to read the EFER MSR.
MFC after: 3 days
set the %eflags used during a BIOS call via BTX to 0x202. Previously
the flags field was uninitialized garbage, and thus it was "random" if
interrupts were enabled or not during BIOS calls.
- Use constants from <machine/psl.h> for fields in %eflags.
MFC after: 3 days
- I had errantly assumed that all user requests should run with interrupts
enabled. User requests for software interrupts, however, need to disable
interrupts (and tracing) just like hardware interrupts.
- Disable alignment checking when emulating a hardware interrupt as well
(based on the description of the real mode operation of the 'INT'
instruction in the IA-32 manuals).
- Use constants for fields in %eflags.
Tested by: bz
MFC after: 3 days
commit, calling i386_parsedev(..., X, ...) where X is "ad", "bge", or
any other disk or network device name without a unit number, would
result in dereferencing whatever happened to be on the stack where the
variable "cp" is stored.
Found by: LLVM/Clang Static Checker
- It is opt-out for now so as to give it maximum testing, but it may be
turned opt-in for stable branches depending on the consensus. You
can turn it off with WITHOUT_SSP.
- WITHOUT_SSP was previously used to disable the build of GNU libssp.
It is harmless to steal the knob as SSP symbols have been provided
by libc for a long time, GNU libssp should not have been much used.
- SSP is disabled in a few corners such as system bootstrap programs
(sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves.
- It should be safe to use -fstack-protector-all to build world, however
libc will be automatically downgraded to -fstack-protector because it
breaks rtld otherwise.
- This option is unavailable on ia64.
Enable GCC stack protection (aka Propolice) for kernel:
- It is opt-out for now so as to give it maximum testing.
- Do not compile your kernel with -fstack-protector-all, it won't work.
Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
libi386's time(), caused by a qemu bug. The bug might
be present in other BIOSes, too.
qemu either does not simulate the AT RTC correctly or
has a broken BIOS 1A/02 implementation, and will return
an incorrect value if the RTC is read while it is being
updated.
The effect is worsened by the fact that qemu's INT 15/86
function ("wait" a.k.a. usleep) is non-implmeneted or
broken and returns immediately, causing beastie.4th to
spin in a tight loop calling the "read RTC" function
millions of times, triggering the problem quickly.
Therefore, we keep reading the BIOS value until we get
the same result twice. This change fixes beastie.4th's
countdown under qemu.
Approved by: des (mentor)
entry in the SMAP is a 20 byte structure and they are queried from the
BIOS via sucessive BIOS calls. Due to an apparent bug in the R900's
BIOS, for some SMAP requests the BIOS overflows the 20 byte buffer
trashing a few bytes of memory immediately after the SMAP structure. As
a workaround, add 8 bytes of padding after the SMAP structure used in
the loader for SMAP queries.
PR: i386/122668
Submitted by: Mike Hibler mike flux.utah.edu, silby
MFC after: 3 days
routines (V86 requests from the client and hardware interrupt handlers):
- Install trampoline real mode interrupt handlers at IDT vectors 0x20-0x2f
to handle hardware interrupts by invoking the appropriate vector (0x8-0xf
or 0x70-0x78). This allows the 8259As to use vectors 0x20-0x2f in real
mode as well as protected mode will ensuring that the master 8259A
doesn't share IDT space with CPU exceptions in protected mode.
- Since we don't need to reserve space for page tables and a page directory
anymore since dropping paging support, move the TSS and protected mode
IDT up by 16k. Grow the ring 1 link stack by 16k as a result.
- Repurpose the ring 1 link stack to be used as a real mode stack when
invoking real mode routines either via a V86 request or a hardware
interrupts. This simplifies a few things as we avoid disturbing the
original user stack.
- Add some more block comments to explain how the code interacts with the
V86 structure as this wasn't immediately obvious from the prior comments
(e.g. that we explicitly copy the seg regs for real mode out of the V86
struct onto the stack to be popped off when going into real mode, etc.).
Also, document some of the stack frames we create going to real mode and
back.
- Remove all of the virtual 86 related code including having to simulate
various instructions and BIOS calls on a trap from virtual 86 mode.
- Explicitly panic if a user client attempts to perform a V86 CALL
request that isn't a far call.
- Bump version to 1.2.
Assuming this works ok this should fix some of the long standing issues
with USB booting as well as etherboot.
MFC after: 2 weeks
Submitted by: kib (some parts from his original real mode patch)
- Consolidate the code to humanize the size of a disk partition into a
single function based on the code for GPT partitions and use it for
GPT partitions, BSD slices, and BSD partitions.
- Teach the humanize code to use KB for small partitions (e.g. GPT boot
partitions now show up as 64KB rather than 0MB).
- Pad a few partition type names out so that things line up in the
common case.
MFC after: 1 week
weren't displayed on the new console. However, the config string has been
altered as part of being parsed so we only display the first option. Fix
this by saving a copy of /boot.config before parsing it and displaying the
saved copy after parsing.
MFC after: 1 week
PR: i386/103972
Submitted by: Alexandre Belloni alexandre.belloni of netasq.com
Enhanced Disk Drive Specification Ver 3.0 defines that the version
of extension in AH would be 30h.
Correct the check for that to be >=30h instead of >3h.
MFC after: 2 months
defined. This lets each boot program choose which version of cgbase() it
wants to use rather than forcing ufsread.c to have that knowledge.
MFC after: 1 week
Discussed with: imp
on i386 and amd64 machines. The overall process is that /boot/pmbr lives
in the PMBR (similar to /boot/mbr for MBR disks) and is responsible for
locating and loading /boot/gptboot. /boot/gptboot is similar to /boot/boot
except that it groks GPT rather than MBR + bsdlabel. Unlike /boot/boot,
/boot/gptboot lives in its own dedicated GPT partition with a new
"FreeBSD boot" type. This partition does not have a fixed size in that
/boot/pmbr will load the entire partition into the lower 640k. However,
it is limited in that it can only be 545k. That's still a lot better than
the current 7.5k limit for boot2 on MBR. gptboot mostly acts just like
boot2 in that it reads /boot.config and loads up /boot/loader. Some more
details:
- Include uuid_equal() and uuid_is_nil() in libstand.
- Add a new 'boot' command to gpt(8) which makes a GPT disk bootable using
/boot/pmbr and /boot/gptboot. Note that the disk must have some free
space for the boot partition.
- This required exposing the backend of the 'add' function as a
gpt_add_part() function to the rest of gpt(8). 'boot' uses this to
create a boot partition if needed.
- Don't cripple cgbase() in the UFS boot code for /boot/gptboot so that
it can handle a filesystem > 1.5 TB.
- /boot/gptboot has a simple loader (gptldr) that doesn't do any I/O
unlike boot1 since /boot/pmbr loads all of gptboot up front. The
C portion of gptboot (gptboot.c) has been repocopied from boot2.c.
The primary changes are to parse the GPT to find a root filesystem
and to use 64-bit disk addresses. Currently gptboot assumes that the
first UFS partition on the disk is the / filesystem, but this algorithm
will likely be improved in the future.
- Teach the biosdisk driver in /boot/loader to understand GPT tables.
GPT partitions are identified as 'disk0pX:' (e.g. disk0p2:) which is
similar to the /dev names the kernel uses (e.g. /dev/ad0p2).
- Add a new "freebsd-boot" alias to g_part() for the new boot UUID.
MFC after: 1 month
Discussed with: marcel (some things might still change, but am committing
what I have so far)
on duplicated code and support 64-bit LBAs for GPT.
- The code to manage an EDD or C/H/S I/O request are now in their own
routines. The EDD routine now handles a full 64-bit LBA instead of
truncating LBAs to the lower 32-bits. (MBRs and BSD labels only
have 32-bit LBAs anyway, so the only LBAs ever passed down were 32-bit).
- All of the bounce buffer and retry logic duplicated in bd_read() and
bd_write() are merged into a single bd_io() routine that takes an
extra direction argument. bd_read() and bd_write() are now simple
wrappers around bd_io().
- If a disk supports EDD then always use it rather than only using it if
the cylinder is > 1023. Other parts of the boot code already do
something similar to this. Also, GPT just uses LBAs, so for a GPT disk
it's probably best to ignore C/H/S completely. Always using EDD when
it is supported by a disk is an easy way to accomplish this.
MFC after: 1 week
macros to treat the 'slice' field as a real part of the bootdev instead
of as hack that spans two other fields (adaptor (sic) and controller)
that are not used in any modern FreeBSD boot code.
MFC after: 1 week
It is disabled by default. You need to put
LOADER_FIREWIRE_SUPPORT=yes in /etc/make.conf
and rebuild loader to enable it.
(cd /sys/boot/i386 && make clean && make && make install)
You can find a short introduction of dcons at
http://wiki.freebsd.org/DebugWithDcons
bioscom is called to set up serial port parameters because COMSPEED
was treated as an address instead of an immediate value, causing
serial port parameters to never be set.
PR: i386/110828
Reviewed by: jhb
MFC after: 2 weeks
I created and tested this with a custom FreeSBIE cd-image.
PR: i386/96452
Submitted by: Yuichiro Goto <y7goto at gmail dot com>
MFC after: 3 days
Approved by: imp (mentor)
rather than treating them as a fatal exception and halting. At least one
storage BIOS (some newer mpt(4) parts) have a breakpoint instruction in
their disk read routine.
MFC after: 3 days
to get the physical address doesn't work for all values of KVA_PAGES,
while masking 8 MSBs works for all values of KVA_PAGES that are
multiple of 4 for non-PAE and 8 for PAE. (This leaves us limited
with 12MB for non-PAE kernels and 14MB for PAE kernels.)
To get things right, we'd need to subtract the KERNBASE from the
virtual address (but KERNBASE is not easy to figure out from here),
or have physical addresses set properly in the ELF headers.
Discussed with: jhb
device (kind) specific unit field to the common field. This change
allows a future version of libefi to work without requiring anything
more than what is defined in struct devdesc and as such makes it
possible to compile said version of libefi for different platforms
without requiring that those platforms have identical derivatives
of struct devdesc.
are no longer limited to a virtual address space of 16 megabytes,
only mask high two bits of a virtual address. This allows to load
larger kernels (up to 1 gigabyte). Not masking addresses at all
was a bad idea on machines with less than >3G of memory -- kernels
are linked at 0xc0xxxxxx, and that would attempt to load a kernel
at above 3G. By masking only two highest bits we stay within the
safe limits while still allowing to boot larger kernels.
(This is a safer reimplmentation of sys/boot/i386/boot2/boot.2.c
rev. 1.71.)
Prodded by: jhb
Tested by: nyan (pc98)
commits. For some reason I thought the scale factor was a shift count
rather than the multiplicand (that is, I thought leal (%eax,%edx,4) was
going to generate %eax + %edx << 4 rather than %eax + %edx * 4). What
I need is to multiply by 16 to convert a real-mode (seg, offset) tuple
into a flat address. However, the max multiplicand for scaled/index
addressing on i386 is 8, so go back to using a shl and an add.
- Convert two more inter-register mov instructions where we don't need to
preserve the source register to xchg instructions to keep our space
savings.
Tested by: Ian FREISLICH if at hetzner.co.za
MFC after: 1 week
another 16 bytes off of BTX (and thus boot2):
- Compare against the value of %eax that is saved on the stack instead of
loading it into %eax (which requires saving the current %eax on the
stack).
- Use %ch to examine the keyboard flag state in the BIOS to see if
Ctrl-Alt-Del is pressed instead of %al so we don't have to save %eax on
the stack anymore.
MFC after: 1 week
BTX (and thus boot2):
- Don't bother saving %eax, %ebx, or %ecx as it is not necessary.
- Use a more compact sequence to load the base value out of a GDT entry
by loading the contiguous low 24 bits into the upper 24 bits of %eax,
loading the high 8 bits into %al, and using a ror to rotate the bits
(2 mov's and a ror) rather than loading the pieces in smaller chunks
(3 mov's and a shl).
- Use movzwl + leal instead of movl + movw + shll + addl.
- Use 'xchgl %eax,%foo' rather than 'movl %eax,%foo' for cases where
it's ok to trash %eax. xchgl %eax, foo is a 1-byte opcode whereas the
mov is a 2-byte opcode.
- Use movzwl rather than xorl + movw.
MFC after: 1 week
rather than just emulating mov cr0, eax. This fixes some Compaq/HP BIOS
with DMA (as the BIOS tried to read cr3 so it could translate addresses
if paging was enabled).
MFC after: 1 week
- Make the PROBE_KEYBOARD option better resemble the -P option in
boot2, i.e., if keyboard isn't present then boot with both
RB_SERIAL and RB_MULTIPLE set.
Reviewed by: jhb
fixes filesystem corruption when nextboot.conf is located after
cylinder 1023. The bug appears to have been introduced at the time
bd_read was copied to create bd_write.
PR: bin/98005
Reported by: yar
MFC after: 1 week
selection and not always beeping on startup. The two bytes for the extra
'jmp' instruction were obtained by removing recognition of BSD/OS
partitions.
Requested by: many
Tested by: subset of many
Head nod: imp, keramida
MFC after: 2 weeks
Otherwise, we could match on a filename that had the wrong last character
(such as /boot/loaded instead of /boot/loader).
PR: kern/95625
Submitted by: Oliver Fromme <olli@secnetix.de>
MFC after: 1 month
controller to get ready (65K x ISA access time, visually around 1 second).
If we have wait more than that amount it's likely that the hardware is a
legacy-free one and simply doesn't have keyboard controller and doesn't
require enabling A20 at all.
This makes cdboot working for MacBook Pro with Boot Camp.
MFC after: 1 day
Use 'BOOT_SENSITIVE_INFO=YES' variable to turn them on.
- Use 'uint*_t' instead of 'u_int*_t', correct compilation warnings, and
update copyright while I am here.
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.
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.
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)
- Teach the i386 and pc98 loaders to honor multiple console requests from
their respective boot2 binaries so that the same console(s) are used in
both boot2 and the loader.
- Since the kernel doesn't support multiple consoles, whichever console is
listed first is treated as the "primary" console and is passed to the
kernel in the boot_howto flags.
PR: kern/66425
Submitted by: Gavin Atkinson gavin at ury dot york dot ac dot uk
MFC after: 1 week
