freebsd-skq/sys/boot/efi/include/efigop.h
Ed Maste 8c00aba8c4 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

123 lines
2.8 KiB
C

/* $FreeBSD$ */
/*++
Copyright (c) 1999 - 2002 Intel Corporation. All rights reserved
This software and associated documentation (if any) is furnished
under a license and may only be used or copied in accordance
with the terms of the license. Except as permitted by such
license, no part of this software or documentation may be
reproduced, stored in a retrieval system, or transmitted in any
form or by any means without the express written consent of
Intel Corporation.
Module Name:
efigop.h
Abstract:
Info about framebuffers
Revision History
--*/
#ifndef _EFIGOP_H
#define _EFIGOP_H
#define EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID \
{ 0x9042a9de, 0x23dc, 0x4a38, 0x96, 0xfb, 0x7a, 0xde, 0xd0, 0x80, \
0x51, 0x6a }
INTERFACE_DECL(_EFI_GRAPHICS_OUTPUT);
typedef struct {
UINT32 RedMask;
UINT32 GreenMask;
UINT32 BlueMask;
UINT32 ReservedMask;
} EFI_PIXEL_BITMASK;
typedef enum {
PixelRedGreenBlueReserved8BitPerColor,
PixelBlueGreenRedReserved8BitPerColor,
PixelBitMask,
PixelBltOnly,
PixelFormatMax,
} EFI_GRAPHICS_PIXEL_FORMAT;
typedef struct {
UINT32 Version;
UINT32 HorizontalResolution;
UINT32 VerticalResolution;
EFI_GRAPHICS_PIXEL_FORMAT PixelFormat;
EFI_PIXEL_BITMASK PixelInformation;
UINT32 PixelsPerScanLine;
} EFI_GRAPHICS_OUTPUT_MODE_INFORMATION;
typedef struct {
UINT32 MaxMode;
UINT32 Mode;
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION *Info;
UINTN SizeOfInfo;
EFI_PHYSICAL_ADDRESS FrameBufferBase;
UINTN FrameBufferSize;
} EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE;
typedef
EFI_STATUS
(EFIAPI *EFI_GRAPHICS_OUTPUT_PROTOCOL_QUERY_MODE) (
IN struct _EFI_GRAPHICS_OUTPUT *This,
IN UINT32 ModeNumber,
OUT UINTN *SizeOfInfo,
OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION **Info
);
typedef
EFI_STATUS
(EFIAPI *EFI_GRAPHICS_OUTPUT_PROTOCOL_SET_MODE) (
IN struct _EFI_GRAPHICS_OUTPUT *This,
IN UINT32 ModeNumber
);
typedef struct {
UINT8 Blue;
UINT8 Green;
UINT8 Red;
UINT8 Reserved;
} EFI_GRAPHICS_OUTPUT_BLT_PIXEL;
typedef enum {
EfiBltVideoFill,
EfiBltVideoToBltBuffer,
EfiBltBufferToVideo,
EfiBltVideoToVideo,
EfiGraphcisOutputBltOperationMax,
} EFI_GRAPHICS_OUTPUT_BLT_OPERATION;
typedef
EFI_STATUS
(EFIAPI *EFI_GRAPHICS_OUTPUT_PROTOCOL_BLT) (
IN struct _EFI_GRAPHICS_OUTPUT *This,
IN OUT EFI_GRAPHICS_OUTPUT_BLT_PIXEL *BltBuffer,
IN EFI_GRAPHICS_OUTPUT_BLT_OPERATION BltOperation,
IN UINTN SourceX,
IN UINTN SourceY,
IN UINTN DestinationX,
IN UINTN DestinationY,
IN UINTN Width,
IN UINTN Height,
IN UINTN Delta
);
typedef struct _EFI_GRAPHICS_OUTPUT {
EFI_GRAPHICS_OUTPUT_PROTOCOL_QUERY_MODE QueryMode;
EFI_GRAPHICS_OUTPUT_PROTOCOL_SET_MODE SetMode;
EFI_GRAPHICS_OUTPUT_PROTOCOL_BLT Blt;
EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE *Mode;
} EFI_GRAPHICS_OUTPUT;
#endif /* _EFIGOP_H */