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.
There is no need to keep multiple copies of the relocation code. The
amd64 code works on arm64 with a few small changes to relocation types.
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28213
Handle malloc failures in vbe_init().
If it should so happen and we do get malloc failure in vbe_init(),
use original mode list.
Replace nitems with nentries to have naming consistency and avoid
confusion with nitems() macro.
Reported by: yuripv, rpokala
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
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.
This fixes the positioning of the "Welcome to FreeBSD" heading, which was
misplaced after the recent update to Lua 5.4. The issue was previously
masked by a compatibility knob in Lua 5.3 that would cause float-tagged
numbers to render faithfully without the decimal component. Lua 5.4 dropped
that and ensures that it always prints a decimal component, even if it has
to append a ".0" to the value.
Standard division produces a "float", floor division (//) can be used to
guarantee an integer. Floating point operations have been completely ripped
out of the liblua compiled for the bootloader, so this is a nop. This is
decidedly better than trying to hack out the float tag entirely.
Reported-by: mjg, probably others
MFC-after: 3 days
Caller is not interested in symlinks follow them.
Throw an error if too many links encountered.
Reviewed by: stevek
Sponsored by: Juniper Networks
--This line, and those below, will be ignored--
> Description of fields to fill in above: 76 columns --|
> PR: If a GNATS PR is affected by the change.
> Differential Revision: https://reviews.freebsd.org/D### (*full* phabric URL needed).
> Submitted by: If someone else sent in the change.
> Reviewed by: If someone else reviewed your modification.
> Approved by: If you needed approval for this commit.
> Obtained from: If the change is from a third party.
> MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email.
> MFH: Ports tree branch name. Request approval for merge.
> Relnotes: Set to 'yes' for mention in release notes.
> Security: Vulnerability reference (one per line) or description.
> Sponsored by: If the change was sponsored by an organization.
> Empty fields above will be automatically removed.
Change-Id: I4ef92ff256f503c620dc5bba79ed93b32cb2330d
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.
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.
hw.vga.textmode is directing VT VGA backend to use text mode.
The default screen mode for BIOS loader is text, and default
screen mode for VT VGA backend is graphics (unless we are running on
hypervisor or hw.vga.textmode is set to 1). Using hw.vga.textmode
for loader does remove possibility to have graphical mode VT VGA with
text mode loader.
screen.textmode can have possible values "0" to disable text mode,
and "1" to set text mode.
Instead of trying to set reasonable register values, save significant
register values, then prepare for font upload and then restore
registers from saved data.
This seems to fix text mode for most cases where text mode breakage
was reported.
