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 5B63AC678DB for ; Sun, 5 Mar 2023 16:04:31 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1A3F885A6E; Sun, 5 Mar 2023 17:04:28 +0100 (CET) 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="GagDIxYe"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1BB0585D79; Sun, 5 Mar 2023 17:04:26 +0100 (CET) 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 7D92E85A66 for ; Sun, 5 Mar 2023 17:04:22 +0100 (CET) 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 B902460B04; Sun, 5 Mar 2023 16:04:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CB282C433D2; Sun, 5 Mar 2023 16:04:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1678032260; bh=KEB+iO9G4C8YYOiUCGEIMKAeRScFnFZn2xlpQDFBRCc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GagDIxYeveZDvC6uFlIItPyXfRfcfMtQRAbh33X3sNW8j/2ewq0uvpb/s1IaBHFVE WyqaZBsKL9+xy6hbG8i5eij8nlfouktmUochb5MGtwh7daXit4nM9ryf69Zk3nPWQX 2qsbddbdNZCCyOOau3GCGXOuVBTlm27pXSHYbjSfO32RgDMOiNjczLiSWZf14wOxaj 54rp94FoGYbQ1OVfAhVl4S0kbv1TNen+lUy72z9VlAY4ngXDMJfMfbpoI4ORcDrdmu SkTivANJIqELZn0bOMtNAWnEn97VIPnSFw2LlAWvmFYbcfNKY1jFfIgFWQGrhg0eAE qGAUBpQH3nWeA== Received: by pali.im (Postfix) id 017A8B84; Sun, 5 Mar 2023 17:04:16 +0100 (CET) Date: Sun, 5 Mar 2023 17:04:16 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Martin Rowe Cc: u-boot@lists.denx.de Subject: Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot Message-ID: <20230305160416.xc7wlzmkaociwcf7@pali> References: <20230304103851.18965-1-pali@kernel.org> <20230305114634.h6wyi26ohuzuamfg@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230305114634.h6wyi26ohuzuamfg@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.6 at phobos.denx.de X-Virus-Status: Clean On Sunday 05 March 2023 12:46:34 Pali Rohár wrote: > On Sunday 05 March 2023 02:24:27 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:40, Pali Rohár wrote: > > > > > Boot configuration stored in EXT_CSC register is completely ignored by > > > BootROM: > > > > > > https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=8DM5ZQ@mail.gmail.com/ > > > > > > Reflect this eMMC booting in documentation and in the code. > > > > > > Martin, can you test this patch series if SPL and main U-Boot is loaded > > > from the same eMMC HW partition? > > > > > > > boot0: u-boot > > > > Works fine, no issues. > > > > > > boot0: zeroed > > boot1: u-boot > > user: zeroed > > > > It succeeds, eventually... > > ============================== > > BootROM - 1.73 > > > > Booting from MMC > > BootROM: Bad header at offset 00000000 > > BootROM: Bad header at offset 00200000 > > Switching BootPartitions. > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 > > +1000) > > High speed PHY - Version: 2.0 > > EEPROM TLV detection failed: Using static config for Clearfog Pro. > > Detected Device ID 6828 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 3 | SATA0 | > > | 1 | 0 | SGMII1 | > > | 2 | 5 | PCIe1 | > > | 3 | 5 | USB3 HOST1 | > > | 4 | 5 | PCIe2 | > > | 5 | 0 | SGMII2 | > > -------------------------------- > > High speed PHY - Ended Successfully > > mv_ddr: 14.0.0 > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > Trying to boot from MMC1 > > ERROR: Invalid kwbimage v1 > > mmc_load_image_raw_sector: mmc block read error > > spl: mmc: wrong boot mode > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > Timeout waiting card ready > > BootROM: Image checksum verification PASSED > > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 05 2023 - 11:50:45 +1000) > > > > SoC: MV88F6828-A0 at 1600 MHz > > DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) > > Core: 38 devices, 22 uclasses, devicetree: separate > > MMC: mv_sdh: 0 > > Loading Environment from MMC... *** Warning - bad CRC, using default > > environment > > > > Model: SolidRun Clearfog A1 > > Board: SolidRun Clearfog Pro > > Net: > > Warning: ethernet@70000 (eth1) using random MAC address - 12:07:8b:f9:7a:6f > > eth1: ethernet@70000 > > Warning: ethernet@30000 (eth2) using random MAC address - ee:ed:f3:bb:c2:af > > , eth2: ethernet@30000 > > Warning: ethernet@34000 (eth3) using random MAC address - ae:34:b9:bb:28:c6 > > , eth3: ethernet@34000 > > Hit any key to stop autoboot: 0 > > => > > ============================== > > > > Between "Returning to BootROM" and "Timeout waiting card ready" takes > > around 315 seconds. That's long enough that I thought it had hung > > completely and I only noticed it continue because I left it running while > > working on something else. I tried several things to reduce this timeout, > > including reverting to the "non-removable" dts for shdci, but nothing seems > > to affect it. > > Ok. So now it is in the state that it is working but is slow. Better > than nothing. > > Message "Returning to BootROM" is printed by SPL and message > "Timeout waiting card ready" is printed by BootROM. After printing > "Returning to BootROM" is SPL jumping back to the BootROM so the delay > is for sure in the BootROM. So seems that SPL reconfigures eMMC into > state in which BootROM cannot work with it. Something timeouts, BootROM > reconfigure/retry it and then it work again. It would be needed to > investigate what is happening here. My guess is that this could have > something with eMMC HW partition access, and code for switching > partitions near SPL MMCSD_MODE_EMMCBOOT. Try this change? diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c index b20eac3dcd38..eb59c41a824e 100644 --- a/arch/arm/mach-mvebu/spl.c +++ b/arch/arm/mach-mvebu/spl.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include #include @@ -297,11 +298,33 @@ u32 spl_boot_device(void) #endif +void restore_emmc_boot_part_config(void) +{ +#ifdef CONFIG_SPL_MMC + struct mmc *mmc; + int ret; + + mmc = find_mmc_device(0); + if (!mmc || !mmc->has_init || mmc->part_config == MMCPART_NOAVAILABLE) + return; + + ret = mmc_set_part_conf(mmc, + EXT_CSD_EXTRACT_BOOT_ACK(mmc->part_config), + EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config), + EXT_CSD_EXTRACT_PARTITION_ACCESS(mmc->part_config)); + if (ret) + printf("Failed to restore eMMC boot partition configuration\n"); +#endif +} + int board_return_to_bootrom(struct spl_image_info *spl_image, struct spl_boot_device *bootdev) { u32 *regs = *(u32 **)(CONFIG_SPL_STACK + 4); + /* restore original eMMC boot partition configuration - required by BootROM */ + restore_emmc_boot_part_config(); + printf("Returning to BootROM (return address 0x%08x)...\n", regs[13]); return_to_bootrom(); > Could you try another test by completely erasing BOOT0, BOOT1 and USER > data? And see what BootROM prints. > > > > > When bootloader is stored on Boot 0, then SPL should take care of > > > loading and executing main U-Boot. When it is stored on Boot 1 or User > > > Data then SPL should return back to BootROM and let BootROM to load and > > > execute main U-Boot. > > > > > > Pali Rohár (2): > > > tools: kwboot: Fix MMC HW boot partitions info > > > arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition > > > > > > arch/arm/mach-mvebu/Kconfig | 1 + > > > arch/arm/mach-mvebu/spl.c | 13 +++++++------ > > > tools/kwboot.c | 6 +++--- > > > 3 files changed, 11 insertions(+), 9 deletions(-) > > > > > > -- > > > 2.20.1 > > > > > >