[{"id":3685255,"web_url":"http://patchwork.ozlabs.org/comment/3685255/","msgid":"","list_archive_url":null,"date":"2026-05-02T07:28:56","subject":"Re: [PATCH 1/1] efi_loader: set correct frame buffer address","submitter":{"id":82181,"url":"http://patchwork.ozlabs.org/api/people/82181/","name":"Heinrich Schuchardt","email":"heinrich.schuchardt@canonical.com"},"content":"On 5/1/26 17:05, Heinrich Schuchardt wrote:\n> If we use video copy, bit image transfers need to write to the in memory\n> copy of the physical frame buffer. Damage control will sync the changes\n> to the physical frame buffer.\n> \n> Cyclic video copy will catch all changes done by EFI applications directly\n> accessing the frame buffer copy.\n> \n> gopobj->mode.fb_base must be a valid pointer to memory and not a virtual\n> sandbox address.\n> \n> With this change the block image transfer test works again on the sandbox.\n> \n> setenv efi_selftest block image transfer\n> bootefi selftest\n> \n> Fixes: a75cf70d23ac (\"efi: Correct handling of frame buffer\")\n> Signed-off-by: Heinrich Schuchardt \n> ---\n> lib/efi_loader/efi_gop.c | 7 +++----\n> 1 file changed, 3 insertions(+), 4 deletions(-)\n> \n> diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c\n> index 9403e09691e..ae44d140289 100644\n> --- a/lib/efi_loader/efi_gop.c\n> +++ b/lib/efi_loader/efi_gop.c\n> @@ -471,7 +471,7 @@ efi_status_t efi_gop_register(void)\n> {\n> \tstruct efi_gop_obj *gopobj;\n> \tu32 bpix, format, col, row;\n> -\tu64 fb_base, fb_size;\n> +\tu64 fb_size;\n> \tefi_status_t ret;\n> \tstruct udevice *vdev;\n> \tstruct video_priv *priv;\n> @@ -490,7 +490,6 @@ efi_status_t efi_gop_register(void)\n> \trow = video_get_ysize(vdev);\n> \n> \tplat = dev_get_uclass_plat(vdev);\n> -\tfb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;\n> \tfb_size = plat->size;\n> \n> \tswitch (bpix) {\n> @@ -528,7 +527,7 @@ efi_status_t efi_gop_register(void)\n> \tgopobj->mode.info = &gopobj->info;\n> \tgopobj->mode.info_size = sizeof(gopobj->info);\n> \n> -\tgopobj->mode.fb_base = fb_base;\n> +\tgopobj->mode.fb_base = (uintptr_t)priv->fb;\n\nI discussed the value of FrameBufferBase with Simon.\n\nThe code before the patch is incorrect, as on the sandbox it does not \nprovide a pointer value but a sandbox virtual address. EFI applications \nmay use the pointer for directly writing to the frame buffer. This would \nlead to a crash on the sandbox.\n\nFor the case of CONFIG_VIDEO_COPY=y it is problematic to pass the memory \nbuffer address here, as Linux has an EFI framebuffer driver and would \nwrite to the buffer instead of the physical framebuffer. But our memory \nbuffer is neither reserved memory not is it copied to the physical \nframebuffer after ExitBootServices.\n\nIf we pass the physical framebuffer address here, then an EFI \napplication might write to it and the cyclic video sync would overwrite \nthe changed pixels.\n\nSetting PixelBltOnly in field Mode.PixelFormat forbids EFI applications \nto directly write to the framebuffer.\n\nSo if plat->copy_base is set we should pass PixelBltOnly as PixelFormat \nand copy_base as FrameBufferBase.\n\nWe the aforementioned change we will need to change function \ngop_get_bpp() to not rely on PixelFormat. Instead we need to pass \npriv->format in a private field of the graphics protocol.\n\n\n> \tgopobj->mode.fb_size = fb_size;\n> \n> \tgopobj->info.version = 0;\n> @@ -553,7 +552,7 @@ efi_status_t efi_gop_register(void)\n> \t}\n> \tgopobj->info.pixels_per_scanline = col;\n> \tgopobj->bpix = bpix;\n> -\tgopobj->fb = map_sysmem(fb_base, fb_size);\n> +\tgopobj->fb = priv->fb;\n\npriv->fb is also the value used by the TrueType drivers.\n\nBest regards\n\nHeinrich\n\n> \tgopobj->vdev = vdev;\n> \n> \treturn EFI_SUCCESS;","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (4096-bit key;\n unprotected) header.d=canonical.com header.i=@canonical.com\n header.a=rsa-sha256 header.s=20251003 header.b=BbMjf3Ai;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=reject dis=none) header.from=canonical.com","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (4096-bit key;\n unprotected) header.d=canonical.com header.i=@canonical.com\n header.b=\"BbMjf3Ai\";\n\tdkim-atps=neutral","phobos.denx.de; dmarc=pass (p=reject dis=none)\n header.from=canonical.com","phobos.denx.de; spf=pass\n smtp.mailfrom=heinrich.schuchardt@canonical.com"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g70095qGjz1yJ0\n\tfor ; Sat, 02 May 2026 17:29:13 +1000 (AEST)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id F103380F0E;\n\tSat, 2 May 2026 09:29:04 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 3BFCB83693; Sat, 2 May 2026 09:29:02 +0200 (CEST)","from smtp-relay-internal-1.canonical.com\n (smtp-relay-internal-1.canonical.com [185.125.188.123])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 6272080077\n for ; Sat, 2 May 2026 09:28:59 +0200 (CEST)","from mail-wr1-f72.google.com (mail-wr1-f72.google.com\n [209.85.221.72])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 077F63F1CC\n for ; Sat, 2 May 2026 07:28:59 +0000 (UTC)","by mail-wr1-f72.google.com with SMTP id\n ffacd0b85a97d-44a122a5128so1322614f8f.0\n for ; Sat, 02 May 2026 00:28:59 -0700 (PDT)","from [192.168.123.154]\n (ip-176-199-115-125.um44.pools.vodafone-ip.de. [176.199.115.125])\n by smtp.gmail.com with ESMTPSA id\n ffacd0b85a97d-44a8ea7cf97sm11208698f8f.6.2026.05.02.00.28.56\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Sat, 02 May 2026 00:28:57 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,\n RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham\n autolearn_force=no version=3.4.2","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com;\n s=20251003; t=1777706939;\n bh=qfQeC77jcppN9Q88H4ZJjMod+lf6yKV2+SV13V9aihI=;\n h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n In-Reply-To:Content-Type;\n b=BbMjf3AiNi0uewlCJmOv651OhVm1xAUY2dCD2SClWPzvrkUlNW/ITFfu2X8MMmZAF\n zi/UtlqGoUA4CG26GubpmED58h9l7YDvABJfhzVnW67Cy0uhCQjn3bbvbgVgUTieVm\n Q/b9y4jXgyjXRcUUKraDsu5xk4ExGKDA7i3PEgeY3GaQvCTeo8dNkCRlrxINkUZUM2\n ZnOIXvaz2aPPiqf7MDEyBKjL/2piEPXryPNg1nn5HsiPqI61AAk5IHtrDehzw3sATw\n JkcINMqU81nlTSw4l1XbDIshKFtOuQYguCUr9tusU5VNE2ZYqbJsmUyJnxHMInsgew\n 3ipf9qbK1PSorhQk6PUTVUf2kPBuTboE898nXddMsbFf9YwtWb2Nm3zqz+IGYAGfRp\n 0jr2sJcB9gZpEl8n8/Tk+wVI9nbZxHLFJZzrFpRjuTatlrhORoTr8q9b3YTGchAcOO\n iPgjdyM/m2hjCIZkCY/h1p5cIJTUqZcgZEkNe3YG5oE6h1A8gEWz82oHSDSD3fFfkz\n TyYVUbx3UgeWOOduoC7zvO/dn+nwtSeIH/xmjmo2zXgrINcFaApHAez1WI+4oqC2/6\n 3MVRS7YeY9OQd5VTKyDp/7QHcgPZEgByeGi+337CXyzrq5FrNEiSgvoqVzp1Jewuvn\n JHNqm2p+GhYuT/2bkrg2j9aU=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777706938; x=1778311738;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=qfQeC77jcppN9Q88H4ZJjMod+lf6yKV2+SV13V9aihI=;\n b=JJhv4ak9LkR0eu3UcCLsNOBGWNe93zy44f6ATTr08VIJlJD+/ZXbyGy3Ef+yrV0fnD\n JmiZ2WdkOXiIOU4Lg0JdybevahBhdF+A1FFRavCIq3wQmE/9fJZxvkvQWzRhCEtngbWY\n 9uO3SqIf6MKoUnvezr1b1xAV9AMzOtqfIdot1Lp3FH+H+7fqP62BfsKC67yuT1hw5o5m\n kpXI0bJ4xqCT12m9/WeshNo03/RaA8A/r0ussb4/rZjQmtfWXZygeCr8YGeQKUPbjdNq\n 8NUmjtu6e0DClKFBUYUUOVgveac9e7Cv2uDa7hYMIXDBcZp4nNRkJeXJ7sM0AK/6ypyP\n AdyA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ82zcLc0vHKMTzA0qJmMw3yz8o2NHLPdWBOjCSpMOk+d7PxkByurDw37U3n3P17UWaIWFZ+gWE=@lists.denx.de","X-Gm-Message-State":"AOJu0YyNEW4nmLvf0v9Hu60D4f/JP7+Vj1Fx0ivWLN4jQIRXl0rI2j/d\n zCDXyRvf4LkY7gHHDQiPn/0ShMLy1CTNj7QgBjollbvLtmy/b1VvaYNLBdCd5G4nu9hWY1cSs5M\n Fa0vxygJYIhozr0AXpAZ2cVFrDC51e2+dd9AO77zTyJxo+YuOIsaFZbHglRsJa/qn/2QIT7Q=","X-Gm-Gg":"AeBDietvQn6pVppGF8B4W6BkqLhIHF6mGD7WqXWKc1pO2gpdRbJrPLE3BF7yspLFo1M\n JwP+6un3kqbAWHoNpn64A+p6jMW+LQAkPDRJqDwvVcfeWlFNyliZVZzWRrf8mP9FtOIFTgSH+2N\n RQNTcz3/6JrT0eU+LMgij+PQYRqMU6DEvM6mV2MbGNlj64cW2NSooxecRWX4iF+KDWt9Gq2zCee\n S8vndaMTpfBfELL+kNtjBw7W8du1d7wtJdKP6pdFw9V83gU3XDsUhsTTazB/9O5usbFwtLSxnF+\n QyB8aMZvKBBNjfMdaC7yiqez+nhyiyA6bxC/XF6gpwWXwYLTvEfY4NeUVIWsOfK4CXrSHpV3mmh\n fKkX48RVJl3gbWUANWwFp1rGDHVt94SFZkyStAkaq3uilwJWYgf1v5PpiBTdqAyoKyLdpYcqD9S\n cjd5fOApFVp10UWwE2M3I5M1wuPdA0CgKVhMK2k5ZlCGszrhPtAdyV+tW7fV7RFwglFCI=","X-Received":["by 2002:a05:6000:220c:b0:448:5ec1:dcb5 with SMTP id\n ffacd0b85a97d-44bb2e2e7cbmr3492048f8f.7.1777706938592;\n Sat, 02 May 2026 00:28:58 -0700 (PDT)","by 2002:a05:6000:220c:b0:448:5ec1:dcb5 with SMTP id\n ffacd0b85a97d-44bb2e2e7cbmr3492023f8f.7.1777706938201;\n Sat, 02 May 2026 00:28:58 -0700 (PDT)"],"Message-ID":"","Date":"Sat, 2 May 2026 09:28:56 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH 1/1] efi_loader: set correct frame buffer address","To":"Ilias Apalodimas ","Cc":"Tom Rini , Peng Fan ,\n Patrice Chotard , Yao Zi ,\n Simon Glass , Bin Meng ,\n u-boot@lists.denx.de","References":"<20260501150550.228937-1-heinrich.schuchardt@canonical.com>","Content-Language":"en-US","From":"Heinrich Schuchardt ","In-Reply-To":"<20260501150550.228937-1-heinrich.schuchardt@canonical.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3685268,"web_url":"http://patchwork.ozlabs.org/comment/3685268/","msgid":"<871pfudqns.fsf@bloch.sibelius.xs4all.nl>","list_archive_url":null,"date":"2026-05-02T10:58:15","subject":"Re: [PATCH 1/1] efi_loader: set correct frame buffer address","submitter":{"id":8281,"url":"http://patchwork.ozlabs.org/api/people/8281/","name":"Mark Kettenis","email":"mark.kettenis@xs4all.nl"},"content":"> Date: Sat, 2 May 2026 09:28:56 +0200\n> From: Heinrich Schuchardt \n\nHi Heinrich,\n\n> On 5/1/26 17:05, Heinrich Schuchardt wrote:\n> > If we use video copy, bit image transfers need to write to the in memory\n> > copy of the physical frame buffer. Damage control will sync the changes\n> > to the physical frame buffer.\n> > \n> > Cyclic video copy will catch all changes done by EFI applications directly\n> > accessing the frame buffer copy.\n> > \n> > gopobj->mode.fb_base must be a valid pointer to memory and not a virtual\n> > sandbox address.\n> > \n> > With this change the block image transfer test works again on the sandbox.\n> > \n> > setenv efi_selftest block image transfer\n> > bootefi selftest\n> > \n> > Fixes: a75cf70d23ac (\"efi: Correct handling of frame buffer\")\n> > Signed-off-by: Heinrich Schuchardt \n> > ---\n> > lib/efi_loader/efi_gop.c | 7 +++----\n> > 1 file changed, 3 insertions(+), 4 deletions(-)\n> > \n> > diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c\n> > index 9403e09691e..ae44d140289 100644\n> > --- a/lib/efi_loader/efi_gop.c\n> > +++ b/lib/efi_loader/efi_gop.c\n> > @@ -471,7 +471,7 @@ efi_status_t efi_gop_register(void)\n> > {\n> > \tstruct efi_gop_obj *gopobj;\n> > \tu32 bpix, format, col, row;\n> > -\tu64 fb_base, fb_size;\n> > +\tu64 fb_size;\n> > \tefi_status_t ret;\n> > \tstruct udevice *vdev;\n> > \tstruct video_priv *priv;\n> > @@ -490,7 +490,6 @@ efi_status_t efi_gop_register(void)\n> > \trow = video_get_ysize(vdev);\n> > \n> > \tplat = dev_get_uclass_plat(vdev);\n> > -\tfb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;\n> > \tfb_size = plat->size;\n> > \n> > \tswitch (bpix) {\n> > @@ -528,7 +527,7 @@ efi_status_t efi_gop_register(void)\n> > \tgopobj->mode.info = &gopobj->info;\n> > \tgopobj->mode.info_size = sizeof(gopobj->info);\n> > \n> > -\tgopobj->mode.fb_base = fb_base;\n> > +\tgopobj->mode.fb_base = (uintptr_t)priv->fb;\n> \n> I discussed the value of FrameBufferBase with Simon.\n> \n> The code before the patch is incorrect, as on the sandbox it does not \n> provide a pointer value but a sandbox virtual address. EFI applications \n> may use the pointer for directly writing to the frame buffer. This would \n> lead to a crash on the sandbox.\n\nI still think this means that EFI on sandbox is fundamentally broken.\nThe identity virtual-to-physical mapping assumption is just too deeply\nengrained in the ecosystem since that is the documented handoff state\nfor most architectures.\n\n> For the case of CONFIG_VIDEO_COPY=y it is problematic to pass the memory \n> buffer address here, as Linux has an EFI framebuffer driver and would \n> write to the buffer instead of the physical framebuffer. But our memory \n> buffer is neither reserved memory not is it copied to the physical \n> framebuffer after ExitBootServices.\n\nRight.\n\n> If we pass the physical framebuffer address here, then an EFI \n> application might write to it and the cyclic video sync would overwrite \n> the changed pixels.\n> \n> Setting PixelBltOnly in field Mode.PixelFormat forbids EFI applications \n> to directly write to the framebuffer.\n\nThat means the framebuffer becomes unusable as soon as the EFI\napplication calls ExitBootServices() since an EFI application can't\ncall Blt() after that\n\n> So if plat->copy_base is set we should pass PixelBltOnly as PixelFormat \n> and copy_base as FrameBufferBase.\n\nIf PixelFormat is PixelBtlOnly, FrameBufferBase is meaningless and\nprobably should be set to 0 instead.\n\nAnyway, as far as I can tell there aren't a lot of OSes that support\nPixelBltOnly. OpenBSD certainly doesn't. And as far as my reading of\nLinux's efistub code is correct, it doesn't support it either. And neither does u-boot's own efi_video driver.\n\nI've always seen PixelBltOnly as a way to support weird hardware that\ndidn't support a linear framebuffer with a sane pixel format. Not as\na way to support a shadow framebuffer like CONFIG_VIDEO_COPY\nimplements. Note that CONFIG_VIDEO_COPY itself assumes a linear\nframebuffer with a sane pixel format as it just does a straight copy\nof the pixels.\n\nInstead of using PixelBltOnly, can we just disable the shadow\nframebuffer as soon as we hand over control to an EFI application? Or\nmaybe at the point where the EFI application uses the GOP protocol?\n\n\n> We the aforementioned change we will need to change function \n> gop_get_bpp() to not rely on PixelFormat. Instead we need to pass \n> priv->format in a private field of the graphics protocol.\n> \n> \n> > \tgopobj->mode.fb_size = fb_size;\n> > \n> > \tgopobj->info.version = 0;\n> > @@ -553,7 +552,7 @@ efi_status_t efi_gop_register(void)\n> > \t}\n> > \tgopobj->info.pixels_per_scanline = col;\n> > \tgopobj->bpix = bpix;\n> > -\tgopobj->fb = map_sysmem(fb_base, fb_size);\n> > +\tgopobj->fb = priv->fb;\n> \n> priv->fb is also the value used by the TrueType drivers.\n> \n> Best regards\n> \n> Heinrich\n> \n> > \tgopobj->vdev = vdev;\n> > \n> > \treturn EFI_SUCCESS;\n> \n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n secure) header.d=xs4all.nl header.i=@xs4all.nl header.a=rsa-sha256\n header.s=xs4all01 header.b=heoRqBVr;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=reject dis=none) header.from=xs4all.nl","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (2048-bit key;\n secure) header.d=xs4all.nl header.i=@xs4all.nl header.b=\"heoRqBVr\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=reject dis=none) header.from=xs4all.nl","phobos.denx.de;\n spf=pass smtp.mailfrom=mark.kettenis@xs4all.nl"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g74dc5lVFz1yJ0\n\tfor ; Sat, 02 May 2026 20:58:28 +1000 (AEST)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id DE99580F0E;\n\tSat, 2 May 2026 12:58:19 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 3424A83642; Sat, 2 May 2026 12:58:19 +0200 (CEST)","from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl\n [195.121.94.186])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id B3D9880087\n for ; Sat, 2 May 2026 12:58:16 +0200 (CEST)","from smtp.kpnmail.nl (unknown [10.31.155.6])\n by ewsoutbound.so.kpn.org (Halon) with ESMTPS\n id d2313816-4615-11f1-89e5-00505699b430;\n Sat, 02 May 2026 12:58:15 +0200 (CEST)","from bloch.sibelius.xs4all.nl (80-61-163-207.fixed.kpn.net\n [80.61.163.207]) by smtp.xs4all.nl (Halon) with ESMTPSA\n id d1a7b609-4615-11f1-bffa-00505699772e;\n Sat, 02 May 2026 12:58:15 +0200 (CEST)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,\n DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,\n SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2","X-KPN-MessageId":"d2313816-4615-11f1-89e5-00505699b430","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=xs4all.nl; s=xs4all01;\n h=subject:to:from:message-id:date;\n bh=yJaATq4tVpLUb06wCjbktbJn8js6a5nlPwtEKHsr7m8=;\n b=heoRqBVrwoVbXKnkG2WH+P0fOwB+V5noanQKiYztPWRCc3+AyNg0fvKpzTEVKsphbCAE1qFNyqv1M\n snDFzJBiTVj6hmu5IhwpEXTz0EYhicvTf7s53gcRXKdG2GaQQDcZMgKQDjcIUV71KfLiEVn0PHjWy7\n td8MVl6su/bukVAKK/YxSpMhkGGX+7gzbVuVvPNGAJk2aqUb6JjKyqVK58y/gdD75QUjSddeUrar/Q\n uj6OykVNo9nf8OSSzz6RBI8+uhhiA5BgEaKQD3oRI/4BBDDi6M20+7zVtIH9xDJS1VfKVL3NBwILZy\n 25vlIExKDEXJ1eRt88Kwzwbpa8VnZ0g==","X-KPN-MID":"33|qUU3ujZNf3HRSWW8VnNmdcFCLMen6RkK6mvc8X2Tscp2XE70xUEVzVGLPdyX4Lk\n 4AhMlqMUq6W50badpd+Y283uZ/nD0IGnYfqPbeFDytuk=","X-KPN-VerifiedSender":"Yes","X-CMASSUN":"33|+V1QwZPqDbPVgGuuKpd9aGBkKFCs/5ICP4aIXvVd64Z5JaERiJ/f/ofVt+K2znu\n m7i60ltpTzLYHozcMtkPdYw==","X-Originating-IP":"80.61.163.207","Date":"Sat, 02 May 2026 12:58:15 +0200","Message-Id":"<871pfudqns.fsf@bloch.sibelius.xs4all.nl>","From":"Mark Kettenis ","To":"Heinrich Schuchardt ","Cc":"ilias.apalodimas@linaro.org, trini@konsulko.com, peng.fan@nxp.com,\n patrice.chotard@foss.st.com, me@ziyao.cc, sjg@chromium.org,\n bmeng.cn@gmail.com, u-boot@lists.denx.de","In-Reply-To":" (message\n from Heinrich Schuchardt on Sat, 2 May 2026 09:28:56 +0200)","Subject":"Re: [PATCH 1/1] efi_loader: set correct frame buffer address","References":"<20260501150550.228937-1-heinrich.schuchardt@canonical.com>\n ","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}},{"id":3685294,"web_url":"http://patchwork.ozlabs.org/comment/3685294/","msgid":"","list_archive_url":null,"date":"2026-05-02T13:04:49","subject":"Re: [PATCH 1/1] efi_loader: set correct frame buffer address","submitter":{"id":6170,"url":"http://patchwork.ozlabs.org/api/people/6170/","name":"Simon Glass","email":"sjg@chromium.org"},"content":"Hi Heinrich, Mark,\n\nOn Sat, 2 May 2026 at 04:58, Mark Kettenis wrote:\n>\n> > Date: Sat, 2 May 2026 09:28:56 +0200\n> > From: Heinrich Schuchardt \n>\n> Hi Heinrich,\n>\n> > On 5/1/26 17:05, Heinrich Schuchardt wrote:\n> > > If we use video copy, bit image transfers need to write to the in memory\n> > > copy of the physical frame buffer. Damage control will sync the changes\n> > > to the physical frame buffer.\n> > >\n> > > Cyclic video copy will catch all changes done by EFI applications directly\n> > > accessing the frame buffer copy.\n> > >\n> > > gopobj->mode.fb_base must be a valid pointer to memory and not a virtual\n> > > sandbox address.\n> > >\n> > > With this change the block image transfer test works again on the sandbox.\n> > >\n> > > setenv efi_selftest block image transfer\n> > > bootefi selftest\n> > >\n> > > Fixes: a75cf70d23ac (\"efi: Correct handling of frame buffer\")\n> > > Signed-off-by: Heinrich Schuchardt \n> > > ---\n> > > lib/efi_loader/efi_gop.c | 7 +++----\n> > > 1 file changed, 3 insertions(+), 4 deletions(-)\n> > >\n> > > diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c\n> > > index 9403e09691e..ae44d140289 100644\n> > > --- a/lib/efi_loader/efi_gop.c\n> > > +++ b/lib/efi_loader/efi_gop.c\n> > > @@ -471,7 +471,7 @@ efi_status_t efi_gop_register(void)\n> > > {\n> > > struct efi_gop_obj *gopobj;\n> > > u32 bpix, format, col, row;\n> > > - u64 fb_base, fb_size;\n> > > + u64 fb_size;\n> > > efi_status_t ret;\n> > > struct udevice *vdev;\n> > > struct video_priv *priv;\n> > > @@ -490,7 +490,6 @@ efi_status_t efi_gop_register(void)\n> > > row = video_get_ysize(vdev);\n> > >\n> > > plat = dev_get_uclass_plat(vdev);\n> > > - fb_base = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;\n> > > fb_size = plat->size;\n> > >\n> > > switch (bpix) {\n> > > @@ -528,7 +527,7 @@ efi_status_t efi_gop_register(void)\n> > > gopobj->mode.info = &gopobj->info;\n> > > gopobj->mode.info_size = sizeof(gopobj->info);\n> > >\n> > > - gopobj->mode.fb_base = fb_base;\n> > > + gopobj->mode.fb_base = (uintptr_t)priv->fb;\n\nDon't you want to use copy_fb (if VIDEO_COPY is enabled) so you get\nthe hardware address?\n\n> >\n> > I discussed the value of FrameBufferBase with Simon.\n> >\n> > The code before the patch is incorrect, as on the sandbox it does not\n> > provide a pointer value but a sandbox virtual address. EFI applications\n> > may use the pointer for directly writing to the frame buffer. This would\n> > lead to a crash on the sandbox.\n>\n> I still think this means that EFI on sandbox is fundamentally broken.\n> The identity virtual-to-physical mapping assumption is just too deeply\n> engrained in the ecosystem since that is the documented handoff state\n> for most architectures.\n\nThe ACPI tables have the same issue (needing to pass a pointer within\nsandbox's emulated RAM buffer) and we use nomap_sysmem() to handle\nthat.\n\nIn what way is it broken?\n\n>\n> > For the case of CONFIG_VIDEO_COPY=y it is problematic to pass the memory\n> > buffer address here, as Linux has an EFI framebuffer driver and would\n> > write to the buffer instead of the physical framebuffer. But our memory\n> > buffer is neither reserved memory not is it copied to the physical\n> > framebuffer after ExitBootServices.\n>\n> Right.\n>\n> > If we pass the physical framebuffer address here, then an EFI\n> > application might write to it and the cyclic video sync would overwrite\n> > the changed pixels.\n> >\n> > Setting PixelBltOnly in field Mode.PixelFormat forbids EFI applications\n> > to directly write to the framebuffer.\n>\n> That means the framebuffer becomes unusable as soon as the EFI\n> application calls ExitBootServices() since an EFI application can't\n> call Blt() after that\n>\n> > So if plat->copy_base is set we should pass PixelBltOnly as PixelFormat\n> > and copy_base as FrameBufferBase.\n>\n> If PixelFormat is PixelBtlOnly, FrameBufferBase is meaningless and\n> probably should be set to 0 instead.\n>\n> Anyway, as far as I can tell there aren't a lot of OSes that support\n> PixelBltOnly. OpenBSD certainly doesn't. And as far as my reading of\n> Linux's efistub code is correct, it doesn't support it either. And neither does u-boot's own efi_video driver.\n>\n> I've always seen PixelBltOnly as a way to support weird hardware that\n> didn't support a linear framebuffer with a sane pixel format. Not as\n> a way to support a shadow framebuffer like CONFIG_VIDEO_COPY\n> implements. Note that CONFIG_VIDEO_COPY itself assumes a linear\n> framebuffer with a sane pixel format as it just does a straight copy\n> of the pixels.\n>\n> Instead of using PixelBltOnly, can we just disable the shadow\n> framebuffer as soon as we hand over control to an EFI application? Or\n> maybe at the point where the EFI application uses the GOP protocol?\n\nThis seems like a good idea to me - the latter would be best since it\nwon't impact apps which only use console output. The impact would be\nthat U-Boot will need to read from the hardware framebuffer with\nwrite-combining enabled (slow on x86) but at least it is correct.\n\n>\n>\n> > We the aforementioned change we will need to change function\n> > gop_get_bpp() to not rely on PixelFormat. Instead we need to pass\n> > priv->format in a private field of the graphics protocol.\n> >\n> >\n> > > gopobj->mode.fb_size = fb_size;\n> > >\n> > > gopobj->info.version = 0;\n> > > @@ -553,7 +552,7 @@ efi_status_t efi_gop_register(void)\n> > > }\n> > > gopobj->info.pixels_per_scanline = col;\n> > > gopobj->bpix = bpix;\n> > > - gopobj->fb = map_sysmem(fb_base, fb_size);\n> > > + gopobj->fb = priv->fb;\n> >\n> > priv->fb is also the value used by the TrueType drivers.\n> >\n> > Best regards\n> >\n> > Heinrich\n> >\n> > > gopobj->vdev = vdev;\n> > >\n> > > return EFI_SUCCESS;\n\nIt would be worth testing this on a real x86 laptop to make sure it\ncan still boot Ubuntu, etc.\n\nRegards,\nSimon","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256\n header.s=google header.b=F1zH5nMi;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de","phobos.denx.de;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=chromium.org header.i=@chromium.org\n header.b=\"F1zH5nMi\";\n\tdkim-atps=neutral","phobos.denx.de;\n dmarc=pass (p=none dis=none) header.from=chromium.org","phobos.denx.de;\n spf=pass smtp.mailfrom=sjg@chromium.org"],"Received":["from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g77Rq2qpqz1y04\n\tfor ; Sat, 02 May 2026 23:05:10 +1000 (AEST)","from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 343CE83642;\n\tSat, 2 May 2026 15:05:08 +0200 (CEST)","by phobos.denx.de (Postfix, from userid 109)\n id 2DE3583693; Sat, 2 May 2026 15:05:07 +0200 (CEST)","from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com\n [IPv6:2a00:1450:4864:20::52e])\n (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 523B180F0E\n for ; Sat, 2 May 2026 15:05:03 +0200 (CEST)","by mail-ed1-x52e.google.com with SMTP id\n 4fb4d7f45d1cf-6763cc8775cso6240051a12.0\n for ; Sat, 02 May 2026 06:05:03 -0700 (PDT)"],"X-Spam-Checker-Version":"SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de","X-Spam-Level":"","X-Spam-Status":"No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,\n DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,\n RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham\n autolearn_force=no version=3.4.2","ARC-Seal":"i=1; a=rsa-sha256; t=1777727102; cv=none;\n d=google.com; s=arc-20240605;\n b=KlcLYJ7HfASzkQ2u39gN8okonjNT7q/9d9RYWjXG17hX9PJ4TB0/W9jOSFLSYcp4hQ\n V7xyuLKt4N56ARxUciZY01Jj6CijPdFyKqDzSiqb5jlE/MT0CszDa4lNbCToeDWGyA1Q\n Uezjzn8DeEqiedIUDU8hYZKc3HcQsRmVLZ05TvtlcMZuz0XtnCxKZxHukvRumswlqeXT\n GCH13PYGeM4lNFKyKFWjcxGx9VJvUnFpUsqLYup4nTzsRbuwGbAEoXkV8u1ZpVRxgI0J\n 01ANA+Ww09OkHJe4Qvy/50WXU7okaQd8IVr7fBX6f94EF28eYsxmFP6Lbj383xxgkdDJ\n uuuw==","ARC-Message-Signature":"i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;\n s=arc-20240605;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:dkim-signature;\n bh=UujfmYHhSq/AW1OHfP3qdMxT54DKPfgzpCIeMFbH4m4=;\n fh=SoIXj8NfUeF9SIhV+2Z4Te8104jwDVuOxiCmqyA3l5Q=;\n b=cUu5I/coZCwdPCkatMspzoJXDikyw/m8crAfsrDYZ6up1nLWRD3unaO75OLvdv5+o9\n ejNoLfWMb7gvvDYYGjaTMyAP/ymCOgXI3AxjXmc2LtpywxtdEe6Mxbv7MFfe3MQr1k5M\n mYiOqC32CerWhyRhns+/lxUXah6Y4Tk1XFTWJ5SmenXa5CqLwcfPZ+GX6qlKQUXcooxj\n 7b8Km9NEyFZLJP9qMZGxTJQvanDvrUPfrhNtLE0NQqxut0E5cj5lXZDgq3YfS3WDOtEk\n c2q28zWR0Af52fV4pDrxGfbiAk/6SBHCaQIV0hB8i6DbBEsxCsFB1NrZz7pmzkiVOXMx\n hhCg==; darn=lists.denx.de","ARC-Authentication-Results":"i=1; mx.google.com; arc=none","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=chromium.org; s=google; t=1777727102; x=1778331902; darn=lists.denx.de;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:from:to:cc:subject:date:message-id:reply-to;\n bh=UujfmYHhSq/AW1OHfP3qdMxT54DKPfgzpCIeMFbH4m4=;\n b=F1zH5nMiby/KBEQxZoRkmJBlovQeidgybpaL3ictDiUMykje72b4UNAwEwWSyh5sfP\n ZK30ZwQqL1tVqkYVTtv16CiqZmhgrDRmC8SAKik6GRwavuRukdaKdgbMbRL/t6Q0DJ9k\n hNa6iwOx+EhhQxVgVGSeOysHmt5HuEevt7pfg=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777727102; x=1778331902;\n h=cc:to:subject:message-id:date:from:in-reply-to:references\n :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date\n :message-id:reply-to;\n bh=UujfmYHhSq/AW1OHfP3qdMxT54DKPfgzpCIeMFbH4m4=;\n b=dQUITLNrbdtYHY9IvgoKTR1Onkyv4eJEVpwydrdK6NR41HuXyhdkVPLiUi4H4rAtZy\n 9g5rkLGXKoB/2Xg0FiJD4SkEuqTUTxky0kqFhA3p9aGkLhvjQMePgyQtsbQCEU5QUqNl\n b0YpUpdLSnoTHXR3TfJK4tdeaBLlnbbIU7tn1UAZquClaDWR5VDsOuvtYNqZXblcbb/f\n Kk0n9qAZjqKyp5bGGLBKQIYr9GRsNiGQxyokTos4e76lcDpWhy6IhmO9BjoBnYLxqJXG\n ZooiyOWYD0Sa6oK9XzFWroQcDCLnqNKEV9i1TcGowXfLetzsuJ4qDkgJD4hiZeorIMPh\n kWcA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/z2ZJryyWzkMLMd9eRb9dmbGavf1balMACtjLlDJHUbtmBrzxywBB0EgIFHTEu5Pj7n4dZJnY=@lists.denx.de","X-Gm-Message-State":"AOJu0Yyy4fW2zJHiyyKu5W6dmNK+tOGKeyPqDrsbmXokeFdErhOv/SwR\n 87b7WLoTyqeyn9tN7eDkdP3Xyp6nn+32uSr2xMy3zxEdr+wonquLf4Ky4Uy2H0iY/9935ddk6OU\n 9ML764j2uCWjdt8yNIRRzLjejHyyINJeyDZlpMb10","X-Gm-Gg":"AeBDieuwcvIZ3R6KK6pcq+CqPtn55zXc67907qG7VuH7Ci5qwcWMXJIBaQ0kMf3MHP1\n WPExzNiBdgtFzH9rZuqUfa+0xWEQrxr7365YSyc/8i6k66UiP748lPRWOGhs9Tg1zdWXUCPdQ/X\n SF/iJA8bG0HYLwrUAw/3Pa4CikqAVwfonBes1rI44+RpEY1Qh78pJFirfAS2ZH6Mvkyocck8UVL\n dilquznZ6tp6P3V1dxTpxl6rqaUJTgZE3WGefbDlb3vQGQ23Y6y8/jra275kgb1RGYidJB/2ax+\n qs8vRqfsha0Z8DYY","X-Received":"by 2002:a17:907:3f1e:b0:ba6:79c0:c743 with SMTP id\n a640c23a62f3a-bbfe08823famr140023266b.11.1777727101730; Sat, 02 May 2026\n 06:05:01 -0700 (PDT)","MIME-Version":"1.0","References":"<20260501150550.228937-1-heinrich.schuchardt@canonical.com>\n \n <871pfudqns.fsf@bloch.sibelius.xs4all.nl>","In-Reply-To":"<871pfudqns.fsf@bloch.sibelius.xs4all.nl>","From":"Simon Glass ","Date":"Sat, 2 May 2026 07:04:49 -0600","X-Gm-Features":"AVHnY4Lbe_XQ6QQr8jiJpX_T94cKcG3YBC6DFz7eoyUFxgJt-6xrWTpf3s7pru4","Message-ID":"\n ","Subject":"Re: [PATCH 1/1] efi_loader: set correct frame buffer address","To":"Mark Kettenis ","Cc":"Heinrich Schuchardt ,\n ilias.apalodimas@linaro.org,\n trini@konsulko.com, peng.fan@nxp.com, patrice.chotard@foss.st.com,\n me@ziyao.cc, bmeng.cn@gmail.com, u-boot@lists.denx.de","Content-Type":"text/plain; charset=\"UTF-8\"","X-BeenThere":"u-boot@lists.denx.de","X-Mailman-Version":"2.1.39","Precedence":"list","List-Id":"U-Boot discussion ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"u-boot-bounces@lists.denx.de","Sender":"\"U-Boot\" ","X-Virus-Scanned":"clamav-milter 0.103.8 at phobos.denx.de","X-Virus-Status":"Clean"}}]