The gfx_fb_drawrect() is drawing rectangle by pixels, this can be very
slow on some systems. Use Blt() video fill primitive instead.
Testing done: Tested on mac mini 2012 where the issue was revealed
Reviewed by: yuripv
MFC after: 1 week
There is no need to call it evert 10ms when we need 1s granularity.
Update to update the time every second.
Reviewed by: imp, manu, tsoome
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D30227
According to comments in the Makefile, to make pxeboot work we need to
have crt0.o first. This is needed because the simplified loader in
pxeboot assumes that the startup code is at offset 0 in this binary. In
normal booting, the start address can be obtained from headers of the
binary, but since pxeboot encodes this as a pure binary, it has no way
of knowing where that is and assumes 0. Added comments to that effect
in the Makefile.
We've done this by adding it to OBJS before all the other .o's are
added. However, there's a problem. This also adds it to the CLEANFILES
variable, which causes it to be removed from multiple places. The
dependencies may also cause it to be re-built at a time that's after
boot2 is built. This causes installs to fail because at install time
boot2 is considered to be out of date and the programs to rebuild it are
no longer in the path.
Cope with this problem by just adding it to LDFLAGS instead.
Glanced at by: kevans ("I thought that went in ages ago")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28876
When VECTX is enabled as a kernel option and non-EFI loaders are
built, many reads will fail due to the mis-match of whether
LOADER_VERIEXEC_VECTX or not in readin.h. Source that includes
bootstrap.h must ensure the kernel option agrees with the compile
time CFLAGS in the various make related files.
Submitted by: bret_ketchum@dell.com (original revision)
Reviewed by: sjg, bdrewery, dab, bret_ketchum@dell.com
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29993
As we output spaces around the menu title, we should also check,
if the title is actually empty string.
PR: 255299
Submitted by: Jose Luis Duran
Reported by: Jose Luis Duran
MFC after: 1 week
Until now, the boot image can be embedded into the loader with
/sys/tools/embed_mfs.sh, and memory disk (MD) is already supported
in loader source. But due to memory disk (MD) driver isn't registered
to the loader yet, the boot image can't be boot from embedded memory
disk.
Reviewed by: dab, tsoome
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D29512
Add a man page for gptboot.efi. Describe when and how to use this as it differs
from the BIOS cases. Include cross reference for the preferred method described
in efibootmgr(8) as well as cross links in both gptboot(8) and gptboot.efi(8) to
the other.
This man page was heavily copied from the gptboot.8 man page by Warren Block.
They are different enough to need separate man pages for clarity, but there's
enough similarity that I worry about the duplication. In the really long term,
gptboot(8) will disappear, so having the same info here will help when that
day comes. In the short to medium term, the information is likely to not
change in gptboot(8) and any changes to gptboot.efi(8) will be easier to
make in a separate copy.
loader.efi(8) needs a complete rewrite from scratch, otherwise I'd have
referenced gptboot.efi(8) from there.
Suggetions from: cress@, mhorne@
Reviewed by: rpokala@
Differential Revision: https://reviews.freebsd.org/D29591
Add a dummy vendor menu entry on the main welcome menu. Vendors can override
this in their local.lua file to create whatever sub-menu they need for their
products.
Also fix the adding a 'welcome' entry as well based on a suggestion from Kyle.
Silly option menu code also from Kyle. They seem to work for me, but any
transcription error is likely mine.
Reviewed by: kevans@ (the vendor stuff)
LLVM12 complains if you change the symbol binding:
`error: _longjmp changed binding to STB_GLOBAL`
In this case LLVM actually ignored the weak directive and used the
later .global, but GNU as would mark the symbol as weak.
None of the other architectures mark the libsa _setjmp as weak so
just drop this directive.
This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standard library with GCC.
This flag was originally added in back in r94332 but the flag is a no-op
in Clang ("This diagnostic flag exists for GCC compatibility, and has no
effect in Clang"). Removing it should make the GCC build output slightly
more readable.
Reviewed By: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D29235
When drawing cursor, we should store original display
content because there may be image data we would like to restore
when the cursor is removed.
PR: 254054
Reported by: Jose Luis Duran
MFC after: 3 days
This makes bi_load_efi_data cleaner to add common acpi setup code.
Reviewed by: imp, tsoome
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28936
Parentheses added to HASZERO macro to avoid a GCC warning, and formatted
with clang-format as we have adopted these and don't consider them
'contrib' code.
Obtained from: musl (snapshot at commit 4d0a82170a25)
Reviewed by: kib (libc integration), mjg (both earlier)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17630
Calculate font size from 16 density independent pixels (dp) by using:
size = 16 * ppi/160 * display_factor
We are specifying font size 16dp, and assuming 1dp = 160ppi.
Also apply scaling factor 2 (display_factor).
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28849
MIPS BERI boot loader is built with -mno-abicalls and -fno-pic
so prevent adding PIE-related build flags.
Fix build after 9a227a2fd6 ("Enable PIE by default on 64-bit architectures")
Obtained from: Semihalf
Sponsored by: Stormshield
Bootloaders for powerpc are not built as position independent
code. Since bsd.prog.mk is used for building, when PIE is enabled,
the PIE flags are added and that causes the build to fail.
Adding MK_PIE=no stops bsd.prog.mk from adding PIE specific flags.
Submitted by: Dawid Gorecki <dgr@semihalf.com>
Reviewed by: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D28893
When performing buildworld for MIPS with PIE enabled, the build fails
with "position-independent code requires '-mabicalls'" message.
-mno-abicalls and -fno-pic flags are explicitly set in MIPS ubldr
makefile, so to work around this problem, set MK_PIE=no for MIPS
ubldr.
Submitted by: Dawid Gorecki <dgr@semihalf.com>
Reviewed by: emaste
Obtained from: Semihalf
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D28370
Check whether we have reached the end of the buffer using search_size
instead of MULTIBOOT_SEARCH, which is the maximum defined by the
specification, but the file can be shorter than that.
This prevents printing a harmless error message when loading a file
that is smaller than MULTIBOOT_SEARCH.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Fixes: adda2797eb ('stand/multiboot2: add support for booting a Xen dom0 in UEFI mode')
Add a missing space in one error message.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Fixes: adda2797eb ('stand/multiboot2: add support for booting a Xen dom0 in UEFI mode')
If we start with console set to comconsole, the local
console (vidconsole, efi) is never initialized and attempt to
use the data can render the loader hung.
Reported by: Kamigishi Rei
MFC after: 3 days
Notable upstream changes:
778869fa1 Fix reporting of mount progress
e7adccf7f Disable use of hardware crypto offload drivers on FreeBSD
03e02e5b5 Fix checksum errors not being counted on repeated repair
64e0fe14f Restore FreeBSD resource usage accounting
11f2e9a49 Fix panic if scrubbing after removing a slog device
MFC after: 2 weeks
Do not attempt to add MODINFOMD_MODULEP to the kernel medatada on
arches that don't have it defined.
This fixes the build for arches different than amd64 after
7d3259775c.
Sponsored by: Citrix Systems R&D
Reported by: lwhsu, arichardson
Add some basic multiboot2 infrastructure to the EFI loader in order to
be capable of booting a FreeBSD/Xen dom0 when booted from UEFI.
Only a very limited subset of the multiboot2 protocol is implemented
in order to support enough to boot into Xen, the implementation
doesn't intend to be a full multiboot2 capable implementation.
Such multiboot2 functionality is hooked up into the amd64 EFI loader,
which is the only architecture that supports Xen dom0 on FreeBSD.
The options to boot a FreeBSD/Xen dom0 system are exactly the same as
on BIOS, and requires setting the xen_kernel and xen_cmdline options
in loader.conf.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28497
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
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
While I was there:
- Fix some typos
- Fix an excessive argument "indent" reported by mandoc -Tlint
- Replace a dead link with the one suggested by
https://www.uefi.org/uefi
Submitted by: linimon (in part)
Reviewed by: bcr
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27774
We use ascii box chars with serial console because we do not know
if terminal can draw unixode box chars. Same problem is about userboot
console.
MFC after: 5 days
The VT screen buffer size is calculated based on our default
built in (8x16) font.
With high-resolution display, we want to use at least 8x16 font,
or we will have large unused areas on screen.
MFC after: 1 week
BORDER_PIXELS is left over from picking up the source from illumos
port. Since FreeBSD VT does not use border in terminal size
calculation, there is no reason why should loader use it.
MFC after: 1 week
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
All callers of bi_load64 pass 0 as the addr parameter, so just remove
it and always calculate the last load address from the module chain.
No functional change.
Sponsored by: Citrix Systems R&D
Reviewed by: tsoome, imp
Differential revision: https://reviews.freebsd.org/D28412
According to the Lua 5.4 manual section 6.4.1 ("Patterns"), the interaction
between ranges and classes is not defined and hyphens must be specified at
either the beginning or the end of a set if they are not escaped.
Move all such occurrences to the beginning.
Reported-by: _parv (twitter)
MFC-after: 3 days
This eliminates a lot of stat() calls that happen when lualoader renders the
menu with the default settings, and greatly speeds up rendering on my
laptop.
ftype is nil if loader/loader.efi hasn't been updated yet, falling back to
lfs.attributes() to test.
This is technically incompatible with lfs, but not in a particularly
terrible way.
Reviewed-by: cem
MFC-after: 4 days
Differential Revision: https://reviews.freebsd.org/D27542
There's a currently ad-hoc protocol to hand off the FreeBSD kernel
payload between the loader and the kernel itself when Xen is in the
middle of the picture. Such protocol wasn't very resilient to changes
to the loader itself, because it relied on moving metadata around to
package it using a certain layout. This has proven to be fragile, so
replace it with a more robust version.
The new protocol requires using a xen_header structure that will be
used to pass data between the FreeBSD loader and the FreeBSD kernel
when booting in dom0 mode. At the moment the only data conveyed is the
offset of the start of the module metadata relative to the start of the
module itself.
This is a slightly disruptive change since it also requires a change
to the kernel which is contained in this patch. In order to update
with this change the kernel must be updated before updating the
loader, as described in the handbook. Note this is only required when
booting a FreeBSD/Xen dom0. This change doesn't affect the normal
FreeBSD boot protocol.
This fixes booting FreeBSD/Xen in dom0 mode after
3630506b9d.
Sponsored by: Citrix Systems R&D
MFC after: 3 days
Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D28411
This is all code only run on ARMv4 and ARMv5. Support for these have
been dropped from FreeBSD.
Differential Revision: https://reviews.freebsd.org/D28314
While loading kernel, we check if vt/vbe backend support is included in
kernel and set the tg_kernel_supported flag in gfx_state. unload
command needs to reset this flag to allow next load to perform
this check with new kernel.
Reported by: jhb
On i386, after 6c7a932d0b, the vbefb vt
driver was no longer detected by the loader, if any kernel module was
loaded after the kernel itself.
This was caused by the parse_vt_drv_set() function being called multiple
times, resetting the detection flag. (It was called multiple times,
becuase i386 .ko files are shared objects like the kernel proper, while
this is not the case on amd64.)
Fix this by skipping the set_vt_drv_set lookup if vbefb was already
detected.
Reviewed by: tsoome
efi, like the various ${MACHINE} directories, should have a dependency on
the enabled interpreters.
The general rule here is that any top-level directory that has a program at
any depth within that includes loader.mk should add ${INTERP_DEPENDS} added
to its dependencies so that the appropriate ficl/lua bits are ready before
they begin.
Note that the only directories in-tree that require it but will not get it
in a more appropriate manner are i386 (on amd64), efi, and userboot. i386
and userboot are handled explicitly in Makefile.amd64 where they are added
to S.yes.
Reported-by: bcran
MFC-after: 3 days
lualoader was previously not processing \ as escapes; this commit fixes
that and does better error checking on the value as well.
Additionally, loader.conf had some odd restrictions on values that make
little sense. Previously, lines like:
kernel=foo
Would simply be discarded with a malformed line complaint you might not
see unless you disable beastie.
lualoader tries to process these as well as it can and manipulates the
environment, while forthloader did minimal processing and constructed a
`set` command to do the heavy lifting instead. The lua approach was
re-envisioned from building a `set` command so that we can appropriately
reset the environment when, for example, boot environments change.
Lift the previous restrictions to allow unquoted values on the right hand
side of an expression. Note that an unquoted value is effectively:
[A-Za-z0-9-][A-Za-z0-9-_.]*
This commit also stops trying to weirdly limit what it can handle in a
quoted value. Previously it only allowed spaces, alphanumeric, and
punctuation, which is kind of weird. Change it here to grab as much as it
can between two sets of quotes, then let processEnvVar() do the needful and
complain if it finds something malformed looking.
My extremely sophisticated test suite is as follows:
<<EOF
X_01_simple_string="simple"
X_02_escaped_string="s\imple"
X_03_unquoted_val=3
X_04_unquoted_strval=simple_test
X_05_subval="${X_03_unquoted_val}"
X_06_escaped_subval="\${X_03_unquoted_val}"
X_07_embedded="truth${X_03_unquoted_val}"
X_08_escaped_embedded="truth\${X_03_unquoted_val}"
X_09_unknown="${unknown_val}"
X_10_unknown_embedded="truth${unknown_val}"
X_11_crunchy="crunch$unknown_val crunch"
X_12_crunchy="crunch${unknown_val}crunch"
Y_01_badquote="te"lol"
Y_02_eolesc="lol\"
Y_02_noteolesc="lol\\"
Y_03_eolvar="lol$"
Y_03_noteolvar="lol\$"
Y_04_badvar="lol${"
exec="echo Done!"
EOF
Future work may provide a stub loader module in userland so that we can
formally test the loader scripts rather than sketchy setups like the above
in conjunction with the lua-* tools in ^/tools/boot.
