From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::236; helo=mail-it0-x236.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 11BD820956078 for ; Thu, 15 Mar 2018 09:11:11 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id u5-v6so9879383itc.1 for ; Thu, 15 Mar 2018 09:17:35 -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:content-transfer-encoding; bh=dJbtcKxQWgwPVuzI5gUBLw9TQoJFn7JKJul+mVvf4Tw=; b=eNXlmupi5cCQrhWJONIDTkM7UYT51dv9y+mCoXAvcEKR4DRD4OolmFKytSkN3I9ZoQ yN2z9rVEZaI5BYNHHgEh4hYNukJmekB7MKwhYJToTa2/5AcBWy7zoz3ol64CHXfwuCDg MaPJA/GxfUrqPaBCAPjiGHdNjtUWrUm/v4W9U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dJbtcKxQWgwPVuzI5gUBLw9TQoJFn7JKJul+mVvf4Tw=; b=lqk0z512MCVrTeuqwwaiNZ1uDzNzXakO6i/cFzP3zBC2R9QiKQJBmZgAtfmmfUNqbJ 1yKlkobamTCdQAYlzHH9DHkshhZKYy+cPgU8AYnV/0PNvd9trnGGtZhAsVEZe7sVCrOa 9loQor8jSjb1vBbunpcI8vBxDM4jD+xs8o3zAl0THo6y1GXS2GE+VdOSz3VBP9d0ZeZb JjIRTAqTHOvMnF0Du64OLu5x2uVFyCaXkh+5mzh2TMo1VtVLWm87kOZt8C2LkfqBBans oFhRKFtpSr+WdIx6NOzFRX3fOVqAeJZNVA90upoxvvqUicvgGDfkfuGzMYO3zoD3ECfi fWpw== X-Gm-Message-State: AElRT7H59kXu8GJEgIQZ8Ak/gJoH7o0NEt/zWRpWQo8jPikYX8TnDNpF 3CuCaO+w93j2i4q8QvTwIF/hy8VmkRPv1H1doe1bGQ== X-Google-Smtp-Source: AG47ELs4DMX0h/a6uHa2ZzTSArHSNOUInspJEaFzxbKvIkBZptkNvBl6vHSZVGBnI+xTprG98NF1aR/t4UujEOh5Q+g= X-Received: by 2002:a24:ad4a:: with SMTP id a10-v6mr2906445itj.42.1521130655111; Thu, 15 Mar 2018 09:17:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Thu, 15 Mar 2018 09:17:34 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Thu, 15 Mar 2018 16:17:34 +0000 Message-ID: To: Evan Lloyd Cc: "edk2-devel (edk2-devel@lists.01.org)" , Leif Lindholm , Matteo Carlini , Girish Pathak Subject: Re: 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:11:12 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 15 March 2018 at 16:09, Evan Lloyd wrote: > The EFI_GRAPHICS_OUTPUT_PROTOCOL provides for a frame buffer: > > =E2=80=9CFrameBufferBase 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 represent= s > the upper left pixel of the display.=E2=80=9D > > > > 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 ha= s > (Table 29. =E2=80=9CMemory Type Usage after ExitBootServices=E2=80=9D) : > > =E2=80=9CEfiMemoryMappedIO > > This memory is not used by the OS. All system memory-mapped IO informatio= n > should come from ACPI tables.=E2=80=9D > > This is slightly problematic because the GOP Frame Buffer is not describe= d > in an ACPI table. > > > > Most options are obviously unusable (like =E2=80=9CEfiBootServicesData M= emory > available for general use.=E2=80=9D) as the =E2=80=9Cavailable for genera= l use=E2=80=9D basically > means overwritten by OS memory usage, so the pixels corrupt OS data. > > > > So =E2=80=93 can anyone advise us on whether there is some =E2=80=9CStan= dard=E2=80=9D 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)