* GOP:Frame Buffer memory type?
@ 2018-03-15 16:09 Evan Lloyd
2018-03-15 16:17 ` Ard Biesheuvel
0 siblings, 1 reply; 2+ messages in thread
From: Evan Lloyd @ 2018-03-15 16:09 UTC (permalink / raw)
To: edk2-devel (edk2-devel@lists.01.org)
Cc: Leif Lindholm, Matteo Carlini, Ard Biesheuvel, Girish Pathak
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: GOP:Frame Buffer memory type?
2018-03-15 16:09 GOP:Frame Buffer memory type? Evan Lloyd
@ 2018-03-15 16:17 ` Ard Biesheuvel
0 siblings, 0 replies; 2+ messages in thread
From: Ard Biesheuvel @ 2018-03-15 16:17 UTC (permalink / raw)
To: Evan Lloyd
Cc: edk2-devel (edk2-devel@lists.01.org), Leif Lindholm,
Matteo Carlini, Girish Pathak
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)
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-03-15 16:11 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-15 16:09 GOP:Frame Buffer memory type? Evan Lloyd
2018-03-15 16:17 ` Ard Biesheuvel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox