From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 057CE1A1E30 for ; Tue, 11 Oct 2016 22:35:14 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id b75so62719636lfg.3 for ; Tue, 11 Oct 2016 22:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s4ALrs0VN2C/sbusdKOmvOGzirGoQ73b13V/ER9s7oA=; b=cPaVfRAYmkLZSWjxOavLBLcddr4+ARBKjvzZRBfz+0GTK86ff2T84FVw+HIzAogHGg 1ZzRBEP+pcfX5ukf2vGez49U6yXcJd5eU19v3e6uGm5KqDvIferTbLGr6f4DEHscx1Io MzWErlq6NlhfdNmyjkKYZ9glcJR8XE1Ke2Pm4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s4ALrs0VN2C/sbusdKOmvOGzirGoQ73b13V/ER9s7oA=; b=ImBEs5RiLuzBsFVsdFwxkRZKVDkuWVVw7v/V6sVjhST4u7JXy3Q8WlqipDDDNIBqpZ k441+8bQw1MDVYZmtIgyis1svuGvXhWpxLYnv1kp8KkiEitkF8EwtZ0xe55Dg5qOwWKT 8fDoKe4LkLFhF1J4AiJLQlY6Xg7Mntq2SCY9WgHA6l0uSHrtzOHCNogS0mdNqHPFN11X wsTj8DexHE18VES8ZlfmvzQGIu7aqcixnpQ7M7iQtbPYbiP3E10zi/KJPjt/jCwyh9Zy 52LZmHAKC3H/NWyBhfCGE88aKrU+ZxRsJQqktuIS2wrzYPMyGxzQ+Edla/j4WPpqkfoT 22qQ== X-Gm-Message-State: AA6/9RnymxlvX79pvpk5uhwd4ifLlUP8NK5vEn8pw0Rm0g9Q3eQxjg+yo1xF8GXTBNWJYlW7zadqe3Wf/FmfwHHf X-Received: by 10.25.7.201 with SMTP id 192mr5961193lfh.170.1476250512048; Tue, 11 Oct 2016 22:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.190.83 with HTTP; Tue, 11 Oct 2016 22:35:11 -0700 (PDT) Received: by 10.25.190.83 with HTTP; Tue, 11 Oct 2016 22:35:11 -0700 (PDT) In-Reply-To: References: From: Ryan Harkin Date: Wed, 12 Oct 2016 06:35:11 +0100 Message-ID: To: Ard Biesheuvel Cc: Leif Lindholm , "edk2-devel@lists.01.org" , Evan Lloyd X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: ArmPlatformPkg: Allocate VRAM as RuntimeServicesData X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 05:35:14 -0000 Content-Type: text/plain; charset=UTF-8 On 11 Oct 2016 20:17, "Ard Biesheuvel" wrote: > > On 11 October 2016 at 18:44, Ryan Harkin 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. > Fair enough, I'll leave it! > > > > On 4 March 2016 at 15:57, wrote: > >> Code at: https://github.com/EvanLloyd/tianocore/commit/ > >> From: Sami Mujawar > >> 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 > >> Signed-off-by: Girish Pathak > >> Signed-off-by: Sami Mujawar > >> Signed-off-by: Evan Lloyd > >> --- > >> 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