Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
/*-
|
|
|
|
* Copyright (c) 2013 The FreeBSD Foundation
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This software was developed by Benno Rice under sponsorship from
|
|
|
|
* the FreeBSD Foundation.
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
2015-08-30 01:39:59 +00:00
|
|
|
#include <bootstrap.h>
|
2015-08-30 23:58:53 +00:00
|
|
|
#include <sys/endian.h>
|
2018-03-23 21:02:46 +00:00
|
|
|
#include <sys/param.h>
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
#include <stand.h>
|
|
|
|
|
|
|
|
#include <efi.h>
|
|
|
|
#include <efilib.h>
|
2015-08-30 23:58:53 +00:00
|
|
|
#include <efiuga.h>
|
|
|
|
#include <efipciio.h>
|
2021-02-20 08:51:28 +00:00
|
|
|
#include <Protocol/EdidActive.h>
|
|
|
|
#include <Protocol/EdidDiscovered.h>
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
#include <machine/metadata.h>
|
|
|
|
|
2020-12-21 05:31:16 +00:00
|
|
|
#include "bootstrap.h"
|
2016-01-12 02:17:39 +00:00
|
|
|
#include "framebuffer.h"
|
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
static EFI_GUID conout_guid = EFI_CONSOLE_OUT_DEVICE_GUID;
|
2020-12-21 05:31:16 +00:00
|
|
|
EFI_GUID gop_guid = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
|
2015-08-30 23:58:53 +00:00
|
|
|
static EFI_GUID pciio_guid = EFI_PCI_IO_PROTOCOL_GUID;
|
|
|
|
static EFI_GUID uga_guid = EFI_UGA_DRAW_PROTOCOL_GUID;
|
2021-02-20 08:51:28 +00:00
|
|
|
static EFI_GUID active_edid_guid = EFI_EDID_ACTIVE_PROTOCOL_GUID;
|
|
|
|
static EFI_GUID discovered_edid_guid = EFI_EDID_DISCOVERED_PROTOCOL_GUID;
|
|
|
|
static EFI_HANDLE gop_handle;
|
|
|
|
|
|
|
|
/* Cached EDID. */
|
|
|
|
struct vesa_edid_info *edid_info = NULL;
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
static EFI_GRAPHICS_OUTPUT *gop;
|
|
|
|
static EFI_UGA_DRAW_PROTOCOL *uga;
|
|
|
|
|
2018-03-23 21:02:46 +00:00
|
|
|
static struct named_resolution {
|
|
|
|
const char *name;
|
|
|
|
const char *alias;
|
|
|
|
unsigned int width;
|
|
|
|
unsigned int height;
|
|
|
|
} resolutions[] = {
|
|
|
|
{
|
|
|
|
.name = "480p",
|
|
|
|
.width = 640,
|
|
|
|
.height = 480,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "720p",
|
|
|
|
.width = 1280,
|
|
|
|
.height = 720,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "1080p",
|
|
|
|
.width = 1920,
|
|
|
|
.height = 1080,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "2160p",
|
|
|
|
.alias = "4k",
|
|
|
|
.width = 3840,
|
|
|
|
.height = 2160,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.name = "5k",
|
|
|
|
.width = 5120,
|
|
|
|
.height = 2880,
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-09-03 04:35:17 +00:00
|
|
|
static u_int
|
|
|
|
efifb_color_depth(struct efi_fb *efifb)
|
|
|
|
{
|
|
|
|
uint32_t mask;
|
|
|
|
u_int depth;
|
|
|
|
|
|
|
|
mask = efifb->fb_mask_red | efifb->fb_mask_green |
|
|
|
|
efifb->fb_mask_blue | efifb->fb_mask_reserved;
|
|
|
|
if (mask == 0)
|
|
|
|
return (0);
|
|
|
|
for (depth = 1; mask != 1; depth++)
|
|
|
|
mask >>= 1;
|
|
|
|
return (depth);
|
|
|
|
}
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
static int
|
|
|
|
efifb_mask_from_pixfmt(struct efi_fb *efifb, EFI_GRAPHICS_PIXEL_FORMAT pixfmt,
|
|
|
|
EFI_PIXEL_BITMASK *pixinfo)
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
{
|
2015-08-30 23:58:53 +00:00
|
|
|
int result;
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
result = 0;
|
|
|
|
switch (pixfmt) {
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
case PixelRedGreenBlueReserved8BitPerColor:
|
2021-01-11 19:16:42 +00:00
|
|
|
case PixelBltOnly:
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
efifb->fb_mask_red = 0x000000ff;
|
|
|
|
efifb->fb_mask_green = 0x0000ff00;
|
|
|
|
efifb->fb_mask_blue = 0x00ff0000;
|
|
|
|
efifb->fb_mask_reserved = 0xff000000;
|
|
|
|
break;
|
|
|
|
case PixelBlueGreenRedReserved8BitPerColor:
|
|
|
|
efifb->fb_mask_red = 0x00ff0000;
|
|
|
|
efifb->fb_mask_green = 0x0000ff00;
|
|
|
|
efifb->fb_mask_blue = 0x000000ff;
|
|
|
|
efifb->fb_mask_reserved = 0xff000000;
|
|
|
|
break;
|
|
|
|
case PixelBitMask:
|
2015-08-30 23:58:53 +00:00
|
|
|
efifb->fb_mask_red = pixinfo->RedMask;
|
|
|
|
efifb->fb_mask_green = pixinfo->GreenMask;
|
|
|
|
efifb->fb_mask_blue = pixinfo->BlueMask;
|
|
|
|
efifb->fb_mask_reserved = pixinfo->ReservedMask;
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
break;
|
|
|
|
default:
|
2015-08-30 23:58:53 +00:00
|
|
|
result = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return (result);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
efifb_from_gop(struct efi_fb *efifb, EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE *mode,
|
|
|
|
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *info)
|
|
|
|
{
|
|
|
|
int result;
|
|
|
|
|
|
|
|
efifb->fb_addr = mode->FrameBufferBase;
|
|
|
|
efifb->fb_size = mode->FrameBufferSize;
|
|
|
|
efifb->fb_height = info->VerticalResolution;
|
|
|
|
efifb->fb_width = info->HorizontalResolution;
|
|
|
|
efifb->fb_stride = info->PixelsPerScanLine;
|
|
|
|
result = efifb_mask_from_pixfmt(efifb, info->PixelFormat,
|
|
|
|
&info->PixelInformation);
|
|
|
|
return (result);
|
|
|
|
}
|
|
|
|
|
2015-09-03 04:35:17 +00:00
|
|
|
static ssize_t
|
|
|
|
efifb_uga_find_pixel(EFI_UGA_DRAW_PROTOCOL *uga, u_int line,
|
|
|
|
EFI_PCI_IO_PROTOCOL *pciio, uint64_t addr, uint64_t size)
|
|
|
|
{
|
|
|
|
EFI_UGA_PIXEL pix0, pix1;
|
|
|
|
uint8_t *data1, *data2;
|
|
|
|
size_t count, maxcount = 1024;
|
|
|
|
ssize_t ofs;
|
|
|
|
EFI_STATUS status;
|
|
|
|
u_int idx;
|
|
|
|
|
|
|
|
status = uga->Blt(uga, &pix0, EfiUgaVideoToBltBuffer,
|
|
|
|
0, line, 0, 0, 1, 1, 0);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("UGA BLT operation failed (video->buffer)");
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
pix1.Red = ~pix0.Red;
|
|
|
|
pix1.Green = ~pix0.Green;
|
|
|
|
pix1.Blue = ~pix0.Blue;
|
|
|
|
pix1.Reserved = 0;
|
|
|
|
|
|
|
|
data1 = calloc(maxcount, 2);
|
|
|
|
if (data1 == NULL) {
|
|
|
|
printf("Unable to allocate memory");
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
data2 = data1 + maxcount;
|
|
|
|
|
|
|
|
ofs = 0;
|
|
|
|
while (size > 0) {
|
|
|
|
count = min(size, maxcount);
|
|
|
|
|
|
|
|
status = pciio->Mem.Read(pciio, EfiPciIoWidthUint32,
|
|
|
|
EFI_PCI_IO_PASS_THROUGH_BAR, addr + ofs, count >> 2,
|
|
|
|
data1);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("Error reading frame buffer (before)");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
status = uga->Blt(uga, &pix1, EfiUgaBltBufferToVideo,
|
|
|
|
0, 0, 0, line, 1, 1, 0);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("UGA BLT operation failed (modify)");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
status = pciio->Mem.Read(pciio, EfiPciIoWidthUint32,
|
|
|
|
EFI_PCI_IO_PASS_THROUGH_BAR, addr + ofs, count >> 2,
|
|
|
|
data2);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("Error reading frame buffer (after)");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
status = uga->Blt(uga, &pix0, EfiUgaBltBufferToVideo,
|
|
|
|
0, 0, 0, line, 1, 1, 0);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
printf("UGA BLT operation failed (restore)");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
for (idx = 0; idx < count; idx++) {
|
|
|
|
if (data1[idx] != data2[idx]) {
|
|
|
|
free(data1);
|
|
|
|
return (ofs + (idx & ~3));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ofs += count;
|
|
|
|
size -= count;
|
|
|
|
}
|
2015-09-05 18:24:51 +00:00
|
|
|
printf("No change detected in frame buffer");
|
2015-09-03 04:35:17 +00:00
|
|
|
|
|
|
|
fail:
|
2016-01-06 19:15:16 +00:00
|
|
|
printf(" -- error %lu\n", EFI_ERROR_CODE(status));
|
2015-09-03 04:35:17 +00:00
|
|
|
free(data1);
|
|
|
|
return (-1);
|
|
|
|
}
|
|
|
|
|
2015-09-05 03:27:23 +00:00
|
|
|
static EFI_PCI_IO_PROTOCOL *
|
|
|
|
efifb_uga_get_pciio(void)
|
2015-08-30 23:58:53 +00:00
|
|
|
{
|
|
|
|
EFI_PCI_IO_PROTOCOL *pciio;
|
2015-09-03 04:35:17 +00:00
|
|
|
EFI_HANDLE *buf, *hp;
|
2015-08-30 23:58:53 +00:00
|
|
|
EFI_STATUS status;
|
2015-09-03 04:35:17 +00:00
|
|
|
UINTN bufsz;
|
2015-08-30 23:58:53 +00:00
|
|
|
|
2015-09-03 04:35:17 +00:00
|
|
|
/* Get all handles that support the UGA protocol. */
|
2015-08-30 23:58:53 +00:00
|
|
|
bufsz = 0;
|
|
|
|
status = BS->LocateHandle(ByProtocol, &uga_guid, NULL, &bufsz, NULL);
|
|
|
|
if (status != EFI_BUFFER_TOO_SMALL)
|
2015-09-05 03:27:23 +00:00
|
|
|
return (NULL);
|
2015-08-30 23:58:53 +00:00
|
|
|
buf = malloc(bufsz);
|
2015-09-03 04:35:17 +00:00
|
|
|
status = BS->LocateHandle(ByProtocol, &uga_guid, NULL, &bufsz, buf);
|
2015-08-30 23:58:53 +00:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
free(buf);
|
2015-09-05 03:27:23 +00:00
|
|
|
return (NULL);
|
2015-08-30 23:58:53 +00:00
|
|
|
}
|
2015-09-03 04:35:17 +00:00
|
|
|
bufsz /= sizeof(EFI_HANDLE);
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
/* Get the PCI I/O interface of the first handle that supports it. */
|
|
|
|
pciio = NULL;
|
2015-09-03 04:35:17 +00:00
|
|
|
for (hp = buf; hp < buf + bufsz; hp++) {
|
2019-08-06 19:27:27 +00:00
|
|
|
status = OpenProtocolByHandle(*hp, &pciio_guid,
|
|
|
|
(void **)&pciio);
|
2015-09-05 03:27:23 +00:00
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
free(buf);
|
|
|
|
return (pciio);
|
|
|
|
}
|
2015-08-30 23:58:53 +00:00
|
|
|
}
|
|
|
|
free(buf);
|
2015-09-05 03:27:23 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static EFI_STATUS
|
2015-09-05 18:24:51 +00:00
|
|
|
efifb_uga_locate_framebuffer(EFI_PCI_IO_PROTOCOL *pciio, uint64_t *addrp,
|
|
|
|
uint64_t *sizep)
|
2015-09-05 03:27:23 +00:00
|
|
|
{
|
|
|
|
uint8_t *resattr;
|
2015-09-05 18:24:51 +00:00
|
|
|
uint64_t addr, size;
|
2015-09-05 03:27:23 +00:00
|
|
|
EFI_STATUS status;
|
|
|
|
u_int bar;
|
2015-09-03 04:35:17 +00:00
|
|
|
|
2015-09-05 18:24:51 +00:00
|
|
|
if (pciio == NULL)
|
|
|
|
return (EFI_DEVICE_ERROR);
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
/* Attempt to get the frame buffer address (imprecise). */
|
2015-09-05 18:24:51 +00:00
|
|
|
*addrp = 0;
|
|
|
|
*sizep = 0;
|
2015-08-30 23:58:53 +00:00
|
|
|
for (bar = 0; bar < 6; bar++) {
|
|
|
|
status = pciio->GetBarAttributes(pciio, bar, NULL,
|
2015-09-03 04:35:17 +00:00
|
|
|
(void **)&resattr);
|
2015-08-30 23:58:53 +00:00
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
continue;
|
|
|
|
/* XXX magic offsets and constants. */
|
2015-09-03 04:35:17 +00:00
|
|
|
if (resattr[0] == 0x87 && resattr[3] == 0) {
|
2015-08-30 23:58:53 +00:00
|
|
|
/* 32-bit address space descriptor (MEMIO) */
|
2015-09-05 18:24:51 +00:00
|
|
|
addr = le32dec(resattr + 10);
|
|
|
|
size = le32dec(resattr + 22);
|
2015-09-03 04:35:17 +00:00
|
|
|
} else if (resattr[0] == 0x8a && resattr[3] == 0) {
|
2015-08-30 23:58:53 +00:00
|
|
|
/* 64-bit address space descriptor (MEMIO) */
|
2015-09-05 18:24:51 +00:00
|
|
|
addr = le64dec(resattr + 14);
|
|
|
|
size = le64dec(resattr + 38);
|
2015-08-30 23:58:53 +00:00
|
|
|
} else {
|
2015-09-05 18:24:51 +00:00
|
|
|
addr = 0;
|
|
|
|
size = 0;
|
2015-08-30 23:58:53 +00:00
|
|
|
}
|
2015-09-03 04:35:17 +00:00
|
|
|
BS->FreePool(resattr);
|
2015-09-05 18:24:51 +00:00
|
|
|
if (addr == 0 || size == 0)
|
2015-08-30 23:58:53 +00:00
|
|
|
continue;
|
2015-09-03 04:35:17 +00:00
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
/* We assume the largest BAR is the frame buffer. */
|
2015-09-05 18:24:51 +00:00
|
|
|
if (size > *sizep) {
|
|
|
|
*addrp = addr;
|
|
|
|
*sizep = size;
|
2015-08-30 23:58:53 +00:00
|
|
|
}
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
}
|
2015-09-05 18:24:51 +00:00
|
|
|
return ((*addrp == 0 || *sizep == 0) ? EFI_DEVICE_ERROR : 0);
|
2015-09-03 04:35:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2021-01-17 13:07:27 +00:00
|
|
|
efifb_from_uga(struct efi_fb *efifb)
|
2015-09-03 04:35:17 +00:00
|
|
|
{
|
|
|
|
EFI_PCI_IO_PROTOCOL *pciio;
|
2015-09-05 03:27:23 +00:00
|
|
|
char *ev, *p;
|
2015-09-03 04:35:17 +00:00
|
|
|
EFI_STATUS status;
|
2015-09-07 17:56:49 +00:00
|
|
|
ssize_t offset;
|
2016-01-12 02:17:39 +00:00
|
|
|
uint64_t fbaddr;
|
2015-09-07 17:56:49 +00:00
|
|
|
uint32_t horiz, vert, stride;
|
|
|
|
uint32_t np, depth, refresh;
|
2015-09-03 04:35:17 +00:00
|
|
|
|
|
|
|
status = uga->GetMode(uga, &horiz, &vert, &depth, &refresh);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
return (1);
|
|
|
|
efifb->fb_height = vert;
|
|
|
|
efifb->fb_width = horiz;
|
2015-09-05 18:24:51 +00:00
|
|
|
/* Paranoia... */
|
|
|
|
if (efifb->fb_height == 0 || efifb->fb_width == 0)
|
|
|
|
return (1);
|
|
|
|
|
|
|
|
/* The color masks are fixed AFAICT. */
|
2015-09-03 04:35:17 +00:00
|
|
|
efifb_mask_from_pixfmt(efifb, PixelBlueGreenRedReserved8BitPerColor,
|
|
|
|
NULL);
|
|
|
|
|
2015-09-07 17:56:49 +00:00
|
|
|
/* pciio can be NULL on return! */
|
|
|
|
pciio = efifb_uga_get_pciio();
|
|
|
|
|
|
|
|
/* Try to find the frame buffer. */
|
|
|
|
status = efifb_uga_locate_framebuffer(pciio, &efifb->fb_addr,
|
|
|
|
&efifb->fb_size);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
efifb->fb_addr = 0;
|
|
|
|
efifb->fb_size = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There's no reliable way to detect the frame buffer or the
|
|
|
|
* offset within the frame buffer of the visible region, nor
|
|
|
|
* the stride. Our only option is to look at the system and
|
|
|
|
* fill in the blanks based on that. Luckily, UGA was mostly
|
2015-12-21 19:56:11 +00:00
|
|
|
* only used on Apple hardware.
|
2015-09-07 17:56:49 +00:00
|
|
|
*/
|
|
|
|
offset = -1;
|
|
|
|
ev = getenv("smbios.system.maker");
|
|
|
|
if (ev != NULL && !strcmp(ev, "Apple Inc.")) {
|
|
|
|
ev = getenv("smbios.system.product");
|
|
|
|
if (ev != NULL && !strcmp(ev, "iMac7,1")) {
|
|
|
|
/* These are the expected values we should have. */
|
|
|
|
horiz = 1680;
|
|
|
|
vert = 1050;
|
|
|
|
fbaddr = 0xc0000000;
|
|
|
|
/* These are the missing bits. */
|
|
|
|
offset = 0x10000;
|
|
|
|
stride = 1728;
|
|
|
|
} else if (ev != NULL && !strcmp(ev, "MacBook3,1")) {
|
|
|
|
/* These are the expected values we should have. */
|
|
|
|
horiz = 1280;
|
|
|
|
vert = 800;
|
|
|
|
fbaddr = 0xc0000000;
|
|
|
|
/* These are the missing bits. */
|
|
|
|
offset = 0x0;
|
|
|
|
stride = 2048;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this is hardware we know, make sure that it looks familiar
|
|
|
|
* before we accept our hardcoded values.
|
|
|
|
*/
|
|
|
|
if (offset >= 0 && efifb->fb_width == horiz &&
|
|
|
|
efifb->fb_height == vert && efifb->fb_addr == fbaddr) {
|
|
|
|
efifb->fb_addr += offset;
|
|
|
|
efifb->fb_size -= offset;
|
|
|
|
efifb->fb_stride = stride;
|
|
|
|
return (0);
|
|
|
|
} else if (offset >= 0) {
|
|
|
|
printf("Hardware make/model known, but graphics not "
|
|
|
|
"as expected.\n");
|
|
|
|
printf("Console may not work!\n");
|
|
|
|
}
|
|
|
|
|
2015-09-05 18:24:51 +00:00
|
|
|
/*
|
|
|
|
* The stride is equal or larger to the width. Often it's the
|
|
|
|
* next larger power of two. We'll start with that...
|
|
|
|
*/
|
|
|
|
efifb->fb_stride = efifb->fb_width;
|
|
|
|
do {
|
|
|
|
np = efifb->fb_stride & (efifb->fb_stride - 1);
|
|
|
|
if (np) {
|
|
|
|
efifb->fb_stride |= (np - 1);
|
|
|
|
efifb->fb_stride++;
|
|
|
|
}
|
|
|
|
} while (np);
|
|
|
|
|
2015-09-07 17:56:49 +00:00
|
|
|
ev = getenv("hw.efifb.address");
|
2015-09-05 03:27:23 +00:00
|
|
|
if (ev == NULL) {
|
2015-09-07 17:56:49 +00:00
|
|
|
if (efifb->fb_addr == 0) {
|
|
|
|
printf("Please set hw.efifb.address and "
|
|
|
|
"hw.efifb.stride.\n");
|
2015-09-05 03:27:23 +00:00
|
|
|
return (1);
|
2015-09-05 18:24:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The visible part of the frame buffer may not start at
|
|
|
|
* offset 0, so try to detect it. Note that we may not
|
|
|
|
* always be able to read from the frame buffer, which
|
|
|
|
* means that we may not be able to detect anything. In
|
|
|
|
* that case, we would take a long time scanning for a
|
|
|
|
* pixel change in the frame buffer, which would have it
|
|
|
|
* appear that we're hanging, so we limit the scan to
|
|
|
|
* 1/256th of the frame buffer. This number is mostly
|
|
|
|
* based on PR 202730 and the fact that on a MacBoook,
|
|
|
|
* where we can't read from the frame buffer the offset
|
|
|
|
* of the visible region is 0. In short: we want to scan
|
|
|
|
* enough to handle all adapters that have an offset
|
|
|
|
* larger than 0 and we want to scan as little as we can
|
|
|
|
* to not appear to hang when we can't read from the
|
|
|
|
* frame buffer.
|
|
|
|
*/
|
2015-09-07 17:56:49 +00:00
|
|
|
offset = efifb_uga_find_pixel(uga, 0, pciio, efifb->fb_addr,
|
2015-09-05 18:24:51 +00:00
|
|
|
efifb->fb_size >> 8);
|
2015-09-07 17:56:49 +00:00
|
|
|
if (offset == -1) {
|
2015-09-05 18:24:51 +00:00
|
|
|
printf("Unable to reliably detect frame buffer.\n");
|
2015-09-07 17:56:49 +00:00
|
|
|
} else if (offset > 0) {
|
|
|
|
efifb->fb_addr += offset;
|
|
|
|
efifb->fb_size -= offset;
|
2015-09-05 18:24:51 +00:00
|
|
|
}
|
2015-09-05 03:27:23 +00:00
|
|
|
} else {
|
2015-09-07 17:56:49 +00:00
|
|
|
offset = 0;
|
2015-09-05 18:24:51 +00:00
|
|
|
efifb->fb_size = efifb->fb_height * efifb->fb_stride * 4;
|
2015-09-05 03:27:23 +00:00
|
|
|
efifb->fb_addr = strtoul(ev, &p, 0);
|
|
|
|
if (*p != '\0')
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
2015-09-07 17:56:49 +00:00
|
|
|
ev = getenv("hw.efifb.stride");
|
2015-09-05 03:27:23 +00:00
|
|
|
if (ev == NULL) {
|
2015-09-07 17:56:49 +00:00
|
|
|
if (pciio != NULL && offset != -1) {
|
2015-09-05 18:24:51 +00:00
|
|
|
/* Determine the stride. */
|
2015-09-07 17:56:49 +00:00
|
|
|
offset = efifb_uga_find_pixel(uga, 1, pciio,
|
2015-09-05 18:24:51 +00:00
|
|
|
efifb->fb_addr, horiz * 8);
|
2015-09-07 17:56:49 +00:00
|
|
|
if (offset != -1)
|
|
|
|
efifb->fb_stride = offset >> 2;
|
2015-09-05 18:24:51 +00:00
|
|
|
} else {
|
|
|
|
printf("Unable to reliably detect the stride.\n");
|
|
|
|
}
|
2015-09-05 03:27:23 +00:00
|
|
|
} else {
|
|
|
|
efifb->fb_stride = strtoul(ev, &p, 0);
|
|
|
|
if (*p != '\0')
|
|
|
|
return (1);
|
|
|
|
}
|
2015-09-05 18:24:51 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We finalized on the stride, so recalculate the size of the
|
|
|
|
* frame buffer.
|
|
|
|
*/
|
|
|
|
efifb->fb_size = efifb->fb_height * efifb->fb_stride * 4;
|
Support UEFI booting on amd64 via loader.efi
This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.
Specific revisions of note from projects/uefi:
r247380:
Adjust our load device when we boot from CD under UEFI.
The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.
To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.
Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r246231:
Add necessary code to hand off from loader to an amd64 kernel.
r246335:
Grab the EFI memory map and store it as module metadata on the kernel.
This is the same approach used to provide the BIOS SMAP to the kernel.
r246336:
Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.
r246608:
Rework copy routines to ensure we always use memory allocated via EFI.
The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.
r247214:
Fix a number of problems preventing proper handover to the kernel.
There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.
Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.
r247216:
Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.
Sponsored by: The FreeBSD Foundation
2014-04-04 00:16:46 +00:00
|
|
|
return (0);
|
|
|
|
}
|
2015-08-30 01:39:59 +00:00
|
|
|
|
2021-02-20 08:51:28 +00:00
|
|
|
/*
|
|
|
|
* Fetch EDID info. Caller must free the buffer.
|
|
|
|
*/
|
|
|
|
static struct vesa_edid_info *
|
|
|
|
efifb_gop_get_edid(EFI_HANDLE h)
|
|
|
|
{
|
|
|
|
const uint8_t magic[] = EDID_MAGIC;
|
|
|
|
EFI_EDID_ACTIVE_PROTOCOL *edid;
|
|
|
|
struct vesa_edid_info *edid_infop;
|
|
|
|
EFI_GUID *guid;
|
|
|
|
EFI_STATUS status;
|
|
|
|
size_t size;
|
|
|
|
|
|
|
|
guid = &active_edid_guid;
|
|
|
|
status = BS->OpenProtocol(h, guid, (void **)&edid, IH, NULL,
|
|
|
|
EFI_OPEN_PROTOCOL_GET_PROTOCOL);
|
|
|
|
if (status != EFI_SUCCESS ||
|
|
|
|
edid->SizeOfEdid == 0) {
|
|
|
|
guid = &discovered_edid_guid;
|
|
|
|
status = BS->OpenProtocol(h, guid, (void **)&edid, IH, NULL,
|
|
|
|
EFI_OPEN_PROTOCOL_GET_PROTOCOL);
|
|
|
|
if (status != EFI_SUCCESS ||
|
|
|
|
edid->SizeOfEdid == 0)
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
size = MAX(sizeof(*edid_infop), edid->SizeOfEdid);
|
|
|
|
|
|
|
|
edid_infop = calloc(1, size);
|
|
|
|
if (edid_infop == NULL)
|
|
|
|
return (NULL);
|
|
|
|
|
|
|
|
memcpy(edid_infop, edid->Edid, edid->SizeOfEdid);
|
|
|
|
|
|
|
|
/* Validate EDID */
|
|
|
|
if (memcmp(edid_infop, magic, sizeof (magic)) != 0)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
if (edid_infop->header.version != 1)
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
return (edid_infop);
|
|
|
|
error:
|
|
|
|
free(edid_infop);
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
efifb_get_edid(edid_res_list_t *res)
|
|
|
|
{
|
|
|
|
bool rv = false;
|
|
|
|
|
|
|
|
if (edid_info == NULL)
|
|
|
|
edid_info = efifb_gop_get_edid(gop_handle);
|
|
|
|
|
|
|
|
if (edid_info != NULL)
|
|
|
|
rv = gfx_get_edid_resolution(edid_info, res);
|
|
|
|
|
|
|
|
return (rv);
|
|
|
|
}
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
int
|
2021-01-11 21:54:23 +00:00
|
|
|
efi_find_framebuffer(teken_gfx_t *gfx_state)
|
2015-08-30 23:58:53 +00:00
|
|
|
{
|
2021-02-20 08:51:28 +00:00
|
|
|
EFI_HANDLE *hlist;
|
2021-01-16 17:51:23 +00:00
|
|
|
UINTN nhandles, i, hsize;
|
2021-01-11 21:54:23 +00:00
|
|
|
struct efi_fb efifb;
|
2015-08-30 23:58:53 +00:00
|
|
|
EFI_STATUS status;
|
2021-01-11 21:54:23 +00:00
|
|
|
int rv;
|
|
|
|
|
|
|
|
gfx_state->tg_fb_type = FB_TEXT;
|
2015-08-30 23:58:53 +00:00
|
|
|
|
2021-01-16 17:51:23 +00:00
|
|
|
hsize = 0;
|
2021-01-17 11:46:00 +00:00
|
|
|
hlist = NULL;
|
2021-01-16 17:51:23 +00:00
|
|
|
status = BS->LocateHandle(ByProtocol, &gop_guid, NULL, &hsize, hlist);
|
|
|
|
if (status == EFI_BUFFER_TOO_SMALL) {
|
|
|
|
hlist = malloc(hsize);
|
|
|
|
if (hlist == NULL)
|
|
|
|
return (ENOMEM);
|
|
|
|
status = BS->LocateHandle(ByProtocol, &gop_guid, NULL, &hsize,
|
|
|
|
hlist);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
free(hlist);
|
|
|
|
}
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
return (efi_status_to_errno(status));
|
|
|
|
|
|
|
|
nhandles = hsize / sizeof(*hlist);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search for ConOut protocol, if not found, use first handle.
|
|
|
|
*/
|
2021-02-20 08:51:28 +00:00
|
|
|
gop_handle = *hlist;
|
2021-01-16 17:51:23 +00:00
|
|
|
for (i = 0; i < nhandles; i++) {
|
|
|
|
void *dummy = NULL;
|
|
|
|
|
|
|
|
status = OpenProtocolByHandle(hlist[i], &conout_guid, &dummy);
|
|
|
|
if (status == EFI_SUCCESS) {
|
2021-02-20 08:51:28 +00:00
|
|
|
gop_handle = hlist[i];
|
2021-01-16 17:51:23 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-20 08:51:28 +00:00
|
|
|
status = OpenProtocolByHandle(gop_handle, &gop_guid, (void **)&gop);
|
2021-01-16 17:51:23 +00:00
|
|
|
free(hlist);
|
|
|
|
|
2021-01-11 21:54:23 +00:00
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
gfx_state->tg_fb_type = FB_GOP;
|
|
|
|
gfx_state->tg_private = gop;
|
2021-02-20 08:51:28 +00:00
|
|
|
if (edid_info == NULL)
|
|
|
|
edid_info = efifb_gop_get_edid(gop_handle);
|
2021-01-11 21:54:23 +00:00
|
|
|
} else {
|
|
|
|
status = BS->LocateProtocol(&uga_guid, NULL, (VOID **)&uga);
|
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
gfx_state->tg_fb_type = FB_UGA;
|
|
|
|
gfx_state->tg_private = uga;
|
|
|
|
} else {
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
}
|
2015-08-30 23:58:53 +00:00
|
|
|
|
2021-01-11 21:54:23 +00:00
|
|
|
switch (gfx_state->tg_fb_type) {
|
|
|
|
case FB_GOP:
|
|
|
|
rv = efifb_from_gop(&efifb, gop->Mode, gop->Mode->Info);
|
|
|
|
break;
|
2015-08-30 23:58:53 +00:00
|
|
|
|
2021-01-11 21:54:23 +00:00
|
|
|
case FB_UGA:
|
2021-01-17 13:07:27 +00:00
|
|
|
rv = efifb_from_uga(&efifb);
|
2021-01-11 21:54:23 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
return (1);
|
|
|
|
}
|
|
|
|
|
|
|
|
gfx_state->tg_fb.fb_addr = efifb.fb_addr;
|
|
|
|
gfx_state->tg_fb.fb_size = efifb.fb_size;
|
|
|
|
gfx_state->tg_fb.fb_height = efifb.fb_height;
|
|
|
|
gfx_state->tg_fb.fb_width = efifb.fb_width;
|
|
|
|
gfx_state->tg_fb.fb_stride = efifb.fb_stride;
|
|
|
|
gfx_state->tg_fb.fb_mask_red = efifb.fb_mask_red;
|
|
|
|
gfx_state->tg_fb.fb_mask_green = efifb.fb_mask_green;
|
|
|
|
gfx_state->tg_fb.fb_mask_blue = efifb.fb_mask_blue;
|
|
|
|
gfx_state->tg_fb.fb_mask_reserved = efifb.fb_mask_reserved;
|
|
|
|
|
|
|
|
gfx_state->tg_fb.fb_bpp = fls(efifb.fb_mask_red | efifb.fb_mask_green |
|
|
|
|
efifb.fb_mask_blue | efifb.fb_mask_reserved);
|
|
|
|
|
|
|
|
return (0);
|
2015-08-30 23:58:53 +00:00
|
|
|
}
|
2015-08-30 01:39:59 +00:00
|
|
|
|
|
|
|
static void
|
2015-08-30 23:58:53 +00:00
|
|
|
print_efifb(int mode, struct efi_fb *efifb, int verbose)
|
2015-08-30 01:39:59 +00:00
|
|
|
{
|
2015-08-30 23:58:53 +00:00
|
|
|
u_int depth;
|
2015-08-30 01:39:59 +00:00
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
if (mode >= 0)
|
|
|
|
printf("mode %d: ", mode);
|
2015-09-03 04:35:17 +00:00
|
|
|
depth = efifb_color_depth(efifb);
|
2015-08-30 23:58:53 +00:00
|
|
|
printf("%ux%ux%u, stride=%u", efifb->fb_width, efifb->fb_height,
|
|
|
|
depth, efifb->fb_stride);
|
|
|
|
if (verbose) {
|
|
|
|
printf("\n frame buffer: address=%jx, size=%jx",
|
|
|
|
(uintmax_t)efifb->fb_addr, (uintmax_t)efifb->fb_size);
|
|
|
|
printf("\n color mask: R=%08x, G=%08x, B=%08x\n",
|
|
|
|
efifb->fb_mask_red, efifb->fb_mask_green,
|
|
|
|
efifb->fb_mask_blue);
|
2015-08-30 01:39:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-23 21:02:46 +00:00
|
|
|
static bool
|
|
|
|
efi_resolution_compare(struct named_resolution *res, const char *cmp)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (strcasecmp(res->name, cmp) == 0)
|
|
|
|
return (true);
|
|
|
|
if (res->alias != NULL && strcasecmp(res->alias, cmp) == 0)
|
|
|
|
return (true);
|
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static void
|
|
|
|
efi_get_max_resolution(int *width, int *height)
|
|
|
|
{
|
|
|
|
struct named_resolution *res;
|
|
|
|
char *maxres;
|
|
|
|
char *height_start, *width_start;
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
*width = *height = 0;
|
|
|
|
maxres = getenv("efi_max_resolution");
|
|
|
|
/* No max_resolution set? Bail out; choose highest resolution */
|
|
|
|
if (maxres == NULL)
|
|
|
|
return;
|
|
|
|
/* See if it matches one of our known resolutions */
|
|
|
|
for (idx = 0; idx < nitems(resolutions); ++idx) {
|
|
|
|
res = &resolutions[idx];
|
|
|
|
if (efi_resolution_compare(res, maxres)) {
|
|
|
|
*width = res->width;
|
|
|
|
*height = res->height;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Not a known resolution, try to parse it; make a copy we can modify */
|
|
|
|
maxres = strdup(maxres);
|
|
|
|
if (maxres == NULL)
|
|
|
|
return;
|
|
|
|
height_start = strchr(maxres, 'x');
|
|
|
|
if (height_start == NULL) {
|
|
|
|
free(maxres);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
width_start = maxres;
|
|
|
|
*height_start++ = 0;
|
|
|
|
/* Errors from this will effectively mean "no max" */
|
|
|
|
*width = (int)strtol(width_start, NULL, 0);
|
|
|
|
*height = (int)strtol(height_start, NULL, 0);
|
|
|
|
free(maxres);
|
|
|
|
}
|
|
|
|
|
2018-03-21 20:36:57 +00:00
|
|
|
static int
|
2021-01-17 13:07:27 +00:00
|
|
|
gop_autoresize(void)
|
2018-03-21 20:36:57 +00:00
|
|
|
{
|
|
|
|
struct efi_fb efifb;
|
|
|
|
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *info;
|
|
|
|
EFI_STATUS status;
|
|
|
|
UINTN infosz;
|
|
|
|
UINT32 best_mode, currdim, maxdim, mode;
|
2018-03-23 21:02:46 +00:00
|
|
|
int height, max_height, max_width, width;
|
2018-03-21 20:36:57 +00:00
|
|
|
|
|
|
|
best_mode = maxdim = 0;
|
2018-03-23 21:02:46 +00:00
|
|
|
efi_get_max_resolution(&max_width, &max_height);
|
2018-03-21 20:36:57 +00:00
|
|
|
for (mode = 0; mode < gop->Mode->MaxMode; mode++) {
|
|
|
|
status = gop->QueryMode(gop, mode, &infosz, &info);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
continue;
|
|
|
|
efifb_from_gop(&efifb, gop->Mode, info);
|
2018-03-23 21:02:46 +00:00
|
|
|
width = info->HorizontalResolution;
|
|
|
|
height = info->VerticalResolution;
|
|
|
|
currdim = width * height;
|
2018-03-21 20:36:57 +00:00
|
|
|
if (currdim > maxdim) {
|
2018-03-23 21:02:46 +00:00
|
|
|
if ((max_width != 0 && width > max_width) ||
|
|
|
|
(max_height != 0 && height > max_height))
|
|
|
|
continue;
|
2018-03-21 20:36:57 +00:00
|
|
|
maxdim = currdim;
|
|
|
|
best_mode = mode;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-19 03:31:41 +00:00
|
|
|
if (maxdim != 0) {
|
|
|
|
status = gop->SetMode(gop, best_mode);
|
|
|
|
if (EFI_ERROR(status)) {
|
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
|
|
|
"gop_autoresize: Unable to set mode to %u (error=%lu)",
|
|
|
|
mode, EFI_ERROR_CODE(status));
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
2020-12-21 05:31:16 +00:00
|
|
|
(void) cons_update_mode(true);
|
2018-03-21 20:36:57 +00:00
|
|
|
}
|
|
|
|
return (CMD_OK);
|
|
|
|
}
|
|
|
|
|
2018-03-24 01:53:43 +00:00
|
|
|
static int
|
|
|
|
text_autoresize()
|
|
|
|
{
|
|
|
|
SIMPLE_TEXT_OUTPUT_INTERFACE *conout;
|
|
|
|
EFI_STATUS status;
|
|
|
|
UINTN i, max_dim, best_mode, cols, rows;
|
|
|
|
|
|
|
|
conout = ST->ConOut;
|
|
|
|
max_dim = best_mode = 0;
|
|
|
|
for (i = 0; i < conout->Mode->MaxMode; i++) {
|
|
|
|
status = conout->QueryMode(conout, i, &cols, &rows);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
continue;
|
|
|
|
if (cols * rows > max_dim) {
|
|
|
|
max_dim = cols * rows;
|
|
|
|
best_mode = i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (max_dim > 0)
|
|
|
|
conout->SetMode(conout, best_mode);
|
2020-12-21 05:31:16 +00:00
|
|
|
(void) cons_update_mode(true);
|
2018-03-24 01:53:43 +00:00
|
|
|
return (CMD_OK);
|
|
|
|
}
|
|
|
|
|
2018-03-21 20:36:57 +00:00
|
|
|
static int
|
2021-01-17 13:07:27 +00:00
|
|
|
uga_autoresize(void)
|
2018-03-21 20:36:57 +00:00
|
|
|
{
|
|
|
|
|
2018-03-26 13:45:17 +00:00
|
|
|
return (text_autoresize());
|
2018-03-21 20:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
COMMAND_SET(efi_autoresize, "efi-autoresizecons", "EFI Auto-resize Console", command_autoresize);
|
|
|
|
|
|
|
|
static int
|
|
|
|
command_autoresize(int argc, char *argv[])
|
|
|
|
{
|
2018-03-24 01:53:43 +00:00
|
|
|
char *textmode;
|
2018-03-21 20:36:57 +00:00
|
|
|
|
2018-03-24 01:53:43 +00:00
|
|
|
textmode = getenv("hw.vga.textmode");
|
|
|
|
/* If it's set and non-zero, we'll select a console mode instead */
|
|
|
|
if (textmode != NULL && strcmp(textmode, "0") != 0)
|
|
|
|
return (text_autoresize());
|
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
if (gop != NULL)
|
|
|
|
return (gop_autoresize());
|
2018-03-21 20:36:57 +00:00
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
if (uga != NULL)
|
|
|
|
return (uga_autoresize());
|
2018-03-21 20:36:57 +00:00
|
|
|
|
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
|
|
|
"%s: Neither Graphics Output Protocol nor Universal Graphics Adapter present",
|
|
|
|
argv[0]);
|
2018-08-04 06:40:18 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Default to text_autoresize if we have neither GOP or UGA. This won't
|
|
|
|
* give us the most ideal resolution, but it will at least leave us
|
|
|
|
* functional rather than failing the boot for an objectively bad
|
|
|
|
* reason.
|
|
|
|
*/
|
|
|
|
return (text_autoresize());
|
2018-03-21 20:36:57 +00:00
|
|
|
}
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
COMMAND_SET(gop, "gop", "graphics output protocol", command_gop);
|
|
|
|
|
2015-08-30 01:39:59 +00:00
|
|
|
static int
|
|
|
|
command_gop(int argc, char *argv[])
|
|
|
|
{
|
2015-08-30 23:58:53 +00:00
|
|
|
struct efi_fb efifb;
|
2015-08-30 01:39:59 +00:00
|
|
|
EFI_STATUS status;
|
|
|
|
u_int mode;
|
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
if (gop == NULL) {
|
2016-08-20 16:23:19 +00:00
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
2021-01-17 13:07:27 +00:00
|
|
|
"%s: Graphics Output Protocol not present", argv[0]);
|
2015-08-30 01:39:59 +00:00
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
if (argc < 2)
|
2015-08-30 01:39:59 +00:00
|
|
|
goto usage;
|
|
|
|
|
|
|
|
if (!strcmp(argv[1], "set")) {
|
|
|
|
char *cp;
|
|
|
|
|
|
|
|
if (argc != 3)
|
|
|
|
goto usage;
|
|
|
|
mode = strtol(argv[2], &cp, 0);
|
|
|
|
if (cp[0] != '\0') {
|
|
|
|
sprintf(command_errbuf, "mode is an integer");
|
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
status = gop->SetMode(gop, mode);
|
|
|
|
if (EFI_ERROR(status)) {
|
2016-08-20 16:23:19 +00:00
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
|
|
|
"%s: Unable to set mode to %u (error=%lu)",
|
|
|
|
argv[0], mode, EFI_ERROR_CODE(status));
|
2015-08-30 01:39:59 +00:00
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
2020-12-21 05:31:16 +00:00
|
|
|
(void) cons_update_mode(true);
|
|
|
|
} else if (strcmp(argv[1], "off") == 0) {
|
|
|
|
(void) cons_update_mode(false);
|
|
|
|
} else if (strcmp(argv[1], "get") == 0) {
|
2021-02-20 08:51:28 +00:00
|
|
|
edid_res_list_t res;
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
if (argc != 2)
|
|
|
|
goto usage;
|
2021-02-20 08:51:28 +00:00
|
|
|
TAILQ_INIT(&res);
|
2015-08-30 23:58:53 +00:00
|
|
|
efifb_from_gop(&efifb, gop->Mode, gop->Mode->Info);
|
2021-02-20 08:51:28 +00:00
|
|
|
if (efifb_get_edid(&res)) {
|
|
|
|
struct resolution *rp;
|
|
|
|
|
|
|
|
printf("EDID");
|
|
|
|
while ((rp = TAILQ_FIRST(&res)) != NULL) {
|
|
|
|
printf(" %dx%d", rp->width, rp->height);
|
|
|
|
TAILQ_REMOVE(&res, rp, next);
|
|
|
|
free(rp);
|
|
|
|
}
|
|
|
|
printf("\n");
|
|
|
|
} else {
|
|
|
|
printf("no EDID information\n");
|
|
|
|
}
|
2015-08-30 23:58:53 +00:00
|
|
|
print_efifb(gop->Mode->Mode, &efifb, 1);
|
|
|
|
printf("\n");
|
2015-08-30 01:39:59 +00:00
|
|
|
} else if (!strcmp(argv[1], "list")) {
|
|
|
|
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *info;
|
|
|
|
UINTN infosz;
|
|
|
|
|
2015-08-30 23:58:53 +00:00
|
|
|
if (argc != 2)
|
|
|
|
goto usage;
|
2021-02-20 08:51:28 +00:00
|
|
|
|
2015-08-30 01:39:59 +00:00
|
|
|
pager_open();
|
|
|
|
for (mode = 0; mode < gop->Mode->MaxMode; mode++) {
|
|
|
|
status = gop->QueryMode(gop, mode, &infosz, &info);
|
|
|
|
if (EFI_ERROR(status))
|
|
|
|
continue;
|
2015-08-30 23:58:53 +00:00
|
|
|
efifb_from_gop(&efifb, gop->Mode, info);
|
|
|
|
print_efifb(mode, &efifb, 0);
|
2015-08-30 01:39:59 +00:00
|
|
|
if (pager_output("\n"))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
pager_close();
|
|
|
|
}
|
|
|
|
return (CMD_OK);
|
|
|
|
|
|
|
|
usage:
|
2016-08-20 16:23:19 +00:00
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
2020-12-21 05:31:16 +00:00
|
|
|
"usage: %s [list | get | set <mode> | off]", argv[0]);
|
2015-08-30 01:39:59 +00:00
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
2015-08-30 23:58:53 +00:00
|
|
|
|
|
|
|
COMMAND_SET(uga, "uga", "universal graphics adapter", command_uga);
|
|
|
|
|
|
|
|
static int
|
|
|
|
command_uga(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
struct efi_fb efifb;
|
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
if (uga == NULL) {
|
2016-08-20 16:23:19 +00:00
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
2021-01-17 13:07:27 +00:00
|
|
|
"%s: UGA Protocol not present", argv[0]);
|
2015-08-30 23:58:53 +00:00
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (argc != 1)
|
|
|
|
goto usage;
|
|
|
|
|
2021-01-17 13:07:27 +00:00
|
|
|
if (efifb_from_uga(&efifb) != CMD_OK) {
|
2016-08-20 16:23:19 +00:00
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf),
|
|
|
|
"%s: Unable to get UGA information", argv[0]);
|
2015-08-30 23:58:53 +00:00
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|
|
|
|
|
|
|
|
print_efifb(-1, &efifb, 1);
|
|
|
|
printf("\n");
|
|
|
|
return (CMD_OK);
|
|
|
|
|
|
|
|
usage:
|
2016-08-20 16:23:19 +00:00
|
|
|
snprintf(command_errbuf, sizeof(command_errbuf), "usage: %s", argv[0]);
|
2015-08-30 23:58:53 +00:00
|
|
|
return (CMD_ERROR);
|
|
|
|
}
|