From: Evan Lloyd <Evan.Lloyd@arm.com>
To: "edk2-devel (edk2-devel@lists.01.org)" <edk2-devel@lists.01.org>
Cc: Leif Lindholm <Leif.Lindholm@arm.com>,
Matteo Carlini <Matteo.Carlini@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
"Girish Pathak" <Girish.Pathak@arm.com>
Subject: GOP:Frame Buffer memory type?
Date: Thu, 15 Mar 2018 16:09:45 +0000 [thread overview]
Message-ID: <HE1PR0801MB17713A93810E214E9DF681388BD00@HE1PR0801MB1771.eurprd08.prod.outlook.com> (raw)
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.
next reply other threads:[~2018-03-15 16:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 16:09 Evan Lloyd [this message]
2018-03-15 16:17 ` GOP:Frame Buffer memory type? Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=HE1PR0801MB17713A93810E214E9DF681388BD00@HE1PR0801MB1771.eurprd08.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox