Since the efipart rewrite, the chain command was looking for device
handle using interface applicable only for net devices. Disk
partitions and zfs pools need their own approach to find the proper handle.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D12287
This patch moves some EFI ZFS functions from loader to libefi,
allowing them to be used by anything that links against libefi.
Submitted by: Eric McCorkle
Differential Revision: https://reviews.freebsd.org/D11855
The smbios code does a lot of unaligned access, since we don't really
care about smbios info on ARM (not all board expose information and those
who does don't expose useful ones) disable smbios for this arch (at least
for now).
Implement simple chain loader in loader; this update does add chain command,
taking device or file as argument to load and start new boot loader.
In case of BIOS, the chain will read the boot block to address 0000:7c00 and
jumps on it. In case of UEFI, the chain command is to be used with efi
application, typically stored in EFI System Partition.
The update also does add simple menu entry, if the variable chain_disk is set.
The value of the variable chain_disk is used as argument for chain loading.
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5992
The current reboot command in efi/loader/main.c is passing extra data with
ResetSystem, however, UEFI spec 2.6, page 265 does state:
"ResetData is only valid if ResetStatus is something other than EFI_SUCCESS
unless the ResetType is EfiResetPlatformSpecific where a minimum amount of
ResetData is always required."
Therefore we should use DataSize 0 and ResetData NULL - those are two last
arguments for the call.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10562
With the zfs probe cleanup, the mistake did slip in the probe code;
instead of reading the pool GUID for the actual boot device (partition),
we read GUID for first found pool from the boot disk.
This will break the case when there are both zfs pool and ufs on the boot
disk, and the ufs is used for boot, not zfs.
Reviewed by: smh
Differential Revision: https://reviews.freebsd.org/D10359
The current zfs reader is only checking first label from each device, however,
we do have 4 labels on device and we should check all 4 to be protected
against disk failures and incomplete label updates.
The difficulty is about the fact that 2 label copies are in front of the
pool data, and 2 are at the end, which means, we have to know the size of
the pool data area.
Since we have now the mechanism from common/disk.c to use the partition
information, it does help us in this task; however, there are still some
corner cases.
Namely, if the pool is created without partition, directly on the disk,
and firmware will give us the wrong size for the disk, we only can check
the first two label copies.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10203
The current efi_zfs_probe() is overcomplicated and can be made
simpler. Still we need to pick up the device handle for our boot
disk first, because the ESP does not have to be the first partition on the
disk.
Once we do have the handle for boot disk, we probe that disk with
pointer for pool GUID.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10198
Rewrite EFI part device interface to present disk devices in more
user friendly way.
We keep list of three types of devices: floppy, cd and disk, the
visible names: fdX: cdX: and diskX:
Use common/disk.c and common/part.c interfaces to manage the
partitioning.
The lsdev -l will additionally list the device path.
Reviewed by: imp, allanjude
Approved by: imp (mentor), allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8581
Since we have dedicated libefi/env.c file for variable support, the following
changes are done:
Simple cstyle changes in env.c
Moved efi variable related commands from loader/main.c to libefi/env.c
Did create function to set "efi-version" environment variable in env.c.
This function does serve two purposes: for first a small clean up of the
loader main(), and for second, it does replace the otherwise unused
efi_variable_support hack.
A bit of cleanup of ficl backend functions. The TEST_MAIN has no meaning,
and removed few memory leaks.
The forth code is updated to use "efi-version" variable, instead of ficl
environment check.
Reviewed by: imp
Approved by: imp (mentor)
Differential Revision: https://reviews.freebsd.org/D9165
The find_currdev() is using variable "copy" to store the reference to trimmed
devpath pointer, if for some reason the efi_devpath_handle() fails, we will
leak this copy.
Also we can simplify the code there a bit.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9191
Instead of repeating "%s, Revision %s" "(%s %s)" in each loader, just
create the full version string in vers.c
Reviewed by: bapt
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8823
This change does modify devsw dv_print() to return the int value,
enabling walkers to interrupt the walk on non zero value from dv_print().
This will allow the pager_print actually to stop displaying data on
user input, and additionally pager is used in various *dev_print callbacks,
where it was missing.
For test, lsdev [-v] command should display data by screenfuls and should
stop when the key 'q' is pressed on pager prompt.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D5461
first EFI device if we can't find the one from which the image was loaded.
Reviewed by: allanjude,imp,jhb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6780
* On arm64 we need to use the ${MACHINE_CPUARCH} subdirectory.
* env.c is only needed when using forth so only build it there.
Sponsored by: ABT Systems Ltd
environment variable to allow conditional compilation based on EFI
being present or not. Provide efi-setenv, efi-getenv, and
efi-unsetenv, though those need improvement. Move the efi definition
to libefi (but include a reference so they get included).
etc. can find out where the SMBIOS entry point is located. In pure
UEFI mode the BIOS is not mapped into the standard address space so the
SMBIOS table might not appear between 0xf0000 and 0xfffff. The
UEFI environment can report this the location of the anchor. If it is
reported then expose it as hint.smbios.0.mem. This can then be used
by other tools. However, we should make smbios(4) useful and have it
take this value and provide accesor function so ipmi(4) etc. don't
have to parse and figure things about the SMBIOS table. I have some
simple patches to smbios(4) to expose this address as sysctl and
for ipmi(4) to get the base address. However, the real fix is to
have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
parse it out and return it. This would make smbios(4) useful and reduce
duplicated code. If this address doesn't point to the anchor then
finding SMBIOS info. will fail as if this didn't exist. So there should
be no harm.
With this change and the following hack, dmidecode works on a bunch of
UEFI machines that I tested:
if kenv hint.smbios.0.mem > /dev/null
then
mkdir -p /sys/firmware/efi
mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
fi
Linux exposes this information via the /sys/firmware/efi/systab file which
dmidecode looks at. We should update dmidecode to do this the FreeBSD
way when we determine what that is!
Reviewed by: jhb
1. Size returned for variable name is in bytes, not CHAR16 (the
UEFI standard is unclear on this, where it is clear on the size of
the variable).
2. Dynamically allocate the buffers so we can grow them if someone
defines a super-long variable name.
These two fixes allow me to examine all the variables in my BIOS and
also removes the repeated printing of variables.
code uses the GetTime function from the Runtime Service, however this has
been shown to not return a useable time on many arm64 UEFI implementations.
Reviewed by: jhb, smh
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D6709
In r277943, the efinet_match() routine was changed to use an off by one
when matching network interfaces. The effect was that using "net1"
actually used the device attached to "net0".
Digging into the hardware that needed this workaround more, I found that
UEFI was creating two simple network protocol devices for each physical
NIC. The first device was a "raw" Ethernet device and the second device
was a "IP" device that used the IP protocol on top of the underlying
"raw" device. The PXE code in the firmware used the "IP" device to pull
across the loader.efi, so currdev was set to "net1" when booting from the
physical interface "net0". (The loaded image's device handle referenced
the "IP" device that "net1" claimed.)
However, the IP device isn't suitable for doing raw packet I/O (and the
current code to open devices exclusively actually turns the "IP" devices
off on these systems).
To fix, change the efinet driver to only attach to "raw" devices. This
is determined by fetching the DEVICE_PATH for each handle which supports
the simple network protocol and examining the last node in the path. If
the last node in the path is a MAC address, the device is assumed to be
a "raw" device and is added as a 'netX' device. If the last node is not
a MAC address, the device is ignored.
However, this causes a new problem as the device handle associated with
the loaded image no longer matches any of the handles enumerated by
efinet for systems that load the image via the "IP" device. To handle
this case, expand the logic that resolves currdev from the loaded image
in main(). First, the existing logic of looking for a handle that
matches the loaded image's handle is tried. If that fails, the device
path of the handle that loaded the loaded image is fetched via
efi_lookup_image_devpath(). This device path is then walked from the
end up to the beginning using efi_handle_lookup() to fetch the handle
associated with a path. If the handle is found and is a known handle,
then that is used as currdev. The effect for machines that load the
image via the "IP" device is that the first lookup fails (the handle
for the "IP" device isn't claimed by efinet), but walking up the
image's device path finds the handle of the raw MAC device which is used
as currdev.
With these fixes in place, the hack to subtract 1 from the unit can now
be removed, so that setting currdev to 'net0' actually uses 'net0'.
PR: 202097
Tested by: ambrisko
Sponsored by: Cisco Systems
return value when it could return 1 (indicating we should stop).
Fix a few instances of pager_open() / pager_close() not being called.
Actually use these routines for the environment variable printing code
I just committed.
The block cache implementation in loader has proven to be almost useless, and in worst case even slowing down the disk reads due to insufficient cache size and extra memory copy.
Also the current cache implementation does not cache reads from CDs, or work with zfs built on top of multiple disks.
Instead of an LRU, this code uses a simple hash (O(1) read from cache), and instead of a single global cache, a separate cache per block device.
The cache also implements limited read-ahead to increase performance.
To simplify read ahead management, the read ahead will not wrap over bcache end, so in worst case, single block physical read will be performed to fill the last block in bcache.
Booting from a virtual CD over IPMI:
0ms latency, before: 27 second, after: 7 seconds
60ms latency, before: over 12 minutes, after: under 5 minutes.
Submitted by: Toomas Soome <tsoome@me.com>
Reviewed by: delphij (previous version), emaste (previous version)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D4713
in boot1, like is normally done. When a keyboard appears in the UEFI
device tree, assume -D -h, just like on a BIOS boot.
# It is unclear if an ACPI keyboard appearing in the tree means there's
# a real keyboard or not. A USB keyboard doesn't seem to appear unless
# it is really there.
Differential Revision: https://reviews.freebsd.org/D5223
This builds on the modular EFI loader support added r294060 adding a
module to provide ZFS boot support on EFI systems.
It should be noted that EFI uses a fixed size memory block for all
allocations performed by the loader so it may be necessary to tune this
size.
For example when building an image which uses mfs_root e.g. mfsbsd, adding
the following to /etc/make.conf would be needed to prevent EFI from running
out of memory when loading the mfs_root image.
EFI_STAGING_SIZE=128
Submitted by: Eric McCorkle
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Make EFI boot loader modular in preparation for adding ZFS support.
This is a partial commit of the D4515.
Submitted by: Eric McCorkle
Reviewed by: emaste (in part)
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4515
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
This is based on the vidconsole implementation.
Submitted by: Toomas Soome <tsoome@me.com>
Reviewed by: adrian
MFC after: 2 weeks
Relnotes: Yes
Differential Revision: https://reviews.freebsd.org/D4797
Examine each cmdline arg and if it contains an '=' convert it to ascii and
pass it to putenv(). This allows var=value settings to come in on the
command line.
This will allow overriding dhcp server-provided data in loader(8), as
discussed in PR 202098
PR: 202098
Differential Revision: https://reviews.freebsd.org/D4561
support for booting arm and arm64 from UEFI.
Differential Revision: https://reviews.freebsd.org/D2164
Reviewed by: emaste, imp (previous version)
Sponsored by: The FreeBSD Foundation
