GOP:Frame Buffer memory type?

GOP:Frame Buffer memory type?

[Evan Lloyd]

The EFI_GRAPHICS_OUTPUT_PROTOCOL provides for a frame buffer:
"FrameBufferBase  Base  address of graphics linear frame buffer. Info contains information required to allow software to draw directly to the frame buffer without using Blt().Offset zero in FrameBufferBase represents the upper left pixel of the display."

The spec is silent on how (or if) the frame buffer should appear in the memory map.  The obvious option is EfiMemoryMappedIO, however the spec has (Table 29. "Memory Type Usage after ExitBootServices") :
"EfiMemoryMappedIO
This memory is not used by the OS. All system memory-mapped IO information should come from ACPI tables."
This is slightly problematic because the GOP Frame Buffer is not described in an ACPI table.

Most options are obviously unusable (like "EfiBootServicesData  Memory available for general use.") as the "available for general use" basically means overwritten by OS memory usage, so the pixels corrupt OS data.

So -  can anyone advise us on whether there is some "Standard" way of doing this, is this an undefined area, or have we missed something?

Regards,
Evan

Evan Lloyd | Technical Lead for Windows on Arm | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m. +44 (0)7825256132
110 Fulbourn Road, Cambridge, CB1 9NJ
Arm.com

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: GOP:Frame Buffer memory type?

[Ard Biesheuvel]

On 15 March 2018 at 16:09, Evan Lloyd <Evan.Lloyd@arm.com> wrote:
> The EFI_GRAPHICS_OUTPUT_PROTOCOL provides for a frame buffer:
>
> “FrameBufferBase  Base  address of graphics linear frame buffer. Info
> contains information required to allow software to draw directly to the
> frame buffer without using Blt().Offset zero in FrameBufferBase represents
> the upper left pixel of the display.”
>
>
>
> The spec is silent on how (or if) the frame buffer should appear in the
> memory map.  The obvious option is EfiMemoryMappedIO, however the spec has
> (Table 29. “Memory Type Usage after ExitBootServices”) :
>
> “EfiMemoryMappedIO
>
> This memory is not used by the OS. All system memory-mapped IO information
> should come from ACPI tables.”
>
> This is slightly problematic because the GOP Frame Buffer is not described
> in an ACPI table.
>
>
>
> Most options are obviously unusable (like “EfiBootServicesData  Memory
> available for general use.”) as the “available for general use” basically
> means overwritten by OS memory usage, so the pixels corrupt OS data.
>
>
>
> So –  can anyone advise us on whether there is some “Standard” way of doing
> this, is this an undefined area, or have we missed something?
>

The UEFI memory map contains two things:
- all memory in the system, no matter how it is used
- other memory regions that may require a virtual mapping to be
provided by the OS in order for the firmware itself to be able to keep
using the device, e.g., the NOR flash or the RTC

So it depends on whether the actual backing of the framebuffer is DRAM
or not. If it is, the memory should be marked as 'reserved' in the
memory map (in which case it cannot be reclaimed). If the framebuffer
is PCI memory or some other non-DRAM resource, it should not appear in
the memory map at all.

(Note that the firmware itself will never access the framebuffer at
runtime, so a virtual mapping should never be needed)