From mboxrd@z Thu Jan 1 00:00:00 1970 From: Baruch Siach Date: Sun, 18 Nov 2018 22:29:08 +0200 Subject: [U-Boot] [PULL] Please pull u-boot-imx In-Reply-To: References: <9d19bc5e-b7aa-d7e3-8eeb-b211360edca0@denx.de> <87r2i64oq1.fsf@tkos.co.il> <20181114070750.rqtlh5dnno6v62ob@sapphire.tkos.co.il> <87sgzyg1d4.fsf@tkos.co.il> Message-ID: <87muq6f7u3.fsf@tkos.co.il> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Ricardo, Ricardo Salveti writes: > On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach wrote: >> Peter Robinson writes: >> > On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti wrote: >> >> On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach wrote: >> >> > On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote: >> >> > > On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam wrote: >> >> > > > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach wrote: >> >> > > > >> >> > > > > I tested current master successfully on Hummingboard2 with i.MX6 Solo >> >> > > > > (SOM rev 1.5): >> >> > > > >> >> > > > Thanks for testing. >> >> > > > >> >> > > > It seems we need more information from Peter about the regression he reported. >> >> > > > >> >> > > > It would be helpful if Peter could run a bisect so that we could >> >> > > > understand where the regression is coming from. >> >> > > >> >> > > Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I >> >> > > can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM >> >> > > i2eX iMX6D - rev 1.3). >> >> > > >> >> > > The patch set that introduced this regression was part of another pull >> >> > > request, the one that introduces eMMC booting support (from Jon >> >> > > Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more >> >> > > testing it seems that the hang happens when trying to verify if the >> >> > > board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), >> >> > > which is not the case for this SOM in particular (and probably why it >> >> > > works fine on most rev 1.5-based SOMs, as eMMC is usually available >> >> > > there). >> >> > > >> >> > > Tested with current u-boot master and the issue is still valid. >> >> > > >> >> > > Jon, did you have any issue when testing that patch set on SOMs >> >> > > without eMMC support? >> >> > >> >> > I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as >> >> > shown in my previous message on this thread. >> >> >> >> Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, >> >> but both without eMMC. >> > >> > I see the issue with a .IMX6Q wirth SOM rev 1.5 (TI wifi, no EMMC) on >> > a hummingboard2 >> >> I could not reproduce with SOM rev 1.3 (no eMMC) on Hummingboard2. >> >> >> > What toolchain are you using? >> >> >> >> Using GCC 8.2 from latest OpenEmbedded. Will try building with the >> >> version you used to see if I get any different behavior. >> > >> > gcc 8.2.x from Fedora 29 >> >> I am using the ARM (Ltd) provided GNU toolchain version 8.2: >> >> => version >> U-Boot 2018.11 (Nov 18 2018 - 11:22:16 +0200) >> >> arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 8.2.1 20180802 >> GNU ld (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 2.30.0.20180625 >> >> >> > What do you see on the serial console? >> >> >> >> It boots up to the point when it tries to find the emmc, and then it >> >> basically hangs completely (tested with current master): >> >> >> >> U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) >> >> Trying to boot from MMC1 >> >> >> >> U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) >> >> >> >> CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) >> >> CPU: Extended Commercial temperature grade (-20C to 105C) at 33C >> >> Reset cause: POR >> >> Board: MX6 HummingBoard2 >> >> DRAM: 1 GiB >> >> MMC: FSL_SDHC: 0, FSL_SDHC: 1 >> >> Loading Environment from MMC... *** Warning - bad CRC, using default environment >> >> >> >> No panel detected: default to HDMI >> >> Display: HDMI (1024x768) >> >> In: serial >> >> Out: serial >> >> Err: serial >> >> ---> hangs >> > >> > Exactly the same as I saw. >> >> Here is what I get at this point: >> >> In: serial >> Out: serial >> Err: serial >> Card did not respond to voltage select! >> Net: FEC >> ... >> >> The error message is from drivers/mmc/mmc.c:mmc_get_op_cond(). The code >> around this point might be the source of your issue. Can you add a few >> prints in mmc_get_op_cond() to pinpoint the call that hangs the code? > > Also tried with ARM's pre-built toolchain (same version), and got the > same hang. Looking a bit further, it basically looks up while waiting > the first mmc command to complete: > > has_emmc -> mmc_get_op_cond -> mmc_send_if_cond (testing for SD > version 2) -> mmc_send_cmd -> esdhc_send_cmd_common -> while > (!(esdhc_read32(®s->irqstat) & flags)) > > And the boot log with MMC_TRACE: > > No panel detected: default to HDMI > Display: HDMI (1024x768) > In: serial > Out: serial > Err: serial > CMD_SEND:0 > ARG 0x00000000 > MMC_RSP_NONE > CMD_SEND:8 > ARG 0x000001AA > > The line where it locks up waiting for the command to complete: > http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=3cdfa7f5a689789ea2f24da867d7c947ab78c002;hb=HEAD#l455 > > Unclear why this only happens with this som/soc, maybe hardware/errata > differences? > > Let me know if you need any extra info. I'll take a look tomorrow. Can you reproduce this hang with these binary images: https://images.solid-build.xyz/IMX6/U-Boot/spl-imx6-sdhc.bin https://images.solid-build.xyz/IMX6/U-Boot/u-boot-imx6-sdhc.img baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -