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
