[PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
Pali Rohár
pali at kernel.org
Sun Mar 5 17:04:16 CET 2023
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 <pali at kernel.org> 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 at 70000 (eth1) using random MAC address - 12:07:8b:f9:7a:6f
> > eth1: ethernet at 70000
> > Warning: ethernet at 30000 (eth2) using random MAC address - ee:ed:f3:bb:c2:af
> > , eth2: ethernet at 30000
> > Warning: ethernet at 34000 (eth3) using random MAC address - ae:34:b9:bb:28:c6
> > , eth3: ethernet at 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 <image.h>
#include <init.h>
#include <log.h>
+#include <mmc.h>
#include <spl.h>
#include <asm/global_data.h>
#include <asm/io.h>
@@ -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
> > >
> > >
More information about the U-Boot
mailing list