| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
When loader(8) inspects MBR, it chooses GPT as main partition table,
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
|
|
|
|
|
|
| |
Approved by: re (blackend)
MFC after: 1 week
X-MFC note: stable/9 only
|
|
|
|
|
|
|
| |
Some partitioning tools can create GPT with number of entries less
than 128.
MFC after: 1 week
|
|
|
|
|
|
|
| |
beginning.
Submitted by: Steven Hartland
MFC after: 1 week
|
|
|
|
|
|
|
| |
Before this change strncmp would access and _compare_ n+1 characters
in the case where the first n characters match.
MFC after: 5 days
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
the elf headers.
|
|
|
|
|
| |
e_entry field holds a physical or a virtual address. Add a comment block
that explains the assumptions being made by the adjustment code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Tested by: dchagin
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Approved by: adrian (co-mentor) (implicit)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
with the rest of code.
|
|
|
|
|
|
|
| |
then try automatically detect an appropriate partition type.
PR: kern/172550
Tested by: Ralf Wenk
|
|
|
|
|
| |
flag, that disables the caching of partition tables metadata.
Use this flag for floppies in the libi386/biosdisk driver.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
next files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
resolve dependencies of modules at boot time and load additional modules when
needed.
MFC after: 1 week
|
| |
|
|
|
|
|
|
| |
... the same way it's done for type argument.
MFC after: 2 weeks
|
|
|
|
|
| |
Reported by: Mathias Breuninger
MFC after: 1 week
|
|
|
|
| |
Requested by: rpaulo
|
|
|
|
|
|
| |
strictly, to do not lost some partitions.
Reported by: swills@
|
| |
|
|
|
|
| |
MFC after: 3 weeks
|
|
|
|
|
| |
but d_partition isn't explicitly set, then try to open BSD label and its
first partition.
|
|
|
|
| |
disk_fmtdev() already has the colons.
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
| |
contains partitions with type zero. And it has worked.
So, allow detect these partitions.
Reported by: glebius
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
loader(8). The following partition tables are supported: BSD label, GPT,
MBR, EBR and VTOC8.
|
|
|
|
|
|
|
| |
kld that only contained a sysctl). The kernel linker allows such
modules, so the boot loader should not reject them.
MFC after: 2 weeks
|
|
|
|
|
|
| |
unnecessary 64-bit math on 32-bit machines.
Sponsored by: Google Summer of Code 2011
|
|
|
|
|
|
|
| |
PR: 168016
Submitted by: Nobuyuki Koganemaru
Approved by: gjb
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
PR: 165025
Submitted by: Gavin Mu
MFC after: 1 week
|
|
|
|
|
|
|
|
|
| |
table aren't valid. If they are ok, use hdr_lba_alt value to read backup
header. This will make gptboot happy when GPT used atop of some GEOM
provider, e.g. GEOM_MIRROR.
Reviewed by: pjd
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
Disussed with: gavin
No objection from: doc
Approved by: joel
MFC after: 3 days
|
|
|
|
|
|
| |
While at it, remove some style(9) bugs in libkern.h.
Submitted by: kan
|