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 8B541C43334 for ; Fri, 3 Jun 2022 17:46:37 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id E30F083E60; Fri, 3 Jun 2022 19:46:34 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id C4E48840B6; Fri, 3 Jun 2022 19:46:32 +0200 (CEST) Received: from mx1.tinet.cat (mx1.dipta.cat [195.76.233.59]) (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 31B7A840B6 for ; Fri, 3 Jun 2022 19:46:30 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=tinet.cat Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xdrudis@tinet.cat X-ASG-Debug-ID: 1654278388-12aaf26c13b57c0001-4l7tJC Received: from smtp01.tinet.cat (smtp01.tinet.org [195.77.216.131]) by mx1.tinet.cat with ESMTP id nZkK9HsoPb9HmsSm; Fri, 03 Jun 2022 19:46:28 +0200 (CEST) X-Barracuda-Envelope-From: xdrudis@tinet.cat X-Barracuda-Effective-Source-IP: smtp01.tinet.org[195.77.216.131] X-Barracuda-Apparent-Source-IP: 195.77.216.131 Received: from begut (50.red-79-152-182.dynamicip.rima-tde.net [79.152.182.50]) by smtp01.tinet.cat (Postfix) with ESMTPSA id 0361E6063587; Fri, 3 Jun 2022 19:46:28 +0200 (CEST) Date: Fri, 3 Jun 2022 19:46:26 +0200 From: Xavier Drudis Ferran To: Jerome Forissier Cc: U-Boot Mailing List , Peng Fan , Jaehoon Chung , imon Glass , Heiko Schocher , Aswath Govindraju , Lokesh Vutla , Michal Simek , Nishanth Menon Subject: Re: [SPAM] RockPi4B: spl_load_fit_image() writing past end of buffer & MMC errors Message-ID: <20220603174626.GE2817@begut> X-ASG-Orig-Subj: Re: [SPAM] RockPi4B: spl_load_fit_image() writing past end of buffer & MMC errors References: <93b2e0bc-7103-d613-42b3-a2ac17573cee@linaro.org> <20220603145837.GB2817@begut> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220603145837.GB2817@begut> User-Agent: Mutt/1.10.1 (2018-07-13) X-Barracuda-Connect: smtp01.tinet.org[195.77.216.131] X-Barracuda-Start-Time: 1654278388 X-Barracuda-URL: https://webmail.tinet.cat:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 992 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5124 1.0000 0.7500 X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=6.0 KILL_LEVEL=8.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.98461 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 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 Sorry for the noise. El Fri, Jun 03, 2022 at 04:58:38PM +0200, Xavier Drudis Ferran deia: > > In my Rock Pi 4B this does not happen. It happily writes the 17 blocks. > Or it's just that I'm not noticing the problem ? Does it hang or give you > an error, or do you just find it out by reading the SRAM? > It was just that I didn't notice the problem. > I'm using the patch I sent yesterday: > > [PATCH 0/3] arm: rockchip: rk3399: rock-pi-4: power domain driver to boot from MMCSD > https://lists.denx.de/pipermail/u-boot/2022-June/485498.html > It doesn't matter, it seems it's just me who gets ATF1 at address 0. > It's that the change shouldn't be needed ? Why can one only use the > first 8K from the 64K INTMEM1 ? Did you find any reason the rest > shouldn't be writable? > Because INTMEM1 is only 8K long in RK3399. 64K is just the length of the addressing page it's in, but the SRAM is just 8Kb in size. INTMEM0 is 192 Kb, but not INTMEM1