From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6E45DC28B20 for ; Fri, 28 Mar 2025 16:32:35 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id ABC7281F00; Fri, 28 Mar 2025 17:32:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; secure) header.d=gmx.de header.i=xypron.glpk@gmx.de header.b="eJ0a4Bdp"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7064681951; Fri, 28 Mar 2025 17:18:11 +0100 (CET) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 42F76810EA for ; Fri, 28 Mar 2025 17:18:09 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1743178661; x=1743783461; i=xypron.glpk@gmx.de; bh=cWg3A5ISrGdswXEuTMTrP5/SOEdGzEW+NELvMdHAuok=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=eJ0a4BdpE+NS6znJmoa/ZfmaKvffmS09ewv+S/oNE7FcvVxNlpwBKQPR3x6JCrPq /Rf8OMbgTh1q+UGxEQkbaE1Al+X6f3fVz9tSPnqPc9p6MJNCDw/9K3faDIfxLeW16 HRf3uV1jzZ1WpurqL53ct263o8VtuhAAqZrxfymEr62Ukk+NaKAKWNNUW3VraBN0k G41vYGRHqACKdohNS8fjlE6U4eVfnSODsPBa5jZbuW0jogB3Elsv8Q0Pnne2iV5La MwgoQ/TLK8t8T9qJV/s4UicjpX6JlLCqI8ViI7a5/VkkDe94WbxZ4iNLN1dzY94eu Kk1DdPUhrqeVzsww/g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.103.102] ([5.147.80.91]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHoN2-1tsCeI3l6U-002LAS; Fri, 28 Mar 2025 17:17:41 +0100 Message-ID: <2c9efc39-b0b9-41e7-b42e-1d026bc286a7@gmx.de> Date: Fri, 28 Mar 2025 17:17:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] efi_loader: remove EFI_BOUNCE_BUFFER To: Tom Rini Cc: Simon Glass , e@freeshell.de, Rayagonda Kokatanur , Tang Yuantian , Mingkai Hu , Ashish Kumar , Priyanka Jain , Wasim Khan , Udit Agarwal , Meenakshi Aggarwal , Patrick Delaunay , Patrice Chotard , Manish Tomar , Mathew McBride , Caleb Connolly , Tien Fong Chee , Michal Simek , Sumit Garg , Patrick Rudolph , Alif Zakuan Yuslaimi , Oliver Gaskell , =?UTF-8?Q?Duje_Mihanovi=C4=87?= , Robert Marko , Lukas Funke , Peng Fan , Wei Ming Chen , Adriano Cordova , Sughosh Ganu , =?UTF-8?Q?Vincent_Stehl=C3=A9?= , Raymond Mao , Maks Mishin , Sam Protsenko , u-boot@lists.denx.de, uboot-stm32@st-md-mailman.stormreply.com, Mark Kettenis , Ilias Apalodimas References: <20250317133845.138061-1-ilias.apalodimas@linaro.org> <380f1f2c-59cd-4c52-a598-5e6f1ed1dcad@gmx.de> <20250328160419.GX93000@bill-the-cat> Content-Language: en-US From: Heinrich Schuchardt In-Reply-To: <20250328160419.GX93000@bill-the-cat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:4NUy4chyS+kg65suL0KnwLHGbAyTf/H06weogu7zLawvkBcJKrl hHKr84K1V83n2vKHAyGem3d37Se9g5nY2g4oQ17y5ab1n3XowajBSTG9tZajOZUda1smqD+ wEoFUtG2bi1efu8qlu2e/KDXMd5vl5WHdATu3A6wfPEAzvmMLKz8NNQinmcNrOU0NYnsZi8 cfZldbRTYSfQRi+6vYz4A== UI-OutboundReport: notjunk:1;M01:P0:Kdzq82JvEOE=;+m6C/VUgfE//HGb6337rfHmeIix AJEnuGdCqZyXOx0P1r/jaKDMMW/eGfd9ROVyqAGBFeV06zhgk1r1RUx3YPxEE4QWbFfFnnIXe OoxJuBSJoAWz5JVBvSjGm8mtr9fiur70SDW86woBWLHb1RlPRPtOY5mnxRE7VkF+fBFQQzNk4 aqOJ+fWCQhicts4JVAhDKJNh6M30uFnDDjE5HROz/B/ipQOOxfSCRRCgW+Xz1b0uY/HSi+8Js O5yhYhiyY2aOwd3QRVT2pki8HWgaINFls/LkWeAUkM/oN3+hXKGevwZLHLOoJMPJRJzcXC2uR /HUmA1Vqj50QSLHEmp0Sh6VgjbGE81AEyljIwUzriKWCYCDIJl40fP2MBB9OCi2XBkSBTNQPa J2wK8oRBkImGuzQY7HAA20pyiDM8ayPVPYa/p2pYjWMiugkGaVJEzo34GSX9l5henjras2Uj9 cSAmNstcgLT8PkUk+mMQXXBl70XaYaobRyvNonICgkTVCtnSPCyYPutXf5sccxBUjaYAz+rdS coPKIX7w18EEDR5FA6ni3Qc+NN7A+N6tKcE8XEQPcPzOLjqEG+DNwG3U8vx8NFlxTU6neyzM5 5mBdBX0dDQZxp1/yW8W0Y0pKZqHAuGv0ABYqJ+WGOIriep6z9sXMPyX0/BjhcbCLCOpeuG7Pm Kzy6z+t6cjeHdYRp5qqi76ThhqFVA/bsiFEPKjUFt02wtJXfr5TTMFIJXA/zqO124CV1DTfCi RM798G1Z8gi/cO+tq5x9RHkbmvInADQIp32kRaezi+5kl16qxzG+wBsRm76el8dYMSe2bhkEj MSk8cSqts8TSaMbpj04wwfTqZRh8RLyDbZdqlGTDGw8sLEvJAWzEqoPzIs96CJ03Ot+7aTwCj TYrfi+RCu73EsXwp4cpRYtVn5ykXlSLTxxLoWk6e4kmsrSzXHKvDmd2EnLaNYVMEiHMw2hvsh Et4El1nOBCSDqzB5Irl1oMpzvq+okhTlj7F6zBpiw/ywgiPaZygLvy9PzeCm6VCTW4QK5bB6W V8zOYBJ0DvvlG+o908L5AnL4gmeHC2qkAEn06o8y6o79TRcK6vmCf8x2fgjMa2MDvV7xCLFqL VRPYLCXfxq5aUOwetwNUG+laYS/EOcs60MFFWcPBFL56RKfsuIxUo0JB5qG4HoJK2lOpHGETs hUnhhGwiZ6vozR6HQztKRnwV4otYsKXU/xvtY6vxbGYHSaOK908zzdLPMTBJdgKuEtAXCO1tl R+xzn+QVBlazWdrOOSJPDWbWBgabwGshYeAQeggTbIhkQEriPC2oFlyWce67Bv8yz/VdiqY1q Ju+BAOsoB17+ny0X/IwbTyWrGGws3nwCH/Z5TvKMB2fdZGhvq6urvoG0j4cYdR9SyVUDEXUrE +teMX79PiqRCdfVE6F5YQP8wnd++VFvsIsy/32mx6XkGeC1NmAtvFjU6bZYkagzuqz53u7MJA +ijdth8RQHiJaUuw/ZBXotdTXqxo= X-Mailman-Approved-At: Fri, 28 Mar 2025 17:32:16 +0100 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On 28.03.25 17:04, Tom Rini wrote: > On Fri, Mar 28, 2025 at 02:26:39PM +0200, Ilias Apalodimas wrote: >> On Fri, 28 Mar 2025 at 13:34, Simon Glass wrote: >>> >>> Hi Ilias, >>> >>> On Thu, 27 Mar 2025 at 15:19, Ilias Apalodimas >>> wrote: >>>> >>>> Hi Simon >>>> >>>> On Thu, 27 Mar 2025 at 15:33, Simon Glass wrote: >>>>> >>>>> Hi Ilias, >>>>> >>>>> On Wed, 26 Mar 2025 at 02:37, Ilias Apalodimas >>>>> wrote: >>>>>> >>>>>> Hi Heinrich, >>>>>> >>>>>> On Mon, 24 Mar 2025 at 19:50, Heinrich Schuchardt wrote: >>>>>>> >>>>>>> On 17.03.25 14:38, Ilias Apalodimas wrote: >>>>>>> >>>>>>> %s/EFI_BOUNCE_BUFFER/CONFIG_EFI_LOADER_BOUNCE_BUFFER/ >>>>>>> >>>>>>>> The EFI subsystem defines its own bounce buffer for devices that >>>>>>>> can't transfer data > 4GB. U-Boot already has a generic BOUNCE_BU= FFER >>>>>>>> which can be reused instead of defining another symbol. >>>>>>>> The only limitation for EFI is that we don't know how big the fil= e a user >>>>>>>> chooses to transfer is and as a result we can't depend on allocat= ing the >>>>>>>> memory from the malloc area, which can prove too small. >>>>>>>> >>>>>>>> So allocate an EFI buffer of the correct size and pass it to the = DM, >>>>>>>> which already supports bounce buffering via bounce_buffer_start_e= xtalign() >>>>>>> >>>>>>> Looking at >>>>>>> >>>>>>> if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && desc->bb) { >>>>>>> >>>>>>> in drivers/block/blk-uclass.c the bounce buffer has to be explicit= ly >>>>>>> enabled by the device driver. Only the scsi drivers sets bb =3D tr= ue. >>>>>>> >>>>>>> Cf. 81bd22e935dc ("rockchip: block: blk-uclass: add bounce buffer = flag >>>>>>> to blk_desc") >>>>>>> >>>>>>> Which device-drivers of the boards mentioned below do actually nee= d >>>>>>> bounce buffering? >>>>>> >>>>>> Unfortunately, I don't have any of the hardware to test and I haven= t >>>>>> worked with that platform much. >>>>>> That 'bb' variable and the fact that EFI needs bigger allocations i= s >>>>>> why I ended up allocationg properly aligned memory from the EFI >>>>>> subsystem. But as Mark pointed out, the cache flush is a no go for >>>>>> now, so I'll drop this and see if I find time to rework the bounce >>>>>> buffer logic overall >>>>> >>>>> There was quite a bit of discussion about all this in the context of >>>>> my attempt to just add a message to warn the user[1] >>>>> >>>>> We might consider adding an event to reserve memory before relocatio= n, >>>>> along with a way to discover (in board_r) where the memory was >>>>> allocated. That would make the solution more generic. >>>> >>>> I am not sure what you are trying to solve here. The EFI bounce buffe= r >>>> after the LMB patches can't overwrite memory, nor can it be >>>> overwritten. >>> >>> I am thinking of we can create a single implementation of the >>> bouncebuf logic which also works for EFI. >>> >>> I think the two sane things to do are: >>> - restrict U-Boot to using memory below 4GB for platforms which have >>> the DMA limitation >> >> You don't need that. The bounce buf code has a callback you can use to >> define the limitations >> >>> - create (in board_f) a special region below 4GB for use with the >>> bouncebuf logic >> >> The only problem with EFI is that you don't know how much memory it >> needs and we can't use the existing memalign calls. So if we replace >> that memalign in the bounce buffer code, with an lmb reservation we >> have everything we need. > > It's not even an EFI problem is it? You could hit the same problem > reading a file from a filesystem outside of EFI too. These specific > SoCs just aren't heavily exercised is one of the challenges I think and > so it's possible that we have a few things to yet improve in the > bounce buffer code (which was added for other SoCs and done as generic > enough starting point for others). > EFI or LMB allocate memory top down. So EFI applications have a good chance of loading files into high memory. Other file-system operations typically use predefined addresses line $loadaddr. This is why the problem became more visible in EFI. It is evident that the bounce-buffer functionality is not EFI specific per se. Best regards Heinrich