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 D0EA8C433EF for ; Fri, 3 Jun 2022 14:58:50 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 460D384184; Fri, 3 Jun 2022 16:58:48 +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 4426683F63; Fri, 3 Jun 2022 16:58:45 +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 0DFA184184 for ; Fri, 3 Jun 2022 16:58:41 +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: 1654268319-12aaf2676355b820001-4l7tJC Received: from smtp01.tinet.cat (smtp01.tinet.org [195.77.216.131]) by mx1.tinet.cat with ESMTP id ivScexzcgQ0Qcwmj; Fri, 03 Jun 2022 16:58:39 +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 3DA04605D0AB; Fri, 3 Jun 2022 16:58:39 +0200 (CEST) Date: Fri, 3 Jun 2022 16:58:38 +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: <20220603145837.GB2817@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <93b2e0bc-7103-d613-42b3-a2ac17573cee@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Barracuda-Connect: smtp01.tinet.org[195.77.216.131] X-Barracuda-Start-Time: 1654268319 X-Barracuda-URL: https://webmail.tinet.cat:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 3299 X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: SPAM GLOBAL 1.0000 1.0000 4.3430 X-Barracuda-Spam-Score: 4.34 X-Barracuda-Spam-Status: No, SCORE=4.34 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.98459 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 El Fri, Jun 03, 2022 at 03:17:05PM +0200, Jerome Forissier deia: > First, I noticed that spl_load_fit_image() may write memory outside the range > given in the image node. For example on RockPi 4B I have the following FIT > (irrelevant parts omitted): > > / { > images { > atf_2 { > /* File size is 8024 bytes */ > data = /incbin/("bl31_0xff3b0000.bin"); > compression = "none"; > load = <0xff3b0000> > } > } > } > > I expect SPL to load atf_2 into 0xff3b0000 - 0xff3b200b but due to the alignment > of the source data in the MMC, spl_load_fit_image() writes one more block and > later moves the data in place with memcpy(). What are the guarantees that it > is a safe thing to do? > In my case bl31_0xff3b0000.bin is 8020 bytes in size. > In my case, the image starts at offset 308 in the 512-byte MMC block (that > offset is called 'overhead' in spl_load_fit_image()). As a result, > (8204 + 308) / 512 + 1 = 17 blocks = 8704 bytes are read. My overhead is 352, it's reading 17 blocks too. > > For some reason I can't explain, on my board only the first 8K of the 64K SRAM > range 0xff3b0000 - 0xff3c0000 (INTMEM1) can be safely written to. Any data > written after this point corrupt the lower 8K. I found nothing in the rk3399 > TRM about this [1]. > 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? 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 (instead of the patch you can simply configure CONFIG_ROCKCHIP_SPL_RESERVE_IRAM from make nconfig or so) Which reserves 0x0 - 0x14fff bytes in DDRAM for bl31. I found that otherwise, SPL memory in that area gets overwritten by bl31_0x00000000.bin. I don't remember exactly what was there, but in my tests, bl31_0x00000000 gets loaded before bl31_0xff3b0000.bin. Depending on what data or code is overwritten, SPL might be doing something funny. When I didn't use that patch, my SPL hanged after "Trying to boot from MMC1", before loading the ATF2 image, just when loading ATF1. But maybe depening on what's in that area, or the particular layout resulting from a particular build, the effect might be different. It might be a little random. > Anyways, I tried using a temporary buffer allocated on the heap to handle > the first and last blocks at least (the load address is properly aligned > for info->read() so the middle blocks can be read in one go). It works but > not reliably. And that is the second problem. mmc_read_blocks() in mmc_bread() > sometimes returns an error. If I read blocks one by one in a loop THE read > randomly fails after a few blocks only. The error is -110 (-ETIMEDOUT) from > dwmci_send_cmd(). > > Am I using the MMC read incorrectly? > It's not that you're using the read incorrectly. 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? Could corrupted memory explain what you're seeing ?