FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.3.0 2019-04-22T04:23:49Z 2019-04-22T04:23:49Z Ian Lepore ian@FreeBSD.org 2019-04-22T04:23:49Z urn:sha1:a7bd88f44d5634ac80f75865462d7c52a42dd741 Add missing MODULE_VERSION() and MODULE_DEPEND(). 2018-09-11T18:35:08Z Konstantin Belousov kib@FreeBSD.org 2018-09-11T18:35:08Z urn:sha1:396793f82de6c52cd07e092ebe795eafeddbc0e2 Improve error messages from clock_if.m method failures. 2018-09-11T18:31:57Z Konstantin Belousov kib@FreeBSD.org 2018-09-11T18:31:57Z urn:sha1:8539f8d4aa09ba04afd3f7b53162bdf0acf664ae Normalize use of semicolon with EFI_TIME_LOCK macros. 2018-08-12T00:33:24Z Kyle Evans kevans@FreeBSD.org 2018-08-12T00:33:24Z urn:sha1:b986bd14706200a1c14628c346b30908eac66ec7 efi_enter here was needed because efi_runtime dereference causes a fault outside of EFI context, due to runtime table living in runtime service space. This may cause problems early in boot, though, so instead access it by converting paddr to KVA for access. While here, remove the other direct PHYS_TO_DMAP calls and the explicit DMAP requirement from efidev. 2018-08-06T03:58:56Z Kyle Evans kevans@FreeBSD.org 2018-08-06T03:58:56Z urn:sha1:f1a5e4200be4f75f98a436d5ce68212767177818 r336919: efirt: Add tunable to allow disabling EFI Runtime Services Leading up to enabling EFIRT in GENERIC, allow runtime services to be disabled with a new tunable: efi.rt_disabled. This makes it so that EFIRT can be disabled easily in case we run into some buggy UEFI implementation and fail to boot. r336924: Follow up to r336919 and r336921: s/efi.rt_disabled/efi.rt.disabled/ The latter matches the rest of the tree better [0]. The UPDATING entry has been updated to reflect this, and the new tunable is now documented in loader(8) [1]. Reported by: imp [0], Shawn Webb [1] 2018-04-04T14:01:10Z Kyle Evans kevans@FreeBSD.org 2018-04-04T14:01:10Z urn:sha1:dd85ea65bcb47465569b8a6e4183e774a36f46b9 There's no real annotation for it, so it's not immediately obvious to the unfamiliar that these pointers are to locations in the EFI runtime map unlike the system table pointer immediately above them. 2018-04-04T13:59:42Z Kyle Evans kevans@FreeBSD.org 2018-04-04T13:59:42Z urn:sha1:1f39f84ae4f9b7510060b1b22821648faf329129 2018-04-04T13:58:18Z Kyle Evans kevans@FreeBSD.org 2018-04-04T13:58:18Z urn:sha1:6958af825d890be490a596e816142285290241e2 r330868: EFIRT: SetVirtualAddressMap with 1:1 mapping after exiting boot services This fixes a problem encountered on the Lenovo Thinkpad X220/Yoga 11e where runtime services would try to inexplicably jump to other parts of memory where it shouldn't be when attempting to enumerate EFI vars, causing a panic. The virtual mapping is enabled by default and can be disabled by setting efi_disable_vmap in loader.conf(5). r331241: Check if the gettime runtime service is valid. The U-Boot efi runtime service expects us to set the address map before calling any runtime services. It will then remap a few functions to their runtime version. One of these is the gettime function. If we call into this without having set a runtime map we get a page fault. Add a check to see if this is valid in efi_init() so we don't try to use the possibly invalid pointer. r331361: Enter into the EFI environment before dereferencing the runtime services pointer. This may be within the EFI address space and not the FreeBSD kernel address space. r331365: Re-work efidev ordering to fix efirt preloaded by loader on amd64 On amd64, efi_enter calls fpu_kern_enter(). This may not be called until fpuinitstate has been invoked, resulting in a kernel panic with efirt_load="YES" in loader.conf(5). Move fpuinitstate a little earlier in SI_SUB_DRIVERS so that we can squeeze efirt between it and efirtc at SI_SUB_DRIVERS, SI_ORDER_ANY. efidev must be after efirt and doesn't really need to be at SI_SUB_DEVFS, so drop it at SI_SUB_DRIVER, SI_ORDER_ANY. The not immediately obvious dependency of fpuinitstate by efirt has been noted in both places. 2018-03-25T01:55:17Z Ian Lepore ian@FreeBSD.org 2018-03-25T01:55:17Z urn:sha1:fd6106be41bb6384e8014fef1a00026d74591f85 Use EFI RTC capabilities info when registering, add bootverbose diagnostics. Make some small improvements to the efirtc driver by obtaining the clock capabilities (resolution and whether the sub-second counters are reset) and using the info when registering the clock. When the hardware zeroes out the subsecond info on clock-set, schedule clock updates to happen just before top-of-second, so that the RTC time is closely in-sync with kernel time. Also, in the identify() routine, always add the driver if EFI runtime services are available, then decide in probe() whether to attach the driver or not. If not attaching and bootverbose is on, say why. All of this is basically to avoid "silent failure" -- if someone thinks there should be an efi rtc and it's not attaching, at least they can set bootverbose and maybe get a clue from the output. Differential Revision: https://reviews.freebsd.org/D14565 (timed out) 2018-03-18T02:59:14Z Eitan Adler eadler@FreeBSD.org 2018-03-18T02:59:14Z urn:sha1:b77baeb220e8d2fcb7fdaf9debc2ef91068213a9 efirtc: Pass a dummy tmcap pointer to efi_get_time_locked As noted in the comment, UEFI spec claims the capabilities pointer is optional, but some implementations will choke and attempt to dereference it without checking. This specific problem was found on a Lenovo Thinkpad X220 that would panic in efirtc_identify. Requested by: kevans