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
