| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
mfsroot."
This reverts commit f7a77d2d71fe340b36e1bb10a73639d463c88e52.
|
|
|
|
| |
(cherry picked from commit a98694e891ecb4b6a4eebd75ddffb6c56266fdec)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r309412 (by imp):
dd is currently a bootstrap tool. It really doesn't have any business
being a bootstrap tool. However, for reproducible build output,
FreeBSD added dd status=none because it was otherwise difficult to
suppress the status information, but retain any errors that might
happen. There's no real reason that dd has to be a build tool, other
than we use status=none unconditional. Remove dd from a bootstrap tool
entirely by only using status=none when available. This may also help
efforts to build the system on non-FreeBSD hosts as well.
r316109:
Don't hardcode input files for stage 1/2 bootloaders; use .ALLSRC instead
This is a better pattern to follow when creating the bootloaders and doing
the relevant space checks to make sure that the sizes aren't exceeded (and
thus, copy-pasting is a bit less error prone).
r316132:
Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to sys/boot/i386/zfsboot/...
This is being done to make it easier to change in the future--this action might be
needed sooner rather than later because of gcc 6.3.0 bailing, stating that there
is negative free space left (deficit) in the boot2 bootloader.
|
|
|
|
|
|
| |
Remove redundant declarations
They're already defined in libstand.h
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
List of revisions merged:
r307070
r307071
r307072
r307074
r307189
r307224
r307339
r307390
r307391
r309776
r314231
r314232
r314615
r314616
r314617
r314618
r314619
r314620
r314621
r314623
r314890
r314925
r314926
r314927
r314928
r315770
r315771
Discussed with: gjb (re), imp
Sponsored by: The FreeBSD Foundation
|
|
|
|
| |
Set the right variable when overriding the default console speed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MFC 308124:
On arm64 build the efi loader with -fPIC. Without this clang 3.9 will
generate relocation in the self relocation code.
MFC 316608:
Add -fPIC to the standalone build flags on arm64. This is needed as
loader.efi is position independend, however we were not building it as
such causing a build failure when building with lld.
MFC 315452:
Mark the EFI PE header as allocated. While ld.bfd doesn't seem to care
about not having this flag ld.lld fails to link without it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The boot1.efi immediate issue from PR216964 is that we are reading into
too small buffer, from UEFI spec 2.6:
The size of the Buffer in bytes. This must be a multiple of the intrinsic block size of the device.
The secondary issue is that LBA calculation does not check reminder from
division.
This fix does check the provided buffer size and if we read less than
media sector size or the read offset is not aligned to sector boundary,
we allocate bounce buffer and perform the read by single sector.
PR: 216964
Reported by: Sergey Kozlov
Reviewed by: allanjude, Sergey Kozlov
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D9870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r314547
loader.efi: reduce the size of the staging area if necessary
The loader assumes physical memory in [2MB, 2MB + EFI_STAGING_SIZE)
is Conventional Memory, but actually it may not, e.g. in the case
of Hyper-V Generation-2 VM (i.e. UEFI VM) running on Windows
Server 2012 R2 host, there is a BootServiceData memory block at
the address 47.449MB and the memory is not writable.
Without the patch, the loader will crash in efi_copy_finish():
see PR 211746.
The patch verifies the end of the staging area, and reduces its
size if necessary. This way, the loader will not try to write into
the BootServiceData memory any longer.
Thank Marcel Moolenaar for helping me on this issue!
The patch also allocates the staging area in the first 1GB memory.
See the comment in the patch for this.
PR: 211746
Reviewed by: marcel, kib, sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9686
r314770
loader.efi: fix recent UEFI-boot regression on physical machines
This patch fixes my recent patch
"loader.efi: reduce the size of the staging area if necessary", which
causes EFI-boot failure on physical machines since Mar 2:
on the host there is a 1MB LoaderData memory range, which splits
the big Conventional Memory range into a small one (15MB) and a
big one: the small one is too small to hold the staging area.
We can actually use the LoaderData range safely, because when
amd64_tramp -> efi_copy_finish() starts to run, we're almost at
the very end of the efi loader code and we're going to "return"
to the kernel entry, so we're pretty sure we won't access any loader
data any more.
For people who are interested in the details: please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22
PS, some people also reported the regression happened to FreeBSD VM
running on Bhyve in EFI mode. This patch should resolve it too,
though I don't have such a setup to test.
Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9904
r314828
loader.efi: fix an off-by-one bug in efi_verify_staging_size()
Also remove the warning message: it may not be unusual to see
the memory range containing 2MB is not of EfiConventionalMemory.
Sponsored by: Microsoft
r314891
loader.efi: finally fix the off-by-one bug in efi_verify_staging_size()
r314828(loader.efi: fix an off-by-one bug in efi_verify_staging_size())
doesn't really fix the bug and this patch adds the missing part.
It's a shame that I didn't make everything correct at the very beginning...
Sponsored by: Microsoft
r314956
loader.efi: only reduce the size of the staging area on Hyper-V
Doing this on physical hosts turns out to be problematic, e.g. see comment
24 and 28 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746.
To fix the real underlying issue correctly & thoroughly, IMO we need
a relocatable kernel, but that would require a lot of complicated long
term work: https://reviews.freebsd.org/D9686?id=25414#inline-56969
For now, let's only apply efi_verify_staging_size() to VMs running on
Hyper-V, and restore the old behavior on physical machines since that
has been working for people for a long period of time, though that's
potentially unsafe...
Sponsored by: Microsoft
r314962
loader.efi: only include the machine/ header files on x86
The 2 files may not exist on other archs like aarch64 and hence we
can have a build failure there.
Reported by: lwhsu
Sponsored by: Microsoft
r315235
loader.efi: use stricter check for Hyper-V
Some other hypervisors like Xen can pretend to be Hyper-V but obviously
they can't implement all Hyper-V features. Let's make sure we're genuine
Hyper-V here.
Also fix some minor coding style issues.
PR: 211746
Sponsored by: Microsoft
PR: 211746
|
|
|
|
|
|
| |
sys: Replace zero with NULL for pointers.
Found with: devel/coccinelle
|
|
|
|
|
|
|
|
|
|
| |
libstand: dosfs cstyle cleanup for return keyword.
dosfs support in libstand is broken since r298230
PR: 214423
Submitted by: Mikhail Kupchik
Reported by: Mikhail Kupchik
Approved by: imp (mentor)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make EFI_RESERVED_SERVICE a proper prototype
With clang 4.0.0, the EFI API header causes the following warning:
In file included from sys/boot/efi/loader/bootinfo.c:43:
In file included from sys/boot/efi/loader/../include/efi.h:52:
sys/boot/efi/include/efiapi.h:534:32: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
(EFIAPI *EFI_RESERVED_SERVICE) (
^
Add VOID to make it into a real prototype.
Reviewed by: imp, emaste, tsoome
Differential Revision: https://reviews.freebsd.org/D9132
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use proper prototypes in struct boot_module_t
With clang 4.0.0, we are getting the following warnings about struct
boot_module_t in efi's boot_module.h:
In file included from sys/boot/efi/boot1/ufs_module.c:41:
sys/boot/efi/boot1/boot_module.h:67:14: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
void (*init)();
^
void
sys/boot/efi/boot1/boot_module.h:92:16: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
void (*status)();
^
void
sys/boot/efi/boot1/boot_module.h:95:24: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
dev_info_t *(*devices)();
^
void
3 errors generated.
Fix this by adding 'void' to the parameter lists. No functional change.
Reviewed by: emaste, imp, smh
Differential Revision: https://reviews.freebsd.org/D9144
|
|
|
|
|
|
|
|
| |
The Makefile rule to create vers.c for loader version info was
previously duplicated in each of the various loader Makefiles.
Instead, share a common rule in Makefile.inc.
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r311888:
[efi] Fix off-by-one error in ARM .bss zeroing code in loader's _start
__bss_end should not be included in .bss zeroing code. Otherwise first 4
bytes of the section that follows .bss (in loader's case it's .sdata) are
overwritten by zero.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D9108
r311890:
[efi] Fix .rel.data.* being erroneously merged into .data on ARM
Fix section pattern code to exclude .rel.data.* sections from being
merged into .data. Otherwise relocations in those sections are lost
in final binary
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D9108
r311891:
[efi] Build EFI bits with -fPIC on ARM
clang 3.9.0 without -fPIC generates absolute jump table for
switch/case statement which trips boot1.efi and loader.efi
on ARM platform.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D9108
|
|
|
|
|
| |
Instead of repeating "%s, Revision %s" "(%s %s)" in each loader, just
create the full version string in vers.c
|
|
|
|
|
| |
GNU ld interprets the padding value as a variable-length byte string,
while GNU gold and LLVM lld interpret it as a 32-bit value.
|
|
|
|
|
| |
The fill pattern was previously an ia64 instruction sequence. Presumably
ia64's linker script was copied as a starting point.
|
|
|
|
|
|
|
| |
Fix typo in the COMPILER_VERSION check
PR: 213120
Submitted by: Yuta Satoh <nigoro.dev@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r304677:
Add tftpfs support for the EFI loader
Allow netbooting on efi without having to setup any NFS server by rebuilding the
loader with LOADER_TFTP_SUPPORT like for the i386 pxeloader
r305125:
Netboot: allow both tftpfs and nfs in both pxeboot and loader.efi
Add a new 'netproto' variable which can be set for now to
NET_TFTP or NET_NFS (default to NET_NONE)
From the dhcp options if one sets the root-path option to:
"ip:path", the loader will consider it is booting over NFS
(meaning same behaviour as the default current behaviour)
if the dhcp option "tftp server address" is set (option 150)
the loader will consider it is booting over tftpfs, it will then
consider the root-path options with 2 possible case
1. "path" then the IP of the tftp server will be the one passed by
the option 150, and the files will be retrieved under "path" on the tftp
server
2. "ip:path" then the IP of the tftp server will be the one passed in
the option "overwritting the IP from the option 150.
We could not "abuse" the rootpath option in the form or tftp://ip:path because
this is already used for other purpose by iPXE preventing any chainload from
iPXE to the FreeBSD loader.
Given at each open(), the loader loops over all available filesystems and keep
the "best" error, we needed to prevent tftpfs to fallback on nfs and vice versa.
the tftpfs and nfs implementation in libstand now return EINVAL early if
'netproto' for that purpose.
Relnotes: yes
Sponsored by: Gandi.net
|
|
|
|
| |
Simple post-mortem reporter for amd64 loader.efi.
|
|
|
|
| |
Utilize pmap.h names.
|
|
|
|
|
|
|
| |
Add double-inclusion protection.
MFC r305947:
Add comment for the closing guard.
|
|
|
|
|
|
| |
reproducible builds
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
| |
loader.efi: Bump the staging size to 64M.
This is required on my system, which loads nvidia, vmm, and zfs, and 48M is
no longer enough for that. nvidia-driver's recent update increased its size
by several megabytes.
|
|
|
|
|
|
|
|
|
| |
Don't set *dev in the zfs root case, it may be NULL and will correctly be
set later in the function. This fixes a potential NULL pointer dereference
found on arm64.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
|
|
|
|
| |
Only use WaitForKeys event if it exists, this is not the case in u-boot efi implementation.
|
|
|
|
|
|
|
| |
Use %ju modifier for u_int64_t and %jd modifier for off_t.
off_t is long long on arm32 and long on amd64
Correctly print and cast u_int64_t and off_t.
|
|
|
|
|
|
|
|
| |
Some defines needed for exporting serial numbers from the SMBIOS were
missed during integration of SMBIOS support in the EFI boot loader (r281138).
This is needed for getting the hostid set from the system hardware UUID.
PR: 206031
|
|
|
|
|
|
|
| |
Do not use TERM_EMU on arm and arm64 as it doesn't behave
well with serial console.
Approved by: re (gjb)
|
|
|
|
|
|
|
| |
PR: 210706
Submitted by: David Binderman <dcb314@hotmail.com>
Approved by: re (kib)
MFC after: 1 week
|
|
|
|
|
|
|
| |
reported by EFI implementation. This address comment on r301714.
Approved by: re (gjb), andrew (mentor)
Differential Revision: https://reviews.freebsd.org/D6787
|
|
|
|
|
| |
Approved by: andrew (mentor)
Differential Revision: https://reviews.freebsd.org/D6782
|
|
|
|
|
|
| |
e.g. on the command line.
Sponsored by: ABT Systems Ltd
|
|
|
|
|
|
| |
disabled. Without this we print all lines over top of each other.
Sponsored by: ABT Systems Ltd
|
|
|
|
|
|
|
|
|
|
| |
where we assumed TERM_EMU was defined but didn't check. Fix these by also
including them under the ifdefs.
As HO is called from loader we need a null implementation so loader.efi
doesn't need to know which version of libefi it is building against.
Sponsored by: ABT Systems Ltd
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
directly pass the request otherwise use a buffer that is a
multiple of the media size. This speeds up I/O quite a bit
when using large transfer sizes on 4Kn disks etc.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
While here, fix the various net driver callbacks to return early instead
of crashing if this fails. (The 'init' callback from the netif interface
doesn't return an error if the protocol lookup fails.)
Sponsored by: Cisco Systems
|
| |
|
| |
|
|
|
|
|
|
|
| |
These efipart layer did several devpath related operations inline. This
just switches it over to using shared code for working with device paths.
Sponsored by: Cisco Systems
|
|
|
|
|
|
|
|
| |
Lookup the DEVICE_PATH for each EFI network device handle and output the
string description using printf with '%S'. To honor the pager, the newline
at the end of each line is still output with pager_output().
Sponsored by: Cisco Systems
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- efi_lookup_devpath() uses the DEVICE_PATH_PROTOCOL to obtain the
DEVICE_PATH for a given EFI handle.
- efi_lookup_image_devpath() uses the LOADED_IMAGE_DEVICE_PATH_PROTOCOL
to lookup the device path of the device used to load a loaded image.
- efi_devpath_name() uses the DEVICE_PATH_TO_TEXT_PROTOCOL to generate
a string description of a device path. The returned string is a CHAR16
string that can be printed via the recently added '%S' format in
libstand's printf(). Note that the returned string is returned in
allocated storage that should be freed by calling
efi_free_devpath_name().
- efi_devpath_last_node() walks a DEVICE_PATH returning a pointer to the
final node in the path (not counting the terminating node). That is,
it returns a pointer to the last meaninful node in a DEVICE_PATH.
- efi_devpath_trim() generates a new DEVICE_PATH from an existing
DEVICE_PATH. The new DEVICE_PATH does not include the last
non-terminating node in the original path. If the original DEVICE_PATH
only contains the terminating node, this function returns NULL.
The caller is responsible for freeing the returned DEVICE_PATH via
free().
- efi_devpath_handle() attempts to find a handle that corresponds to a
given device path. However, if nodes at the end of the device path do
not have valid handles associated with them, this function will return
a handle that matches a node earlier in the device path. In particular,
this function returns a handle for the node closest to the end of the
device path which has a valid handle.
Sponsored by: Cisco Systems
|
|
|
|
|
|
| |
Silence a format specifier warning.
Sponsored by: EMC / Isilon Storage Division
|
|
|
|
|
| |
linger). We now print only printable characters for the
values and we print ascii strings as strings.
|
| |
|
| |
|
|
|
|
| |
without error at the end.
|