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 54413C001B0 for ; Wed, 26 Jul 2023 16:29:08 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 471058693E; Wed, 26 Jul 2023 18:29:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=ti.com header.i=@ti.com header.b="n+rI6nvf"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 420CD86962; Wed, 26 Jul 2023 18:29:03 +0200 (CEST) Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id A35458693E for ; Wed, 26 Jul 2023 18:28:48 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=devarsht@ti.com Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 36QB8v6N024480; Wed, 26 Jul 2023 06:08:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1690369737; bh=7olgt2iNz0uJkMlizD5GeaEY+DAVMYCtNdB+BeY3BRU=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=n+rI6nvfTIB5hr93t3ibI1GKfT9/ll89rBGzJypOu2qgVO3k594F7uZlZZDIT2VHU GbCobObCAyRPWAa+Al5XN6DkWxi9begdZQawZ60KIz1iGF/bo595+OYWHugndhjd9s 1Ilvx58JfB5rgx6lNI/8D6FXLwE9imlhEzkkpWtI= Received: from DLEE103.ent.ti.com (dlee103.ent.ti.com [157.170.170.33]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 36QB8vpS063383 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 26 Jul 2023 06:08:57 -0500 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Wed, 26 Jul 2023 06:08:57 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Wed, 26 Jul 2023 06:08:57 -0500 Received: from [172.24.227.6] (ileaxei01-snat.itg.ti.com [10.180.69.5]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 36QB8rg1104733; Wed, 26 Jul 2023 06:08:54 -0500 Message-ID: Date: Wed, 26 Jul 2023 16:38:53 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 5/9] board_f: Fix corruption of relocaddr Content-Language: en-US To: Simon Glass CC: U-Boot Mailing List , Bin Meng , Michal Suchanek , Nikhil M Jain , Ovidiu Panait , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Rasmus Villemoes , Stefan Roese , "Raghavendra, Vignesh" , "Luthra, Jai" , "Bhatia, Aradhya" References: <20230724145210.304917-1-sjg@chromium.org> <20230724145210.304917-5-sjg@chromium.org> From: Devarsh Thakkar In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 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 Hi Simon, On 26/07/23 02:58, Simon Glass wrote: > Hi Devarsh, > > On Tue, 25 Jul 2023 at 03:21, Devarsh Thakkar wrote: >> >> Hi Simon, >> >> On 24/07/23 20:22, Simon Glass wrote: >>> When the video framebuffer comes from the bloblist, we should not change >>> relocaddr to this address, since it interfers with the normal memory >>> allocation. >>> >>> This fixes a boot loop in qemu-x86_64 >>> >>> Signed-off-by: Simon Glass >>> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL to u-boot") >>> --- >>> >>> common/board_f.c | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/common/board_f.c b/common/board_f.c >>> index 7d2c380e91e2..5c8646b22283 100644 >>> --- a/common/board_f.c >>> +++ b/common/board_f.c >>> @@ -419,7 +419,6 @@ static int reserve_video(void) >>> if (!ho) >>> return log_msg_ret("blf", -ENOENT); >>> video_reserve_from_bloblist(ho); >>> - gd->relocaddr = ho->fb; >> >> I think this change was done as relocaddr pointer was required to be updated >> to move after frame-buffer reserved area to ensure that any further memory >> reservations done using gd->relocaddr (for e.g. in reserve_trace/uboot/malloc) >> don't overlap with frame-buffer reserved area passed from blob, so I think >> removing this line may cause further memory reservations to overlap with >> reserved framebuffer. >> >> Could you please confirm? > > SPL and U-Boot have different memory layouts. The current code is > interrupting U-Boot's careful building up of chunks of memory used for > different purposes. > But it is possible they could be using similar memory layout for some components like framebuffer. For e.g. in our case we are using same video_reserve func in A53 SPL too and which allocates framebuffer from gd->relocaddr as seen here: https://source.denx.de/u-boot/u-boot/-/blob/v2023.10-rc1/common/board_f.c?ref_type=tags#L427 > The video memory has already been allocated by SPL, so we don't need > to insert a new one here, as your code demonstrates. > Agreed. > But also we have no way of knowing if it is legal to relocate U-Boot > (and various other things) just below the frame buffer chosen by SPL. > Yes, so i suppose your case is that framebuffer address which is being passed by SPL is totally disjoint and too far away from gd->relocaddr, for e.g. it is at the start (or bottom of DDR) and doesn't interfere with gd->relocaddr in any manner since relocaddr points to ramtop (i.e. near to end address of DDR). In that case I agree it doesn't make sense to move relocaddr to ho->fb. But for the scenario where gd->relocaddr and ho->fb are nearby there is every possibility that gd->relocaddr may overlap with framebuffer, also the code in reserve_trace, reserve_uboot doesn't have any intelligence or check that it is overlapping with framebuffer area or not. I think one thing that can probably be done here is to have a check that if passed framebuffer area falls within current relocaddr region, then update the relocaddr else don't touch relocaddr : if (ho->fb <= gd->relocaddr - ho->size) //It means framebuffer are is overlapping with current relocaddr so update relocaddr gd->relocaddr = ho->fb else //don't update gd->relocaddr since ho->fb is disjoint to gd->relocaddr Could you please share your opinion on this and if above logic suffice your case too ? Regards Devarsh > The SPL frame buffer needs to be considered pre-allocated. It makes no > sense to set relocaddr to this value. It will break all sorts of > things. E.g. qemu-x86_64 crashes with this. > >> >> >> Regards >> Devarsh >> >>> } else if (CONFIG_IS_ENABLED(VIDEO)) { >>> ulong addr; >>> int ret; > > Regards, > Simon