The EFI memory map may change before or during the first
ExitBootServices call. In that case ExitBootServices returns an error,
and GetMemoryMap and ExitBootServices must be retried.
Glue together calls to GetMemoryMap(), ExitBootServices() and storage of
(now up-to-date) MODINFOMD_EFI_MAP metadata within a single function.
That new function - bi_add_efi_data_and_exit() - uses space previously
allocated in bi_load_efi_data() to store the memory map (it will fail if
that space is too short). It handles re-calling GetMemoryMap() once to
update the map key if necessary. Finally, if ExitBootServices() is
successful, it stores the memory map and its header as MODINFOMD_EFI_MAP
metadata.
ExitBootServices() calls are now done earlier, from within arch-
independent bi_load() code.
PR: 202455
Submitted by: Ganael LAPLANCHE
Reviewed by: kib
MFC after: 2 weeks
Relnotes: Yes
Differential Revision: https://reviews.freebsd.org/D4296
no option but to use the smbios information to fill in the blanks.
It's a good thing UGA is a protocol of the past and GOP has all the
info we need.
Anyway, the logic has been tweaked a little to get the easier bits
of information up front. This includes the resolution and the frame
buffer address. Then we look at the smbios information and define
expected values as well as the missing bits (frame buffer offset and
stride). If the values obtained match the expect values, we fill in
the blanks and return. Otherwise we use the existing detection logic
to figure it out.
Rename the environment variables from uga_framebuffer abd uga_stride
to hw.efifb.address and hw.efifb.stride. The latter names are more
in line with other variable names.
We currently have hardcoded settings for:
1. Mid-2007 iMac (iMac7,1)
2. Late-2007 MacBook (MacBook3,1)
striking a delicate balance between exhaustive searching and
banking on assumptions. The environment variables can be used
as a fall-back anyway. With this change, all known and tested
Macs with only UGA should have a working console out of the
box... for now...
in the frame buffer when we flip pixels. Allow the detection
to be bypassed by setting the uga_framebuffer and uga_stride
variables. The kernel console works fine even when we can't
detect pixel changes in the frame buffer, which indicates
that the problem could be with reading from the frame buffer
and not writing to it.
PCI BARs does not necessarily correspond to the upper-left
most pixel. Scan the frame buffer for which byte changed
when changing the pixel at (0,0).
Use the same technique to determine the stride. Except for
changing the pixel at (0,0), we change the pixel at (0,1).
PR: 202730
Tested by: hartzell (at) alerce.com
command called 'uga' to show whether UGA is implemented by the
firmware and what the settings are. It also includes filling
the efi_fb structure from the UGA information when GOP isn't
implemented by the firmware.
Since UGA does not provide information about the stride, we
set the stride to the horizontal resolution. This is likely
not correct and we should determine the stride by trial and
error. For now, this should show something on the console
rather than nothing.
Refactor this file to maximize code reuse.
PR: 202730
command has the following sub-commands:
list - list all possible modes (paged)
get - return the current mode
set <mode> - set the current mode to <mode>
return a value.
Despite what I said in my prior commit, it turns out this one platform
was checking the return value from the old self-reloc code (which returned
a hard-coded 0).
The function was defined as taking 4 parameters and returning EFI_STATUS,
but all existing callers (in asm code) passed only two parameters and don't
use the return value. The function signature now matches that usage, and
doesn't refer to efi-specific types.
Parameters and variables now use the cannonical typenames set up by elf.h
(Elf_Word, Elf_Addr, etc) instead of raw C types. Hopefully this will
prevent suprises as new platforms come along and use this code.
The function was renamed from _reloc() to self_reloc() to emphasize its
difference from the other elf relocation code found in boot/common.
Differential Revision: https://reviews.freebsd.org/D2490
Much of this file is common to the architectures we support, so share
an implementation by adding a little #ifdef-ery.
Differential Revision: https://reviews.freebsd.org/D2241
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
This was not (and still is not) connected to the build, but the EFI
loader is in the process of being built for other than amd64 so these
files ought to live in their eventual MD location.
support for booting arm and arm64 from UEFI.
Differential Revision: https://reviews.freebsd.org/D2164
Reviewed by: emaste, imp (previous version)
Sponsored by: The FreeBSD Foundation
