From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=104.47.2.67; helo=eur01-db5-obe.outbound.protection.outlook.com; envelope-from=evan.lloyd@arm.com; receiver=edk2-devel@lists.01.org Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0067.outbound.protection.outlook.com [104.47.2.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 81E7220954BBE for ; Thu, 15 Mar 2018 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ONK5uR9RXk2N8RlMJbXOXNzgKeUhPbzmxaQKGHiexzM=; b=QRBuq7FrZs5dZnGDNuknCpo5CYkWerxvPrJzO9uKdevVMtBV3RVIoHdBfQJdmuNWMwepa6gEmIrvLataOmGGeWYgyTUajqfjgyzYmmZtntRjhIci5eDf2GOJjc5zhL/NPQwYItAdz8Ut2JFnvZWWHSxkc1b6jI5ysbPu3RQD5hQ= Received: from HE1PR0801MB1771.eurprd08.prod.outlook.com (10.168.150.14) by HE1PR0801MB1417.eurprd08.prod.outlook.com (10.167.248.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Thu, 15 Mar 2018 16:09:45 +0000 Received: from HE1PR0801MB1771.eurprd08.prod.outlook.com ([fe80::1925:dd6f:e583:faaf]) by HE1PR0801MB1771.eurprd08.prod.outlook.com ([fe80::1925:dd6f:e583:faaf%15]) with mapi id 15.20.0548.021; Thu, 15 Mar 2018 16:09:46 +0000 From: Evan Lloyd To: "edk2-devel (edk2-devel@lists.01.org)" CC: Leif Lindholm , Matteo Carlini , Ard Biesheuvel , "Girish Pathak" Thread-Topic: GOP:Frame Buffer memory type? Thread-Index: AdO7zAZgDDDiXwgjTtm22zQsNmmNjQ== Date: Thu, 15 Mar 2018 16:09:45 +0000 Message-ID: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Evan.Lloyd@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0801MB1417; 7:JIUKKzQVmRUOV/qpgHDp8XucYQFd8EYEBkt5kQOCkHVyTpA6I4gqSgYxViHA2Tfx3qemyN4qPOIgABgUIsMH1MT1wRnQ7llxFVOk2awPPC4WBQGjJh8DbTx9NZAPuDB/Ueaexk3yvnGb5sbpG3j5VDbHXP+sHqjjRkmft6OvAeYVpSfuNYJLUZHLXLSNDk4lY+nvQg7v32ZtWxykZQl3jMXC/rxUN0eHDajvpUFEJJHtpPjHZKGQNDuE/XfNmLiu x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bf661967-e273-4035-269b-08d58a8f2bb5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:HE1PR0801MB1417; x-ms-traffictypediagnostic: HE1PR0801MB1417: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501244)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0801MB1417; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0801MB1417; x-forefront-prvs: 0612E553B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(366004)(39380400002)(346002)(199004)(189003)(40434004)(102836004)(6506007)(6916009)(72206003)(66066001)(478600001)(186003)(53936002)(68736007)(6306002)(2900100001)(14454004)(86362001)(54906003)(9686003)(6116002)(3846002)(790700001)(2906002)(59450400001)(54896002)(99286004)(5660300001)(4326008)(25786009)(5890100001)(74316002)(5250100002)(105586002)(55016002)(7736002)(97736004)(7696005)(3660700001)(106356001)(26005)(316002)(33656002)(3280700002)(6436002)(81156014)(3480700004)(8936002)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0801MB1417; H:HE1PR0801MB1771.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: y7UlmtW8YKitevL75ceL49Wo81uZOZNHlEt6T6H0JoITUnA2UYEG/pK2dw3SFqkIlkJhAoIYMgnADCPZQLT+DgTt1eu8TokOm3ydjW+IfjLpFZP8/yh5O9GJErLkwn9I+Ha90lD1TkxAU86XYnw4sz6soJAfnXznHGLmJKeRRLeeltexnE7MlWnE25wW8T8v02YMNnqAdQs5KwvmjoGU+YPPXMhWbFerzY/S6zEazn4shKQ7FYE0wPQZikt+QpiL5aFosoijAmOIbL43doExOwmSgqnt4PwYng5bluhS5l/w/Cli0D+JvSSjXTzeZA6mDMleGQFj+y56eXeNPGtefQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf661967-e273-4035-269b-08d58a8f2bb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2018 16:09:45.9323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1417 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 Subject: GOP:Frame Buffer memory type? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 16:03:25 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The EFI_GRAPHICS_OUTPUT_PROTOCOL provides for a frame buffer: "FrameBufferBase Base address of graphics linear frame buffer. Info conta= ins information required to allow software to draw directly to the frame bu= ffer without using Blt().Offset zero in FrameBufferBase represents the uppe= r left pixel of the display." The spec is silent on how (or if) the frame buffer should appear in the mem= ory map. The obvious option is EfiMemoryMappedIO, however the spec has (Ta= ble 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 avai= lable 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 confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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.