When detaching device trees parent devices must be detached prior to
detaching its children. This is because parent devices can have
pointers to the child devices in their softcs which are not
invalidated by device_delete_child(). This can cause use after free
issues and panic().
Device drivers implementing trees, must ensure its detach function
detaches or deletes all its children before returning.
While at it remove now redundant device_detach() calls before
device_delete_child() and device_delete_children(), mostly in
the USB controller drivers.
Tested by: Jan Henrik Sylvester <me@janh.de>
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D8070
MFC after: 2 weeks
etc. can find out where the SMBIOS entry point is located. In pure
UEFI mode the BIOS is not mapped into the standard address space so the
SMBIOS table might not appear between 0xf0000 and 0xfffff. The
UEFI environment can report this the location of the anchor. If it is
reported then expose it as hint.smbios.0.mem. This can then be used
by other tools. However, we should make smbios(4) useful and have it
take this value and provide accesor function so ipmi(4) etc. don't
have to parse and figure things about the SMBIOS table. I have some
simple patches to smbios(4) to expose this address as sysctl and
for ipmi(4) to get the base address. However, the real fix is to
have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
parse it out and return it. This would make smbios(4) useful and reduce
duplicated code. If this address doesn't point to the anchor then
finding SMBIOS info. will fail as if this didn't exist. So there should
be no harm.
With this change and the following hack, dmidecode works on a bunch of
UEFI machines that I tested:
if kenv hint.smbios.0.mem > /dev/null
then
mkdir -p /sys/firmware/efi
mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
fi
Linux exposes this information via the /sys/firmware/efi/systab file which
dmidecode looks at. We should update dmidecode to do this the FreeBSD
way when we determine what that is!
Reviewed by: jhb
functions to call at the appropriate time to register new forth
words. In the past we've done this with ifdef soup, but now if the
file is included in the build, we'll get the new forth words.
Use this new functionality to move the pci bios stuff out of loader.c
by moving it to biospci.c.
Move the pnp functionality to common/pnp.c.
Move the inb/outb forth words to the i386 sysdep.c file where their
implementation is defined.
Adjust the efi linker scripts and build machinery to cope.
his should be an invisible change to forth scripts and user
experience.
Differential Revision: https://reviews.freebsd.org/D8145
than to store the location of a forth word that is subsequently never
used. It was last used before the 2.03 ficl upgrade in r51786. It was
only used from r43614 (so Feb-Sept 1999) on head and in the 3.x branch
(merged r43715 3.1 -> EOL). Remove it since nobody cared enough to
report the bug in the last 18 years rather than fix it. It's need
seems to have passed in the 2.03 ficl update.
Differential Revision: https://reviews.freebsd.org/D8150
replaced by /boot/loader.rc for 3.1 (r42682). In May 2000, this was
documented as deprecated (r61942) (between FreeBSD 4.0 and
4.1). Remove it since it's not been the preferred method in 17 years
and has been deprecated for 16.
Differential Revision: https://reviews.freebsd.org/D8142
dev_net.c code.
The NETIF_OPEN_CLOSE_ONCE flag was added in r201932 to prevent that behaviour
on some architectures (sparc64 and powerpc64) the default was left to always
open and close the device for each open and close of a file by the loader
because it was necessary for u-boot on arm.
Since it has been added, the flag was turned on for every arches including the
u-boot loader for arm.
This also fixes netbooting on RPi3 (tested by gonzo@)
For the loader.efi it greatly speeds up netbooting
Reviewed by: emaste, gonzo, tsoome
Approved by: gonzo
MFC after: 1 month
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D8230
R_AARCH64_RELATIVE relocation found on arm64. It would try to add the
contents of the memory location being relocated to the base address and
the relocation addend. This worked when the contents was zero, however
this now seems to be set to the value of the addend so we add this twice.
Fix this by just setting the memory to the computed value.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D8177
When tsoome@ added skein support to the ZFS boot code and zfsloader, it
resulted in an explosion in code size, running close to a number of
limits.
The default for the C version of skein is to unroll all loops for
skein-256 and 512
Disabling the loop unrolling saves 20-28kb from each binary
boot1.efi
gptzfsboot
loader.efi
userboot.so
zfsloader
Reviewed by: emaste, tsoome
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D7826
Usually there is some slack after the last partition due to 4k alignment
In the 10.3 EC2 images, there was not. EC2 seems to hang if you try to
read past the end of the disk in the loader, resulting in an unbootable
instance after upgrading to 11.0
PR: 213196
Reported by: Peter Ankerstal <peter@pean.org>
Tested by: cperciva
Reviewed by: tsoome
MFC after: 3 days
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D8144
1. Size returned for variable name is in bytes, not CHAR16 (the
UEFI standard is unclear on this, where it is clear on the size of
the variable).
2. Dynamically allocate the buffers so we can grow them if someone
defines a super-long variable name.
These two fixes allow me to examine all the variables in my BIOS and
also removes the repeated printing of variables.
Technically touchscreen chip is FT5406 but all hardware
communication is performed by VideCore and only final results
are presented to ARM part through memory region shared between
VC and ARM.
evdev is used as userland interface. FT5406 supports up to
10 touchpoints, but for now driver emulates single touch device
because I do not have GUI bits to test this functionality.
Driver is not enabled in default config for RPI and RPI2
Tested with: evdev-dump, tslib
The command interpreter does leave command_errmsg as is after printing its
content, assuming the next command will reset it in bf_command(). However,
in case the forth native word is defined as builtin, the bf_command is not
used and forth words will also end up the command_errmsg content printed.
Since command_errmsg is pointer to actual error message, which can be static
read only string, we can not just set *command_errmsg = '\0', instead we need
to reset the pointer itself.
Illumos issue: https://www.illumos.org/issues/7405
Reported by: Igor Kozhukhov.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D8032
files and, in a number of these places, there were problems with how they
were declared.
Some used int return instead of time_t. On some architectures the bit
width of time_t did not naturally fit into an integer and could lead to
some unexpected behavior. (For example, 32-bit ARM builds uses a 64-bit
time_t.)
Make sure the function prototypes always specify void for the argument
list when they do not have any arguemnts, otherwise some compilers can
complain about the prototype.
Reported by: Kevin Zheng
Reviewed by: sjg
Approved by: sjg (mentor)
Obtained from: Juniper Networks, Inc.
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D7463
There is no way to see anything about the faults occuring in
loader.efi. Some intel BIOSes do output a line into serial port at
115200/8/1 regardless of the current port settings with the EFI error
number, but this is too little, and not always available, esp. if the
user does not know where to look.
The patch adds a simple facility to grab exceptions and at least dump
generic registers and some exception details. Due to the relative
complexity of correctly taking over the BIOS IDT setup, only install
the facility on user request.
Two new commands, 'grab_faults' and 'ungrab_faults' are provided,
first one takes over, second undoes the first. It is supposed that
user would execute 'grab' by the developer direction of collecting the
debugging data. The 'fault' command generates exception to test the
setup.
Fault handlers use dedicated stack to improve chances of catching
stack/TSS exceptions. Due to this, BIOS IDT is duplicated into a
private copy, and debugger needs to find a free GDT slot for TSS. This
is done in somewhat complicated efi_redirect_exceptions().
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D7935
trampoline page table. Also do some style cleanup.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D7934
The fill pattern was previously an ia64 instruction sequence. Presumably
ia64's linker script was copied as a starting point.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
This commit adds drivers for Alpine Cache Coherency Unit
and North Bridge Service whose task is to configure
the system fabric and enable cache coherency.
Obtained from: Semihalf
Submitted by: Michal Stanek <mst@semihalf.com>
Sponsored by: Annapurna Labs
Reviewed by: wma
Differential Revision: https://reviews.freebsd.org/D7565
This is required on my system, which loads nvidia, vmm, and zfs, and 48M is
no longer enough for that. nvidia-driver's recent update increased its size
by several megabytes.
Reviewed by: jhb
MFC after: 1 week
not page aligned. To do this, use the ld script gnu ld installs on my
system.
This is imperfect: LDFLAGS_BIN and LD_FLAGS_BIN describe different
things. The loader script could be better named and take into account
other architectures. And having two different mechanisms to do
basically the same thing needs study. However, it's blocking forward
progress on lld, so I'll work in parallel to sort these out.
Differential Revision: https://reviews.freebsd.org/D7409
Reviewed by: emaste
The linker script CONSTRUCTORS keyword is only meaningful "when linking
object file formats which do not support arbitrary sections, such as
ECOFF and XCOFF"[1] and is ignored for other object file formats.
LLVM's lld does not yet accept (and ignore) CONSTRUCTORS, so just remove
CONSTRUCTORS from the linker script as it has no effect.
[1] https://sourceware.org/binutils/docs/ld/Output-Section-Keywords.html
RISC-V cpu implementations.
o Update RocketChip device tree source (DTS).
We now support latest verison of RocketChip synthesized on
Xilinx FPGA (Zedboard).
RocketChip is an implementation of RISC-V processor written on
Chisel hardware construction language.
Sponsored by: DARPA, AFRL
Sponsored by: HEIF5
In some Dell systems and usb stick combinations, it is found that
int13 AH=08 is reporting back bad sector information, preventing the
boot.
This update is allowing bd_int13probe() to use extended info call to
build disk properties.
It also can happen the total sectors count from extended info may be
wrong, in such case, the CHS data is used to calculate total sectors.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D7718
Add a new 'netproto' variable which can be set for now to
NET_TFTP or NET_NFS (default to NET_NONE)
From the dhcp options if one sets the root-path option to:
"ip:path", the loader will consider it is booting over NFS
(meaning same behaviour as the default current behaviour)
if the dhcp option "tftp server address" is set (option 150)
the loader will consider it is booting over tftpfs, it will then
consider the root-path options with 2 possible case
1. "path" then the IP of the tftp server will be the one passed by
the option 150, and the files will be retrieved under "path" on the tftp
server
2. "ip:path" then the IP of the tftp server will be the one passed in
the option "overwritting the IP from the option 150.
We could not "abuse" the rootpath option in the form or tftp://ip:path because
this is already used for other purpose by iPXE preventing any chainload from
iPXE to the FreeBSD loader.
Given at each open(), the loader loops over all available filesystems and keep
the "best" error, we needed to prevent tftpfs to fallback on nfs and vice versa.
the tftpfs and nfs implementation in libstand now return EINVAL early if
'netproto' for that purpose.
Reviewed by: tsoome
Relnotes: yes
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D7628
something (perhaps in loader.rc.local) that can read in .conf files
after all the other .conf files have been read and override settings
in them. This is quite handy if the .conf file name is determined
while the loader is running, but might be generically useful for other
things. If this hook exists, call it, otherwise don't do anything.
Doing it in these functions ensures that this file is reliably
read. It also works around a defect in forth where s" isn't allowed
outside a function (well, in a compile context) leading to gross
workarounds if one were to hack loader.rc like:
: maybe-some-func s" some-func" sfind if execute else drop then ;
maybe-some-func
which somehow seems worse. Though I'm sure there's some clever forthy
way of doing that with a macro.
Sponsored by: Netflix, Inc
device argument to the stage-1 bootloader. In such cases, boot1 would
only try to read the entire device rather than checking for partitions.
Instead of panic'ing, fall back to reading the partitions as normal in
such situations. This was preventing boot of installed systems on some
versions of PowerKVM.
PR: kern/211599
MFC after: 2 days
can emulate efi_cons_poll(0 with a flag and caching the last key read with
ReadKeyStroke. This fixes the loader.efi countdown timer on Pine64 (and
other U-Boot + EFI using platforms).
Reviewed by: imp, manu
Differential Revision: https://reviews.freebsd.org/D7670
beyond the end of disk. r298900 added code to prevent this. Some BIOSes
cause significant delays if asked to read past end-of-disk.
We never trusted the BIOS to accurately report the sectorsize of disks
before and this set of changes. Unfortuately they interact badly with
the infamous >2TB wraparound bugs. We have a number of relatively-recent
machines in the FreeBSD.org cluster where the BIOS reports 3TB disks as 1TB.
With pre-r298900 they work just fine. After r298900 they stop working if
the boot environment attempts to access anything outside the first 1TB on
the disk. 'ZFS: I/O error, all block copies unavailable' etc. It affects
both UFS and ZFS if they try to boot from large volumes.
This change replaces the blind trust of the BIOS end-of-disk reporting
with a read-ahead clip to prevent reads crossing the of end-of-disk
boundary. Since 2^32 (2TB) size reporting truncation is not uncommon,
the clipping is done on 2TB aliases of the reported end-of-disk.
ie: a 3TB disk reported as 1TB has readahead clipped at 1TB, 3TB, 5TB, ...
as one of them is likely to be the real end-of-disk.
This should make the loader on these broken machines behave the same as
traditional pre-r298900 loader behavior, without disabling read-ahead.
PR: 212139
Discussed with: tsoome, allanjude
set later in the function. This fixes a potential NULL pointer dereference
found on arm64.
Obtained from: ABT Systems Ltd
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
