From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Ryan Harkin <ryan.harkin@linaro.org>
Cc: Evan Lloyd <evan.lloyd@arm.com>,
"edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>,
Leif Lindholm <leif.lindholm@linaro.org>
Subject: Re: ArmPlatformPkg: Allocate VRAM as RuntimeServicesData
Date: Tue, 11 Oct 2016 20:17:16 +0100 [thread overview]
Message-ID: <CAKv+Gu8ERvzPSAb4RdQU=db4MHwO=8hk62-T1umFRw9B5GXzmQ@mail.gmail.com> (raw)
In-Reply-To: <CAD0U-h++vNdVORDt8e5bJdhXpyQXfiiZsi4EG7wDCsOUxWYEJA@mail.gmail.com>
On 11 October 2016 at 18:44, Ryan Harkin <ryan.harkin@linaro.org> wrote:
> Hi Evan,
>
> This was sent to the list with no subject line and I wasn't on CC, so
> I didn't see it.
>
> Are you still using this patch and want it in, i.e. does it need
> review and test?
>
I'm sure it works, but I don't think we should take it.
RuntimeServicesData can never be released to the OS, so taking an 8MB
chunk just in case the OS may decide to drive the framebuffer using
the firmware's protocol rather than via a native driver is not
something we should have in reference code.
The GOP protocol is arguably a hack anyway, since the entire protocol
database and driver tree are torn down after ExitBootServices(), while
the GOP leaves a live memory range in place that happens to keep
operating as a framebuffer. If the OS wants to use this protocol
during normal operation, it should take care to reserve this memory
region itself.
I am aware that not all OSes may behave correctly in this regard. This
is mainly due to the fact that GOP is usually implemented by a PCI
device, which exposes the framebuffer via a PCI BAR rather than via a
system memory range.
> On 4 March 2016 at 15:57, <evan.lloyd@arm.com> wrote:
>> Code at: https://github.com/EvanLloyd/tianocore/commit/
>> From: Sami Mujawar <sami.mujawar@arm.com>
>> Date: Thu, 25 Feb 2016 15:07:40 +0000
>> Subject: [PATCH] ArmPlatformPkg: Allocate VRAM as RuntimeServicesData
>>
>> The UEFI specification allows the operating system (OS) to use the
>> Graphics Output Protocol (GOP) in the following scenarios:
>> a. as part of the startup process and
>> b. prior to loading of a high performance OS graphics driver
>>
>> If the VRAM is allocated as BootServicesData, then it is unmapped on
>> exit boot services. This prevents GOP usage by the OS post exit boot
>> services (the second scenario); as it results in a crash when the VRAM
>> is accessed.
>>
>> This patch fixes the issue by allocating VRAM as RuntimeServicesData.
>>
>> Code at: https://github.com/EvanLloyd/tianocore/commit/18fab16a63c59c84c71cd81089a55a4081ebe253
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Alexei Fedorov <alexei.fedorov@arm.com>
>> Signed-off-by: Girish Pathak <girish.pathak@arm.com>
>> Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
>> Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
>> ---
>> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>> index a578467..4ab8862 100644
>> --- a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>> +++ b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
>> @@ -133,7 +133,7 @@ LcdPlatformGetVram (
>> } else {
>> AllocationType = AllocateAddress;
>> }
>> - Status = gBS->AllocatePages (AllocationType, EfiBootServicesData, EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
>> + Status = gBS->AllocatePages (AllocationType, EfiRuntimeServicesData, EFI_SIZE_TO_PAGES(((UINTN)LCD_VRAM_SIZE)), VramBaseAddress);
>> if (EFI_ERROR(Status)) {
>> return Status;
>> }
>> --
>> 2.7.0
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2016-10-11 19:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 17:44 ArmPlatformPkg: Allocate VRAM as RuntimeServicesData Ryan Harkin
2016-10-11 19:17 ` Ard Biesheuvel [this message]
2016-10-12 5:35 ` Ryan Harkin
2016-10-12 11:39 ` Evan Lloyd
2016-10-12 12:53 ` Ryan Harkin
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='CAKv+Gu8ERvzPSAb4RdQU=db4MHwO=8hk62-T1umFRw9B5GXzmQ@mail.gmail.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