EFI was mixing caching in two separate places causing issues when multiple
partitions where tested.
Eliminate this by removing fsstat and re-factoring fsread into fsread_size,
adding basic parameter validation.
Also:
* Enhance some error print outs.
* Fix compilation under UFS1_ONLY and UFS2_ONLY
* Use sizeof on vars instead of structs.
* Add basic parameter validation to fsread_size.
MFC after: 1 week
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4989
The boot code fsread was caching the result of meta data request and
reusing it even for calls with inode = 0, which is used to partitions
trigger a probe.
The result was that success was incorrectly returned for all partition
probes after the first valid success, even for partitions which are not
UFS.
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Fix compiler warnings about dropping const qualifier by changing file_loadraw
name param to const, and updating method to make that the case (it was
abusing the variable).
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Non-interactive forth command errors where silent even for critical issues
e.g. failing to load a required kernel module or mfs_root.
This resulted in later unexplained and hard to trace errors such as mount
root failures.
This introduces additional command return codes that are treated
appropriately by the non-interactive command processor (bf_command).
* CMD_CRIT = print error
* CMD_FATAL = panic
Also fix minor style(9) issues with command_load return codes.
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Set WARNS if not set for EFI boot code and fix the issues highlighted by
setting it.
Most components are set to WARNS level 6 with few being left at lower
levels due to the amount of changes needed to fix at higher levels.
Error types fixed:
* Missing / invalid casts
* Missing inner structs
* Unused vars
* Missing static for internal only funcs
* Missing prototypes
* Alignment changes
* Use of uninitialised vars
* Unknown pragma (intrinsic)
* Missing types etc due to missing includes
* printf formatting types
Reviewed by: emaste (in part)
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4839
Remove the printf("Not ufs\n") from the boot code which was hidden by the
local printf implementations, allowing these to have that code removed too.
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
When we are detecting a partition table and didn't find PMBR, try to
read backup GPT header from the last sector and if it is correct,
assume that we have GPT.
Reviewed by: rpokala
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D4282
This is not properly respecting WITHOUT or ARCH dependencies in target/.
Doing so requires a massive effort to rework targets/ to do so. A
better approach will be to either include the SUBDIR Makefiles directly
and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose
the benefit of having a userland/lib, userland/libexec, etc, though and
results in a massive package. The current implementation of targets/ is
very unmaintainable.
Currently rescue/rescue and sys/modules are still not connected.
Sponsored by: EMC / Isilon Storage Division
The initial IOCTL implementation supports reading disk physical
geometry.
Two additional functions were added. They allow reading/writing raw
data to the disk (default partition).
Submitted by: Wojciech Macek <wma@semihalf.com>
Obtained from: Semihalf
Sponsored by: Juniper Networks Inc.
Differential Revision: https://reviews.freebsd.org/D4143
the temporary file to vers.c at the end of the script
The previous logic wrote out to vers.c multiple times, so the file
could be incorrectly interpreted as being completely written out
after one of the echo calls with recursive make, when in reality it
was only partially written.
Also, in the event the build was interrupted when creating vers.c
(small race window), it would have a leftover file that needed to
be cleaned up before resuming the build.
MFC after: 3 weeks
Sponsored by: EMC / Isilon Storage Division
For example, without this patch, the following three lines
in /boot/loader.conf would result in /boot/root.img being preloaded
twice, and two md(4) devices - md0 and md1 - being created.
initmd_load="YES"
initmd_type="md_image"
initmd_name="/boot/root.img"
Reviewed by: marcel@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3204
but it's hard to find and easy to miss.
Reviewed by: wblock@
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3183
than bootp and rarp.
The code which splits a serverip:/rootpath string into rootip and a plain
pathname is now a separate net_parse_rootpath() function that can be
called by others. The code that sets the kernel env vars needed for
nfs_diskless is moved into net_open() so that the variables get set no
matter where the params came from.
There was already code in net_open() that allowed for the possibility that
some other entity has set up the network-related global variables. It uses
the rootip variable as the key, assuming that if it is set all the other
required variables are set too. These changes don't alter the existing
behavior, they just make it easier to actually write some new code to get
the params from another source (such as the U-Boot environment).
Previously, ubldr would use the virtual addresses in the elf headers by
masking off the high bits and assuming the result was a physical address
where the kernel should be loaded. That would sometimes discard
significant bits of the physical address, but the effects of that were
undone by archsw copy code that would find a large block of memory and
apply an offset to the source/dest copy addresses. The result was that
things were loaded at a different physical address than requested by the
higher code layers, but that worked because other adjustments were applied
later (such as when jumping to the entry point). Very confusing, and
somewhat fragile.
Now the archsw copy routines are just simple copies, and instead
archsw.arch_loadaddr is implemented to choose a load address. The new
routine uses some of the code from the old offset-translation routine to
find the largest block of ram, but it excludes ubldr itself from that
range, and also excludes If ubldr splits the largest block of ram in
two, the kernel is loaded into the bottom of whichever resulting block is
larger.
As part of eliminating ubldr itself from the ram ranges, export the heap
start/end addresses in a pair of new global variables.
This change means that the virtual addresses in the arm kernel elf headers
now have no meaning at all, except for the entry point address. There is
an implicit assumption that the entry point is in the first text page, and
that the address in the the header can be turned into an offset by masking
it with PAGE_MASK. In the future we can link all arm kernels at a virtual
address of 0xC0000000 with no need to use any low-order part of the
address to influence where in ram the kernel gets loaded.
The function was defined as taking 4 parameters and returning EFI_STATUS,
but all existing callers (in asm code) passed only two parameters and don't
use the return value. The function signature now matches that usage, and
doesn't refer to efi-specific types.
Parameters and variables now use the cannonical typenames set up by elf.h
(Elf_Word, Elf_Addr, etc) instead of raw C types. Hopefully this will
prevent suprises as new platforms come along and use this code.
The function was renamed from _reloc() to self_reloc() to emphasize its
difference from the other elf relocation code found in boot/common.
Differential Revision: https://reviews.freebsd.org/D2490
Use the proper types in parse_modmetadata for the p_start and p_end
parameters. This was causing problems in the ARM 32bit loader.
Sponsored by: Citrix Systems R&D
Reported and Tested by: ian
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
associating an optional PNP hint table with this module. In the
future, when these are added, these changes will silently ignore the
new type they would otherwise warn about. It will always be safe to
ignore this data. Get this into the builds today for some future
proofing.
MFC After: 3 days
output frequency of the "twiddle" IO progress indicator. The default
value is 1. For larger values N, the next stage of the animation is only
output on every Nth call to the output routine. A sufficiently large N
effectively disables the animation completely.
crowded as we now are at about 70k. Bump the limit to 1MB instead
which is still quite a reasonable limit and allows for future growth
of this file and possible future expansion to additional data.
MFC After: 2 weeks
The various structures in the mod_metadata set of a FreeBSD kernel and
modules contain pointers. The FreeBSD loader correctly deals with a
mismatch in loader and kernel pointer size (e.g. 32-bit i386/ppc
loader, loading 64-bit amd64/ppc64 kernels), but wasn't dealing with
the inverse case where a 64-bit loader was loading a 32-bit kernel.
Reported by: ktcallbox@gmail.com with a bhyve/i386 and ZFS root install
Differential Revision: https://reviews.freebsd.org/D1129
Reviewed by: neel, jhb
MFC after: 1 week
This involves:
1. Have the loader pass the start and size of the .ctors section to the
kernel in 2 new metadata elements.
2. Have the linker backends look for and record the start and size of
the .ctors section in dynamically loaded modules.
3. Have the linker backends call the constructors as part of the final
work of initializing preloaded or dynamically loaded modules.
Note that LLVM appends the priority of the constructors to the name of
the .ctors section. Not so when compiling with GCC. The code currently
works for GCC and not for LLVM.
Submitted by: Dmitry Mikulin <dmitrym@juniper.net>
Obtained from: Juniper Networks, Inc.
like EX and SRX. The install command uses pkgfs to extract a kernel,
zero or more modules and a root file system from the specified package
and boots the kernel. The name of the kernel, the list of modules and
the name of the root file system can be specified by putting a
file called "metatags in the package.
The package to use is given by an URL. The schemes supported are
tftp and file. For the file scheme, the disk is currently hardcoded
but that should really look for the package on all devices and
partititions.
Obtained from: Juniper Networks, Inc.
particular, allow loaders to define the name of the RC script the
interpreter needs to use. Use this new-found control to have the
PXE loader (when compiled with TFTP support and not NFS support)
read from ${bootfile}.4th, where ${bootfile} is the name of the
file fetched by the PXE firmware.
The normal startup process involves reading the following files:
1. /boot/boot.4th
2. /boot/loader.rc or alternatively /boot/boot.conf
When these come from a FreeBSD-defined file system, this is all
good. But when we boot over the network, subdirectories and fixed
file names are often painful to administrators and there's really
no way for them to change the behaviour of the loader.
Obtained from: Juniper Networks, Inc.
This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation
This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h
Discussed at: BSDcan
the PowerPC port with all the Open Firmware bits removed and replaced by
their EFI counterparts. On the whole, I think I prefer Open Firmware.
This code is supposed to be an immutable shim that sits on the EFI system
partition, loads /boot/loader.efi from UFS and tells the real loader what
disk/partition to look at. It finds the UFS root partition by the somewhat
braindead approach of picking the first UFS partition it can find. Better
approaches are called for, but this works for now. This shim loader will
also be useful for secure boot in the future, which will require some
rearchitecture.
when MBR contains only PMBR entry or it is bootcamp-compatible.
If MBR has PMBR entry and some other, the loader rejects it.
Make these checks to be less strict. If loader decided that PMBR
isn't suitable for GPT, it will use MBR.
Reported by: Paul Thornton
Tested by: Paul Thornton
MFC after: 1 week
fragments; while this won't actually be used for anything (yet), it
doesn't hurt to ensure it is exposed to the tinderbox.
Requested by: imp, jmallett
MFC after: 3 weeks
arguments from type,filename to filename,type to be consistant with other
public file_whatever() functions, and change it to return a pointer to
the preloaded_file struct describing the file. Adjust existing callers.
- Similar to the hack for bootinfo32.c in userboot, define
_MACHINE_ELF_WANT_32BIT in the load_elf32 file handlers in userboot.
This allows userboot to load 32-bit kernels and modules.
- Copy the SMAP generation code out of bootinfo64.c and into its own
file so it can be shared with bootinfo32.c to pass an SMAP to the i386
kernel.
- Use uint32_t instead of u_long when aligning module metadata in
bootinfo32.c in userboot, as otherwise the metadata used 64-bit
alignment which corrupted the layout.
- Populate the basemem and extmem members of the bootinfo struct passed
to 32-bit kernels.
- Fix the 32-bit stack in userboot to start at the top of the stack
instead of the bottom so that there is room to grow before the
kernel switches to its own stack.
- Push a fake return address onto the 32-bit stack in addition to the
arguments normally passed to exec() in the loader. This return
address is needed to convince recover_bootinfo() in the 32-bit
locore code that it is being invoked from a "new" boot block.
- Add a routine to libvmmapi to setup a 32-bit flat mode register state
including a GDT and TSS that is able to start the i386 kernel and
update bhyveload to use it when booting an i386 kernel.
- Use the guest register state to determine the CPU's current instruction
mode (32-bit vs 64-bit) and paging mode (flat, 32-bit, PAE, or long
mode) in the instruction emulation code. Update the gla2gpa() routine
used when fetching instructions to handle flat mode, 32-bit paging, and
PAE paging in addition to long mode paging. Don't look for a REX
prefix when the CPU is in 32-bit mode, and use the detected mode to
enable the existing 32-bit mode code when decoding the mod r/m byte.
Reviewed by: grehan, neel
MFC after: 1 month
they can easily be used by later post-processing. When searching for
a compiled-in fdt blob, use the section headers to get the size and
location of the .dynsym section to do a symbol search.
This fixes a problem where the search could overshoot the symbol
table and wander into the string table. Sometimes that was harmless
and sometimes it lead to spurious panic messages about an offset
bigger than the module size.
elf headers, mask out the high nibble of that address. This effectly makes
the entry point the offset from the load address, and it gets adjusted for
the actual load address before jumping to it.
Masking the high nibble makes assumptions about memory layout that are true
for all the arm platforms we support right now, but it makes me uneasy.
This needs to be revisited.
After digging through more carefully, it looks like there's
no real need to have the DTB in the module directory.
So we can simplify a lot: Just copy DTB into local heap
for "fdt addr" and U-Boot integration, drop all the extra
COPYIN() calls.
I've left one final COPYIN() to update the in-kernel DTB
for consistency with how this code used to work, but I'm
no longer convinced it's appropriate here.
I've also remove the mem_load_raw() utility that I added
to boot/common/module.c with r247045 since it's no longer
necessary.
This will be used by some upcoming changes to loader(8) FDT
handling to allow it to use an FDT provided by an earlier
boot stage the same as an FDT loaded from disk.
r238966
Bump up the heap size to 1MB. With a few kernel modules, libstand
zalloc and userboot seem to want to use ~600KB of heap space, which
results in a segfault when malloc fails in bhyveload.
r241180
Clarify comment about default number of FICL dictionary cells.
r241153
Allow the number of FICL dictionary cells to be overridden.
Loading a 7.3 ISO with userboot/amd64 takes up 10035 cells,
overflowing the long-standing default of 10000.
Bump userboot's value up to 15000 cells.
Reviewed by: dteske (r238966,241180)
Obtained from: NetApp
command execution. In case of such unhandled exception, vmReset() inside
ficlExecC() flushes the VM state. Attempt to return back to Forth after
that cause garbage dereference with unexpected results. To avoid that
situation call vmThrow() directly instead of expecting Forth to do it.
- clarify meaning of console flags
- perform i/o via a console only if both of the following conditions are met:
o console is active (selected by user or config)
o console flags that it can perform the operation
- warn if a chosen console can not work (the warning may go nowhere without
working and active console, though)
Reviewed by: jhb
Tested by: Uffe Jakobsen <uffe@uffe.org>,
Olivier Cochard-Labbe' <olivier@cochard.me>
MFC after: 26 days
disk_open(). Very often this is called several times for one file.
This leads to reading partition table metadata for each call. To
reduce the number of disk I/O we have a simple block cache, but it
is very dumb and more than half of I/O operations related to reading
metadata, misses this cache.
Introduce new cache layer to resolve this problem. It is independent
and doesn't need initialization like bcache, and will work by default
for all loaders which use the new DISK API. A successful disk_open()
call to each new disk or partition produces new entry in the cache.
Even more, when disk was already open, now opening of any nested
partitions does not require reading top level partition table.
So, if without this cache, partition table metadata was read around
20-50 times during boot, now it reads only once. This affects the booting
from GPT and MBR from the UFS.
number is not exactly specified. When the disk has MBR, also try to read
BSD label after ptable_getpart() call. When the disk has GPT, also set
d_partition to 255. Mostly, this is how it worked before.
When we open the disk, check the type of partition table, that has
been detected. If this is BSD label, then we assume this is DD mode.
Reported by: dim@
It uses new API from the part.c to work with partition tables.
Update userboot's disk driver to use new API. Note that struct
loader_callbacks_v1 has changed.
This way with the new zfsloader there is no need to explicitly set zfs
root filesystem either via vfs.root.mountfrom or fstab.
It should be automatically picked up from currdev which is by default
is set from bootfs.
Tested by: Florian Wagner <florian@wagner-flo.net> (x86)
MFC after: 1 month
In zfs loader zfs device name format now is "zfs:pool/fs",
fully qualified file path is "zfs:pool/fs:/path/to/file"
loader allows accessing files from various pools and filesystems as well
as changing currdev to a different pool/filesystem.
zfsboot accepts kernel/loader name in a format pool:fs:path/to/file or,
as before, pool:path/to/file; in the latter case a default filesystem
is used (pool root or bootfs). zfsboot passes guids of the selected
pool and dataset to zfsloader to be used as its defaults.
zfs support should be architecture independent and is provided
in a separate library, but architectures wishing to use this zfs support
still have to provide some glue code and their devdesc should be
compatible with zfs_devdesc.
arch_zfs_probe method is used to discover all disk devices that may
be part of ZFS pool(s).
libi386 unconditionally includes zfs support, but some zfs-specific
functions are stubbed out as weak symbols. The strong definitions
are provided in libzfsboot.
This change mean that the size of i386_devspec becomes larger
to match zfs_devspec.
Backward-compatibility shims are provided for recently added sparc64
zfs boot support. Currently that architecture still works the old
way and does not support the new features.
TODO:
- clear up pool root filesystem vs pool bootfs filesystem distinction
- update sparc64 support
- set vfs.root.mountfrom based on currdev (for zfs)
Mid-future TODO:
- loader sub-menu for selecting alternative boot environment
Distant future TODO:
- support accessing snapshots, using a snapshot as readonly root
Reviewed by: marius (sparc64),
Gavin Mu <gavin.mu@gmail.com> (sparc64)
Tested by: Florian Wagner <florian@wagner-flo.net> (x86),
marius (sparc64)
No objections: fs@, hackers@
MFC after: 1 month
