Currently, our overlay blob will grow to include the size of the complete
overlay blob we're applying. This doesn't scale very well with a lot of
overlays- they tend to include a lot of overhead, and they will generally
only add a fraction of their total size to the blob they're being applied
to.
To combat this, pack the blob as we apply new overlays and keep track of how
many overlays we've applied. Only ubldr has any fixups to be applied after
overlays, so we only need to re-pad the blob in ubldr. Presumably the
allocation won't fail since we just did a lot worse in trying to apply
overlays and succeeded.
I have no intention of removing the padding in make_dtb.sh. There might be
an argument to be had over whether it should be configurable, since ubldr
*is* the only loader that actually has fixups to be applied and we can do
this at runtime, but I'm not too concerned about this.
This diff has been sitting in Phabricator for a year and a half, but I've
decided to flush it as it does make sure that we're scaling the blob
appropriately and leave room at the end for fixups in case of some freak
circumstance where applying overlays leaves us with a blob of insufficient
size.
Reviewed by: gonzo (a long time ago)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14133
Since rS330365, there has been no particular reason for libofw to be in a
subdirectory of ofw. Move libofw up a level to make it fit in better with
the other top level libraries.
Also add a LIBOFWSRC to stand/defs.mk to match what all the other
libraries are doing.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23000
Summary:
This patch is to support ongoing work for replacing "GCC/BFD" by "CLANG/LLD" on
target PowerPC64 [1], by proposing a way to specify and/or locate a secondary
ld.bfd linker.
This is necessary as LLD currently doesn't support PowerPC 32 bits, so we keep
using BFD for the 32 bit stuff on PowePC64(LIB32 compatibility and
STAND/slof/loader.)
- creates LD_BFD variable pointing to ld.bfd
- use LD_BFD as linker for LIB32/compat
- Default behavior for other platforms aren't changed.
[1] https://wiki.freebsd.org/powerpc/llvm-elfv2
Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D20261
partitions can have 128 partitions, so parse contiguous digits and then
validate that the number is between 1-128 inclusive.
I'm not sure 128 is a hard limit in the GPT standard, but it's the common
number in use, and it's a better upper limit than 9.
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
From UEFI specification 2.8, page 434:
"It should also be noted that certain input devices may not be able to produce
shift or toggle state information, and in those cases the high order bit in
the respective Toggle and Shift state fields should not be active."
But we still need to check for ScanCode and UnicodeChar.
PR: 242660
Reported by: Trond Endrestol
MFC after: 1 week
For all the INT13 calls, use symbolic names instead of magic numbers. This makes
it easier to understand what the code is doing w/o a trip to google to find what
these numbers mean.
In some cases the pool discovery will get stuck in infinite loop while setting
up the vdev children.
To fix, we split the vdev setup into two parts, first we create vdevs based on
configuration we do get from pool label, then, we process pool config from MOS
and update the pool config if needed.
Testing done: confirm previously hung loader is not hung any more.
MFC after: 1 week
Instead of passing NULL to fzap_name_equal and crashing, just return
ENOENT. This happened when higher bits of a hash of the searched key
(its hash prefix) matched a hash prefix of some key in the ZAP, but the
full hash value of the searched key did not match any key in the ZAP.
I observerved this problem when loader tried to look up
"features_for_read" in a particular old pool that predates pool
features.
MFC after: 2 weeks
Sponsored by: Panzura
We do allocate amount of memory (void * or char *), and then assign this
buffer to struct iso_primary_descriptor *vd. Make sure we do
allocate enough bytes.
In fact we do allocate enough, but it is good idea to make sure this really
is so.
MFC after: 1 week
Lua allocates LUAL_BUFFERSIZE buffers on the stack for various string
functions (string.format, string.gsub) -- this works out to be somewhat
significant and not necessary, based on how we use string operations.
Dropping it risks having to allocate per call to format/gsub, but this is
not the case for our usage. This simply stops allocating 8K buffers on the
stack when luaL_Buffer is used.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22500
Update a bunch of Makefile.depend files as
a result of adding Makefile.depend.options files
Reviewed by: bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22494
Summary:
There's no need to use the fallback fls() and flsl() libkern functions
when the PowerISA includes instructions that already do the bulk of the
work. Take advantage of this through the GCC builtins __builtin_clz()
and __builtin_clzl().
Reviewed by: luporl
Differential Revision: https://reviews.freebsd.org/D22340
o Remove All Rights Reserved from my notices
o imp@FreeBSD.org everywhere
o regularize punctiation, eliminate date ranges
o Make sure that it's clear that I don't claim All Rights reserved by listing
All Rights Reserved on same line as other copyright holders (but not
me). Other such holders are also listed last where it's clear.
r354247 converted try_include to lfs + dofile with the loader.lua_path added
just before. Fortunately, there was a hardcoded /boot/lua fallback in case
loader.lua_path wasn't being set yet- I typo'd it as loader.lua_paths.
Fix the typo.
X-MFC-With: r354247
MFC after: 3 days
Just as disks can have nested partitions, the same happens with cd devices,
so we need to detect device paths and make sure we will not mix the handles.
To address this:
we fetch handle array and create linked list of block devices.
we walk the list and detect parent devices and set children pd_parent.
for {fd, cd, hd}, we walk device list and pick up our devices and store to
corresponding list. We make sure we store parent device first.
For sorting we use 3 steps: We check for floppy, we check for cd and then
everything else must be hd.
In general, it seems the floppy devices have no parent.
CD can have both parents and children (multiple boot entries, partitions
from the hybrid disk image).
Tested by: cross+freebsd@distal.com on Cisco UCS systems, C200 series (C220M5, C240M4).
Also on MBP with UEFI 1.10
Reported by: Chriss Ross
MFC after: 1w
Differential Revision: https://reviews.freebsd.org/D22553
RB_MULTIPLE without RB_SERIAL set is valid, and means 'Video first, then serial'
to the kernel (so kernel messages go to both, but /etc/rc uses video console
(this should be fixed, btw, but another day)). Check for RB_MULTIPLE as well as
RB_SERIAL where we want to to serial things. This means we'll use the old code
for emulation in these situations, which is likely best since we're outputing to
both and the old code is ligher weight allowing both to keep up w/o weird
scrolling things.
With a very large kernel or module the staging area may be too small to
hold it. When this is the case try to allocate more space before failing
in the efi copyin/copyout/readin functions.
Reviewed by: imp, tsoome
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22569
illumos/illumos-gate@663207adb1663207adb1
10601 Pool allocation classes
https://www.illumos.org/issues/10601
illumos port of ZoL Pool allocation classes. Includes at least these two
commits:
441709695 Pool allocation classes misplacing small file blocks
cc99f275a Pool allocation classes
10757 Add -gLp to zpool subcommands for alt vdev names
https://www.illumos.org/issues/10757
Port from ZoL of
d2f3e292d Add -gLp to zpool subcommands for alt vdev names
Note that a subsequent ZoL commit changed -p to -P
a77f29f93 Change full path subcommand flag from -p to -P
Portions contributed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Portions contributed by: Håkan Johansson <f96hajo@chalmers.se>
Portions contributed by: Richard Yao <ryao@gentoo.org>
Portions contributed by: Chunwei Chen <david.chen@nutanix.com>
Portions contributed by: loli10K <ezomori.nozomu@gmail.com>
Author: Don Brady <don.brady@delphix.com>
11541 allocation_classes feature must be enabled to add log device
illumos/illumos-gate@c1064fd7cec1064fd7cehttps://www.illumos.org/issues/11541
After the allocation_classes feature was integrated, one can no longer add a
log device to a pool unless that feature is enabled. There is an explicit check
for this, but it is unnecessary in the case of log devices, so we should handle
this better instead of forcing the feature to be enabled.
Author: Jerry Jelinek <jerry.jelinek@joyent.com>
FreeBSD notes.
I faithfully added the new -g, -L, -P flags, but only -g does something:
vdev GUIDs are displayed instead of device names. -L, resolve symlinks,
and -P, display full disk paths, do nothing at the moment.
The use of special vdevs is backward compatible for read-only access, so
root pools should be bootable, but exercise caution.
MFC after: 4 weeks
FreeBSDlua ("flua") is a FreeBSD-private lua, flavored with whatever
extensions we need for base system operations. We currently support a subset
of lfs and lposix that are used in the rewrite of makesyscall.sh into lua,
added in r354786.
flua is intentionally written such that one can install standard lua and
some set of lua modules from ports and achieve the same effect.
linit_flua is a copy of linit.c from contrib/lua with lfs and lposix added
in. This is similar to what we do in stand/. linit.c has been renamed to
make it clear that this has flua-specific bits.
luaconf has been slightly obfuscated to make extensions more difficult. Part
of the problem is that flua is already hard enough to use as a bootstrap
tool because it's not in PATH- attempting to do extension loading would
require a special bootstrap version of flua with paths changed to protect
the innocent.
src.lua.mk has been added to make it easy for in-tree stuff to find flua,
whether it's bootstrap-flua or relying on PATH frobbing by Makefile.inc1.
Reviewed by: brooks, emaste (both earlier version), imp
Differential Revision: https://reviews.freebsd.org/D21893
Include the server IP address when logging nfs_open(), add a few missing
"\n"s, and correct a typo.
Reviewed by: kevans
MFC after: 2 weeks
Sponsored by: Panasas
Differential Revision: https://reviews.freebsd.org/D22346
In our case the structure is more complex and simple static initializer
will upset compiler diagnostics - using memset is still better than building
more complext initializer.
In the EFI implementation in U-Boot no ConOut efi variable is created,
this cause loader to fallback to TERM_EMU implementation which is very
very very slow (and uses the ConOut device in the system table anyway).
The UEFI spec aren't clear as if this variable needs to exists or not.
Reviewed by: imp, kevans
UEFI 1.10 on macs does not seem to provide devpath to name translation,
provide our own (limited) version, so we can get information about commmon
devices.
MFC after: 1 week
The macos does create Vendor Media devices on top of APFS container
(like partition table inside the partition), so we need to collect such
devices into respective device tree.
MFC after: 1 week
Since physical device asize is calculated from psize and the asize is stored
in pool label, we can use asize to set the value of psize, which is used to
calculate the location of the pool labels.
MFC after: 1 week
Port illumos change: https://www.illumos.org/issues/11667
Move lz4.c out of zfs tree to opensolaris/common/lz4, adjust it to be
usable from kernel/stand/userland builds, so we can use just one single
source. Add lz4.h to declare lz4_compress() and lz4_decompress().
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D22037
In case of efi console having serial backend (video + serial or only serial),
we need to stick with old emulator till we can draw console.
Eventually we would need to get console terminal emulator to be removed
from serial console because the serial link already has the terminal.
However, we need to implement comconsole on all efi platforms first, then
we need the ability to draw console, so we do not have to use SimpleTextOutput
protocol (which will write both on video and serial in case of multiplexed
ComOut).
Differential Revision: https://reviews.freebsd.org/D22161
Actual modules get require()'d in, rather than try_include(). All instances
of try_include should be provided with proper hooks/API in the rest of
loader to do the work they need to do, since we can't rely on them to exist.
Convert this now to lfs + dofile since we won't really be treating them as
modules.
lfs is required because dofile will properly throw an error if the file
doesn't exist, which is not in the spirit of 'optionally included'.
Getting out of the pcall game allows us to provide a loader.exit() style
call that backs out to the common bits of loader (autoboot sequence unless
disabled with a loader.setenv("autoboot_delay", "NO")). The most ideal way
identified so far to implement loader.exit() is to throw a special
abort-style error that indicates to the caller in interp_lua that we've not
actually errored out, just continue execution. Otherwise, we have to hack in
logic to bubble up and return from loader.lua without continuing further,
which gets kind of ugly depending on the context in which we're aborting.
A compat shim is provided temporarily in case the executing loader doesn't
yet have loader.lua_path, which was just added in r354246.
As described previously, loader.lua_path is absolute path where scripts are
installed. A future commit will use this to build paths for dofile in
try_include, rather than the current pcall/require setup that makes it more
difficult to coordinate loader aborts from local.lua -- we do not need the
flexibility of require(), and local.lua is in-fact not a 'module-like' file
as we will not be referencing anything from it.
Multiple places coordinate to 'know' where lua scripts are installed. Knock
this down to being formally defined (and overridable) in exactly one spot,
defs.mk, and spread the knowledge to loaders and liblua alike. A future
commit will expose this to lua as loader.lua_path, so it can build absolute
paths to lua scripts as needed.
MFC after: 1 week
Add ficl words for isvirtualized
and move ficl inb and outb words to ficl/x86/sysdep.c
so can be shared by i386 and amd64
Reviewed by: imp bdrewery
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org/D22069
PATH_BOOTABLE_TOKEN can be set to a non-standard
path that identifies a device as bootable.
Reviewed by: kevans, bcran
Differential Revision: https://reviews.freebsd.org/D22062
Previously color.disabled would be calculated at color module load time,
then never touched again. We can detect serial boots beyond just what we're
told by loader.conf(5) so this works out in many cases, but we must
re-evaluate the situation after the config is loaded to make sure we're not
supposed to be forcing it enabled/disabled.
Discovered while trying to test r353872.
When colors are disabled, color.escape{fg,bg} would return the passed in
color rather than the proper ANSI sequence for the color.
color.escape{fg,bg} would be wrong.
Instead return '', as the associated reset* functions will also return ''.
This should get rid of the funky '2' and '4' in the kernel selector if
you're booting serial.
Reported by: npn
When zfs probe did fail and no spa was created, but zfs_fmtdev() is called,
we will crash while dereferencing spa (NULL pointer dereference).
MFC after: 1 week
PATH_BOOTABLE_TOKEN can be set to a non-standard
path that identifies a device as bootable.
Reviewed by: kevans, bcran
Differential Revision: https://reviews.freebsd.org/D22062
Add generic PVR values for PowerISA 2.07 and 3.00. This allows booting pseries
in QEMU with compatibilty mode enabled.
Submitted by: Shawn Anastasio <shawn@anastas.io>
This was committed due to what was later diagnosed as an msdosfs bug
preventing in-place strip. This bug was fixed in r352564, and we agreed to
keep the workaround in for a bit to allow the driver fix a suitable amount
of propagation time for folks building/installing powerpc/ubldr, seeing as
how we were not in any hurry to revert.
Logic was backwards. The function returns true if it *is* running as a
hypervisor, whereas we want to only call the CAS utility if we're running as a
guest.
Reported by: Shawn Anastasio <shawn@anastas.io>
Since local UEFI console is implemented on top of framebuffer,
we need to avoid redrawing the whole screen ourselves, but let
Simple Text Mode to do the scroll for us.
Add settable variables to control teken default color attributes.
The supported colors are 0-7 or basic color names:
black, red, green, brown, blue, magenta, cyan, white.
The current implementation does add some duplication which will be addressed
later.
It's not uncommon these days for the terminals attached to serial consoles
to support ANSI escape sequences. However, we assume escape sequences may
break some serial consoles and default to not using them when boot_serial or
boot_multicons (or if console contains "comconsole" in the forth loader) for
broader compatibility. We also have loader_color which can be explicitly set
to "NO" to disable the use of ANSI escape sequences.
The problem is that loader_color=YES gets ignored when boot_serial=YES or
boot_multicons=YES (or when console contains "comconsole" in the forth
loader).
To fix, the existing default behavior remains unchanged when loader_color is
unset, loader_color=NO explicitly disables the use of ANSI escape sequences
still, and the change is that loader_color=YES can now be used to explicitly
allow ANSI escapes when a serial console is enabled.
Submitted by: Ryan Moeller <ryan@ixsystems.com>
Reviewed by: tsoome (forth), kevans (lua)
MFC after: 1 week
Sponsored by: iXsystems, Inc. (Ryan)
Differential Revision: https://reviews.freebsd.org/D21732
Summary:
Install's strip capability, by way of strip(1), doesn't seem to work
correctly on msdosfs, and instead ends up truncating the resulting
binary to 0-length. As a workaround, don't strip ubldr(8). This
fixes installworld on Book-E ubldr-based platforms, which prior to this
would need to manually install ubldr separately after installworld, in
order to have a functional ubldr.
The same thing could be done on PowerNV platforms that use msdosfs /boot
volumes, since loader and loader.kboot, etc, all get truncated to 0 on
install. However, PowerNV does not use loader, instead loading from
petitboot, so it's not really necessary at this time.
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D21725
BFD appears to silently truncate 0xffffffff80800000 when it processes the
ldscript for 32-bit mips, but LLD chokes on it as the linker script tries to
place elements above 32-bit range. It's unclear to me if silent truncation
is kosher or not and whether this patch is really what we want to do, but it
is one approach at least.
Reviewed by: imp, mizhka
Differential Revision: https://reviews.freebsd.org/D21487
UEFI specification 2.7A, EFI_BLOCK_IO_PROTOCOL, page 566.
The ioalign property does define the alignment of data buffer.
If the alignment is required and our buffer is not aligned, or if
the data buffer is not multiple of Blocksize, we need to use bounce buffer
to perform the block IO. This is much like with BIOS version, except
there the INT13 needs buffer to be located in low memory.
Additionally, we need to handle disk writes properly.
Clean up libstand zalloc* sources. Note that it is not 100% whitespace cleanup.
I also reduced block in znalloc and zfree as those were obvious simplifications
and did help to save one level of indent.
This command will trigger a reload of the configuration from disk. This is
useful if you've changed currdev from recovery media to local disk as much
as I have over the past ~2 hours and are tired of the extra keystrokes.
This is really just a glorified shortcut, but reload-conf is likely easier
to remember for other people and does save some keystrokes when reloading
the configuration. It is also resilient to the underlying config method
changing interface, but this is unlikely to happen.
MFC after: 1 week
The box drawing characters we use aren't necessarily safe with a serial
console; for instance, in the report by npn@, these were causing his xterm
to send back a sequence that lua picked up as input and halted the boot.
This is less than ideal.
Fallback to ASCII frames for console with 'comconsole' in it. This is a
partial revert r338108 by imp@ -- instead of removing the menu entirely and
disabling color/cursor sequences, just reverting the default frame to ASCII
is enough to not break in this setup.
Reported by: npn
Triaged and recommended by: tsoome
--gc-sections is not really useful unless we generate sections with
-ffunction-sections -fdata-sections
While there, i386/loader would win from --gc-sections too.
Summary:
There is logic in ELF loadimage() to relocate kernels, but currently
only type ET_EXEC. PowerPC kernels are ET_DYN, and can be relocated anywhere.
Add the load offset to kernel entry points on this platform.
Reviewed by: imp, ian
Differential Revision: https://reviews.freebsd.org/D21286
Replace mini cons25 emulator with teken, this does enable us proper console
terminal for loader and will make it possible to implement different
back end callbacks to draw to screen.
At this time we still only "draw" in text mode.
This unbreaks using the powerpc64 loader on a 32-bit processor.
Approved by: jhibbits (mentor)
Differential Revision: https://reviews.freebsd.org/D21297
This brings the libsa/mips _setjmp implementation closer to parity with the
libc version.
Reviewed by: imp, jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21330
The cd handles should be collected as list of partitions. Some systems also
provide base name for block device (like PciRoot(0x0)/Pci(0x5,0x0)), we need
to be careful about those.
To make out life a bit easier, we prepare not just an array of handles, but we
allocate pdinfo struct for each handle and devicepath, then we can simplify
our work to sort the devices.
Differential Revision: https://reviews.freebsd.org/D21187
Reduce the size of the EFI_STAGING area we allocate on arm to 32. On arm SBC
such as the NanoPi-NEOLTS the staging area allocation will fail on the 256MB
model with a staging size of 64.
Reviewed by: bcran, manu
Approved by: bz (mentor)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D21016
ufsread.c grows a dependency on __ashldi3 with llvm90. For gptboot, just
start pulling in ashldi3.c ashrdi3.c lshrdi3.c into libsa for all archs as
the number of archs requiring one or more of them keeps growing. qdivrem.c
and quad.h can be trivially kicked out of libsa if we start pulling these
from compiler-rt as qdivrem was only used to implement umoddi3, divdi3,
moddi3 (also in qdivrem.c).
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21291
ufsread.c grows a dependency on __ashldi3 with llvm90. Grab ashldi3.c out of
compiler-rt rather than trying to link against libsa (for now).
-Wno-missing-prototypes is necessary to compile ashldi3.c standalone.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21291
Other parts of stand/ that don't use libsa will need to grab bits from libc
shortly. Push LIBC_SRC up to defs.mk in advance of this so that they can use
it, and rename it to LIBCSRC to match the convention of the rest of the *SRC
variables in this file.
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21282
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler did not handle .codeNN directives. Clang gained
support quite some time ago, so we can build stand/ with IAS.
In some cases there were small differences in generated object output.
In the case of gptzfsboot however using GNU as or Clang IAS to assemble
gptldr.S resulted in identical final gptzfsboot binary output.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11115
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler (IAS) did not handle .codeNN directives. Clang
gained support quite some time ago, and we can now build stand/ with
IAS. In most cases IAS- and GNU as-assembled boot components were
identical, and CLANG_NO_IAS was already removed from other components.
Clang IAS produces different output for some components, including
pxeldr, so CLANG_NO_IAS was not previously removed for those.
In the case of pxeldr the difference is that IAS adds a size override
prefix (67h) to three instructions to specify a 32-bit address, even
though the two high bytes are zero and the address fits in 16 bits.
this wastes three bytes per instruction and causes some additional nop
npadding to be required elsewhere in the object, but pxeboot is not
size-constrained so it doesn't matter.
Sponsored by: The FreeBSD Foundation
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler (IAS) did not handle .codeNN directives. Clang
gained support quite some time ago, and we can now build stand/ with
IAS. In most cases IAS- and GNU as-assembled boot components were
identical, and CLANG_NO_IAS was already removed from other components.
Clang IAS produces different output for some components, including
cdboot, so CLANG_NO_IAS was not previously removed for those.
In the case of cdboot the difference is that IAS adds a size override
prefix (67h) to many instructions to specify a 32-bit address, even
though the two high bytes are zero. This wastes three bytes per
instance, but as cdboot is not size-constrained it doesn't matter.
Padding is also different in one case; Clang used two one-byte nops
while GNU as used a single two-byte xchg %eax, %eax. In any case, there
is no functional change.
Sponsored by: The FreeBSD Foundation
Use quad.h from libc instead for the time being. This reduces the number of
nearly-identical-quad.h we have in tree to two with only minor changes.
Prototypes for some *sh*di3 have been added to match the copy in libkern.
The differences between the two are likely few enough that they can perhaps
be merged with little additional effort to bring us down to 1.
MFC after: 3 days
Many components under stand/ had CLANG_NO_IAS added when Clang's
Integrated Assembler (IAS) did not handle .codeNN directives. Clang
gained support quite some time ago, and we can now build stand/ with
IAS. In most cases IAS- and GNU as-assembled boot components were
identical, and CLANG_NO_IAS was already removed from other components.
Clang IAS produces different output for some components, including
boot2, so CLANG_NO_IAS was not previously removed for those.
In the case of boot2 the difference is that IAS produces a larger
encoding for one instruction (the testb at the beginning of read).
GNU as produces:
2e f6 06 b0 08 80
while IAS includes an address size override prefix (67) and produces:
2e 67 f6 05 b3 08 00 00 80
This results in three fewer NOPs elsewhere in boot2 but no functional
change, so switch to IAS for boot2.
(We can separately pursue improved 16-bit IAS support with the LLVM
developers.)
Sponsored by: The FreeBSD Foundation
We should support removing vdev from boot pool. Update loader zfs reader
to support com.delphix:removing.
Reviewed by: allanjude
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D18901
The chain command can be used to chain load another binary.
If veriexec is enabled we should verify it first.
Note that on EFI systems the verification was already done
through firmware, assuming that Secure Boot was enabled there.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reviewed by: sjg
MFC after: 1 week
Obtained from: Semihalf
Differential Revision: https://reviews.freebsd.org/D20952
The HandleProtocol() is deprecated interface and we should use OpenProtocol()
instead. Moreover, in some firmware implementation(s), the HandleProtocol()
does return device path using static storage, so we can not keep the value
returned there. With same firmware, the OpenProtocol() does return data we
do not need to clone.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D21162
Guest PPC OSs running under a hypervisor may communicate the features they
support, in order for the hypervisor to expose a virtualized machine in the way
the client (guest OS) expects (see LoPAPR 1.1 - B.6.2.3).
This is done by calling the "/ibm,client-architecture-support" (CAS) method,
informing supported features in option vectors. Until now, FreeBSD wasn't
using CAS, but instead relied on hypervisor/QEMU's defaults.
The problem is that, without CAS, it is very inconvenient to run POWER9 VMs on
a POWER9 host running with radix enabled. This happens because, in this case,
the QEMU default is to present the guest OS a dual MMU (HPT/RPT), instead of
presenting a regular HPT MMU, as FreeBSD expects, resulting in an early panic.
The known workarounds required either changing the host to disable radix or
passing a flag to QEMU to run in a POWER8 compatible mode.
With CAS, FreeBSD is now able to communicate that it wants an HPT MMU,
independent of the host setup, which now makes FreeBSD work on POWER9/pseries,
with KVM enabled and without hugepages (support added in a previous commit).
As CAS is invoked through OpenFirmware's call-method interface, it needs to be
performed early, when OpenFirmware is still operational. Besides, now that FDT
is the default way to inspect the device tree on PPC, OFW call-method feature
will be unavailable by default, when control is passed to the kernel. Because
of this, the call to CAS is being performed at the loader, instead of at the
kernel.
To avoid regressions with old platforms, this change uses CAS only on
POWER8/POWER9.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D20827
libsecureboot can tell us if the most recent file opened was
verfied or not.
If it's state is VE_UNVERIFIED_OK, skip if variable
matches one of the restricted prefixes.
Reviewed by: stevek
MFC after: 1 week
Sponsored by: Juniper Networks
Differential Revision: https://reviews.freebsd.org//D20909
Summary:
efi loader does not work with static network parameters. It always uses
BOOTP/DHCP and also uses RARP as a fallback. Problems with DHCP servers can
cause the loader to fail to populate network parameters.
Submitted by: Siddharth Tuli <siddharthtuli_gmail.com>
Reviewed by: imp
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D20811
To avoid failures when the large 18MB nvidia.ko module is being loaded,
increase EFI_STAGING_SIZE from 64MB to 100MB on x64 systems.
Leave the other platforms at 64MB.
The code in efihttp.c was assuming that dv_open wouldn't be called if
dv_init failed. But the dv_init return value is currently ignored.
Add a new variable, `efihttp_init_done` and only proceed in dv_open if
it's true. This fixes the loader on systems without efi http support.
NANDFS has been broken for years. Remove it. The NAND drivers that
remain are for ancient parts that are no longer relevant. They are
polled, have terrible performance and just for ancient arm
hardware. NAND parts have evolved significantly from this early work
and little to none of it would be relevant should someone need to
update to support raw nand. This code has been off by default for
years and has violated the vnode protocol leading to panics since it
was committed.
Numerous posts to arch@ and other locations have found no actual users
for this software.
Relnotes: Yes
No Objection From: arch@
Differential Revision: https://reviews.freebsd.org/D20745
Add support for an HTTP "network filesystem" using the UEFI's HTTP
stack.
This also supports HTTPS, but TianoCore EDK2 implementations currently
crash while fetching loader files.
Only IPv4 is supported at the moment. IPv6 support is planned for a
follow-up changeset.
Note that we include some headers from the TianoCore EDK II project in
stand/efi/include/Protocol verbatim, including links to the license instead
of including the full text because that's their preferred way of
communicating it, despite not being normal FreeBSD project practice.
Submitted by: scottph
Reviewed by: imp, bcran
Differential Revision: https://reviews.freebsd.org/D20643
There are many new features in ZoF. Most, if not all, do not effect read only usage.
Encryption in particular is enabled at the pool level but used at the dataset level.
The loader obviously will not be able to boot if the boot dataset is encrypted, but
should not care if some other dataset in the root pool is encrypted.
Reviewed by: allanjude
MFC after: 1 week
Don't commit to exclusive access to the network device handle by
efinet until the loader has decided to load something through the
network. This allows for the possibility of other users of the
network device.
Submitted by: scottph
Reviewed by: tsoome, emaste
Tested by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20642
At least since version 4.0.0, QEMU became bug-compatible with PowerVM's
vty, by inserting a \0 after every \r. As this confuses loader's
interpreter and as a \0 coming from the console doesn't seem reasonable,
it's now being filtered at OFW console input.
Reviewed by: jhibbits
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20676
rename the source to gsb_crc32.c.
This is a prerequisite of unifying kernel zlib instances.
PR: 229763
Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>
Differential Revision: https://reviews.freebsd.org/D20193
Add the customary warnings to disable format checking on armv7. Code
move to new files, and the unconditional setting of WARNS to 6
provoked it on tinerbox...
This is a primary boot loader that is intended to implement the
gptboot partition selection algorithm just like we did for BIOS
booting. While the preferred method for UEFI is to use the UEFI Boot
Manager protocol, there are situations where that can't be done: some
BIOS makers interfere with the protocol in unhelpful ways, there's a
new standard for a zero variable write from the client OS, and finally
for USB drives that might be mobile between systems with multiple
partitions there needs to be a media stable way to select.
Reviewed by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20547
Segregate the disk probing and selection protocol from the rest of the
boot loader.
Reviewed by: tsoome, bcran
Differential Revision: https://reviews.freebsd.org/D20547
