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.
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.
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
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
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.
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
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
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
Simplify the code a bit and rework how we report the results
of the probing.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20537
BootServices AllocatePool/FreePool calls. They are simpler to use and
result in the same thing happening.
Reviewed by: tsoome@
Differential Revision: https://reviews.freebsd.org/D20540
This is like efi_devpath_match, but allows differing device media
paths. Those just specify the partition information.
Differential Revision: https://reviews.freebsd.org/D20513
looping over the filesystem modules rather than doing a malloc + free
each time through the loop. In addition, nothing changes from loop to
loop, so setup the new devinfo outside the loop as well.
