When such an address is known, do not search elsewhere, contrary to what
we are doing on non-EFI boot (see SMBIOS_START and SMBIOS_LENGTH).
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49291
In particular, this allows the caller to know whether the detection was
successful.
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49290
This is in preparation for modifying the EFI loader to favor a v3 table
if present.
As an impact, caller smbios_match() has been changed so that it only
calls smbios_probe() with NULL (non-EFI discovery) once.
While here, expand the original XXXRP comment in smbios_match().
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49289
On amd64, boot blocks and the non-EFI loader are 32-bit compiled as
clients of BTX, so cannot access addresses beyond 4GB. However, the
64-bit entry point may refer to a structure table below 4GB, which we
want to use if the BIOS does not provide a 32-bit entry point. The
situation is similar for powerpc64.
Consequently, always compile-in support for the 64-bit entry point, but
ensure that it is not selected on 32-bit-compiled boot loaders if the
structure table it points to grows beyond 4GB (as it is then not
accessible).
PR: 284460
Reviewed by: markj
MFC after: 2 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49288
When both the 32-bit and 64-bit entry points are present, the SMBIOS
specification says that the 64-bit entry point always has at least all
the structures the 32-bit entry point refers. In other words, the
32-bit entry point is provided for compatibility, so we assume the
64-bit one has more chances to be filled with adequate values.
Doing this also increases consistency with the kernel's smbios(4)
driver.
Reviewed by: imp, markj
MFC after: 2 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49287
According to the specification, such an entry point may have different
data in bytes at offsets 0x0c to 0x17 (included). In such a case,
interpreting them as the Structure Table Maximum Size and Address fields
could have catastrophic consequences.
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49286
This structure exists since SMBIOS v2.2 and indicates that there are no
structures to be parsed beyond this point. For backwards compatibility,
the standard recommends that system software ensures that this structure
covers the rest of the SMBIOS structure table area as reported by the
Structure Table Address, and the Structure Table Maximum Size (64-bit
entry point) or the Structure Table Length (32-bit entry point), which
makes existing parsers continue to work correctly as they usually ignore
unknown structure types. However, this is not a requirement, so be
bullet proof and immediately stop parsing in this case.
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49285
The code parsing the BCD revision is only meaningful on v2, so move it
away into the appropriate 'if' branch to ease reading (and to avoid
a useless test).
Expand comments. In particular, make it clear that setting
'smbios.count' to '-1' removes the limit of the number of structures to
parse.
No functional change.
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49284
Via the kenv 'smbios.entry_point_type'.
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49283
Rename HAS_SMBV3 to SMBIOS_64BIT_EP, as it will soon be externally
defined in some cases, and 'isv3' to 'is_64bit_ep'. These are more
accurate names for what they actually control/indicate.
No functional change.
Reviewed by: imp, markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49281
Move the comments so that lines stay of reasonable length.
Remove comments that state the obvious.
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49280
The current dosfs is only able to use 512B sector sizes, add
support for 4kn disks (incidentally this should also add support
for 1024B and 2048B sectors, have not tested those).
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49078
Currently only directly opened disk device is allowed to access
ioctl() - that is, when file has F_RAW flag set.
The problem is, file systems might need to determine the device parameters,
and we could use already opened device descriptor to communicate this
information.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49077
Use the RISCV_EFI_BOOT_PROTOCOL to fetch the boot hart ID, and
communicate this to the kernel via new metadata field
(MODINFOMD_BOOT_HART).
If the boot hart is not found this way, fall back to the (now
deprecated) device-tree method.
The assumption that a hart ID can be represented with a 32-bit unsigned
integer is unchanged in the kernel, but from the loader we pass the full
64-bit value. This ensures that this API won't need to change in the
future, should the wider value become necessary.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48887
It seems like this file was vendored (sorta) originally, but we have not
kept it in sync with the original source, if it still exists. Follow the
precedent in commit acf82d2659, and just add the definition to the
bottom of the file, keeping its style conventions.
Defined here: https://github.com/riscv-non-isa/riscv-uefi
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D48885
Pass framebuffer information from loader(8) to the kernel via the
MODINFOMD_EFI_FB metadata field.
Enable the vt_efifb driver. A small tweak is required to work around the
lack of VM_MEMATTR_WRITE_COMBINING on this platform; we use
VM_MEMATTR_UNCACHEABLE instead.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48884
The drawer.lua script ignores the values in loader_brand_x and
loader_brand_y on framebuffer consoles, always positioning the brand at
(1, 1).
Allow it to be positioned by accepting the x and y values just like the
text version. For example:
/boot/lua/gfx-nanobsd.lua:
return {
brand = {
graphic = {
""
},
requires_color = true,
image = "/boot/images/freebsd-logo-rev.png"
}
}
/boot/loader.conf.d/bootloader.conf:
loader_logo="none"
loader_brand="nanobsd"
loader_brand_x="15"
PR: 255202
Reviewed by: manu, imp
Approved by: emaste (mentor)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49092
Some systems have very slow console output and it may be about either
wrong memory attributes are set or gop->Blt() implementation is bad.
We do not have good way to set memory attributes, but we can
choose which Blt() to use (or we can set "gop off" to fall back on
use of SimpleTextOutput protocol).
This update adds argument for "gop" command to switch gop->Blt() use.
Note, this update does not fix the problem, but allows us to try to
understand the possible cause.
PR: 254381
Reported by: Michael Galassi
Reviewed by: manu, imp
Differential Revision: https://reviews.freebsd.org/D49073
The newvers.sh script is used to generate vers.c for 10 programs (at
latest count on amd64): 4 EFI loaders, 3 x86 loaders, two userboots,
and one kboot. When building without MK_REPRODUCIBLE_BUILD this
resulted in 10 different timestamps being compiled into various files.
If SOURCE_DATE_EPOCH is set, use that value rather than the current
date and time.
Reviewed by: emaste, imp
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D48803
Each program that operates on UFS on-disk inodes defines its own
version of a dinode. They all (of necessity) define the same
layout but use different names. This change adds a definition of
a dinode (a union of a UFS1 on-disk inode and a UFS2 on-disk inode)
as well as a dinodep (a union of a pointer to a UFS1 on-disk inode
and a pointer to a UFS2 on-disk inode) in sys/ufs/ufs/dinode.h.
It then deletes the definitions of dinode and dinodep in all the
programs that operate on them and instead uses these standard
definitions.
No functional change intended.
MFC-after: 1 week
A new filesystems category was created in the ports tree, with 142
filesystem related ports moved to there, some of them renamed.
Update all references in the src tree to the new locations.
PR: 283881
Fixes: ports:6e2da9672f79f44 (filesystems: add new category)
MFC after: 1 month
Reviewed by: fuz, mhorne, bapt
Accepted by: mhorne (mentor)
Differential Revision: https://reviews.freebsd.org/D48406
When FEAT_LPA2 is implemented the hardware supports increasing the
physical address space from 48-bit to 52-bit.
As older kernels only support a 48-bit physical address space limit
where the kernel is loaded to this.
Reviewed by: kib, markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D46625
The Arm SBSA uarts are handled by the pl011 driver. Add them to the
list of pl011 uarts.
Reviewed by: manu, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48526
To keep the SPCR uart type to name map aligned always use the hex value
as an index in the types array.
Reviewed by: manu, imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48525
Ensure the open operation targets an HTTP device. Return EINVAL if
not, to prevent potential system crashes when used on other devices.
Differential Revision: https://reviews.freebsd.org/D48439
Reviewed by: dab, imp, vangyzen
Sponsored by: Dell Technologies
While here, update bus_generic_detach to delete devices as in the
kernel.
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D48410
The kshim code abused the devclass argument to DRIVER_MODULE in some
odd ways. Instead, refactor the devclass handling to more closely
mirror what new-bus does in the kernel by having a linked list of
devclasses looked up by name and associate devices with a devclass.
Devices are now only associated with a module while probing and
attaching.
Reviewed by: imp, markj
Differential Revision: https://reviews.freebsd.org/D48409
With pkgbase we can have long kernel name, so create a new section
for the kernel name.
Do not show the "default" text, we already show the "1 of X" part at
the end of the line and the default kernel is always number 1 so it's a bit
redundant.
Differential Revision: https://reviews.freebsd.org/D48354
Reviewed by: imp, tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
Fix the orb position to be aligned with the menu
Differential Revision: https://reviews.freebsd.org/D48353
Reviewed by: imp, tsoome
Sponsored by: Beckhoff Automation GmbH & Co. KG
Since we started to ship raw firmware for iwm(4), users who loads
the driver from loader are having problems as loader don't know that
the firmwares are now raw files and not kernel modules anymore.
Start a list of default entry for iwm(4) firmwares name mapping so it will
still works when loaded from loader.
Differential Revision: https://reviews.freebsd.org/D48211
Reviewed by: bz, imp, kevans
Sponsored by: Beckhoff Automation GmbH & Co. KG
This may be used to disable or limit functionality of some services
when safe mode is selected. The particular value of boot_safe should not
be considered significant, only its presence in the environment.
Reviewed by: imp, tsoome
Differential Revision: https://reviews.freebsd.org/D32172
Try our best to use headers instead of doing things ourselves. With
i386's headers, there are some holes we need to fill manually.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1446
Nothing uses it anymore, so drop it from the 'safe' list. Also, move
stand/efi/loader/main.c to using machine/_inttypes.h which is all it
really needs.
Sponsored by: Netflix
unistd.h includes too much extra stuff for the boot loader. This creates
a fair amount of namespace pollution and it's best to just make it an
alias for stand.h like the other include files already are.
Sponsored by: Netflix
Olivier Certner