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 7FD46C433EF for ; Wed, 13 Apr 2022 09:26:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id BC9C881A02; Wed, 13 Apr 2022 11:26:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org 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; unprotected) header.d=kernel.org header.i=@kernel.org header.b="hXhMxLii"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7C6D981A02; Wed, 13 Apr 2022 11:26:45 +0200 (CEST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (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 6FA50831E0 for ; Wed, 13 Apr 2022 11:26:39 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E2C1A61B86; Wed, 13 Apr 2022 09:26:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 324ABC385A3; Wed, 13 Apr 2022 09:26:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649841996; bh=ptKMp5GB5RojZ5CC5eYhRY1v/7VuAgaYk25R6V/YJpA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hXhMxLiie5MeFloBQ7e7aTiA9+B81Ix3ob2FMMvr57Cne1kP1MP7/6fow9ZqhM6MY mzZlMpgSCyv/ITk2CQDENEvZ8+OJQRoJaokbZn2glgNDf+1nx9ep5aZ6YTVKEme4FN mkCWbAz91Spm9TX+eJxJj4ltpzkAeM+Irz3ZJxpRmseed0w0jLQhbIOL22zZPKI+Ce LeCODXj0cC710wuewpHe0zQjgopUsrDyOLD6qgGbwZpEmVTD0DTop4IlYbKC+3X4GW 6y9E0J7mT5HnRjDQ3qq2dprvyIIHiAhZH32ZtsG4wPbdCIZtTI9f+nMwPnrNkoWyMl slsvcS8XFVvbw== Received: by pali.im (Postfix) id 33998805; Wed, 13 Apr 2022 11:26:33 +0200 (CEST) Date: Wed, 13 Apr 2022 11:26:33 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Priyanka Jain , Wolfgang Denk , u-boot@lists.denx.de Subject: Re: Bug in p1_p2_rdb_pc? Caching-inhibited bit for initial L2 SRAM entry in TLB Message-ID: <20220413092633.gmz4rqpiha4rwecb@pali> References: <20220405085737.s34rfws7rg2zhe2n@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220405085737.s34rfws7rg2zhe2n@pali> User-Agent: NeoMutt/20180716 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.5 at phobos.denx.de X-Virus-Status: Clean On Tuesday 05 April 2022 10:57:37 Pali Rohár wrote: > Hello! > > I suspect that there is a bug in board/freescale/p1_p2_rdb_pc/tlb.c code > which configures TLB entry for initial L2 SRAM. > > When L2 is 512 kB long (e.g. on P2020) then U-Boot *unsets* MAS2_I bit > for first half of L2 and for second half of L2 U-Boot *sets* this bit. > > See code: > https://source.denx.de/u-boot/u-boot/-/blob/v2022.04/board/freescale/p1_p2_rdb_pc/tlb.c#L99-104 > > I do not think that one part of L2 SRAM should be configured differently > as second part. Therefore I think that this is a bug in U-Boot code. > > Do you know is correct configuration of TLB entries for initial L2 SRAM? > > MAS2_I is Caching-inhibited bit which is described as: > > Caching-inhibited: > * 0 - Accesses to this page are considered cacheable. > * 1 - The page is considered caching-inhibited. All loads and stores to > the page bypass the caches and are performed directly to main > memory. A read or write to a caching-inhibited page affects only > the memory element specified by the operation. Hello! I found EREF: A Programmer’s Reference Manual for Freescale Power Architecture Processors Supports e500 core family (e500v1, e500v2, e500mc, e5500, e6500) e200 core family document at NXP web: https://www.nxp.com/files-static/32bit/doc/ref_manual/EREF_RM.pdf And section "Cache and MMU Architecture" in part 7.3.1.2.2 Unable to Lock Conditions (page 763) contains following information: If no exceptions occur and no overlocking condition exists, an attempt to set a lock can fail if any of the following is true: • The target address is marked cache-inhibited, or the storage attributes of the address uses a coherency protocol that does not support locking So for me it looks like that L2 SRAM (which works at L2 with locked cache lines) should not set MA2_I (cache-inhibited) bit. Any opinion? Or you do have some more information?