path: root/stand/efi
Commit message (Collapse)AuthorAgeFilesLines
* stand/efi: add modulep to kernel metadataRoger Pau Monné2021-02-161-3/+6
| | | | | | | | | | | | | | This mirrors the functionality of the BIOS amd64 bi_load function, that stashes the absolute address of the module metadata. This is required for booting as a Xen dom0 that does relocate the modulep and the loaded modules, and thus requires adjusting the offset. No functional change introduced, further patches will make use of this functionality for Xen dom0 loading. Sponsored by: Citrix Systems R&D Reviewed by: imp Differential revision: https://reviews.freebsd.org/D28496
* stand/efi: allow not exiting boot servicesRoger Pau Monné2021-02-166-14/+20
| | | | | | | | | | | | | | | | | | Xen requires that UEFI BootServices are enabled in order to boot, so introduce a new parameter to bi_load in order to select whether BS should be exited. No functional change introduced in this patch, as all current users of bi_load request BS to be exited. Further changes will make use of this functionality. Note the memory map is still appended to the kernel metadata, even when it could be modified by further calls to the Boot Services, as it will be used to detect if the kernel has been booted from UEFI. Sponsored by: Citrix Systems R&D Reviewed by: tsoome, imp Differential revision: https://reviews.freebsd.org/D28495
* loader.efi: There are systems without ConOut, also use ConOutDevToomas Soome2021-02-041-0/+2
| | | | | | | | Conout does contian the default output device name. ConOutDev does contain all possible output device names, so we can use it as fallback, when there is no ConOut. PR: 253253
* loader: create built in font from bold font faceToomas Soome2021-01-231-1/+1
| | | | | We did replace full version of default font 8x16v with bold, also use bold version for built in font.
* loader: Use TERM_EMU for arm and arm64Emmanuel Vadot2021-01-171-3/+0
| | | | | | | | | | Even if it didn't behave well previously this is fixed. Tested on: OrangePi One (armv7 u-boot) (serial only and serial + HDMI) Tested on: Pine64-LTS (aarch64 u-boot) (serial only and serial + HDMI) Tested on: Honeycomb (aarch64 EDK2) (serial only) Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D28153
* loader.efi: commands gop, uga and autoresize should use cached dataToomas Soome2021-01-171-30/+17
| | | | | We are setting up pointers for gop or uga protocol in efi_find_framebuffer(), reuse those pointers.
* loader.efi: variable 'hlist' is uninitializedToomas Soome2021-01-171-0/+1
| | | | framebuffer.c:481:65: error: variable 'hlist' is uninitialized
* loader.efi: unused variable 'mode'Toomas Soome2021-01-171-1/+0
| | | | | framebuffer.c:707:8: error: unused variable 'mode' [-Wunused-variable] u_int mode;
* loader.efi: handle multiple gop instancesToomas Soome2021-01-161-1/+36
| | | | | | | | Some systems may provide multiple GOP instances and not all are bound to hardware. The current loader is picking up the first GOP, which may not be usable. Instead we load the GOP handle array, and test every handle to have registered ConOut protocol. If ConOut is present, we can use this GOP handle to open GOP protocol.
* Revert "loader.efi: disable workaround for serial console on non-x86"Toomas Soome2021-01-131-4/+0
| | | | | | This patch is creating some issues, reverting it. This reverts commit 8b18395487506d3602205e5844e0b67ba0c0dc80.
* loader.efi: initial terminal size should base on UEFI terminal sizeToomas Soome2021-01-131-6/+6
| | | | | | We do select font based on desired terminal size, we do query UEFI terminal size with conout->QueryMode(), but by mistake, the fallback values are used.
* loader.efi: disable workaround for serial console on non-x86Toomas Soome2021-01-121-0/+4
| | | | | As efi console is drawn and with functional comconsole driver, we can use proper terminal emulator on efi framebuffer console.
* loader.efi: reworked framebuffer setupToomas Soome2021-01-126-63/+90
| | | | | | | | | | | | | | Pass gfx_state to efi_find_framebuffer(), so we can pick between GOP and UGA in efi_find_framebuffer(), also we can then set up struct gen_fb in gfx_state from efifb and isolate efi fb data processing into framebuffer.c. This change does allow us to clean up efi_cons_init() and reduce BS->LocateProtocol() calls. A little downside is that we now need to translate gen_fb back to efifb in bootinfo.c (for passing to kernel), and we need to add few -I options to CFLAGS.
* loader.efi: efifb_mask_from_pixfmt is missing PixelBltOnlyToomas Soome2021-01-111-0/+1
| | | | We are missing way to set RGB masks for BLT only framebuffer.
* loader: term_image_display() should test screen_bufferToomas Soome2021-01-101-0/+3
| | | | Make sure screen_buffer is not NULL.
* loader: implement framebuffer consoleToomas Soome2021-01-027-175/+361
| | | | | | | | | | | | | | | | | | | | | | | Draw console on efi. Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list, vbe set xxx). autoload font (/boot/fonts) based on resolution and font size. Add command loadfont (set font by file) and variable screen.font (set font by size). Pass loaded font to kernel. Export variables: screen.height screen.width screen.depth Add gfx primitives to draw the screen and put png image on the screen. Rework menu draw to iterate list of consoles to enamble device specific output. Probably something else I forgot... Relnotes: yes Differential Revision: https://reviews.freebsd.org/D27420
* efi loader: fix typos in a commentEric van Gyzen2021-01-011-4/+4
| | | | | | ...mostly because it's a harmless way to try the shiny new git repo. Sponsored by: Dell EMC Isilon
* stand: properly declare subdir deps or .WAIT, do parallel buildKyle Evans2020-12-311-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | buildworld already runs the stand build in parallel[1], so make it easier to identify ordering issues by properly establishing dependencies or adding .WAIT where needed. Everything in stand/ relies on libsa, either directly or indirectly, because libsa build is where the stand headers get installed and it gets linked in most places. Interpreters depend on their libs, machine dirs usually depend on top-level libs that are getting built and at least one of the interpreter flavors. For i386, order btx/libi386/libfirewire before everything else using a big-ol-.WAIT hammer. btx is the most common dependency, but the others are used sporadically. This seems to be where the race reporting on the mailing list is- AFAICT, the following sequence is happening: 1.) One of the loaders gets built based on stale btx/btxldr 2.) btx/btxldr gets rebuilt 3.) installworld triggers loader rebuild because btx was rebuilt after This seems like the most plausible explanation, as they've verified system time and timestamps. While we're here, let's switch stand/ over to a completely parallel build so we can work out these kinds of issues in isolation rather than in the middle of a larger build. Reviewed by: bdragon, sjg, tsoome Tested by: bdragon (-j1024, no failures, significant speed improvement) Differential Revision: https://reviews.freebsd.org/D23411
* Drop EFI_STAGING_SIZE back down to 64MWarner Losh2020-12-171-3/+1
| | | | | | | | | | | vmware can't cope with anything larger than 64MB. Drop this back to 64MB everywhere but arm. PR: 251866 MFC After: 1 week Notes: svn path=/head/; revision=368721
* loader: Ignore the .interp section on RISC-VJessica Clarke2020-12-141-0/+1
| | | | | | | | | | | | | | Without this we risk having the .interp section be placed earlier in the file and mess with section offsets; in particular it has been seen to be placed at the start of the file and cause the PE/COFF header to not be at address 0. This is the same fix as was done for arm64 in r365578. Reviewed by: mhorne, imp Approved by: mhorne, imp Differential Revision: https://reviews.freebsd.org/D27603 Notes: svn path=/head/; revision=368626
* Unobfuscate "KERNLOAD" parameter on amd64. This change lines-up amd64 with theMaxim Sobolev2020-11-251-5/+3
| | | | | | | | | | | | | | | | | i386 and the rest of supported architectures by defining KERNLOAD in the vmparam.h and getting rid of magic constant in the linker script, which albeit documented via comment but isn't programmatically accessible at a compile time. Use KERNLOAD to eliminate another (matching) magic constant 100 lines down inside unremarkable TU "copy.c" 3 levels deep in the EFI loader tree. Reviewed by: markj Approved by: markj MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D27355 Notes: svn path=/head/; revision=368041
* Add 'netserver' command to EFI loader.Michal Meloun2020-10-141-0/+35
| | | | | | | | | | | | | | | | | | In some environments is difficult to access bootp/dhcp configuration as "standard user". Add a command that allows to set or display the URI of the network server used as "net:" device. Currently only tftp and nfs protocols are supported. Typical usage pattern is: netserver tftp:// boot net:kernel Reviewed by: imp, kevans MFC after: 4 weeks Differential Revision: https://reviews.freebsd.org/D26736 Notes: svn path=/head/; revision=366700
* Use adrp in the arm64 efi loaderAndrew Turner2020-10-131-5/+10
| | | | | | | | | | | | | | | | | On startup the arm64 efi loaders need to know PC-relative addresses. Previously we used the adr instruction to find this address, however this instruction is limited to +/- 1MiB. Switch to adrp to find the 4k page the address is within and an add to set the bottom 12 bits. This lets us address +/- 4GiB which should be large enough for now. Reported by: imp MFC after: 2 weeks Sponsored by: Innovate UK Notes: svn path=/head/; revision=366670
* Add zstd support to the boot loader.Warner Losh2020-10-121-0/+1
| | | | | | | | | | | | | | | Add support to the _STANDALONE environment enough bits of the kernel that we can compile it. We still have a small zstd_shim.c since there were 3 items that were a bit hard to nail down and may be cleaned up in the future. These go hand in hand with a number of commits to sys/sys in the past weeks, should this need be MFCd. Discussed with: mmacy (in review and on IRC/Slack) Reviewed by: freqlabs (on openzfs repo) Differential Revision: https://reviews.freebsd.org/D26218 Notes: svn path=/head/; revision=366657
* Link efi programs with -pie rather than -sharedAlex Richardson2020-10-122-2/+2
| | | | | | | | | | | This was causing build failures in CheriBSD where we were passing -pie already by default. Reviewed By: andrew Differential Revision: https://reviews.freebsd.org/D24787 Notes: svn path=/head/; revision=366644
* Fix video on PCI heuristicWarner Losh2020-09-281-2/+4
| | | | | | | | | | | | | | | | | | The video on PCI heuristic was broken. It was supposed to infer a video device when the last element of the path was a PCI DEVICE PATH node. However, the last node in the device path is an END node, so this heuristic never fired. This leads, among other things, to bhyve only producing output in the serial connection once we leave the boot loader. This restores the dual headed boot on bhyve + UEFI (as we did in 11.2), but will favor serial in the absence of other config which may be a change from 11.2. MFC After: 3 days Differential Revision: https://reviews.freebsd.org/D26572 Notes: svn path=/head/; revision=366216
* loader: fix non-zfs buildToomas Soome2020-09-231-0/+2
| | | | | | | | | We can not include zfs headers while building without zfs. Reported by: Oscar Holmlund Notes: svn path=/head/; revision=366087
* loader: zfs_probe_dev should pick first matching zfs poolToomas Soome2020-09-231-1/+2
| | | | | | | | | | | | | | | | | | During devswitch probe, we pick boot pool based on boot disk, if the boot disk happens to have multiple pools in freebsd-zfs partitions, the current code does pick last pool from boot disk as boot pool. While there is no way at that stage to test, the more logical approach would be to pick first matching pool. This patch is assuming we do pass pool guid pointer with guid value 0, this will help us to determine, if the guid value is already set or not. The general suggestion would be not to share disk between different pools. Reported by: Alexander Leidinger Notes: svn path=/head/; revision=366066
* loader: zfs should support bootonce an nextbootToomas Soome2020-09-214-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bootonce feature is temporary, one time boot, activated by "bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag. By default, the bootonce setting is reset on attempt to boot and the next boot will use previously active BE. By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will be set permanently active. bootonce dataset name is recorded in boot pool labels, bootenv area. in case of nextboot, the nextboot_enable boolean variable is recorded in freebsd:nvstore nvlist, also stored in boot pool label bootenv area. On boot, the loader will process /boot/nextboot.conf if nextboot_enable is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf processing on next boot. bootonce and nextboot features are usable in both UEFI and BIOS boot. To use bootonce/nextboot features, the boot loader needs to be updated on disk; if loader.efi is stored on ESP, then ESP needs to be updated and for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated (gpart or other tools). At this time, only lua loader is updated. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25512 Notes: svn path=/head/; revision=365938
* Only set WARNS if not definedKyle Evans2020-09-112-2/+2
| | | | | | | | | | | | | This would allow interested parties to do experimental runs with an environment set appropriately to raise all the warnings throughout the build; e.g. env WARNS=6 NO_WERROR=yes buildworld. Not currently touching the numerous instances in ^/tools. MFC after: 1 week Notes: svn path=/head/; revision=365631
* Ignore the .interp section in the arm64 EFI loaderAndrew Turner2020-09-101-0/+1
| | | | | | | | | | | | When building the loader an unneeded .interp section may be added. Move this to the unused section region so offsets of used sections don't change. Obtained from: CheriBSD Sponsored by: Innovate UK Notes: svn path=/head/; revision=365578
* stand/efihttp: Work around a bug in edk2 http instance reconfigurationD Scott Phillips2020-09-091-0/+16
| | | | | | | | | | | | | | | | | | | A bug in the EFI HTTP driver of TianoCore EDK2 causes memory corruption when an http instance that uses tls is reconfigured, leading to a crash. Work around this by forcing a new http instance for each request instead of reconfiguring the existing one. The upstream bug report is https://bugzilla.tianocore.org/show_bug.cgi?id=1917 Submitted by: bcran Reviewed By: imp, kevans, tsoome MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D21281 Notes: svn path=/head/; revision=365505
* Quiet int-to-pointer-cast warnings on i386 with GCC 9.John Baldwin2020-09-041-2/+2
| | | | | | | | Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D26200 Notes: svn path=/head/; revision=365318
* zfs: add an option to the bootloader to rewind the ZFS checkpointMariusz Zaborski2020-08-181-1/+1
| | | | | | | | | | | | | | | | | | The checkpoints are another way of keeping the state of ZFS. During the rewind, the pool has to be exported. This makes checkpoints unusable when using ZFS as root. Add the option to rewind the ZFS checkpoint at the boot time. If checkpoint exists, a new option for rewinding a checkpoint will appear in the bootloader menu. We fully support boot environments. If the rewind option is selected, the boot loader will show a list of boot environments that existed before the checkpoint. Reviewed by: tsoome, allanjude, kevans (ok with high-level overview) Differential Revision: https://reviews.freebsd.org/D24920 Notes: svn path=/head/; revision=364355
* loader: Avoid -Wpointer-to-int cast warnings for Arm and RISC-VJessica Clarke2020-07-262-2/+2
| | | | | | | | | | | | | | | | | On RISC-V, Clang warns with: cast to smaller integer type 'unsigned int' from 'void (*)(void *)' Instead, use %p as the standard format specifier for printing pointers. Whilst Arm's pointer size is the same as unsigned, it's still cleaner to use the right thing there too. Reviewed by: brooks (mentor), emaste Approved by: brooks (mentor), emaste Differential Revision: https://reviews.freebsd.org/D25718 Notes: svn path=/head/; revision=363572
* Revert that!Simon J. Gerraty2020-07-191-5/+0
| | | | Notes: svn path=/head/; revision=363351
* Oops missed Makefile.configSimon J. Gerraty2020-07-191-0/+5
| | | | Notes: svn path=/head/; revision=363350
* RISC-V boot1.efi and loader.efi supportMitchell Horne2020-07-068-4/+581
| | | | | | | | | | | | | | | | | | | | | This implementation doesn't have any major deviations from the other EFI ports. I've copied the boilerplate from arm and arm64. I've tested this with the following boot flows: OpenSBI (M-mode) -> u-boot (S-mode) -> loader.efi -> FreeBSD OpenSBI (M-mode) -> u-boot (S-mode) -> boot1.efi -> loader.efi -> FreeBSD Due to the way that u-boot handles secondary CPUs, OpenSBI >= v0.7 is required, as the HSM extension is needed to bring them up explicitly. Because of this, using BBL as the SBI implementation will not be possible. Additionally, there are a few recent u-boot changes that are required as well, all of which will be present in the upcoming v2020.07 release. Looks good: emaste Differential Revision: https://reviews.freebsd.org/D25135 Notes: svn path=/head/; revision=362973
* boot1.efi: use malloc family from libsaToomas Soome2020-06-301-36/+16
| | | | | | | | | | | | | | | The zfs reader development did reach to the point where linking boot1, we will get errors about duplicate symbols Malloc, Free, Calloc. We can just use libsa version, just as loader.efi does. The only concern is, libsa zalloc is using fixed size heap region, I did pick 64MB as other stage instances are using, but this size is likely not optimal. In any case, with limited memory setups, we should boot loader.efi directly. Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=362812
* stand: remove redundant declarationsKyle Evans2020-06-232-1/+1
| | | | | | | | | | | | | These are picked out by the amd64-gcc6 build; time() is declared in <time.h> and delay() is declared in <bootstrap.h>. These are the correct places for these in stand/, so remove the duplicate declarations and make sure the delay() consumer in libefi that depended on the extra delay() declaration includes <bootstrap.h>. MFC after: 1 week Notes: svn path=/head/; revision=362564
* Revert r362466Baptiste Daroussin2020-06-221-2/+2
| | | | | | | | | Such change should not have happen without prior discussion and review. With hat: transitioning core Notes: svn path=/head/; revision=362488
* Improve wording to be more precise and clear.Hans Petter Selasky2020-06-211-2/+2
| | | | | | | | | | | | No functional change intended. s/Master Boot/Main Boot/ (also called MBR) MFC after: 1 week Sponsored by: Mellanox Technologies Notes: svn path=/head/; revision=362466
* loader: create single zfs nextboot implementationToomas Soome2020-06-202-1/+16
| | | | | | | | | | | | | | | | | | | | We should have nextboot feature implemented in libsa zfs code. To get there, I have created zfs_nextboot() implementation based on two sources, our current simple textual string based approach with added structured boot label PAD structure from OpenZFS. Secondly, all nvlist details are moved to separate source file and restructured a bit. This is done to provide base support to add nvlist add/update feature in followup updates. And finally, the zfsboot/gptzfsboot disk access functions are swapped to use libi386 and libsa. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25324 Notes: svn path=/head/; revision=362431
* loader.efi: update console after gfx mode changeToomas Soome2020-06-141-0/+3
| | | | | | | The gfx mode change should be coordinated with console setup. Notes: svn path=/head/; revision=362174
* Fix the efi serial console in the Arm models.Andrew Turner2020-06-101-12/+9
| | | | | | | | | | | | | | | | | On some UEFI implementations the ConsOut EFI variable is not a device path end type so we never move to the next node. Fix this by always incrementing the device path node pointer, with a sanity check that the node length is large enough so no two nodes overlap. While here return failure on malloc failure rather than a NULL pointer dereference. Reviewed by: tsoome, imp (previous version) Sponsored by: Innovate UK Differential Revision: https://reviews.freebsd.org/D25202 Notes: svn path=/head/; revision=362008
* gptboot.efi: align secbuf to 4KMitchell Horne2020-06-031-1/+1
| | | | | | | | | | | | | | | | The u-boot EFI implementation of the ReadBlocks and WriteBlocks methods requires that the provided buffer meet the IO alignment requirements of the underlying disk. Unlike loader.efi, gptboot.efi doesn't check this requirement, and therefore fails to perform a successful read. Adjust secbuf's alignment to 4K in hopes that we will always meet this requirement. Reviewed by: imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D25111 Notes: svn path=/head/; revision=361754
* Remove tests for obsolete compilers in the build systemEric van Gyzen2020-05-123-14/+0
| | | | | | | | | | | | | | Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree. Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions for older compilers. Reviewed by: imp (earlier version), emaste, jhb MFC after: 2 weeks Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D24802 Notes: svn path=/head/; revision=360964
* Fix the EFI_DEBUG case, prio_str is only used when EFI_DEBUG is unset.Andrew Turner2020-05-051-0/+2
| | | | | | | Sponsored by: Innovate UK Notes: svn path=/head/; revision=360655
* As with r352446 align blocks in boot1.efiAndrew Turner2020-05-051-5/+5
| | | | | | | | | | | | We need to ensure the buffers are aligned before passing them to ReadBlocks. Assume 512 bytes is enough for now. Reviewed by: imp MFC after: 1 month Sponsored by: Innovate UK Notes: svn path=/head/; revision=360654
* Stop setting PG_U in bootstrap mappings.Mark Johnston2020-04-241-3/+3
| | | | | | | | | | | | | | These mappings are never visible to userspace as they get replaced when the amd64 pmap is bootstrapped, but there is no need to set PG_U in the first place. Reviewed by: alc, kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D24547 Notes: svn path=/head/; revision=360260