[PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

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?

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

[PATCH RFC u-boot-mvebu 1/2] tools: kwboot: Fix MMC HW boot partitions info

[Pali Rohár]

Boot configuration stored in EXT_CSC register is completely ignored by BootROM.

Fixes: fa03279e198d ("tools: kwboot: Add image type documentation")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 tools/kwboot.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7c666486f31f..1844d7291fe0 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -106,9 +106,9 @@
  *   1024 bytes long sector sizes and also can be changed at runtime.
  *
  *   For MMC-compatible devices, image can be stored at offset 0 or at offset
- *   2 MB. If MMC device supports HW boot partitions then image must be stored
- *   on the HW partition as is configured in the EXT_CSC register (it can be
- *   either boot or user data).
+ *   2 MB. If MMC device supports HW boot partitions then image is read from
+ *   partitions in following order: Boot 0, Boot 1, User Data partition.
+ *   Boot configuration stored in EXT_CSC register is completely ignored.
  *
  *   Note that source address for SDIO image is stored in byte unit, like for
  *   any other images (except SATA). Marvell Functional Specifications for
-- 
2.20.1

[PATCH RFC u-boot-mvebu 2/2] arm: mvebu: spl: Load proper U-Boot from eMMC Boot 0 partition

[Pali Rohár]

Boot configuration stored in EXT_CSC register is completely ignored by
BootROM. So we should skip it too in SPL, to load proper U-Boot from the
same location as from which was loaded SPL by BootROM.

BootROM tries to boot from partitions in this order: Boot 0, Boot 1, User
Data Partition.

In case SPL+U-Boot is stored on Boot 1 or User Data partition then SPL code
skips MMC booting (nothing is valid on Boot 0) and fallback to BootROM
booting which loads proper U-Boot from correct partition (Boot 1 or User
Data).

Implement it via setting CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG and
CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION to fixed values for mvebu.

Fixes: 2f27db2fbd6e ("arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition")
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-mvebu/Kconfig |  1 +
 arch/arm/mach-mvebu/spl.c   | 13 +++++++------
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index ba40c59f4a95..dfc50ec91350 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -336,6 +336,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
 	imply SPL_LIBDISK_SUPPORT
 	imply SPL_MMC
 	select SUPPORT_EMMC_BOOT if SPL_MMC
+	select SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG if SPL_MMC
 	select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC
 	select SPL_BOOTROM_SUPPORT
 
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 6b8c72a71dab..b20eac3dcd38 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -34,8 +34,7 @@
 
 /*
  * When loading U-Boot via SPL from eMMC, the kwbimage main header is stored at
- * sector 0 and either on HW boot partition or on data partition. Choice of HW
- * partition depends on what is configured in eMMC EXT_CSC register.
+ * sector 0 of Boot 0 HW partition.
  * When loading U-Boot via SPL from SD card, the kwbimage main header is stored
  * at sector 1.
  * Therefore MBR/GPT partition booting, fixed sector number and fixed eMMC HW
@@ -46,6 +45,7 @@
  * Runtime mvebu SPL sector calculation code expects:
  * - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0
  * - CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0
+ * - CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION=1
  */
 #ifdef CONFIG_SPL_MMC
 #ifdef CONFIG_SYS_MMCSD_FS_BOOT
@@ -54,11 +54,12 @@
 #ifdef CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
 #error CONFIG_SYS_MMCSD_FS_BOOT_PARTITION is unsupported
 #endif
-#ifdef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
-#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG is unsupported
+#ifndef CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG
+#error CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG must be enabled for SD/eMMC boot support
 #endif
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
-#error CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION is unsupported
+#if !defined(CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION) || \
+    CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION != 1
+#error CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION must be set to 1
 #endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 #error CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION is unsupported
-- 
2.20.1

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Sat, 4 Mar 2023 at 10:40, Pali Rohár <pali@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@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.

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
>
>

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Sunday 05 March 2023 02:24:27 Martin Rowe wrote:
> On Sat, 4 Mar 2023 at 10:40, Pali Rohár <pali@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@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.

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
> >
> >

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

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@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@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 <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
> > >
> > >

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:

> 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@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@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 <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();
>

Same result, around 5 minutes wait after returning to BootROM:
=====================================
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 06 2023 - 21:02:40
+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 06 2023 - 21:02:40 +1000)
=====================================

> Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > data? And see what BootROM prints.
>

=====================================
BootROM - 1.73

Booting from MMC
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad h
Trying Uart
=====================================

> >
> > > 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
> > > >
> > > >
>

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:
> 
> > 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@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@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 <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();
> >
> 
> Same result, around 5 minutes wait after returning to BootROM:

Could you try to print mmc->part_config (ideally as early as possible)?

> =====================================
> 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 06 2023 - 21:02:40
> +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 06 2023 - 21:02:40 +1000)
> =====================================
> 
> > Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > > data? And see what BootROM prints.
> >
> 
> =====================================
> BootROM - 1.73
> 
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad h
> Trying Uart
> =====================================
> 
> > >
> > > > 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
> > > > >
> > > > >
> >

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:
> > Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > > data? And see what BootROM prints.
> >
> 
> =====================================
> BootROM - 1.73
> 
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad h
> Trying Uart
> =====================================

Originally I though that I did not understand disassembled bootrom code
correctly but this logs proves that I did it correctly. Log is very
strange.

There is a loop which tries partition numbers 0x1, 0x2, ... 0x9, 0xa.

And if I'm looking at the bootrom code correctly it does bit-AND
operation on partition number with constant 0x7 and result is set into
mmc register 179 (partition_config).

So if I understand it correctly it means that bootrom automatically
clears boot_ack and boot_partition. And into partition_access it sets
the partition number. Hence numbers 0x9 and 0xa are trimmed and
aliased to 0x1 and 0x2; and number 0x8 overflows to 0x0.

Completely strange behavior and probably against how HW mmc boot
partitions should be used.

eMMC spec defines:
partition_access (low 3 bits of mmc 179/partition_config register):
0x0 : No access to boot partition (default)
0x1 : R/W boot partition 1
0x2 : R/W boot partition 2
0x3 : R/W Replay Protected Memory Block (RPMB)
0x4 : Access to General Purpose partition 1
0x5 : Access to General Purpose partition 2
0x6 : Access to General Purpose partition 3
0x7 : Access to General Purpose partition 4

I guess that you do not have general purpose partitions layout on emmc
and RPMB is not used too. So technically only 0x0, 0x1, and 0x2 are
available.

To confirm my theory, could you try to do following tests?

1. Check u-boot's "mmc partconf" settings are not preserved across
reboots.

2. Put valid image into userdata partition; erase boot 0 and boot 1; and
post bootrom output. There should be 7 invalid attempts with Switching
BootPartitions message.

3. Take valid image, invalidate kwb header checksum and put it on boot0;
plus erase boot1 and user. Bootrom should print "Invalid header
checksum" message and it should be two times. Once for 0x1 and second
time for overflowed 0x9.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Monday 06 March 2023 12:53:25 Pali Rohár wrote:
> On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> > On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:
> > 
> > > 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@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@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 <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();
> > >
> > 
> > Same result, around 5 minutes wait after returning to BootROM:
> 
> Could you try to print mmc->part_config (ideally as early as possible)?

If you have time, please look this and other email, so I can try to
prepare different patch for testing.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:

> On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> > On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:
> >
> > > 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@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@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 <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();
> > >
> >
> > Same result, around 5 minutes wait after returning to BootROM:
>
> Could you try to print mmc->part_config (ideally as early as possible)?
>

In SPL mmc->part_config is 255
In main u-boot at the start of clearfog.c board_init() mmc->part_config is
255
In main u-boot at the start of clearfog.c checkboard() mmc->part_config is
8 (ack: 0, partition_enable: 1, access: 0)

If I set partition_enable to 2, I get the same result except the value is
16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the last value

<partition_enable 1>
BootROM - 1.73

Booting from MMC

U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
+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
spl.c spl_boot_device part_config = 255
Trying to boot from MMC1


U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
clearfog.c board_init part_config = 255
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
clearfog.c checkboard part_config = 8
Board: SolidRun Clearfog Pro
Net:
Warning: ethernet@70000 (eth1) using random MAC address - 32:16:0e:b4:d1:d8
eth1: ethernet@70000
Warning: ethernet@30000 (eth2) using random MAC address - 72:30:3f:79:07:12
, eth2: ethernet@30000
Warning: ethernet@34000 (eth3) using random MAC address - 82:fb:71:23:46:4f
, eth3: ethernet@34000
Hit any key to stop autoboot:  0
=> mmc partconf 0
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x0
BOOT_PARTITION_ENABLE: 0x1
PARTITION_ACCESS: 0x0
</partition_enable 1>

<partition_enable 2>
BootROM - 1.73

Booting from MMC

U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
+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
spl.c spl_boot_device part_config = 255
Trying to boot from MMC1


U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
clearfog.c board_init part_config = 255
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
clearfog.c checkboard part_config = 16
Board: SolidRun Clearfog Pro
Net:
Warning: ethernet@70000 (eth1) using random MAC address - 92:5a:fc:14:e8:f6
eth1: ethernet@70000
Warning: ethernet@30000 (eth2) using random MAC address - 42:9c:d8:3a:cb:b2
, eth2: ethernet@30000
Warning: ethernet@34000 (eth3) using random MAC address - c6:99:20:f4:02:a0
, eth3: ethernet@34000
Hit any key to stop autoboot:  0
=> mmc partconf 0
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x0
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0
</partition_enable 2>

I'm having trouble trying to find the hooks which run between board_init
and checkboard. If you can point me in the right direction I'm happy to
re-run and try to narrow down where the valid values are being set from.

> =====================================
> > 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 06 2023 - 21:02:40
> > +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 06 2023 - 21:02:40 +1000)
> > =====================================
> >
> > > Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > > > data? And see what BootROM prints.
> > >
> >
> > =====================================
> > BootROM - 1.73
> >
> > Booting from MMC
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad h
> > Trying Uart
> > =====================================
> >
> > > >
> > > > > 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
> > > > > >
> > > > > >
> > >
>

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Mon, 6 Mar 2023 at 18:40, Pali Rohár <pali@kernel.org> wrote:

> On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> > On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:
> > > Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > > > data? And see what BootROM prints.
> > >
> >
> > =====================================
> > BootROM - 1.73
> >
> > Booting from MMC
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad header at offset 00200000
> > Switching BootPartitions.
> > BootROM: Bad header at offset 00000000
> > BootROM: Bad h
> > Trying Uart
> > =====================================
>
> Originally I though that I did not understand disassembled bootrom code
> correctly but this logs proves that I did it correctly. Log is very
> strange.
>
> There is a loop which tries partition numbers 0x1, 0x2, ... 0x9, 0xa.
>
> And if I'm looking at the bootrom code correctly it does bit-AND
> operation on partition number with constant 0x7 and result is set into
> mmc register 179 (partition_config).
>
> So if I understand it correctly it means that bootrom automatically
> clears boot_ack and boot_partition. And into partition_access it sets
> the partition number. Hence numbers 0x9 and 0xa are trimmed and
> aliased to 0x1 and 0x2; and number 0x8 overflows to 0x0.
>
> Completely strange behavior and probably against how HW mmc boot
> partitions should be used.
>
> eMMC spec defines:
> partition_access (low 3 bits of mmc 179/partition_config register):
> 0x0 : No access to boot partition (default)
> 0x1 : R/W boot partition 1
> 0x2 : R/W boot partition 2
> 0x3 : R/W Replay Protected Memory Block (RPMB)
> 0x4 : Access to General Purpose partition 1
> 0x5 : Access to General Purpose partition 2
> 0x6 : Access to General Purpose partition 3
> 0x7 : Access to General Purpose partition 4
>

 I can only set 0, 1, 2, and 7; the others result in `exit not allowed from
main input shell.`


> I guess that you do not have general purpose partitions layout on emmc
> and RPMB is not used too. So technically only 0x0, 0x1, and 0x2 are
> available.
>
> To confirm my theory, could you try to do following tests?
>
> 1. Check u-boot's "mmc partconf" settings are not preserved across
> reboots.
>

The only part that seems to be preserved is the partition_enable; ack and
access both reset to 0.


> 2. Put valid image into userdata partition; erase boot 0 and boot 1; and
> post bootrom output. There should be 7 invalid attempts with Switching
> BootPartitions message.
>

7 invalid attempts before it finds u-boot in the userdata partition:

<user output>
BootROM - 1.73

Booting from MMC
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.
BootROM: Bad header at offset 00000000
BootROM: Bad header at offset 00200000
Switching BootPartitions.

U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
+1000)
</user output>


> 3. Take valid image, invalidate kwb header checksum and put it on boot0;
> plus erase boot1 and user. Bootrom should print "Invalid header
> checksum" message and it should be two times. Once for 0x1 and second
> time for overflowed 0x9.
>

Changing just the checksum at 0x1F results in BootROM producing no output
and just hanging. I've tried on each boot partition (with the others
zeroed) and can't get any results at all. I also tried a valid header and
zeroes for the rest of the image; same result.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> 
> > Could you try to print mmc->part_config (ideally as early as possible)?
> >
> 
> In SPL mmc->part_config is 255
> In main u-boot at the start of clearfog.c board_init() mmc->part_config is
> 255
> In main u-boot at the start of clearfog.c checkboard() mmc->part_config is
> 8 (ack: 0, partition_enable: 1, access: 0)

255 is uninitialized value.

> If I set partition_enable to 2, I get the same result except the value is
> 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the last value

Try to change "access" bits.

> <partition_enable 1>
> BootROM - 1.73
> 
> Booting from MMC
> 
> U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> +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
> spl.c spl_boot_device part_config = 255
> Trying to boot from MMC1
> 
> 
> U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> 
> SoC:   MV88F6828-A0 at 1600 MHz
> DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> clearfog.c board_init part_config = 255
> 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
> clearfog.c checkboard part_config = 8
> Board: SolidRun Clearfog Pro
> Net:
> Warning: ethernet@70000 (eth1) using random MAC address - 32:16:0e:b4:d1:d8
> eth1: ethernet@70000
> Warning: ethernet@30000 (eth2) using random MAC address - 72:30:3f:79:07:12
> , eth2: ethernet@30000
> Warning: ethernet@34000 (eth3) using random MAC address - 82:fb:71:23:46:4f
> , eth3: ethernet@34000
> Hit any key to stop autoboot:  0
> => mmc partconf 0
> EXT_CSD[179], PARTITION_CONFIG:
> BOOT_ACK: 0x0
> BOOT_PARTITION_ENABLE: 0x1
> PARTITION_ACCESS: 0x0
> </partition_enable 1>
> 
> <partition_enable 2>
> BootROM - 1.73
> 
> Booting from MMC
> 
> U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> +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
> spl.c spl_boot_device part_config = 255
> Trying to boot from MMC1
> 
> 
> U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> 
> SoC:   MV88F6828-A0 at 1600 MHz
> DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> clearfog.c board_init part_config = 255
> 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
> clearfog.c checkboard part_config = 16
> Board: SolidRun Clearfog Pro
> Net:
> Warning: ethernet@70000 (eth1) using random MAC address - 92:5a:fc:14:e8:f6
> eth1: ethernet@70000
> Warning: ethernet@30000 (eth2) using random MAC address - 42:9c:d8:3a:cb:b2
> , eth2: ethernet@30000
> Warning: ethernet@34000 (eth3) using random MAC address - c6:99:20:f4:02:a0
> , eth3: ethernet@34000
> Hit any key to stop autoboot:  0
> => mmc partconf 0
> EXT_CSD[179], PARTITION_CONFIG:
> BOOT_ACK: 0x0
> BOOT_PARTITION_ENABLE: 0x2
> PARTITION_ACCESS: 0x0
> </partition_enable 2>

Are both logs from the configuration when SPL+u-boot is stored on Boot0?
Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
interested to see if "access" bits are changed in SPL (before loading
main u-boot).

> I'm having trouble trying to find the hooks which run between board_init
> and checkboard. If you can point me in the right direction I'm happy to
> re-run and try to narrow down where the valid values are being set from.

Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
I want to see original value from EXT_CSD_PART_CONF.

I do not know which hook is the best, so printing it from mmc.c driver
should work better.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Sunday 19 March 2023 02:30:07 Martin Rowe wrote:
> On Mon, 6 Mar 2023 at 18:40, Pali Rohár <pali@kernel.org> wrote:
> 
> > On Monday 06 March 2023 11:15:35 Martin Rowe wrote:
> > > On Sun, 5 Mar 2023 at 16:04, Pali Rohár <pali@kernel.org> wrote:
> > > > Could you try another test by completely erasing BOOT0, BOOT1 and USER
> > > > > data? And see what BootROM prints.
> > > >
> > >
> > > =====================================
> > > BootROM - 1.73
> > >
> > > Booting from MMC
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad header at offset 00200000
> > > Switching BootPartitions.
> > > BootROM: Bad header at offset 00000000
> > > BootROM: Bad h
> > > Trying Uart
> > > =====================================
> >
> > Originally I though that I did not understand disassembled bootrom code
> > correctly but this logs proves that I did it correctly. Log is very
> > strange.
> >
> > There is a loop which tries partition numbers 0x1, 0x2, ... 0x9, 0xa.
> >
> > And if I'm looking at the bootrom code correctly it does bit-AND
> > operation on partition number with constant 0x7 and result is set into
> > mmc register 179 (partition_config).
> >
> > So if I understand it correctly it means that bootrom automatically
> > clears boot_ack and boot_partition. And into partition_access it sets
> > the partition number. Hence numbers 0x9 and 0xa are trimmed and
> > aliased to 0x1 and 0x2; and number 0x8 overflows to 0x0.
> >
> > Completely strange behavior and probably against how HW mmc boot
> > partitions should be used.
> >
> > eMMC spec defines:
> > partition_access (low 3 bits of mmc 179/partition_config register):
> > 0x0 : No access to boot partition (default)
> > 0x1 : R/W boot partition 1
> > 0x2 : R/W boot partition 2
> > 0x3 : R/W Replay Protected Memory Block (RPMB)
> > 0x4 : Access to General Purpose partition 1
> > 0x5 : Access to General Purpose partition 2
> > 0x6 : Access to General Purpose partition 3
> > 0x7 : Access to General Purpose partition 4
> >
> 
>  I can only set 0, 1, 2, and 7; the others result in `exit not allowed from
> main input shell.`

Bingo, you found a new bug in u-boot mmc code. I hope that this patch fixes it:
https://patchwork.ozlabs.org/project/uboot/patch/20230319163342.15385-1-pali@kernel.org/

> > I guess that you do not have general purpose partitions layout on emmc
> > and RPMB is not used too. So technically only 0x0, 0x1, and 0x2 are
> > available.
> >
> > To confirm my theory, could you try to do following tests?
> >
> > 1. Check u-boot's "mmc partconf" settings are not preserved across
> > reboots.
> >
> 
> The only part that seems to be preserved is the partition_enable; ack and
> access both reset to 0.

Ok, it is possible that U-Boot itself overwrite access bits and hence
via "mmc partconf" command it is not possible to "print it".

Could you try to check current settings in SPL via mmc.c hook which I
described in previous email?

> > 2. Put valid image into userdata partition; erase boot 0 and boot 1; and
> > post bootrom output. There should be 7 invalid attempts with Switching
> > BootPartitions message.
> >
> 
> 7 invalid attempts before it finds u-boot in the userdata partition:
> 
> <user output>
> BootROM - 1.73
> 
> Booting from MMC
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> BootROM: Bad header at offset 00000000
> BootROM: Bad header at offset 00200000
> Switching BootPartitions.
> 
> U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> +1000)
> </user output>

Ok, so this test fully confirms my theory about what "Switching
BootPartitions" means.

> 
> > 3. Take valid image, invalidate kwb header checksum and put it on boot0;
> > plus erase boot1 and user. Bootrom should print "Invalid header
> > checksum" message and it should be two times. Once for 0x1 and second
> > time for overflowed 0x9.
> >
> 
> Changing just the checksum at 0x1F results in BootROM producing no output
> and just hanging. I've tried on each boot partition (with the others
> zeroed) and can't get any results at all. I also tried a valid header and
> zeroes for the rest of the image; same result.

Ok, probably this is another hit of debug log BootROM bug (as I
documented it in kwboot.1 manpage). In this case we are not able to get
BootROM output over UART.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:

> On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> >
> > > Could you try to print mmc->part_config (ideally as early as possible)?
> > >
> >
> > In SPL mmc->part_config is 255
> > In main u-boot at the start of clearfog.c board_init() mmc->part_config
> is
> > 255
> > In main u-boot at the start of clearfog.c checkboard() mmc->part_config
> is
> > 8 (ack: 0, partition_enable: 1, access: 0)
>
> 255 is uninitialized value.
>
> > If I set partition_enable to 2, I get the same result except the value is
> > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the last
> value
>
> Try to change "access" bits.
>
> > <partition_enable 1>
> > BootROM - 1.73
> >
> > Booting from MMC
> >
> > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > +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
> > spl.c spl_boot_device part_config = 255
> > Trying to boot from MMC1
> >
> >
> > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> >
> > SoC:   MV88F6828-A0 at 1600 MHz
> > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > clearfog.c board_init part_config = 255
> > 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
> > clearfog.c checkboard part_config = 8
> > Board: SolidRun Clearfog Pro
> > Net:
> > Warning: ethernet@70000 (eth1) using random MAC address -
> 32:16:0e:b4:d1:d8
> > eth1: ethernet@70000
> > Warning: ethernet@30000 (eth2) using random MAC address -
> 72:30:3f:79:07:12
> > , eth2: ethernet@30000
> > Warning: ethernet@34000 (eth3) using random MAC address -
> 82:fb:71:23:46:4f
> > , eth3: ethernet@34000
> > Hit any key to stop autoboot:  0
> > => mmc partconf 0
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x0
> > BOOT_PARTITION_ENABLE: 0x1
> > PARTITION_ACCESS: 0x0
> > </partition_enable 1>
> >
> > <partition_enable 2>
> > BootROM - 1.73
> >
> > Booting from MMC
> >
> > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > +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
> > spl.c spl_boot_device part_config = 255
> > Trying to boot from MMC1
> >
> >
> > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> >
> > SoC:   MV88F6828-A0 at 1600 MHz
> > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > clearfog.c board_init part_config = 255
> > 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
> > clearfog.c checkboard part_config = 16
> > Board: SolidRun Clearfog Pro
> > Net:
> > Warning: ethernet@70000 (eth1) using random MAC address -
> 92:5a:fc:14:e8:f6
> > eth1: ethernet@70000
> > Warning: ethernet@30000 (eth2) using random MAC address -
> 42:9c:d8:3a:cb:b2
> > , eth2: ethernet@30000
> > Warning: ethernet@34000 (eth3) using random MAC address -
> c6:99:20:f4:02:a0
> > , eth3: ethernet@34000
> > Hit any key to stop autoboot:  0
> > => mmc partconf 0
> > EXT_CSD[179], PARTITION_CONFIG:
> > BOOT_ACK: 0x0
> > BOOT_PARTITION_ENABLE: 0x2
> > PARTITION_ACCESS: 0x0
> > </partition_enable 2>
>
> Are both logs from the configuration when SPL+u-boot is stored on Boot0?
> Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> interested to see if "access" bits are changed in SPL (before loading
> main u-boot).
>
> > I'm having trouble trying to find the hooks which run between board_init
> > and checkboard. If you can point me in the right direction I'm happy to
> > re-run and try to narrow down where the valid values are being set from.
>
> Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> I want to see original value from EXT_CSD_PART_CONF.
>
> I do not know which hook is the best, so printing it from mmc.c driver
> should work better.
>

u-boot in boot0, partconf set to 0x1:
mmc->part_config = 8

u-boot in boot0, partconf set to 0x2:
mmc->part_config = 16

u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
mmc->part_config = 8

u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
mmc->part_config = 16

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> 
> > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > > Could you try to print mmc->part_config (ideally as early as possible)?
> > > >
> > >
> > > In SPL mmc->part_config is 255
> > > In main u-boot at the start of clearfog.c board_init() mmc->part_config
> > is
> > > 255
> > > In main u-boot at the start of clearfog.c checkboard() mmc->part_config
> > is
> > > 8 (ack: 0, partition_enable: 1, access: 0)
> >
> > 255 is uninitialized value.
> >
> > > If I set partition_enable to 2, I get the same result except the value is
> > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the last
> > value
> >
> > Try to change "access" bits.
> >
> > > <partition_enable 1>
> > > BootROM - 1.73
> > >
> > > Booting from MMC
> > >
> > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > +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
> > > spl.c spl_boot_device part_config = 255
> > > Trying to boot from MMC1
> > >
> > >
> > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> > >
> > > SoC:   MV88F6828-A0 at 1600 MHz
> > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > clearfog.c board_init part_config = 255
> > > 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
> > > clearfog.c checkboard part_config = 8
> > > Board: SolidRun Clearfog Pro
> > > Net:
> > > Warning: ethernet@70000 (eth1) using random MAC address -
> > 32:16:0e:b4:d1:d8
> > > eth1: ethernet@70000
> > > Warning: ethernet@30000 (eth2) using random MAC address -
> > 72:30:3f:79:07:12
> > > , eth2: ethernet@30000
> > > Warning: ethernet@34000 (eth3) using random MAC address -
> > 82:fb:71:23:46:4f
> > > , eth3: ethernet@34000
> > > Hit any key to stop autoboot:  0
> > > => mmc partconf 0
> > > EXT_CSD[179], PARTITION_CONFIG:
> > > BOOT_ACK: 0x0
> > > BOOT_PARTITION_ENABLE: 0x1
> > > PARTITION_ACCESS: 0x0
> > > </partition_enable 1>
> > >
> > > <partition_enable 2>
> > > BootROM - 1.73
> > >
> > > Booting from MMC
> > >
> > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > +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
> > > spl.c spl_boot_device part_config = 255
> > > Trying to boot from MMC1
> > >
> > >
> > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> > >
> > > SoC:   MV88F6828-A0 at 1600 MHz
> > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > clearfog.c board_init part_config = 255
> > > 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
> > > clearfog.c checkboard part_config = 16
> > > Board: SolidRun Clearfog Pro
> > > Net:
> > > Warning: ethernet@70000 (eth1) using random MAC address -
> > 92:5a:fc:14:e8:f6
> > > eth1: ethernet@70000
> > > Warning: ethernet@30000 (eth2) using random MAC address -
> > 42:9c:d8:3a:cb:b2
> > > , eth2: ethernet@30000
> > > Warning: ethernet@34000 (eth3) using random MAC address -
> > c6:99:20:f4:02:a0
> > > , eth3: ethernet@34000
> > > Hit any key to stop autoboot:  0
> > > => mmc partconf 0
> > > EXT_CSD[179], PARTITION_CONFIG:
> > > BOOT_ACK: 0x0
> > > BOOT_PARTITION_ENABLE: 0x2
> > > PARTITION_ACCESS: 0x0
> > > </partition_enable 2>
> >
> > Are both logs from the configuration when SPL+u-boot is stored on Boot0?
> > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > interested to see if "access" bits are changed in SPL (before loading
> > main u-boot).
> >
> > > I'm having trouble trying to find the hooks which run between board_init
> > > and checkboard. If you can point me in the right direction I'm happy to
> > > re-run and try to narrow down where the valid values are being set from.
> >
> > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > I want to see original value from EXT_CSD_PART_CONF.
> >
> > I do not know which hook is the best, so printing it from mmc.c driver
> > should work better.
> >
> 
> u-boot in boot0, partconf set to 0x1:
> mmc->part_config = 8
> 
> u-boot in boot0, partconf set to 0x2:
> mmc->part_config = 16
> 
> u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> mmc->part_config = 8
> 
> u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> mmc->part_config = 16

Ah, that does not look useful :-(

Just to confirm, is this output from SPL or from main U-Boot?

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:

> On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> >
> > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > > Could you try to print mmc->part_config (ideally as early as
> possible)?
> > > > >
> > > >
> > > > In SPL mmc->part_config is 255
> > > > In main u-boot at the start of clearfog.c board_init()
> mmc->part_config
> > > is
> > > > 255
> > > > In main u-boot at the start of clearfog.c checkboard()
> mmc->part_config
> > > is
> > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > >
> > > 255 is uninitialized value.
> > >
> > > > If I set partition_enable to 2, I get the same result except the
> value is
> > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> last
> > > value
> > >
> > > Try to change "access" bits.
> > >
> > > > <partition_enable 1>
> > > > BootROM - 1.73
> > > >
> > > > Booting from MMC
> > > >
> > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> 10:05:32
> > > > +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
> > > > spl.c spl_boot_device part_config = 255
> > > > Trying to boot from MMC1
> > > >
> > > >
> > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> +1000)
> > > >
> > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > clearfog.c board_init part_config = 255
> > > > 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
> > > > clearfog.c checkboard part_config = 8
> > > > Board: SolidRun Clearfog Pro
> > > > Net:
> > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > 32:16:0e:b4:d1:d8
> > > > eth1: ethernet@70000
> > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > 72:30:3f:79:07:12
> > > > , eth2: ethernet@30000
> > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > 82:fb:71:23:46:4f
> > > > , eth3: ethernet@34000
> > > > Hit any key to stop autoboot:  0
> > > > => mmc partconf 0
> > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > BOOT_ACK: 0x0
> > > > BOOT_PARTITION_ENABLE: 0x1
> > > > PARTITION_ACCESS: 0x0
> > > > </partition_enable 1>
> > > >
> > > > <partition_enable 2>
> > > > BootROM - 1.73
> > > >
> > > > Booting from MMC
> > > >
> > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> 10:05:32
> > > > +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
> > > > spl.c spl_boot_device part_config = 255
> > > > Trying to boot from MMC1
> > > >
> > > >
> > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> +1000)
> > > >
> > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > clearfog.c board_init part_config = 255
> > > > 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
> > > > clearfog.c checkboard part_config = 16
> > > > Board: SolidRun Clearfog Pro
> > > > Net:
> > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > 92:5a:fc:14:e8:f6
> > > > eth1: ethernet@70000
> > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > 42:9c:d8:3a:cb:b2
> > > > , eth2: ethernet@30000
> > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > c6:99:20:f4:02:a0
> > > > , eth3: ethernet@34000
> > > > Hit any key to stop autoboot:  0
> > > > => mmc partconf 0
> > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > BOOT_ACK: 0x0
> > > > BOOT_PARTITION_ENABLE: 0x2
> > > > PARTITION_ACCESS: 0x0
> > > > </partition_enable 2>
> > >
> > > Are both logs from the configuration when SPL+u-boot is stored on
> Boot0?
> > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > > interested to see if "access" bits are changed in SPL (before loading
> > > main u-boot).
> > >
> > > > I'm having trouble trying to find the hooks which run between
> board_init
> > > > and checkboard. If you can point me in the right direction I'm happy
> to
> > > > re-run and try to narrow down where the valid values are being set
> from.
> > >
> > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > > I want to see original value from EXT_CSD_PART_CONF.
> > >
> > > I do not know which hook is the best, so printing it from mmc.c driver
> > > should work better.
> > >
> >
> > u-boot in boot0, partconf set to 0x1:
> > mmc->part_config = 8
> >
> > u-boot in boot0, partconf set to 0x2:
> > mmc->part_config = 16
> >
> > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > mmc->part_config = 8
> >
> > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > mmc->part_config = 16
>
> Ah, that does not look useful :-(
>
> Just to confirm, is this output from SPL or from main U-Boot?
>

Definitely SPL. I triple checked because I was also disappointed with those
results. With BootROM hardcoded with its boot order it seems like neither
CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
mmc->part_config is going to work well.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> 
> > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > > > >
> > > > > > Could you try to print mmc->part_config (ideally as early as
> > possible)?
> > > > > >
> > > > >
> > > > > In SPL mmc->part_config is 255
> > > > > In main u-boot at the start of clearfog.c board_init()
> > mmc->part_config
> > > > is
> > > > > 255
> > > > > In main u-boot at the start of clearfog.c checkboard()
> > mmc->part_config
> > > > is
> > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > > >
> > > > 255 is uninitialized value.
> > > >
> > > > > If I set partition_enable to 2, I get the same result except the
> > value is
> > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> > last
> > > > value
> > > >
> > > > Try to change "access" bits.
> > > >
> > > > > <partition_enable 1>
> > > > > BootROM - 1.73
> > > > >
> > > > > Booting from MMC
> > > > >
> > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > 10:05:32
> > > > > +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
> > > > > spl.c spl_boot_device part_config = 255
> > > > > Trying to boot from MMC1
> > > > >
> > > > >
> > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > +1000)
> > > > >
> > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > clearfog.c board_init part_config = 255
> > > > > 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
> > > > > clearfog.c checkboard part_config = 8
> > > > > Board: SolidRun Clearfog Pro
> > > > > Net:
> > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > 32:16:0e:b4:d1:d8
> > > > > eth1: ethernet@70000
> > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > 72:30:3f:79:07:12
> > > > > , eth2: ethernet@30000
> > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > 82:fb:71:23:46:4f
> > > > > , eth3: ethernet@34000
> > > > > Hit any key to stop autoboot:  0
> > > > > => mmc partconf 0
> > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > > BOOT_ACK: 0x0
> > > > > BOOT_PARTITION_ENABLE: 0x1
> > > > > PARTITION_ACCESS: 0x0
> > > > > </partition_enable 1>
> > > > >
> > > > > <partition_enable 2>
> > > > > BootROM - 1.73
> > > > >
> > > > > Booting from MMC
> > > > >
> > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > 10:05:32
> > > > > +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
> > > > > spl.c spl_boot_device part_config = 255
> > > > > Trying to boot from MMC1
> > > > >
> > > > >
> > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > +1000)
> > > > >
> > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > clearfog.c board_init part_config = 255
> > > > > 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
> > > > > clearfog.c checkboard part_config = 16
> > > > > Board: SolidRun Clearfog Pro
> > > > > Net:
> > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > 92:5a:fc:14:e8:f6
> > > > > eth1: ethernet@70000
> > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > 42:9c:d8:3a:cb:b2
> > > > > , eth2: ethernet@30000
> > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > c6:99:20:f4:02:a0
> > > > > , eth3: ethernet@34000
> > > > > Hit any key to stop autoboot:  0
> > > > > => mmc partconf 0
> > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > > BOOT_ACK: 0x0
> > > > > BOOT_PARTITION_ENABLE: 0x2
> > > > > PARTITION_ACCESS: 0x0
> > > > > </partition_enable 2>
> > > >
> > > > Are both logs from the configuration when SPL+u-boot is stored on
> > Boot0?
> > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > > > interested to see if "access" bits are changed in SPL (before loading
> > > > main u-boot).
> > > >
> > > > > I'm having trouble trying to find the hooks which run between
> > board_init
> > > > > and checkboard. If you can point me in the right direction I'm happy
> > to
> > > > > re-run and try to narrow down where the valid values are being set
> > from.
> > > >
> > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > > > I want to see original value from EXT_CSD_PART_CONF.
> > > >
> > > > I do not know which hook is the best, so printing it from mmc.c driver
> > > > should work better.
> > > >
> > >
> > > u-boot in boot0, partconf set to 0x1:
> > > mmc->part_config = 8
> > >
> > > u-boot in boot0, partconf set to 0x2:
> > > mmc->part_config = 16
> > >
> > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > > mmc->part_config = 8
> > >
> > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > > mmc->part_config = 16
> >
> > Ah, that does not look useful :-(
> >
> > Just to confirm, is this output from SPL or from main U-Boot?
> >
> 
> Definitely SPL. I triple checked because I was also disappointed with those
> results. With BootROM hardcoded with its boot order it seems like neither
> CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> mmc->part_config is going to work well.

In emmc spec is written:

Each time the host wants to access a partition the following flow shall be executed:
1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
2. Issue commands referred to the selected partition
3. Restore default access to the User Data Area or re-direction the access to another partition
All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.

I'm feeling that partition_access bits should be preserved between
reading data from boot0 and starting SPL. And these bits somehow could
be used to determinate from which source bootrom loaded SPL. Maybe the
last point ("all the reset events...") applies there and u-boot mmc
driver does some reset in its init phase? And need to figure
out how to read PARTITION_ACCESS without u-boot's mmc driver?

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:

> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> >
> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > > > > >
> > > > > > > Could you try to print mmc->part_config (ideally as early as
> > > possible)?
> > > > > > >
> > > > > >
> > > > > > In SPL mmc->part_config is 255
> > > > > > In main u-boot at the start of clearfog.c board_init()
> > > mmc->part_config
> > > > > is
> > > > > > 255
> > > > > > In main u-boot at the start of clearfog.c checkboard()
> > > mmc->part_config
> > > > > is
> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > > > >
> > > > > 255 is uninitialized value.
> > > > >
> > > > > > If I set partition_enable to 2, I get the same result except the
> > > value is
> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> > > last
> > > > > value
> > > > >
> > > > > Try to change "access" bits.
> > > > >
> > > > > > <partition_enable 1>
> > > > > > BootROM - 1.73
> > > > > >
> > > > > > Booting from MMC
> > > > > >
> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > 10:05:32
> > > > > > +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
> > > > > > spl.c spl_boot_device part_config = 255
> > > > > > Trying to boot from MMC1
> > > > > >
> > > > > >
> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> 10:05:32
> > > +1000)
> > > > > >
> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > > clearfog.c board_init part_config = 255
> > > > > > 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
> > > > > > clearfog.c checkboard part_config = 8
> > > > > > Board: SolidRun Clearfog Pro
> > > > > > Net:
> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > > 32:16:0e:b4:d1:d8
> > > > > > eth1: ethernet@70000
> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > > 72:30:3f:79:07:12
> > > > > > , eth2: ethernet@30000
> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > > 82:fb:71:23:46:4f
> > > > > > , eth3: ethernet@34000
> > > > > > Hit any key to stop autoboot:  0
> > > > > > => mmc partconf 0
> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > > > BOOT_ACK: 0x0
> > > > > > BOOT_PARTITION_ENABLE: 0x1
> > > > > > PARTITION_ACCESS: 0x0
> > > > > > </partition_enable 1>
> > > > > >
> > > > > > <partition_enable 2>
> > > > > > BootROM - 1.73
> > > > > >
> > > > > > Booting from MMC
> > > > > >
> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > 10:05:32
> > > > > > +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
> > > > > > spl.c spl_boot_device part_config = 255
> > > > > > Trying to boot from MMC1
> > > > > >
> > > > > >
> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> 10:05:32
> > > +1000)
> > > > > >
> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > > clearfog.c board_init part_config = 255
> > > > > > 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
> > > > > > clearfog.c checkboard part_config = 16
> > > > > > Board: SolidRun Clearfog Pro
> > > > > > Net:
> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > > 92:5a:fc:14:e8:f6
> > > > > > eth1: ethernet@70000
> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > > 42:9c:d8:3a:cb:b2
> > > > > > , eth2: ethernet@30000
> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > > c6:99:20:f4:02:a0
> > > > > > , eth3: ethernet@34000
> > > > > > Hit any key to stop autoboot:  0
> > > > > > => mmc partconf 0
> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > > > BOOT_ACK: 0x0
> > > > > > BOOT_PARTITION_ENABLE: 0x2
> > > > > > PARTITION_ACCESS: 0x0
> > > > > > </partition_enable 2>
> > > > >
> > > > > Are both logs from the configuration when SPL+u-boot is stored on
> > > Boot0?
> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > > > > interested to see if "access" bits are changed in SPL (before
> loading
> > > > > main u-boot).
> > > > >
> > > > > > I'm having trouble trying to find the hooks which run between
> > > board_init
> > > > > > and checkboard. If you can point me in the right direction I'm
> happy
> > > to
> > > > > > re-run and try to narrow down where the valid values are being
> set
> > > from.
> > > > >
> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > > > > I want to see original value from EXT_CSD_PART_CONF.
> > > > >
> > > > > I do not know which hook is the best, so printing it from mmc.c
> driver
> > > > > should work better.
> > > > >
> > > >
> > > > u-boot in boot0, partconf set to 0x1:
> > > > mmc->part_config = 8
> > > >
> > > > u-boot in boot0, partconf set to 0x2:
> > > > mmc->part_config = 16
> > > >
> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > > > mmc->part_config = 8
> > > >
> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > > > mmc->part_config = 16
> > >
> > > Ah, that does not look useful :-(
> > >
> > > Just to confirm, is this output from SPL or from main U-Boot?
> > >
> >
> > Definitely SPL. I triple checked because I was also disappointed with
> those
> > results. With BootROM hardcoded with its boot order it seems like neither
> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> > mmc->part_config is going to work well.
>
> In emmc spec is written:
>
> Each time the host wants to access a partition the following flow shall be
> executed:
> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended
> CSD register in order to address one of the partitions
> 2. Issue commands referred to the selected partition
> 3. Restore default access to the User Data Area or re-direction the access
> to another partition
> All the reset events (CMD0 or hardware reset) will restore the access by
> default to the User Data Area.
>
> I'm feeling that partition_access bits should be preserved between
> reading data from boot0 and starting SPL. And these bits somehow could
> be used to determinate from which source bootrom loaded SPL. Maybe the
> last point ("all the reset events...") applies there and u-boot mmc
> driver does some reset in its init phase? And need to figure
> out how to read PARTITION_ACCESS without u-boot's mmc driver?
>

I enabled MMC tracing and added some printfs in mmc.c functions to see if
we can get a better idea of where best to read the value from:

<output>
BootROM - 1.73

Booting from MMC

U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28
+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
===mmc_start_init start===
===Getting ext_csd===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
===mmc_power_on===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
===mmc_select_mode===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
===mmc_mode2freq===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
===mmc_set_initial_state===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
CMD_SEND:0
ARG 0x00000000
MMC_RSP_NONE
CMD_SEND:8
ARG 0x000001aa
RET -110
CMD_SEND:55
ARG 0x00000000
RET -110
CMD_SEND:0
ARG 0x00000000
MMC_RSP_NONE
CMD_SEND:1
ARG 0x00000000
MMC_RSP_R3,4 0x40ff8080
CMD_SEND:1
ARG 0x40300080
MMC_RSP_R3,4 0x40ff8080
CMD_SEND:1
ARG 0x40300080
MMC_RSP_R3,4 0xc0ff8080
===mmc_start_init end===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
CMD_SEND:2
ARG 0x00000000
MMC_RSP_R2 0x15010038
          0x474d4534
          0x52010418
          0xfc4f7300

DUMPING DATA
000 - 15 01 00 38
004 - 47 4d 45 34
008 - 52 01 04 18
012 - fc 4f 73 00
CMD_SEND:3
ARG 0x00010000
MMC_RSP_R1,5,6,7 0x00000500
CMD_SEND:9
ARG 0x00010000
MMC_RSP_R2 0xd0270132
          0x0f5903ff
          0xf6dbffef
          0x8e404000

DUMPING DATA
000 - d0 27 01 32
004 - 0f 59 03 ff
008 - f6 db ff ef
012 - 8e 40 40 00
===mmc_select_mode===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
===mmc_mode2freq===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
CMD_SEND:7
ARG 0x00010000
MMC_RSP_R1,5,6,7 0x00000700
CMD_SEND:8
ARG 0x00000000
MMC_RSP_R1,5,6,7 0x00000900
===mmc_startup_v4===
===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
<snip>
</output>

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Wed, 22 Mar 2023 at 12:38, Martin Rowe <martin.p.rowe@gmail.com> wrote:
>
> On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:
>>
>> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
>> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
>> >
>> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
>> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
>> > > >
>> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
>> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
>> > > > > >
>> > > > > > > Could you try to print mmc->part_config (ideally as early as
>> > > possible)?
>> > > > > > >
>> > > > > >
>> > > > > > In SPL mmc->part_config is 255
>> > > > > > In main u-boot at the start of clearfog.c board_init()
>> > > mmc->part_config
>> > > > > is
>> > > > > > 255
>> > > > > > In main u-boot at the start of clearfog.c checkboard()
>> > > mmc->part_config
>> > > > > is
>> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
>> > > > >
>> > > > > 255 is uninitialized value.
>> > > > >
>> > > > > > If I set partition_enable to 2, I get the same result except the
>> > > value is
>> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
>> > > last
>> > > > > value
>> > > > >
>> > > > > Try to change "access" bits.
>> > > > >
>> > > > > > <partition_enable 1>
>> > > > > > BootROM - 1.73
>> > > > > >
>> > > > > > Booting from MMC
>> > > > > >
>> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
>> > > 10:05:32
>> > > > > > +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
>> > > > > > spl.c spl_boot_device part_config = 255
>> > > > > > Trying to boot from MMC1
>> > > > > >
>> > > > > >
>> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
>> > > +1000)
>> > > > > >
>> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
>> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
>> > > > > > clearfog.c board_init part_config = 255
>> > > > > > 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
>> > > > > > clearfog.c checkboard part_config = 8
>> > > > > > Board: SolidRun Clearfog Pro
>> > > > > > Net:
>> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
>> > > > > 32:16:0e:b4:d1:d8
>> > > > > > eth1: ethernet@70000
>> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
>> > > > > 72:30:3f:79:07:12
>> > > > > > , eth2: ethernet@30000
>> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
>> > > > > 82:fb:71:23:46:4f
>> > > > > > , eth3: ethernet@34000
>> > > > > > Hit any key to stop autoboot:  0
>> > > > > > => mmc partconf 0
>> > > > > > EXT_CSD[179], PARTITION_CONFIG:
>> > > > > > BOOT_ACK: 0x0
>> > > > > > BOOT_PARTITION_ENABLE: 0x1
>> > > > > > PARTITION_ACCESS: 0x0
>> > > > > > </partition_enable 1>
>> > > > > >
>> > > > > > <partition_enable 2>
>> > > > > > BootROM - 1.73
>> > > > > >
>> > > > > > Booting from MMC
>> > > > > >
>> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
>> > > 10:05:32
>> > > > > > +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
>> > > > > > spl.c spl_boot_device part_config = 255
>> > > > > > Trying to boot from MMC1
>> > > > > >
>> > > > > >
>> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
>> > > +1000)
>> > > > > >
>> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
>> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
>> > > > > > clearfog.c board_init part_config = 255
>> > > > > > 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
>> > > > > > clearfog.c checkboard part_config = 16
>> > > > > > Board: SolidRun Clearfog Pro
>> > > > > > Net:
>> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
>> > > > > 92:5a:fc:14:e8:f6
>> > > > > > eth1: ethernet@70000
>> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
>> > > > > 42:9c:d8:3a:cb:b2
>> > > > > > , eth2: ethernet@30000
>> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
>> > > > > c6:99:20:f4:02:a0
>> > > > > > , eth3: ethernet@34000
>> > > > > > Hit any key to stop autoboot:  0
>> > > > > > => mmc partconf 0
>> > > > > > EXT_CSD[179], PARTITION_CONFIG:
>> > > > > > BOOT_ACK: 0x0
>> > > > > > BOOT_PARTITION_ENABLE: 0x2
>> > > > > > PARTITION_ACCESS: 0x0
>> > > > > > </partition_enable 2>
>> > > > >
>> > > > > Are both logs from the configuration when SPL+u-boot is stored on
>> > > Boot0?
>> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
>> > > > > interested to see if "access" bits are changed in SPL (before loading
>> > > > > main u-boot).
>> > > > >
>> > > > > > I'm having trouble trying to find the hooks which run between
>> > > board_init
>> > > > > > and checkboard. If you can point me in the right direction I'm happy
>> > > to
>> > > > > > re-run and try to narrow down where the valid values are being set
>> > > from.
>> > > > >
>> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
>> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
>> > > > > I want to see original value from EXT_CSD_PART_CONF.
>> > > > >
>> > > > > I do not know which hook is the best, so printing it from mmc.c driver
>> > > > > should work better.
>> > > > >
>> > > >
>> > > > u-boot in boot0, partconf set to 0x1:
>> > > > mmc->part_config = 8
>> > > >
>> > > > u-boot in boot0, partconf set to 0x2:
>> > > > mmc->part_config = 16
>> > > >
>> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
>> > > > mmc->part_config = 8
>> > > >
>> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
>> > > > mmc->part_config = 16
>> > >
>> > > Ah, that does not look useful :-(
>> > >
>> > > Just to confirm, is this output from SPL or from main U-Boot?
>> > >
>> >
>> > Definitely SPL. I triple checked because I was also disappointed with those
>> > results. With BootROM hardcoded with its boot order it seems like neither
>> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
>> > mmc->part_config is going to work well.
>>
>> In emmc spec is written:
>>
>> Each time the host wants to access a partition the following flow shall be executed:
>> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
>> 2. Issue commands referred to the selected partition
>> 3. Restore default access to the User Data Area or re-direction the access to another partition
>> All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.
>>
>> I'm feeling that partition_access bits should be preserved between
>> reading data from boot0 and starting SPL. And these bits somehow could
>> be used to determinate from which source bootrom loaded SPL. Maybe the
>> last point ("all the reset events...") applies there and u-boot mmc
>> driver does some reset in its init phase? And need to figure
>> out how to read PARTITION_ACCESS without u-boot's mmc driver?
>
>
> I enabled MMC tracing and added some printfs in mmc.c functions to see if we can get a better idea of where best to read the value from:
>
> <output>
> BootROM - 1.73
>
> Booting from MMC
>
> U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28 +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
> ===mmc_start_init start===
> ===Getting ext_csd===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> ===mmc_power_on===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> ===mmc_select_mode===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> ===mmc_mode2freq===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> ===mmc_set_initial_state===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> CMD_SEND:0
> ARG 0x00000000
> MMC_RSP_NONE
> CMD_SEND:8
> ARG 0x000001aa
> RET -110
> CMD_SEND:55
> ARG 0x00000000
> RET -110
> CMD_SEND:0
> ARG 0x00000000
> MMC_RSP_NONE
> CMD_SEND:1
> ARG 0x00000000
> MMC_RSP_R3,4 0x40ff8080
> CMD_SEND:1
> ARG 0x40300080
> MMC_RSP_R3,4 0x40ff8080
> CMD_SEND:1
> ARG 0x40300080
> MMC_RSP_R3,4 0xc0ff8080
> ===mmc_start_init end===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> CMD_SEND:2
> ARG 0x00000000
> MMC_RSP_R2 0x15010038
>           0x474d4534
>           0x52010418
>           0xfc4f7300
>
> DUMPING DATA
> 000 - 15 01 00 38
> 004 - 47 4d 45 34
> 008 - 52 01 04 18
> 012 - fc 4f 73 00
> CMD_SEND:3
> ARG 0x00010000
> MMC_RSP_R1,5,6,7 0x00000500
> CMD_SEND:9
> ARG 0x00010000
> MMC_RSP_R2 0xd0270132
>           0x0f5903ff
>           0xf6dbffef
>           0x8e404000
>
> DUMPING DATA
> 000 - d0 27 01 32
> 004 - 0f 59 03 ff
> 008 - f6 db ff ef
> 012 - 8e 40 40 00
> ===mmc_select_mode===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> ===mmc_mode2freq===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> CMD_SEND:7
> ARG 0x00010000
> MMC_RSP_R1,5,6,7 0x00000700
> CMD_SEND:8
> ARG 0x00000000
> MMC_RSP_R1,5,6,7 0x00000900
> ===mmc_startup_v4===
> ===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
> <snip>
> </output>
>

You are correct Pali, it is preserved :)

The first time I can get the value is at the end of mmc_set_initial_state using:

static void mmc_set_initial_state(struct mmc *mmc)
{
   printf("+mmc_set_initial_state\n");
   int err;

   /* First try to set 3.3V. If it fails set to 1.8V */
   err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
   if (err != 0)
      err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
   if (err != 0)
      pr_warn("mmc: failed to set signal voltage\n");

   mmc_select_mode(mmc, MMC_LEGACY);
   mmc_set_bus_width(mmc, 1);
   mmc_set_clock(mmc, 0, MMC_CLK_ENABLE);
   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
   err = mmc_send_ext_csd(mmc, ext_csd);
   if (!err) {
      printf("++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] =
%d\n", ext_csd[EXT_CSD_PART_CONF]);
   }
}

I set mmc partconf 0 0 0 0, zeroed the first boot area and loaded
u-boot in the second. I had a few extra attempts to call
mmc_send_ext_csd in earlier functions that timeout and a lot of extra
printfs:

<output>
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-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 23:27:20 +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
+mmc_power_init
+mmc_power_cycle
+mmc_power_off
+mmc_power_on
CMD_SEND:8
        ARG             0x00000000
sdhci_send_command: Timeout for status update!
        RET             -110
+mmc_set_initial_state
+mmc_set_signal_voltage
+mmc_select_mode
+mmc_mode2freq
CMD_SEND:8
        ARG             0x00000000
sdhci_send_command: Timeout for status update!
        RET             -110
+mmc_set_bus_width
CMD_SEND:8
        ARG             0x00000000
sdhci_send_command: Timeout for status update!
        RET             -110
CMD_SEND:8
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 2
+mmc_go_idle
CMD_SEND:0
        ARG             0x00000000
        MMC_RSP_NONE
+mmc_send_if_cond
CMD_SEND:8
        ARG             0x000001aa
        RET             -110
+sd_send_op_cond
CMD_SEND:55
        ARG             0x00000000
        RET             -110
+mmc_send_op_cond
+mmc_go_idle
CMD_SEND:0
        ARG             0x00000000
        MMC_RSP_NONE
+mmc_send_op_cond_iter
CMD_SEND:1
        ARG             0x00000000
        MMC_RSP_R3,4         0x40ff8080
+mmc_send_op_cond_iter
CMD_SEND:1
        ARG             0x40300080
        MMC_RSP_R3,4         0x40ff8080
+mmc_send_op_cond_iter
CMD_SEND:1
        ARG             0x40300080
        MMC_RSP_R3,4         0xc0ff8080
+mmc_complete_init
CMD_SEND:8
        ARG             0x00000000
        RET             -110
+mmc_complete_op_cond
+mmc_startup
CMD_SEND:8
        ARG             0x00000000
        RET             -110
CMD_SEND:2
        ARG             0x00000000
        MMC_RSP_R2         0x15010038
                           0x474d4534
                           0x52010418
                           0xfc4f7300

                    DUMPING DATA
                    000 - 15 01 00 38
                    004 - 47 4d 45 34
                    008 - 52 01 04 18
                    012 - fc 4f 73 00
CMD_SEND:3
        ARG             0x00010000
        MMC_RSP_R1,5,6,7      0x00400500
CMD_SEND:9
        ARG             0x00010000
        MMC_RSP_R2         0xd0270132
                           0x0f5903ff
                           0xf6dbffef
                           0x8e404000

                    DUMPING DATA
                    000 - d0 27 01 32
                    004 - 0f 59 03 ff
                    008 - f6 db ff ef
                    012 - 8e 40 40 00
+mmc_select_mode
+mmc_mode2freq
CMD_SEND:8
        ARG             0x00000000
        RET             -110
CMD_SEND:7
        ARG             0x00010000
        MMC_RSP_R1,5,6,7      0x00000700
+mmc_startup_v4
CMD_SEND:8
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
+mmc_set_capacity
+mmc_get_capabilities
+mmc_select_mode_and_width
CMD_SEND:6
        ARG             0x03b70100
        MMC_RSP_R1b         0x00000900
CMD_SEND:13
        ARG             0x00010000
        MMC_RSP_R1,5,6,7      0x00000900
CURR STATE:4
+bus_width
+mmc_set_bus_width
CMD_SEND:8
        ARG             0x00000000
        RET             -70
CMD_SEND:6
        ARG             0x03b90100
        MMC_RSP_R1b         0x00000900
CMD_SEND:13
        ARG             0x00010000
        MMC_RSP_R1,5,6,7      0x00000900
CURR STATE:4
CMD_SEND:8
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
+mmc_select_mode
+mmc_mode2freq
CMD_SEND:8
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
++mmc_select_mode ext_csd[EXT_CSD_PART_CONF] = 0
+mmc_read_and_compare_ext_csd
CMD_SEND:8
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
CMD_SEND:8
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
++ext_csd[EXT_CSD_PART_CONF] = 0
CMD_SEND:16
        ARG             0x00000200
        MMC_RSP_R1,5,6,7      0x00000900
CMD_SEND:17
        ARG             0x00000000
        MMC_RSP_R1,5,6,7      0x00000900
CMD_SEND:16
        ARG             0x00000200
        MMC_RSP_R1,5,6,7      0x00000900
CMD_SEND:18
        ARG             0x000000de
        MMC_RSP_R1,5,6,7      0x00000900
CMD_SEND:12
        ARG             0x00000000
        MMC_RSP_R1b         0x00000b00


U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
clearfog.c board_init part_config = 247
Core:  38 devices, 22 uclasses, devicetree: separate
MMC:   mv_sdh: 0
Loading Environment from MMC... OK
Model: SolidRun Clearfog A1
clearfog.c checkboard part_config = 0
Board: SolidRun Clearfog Pro
Net:   eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000
Hit any key to stop autoboot:  0
</output>

When I set mmc partconf 0 0 2 2, I get:
++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 18

When I load u-boot to the first boot area with mmc partconf 0 0 2 2, I get:
++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 17

When I load u-boot to the first boot area with mmc partconf 0 0 0 0, I get:
++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 1

When I zero both boot areas and load u-boot to the data/user area with
mmc partconf 0 0 0 0, I get:
++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 0

I'm not sure where to take it from here, but I'm assuming we'll need
to stash that value somewhere so we can refer to it later.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote:
> On Wed, 22 Mar 2023 at 12:38, Martin Rowe <martin.p.rowe@gmail.com> wrote:
> >
> > On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:
> >>
> >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> >> >
> >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> >> > > >
> >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> >> > > > > >
> >> > > > > > > Could you try to print mmc->part_config (ideally as early as
> >> > > possible)?
> >> > > > > > >
> >> > > > > >
> >> > > > > > In SPL mmc->part_config is 255
> >> > > > > > In main u-boot at the start of clearfog.c board_init()
> >> > > mmc->part_config
> >> > > > > is
> >> > > > > > 255
> >> > > > > > In main u-boot at the start of clearfog.c checkboard()
> >> > > mmc->part_config
> >> > > > > is
> >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> >> > > > >
> >> > > > > 255 is uninitialized value.
> >> > > > >
> >> > > > > > If I set partition_enable to 2, I get the same result except the
> >> > > value is
> >> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> >> > > last
> >> > > > > value
> >> > > > >
> >> > > > > Try to change "access" bits.
> >> > > > >
> >> > > > > > <partition_enable 1>
> >> > > > > > BootROM - 1.73
> >> > > > > >
> >> > > > > > Booting from MMC
> >> > > > > >
> >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> >> > > 10:05:32
> >> > > > > > +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
> >> > > > > > spl.c spl_boot_device part_config = 255
> >> > > > > > Trying to boot from MMC1
> >> > > > > >
> >> > > > > >
> >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> >> > > +1000)
> >> > > > > >
> >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> >> > > > > > clearfog.c board_init part_config = 255
> >> > > > > > 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
> >> > > > > > clearfog.c checkboard part_config = 8
> >> > > > > > Board: SolidRun Clearfog Pro
> >> > > > > > Net:
> >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> >> > > > > 32:16:0e:b4:d1:d8
> >> > > > > > eth1: ethernet@70000
> >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> >> > > > > 72:30:3f:79:07:12
> >> > > > > > , eth2: ethernet@30000
> >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> >> > > > > 82:fb:71:23:46:4f
> >> > > > > > , eth3: ethernet@34000
> >> > > > > > Hit any key to stop autoboot:  0
> >> > > > > > => mmc partconf 0
> >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> >> > > > > > BOOT_ACK: 0x0
> >> > > > > > BOOT_PARTITION_ENABLE: 0x1
> >> > > > > > PARTITION_ACCESS: 0x0
> >> > > > > > </partition_enable 1>
> >> > > > > >
> >> > > > > > <partition_enable 2>
> >> > > > > > BootROM - 1.73
> >> > > > > >
> >> > > > > > Booting from MMC
> >> > > > > >
> >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> >> > > 10:05:32
> >> > > > > > +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
> >> > > > > > spl.c spl_boot_device part_config = 255
> >> > > > > > Trying to boot from MMC1
> >> > > > > >
> >> > > > > >
> >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> >> > > +1000)
> >> > > > > >
> >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> >> > > > > > clearfog.c board_init part_config = 255
> >> > > > > > 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
> >> > > > > > clearfog.c checkboard part_config = 16
> >> > > > > > Board: SolidRun Clearfog Pro
> >> > > > > > Net:
> >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> >> > > > > 92:5a:fc:14:e8:f6
> >> > > > > > eth1: ethernet@70000
> >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> >> > > > > 42:9c:d8:3a:cb:b2
> >> > > > > > , eth2: ethernet@30000
> >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> >> > > > > c6:99:20:f4:02:a0
> >> > > > > > , eth3: ethernet@34000
> >> > > > > > Hit any key to stop autoboot:  0
> >> > > > > > => mmc partconf 0
> >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> >> > > > > > BOOT_ACK: 0x0
> >> > > > > > BOOT_PARTITION_ENABLE: 0x2
> >> > > > > > PARTITION_ACCESS: 0x0
> >> > > > > > </partition_enable 2>
> >> > > > >
> >> > > > > Are both logs from the configuration when SPL+u-boot is stored on
> >> > > Boot0?
> >> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> >> > > > > interested to see if "access" bits are changed in SPL (before loading
> >> > > > > main u-boot).
> >> > > > >
> >> > > > > > I'm having trouble trying to find the hooks which run between
> >> > > board_init
> >> > > > > > and checkboard. If you can point me in the right direction I'm happy
> >> > > to
> >> > > > > > re-run and try to narrow down where the valid values are being set
> >> > > from.
> >> > > > >
> >> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> >> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> >> > > > > I want to see original value from EXT_CSD_PART_CONF.
> >> > > > >
> >> > > > > I do not know which hook is the best, so printing it from mmc.c driver
> >> > > > > should work better.
> >> > > > >
> >> > > >
> >> > > > u-boot in boot0, partconf set to 0x1:
> >> > > > mmc->part_config = 8
> >> > > >
> >> > > > u-boot in boot0, partconf set to 0x2:
> >> > > > mmc->part_config = 16
> >> > > >
> >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> >> > > > mmc->part_config = 8
> >> > > >
> >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> >> > > > mmc->part_config = 16
> >> > >
> >> > > Ah, that does not look useful :-(
> >> > >
> >> > > Just to confirm, is this output from SPL or from main U-Boot?
> >> > >
> >> >
> >> > Definitely SPL. I triple checked because I was also disappointed with those
> >> > results. With BootROM hardcoded with its boot order it seems like neither
> >> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> >> > mmc->part_config is going to work well.
> >>
> >> In emmc spec is written:
> >>
> >> Each time the host wants to access a partition the following flow shall be executed:
> >> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
> >> 2. Issue commands referred to the selected partition
> >> 3. Restore default access to the User Data Area or re-direction the access to another partition
> >> All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.
> >>
> >> I'm feeling that partition_access bits should be preserved between
> >> reading data from boot0 and starting SPL. And these bits somehow could
> >> be used to determinate from which source bootrom loaded SPL. Maybe the
> >> last point ("all the reset events...") applies there and u-boot mmc
> >> driver does some reset in its init phase? And need to figure
> >> out how to read PARTITION_ACCESS without u-boot's mmc driver?
> >
> >
> > I enabled MMC tracing and added some printfs in mmc.c functions to see if we can get a better idea of where best to read the value from:
> >
> > <output>
> > BootROM - 1.73
> >
> > Booting from MMC
> >
> > U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28 +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
> > ===mmc_start_init start===
> > ===Getting ext_csd===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > ===mmc_power_on===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > ===mmc_select_mode===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > ===mmc_mode2freq===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > ===mmc_set_initial_state===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > CMD_SEND:0
> > ARG 0x00000000
> > MMC_RSP_NONE
> > CMD_SEND:8
> > ARG 0x000001aa
> > RET -110
> > CMD_SEND:55
> > ARG 0x00000000
> > RET -110
> > CMD_SEND:0
> > ARG 0x00000000
> > MMC_RSP_NONE
> > CMD_SEND:1
> > ARG 0x00000000
> > MMC_RSP_R3,4 0x40ff8080
> > CMD_SEND:1
> > ARG 0x40300080
> > MMC_RSP_R3,4 0x40ff8080
> > CMD_SEND:1
> > ARG 0x40300080
> > MMC_RSP_R3,4 0xc0ff8080
> > ===mmc_start_init end===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > CMD_SEND:2
> > ARG 0x00000000
> > MMC_RSP_R2 0x15010038
> >           0x474d4534
> >           0x52010418
> >           0xfc4f7300
> >
> > DUMPING DATA
> > 000 - 15 01 00 38
> > 004 - 47 4d 45 34
> > 008 - 52 01 04 18
> > 012 - fc 4f 73 00
> > CMD_SEND:3
> > ARG 0x00010000
> > MMC_RSP_R1,5,6,7 0x00000500
> > CMD_SEND:9
> > ARG 0x00010000
> > MMC_RSP_R2 0xd0270132
> >           0x0f5903ff
> >           0xf6dbffef
> >           0x8e404000
> >
> > DUMPING DATA
> > 000 - d0 27 01 32
> > 004 - 0f 59 03 ff
> > 008 - f6 db ff ef
> > 012 - 8e 40 40 00
> > ===mmc_select_mode===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > ===mmc_mode2freq===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > CMD_SEND:7
> > ARG 0x00010000
> > MMC_RSP_R1,5,6,7 0x00000700
> > CMD_SEND:8
> > ARG 0x00000000
> > MMC_RSP_R1,5,6,7 0x00000900
> > ===mmc_startup_v4===
> > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
> > <snip>
> > </output>
> >
> 
> You are correct Pali, it is preserved :)

Perfect!

> The first time I can get the value is at the end of mmc_set_initial_state using:
> 
> static void mmc_set_initial_state(struct mmc *mmc)
> {
>    printf("+mmc_set_initial_state\n");
>    int err;
> 
>    /* First try to set 3.3V. If it fails set to 1.8V */
>    err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
>    if (err != 0)
>       err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
>    if (err != 0)
>       pr_warn("mmc: failed to set signal voltage\n");
> 
>    mmc_select_mode(mmc, MMC_LEGACY);
>    mmc_set_bus_width(mmc, 1);
>    mmc_set_clock(mmc, 0, MMC_CLK_ENABLE);
>    ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
>    err = mmc_send_ext_csd(mmc, ext_csd);
>    if (!err) {
>       printf("++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] =
> %d\n", ext_csd[EXT_CSD_PART_CONF]);
>    }
> }

And seems you found the correct function because after
mmc_set_initial_state() in mmc_get_op_cond() is code:

	/* Reset the Card */
	err = mmc_go_idle(mmc);

And in emmc spec is written:
"All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area."

So we really need to read EXT_CSD_PART_CONF before that reset.

> I set mmc partconf 0 0 0 0, zeroed the first boot area and loaded
> u-boot in the second. I had a few extra attempts to call
> mmc_send_ext_csd in earlier functions that timeout and a lot of extra
> printfs:
> 
> <output>
> 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-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 23:27:20 +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
> +mmc_power_init
> +mmc_power_cycle
> +mmc_power_off
> +mmc_power_on
> CMD_SEND:8
>         ARG             0x00000000
> sdhci_send_command: Timeout for status update!
>         RET             -110
> +mmc_set_initial_state
> +mmc_set_signal_voltage
> +mmc_select_mode
> +mmc_mode2freq
> CMD_SEND:8
>         ARG             0x00000000
> sdhci_send_command: Timeout for status update!
>         RET             -110
> +mmc_set_bus_width
> CMD_SEND:8
>         ARG             0x00000000
> sdhci_send_command: Timeout for status update!
>         RET             -110
> CMD_SEND:8
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 2

Access is set to second boot partition which matches the boot source in
BootROM.

> +mmc_go_idle
> CMD_SEND:0
>         ARG             0x00000000
>         MMC_RSP_NONE
> +mmc_send_if_cond
> CMD_SEND:8
>         ARG             0x000001aa
>         RET             -110
> +sd_send_op_cond
> CMD_SEND:55
>         ARG             0x00000000
>         RET             -110
> +mmc_send_op_cond
> +mmc_go_idle
> CMD_SEND:0
>         ARG             0x00000000
>         MMC_RSP_NONE
> +mmc_send_op_cond_iter
> CMD_SEND:1
>         ARG             0x00000000
>         MMC_RSP_R3,4         0x40ff8080
> +mmc_send_op_cond_iter
> CMD_SEND:1
>         ARG             0x40300080
>         MMC_RSP_R3,4         0x40ff8080
> +mmc_send_op_cond_iter
> CMD_SEND:1
>         ARG             0x40300080
>         MMC_RSP_R3,4         0xc0ff8080
> +mmc_complete_init
> CMD_SEND:8
>         ARG             0x00000000
>         RET             -110
> +mmc_complete_op_cond
> +mmc_startup
> CMD_SEND:8
>         ARG             0x00000000
>         RET             -110
> CMD_SEND:2
>         ARG             0x00000000
>         MMC_RSP_R2         0x15010038
>                            0x474d4534
>                            0x52010418
>                            0xfc4f7300
> 
>                     DUMPING DATA
>                     000 - 15 01 00 38
>                     004 - 47 4d 45 34
>                     008 - 52 01 04 18
>                     012 - fc 4f 73 00
> CMD_SEND:3
>         ARG             0x00010000
>         MMC_RSP_R1,5,6,7      0x00400500
> CMD_SEND:9
>         ARG             0x00010000
>         MMC_RSP_R2         0xd0270132
>                            0x0f5903ff
>                            0xf6dbffef
>                            0x8e404000
> 
>                     DUMPING DATA
>                     000 - d0 27 01 32
>                     004 - 0f 59 03 ff
>                     008 - f6 db ff ef
>                     012 - 8e 40 40 00
> +mmc_select_mode
> +mmc_mode2freq
> CMD_SEND:8
>         ARG             0x00000000
>         RET             -110
> CMD_SEND:7
>         ARG             0x00010000
>         MMC_RSP_R1,5,6,7      0x00000700
> +mmc_startup_v4
> CMD_SEND:8
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> +mmc_set_capacity
> +mmc_get_capabilities
> +mmc_select_mode_and_width
> CMD_SEND:6
>         ARG             0x03b70100
>         MMC_RSP_R1b         0x00000900
> CMD_SEND:13
>         ARG             0x00010000
>         MMC_RSP_R1,5,6,7      0x00000900
> CURR STATE:4
> +bus_width
> +mmc_set_bus_width
> CMD_SEND:8
>         ARG             0x00000000
>         RET             -70
> CMD_SEND:6
>         ARG             0x03b90100
>         MMC_RSP_R1b         0x00000900
> CMD_SEND:13
>         ARG             0x00010000
>         MMC_RSP_R1,5,6,7      0x00000900
> CURR STATE:4
> CMD_SEND:8
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> +mmc_select_mode
> +mmc_mode2freq
> CMD_SEND:8
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> ++mmc_select_mode ext_csd[EXT_CSD_PART_CONF] = 0
> +mmc_read_and_compare_ext_csd
> CMD_SEND:8
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> CMD_SEND:8
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> ++ext_csd[EXT_CSD_PART_CONF] = 0
> CMD_SEND:16
>         ARG             0x00000200
>         MMC_RSP_R1,5,6,7      0x00000900
> CMD_SEND:17
>         ARG             0x00000000
>         MMC_RSP_R1,5,6,7      0x00000900
> CMD_SEND:16
>         ARG             0x00000200
>         MMC_RSP_R1,5,6,7      0x00000900
> CMD_SEND:18
>         ARG             0x000000de
>         MMC_RSP_R1,5,6,7      0x00000900
> CMD_SEND:12
>         ARG             0x00000000
>         MMC_RSP_R1b         0x00000b00
> 
> 
> U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> 
> SoC:   MV88F6828-A0 at 1600 MHz
> DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> clearfog.c board_init part_config = 247
> Core:  38 devices, 22 uclasses, devicetree: separate
> MMC:   mv_sdh: 0
> Loading Environment from MMC... OK
> Model: SolidRun Clearfog A1
> clearfog.c checkboard part_config = 0
> Board: SolidRun Clearfog Pro
> Net:   eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000
> Hit any key to stop autoboot:  0
> </output>
> 
> When I set mmc partconf 0 0 2 2, I get:
> ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 18

Access is second boot partition which matches your setup.

> When I load u-boot to the first boot area with mmc partconf 0 0 2 2, I get:
> ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 17

Also matches as access is to first boot partition.

> When I load u-boot to the first boot area with mmc partconf 0 0 0 0, I get:
> ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 1

And this also matches as access is also to first boot partition.

> When I zero both boot areas and load u-boot to the data/user area with
> mmc partconf 0 0 0 0, I get:
> ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 0

And this access is to user area.

> I'm not sure where to take it from here, but I'm assuming we'll need
> to stash that value somewhere so we can refer to it later.

In my opinion we need to read access bits of EXT_CSD_PART_CONF before
that mmc_go_idle() which resets the card, and store them to
mmc->part_config. Then in mmc_startup_v4() ensures that we do not
overwrite access bits of mmc->part_config as we know that at this stage
access bits in EXT_CSD_PART_CONF are already reset.

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote:
> On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote:
> > On Wed, 22 Mar 2023 at 12:38, Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > >
> > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:
> > >>
> > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> > >> >
> > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> > >> > > >
> > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > >> > > > > >
> > >> > > > > > > Could you try to print mmc->part_config (ideally as early as
> > >> > > possible)?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > In SPL mmc->part_config is 255
> > >> > > > > > In main u-boot at the start of clearfog.c board_init()
> > >> > > mmc->part_config
> > >> > > > > is
> > >> > > > > > 255
> > >> > > > > > In main u-boot at the start of clearfog.c checkboard()
> > >> > > mmc->part_config
> > >> > > > > is
> > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > >> > > > >
> > >> > > > > 255 is uninitialized value.
> > >> > > > >
> > >> > > > > > If I set partition_enable to 2, I get the same result except the
> > >> > > value is
> > >> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> > >> > > last
> > >> > > > > value
> > >> > > > >
> > >> > > > > Try to change "access" bits.
> > >> > > > >
> > >> > > > > > <partition_enable 1>
> > >> > > > > > BootROM - 1.73
> > >> > > > > >
> > >> > > > > > Booting from MMC
> > >> > > > > >
> > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > >> > > 10:05:32
> > >> > > > > > +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
> > >> > > > > > spl.c spl_boot_device part_config = 255
> > >> > > > > > Trying to boot from MMC1
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > >> > > +1000)
> > >> > > > > >
> > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > >> > > > > > clearfog.c board_init part_config = 255
> > >> > > > > > 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
> > >> > > > > > clearfog.c checkboard part_config = 8
> > >> > > > > > Board: SolidRun Clearfog Pro
> > >> > > > > > Net:
> > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > >> > > > > 32:16:0e:b4:d1:d8
> > >> > > > > > eth1: ethernet@70000
> > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > >> > > > > 72:30:3f:79:07:12
> > >> > > > > > , eth2: ethernet@30000
> > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > >> > > > > 82:fb:71:23:46:4f
> > >> > > > > > , eth3: ethernet@34000
> > >> > > > > > Hit any key to stop autoboot:  0
> > >> > > > > > => mmc partconf 0
> > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > >> > > > > > BOOT_ACK: 0x0
> > >> > > > > > BOOT_PARTITION_ENABLE: 0x1
> > >> > > > > > PARTITION_ACCESS: 0x0
> > >> > > > > > </partition_enable 1>
> > >> > > > > >
> > >> > > > > > <partition_enable 2>
> > >> > > > > > BootROM - 1.73
> > >> > > > > >
> > >> > > > > > Booting from MMC
> > >> > > > > >
> > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > >> > > 10:05:32
> > >> > > > > > +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
> > >> > > > > > spl.c spl_boot_device part_config = 255
> > >> > > > > > Trying to boot from MMC1
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > >> > > +1000)
> > >> > > > > >
> > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > >> > > > > > clearfog.c board_init part_config = 255
> > >> > > > > > 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
> > >> > > > > > clearfog.c checkboard part_config = 16
> > >> > > > > > Board: SolidRun Clearfog Pro
> > >> > > > > > Net:
> > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > >> > > > > 92:5a:fc:14:e8:f6
> > >> > > > > > eth1: ethernet@70000
> > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > >> > > > > 42:9c:d8:3a:cb:b2
> > >> > > > > > , eth2: ethernet@30000
> > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > >> > > > > c6:99:20:f4:02:a0
> > >> > > > > > , eth3: ethernet@34000
> > >> > > > > > Hit any key to stop autoboot:  0
> > >> > > > > > => mmc partconf 0
> > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > >> > > > > > BOOT_ACK: 0x0
> > >> > > > > > BOOT_PARTITION_ENABLE: 0x2
> > >> > > > > > PARTITION_ACCESS: 0x0
> > >> > > > > > </partition_enable 2>
> > >> > > > >
> > >> > > > > Are both logs from the configuration when SPL+u-boot is stored on
> > >> > > Boot0?
> > >> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > >> > > > > interested to see if "access" bits are changed in SPL (before loading
> > >> > > > > main u-boot).
> > >> > > > >
> > >> > > > > > I'm having trouble trying to find the hooks which run between
> > >> > > board_init
> > >> > > > > > and checkboard. If you can point me in the right direction I'm happy
> > >> > > to
> > >> > > > > > re-run and try to narrow down where the valid values are being set
> > >> > > from.
> > >> > > > >
> > >> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > >> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > >> > > > > I want to see original value from EXT_CSD_PART_CONF.
> > >> > > > >
> > >> > > > > I do not know which hook is the best, so printing it from mmc.c driver
> > >> > > > > should work better.
> > >> > > > >
> > >> > > >
> > >> > > > u-boot in boot0, partconf set to 0x1:
> > >> > > > mmc->part_config = 8
> > >> > > >
> > >> > > > u-boot in boot0, partconf set to 0x2:
> > >> > > > mmc->part_config = 16
> > >> > > >
> > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > >> > > > mmc->part_config = 8
> > >> > > >
> > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > >> > > > mmc->part_config = 16
> > >> > >
> > >> > > Ah, that does not look useful :-(
> > >> > >
> > >> > > Just to confirm, is this output from SPL or from main U-Boot?
> > >> > >
> > >> >
> > >> > Definitely SPL. I triple checked because I was also disappointed with those
> > >> > results. With BootROM hardcoded with its boot order it seems like neither
> > >> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> > >> > mmc->part_config is going to work well.
> > >>
> > >> In emmc spec is written:
> > >>
> > >> Each time the host wants to access a partition the following flow shall be executed:
> > >> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
> > >> 2. Issue commands referred to the selected partition
> > >> 3. Restore default access to the User Data Area or re-direction the access to another partition
> > >> All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.
> > >>
> > >> I'm feeling that partition_access bits should be preserved between
> > >> reading data from boot0 and starting SPL. And these bits somehow could
> > >> be used to determinate from which source bootrom loaded SPL. Maybe the
> > >> last point ("all the reset events...") applies there and u-boot mmc
> > >> driver does some reset in its init phase? And need to figure
> > >> out how to read PARTITION_ACCESS without u-boot's mmc driver?
> > >
> > >
> > > I enabled MMC tracing and added some printfs in mmc.c functions to see if we can get a better idea of where best to read the value from:
> > >
> > > <output>
> > > BootROM - 1.73
> > >
> > > Booting from MMC
> > >
> > > U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28 +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
> > > ===mmc_start_init start===
> > > ===Getting ext_csd===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > ===mmc_power_on===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > ===mmc_select_mode===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > ===mmc_mode2freq===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > ===mmc_set_initial_state===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > CMD_SEND:0
> > > ARG 0x00000000
> > > MMC_RSP_NONE
> > > CMD_SEND:8
> > > ARG 0x000001aa
> > > RET -110
> > > CMD_SEND:55
> > > ARG 0x00000000
> > > RET -110
> > > CMD_SEND:0
> > > ARG 0x00000000
> > > MMC_RSP_NONE
> > > CMD_SEND:1
> > > ARG 0x00000000
> > > MMC_RSP_R3,4 0x40ff8080
> > > CMD_SEND:1
> > > ARG 0x40300080
> > > MMC_RSP_R3,4 0x40ff8080
> > > CMD_SEND:1
> > > ARG 0x40300080
> > > MMC_RSP_R3,4 0xc0ff8080
> > > ===mmc_start_init end===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > CMD_SEND:2
> > > ARG 0x00000000
> > > MMC_RSP_R2 0x15010038
> > >           0x474d4534
> > >           0x52010418
> > >           0xfc4f7300
> > >
> > > DUMPING DATA
> > > 000 - 15 01 00 38
> > > 004 - 47 4d 45 34
> > > 008 - 52 01 04 18
> > > 012 - fc 4f 73 00
> > > CMD_SEND:3
> > > ARG 0x00010000
> > > MMC_RSP_R1,5,6,7 0x00000500
> > > CMD_SEND:9
> > > ARG 0x00010000
> > > MMC_RSP_R2 0xd0270132
> > >           0x0f5903ff
> > >           0xf6dbffef
> > >           0x8e404000
> > >
> > > DUMPING DATA
> > > 000 - d0 27 01 32
> > > 004 - 0f 59 03 ff
> > > 008 - f6 db ff ef
> > > 012 - 8e 40 40 00
> > > ===mmc_select_mode===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > ===mmc_mode2freq===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > CMD_SEND:7
> > > ARG 0x00010000
> > > MMC_RSP_R1,5,6,7 0x00000700
> > > CMD_SEND:8
> > > ARG 0x00000000
> > > MMC_RSP_R1,5,6,7 0x00000900
> > > ===mmc_startup_v4===
> > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
> > > <snip>
> > > </output>
> > >
> > 
> > You are correct Pali, it is preserved :)
> 
> Perfect!
> 
> > The first time I can get the value is at the end of mmc_set_initial_state using:
> > 
> > static void mmc_set_initial_state(struct mmc *mmc)
> > {
> >    printf("+mmc_set_initial_state\n");
> >    int err;
> > 
> >    /* First try to set 3.3V. If it fails set to 1.8V */
> >    err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
> >    if (err != 0)
> >       err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> >    if (err != 0)
> >       pr_warn("mmc: failed to set signal voltage\n");
> > 
> >    mmc_select_mode(mmc, MMC_LEGACY);
> >    mmc_set_bus_width(mmc, 1);
> >    mmc_set_clock(mmc, 0, MMC_CLK_ENABLE);
> >    ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> >    err = mmc_send_ext_csd(mmc, ext_csd);
> >    if (!err) {
> >       printf("++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] =
> > %d\n", ext_csd[EXT_CSD_PART_CONF]);
> >    }
> > }
> 
> And seems you found the correct function because after
> mmc_set_initial_state() in mmc_get_op_cond() is code:
> 
> 	/* Reset the Card */
> 	err = mmc_go_idle(mmc);
> 
> And in emmc spec is written:
> "All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area."
> 
> So we really need to read EXT_CSD_PART_CONF before that reset.
> 
> > I set mmc partconf 0 0 0 0, zeroed the first boot area and loaded
> > u-boot in the second. I had a few extra attempts to call
> > mmc_send_ext_csd in earlier functions that timeout and a lot of extra
> > printfs:
> > 
> > <output>
> > 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-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 23:27:20 +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
> > +mmc_power_init
> > +mmc_power_cycle
> > +mmc_power_off
> > +mmc_power_on
> > CMD_SEND:8
> >         ARG             0x00000000
> > sdhci_send_command: Timeout for status update!
> >         RET             -110
> > +mmc_set_initial_state
> > +mmc_set_signal_voltage
> > +mmc_select_mode
> > +mmc_mode2freq
> > CMD_SEND:8
> >         ARG             0x00000000
> > sdhci_send_command: Timeout for status update!
> >         RET             -110
> > +mmc_set_bus_width
> > CMD_SEND:8
> >         ARG             0x00000000
> > sdhci_send_command: Timeout for status update!
> >         RET             -110
> > CMD_SEND:8
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 2
> 
> Access is set to second boot partition which matches the boot source in
> BootROM.
> 
> > +mmc_go_idle
> > CMD_SEND:0
> >         ARG             0x00000000
> >         MMC_RSP_NONE
> > +mmc_send_if_cond
> > CMD_SEND:8
> >         ARG             0x000001aa
> >         RET             -110
> > +sd_send_op_cond
> > CMD_SEND:55
> >         ARG             0x00000000
> >         RET             -110
> > +mmc_send_op_cond
> > +mmc_go_idle
> > CMD_SEND:0
> >         ARG             0x00000000
> >         MMC_RSP_NONE
> > +mmc_send_op_cond_iter
> > CMD_SEND:1
> >         ARG             0x00000000
> >         MMC_RSP_R3,4         0x40ff8080
> > +mmc_send_op_cond_iter
> > CMD_SEND:1
> >         ARG             0x40300080
> >         MMC_RSP_R3,4         0x40ff8080
> > +mmc_send_op_cond_iter
> > CMD_SEND:1
> >         ARG             0x40300080
> >         MMC_RSP_R3,4         0xc0ff8080
> > +mmc_complete_init
> > CMD_SEND:8
> >         ARG             0x00000000
> >         RET             -110
> > +mmc_complete_op_cond
> > +mmc_startup
> > CMD_SEND:8
> >         ARG             0x00000000
> >         RET             -110
> > CMD_SEND:2
> >         ARG             0x00000000
> >         MMC_RSP_R2         0x15010038
> >                            0x474d4534
> >                            0x52010418
> >                            0xfc4f7300
> > 
> >                     DUMPING DATA
> >                     000 - 15 01 00 38
> >                     004 - 47 4d 45 34
> >                     008 - 52 01 04 18
> >                     012 - fc 4f 73 00
> > CMD_SEND:3
> >         ARG             0x00010000
> >         MMC_RSP_R1,5,6,7      0x00400500
> > CMD_SEND:9
> >         ARG             0x00010000
> >         MMC_RSP_R2         0xd0270132
> >                            0x0f5903ff
> >                            0xf6dbffef
> >                            0x8e404000
> > 
> >                     DUMPING DATA
> >                     000 - d0 27 01 32
> >                     004 - 0f 59 03 ff
> >                     008 - f6 db ff ef
> >                     012 - 8e 40 40 00
> > +mmc_select_mode
> > +mmc_mode2freq
> > CMD_SEND:8
> >         ARG             0x00000000
> >         RET             -110
> > CMD_SEND:7
> >         ARG             0x00010000
> >         MMC_RSP_R1,5,6,7      0x00000700
> > +mmc_startup_v4
> > CMD_SEND:8
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > +mmc_set_capacity
> > +mmc_get_capabilities
> > +mmc_select_mode_and_width
> > CMD_SEND:6
> >         ARG             0x03b70100
> >         MMC_RSP_R1b         0x00000900
> > CMD_SEND:13
> >         ARG             0x00010000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CURR STATE:4
> > +bus_width
> > +mmc_set_bus_width
> > CMD_SEND:8
> >         ARG             0x00000000
> >         RET             -70
> > CMD_SEND:6
> >         ARG             0x03b90100
> >         MMC_RSP_R1b         0x00000900
> > CMD_SEND:13
> >         ARG             0x00010000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CURR STATE:4
> > CMD_SEND:8
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > +mmc_select_mode
> > +mmc_mode2freq
> > CMD_SEND:8
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > ++mmc_select_mode ext_csd[EXT_CSD_PART_CONF] = 0
> > +mmc_read_and_compare_ext_csd
> > CMD_SEND:8
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CMD_SEND:8
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > ++ext_csd[EXT_CSD_PART_CONF] = 0
> > CMD_SEND:16
> >         ARG             0x00000200
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CMD_SEND:17
> >         ARG             0x00000000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CMD_SEND:16
> >         ARG             0x00000200
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CMD_SEND:18
> >         ARG             0x000000de
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CMD_SEND:12
> >         ARG             0x00000000
> >         MMC_RSP_R1b         0x00000b00
> > 
> > 
> > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> > 
> > SoC:   MV88F6828-A0 at 1600 MHz
> > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > clearfog.c board_init part_config = 247
> > Core:  38 devices, 22 uclasses, devicetree: separate
> > MMC:   mv_sdh: 0
> > Loading Environment from MMC... OK
> > Model: SolidRun Clearfog A1
> > clearfog.c checkboard part_config = 0
> > Board: SolidRun Clearfog Pro
> > Net:   eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000
> > Hit any key to stop autoboot:  0
> > </output>
> > 
> > When I set mmc partconf 0 0 2 2, I get:
> > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 18
> 
> Access is second boot partition which matches your setup.
> 
> > When I load u-boot to the first boot area with mmc partconf 0 0 2 2, I get:
> > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 17
> 
> Also matches as access is to first boot partition.
> 
> > When I load u-boot to the first boot area with mmc partconf 0 0 0 0, I get:
> > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 1
> 
> And this also matches as access is also to first boot partition.
> 
> > When I zero both boot areas and load u-boot to the data/user area with
> > mmc partconf 0 0 0 0, I get:
> > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 0
> 
> And this access is to user area.
> 
> > I'm not sure where to take it from here, but I'm assuming we'll need
> > to stash that value somewhere so we can refer to it later.
> 
> In my opinion we need to read access bits of EXT_CSD_PART_CONF before
> that mmc_go_idle() which resets the card, and store them to
> mmc->part_config. Then in mmc_startup_v4() ensures that we do not
> overwrite access bits of mmc->part_config as we know that at this stage
> access bits in EXT_CSD_PART_CONF are already reset.

What about this change?

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 210703ea46b3..0c9c1a43b43b 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2329,8 +2329,13 @@ static int mmc_startup_v4(struct mmc *mmc)
 	/* store the partition info of emmc */
 	mmc->part_support = ext_csd[EXT_CSD_PARTITIONING_SUPPORT];
 	if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
-	    ext_csd[EXT_CSD_BOOT_MULT])
-		mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
+	    ext_csd[EXT_CSD_BOOT_MULT]) {
+		if (mmc->part_config == MMCPART_NOAVAILABLE)
+			mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
+		else
+			mmc->part_config = (ext_csd[EXT_CSD_PART_CONF] & ~PART_ACCESS_MASK) |
+					   (mmc->part_config & PART_ACCESS_MASK);
+	}
 	if (part_completed &&
 	    (ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & ENHNCD_SUPPORT))
 		mmc->part_attr = ext_csd[EXT_CSD_PARTITIONS_ATTRIBUTE];
@@ -2600,7 +2605,6 @@ static int mmc_startup(struct mmc *mmc)
 #if CONFIG_IS_ENABLED(MMC_WRITE)
 	mmc->erase_grp_size = 1;
 #endif
-	mmc->part_config = MMCPART_NOAVAILABLE;
 
 	err = mmc_startup_v4(mmc);
 	if (err)
@@ -2848,9 +2852,21 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet)
 		return err;
 	mmc->ddr_mode = 0;
 
+	mmc->part_config = MMCPART_NOAVAILABLE;
+
 retry:
 	mmc_set_initial_state(mmc);
 
+	if (mmc->part_config == MMCPART_NOAVAILABLE &&
+	    !IS_SD(mmc) && mmc->version >= MMC_VERSION_4) {
+		ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+		err = mmc_send_ext_csd(mmc, ext_csd);
+		if (err == 0 &&
+		    ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
+		     ext_csd[EXT_CSD_BOOT_MULT]))
+			mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK;
+	}
+
 	/* Reset the Card */
 	err = mmc_go_idle(mmc);
 

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Wed, 22 Mar 2023 at 19:09, Pali Rohár <pali@kernel.org> wrote:
>
> On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote:
> > On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote:
> > > On Wed, 22 Mar 2023 at 12:38, Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > > >
> > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:
> > > >>
> > > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> > > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> > > >> >
> > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> > > >> > > >
> > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > > >> > > > > >
> > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as
> > > >> > > possible)?
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > In SPL mmc->part_config is 255
> > > >> > > > > > In main u-boot at the start of clearfog.c board_init()
> > > >> > > mmc->part_config
> > > >> > > > > is
> > > >> > > > > > 255
> > > >> > > > > > In main u-boot at the start of clearfog.c checkboard()
> > > >> > > mmc->part_config
> > > >> > > > > is
> > > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > > >> > > > >
> > > >> > > > > 255 is uninitialized value.
> > > >> > > > >
> > > >> > > > > > If I set partition_enable to 2, I get the same result except the
> > > >> > > value is
> > > >> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> > > >> > > last
> > > >> > > > > value
> > > >> > > > >
> > > >> > > > > Try to change "access" bits.
> > > >> > > > >
> > > >> > > > > > <partition_enable 1>
> > > >> > > > > > BootROM - 1.73
> > > >> > > > > >
> > > >> > > > > > Booting from MMC
> > > >> > > > > >
> > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > >> > > 10:05:32
> > > >> > > > > > +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
> > > >> > > > > > spl.c spl_boot_device part_config = 255
> > > >> > > > > > Trying to boot from MMC1
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > >> > > +1000)
> > > >> > > > > >
> > > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > >> > > > > > clearfog.c board_init part_config = 255
> > > >> > > > > > 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
> > > >> > > > > > clearfog.c checkboard part_config = 8
> > > >> > > > > > Board: SolidRun Clearfog Pro
> > > >> > > > > > Net:
> > > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > >> > > > > 32:16:0e:b4:d1:d8
> > > >> > > > > > eth1: ethernet@70000
> > > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > >> > > > > 72:30:3f:79:07:12
> > > >> > > > > > , eth2: ethernet@30000
> > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > >> > > > > 82:fb:71:23:46:4f
> > > >> > > > > > , eth3: ethernet@34000
> > > >> > > > > > Hit any key to stop autoboot:  0
> > > >> > > > > > => mmc partconf 0
> > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > >> > > > > > BOOT_ACK: 0x0
> > > >> > > > > > BOOT_PARTITION_ENABLE: 0x1
> > > >> > > > > > PARTITION_ACCESS: 0x0
> > > >> > > > > > </partition_enable 1>
> > > >> > > > > >
> > > >> > > > > > <partition_enable 2>
> > > >> > > > > > BootROM - 1.73
> > > >> > > > > >
> > > >> > > > > > Booting from MMC
> > > >> > > > > >
> > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > >> > > 10:05:32
> > > >> > > > > > +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
> > > >> > > > > > spl.c spl_boot_device part_config = 255
> > > >> > > > > > Trying to boot from MMC1
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > >> > > +1000)
> > > >> > > > > >
> > > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > >> > > > > > clearfog.c board_init part_config = 255
> > > >> > > > > > 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
> > > >> > > > > > clearfog.c checkboard part_config = 16
> > > >> > > > > > Board: SolidRun Clearfog Pro
> > > >> > > > > > Net:
> > > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > >> > > > > 92:5a:fc:14:e8:f6
> > > >> > > > > > eth1: ethernet@70000
> > > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > >> > > > > 42:9c:d8:3a:cb:b2
> > > >> > > > > > , eth2: ethernet@30000
> > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > >> > > > > c6:99:20:f4:02:a0
> > > >> > > > > > , eth3: ethernet@34000
> > > >> > > > > > Hit any key to stop autoboot:  0
> > > >> > > > > > => mmc partconf 0
> > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > >> > > > > > BOOT_ACK: 0x0
> > > >> > > > > > BOOT_PARTITION_ENABLE: 0x2
> > > >> > > > > > PARTITION_ACCESS: 0x0
> > > >> > > > > > </partition_enable 2>
> > > >> > > > >
> > > >> > > > > Are both logs from the configuration when SPL+u-boot is stored on
> > > >> > > Boot0?
> > > >> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > > >> > > > > interested to see if "access" bits are changed in SPL (before loading
> > > >> > > > > main u-boot).
> > > >> > > > >
> > > >> > > > > > I'm having trouble trying to find the hooks which run between
> > > >> > > board_init
> > > >> > > > > > and checkboard. If you can point me in the right direction I'm happy
> > > >> > > to
> > > >> > > > > > re-run and try to narrow down where the valid values are being set
> > > >> > > from.
> > > >> > > > >
> > > >> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > > >> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > > >> > > > > I want to see original value from EXT_CSD_PART_CONF.
> > > >> > > > >
> > > >> > > > > I do not know which hook is the best, so printing it from mmc.c driver
> > > >> > > > > should work better.
> > > >> > > > >
> > > >> > > >
> > > >> > > > u-boot in boot0, partconf set to 0x1:
> > > >> > > > mmc->part_config = 8
> > > >> > > >
> > > >> > > > u-boot in boot0, partconf set to 0x2:
> > > >> > > > mmc->part_config = 16
> > > >> > > >
> > > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > > >> > > > mmc->part_config = 8
> > > >> > > >
> > > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > > >> > > > mmc->part_config = 16
> > > >> > >
> > > >> > > Ah, that does not look useful :-(
> > > >> > >
> > > >> > > Just to confirm, is this output from SPL or from main U-Boot?
> > > >> > >
> > > >> >
> > > >> > Definitely SPL. I triple checked because I was also disappointed with those
> > > >> > results. With BootROM hardcoded with its boot order it seems like neither
> > > >> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> > > >> > mmc->part_config is going to work well.
> > > >>
> > > >> In emmc spec is written:
> > > >>
> > > >> Each time the host wants to access a partition the following flow shall be executed:
> > > >> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
> > > >> 2. Issue commands referred to the selected partition
> > > >> 3. Restore default access to the User Data Area or re-direction the access to another partition
> > > >> All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.
> > > >>
> > > >> I'm feeling that partition_access bits should be preserved between
> > > >> reading data from boot0 and starting SPL. And these bits somehow could
> > > >> be used to determinate from which source bootrom loaded SPL. Maybe the
> > > >> last point ("all the reset events...") applies there and u-boot mmc
> > > >> driver does some reset in its init phase? And need to figure
> > > >> out how to read PARTITION_ACCESS without u-boot's mmc driver?
> > > >
> > > >
> > > > I enabled MMC tracing and added some printfs in mmc.c functions to see if we can get a better idea of where best to read the value from:
> > > >
> > > > <output>
> > > > BootROM - 1.73
> > > >
> > > > Booting from MMC
> > > >
> > > > U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28 +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
> > > > ===mmc_start_init start===
> > > > ===Getting ext_csd===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > ===mmc_power_on===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > ===mmc_select_mode===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > ===mmc_mode2freq===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > ===mmc_set_initial_state===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > CMD_SEND:0
> > > > ARG 0x00000000
> > > > MMC_RSP_NONE
> > > > CMD_SEND:8
> > > > ARG 0x000001aa
> > > > RET -110
> > > > CMD_SEND:55
> > > > ARG 0x00000000
> > > > RET -110
> > > > CMD_SEND:0
> > > > ARG 0x00000000
> > > > MMC_RSP_NONE
> > > > CMD_SEND:1
> > > > ARG 0x00000000
> > > > MMC_RSP_R3,4 0x40ff8080
> > > > CMD_SEND:1
> > > > ARG 0x40300080
> > > > MMC_RSP_R3,4 0x40ff8080
> > > > CMD_SEND:1
> > > > ARG 0x40300080
> > > > MMC_RSP_R3,4 0xc0ff8080
> > > > ===mmc_start_init end===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > CMD_SEND:2
> > > > ARG 0x00000000
> > > > MMC_RSP_R2 0x15010038
> > > >           0x474d4534
> > > >           0x52010418
> > > >           0xfc4f7300
> > > >
> > > > DUMPING DATA
> > > > 000 - 15 01 00 38
> > > > 004 - 47 4d 45 34
> > > > 008 - 52 01 04 18
> > > > 012 - fc 4f 73 00
> > > > CMD_SEND:3
> > > > ARG 0x00010000
> > > > MMC_RSP_R1,5,6,7 0x00000500
> > > > CMD_SEND:9
> > > > ARG 0x00010000
> > > > MMC_RSP_R2 0xd0270132
> > > >           0x0f5903ff
> > > >           0xf6dbffef
> > > >           0x8e404000
> > > >
> > > > DUMPING DATA
> > > > 000 - d0 27 01 32
> > > > 004 - 0f 59 03 ff
> > > > 008 - f6 db ff ef
> > > > 012 - 8e 40 40 00
> > > > ===mmc_select_mode===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > ===mmc_mode2freq===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > CMD_SEND:7
> > > > ARG 0x00010000
> > > > MMC_RSP_R1,5,6,7 0x00000700
> > > > CMD_SEND:8
> > > > ARG 0x00000000
> > > > MMC_RSP_R1,5,6,7 0x00000900
> > > > ===mmc_startup_v4===
> > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
> > > > <snip>
> > > > </output>
> > > >
> > >
> > > You are correct Pali, it is preserved :)
> >
> > Perfect!
> >
> > > The first time I can get the value is at the end of mmc_set_initial_state using:
> > >
> > > static void mmc_set_initial_state(struct mmc *mmc)
> > > {
> > >    printf("+mmc_set_initial_state\n");
> > >    int err;
> > >
> > >    /* First try to set 3.3V. If it fails set to 1.8V */
> > >    err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
> > >    if (err != 0)
> > >       err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> > >    if (err != 0)
> > >       pr_warn("mmc: failed to set signal voltage\n");
> > >
> > >    mmc_select_mode(mmc, MMC_LEGACY);
> > >    mmc_set_bus_width(mmc, 1);
> > >    mmc_set_clock(mmc, 0, MMC_CLK_ENABLE);
> > >    ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> > >    err = mmc_send_ext_csd(mmc, ext_csd);
> > >    if (!err) {
> > >       printf("++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] =
> > > %d\n", ext_csd[EXT_CSD_PART_CONF]);
> > >    }
> > > }
> >
> > And seems you found the correct function because after
> > mmc_set_initial_state() in mmc_get_op_cond() is code:
> >
> >       /* Reset the Card */
> >       err = mmc_go_idle(mmc);
> >
> > And in emmc spec is written:
> > "All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area."
> >
> > So we really need to read EXT_CSD_PART_CONF before that reset.
> >
> > > I set mmc partconf 0 0 0 0, zeroed the first boot area and loaded
> > > u-boot in the second. I had a few extra attempts to call
> > > mmc_send_ext_csd in earlier functions that timeout and a lot of extra
> > > printfs:
> > >
> > > <output>
> > > 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-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 23:27:20 +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
> > > +mmc_power_init
> > > +mmc_power_cycle
> > > +mmc_power_off
> > > +mmc_power_on
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > > sdhci_send_command: Timeout for status update!
> > >         RET             -110
> > > +mmc_set_initial_state
> > > +mmc_set_signal_voltage
> > > +mmc_select_mode
> > > +mmc_mode2freq
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > > sdhci_send_command: Timeout for status update!
> > >         RET             -110
> > > +mmc_set_bus_width
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > > sdhci_send_command: Timeout for status update!
> > >         RET             -110
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 2
> >
> > Access is set to second boot partition which matches the boot source in
> > BootROM.
> >
> > > +mmc_go_idle
> > > CMD_SEND:0
> > >         ARG             0x00000000
> > >         MMC_RSP_NONE
> > > +mmc_send_if_cond
> > > CMD_SEND:8
> > >         ARG             0x000001aa
> > >         RET             -110
> > > +sd_send_op_cond
> > > CMD_SEND:55
> > >         ARG             0x00000000
> > >         RET             -110
> > > +mmc_send_op_cond
> > > +mmc_go_idle
> > > CMD_SEND:0
> > >         ARG             0x00000000
> > >         MMC_RSP_NONE
> > > +mmc_send_op_cond_iter
> > > CMD_SEND:1
> > >         ARG             0x00000000
> > >         MMC_RSP_R3,4         0x40ff8080
> > > +mmc_send_op_cond_iter
> > > CMD_SEND:1
> > >         ARG             0x40300080
> > >         MMC_RSP_R3,4         0x40ff8080
> > > +mmc_send_op_cond_iter
> > > CMD_SEND:1
> > >         ARG             0x40300080
> > >         MMC_RSP_R3,4         0xc0ff8080
> > > +mmc_complete_init
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         RET             -110
> > > +mmc_complete_op_cond
> > > +mmc_startup
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         RET             -110
> > > CMD_SEND:2
> > >         ARG             0x00000000
> > >         MMC_RSP_R2         0x15010038
> > >                            0x474d4534
> > >                            0x52010418
> > >                            0xfc4f7300
> > >
> > >                     DUMPING DATA
> > >                     000 - 15 01 00 38
> > >                     004 - 47 4d 45 34
> > >                     008 - 52 01 04 18
> > >                     012 - fc 4f 73 00
> > > CMD_SEND:3
> > >         ARG             0x00010000
> > >         MMC_RSP_R1,5,6,7      0x00400500
> > > CMD_SEND:9
> > >         ARG             0x00010000
> > >         MMC_RSP_R2         0xd0270132
> > >                            0x0f5903ff
> > >                            0xf6dbffef
> > >                            0x8e404000
> > >
> > >                     DUMPING DATA
> > >                     000 - d0 27 01 32
> > >                     004 - 0f 59 03 ff
> > >                     008 - f6 db ff ef
> > >                     012 - 8e 40 40 00
> > > +mmc_select_mode
> > > +mmc_mode2freq
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         RET             -110
> > > CMD_SEND:7
> > >         ARG             0x00010000
> > >         MMC_RSP_R1,5,6,7      0x00000700
> > > +mmc_startup_v4
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > +mmc_set_capacity
> > > +mmc_get_capabilities
> > > +mmc_select_mode_and_width
> > > CMD_SEND:6
> > >         ARG             0x03b70100
> > >         MMC_RSP_R1b         0x00000900
> > > CMD_SEND:13
> > >         ARG             0x00010000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CURR STATE:4
> > > +bus_width
> > > +mmc_set_bus_width
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         RET             -70
> > > CMD_SEND:6
> > >         ARG             0x03b90100
> > >         MMC_RSP_R1b         0x00000900
> > > CMD_SEND:13
> > >         ARG             0x00010000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CURR STATE:4
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > +mmc_select_mode
> > > +mmc_mode2freq
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > ++mmc_select_mode ext_csd[EXT_CSD_PART_CONF] = 0
> > > +mmc_read_and_compare_ext_csd
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CMD_SEND:8
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > ++ext_csd[EXT_CSD_PART_CONF] = 0
> > > CMD_SEND:16
> > >         ARG             0x00000200
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CMD_SEND:17
> > >         ARG             0x00000000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CMD_SEND:16
> > >         ARG             0x00000200
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CMD_SEND:18
> > >         ARG             0x000000de
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CMD_SEND:12
> > >         ARG             0x00000000
> > >         MMC_RSP_R1b         0x00000b00
> > >
> > >
> > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> > >
> > > SoC:   MV88F6828-A0 at 1600 MHz
> > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > clearfog.c board_init part_config = 247
> > > Core:  38 devices, 22 uclasses, devicetree: separate
> > > MMC:   mv_sdh: 0
> > > Loading Environment from MMC... OK
> > > Model: SolidRun Clearfog A1
> > > clearfog.c checkboard part_config = 0
> > > Board: SolidRun Clearfog Pro
> > > Net:   eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000
> > > Hit any key to stop autoboot:  0
> > > </output>
> > >
> > > When I set mmc partconf 0 0 2 2, I get:
> > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 18
> >
> > Access is second boot partition which matches your setup.
> >
> > > When I load u-boot to the first boot area with mmc partconf 0 0 2 2, I get:
> > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 17
> >
> > Also matches as access is to first boot partition.
> >
> > > When I load u-boot to the first boot area with mmc partconf 0 0 0 0, I get:
> > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 1
> >
> > And this also matches as access is also to first boot partition.
> >
> > > When I zero both boot areas and load u-boot to the data/user area with
> > > mmc partconf 0 0 0 0, I get:
> > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 0
> >
> > And this access is to user area.
> >
> > > I'm not sure where to take it from here, but I'm assuming we'll need
> > > to stash that value somewhere so we can refer to it later.
> >
> > In my opinion we need to read access bits of EXT_CSD_PART_CONF before
> > that mmc_go_idle() which resets the card, and store them to
> > mmc->part_config. Then in mmc_startup_v4() ensures that we do not
> > overwrite access bits of mmc->part_config as we know that at this stage
> > access bits in EXT_CSD_PART_CONF are already reset.
>
> What about this change?
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 210703ea46b3..0c9c1a43b43b 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -2329,8 +2329,13 @@ static int mmc_startup_v4(struct mmc *mmc)
>         /* store the partition info of emmc */
>         mmc->part_support = ext_csd[EXT_CSD_PARTITIONING_SUPPORT];
>         if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
> -           ext_csd[EXT_CSD_BOOT_MULT])
> -               mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
> +           ext_csd[EXT_CSD_BOOT_MULT]) {
> +               if (mmc->part_config == MMCPART_NOAVAILABLE)
> +                       mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
> +               else
> +                       mmc->part_config = (ext_csd[EXT_CSD_PART_CONF] & ~PART_ACCESS_MASK) |
> +                                          (mmc->part_config & PART_ACCESS_MASK);
> +       }
>         if (part_completed &&
>             (ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & ENHNCD_SUPPORT))
>                 mmc->part_attr = ext_csd[EXT_CSD_PARTITIONS_ATTRIBUTE];
> @@ -2600,7 +2605,6 @@ static int mmc_startup(struct mmc *mmc)
>  #if CONFIG_IS_ENABLED(MMC_WRITE)
>         mmc->erase_grp_size = 1;
>  #endif
> -       mmc->part_config = MMCPART_NOAVAILABLE;
>
>         err = mmc_startup_v4(mmc);
>         if (err)
> @@ -2848,9 +2852,21 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet)
>                 return err;
>         mmc->ddr_mode = 0;
>
> +       mmc->part_config = MMCPART_NOAVAILABLE;
> +
>  retry:
>         mmc_set_initial_state(mmc);
>
> +       if (mmc->part_config == MMCPART_NOAVAILABLE &&
> +           !IS_SD(mmc) && mmc->version >= MMC_VERSION_4) {

mmc->version == 0 at this point, so the if is always false. I removed
that part of the test to get the results below.

> +               ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> +               err = mmc_send_ext_csd(mmc, ext_csd);
> +               if (err == 0 &&
> +                   ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
> +                    ext_csd[EXT_CSD_BOOT_MULT]))
> +                       mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK;

With zeroed first boot area and partconf 0 0 2 2, after this line I see:
ext_csd[EXT_CSD_PART_CONF] == 18
mmc->part_config == 2

> +       }
> +
>         /* Reset the Card */
>         err = mmc_go_idle(mmc);
>

After the emmc logic in mmc_startup_v4, mmc->part_config == 18. To
test if we can use it to choose a partition, I set mmc partconf 0 0 1
1 and added the patch below (proof of concept only; don't merge!). SPL
loads from the second boot area since the first is zeroed, and chooses
the second boot area as the boot part successfully.

index 0087fea7db..0ebe9985c5 100644
--- a/board/solidrun/clearfog/clearfog.c
+++ b/board/solidrun/clearfog/clearfog.c
@@ -263,6 +263,15 @@ int board_late_init(void)
        return 0;
 }

+int spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+       int part;
+       part = mmc->part_config % 8;
+       if (part == 7)
+               part = 0;
+       return part;
+}
+
 static bool has_emmc(void)
 {
        struct mmc *mmc;

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Pali Rohár]

On Thursday 23 March 2023 12:24:13 Martin Rowe wrote:
> On Wed, 22 Mar 2023 at 19:09, Pali Rohár <pali@kernel.org> wrote:
> >
> > On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote:
> > > On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote:
> > > > On Wed, 22 Mar 2023 at 12:38, Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > > > >
> > > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:
> > > > >>
> > > > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> > > > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> > > > >> >
> > > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > > > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> > > > >> > > >
> > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as
> > > > >> > > possible)?
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > In SPL mmc->part_config is 255
> > > > >> > > > > > In main u-boot at the start of clearfog.c board_init()
> > > > >> > > mmc->part_config
> > > > >> > > > > is
> > > > >> > > > > > 255
> > > > >> > > > > > In main u-boot at the start of clearfog.c checkboard()
> > > > >> > > mmc->part_config
> > > > >> > > > > is
> > > > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > > > >> > > > >
> > > > >> > > > > 255 is uninitialized value.
> > > > >> > > > >
> > > > >> > > > > > If I set partition_enable to 2, I get the same result except the
> > > > >> > > value is
> > > > >> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> > > > >> > > last
> > > > >> > > > > value
> > > > >> > > > >
> > > > >> > > > > Try to change "access" bits.
> > > > >> > > > >
> > > > >> > > > > > <partition_enable 1>
> > > > >> > > > > > BootROM - 1.73
> > > > >> > > > > >
> > > > >> > > > > > Booting from MMC
> > > > >> > > > > >
> > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > > >> > > 10:05:32
> > > > >> > > > > > +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
> > > > >> > > > > > spl.c spl_boot_device part_config = 255
> > > > >> > > > > > Trying to boot from MMC1
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > > >> > > +1000)
> > > > >> > > > > >
> > > > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > >> > > > > > clearfog.c board_init part_config = 255
> > > > >> > > > > > 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
> > > > >> > > > > > clearfog.c checkboard part_config = 8
> > > > >> > > > > > Board: SolidRun Clearfog Pro
> > > > >> > > > > > Net:
> > > > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > >> > > > > 32:16:0e:b4:d1:d8
> > > > >> > > > > > eth1: ethernet@70000
> > > > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > >> > > > > 72:30:3f:79:07:12
> > > > >> > > > > > , eth2: ethernet@30000
> > > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > >> > > > > 82:fb:71:23:46:4f
> > > > >> > > > > > , eth3: ethernet@34000
> > > > >> > > > > > Hit any key to stop autoboot:  0
> > > > >> > > > > > => mmc partconf 0
> > > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > >> > > > > > BOOT_ACK: 0x0
> > > > >> > > > > > BOOT_PARTITION_ENABLE: 0x1
> > > > >> > > > > > PARTITION_ACCESS: 0x0
> > > > >> > > > > > </partition_enable 1>
> > > > >> > > > > >
> > > > >> > > > > > <partition_enable 2>
> > > > >> > > > > > BootROM - 1.73
> > > > >> > > > > >
> > > > >> > > > > > Booting from MMC
> > > > >> > > > > >
> > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > > >> > > 10:05:32
> > > > >> > > > > > +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
> > > > >> > > > > > spl.c spl_boot_device part_config = 255
> > > > >> > > > > > Trying to boot from MMC1
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > > >> > > +1000)
> > > > >> > > > > >
> > > > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > >> > > > > > clearfog.c board_init part_config = 255
> > > > >> > > > > > 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
> > > > >> > > > > > clearfog.c checkboard part_config = 16
> > > > >> > > > > > Board: SolidRun Clearfog Pro
> > > > >> > > > > > Net:
> > > > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > >> > > > > 92:5a:fc:14:e8:f6
> > > > >> > > > > > eth1: ethernet@70000
> > > > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > >> > > > > 42:9c:d8:3a:cb:b2
> > > > >> > > > > > , eth2: ethernet@30000
> > > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > >> > > > > c6:99:20:f4:02:a0
> > > > >> > > > > > , eth3: ethernet@34000
> > > > >> > > > > > Hit any key to stop autoboot:  0
> > > > >> > > > > > => mmc partconf 0
> > > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > >> > > > > > BOOT_ACK: 0x0
> > > > >> > > > > > BOOT_PARTITION_ENABLE: 0x2
> > > > >> > > > > > PARTITION_ACCESS: 0x0
> > > > >> > > > > > </partition_enable 2>
> > > > >> > > > >
> > > > >> > > > > Are both logs from the configuration when SPL+u-boot is stored on
> > > > >> > > Boot0?
> > > > >> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > > > >> > > > > interested to see if "access" bits are changed in SPL (before loading
> > > > >> > > > > main u-boot).
> > > > >> > > > >
> > > > >> > > > > > I'm having trouble trying to find the hooks which run between
> > > > >> > > board_init
> > > > >> > > > > > and checkboard. If you can point me in the right direction I'm happy
> > > > >> > > to
> > > > >> > > > > > re-run and try to narrow down where the valid values are being set
> > > > >> > > from.
> > > > >> > > > >
> > > > >> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > > > >> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > > > >> > > > > I want to see original value from EXT_CSD_PART_CONF.
> > > > >> > > > >
> > > > >> > > > > I do not know which hook is the best, so printing it from mmc.c driver
> > > > >> > > > > should work better.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > > u-boot in boot0, partconf set to 0x1:
> > > > >> > > > mmc->part_config = 8
> > > > >> > > >
> > > > >> > > > u-boot in boot0, partconf set to 0x2:
> > > > >> > > > mmc->part_config = 16
> > > > >> > > >
> > > > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > > > >> > > > mmc->part_config = 8
> > > > >> > > >
> > > > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > > > >> > > > mmc->part_config = 16
> > > > >> > >
> > > > >> > > Ah, that does not look useful :-(
> > > > >> > >
> > > > >> > > Just to confirm, is this output from SPL or from main U-Boot?
> > > > >> > >
> > > > >> >
> > > > >> > Definitely SPL. I triple checked because I was also disappointed with those
> > > > >> > results. With BootROM hardcoded with its boot order it seems like neither
> > > > >> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> > > > >> > mmc->part_config is going to work well.
> > > > >>
> > > > >> In emmc spec is written:
> > > > >>
> > > > >> Each time the host wants to access a partition the following flow shall be executed:
> > > > >> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
> > > > >> 2. Issue commands referred to the selected partition
> > > > >> 3. Restore default access to the User Data Area or re-direction the access to another partition
> > > > >> All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.
> > > > >>
> > > > >> I'm feeling that partition_access bits should be preserved between
> > > > >> reading data from boot0 and starting SPL. And these bits somehow could
> > > > >> be used to determinate from which source bootrom loaded SPL. Maybe the
> > > > >> last point ("all the reset events...") applies there and u-boot mmc
> > > > >> driver does some reset in its init phase? And need to figure
> > > > >> out how to read PARTITION_ACCESS without u-boot's mmc driver?
> > > > >
> > > > >
> > > > > I enabled MMC tracing and added some printfs in mmc.c functions to see if we can get a better idea of where best to read the value from:
> > > > >
> > > > > <output>
> > > > > BootROM - 1.73
> > > > >
> > > > > Booting from MMC
> > > > >
> > > > > U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28 +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
> > > > > ===mmc_start_init start===
> > > > > ===Getting ext_csd===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > ===mmc_power_on===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > ===mmc_select_mode===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > ===mmc_mode2freq===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > ===mmc_set_initial_state===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > CMD_SEND:0
> > > > > ARG 0x00000000
> > > > > MMC_RSP_NONE
> > > > > CMD_SEND:8
> > > > > ARG 0x000001aa
> > > > > RET -110
> > > > > CMD_SEND:55
> > > > > ARG 0x00000000
> > > > > RET -110
> > > > > CMD_SEND:0
> > > > > ARG 0x00000000
> > > > > MMC_RSP_NONE
> > > > > CMD_SEND:1
> > > > > ARG 0x00000000
> > > > > MMC_RSP_R3,4 0x40ff8080
> > > > > CMD_SEND:1
> > > > > ARG 0x40300080
> > > > > MMC_RSP_R3,4 0x40ff8080
> > > > > CMD_SEND:1
> > > > > ARG 0x40300080
> > > > > MMC_RSP_R3,4 0xc0ff8080
> > > > > ===mmc_start_init end===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > CMD_SEND:2
> > > > > ARG 0x00000000
> > > > > MMC_RSP_R2 0x15010038
> > > > >           0x474d4534
> > > > >           0x52010418
> > > > >           0xfc4f7300
> > > > >
> > > > > DUMPING DATA
> > > > > 000 - 15 01 00 38
> > > > > 004 - 47 4d 45 34
> > > > > 008 - 52 01 04 18
> > > > > 012 - fc 4f 73 00
> > > > > CMD_SEND:3
> > > > > ARG 0x00010000
> > > > > MMC_RSP_R1,5,6,7 0x00000500
> > > > > CMD_SEND:9
> > > > > ARG 0x00010000
> > > > > MMC_RSP_R2 0xd0270132
> > > > >           0x0f5903ff
> > > > >           0xf6dbffef
> > > > >           0x8e404000
> > > > >
> > > > > DUMPING DATA
> > > > > 000 - d0 27 01 32
> > > > > 004 - 0f 59 03 ff
> > > > > 008 - f6 db ff ef
> > > > > 012 - 8e 40 40 00
> > > > > ===mmc_select_mode===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > ===mmc_mode2freq===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > CMD_SEND:7
> > > > > ARG 0x00010000
> > > > > MMC_RSP_R1,5,6,7 0x00000700
> > > > > CMD_SEND:8
> > > > > ARG 0x00000000
> > > > > MMC_RSP_R1,5,6,7 0x00000900
> > > > > ===mmc_startup_v4===
> > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
> > > > > <snip>
> > > > > </output>
> > > > >
> > > >
> > > > You are correct Pali, it is preserved :)
> > >
> > > Perfect!
> > >
> > > > The first time I can get the value is at the end of mmc_set_initial_state using:
> > > >
> > > > static void mmc_set_initial_state(struct mmc *mmc)
> > > > {
> > > >    printf("+mmc_set_initial_state\n");
> > > >    int err;
> > > >
> > > >    /* First try to set 3.3V. If it fails set to 1.8V */
> > > >    err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
> > > >    if (err != 0)
> > > >       err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> > > >    if (err != 0)
> > > >       pr_warn("mmc: failed to set signal voltage\n");
> > > >
> > > >    mmc_select_mode(mmc, MMC_LEGACY);
> > > >    mmc_set_bus_width(mmc, 1);
> > > >    mmc_set_clock(mmc, 0, MMC_CLK_ENABLE);
> > > >    ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> > > >    err = mmc_send_ext_csd(mmc, ext_csd);
> > > >    if (!err) {
> > > >       printf("++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] =
> > > > %d\n", ext_csd[EXT_CSD_PART_CONF]);
> > > >    }
> > > > }
> > >
> > > And seems you found the correct function because after
> > > mmc_set_initial_state() in mmc_get_op_cond() is code:
> > >
> > >       /* Reset the Card */
> > >       err = mmc_go_idle(mmc);
> > >
> > > And in emmc spec is written:
> > > "All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area."
> > >
> > > So we really need to read EXT_CSD_PART_CONF before that reset.
> > >
> > > > I set mmc partconf 0 0 0 0, zeroed the first boot area and loaded
> > > > u-boot in the second. I had a few extra attempts to call
> > > > mmc_send_ext_csd in earlier functions that timeout and a lot of extra
> > > > printfs:
> > > >
> > > > <output>
> > > > 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-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 23:27:20 +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
> > > > +mmc_power_init
> > > > +mmc_power_cycle
> > > > +mmc_power_off
> > > > +mmc_power_on
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > > sdhci_send_command: Timeout for status update!
> > > >         RET             -110
> > > > +mmc_set_initial_state
> > > > +mmc_set_signal_voltage
> > > > +mmc_select_mode
> > > > +mmc_mode2freq
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > > sdhci_send_command: Timeout for status update!
> > > >         RET             -110
> > > > +mmc_set_bus_width
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > > sdhci_send_command: Timeout for status update!
> > > >         RET             -110
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 2
> > >
> > > Access is set to second boot partition which matches the boot source in
> > > BootROM.
> > >
> > > > +mmc_go_idle
> > > > CMD_SEND:0
> > > >         ARG             0x00000000
> > > >         MMC_RSP_NONE
> > > > +mmc_send_if_cond
> > > > CMD_SEND:8
> > > >         ARG             0x000001aa
> > > >         RET             -110
> > > > +sd_send_op_cond
> > > > CMD_SEND:55
> > > >         ARG             0x00000000
> > > >         RET             -110
> > > > +mmc_send_op_cond
> > > > +mmc_go_idle
> > > > CMD_SEND:0
> > > >         ARG             0x00000000
> > > >         MMC_RSP_NONE
> > > > +mmc_send_op_cond_iter
> > > > CMD_SEND:1
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R3,4         0x40ff8080
> > > > +mmc_send_op_cond_iter
> > > > CMD_SEND:1
> > > >         ARG             0x40300080
> > > >         MMC_RSP_R3,4         0x40ff8080
> > > > +mmc_send_op_cond_iter
> > > > CMD_SEND:1
> > > >         ARG             0x40300080
> > > >         MMC_RSP_R3,4         0xc0ff8080
> > > > +mmc_complete_init
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         RET             -110
> > > > +mmc_complete_op_cond
> > > > +mmc_startup
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         RET             -110
> > > > CMD_SEND:2
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R2         0x15010038
> > > >                            0x474d4534
> > > >                            0x52010418
> > > >                            0xfc4f7300
> > > >
> > > >                     DUMPING DATA
> > > >                     000 - 15 01 00 38
> > > >                     004 - 47 4d 45 34
> > > >                     008 - 52 01 04 18
> > > >                     012 - fc 4f 73 00
> > > > CMD_SEND:3
> > > >         ARG             0x00010000
> > > >         MMC_RSP_R1,5,6,7      0x00400500
> > > > CMD_SEND:9
> > > >         ARG             0x00010000
> > > >         MMC_RSP_R2         0xd0270132
> > > >                            0x0f5903ff
> > > >                            0xf6dbffef
> > > >                            0x8e404000
> > > >
> > > >                     DUMPING DATA
> > > >                     000 - d0 27 01 32
> > > >                     004 - 0f 59 03 ff
> > > >                     008 - f6 db ff ef
> > > >                     012 - 8e 40 40 00
> > > > +mmc_select_mode
> > > > +mmc_mode2freq
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         RET             -110
> > > > CMD_SEND:7
> > > >         ARG             0x00010000
> > > >         MMC_RSP_R1,5,6,7      0x00000700
> > > > +mmc_startup_v4
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > +mmc_set_capacity
> > > > +mmc_get_capabilities
> > > > +mmc_select_mode_and_width
> > > > CMD_SEND:6
> > > >         ARG             0x03b70100
> > > >         MMC_RSP_R1b         0x00000900
> > > > CMD_SEND:13
> > > >         ARG             0x00010000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CURR STATE:4
> > > > +bus_width
> > > > +mmc_set_bus_width
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         RET             -70
> > > > CMD_SEND:6
> > > >         ARG             0x03b90100
> > > >         MMC_RSP_R1b         0x00000900
> > > > CMD_SEND:13
> > > >         ARG             0x00010000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CURR STATE:4
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > +mmc_select_mode
> > > > +mmc_mode2freq
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > ++mmc_select_mode ext_csd[EXT_CSD_PART_CONF] = 0
> > > > +mmc_read_and_compare_ext_csd
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CMD_SEND:8
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > ++ext_csd[EXT_CSD_PART_CONF] = 0
> > > > CMD_SEND:16
> > > >         ARG             0x00000200
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CMD_SEND:17
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CMD_SEND:16
> > > >         ARG             0x00000200
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CMD_SEND:18
> > > >         ARG             0x000000de
> > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > CMD_SEND:12
> > > >         ARG             0x00000000
> > > >         MMC_RSP_R1b         0x00000b00
> > > >
> > > >
> > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> > > >
> > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > clearfog.c board_init part_config = 247
> > > > Core:  38 devices, 22 uclasses, devicetree: separate
> > > > MMC:   mv_sdh: 0
> > > > Loading Environment from MMC... OK
> > > > Model: SolidRun Clearfog A1
> > > > clearfog.c checkboard part_config = 0
> > > > Board: SolidRun Clearfog Pro
> > > > Net:   eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000
> > > > Hit any key to stop autoboot:  0
> > > > </output>
> > > >
> > > > When I set mmc partconf 0 0 2 2, I get:
> > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 18
> > >
> > > Access is second boot partition which matches your setup.
> > >
> > > > When I load u-boot to the first boot area with mmc partconf 0 0 2 2, I get:
> > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 17
> > >
> > > Also matches as access is to first boot partition.
> > >
> > > > When I load u-boot to the first boot area with mmc partconf 0 0 0 0, I get:
> > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 1
> > >
> > > And this also matches as access is also to first boot partition.
> > >
> > > > When I zero both boot areas and load u-boot to the data/user area with
> > > > mmc partconf 0 0 0 0, I get:
> > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 0
> > >
> > > And this access is to user area.
> > >
> > > > I'm not sure where to take it from here, but I'm assuming we'll need
> > > > to stash that value somewhere so we can refer to it later.
> > >
> > > In my opinion we need to read access bits of EXT_CSD_PART_CONF before
> > > that mmc_go_idle() which resets the card, and store them to
> > > mmc->part_config. Then in mmc_startup_v4() ensures that we do not
> > > overwrite access bits of mmc->part_config as we know that at this stage
> > > access bits in EXT_CSD_PART_CONF are already reset.
> >
> > What about this change?
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 210703ea46b3..0c9c1a43b43b 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -2329,8 +2329,13 @@ static int mmc_startup_v4(struct mmc *mmc)
> >         /* store the partition info of emmc */
> >         mmc->part_support = ext_csd[EXT_CSD_PARTITIONING_SUPPORT];
> >         if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
> > -           ext_csd[EXT_CSD_BOOT_MULT])
> > -               mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
> > +           ext_csd[EXT_CSD_BOOT_MULT]) {
> > +               if (mmc->part_config == MMCPART_NOAVAILABLE)
> > +                       mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
> > +               else
> > +                       mmc->part_config = (ext_csd[EXT_CSD_PART_CONF] & ~PART_ACCESS_MASK) |
> > +                                          (mmc->part_config & PART_ACCESS_MASK);
> > +       }
> >         if (part_completed &&
> >             (ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & ENHNCD_SUPPORT))
> >                 mmc->part_attr = ext_csd[EXT_CSD_PARTITIONS_ATTRIBUTE];
> > @@ -2600,7 +2605,6 @@ static int mmc_startup(struct mmc *mmc)
> >  #if CONFIG_IS_ENABLED(MMC_WRITE)
> >         mmc->erase_grp_size = 1;
> >  #endif
> > -       mmc->part_config = MMCPART_NOAVAILABLE;
> >
> >         err = mmc_startup_v4(mmc);
> >         if (err)
> > @@ -2848,9 +2852,21 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet)
> >                 return err;
> >         mmc->ddr_mode = 0;
> >
> > +       mmc->part_config = MMCPART_NOAVAILABLE;
> > +
> >  retry:
> >         mmc_set_initial_state(mmc);
> >
> > +       if (mmc->part_config == MMCPART_NOAVAILABLE &&
> > +           !IS_SD(mmc) && mmc->version >= MMC_VERSION_4) {
> 
> mmc->version == 0 at this point, so the if is always false. I removed
> that part of the test to get the results below.

Yea, I see. IS_SD is defined based on mmc->version and mmc->version at
this stage is not available. So call mmc_send_ext_csd() unconditionally.

> > +               ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> > +               err = mmc_send_ext_csd(mmc, ext_csd);
> > +               if (err == 0 &&
> > +                   ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
> > +                    ext_csd[EXT_CSD_BOOT_MULT]))
> > +                       mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK;
> 
> With zeroed first boot area and partconf 0 0 2 2, after this line I see:
> ext_csd[EXT_CSD_PART_CONF] == 18
> mmc->part_config == 2

That it correct.

> > +       }
> > +
> >         /* Reset the Card */
> >         err = mmc_go_idle(mmc);
> >
> 
> After the emmc logic in mmc_startup_v4, mmc->part_config == 18. To
> test if we can use it to choose a partition, I set mmc partconf 0 0 1
> 1 and added the patch below (proof of concept only; don't merge!). SPL
> loads from the second boot area since the first is zeroed, and chooses
> the second boot area as the boot part successfully.

Perfect!

So I think we have a solution. I will prepare v2 patch series.

But could you test if fallback via BootROM booting is also working?

There is issue with that 5 minutes delay. But I think it should be fixed
by the patch which I sent earlier, which restore partition config based
on mmc->part_config in board_return_to_bootrom(). Could you test it?
https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
Now when mmc->part_config is correctly initialized it should restore
configuration and BootROM does not have to get that "Timeout waiting
card ready" error.

> index 0087fea7db..0ebe9985c5 100644
> --- a/board/solidrun/clearfog/clearfog.c
> +++ b/board/solidrun/clearfog/clearfog.c
> @@ -263,6 +263,15 @@ int board_late_init(void)
>         return 0;
>  }
> 
> +int spl_mmc_emmc_boot_partition(struct mmc *mmc)
> +{
> +       int part;
> +       part = mmc->part_config % 8;
> +       if (part == 7)
> +               part = 0;

Low 3 bits encodes partition access and spl_mmc_emmc_boot_partition()
should return partition access. So code has to be without 7 to 0
conversion.

Conversion is needed when reading boot partition number where 0 means
boot disabled; 1 means boot 1 part; 2 means boot 2 part; 3-6 means
reserved and 7 means user area for boot.

So it should be just:

  int spl_mmc_emmc_boot_partition(struct mmc *mmc) {
    return EXT_CSD_EXTRACT_PARTITION_ACCESS(mmc->part_config);
  }

> +       return part;
> +}
> +
>  static bool has_emmc(void)
>  {
>         struct mmc *mmc;

Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot

[Martin Rowe]

On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
>
> On Thursday 23 March 2023 12:24:13 Martin Rowe wrote:
> > On Wed, 22 Mar 2023 at 19:09, Pali Rohár <pali@kernel.org> wrote:
> > >
> > > On Wednesday 22 March 2023 18:59:45 Pali Rohár wrote:
> > > > On Wednesday 22 March 2023 13:45:56 Martin Rowe wrote:
> > > > > On Wed, 22 Mar 2023 at 12:38, Martin Rowe <martin.p.rowe@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, 21 Mar 2023 at 08:08, Pali Rohár <pali@kernel.org> wrote:
> > > > > >>
> > > > > >> On Tuesday 21 March 2023 08:01:16 Martin Rowe wrote:
> > > > > >> > On Mon, 20 Mar 2023 at 17:33, Pali Rohár <pali@kernel.org> wrote:
> > > > > >> >
> > > > > >> > > On Monday 20 March 2023 11:48:59 Martin Rowe wrote:
> > > > > >> > > > On Sun, 19 Mar 2023 at 16:22, Pali Rohár <pali@kernel.org> wrote:
> > > > > >> > > >
> > > > > >> > > > > On Sunday 19 March 2023 00:32:01 Martin Rowe wrote:
> > > > > >> > > > > > On Mon, 6 Mar 2023 at 11:53, Pali Rohár <pali@kernel.org> wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > Could you try to print mmc->part_config (ideally as early as
> > > > > >> > > possible)?
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > In SPL mmc->part_config is 255
> > > > > >> > > > > > In main u-boot at the start of clearfog.c board_init()
> > > > > >> > > mmc->part_config
> > > > > >> > > > > is
> > > > > >> > > > > > 255
> > > > > >> > > > > > In main u-boot at the start of clearfog.c checkboard()
> > > > > >> > > mmc->part_config
> > > > > >> > > > > is
> > > > > >> > > > > > 8 (ack: 0, partition_enable: 1, access: 0)
> > > > > >> > > > >
> > > > > >> > > > > 255 is uninitialized value.
> > > > > >> > > > >
> > > > > >> > > > > > If I set partition_enable to 2, I get the same result except the
> > > > > >> > > value is
> > > > > >> > > > > > 16  (ack: 0, partition_enable: 2, access: 0) instead of 8 for the
> > > > > >> > > last
> > > > > >> > > > > value
> > > > > >> > > > >
> > > > > >> > > > > Try to change "access" bits.
> > > > > >> > > > >
> > > > > >> > > > > > <partition_enable 1>
> > > > > >> > > > > > BootROM - 1.73
> > > > > >> > > > > >
> > > > > >> > > > > > Booting from MMC
> > > > > >> > > > > >
> > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > > > >> > > 10:05:32
> > > > > >> > > > > > +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
> > > > > >> > > > > > spl.c spl_boot_device part_config = 255
> > > > > >> > > > > > Trying to boot from MMC1
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > > > >> > > +1000)
> > > > > >> > > > > >
> > > > > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > >> > > > > > clearfog.c board_init part_config = 255
> > > > > >> > > > > > 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
> > > > > >> > > > > > clearfog.c checkboard part_config = 8
> > > > > >> > > > > > Board: SolidRun Clearfog Pro
> > > > > >> > > > > > Net:
> > > > > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > > >> > > > > 32:16:0e:b4:d1:d8
> > > > > >> > > > > > eth1: ethernet@70000
> > > > > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > > >> > > > > 72:30:3f:79:07:12
> > > > > >> > > > > > , eth2: ethernet@30000
> > > > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > > >> > > > > 82:fb:71:23:46:4f
> > > > > >> > > > > > , eth3: ethernet@34000
> > > > > >> > > > > > Hit any key to stop autoboot:  0
> > > > > >> > > > > > => mmc partconf 0
> > > > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > > >> > > > > > BOOT_ACK: 0x0
> > > > > >> > > > > > BOOT_PARTITION_ENABLE: 0x1
> > > > > >> > > > > > PARTITION_ACCESS: 0x0
> > > > > >> > > > > > </partition_enable 1>
> > > > > >> > > > > >
> > > > > >> > > > > > <partition_enable 2>
> > > > > >> > > > > > BootROM - 1.73
> > > > > >> > > > > >
> > > > > >> > > > > > Booting from MMC
> > > > > >> > > > > >
> > > > > >> > > > > > U-Boot SPL 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 -
> > > > > >> > > 10:05:32
> > > > > >> > > > > > +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
> > > > > >> > > > > > spl.c spl_boot_device part_config = 255
> > > > > >> > > > > > Trying to boot from MMC1
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32
> > > > > >> > > +1000)
> > > > > >> > > > > >
> > > > > >> > > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > >> > > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > >> > > > > > clearfog.c board_init part_config = 255
> > > > > >> > > > > > 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
> > > > > >> > > > > > clearfog.c checkboard part_config = 16
> > > > > >> > > > > > Board: SolidRun Clearfog Pro
> > > > > >> > > > > > Net:
> > > > > >> > > > > > Warning: ethernet@70000 (eth1) using random MAC address -
> > > > > >> > > > > 92:5a:fc:14:e8:f6
> > > > > >> > > > > > eth1: ethernet@70000
> > > > > >> > > > > > Warning: ethernet@30000 (eth2) using random MAC address -
> > > > > >> > > > > 42:9c:d8:3a:cb:b2
> > > > > >> > > > > > , eth2: ethernet@30000
> > > > > >> > > > > > Warning: ethernet@34000 (eth3) using random MAC address -
> > > > > >> > > > > c6:99:20:f4:02:a0
> > > > > >> > > > > > , eth3: ethernet@34000
> > > > > >> > > > > > Hit any key to stop autoboot:  0
> > > > > >> > > > > > => mmc partconf 0
> > > > > >> > > > > > EXT_CSD[179], PARTITION_CONFIG:
> > > > > >> > > > > > BOOT_ACK: 0x0
> > > > > >> > > > > > BOOT_PARTITION_ENABLE: 0x2
> > > > > >> > > > > > PARTITION_ACCESS: 0x0
> > > > > >> > > > > > </partition_enable 2>
> > > > > >> > > > >
> > > > > >> > > > > Are both logs from the configuration when SPL+u-boot is stored on
> > > > > >> > > Boot0?
> > > > > >> > > > > Could you try to erase Boot0 and store SPL+u-boot to Boot1? I'm
> > > > > >> > > > > interested to see if "access" bits are changed in SPL (before loading
> > > > > >> > > > > main u-boot).
> > > > > >> > > > >
> > > > > >> > > > > > I'm having trouble trying to find the hooks which run between
> > > > > >> > > board_init
> > > > > >> > > > > > and checkboard. If you can point me in the right direction I'm happy
> > > > > >> > > to
> > > > > >> > > > > > re-run and try to narrow down where the valid values are being set
> > > > > >> > > from.
> > > > > >> > > > >
> > > > > >> > > > > Print it directly in drivers/mmc/mmc.c mmc_startup_v4() where
> > > > > >> > > > > mmc->part_config = is set from ext_csd[EXT_CSD_PART_CONF] register.
> > > > > >> > > > > I want to see original value from EXT_CSD_PART_CONF.
> > > > > >> > > > >
> > > > > >> > > > > I do not know which hook is the best, so printing it from mmc.c driver
> > > > > >> > > > > should work better.
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > > > u-boot in boot0, partconf set to 0x1:
> > > > > >> > > > mmc->part_config = 8
> > > > > >> > > >
> > > > > >> > > > u-boot in boot0, partconf set to 0x2:
> > > > > >> > > > mmc->part_config = 16
> > > > > >> > > >
> > > > > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x1:
> > > > > >> > > > mmc->part_config = 8
> > > > > >> > > >
> > > > > >> > > > u-boot in boot1 (boot0 zeroed), partconf set to 0x2:
> > > > > >> > > > mmc->part_config = 16
> > > > > >> > >
> > > > > >> > > Ah, that does not look useful :-(
> > > > > >> > >
> > > > > >> > > Just to confirm, is this output from SPL or from main U-Boot?
> > > > > >> > >
> > > > > >> >
> > > > > >> > Definitely SPL. I triple checked because I was also disappointed with those
> > > > > >> > results. With BootROM hardcoded with its boot order it seems like neither
> > > > > >> > CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION nor relying on
> > > > > >> > mmc->part_config is going to work well.
> > > > > >>
> > > > > >> In emmc spec is written:
> > > > > >>
> > > > > >> Each time the host wants to access a partition the following flow shall be executed:
> > > > > >> 1. Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
> > > > > >> 2. Issue commands referred to the selected partition
> > > > > >> 3. Restore default access to the User Data Area or re-direction the access to another partition
> > > > > >> All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area.
> > > > > >>
> > > > > >> I'm feeling that partition_access bits should be preserved between
> > > > > >> reading data from boot0 and starting SPL. And these bits somehow could
> > > > > >> be used to determinate from which source bootrom loaded SPL. Maybe the
> > > > > >> last point ("all the reset events...") applies there and u-boot mmc
> > > > > >> driver does some reset in its init phase? And need to figure
> > > > > >> out how to read PARTITION_ACCESS without u-boot's mmc driver?
> > > > > >
> > > > > >
> > > > > > I enabled MMC tracing and added some printfs in mmc.c functions to see if we can get a better idea of where best to read the value from:
> > > > > >
> > > > > > <output>
> > > > > > BootROM - 1.73
> > > > > >
> > > > > > Booting from MMC
> > > > > >
> > > > > > U-Boot SPL 2023.04-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 22:14:28 +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
> > > > > > ===mmc_start_init start===
> > > > > > ===Getting ext_csd===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > ===mmc_power_on===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > ===mmc_select_mode===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > ===mmc_mode2freq===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > ===mmc_set_initial_state===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > CMD_SEND:0
> > > > > > ARG 0x00000000
> > > > > > MMC_RSP_NONE
> > > > > > CMD_SEND:8
> > > > > > ARG 0x000001aa
> > > > > > RET -110
> > > > > > CMD_SEND:55
> > > > > > ARG 0x00000000
> > > > > > RET -110
> > > > > > CMD_SEND:0
> > > > > > ARG 0x00000000
> > > > > > MMC_RSP_NONE
> > > > > > CMD_SEND:1
> > > > > > ARG 0x00000000
> > > > > > MMC_RSP_R3,4 0x40ff8080
> > > > > > CMD_SEND:1
> > > > > > ARG 0x40300080
> > > > > > MMC_RSP_R3,4 0x40ff8080
> > > > > > CMD_SEND:1
> > > > > > ARG 0x40300080
> > > > > > MMC_RSP_R3,4 0xc0ff8080
> > > > > > ===mmc_start_init end===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > CMD_SEND:2
> > > > > > ARG 0x00000000
> > > > > > MMC_RSP_R2 0x15010038
> > > > > >           0x474d4534
> > > > > >           0x52010418
> > > > > >           0xfc4f7300
> > > > > >
> > > > > > DUMPING DATA
> > > > > > 000 - 15 01 00 38
> > > > > > 004 - 47 4d 45 34
> > > > > > 008 - 52 01 04 18
> > > > > > 012 - fc 4f 73 00
> > > > > > CMD_SEND:3
> > > > > > ARG 0x00010000
> > > > > > MMC_RSP_R1,5,6,7 0x00000500
> > > > > > CMD_SEND:9
> > > > > > ARG 0x00010000
> > > > > > MMC_RSP_R2 0xd0270132
> > > > > >           0x0f5903ff
> > > > > >           0xf6dbffef
> > > > > >           0x8e404000
> > > > > >
> > > > > > DUMPING DATA
> > > > > > 000 - d0 27 01 32
> > > > > > 004 - 0f 59 03 ff
> > > > > > 008 - f6 db ff ef
> > > > > > 012 - 8e 40 40 00
> > > > > > ===mmc_select_mode===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > ===mmc_mode2freq===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > > CMD_SEND:7
> > > > > > ARG 0x00010000
> > > > > > MMC_RSP_R1,5,6,7 0x00000700
> > > > > > CMD_SEND:8
> > > > > > ARG 0x00000000
> > > > > > MMC_RSP_R1,5,6,7 0x00000900
> > > > > > ===mmc_startup_v4===
> > > > > > ===mmc->ext_csd[EXT_CSD_PART_CONF] = 8
> > > > > > <snip>
> > > > > > </output>
> > > > > >
> > > > >
> > > > > You are correct Pali, it is preserved :)
> > > >
> > > > Perfect!
> > > >
> > > > > The first time I can get the value is at the end of mmc_set_initial_state using:
> > > > >
> > > > > static void mmc_set_initial_state(struct mmc *mmc)
> > > > > {
> > > > >    printf("+mmc_set_initial_state\n");
> > > > >    int err;
> > > > >
> > > > >    /* First try to set 3.3V. If it fails set to 1.8V */
> > > > >    err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_330);
> > > > >    if (err != 0)
> > > > >       err = mmc_set_signal_voltage(mmc, MMC_SIGNAL_VOLTAGE_180);
> > > > >    if (err != 0)
> > > > >       pr_warn("mmc: failed to set signal voltage\n");
> > > > >
> > > > >    mmc_select_mode(mmc, MMC_LEGACY);
> > > > >    mmc_set_bus_width(mmc, 1);
> > > > >    mmc_set_clock(mmc, 0, MMC_CLK_ENABLE);
> > > > >    ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> > > > >    err = mmc_send_ext_csd(mmc, ext_csd);
> > > > >    if (!err) {
> > > > >       printf("++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] =
> > > > > %d\n", ext_csd[EXT_CSD_PART_CONF]);
> > > > >    }
> > > > > }
> > > >
> > > > And seems you found the correct function because after
> > > > mmc_set_initial_state() in mmc_get_op_cond() is code:
> > > >
> > > >       /* Reset the Card */
> > > >       err = mmc_go_idle(mmc);
> > > >
> > > > And in emmc spec is written:
> > > > "All the reset events (CMD0 or hardware reset) will restore the access by default to the User Data Area."
> > > >
> > > > So we really need to read EXT_CSD_PART_CONF before that reset.
> > > >
> > > > > I set mmc partconf 0 0 0 0, zeroed the first boot area and loaded
> > > > > u-boot in the second. I had a few extra attempts to call
> > > > > mmc_send_ext_csd in earlier functions that timeout and a lot of extra
> > > > > printfs:
> > > > >
> > > > > <output>
> > > > > 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-rc4-00342-g7e562609bb-dirty (Mar 22 2023 - 23:27:20 +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
> > > > > +mmc_power_init
> > > > > +mmc_power_cycle
> > > > > +mmc_power_off
> > > > > +mmc_power_on
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > > sdhci_send_command: Timeout for status update!
> > > > >         RET             -110
> > > > > +mmc_set_initial_state
> > > > > +mmc_set_signal_voltage
> > > > > +mmc_select_mode
> > > > > +mmc_mode2freq
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > > sdhci_send_command: Timeout for status update!
> > > > >         RET             -110
> > > > > +mmc_set_bus_width
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > > sdhci_send_command: Timeout for status update!
> > > > >         RET             -110
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 2
> > > >
> > > > Access is set to second boot partition which matches the boot source in
> > > > BootROM.
> > > >
> > > > > +mmc_go_idle
> > > > > CMD_SEND:0
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_NONE
> > > > > +mmc_send_if_cond
> > > > > CMD_SEND:8
> > > > >         ARG             0x000001aa
> > > > >         RET             -110
> > > > > +sd_send_op_cond
> > > > > CMD_SEND:55
> > > > >         ARG             0x00000000
> > > > >         RET             -110
> > > > > +mmc_send_op_cond
> > > > > +mmc_go_idle
> > > > > CMD_SEND:0
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_NONE
> > > > > +mmc_send_op_cond_iter
> > > > > CMD_SEND:1
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R3,4         0x40ff8080
> > > > > +mmc_send_op_cond_iter
> > > > > CMD_SEND:1
> > > > >         ARG             0x40300080
> > > > >         MMC_RSP_R3,4         0x40ff8080
> > > > > +mmc_send_op_cond_iter
> > > > > CMD_SEND:1
> > > > >         ARG             0x40300080
> > > > >         MMC_RSP_R3,4         0xc0ff8080
> > > > > +mmc_complete_init
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         RET             -110
> > > > > +mmc_complete_op_cond
> > > > > +mmc_startup
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         RET             -110
> > > > > CMD_SEND:2
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R2         0x15010038
> > > > >                            0x474d4534
> > > > >                            0x52010418
> > > > >                            0xfc4f7300
> > > > >
> > > > >                     DUMPING DATA
> > > > >                     000 - 15 01 00 38
> > > > >                     004 - 47 4d 45 34
> > > > >                     008 - 52 01 04 18
> > > > >                     012 - fc 4f 73 00
> > > > > CMD_SEND:3
> > > > >         ARG             0x00010000
> > > > >         MMC_RSP_R1,5,6,7      0x00400500
> > > > > CMD_SEND:9
> > > > >         ARG             0x00010000
> > > > >         MMC_RSP_R2         0xd0270132
> > > > >                            0x0f5903ff
> > > > >                            0xf6dbffef
> > > > >                            0x8e404000
> > > > >
> > > > >                     DUMPING DATA
> > > > >                     000 - d0 27 01 32
> > > > >                     004 - 0f 59 03 ff
> > > > >                     008 - f6 db ff ef
> > > > >                     012 - 8e 40 40 00
> > > > > +mmc_select_mode
> > > > > +mmc_mode2freq
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         RET             -110
> > > > > CMD_SEND:7
> > > > >         ARG             0x00010000
> > > > >         MMC_RSP_R1,5,6,7      0x00000700
> > > > > +mmc_startup_v4
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > +mmc_set_capacity
> > > > > +mmc_get_capabilities
> > > > > +mmc_select_mode_and_width
> > > > > CMD_SEND:6
> > > > >         ARG             0x03b70100
> > > > >         MMC_RSP_R1b         0x00000900
> > > > > CMD_SEND:13
> > > > >         ARG             0x00010000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CURR STATE:4
> > > > > +bus_width
> > > > > +mmc_set_bus_width
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         RET             -70
> > > > > CMD_SEND:6
> > > > >         ARG             0x03b90100
> > > > >         MMC_RSP_R1b         0x00000900
> > > > > CMD_SEND:13
> > > > >         ARG             0x00010000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CURR STATE:4
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > +mmc_select_mode
> > > > > +mmc_mode2freq
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > ++mmc_select_mode ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > +mmc_read_and_compare_ext_csd
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CMD_SEND:8
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > ++ext_csd[EXT_CSD_PART_CONF] = 0
> > > > > CMD_SEND:16
> > > > >         ARG             0x00000200
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CMD_SEND:17
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CMD_SEND:16
> > > > >         ARG             0x00000200
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CMD_SEND:18
> > > > >         ARG             0x000000de
> > > > >         MMC_RSP_R1,5,6,7      0x00000900
> > > > > CMD_SEND:12
> > > > >         ARG             0x00000000
> > > > >         MMC_RSP_R1b         0x00000b00
> > > > >
> > > > >
> > > > > U-Boot 2023.04-rc3-00159-gd1653548d2-dirty (Mar 19 2023 - 10:05:32 +1000)
> > > > >
> > > > > SoC:   MV88F6828-A0 at 1600 MHz
> > > > > DRAM:  1 GiB (800 MHz, 32-bit, ECC not enabled)
> > > > > clearfog.c board_init part_config = 247
> > > > > Core:  38 devices, 22 uclasses, devicetree: separate
> > > > > MMC:   mv_sdh: 0
> > > > > Loading Environment from MMC... OK
> > > > > Model: SolidRun Clearfog A1
> > > > > clearfog.c checkboard part_config = 0
> > > > > Board: SolidRun Clearfog Pro
> > > > > Net:   eth1: ethernet@70000, eth2: ethernet@30000, eth3: ethernet@34000
> > > > > Hit any key to stop autoboot:  0
> > > > > </output>
> > > > >
> > > > > When I set mmc partconf 0 0 2 2, I get:
> > > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 18
> > > >
> > > > Access is second boot partition which matches your setup.
> > > >
> > > > > When I load u-boot to the first boot area with mmc partconf 0 0 2 2, I get:
> > > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 17
> > > >
> > > > Also matches as access is to first boot partition.
> > > >
> > > > > When I load u-boot to the first boot area with mmc partconf 0 0 0 0, I get:
> > > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 1
> > > >
> > > > And this also matches as access is also to first boot partition.
> > > >
> > > > > When I zero both boot areas and load u-boot to the data/user area with
> > > > > mmc partconf 0 0 0 0, I get:
> > > > > ++mmc_set_initial_state ext_csd[EXT_CSD_PART_CONF] = 0
> > > >
> > > > And this access is to user area.
> > > >
> > > > > I'm not sure where to take it from here, but I'm assuming we'll need
> > > > > to stash that value somewhere so we can refer to it later.
> > > >
> > > > In my opinion we need to read access bits of EXT_CSD_PART_CONF before
> > > > that mmc_go_idle() which resets the card, and store them to
> > > > mmc->part_config. Then in mmc_startup_v4() ensures that we do not
> > > > overwrite access bits of mmc->part_config as we know that at this stage
> > > > access bits in EXT_CSD_PART_CONF are already reset.
> > >
> > > What about this change?
> > >
> > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > > index 210703ea46b3..0c9c1a43b43b 100644
> > > --- a/drivers/mmc/mmc.c
> > > +++ b/drivers/mmc/mmc.c
> > > @@ -2329,8 +2329,13 @@ static int mmc_startup_v4(struct mmc *mmc)
> > >         /* store the partition info of emmc */
> > >         mmc->part_support = ext_csd[EXT_CSD_PARTITIONING_SUPPORT];
> > >         if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
> > > -           ext_csd[EXT_CSD_BOOT_MULT])
> > > -               mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
> > > +           ext_csd[EXT_CSD_BOOT_MULT]) {
> > > +               if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > +                       mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
> > > +               else
> > > +                       mmc->part_config = (ext_csd[EXT_CSD_PART_CONF] & ~PART_ACCESS_MASK) |
> > > +                                          (mmc->part_config & PART_ACCESS_MASK);
> > > +       }
> > >         if (part_completed &&
> > >             (ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & ENHNCD_SUPPORT))
> > >                 mmc->part_attr = ext_csd[EXT_CSD_PARTITIONS_ATTRIBUTE];
> > > @@ -2600,7 +2605,6 @@ static int mmc_startup(struct mmc *mmc)
> > >  #if CONFIG_IS_ENABLED(MMC_WRITE)
> > >         mmc->erase_grp_size = 1;
> > >  #endif
> > > -       mmc->part_config = MMCPART_NOAVAILABLE;
> > >
> > >         err = mmc_startup_v4(mmc);
> > >         if (err)
> > > @@ -2848,9 +2852,21 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet)
> > >                 return err;
> > >         mmc->ddr_mode = 0;
> > >
> > > +       mmc->part_config = MMCPART_NOAVAILABLE;
> > > +
> > >  retry:
> > >         mmc_set_initial_state(mmc);
> > >
> > > +       if (mmc->part_config == MMCPART_NOAVAILABLE &&
> > > +           !IS_SD(mmc) && mmc->version >= MMC_VERSION_4) {
> >
> > mmc->version == 0 at this point, so the if is always false. I removed
> > that part of the test to get the results below.
>
> Yea, I see. IS_SD is defined based on mmc->version and mmc->version at
> this stage is not available. So call mmc_send_ext_csd() unconditionally.
>
> > > +               ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
> > > +               err = mmc_send_ext_csd(mmc, ext_csd);
> > > +               if (err == 0 &&
> > > +                   ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
> > > +                    ext_csd[EXT_CSD_BOOT_MULT]))
> > > +                       mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK;
> >
> > With zeroed first boot area and partconf 0 0 2 2, after this line I see:
> > ext_csd[EXT_CSD_PART_CONF] == 18
> > mmc->part_config == 2
>
> That it correct.
>
> > > +       }
> > > +
> > >         /* Reset the Card */
> > >         err = mmc_go_idle(mmc);
> > >
> >
> > After the emmc logic in mmc_startup_v4, mmc->part_config == 18. To
> > test if we can use it to choose a partition, I set mmc partconf 0 0 1
> > 1 and added the patch below (proof of concept only; don't merge!). SPL
> > loads from the second boot area since the first is zeroed, and chooses
> > the second boot area as the boot part successfully.
>
> Perfect!
>
> So I think we have a solution. I will prepare v2 patch series.
>
> But could you test if fallback via BootROM booting is also working?
>
> There is issue with that 5 minutes delay. But I think it should be fixed
> by the patch which I sent earlier, which restore partition config based
> on mmc->part_config in board_return_to_bootrom(). Could you test it?
> https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
> Now when mmc->part_config is correctly initialized it should restore
> configuration and BootROM does not have to get that "Timeout waiting
> card ready" error.

Still takes about 5 minutes. The output is below with MMC tracing. I
confirmed the value of mmc->part_config used for
restore_emmc_boot_part_config is the same as what is initially
detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
zeroed boot0).

ERROR: Invalid kwbimage v1
mmc_load_image_raw_sector: mmc block read error
spl: mmc: wrong boot mode
Trying to boot from BOOTROM
CMD_SEND:6
        ARG             0x03b30a00
        MMC_RSP_R1b         0x00000900
CMD_SEND:13
        ARG             0x00010000
        MMC_RSP_R1,5,6,7      0x00000900
CURR STATE:4
Returning to BootROM (return address 0xffff05c4)...

> > index 0087fea7db..0ebe9985c5 100644
> > --- a/board/solidrun/clearfog/clearfog.c
> > +++ b/board/solidrun/clearfog/clearfog.c
> > @@ -263,6 +263,15 @@ int board_late_init(void)
> >         return 0;
> >  }
> >
> > +int spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > +{
> > +       int part;
> > +       part = mmc->part_config % 8;
> > +       if (part == 7)
> > +               part = 0;
>
> Low 3 bits encodes partition access and spl_mmc_emmc_boot_partition()
> should return partition access. So code has to be without 7 to 0
> conversion.
>
> Conversion is needed when reading boot partition number where 0 means
> boot disabled; 1 means boot 1 part; 2 means boot 2 part; 3-6 means
> reserved and 7 means user area for boot.
>
> So it should be just:
>
>   int spl_mmc_emmc_boot_partition(struct mmc *mmc) {
>     return EXT_CSD_EXTRACT_PARTITION_ACCESS(mmc->part_config);
>   }
>
> > +       return part;
> > +}
> > +
> >  static bool has_emmc(void)
> >  {
> >         struct mmc *mmc;

A38x BootROM MMC_CMD_SEND_STATUS timeouts (Was: Re: [PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot)

[Pali Rohár]

CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with
this issue? Expected usage is following: BootROM reads and execute SPL
from eMMC (BootROM has its own code for reading eMMC), SPL initialize
mmc driver and after SPL finish its work it returns control back to
BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue
is that after SPL returns control back to BootROM it looks like that
BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts
(timeout takes 5 minutes!) and after it correctly reads proper U-Boot
from eMMC and continues booting proper U-Boot. I guess that there is an
issue that SPL's mmc driver changes eMMC state into something which
BootROM does not expect.

On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
> On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
> > There is issue with that 5 minutes delay. But I think it should be fixed
> > by the patch which I sent earlier, which restore partition config based
> > on mmc->part_config in board_return_to_bootrom(). Could you test it?
> > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
> > Now when mmc->part_config is correctly initialized it should restore
> > configuration and BootROM does not have to get that "Timeout waiting
> > card ready" error.
> 
> Still takes about 5 minutes. The output is below with MMC tracing. I
> confirmed the value of mmc->part_config used for
> restore_emmc_boot_part_config is the same as what is initially
> detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
> zeroed boot0).
> 
> ERROR: Invalid kwbimage v1
> mmc_load_image_raw_sector: mmc block read error
> spl: mmc: wrong boot mode
> Trying to boot from BOOTROM
> CMD_SEND:6
>         ARG             0x03b30a00
>         MMC_RSP_R1b         0x00000900
> CMD_SEND:13
>         ARG             0x00010000
>         MMC_RSP_R1,5,6,7      0x00000900
> CURR STATE:4
> Returning to BootROM (return address 0xffff05c4)...

I looked at the BootROM disassembled code and error message
"Timeout waiting card ready" is printed when following mmc command
cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.

0xd is in U-Boot MMC_CMD_SEND_STATUS

0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY
which looks like U-Boot's MMC_RSP_R2 with BUSY bit set

It looks like U-Boot function mmc_send_status() where that "something"
in cmdarg is mmc->rca.

If command does not timeout then BootROM next checks if response has
BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are
truth then BootROM mark call as successful.

If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints
"Status Error: " with hex response value and mark call as unsuccessful.

I'm looking at the U-Boot code and this BootROM logic looks very similar
to U-Boot function mmc_poll_for_busy(), just without first call
mmc_wait_dat0().

BIT(8) is MMC_STATUS_RDY_FOR_DATA
0x1e00 is MMC_STATUS_CURR_STATE
0xe00 is MMC_STATE_PRG
0xfdf94080 is MMC_STATUS_MASK

I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing
in BootROM after U-Boot returns control back to the BootROM.

Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Pali Rohár]

Can anybody help with this?

On Saturday 25 March 2023 13:25:06 Pali Rohár wrote:
> CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with
> this issue? Expected usage is following: BootROM reads and execute SPL
> from eMMC (BootROM has its own code for reading eMMC), SPL initialize
> mmc driver and after SPL finish its work it returns control back to
> BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue
> is that after SPL returns control back to BootROM it looks like that
> BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts
> (timeout takes 5 minutes!) and after it correctly reads proper U-Boot
> from eMMC and continues booting proper U-Boot. I guess that there is an
> issue that SPL's mmc driver changes eMMC state into something which
> BootROM does not expect.
> 
> On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
> > On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
> > > There is issue with that 5 minutes delay. But I think it should be fixed
> > > by the patch which I sent earlier, which restore partition config based
> > > on mmc->part_config in board_return_to_bootrom(). Could you test it?
> > > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
> > > Now when mmc->part_config is correctly initialized it should restore
> > > configuration and BootROM does not have to get that "Timeout waiting
> > > card ready" error.
> > 
> > Still takes about 5 minutes. The output is below with MMC tracing. I
> > confirmed the value of mmc->part_config used for
> > restore_emmc_boot_part_config is the same as what is initially
> > detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
> > zeroed boot0).
> > 
> > ERROR: Invalid kwbimage v1
> > mmc_load_image_raw_sector: mmc block read error
> > spl: mmc: wrong boot mode
> > Trying to boot from BOOTROM
> > CMD_SEND:6
> >         ARG             0x03b30a00
> >         MMC_RSP_R1b         0x00000900
> > CMD_SEND:13
> >         ARG             0x00010000
> >         MMC_RSP_R1,5,6,7      0x00000900
> > CURR STATE:4
> > Returning to BootROM (return address 0xffff05c4)...
> 
> I looked at the BootROM disassembled code and error message
> "Timeout waiting card ready" is printed when following mmc command
> cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.
> 
> 0xd is in U-Boot MMC_CMD_SEND_STATUS
> 
> 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY
> which looks like U-Boot's MMC_RSP_R2 with BUSY bit set
> 
> It looks like U-Boot function mmc_send_status() where that "something"
> in cmdarg is mmc->rca.
> 
> If command does not timeout then BootROM next checks if response has
> BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are
> truth then BootROM mark call as successful.
> 
> If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints
> "Status Error: " with hex response value and mark call as unsuccessful.
> 
> I'm looking at the U-Boot code and this BootROM logic looks very similar
> to U-Boot function mmc_poll_for_busy(), just without first call
> mmc_wait_dat0().
> 
> BIT(8) is MMC_STATUS_RDY_FOR_DATA
> 0x1e00 is MMC_STATUS_CURR_STATE
> 0xe00 is MMC_STATE_PRG
> 0xfdf94080 is MMC_STATUS_MASK
> 
> I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing
> in BootROM after U-Boot returns control back to the BootROM.

Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Pali Rohár]

PING?

On Saturday 01 April 2023 18:43:45 Pali Rohár wrote:
> Can anybody help with this?
> 
> On Saturday 25 March 2023 13:25:06 Pali Rohár wrote:
> > CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with
> > this issue? Expected usage is following: BootROM reads and execute SPL
> > from eMMC (BootROM has its own code for reading eMMC), SPL initialize
> > mmc driver and after SPL finish its work it returns control back to
> > BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue
> > is that after SPL returns control back to BootROM it looks like that
> > BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts
> > (timeout takes 5 minutes!) and after it correctly reads proper U-Boot
> > from eMMC and continues booting proper U-Boot. I guess that there is an
> > issue that SPL's mmc driver changes eMMC state into something which
> > BootROM does not expect.
> > 
> > On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
> > > On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
> > > > There is issue with that 5 minutes delay. But I think it should be fixed
> > > > by the patch which I sent earlier, which restore partition config based
> > > > on mmc->part_config in board_return_to_bootrom(). Could you test it?
> > > > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
> > > > Now when mmc->part_config is correctly initialized it should restore
> > > > configuration and BootROM does not have to get that "Timeout waiting
> > > > card ready" error.
> > > 
> > > Still takes about 5 minutes. The output is below with MMC tracing. I
> > > confirmed the value of mmc->part_config used for
> > > restore_emmc_boot_part_config is the same as what is initially
> > > detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
> > > zeroed boot0).
> > > 
> > > ERROR: Invalid kwbimage v1
> > > mmc_load_image_raw_sector: mmc block read error
> > > spl: mmc: wrong boot mode
> > > Trying to boot from BOOTROM
> > > CMD_SEND:6
> > >         ARG             0x03b30a00
> > >         MMC_RSP_R1b         0x00000900
> > > CMD_SEND:13
> > >         ARG             0x00010000
> > >         MMC_RSP_R1,5,6,7      0x00000900
> > > CURR STATE:4
> > > Returning to BootROM (return address 0xffff05c4)...
> > 
> > I looked at the BootROM disassembled code and error message
> > "Timeout waiting card ready" is printed when following mmc command
> > cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.
> > 
> > 0xd is in U-Boot MMC_CMD_SEND_STATUS
> > 
> > 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY
> > which looks like U-Boot's MMC_RSP_R2 with BUSY bit set
> > 
> > It looks like U-Boot function mmc_send_status() where that "something"
> > in cmdarg is mmc->rca.
> > 
> > If command does not timeout then BootROM next checks if response has
> > BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are
> > truth then BootROM mark call as successful.
> > 
> > If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints
> > "Status Error: " with hex response value and mark call as unsuccessful.
> > 
> > I'm looking at the U-Boot code and this BootROM logic looks very similar
> > to U-Boot function mmc_poll_for_busy(), just without first call
> > mmc_wait_dat0().
> > 
> > BIT(8) is MMC_STATUS_RDY_FOR_DATA
> > 0x1e00 is MMC_STATUS_CURR_STATE
> > 0xe00 is MMC_STATE_PRG
> > 0xfdf94080 is MMC_STATUS_MASK
> > 
> > I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing
> > in BootROM after U-Boot returns control back to the BootROM.

Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Peng Fan]

On 4/2/2023 12:43 AM, Pali Rohár wrote:
> Can anybody help with this?

I expected Jaehoon would say some words.

> 
> On Saturday 25 March 2023 13:25:06 Pali Rohár wrote:
>> CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with
>> this issue? Expected usage is following: BootROM reads and execute SPL
>> from eMMC (BootROM has its own code for reading eMMC), SPL initialize
>> mmc driver and after SPL finish its work it returns control back to
>> BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue
>> is that after SPL returns control back to BootROM it looks like that
>> BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts
>> (timeout takes 5 minutes!) and after it correctly reads proper U-Boot
>> from eMMC and continues booting proper U-Boot. I guess that there is an
>> issue that SPL's mmc driver changes eMMC state into something which
>> BootROM does not expect.

A general question is since BootROM will still using eMMC, why let
SPL to initialize eMMC? SPL's configuration may not match ROM's expection.

For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask
ROM help loading images, and SPL not touch relevant USB/EMMC.

Regards,
Peng.

>>
>> On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
>>> On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
>>>> There is issue with that 5 minutes delay. But I think it should be fixed
>>>> by the patch which I sent earlier, which restore partition config based
>>>> on mmc->part_config in board_return_to_bootrom(). Could you test it?
>>>> https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
>>>> Now when mmc->part_config is correctly initialized it should restore
>>>> configuration and BootROM does not have to get that "Timeout waiting
>>>> card ready" error.
>>>
>>> Still takes about 5 minutes. The output is below with MMC tracing. I
>>> confirmed the value of mmc->part_config used for
>>> restore_emmc_boot_part_config is the same as what is initially
>>> detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
>>> zeroed boot0).
>>>
>>> ERROR: Invalid kwbimage v1
>>> mmc_load_image_raw_sector: mmc block read error
>>> spl: mmc: wrong boot mode
>>> Trying to boot from BOOTROM
>>> CMD_SEND:6
>>>          ARG             0x03b30a00
>>>          MMC_RSP_R1b         0x00000900
>>> CMD_SEND:13
>>>          ARG             0x00010000
>>>          MMC_RSP_R1,5,6,7      0x00000900
>>> CURR STATE:4
>>> Returning to BootROM (return address 0xffff05c4)...
>>
>> I looked at the BootROM disassembled code and error message
>> "Timeout waiting card ready" is printed when following mmc command
>> cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.
>>
>> 0xd is in U-Boot MMC_CMD_SEND_STATUS
>>
>> 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY
>> which looks like U-Boot's MMC_RSP_R2 with BUSY bit set
>>
>> It looks like U-Boot function mmc_send_status() where that "something"
>> in cmdarg is mmc->rca.
>>
>> If command does not timeout then BootROM next checks if response has
>> BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are
>> truth then BootROM mark call as successful.
>>
>> If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints
>> "Status Error: " with hex response value and mark call as unsuccessful.
>>
>> I'm looking at the U-Boot code and this BootROM logic looks very similar
>> to U-Boot function mmc_poll_for_busy(), just without first call
>> mmc_wait_dat0().
>>
>> BIT(8) is MMC_STATUS_RDY_FOR_DATA
>> 0x1e00 is MMC_STATUS_CURR_STATE
>> 0xe00 is MMC_STATE_PRG
>> 0xfdf94080 is MMC_STATUS_MASK
>>
>> I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing
>> in BootROM after U-Boot returns control back to the BootROM.

Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Pali Rohár]

On Friday 28 April 2023 15:39:20 Peng Fan wrote:
> On 4/2/2023 12:43 AM, Pali Rohár wrote:
> > Can anybody help with this?
> 
> I expected Jaehoon would say some words.
> 
> > 
> > On Saturday 25 March 2023 13:25:06 Pali Rohár wrote:
> > > CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with
> > > this issue? Expected usage is following: BootROM reads and execute SPL
> > > from eMMC (BootROM has its own code for reading eMMC), SPL initialize
> > > mmc driver and after SPL finish its work it returns control back to
> > > BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue
> > > is that after SPL returns control back to BootROM it looks like that
> > > BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts
> > > (timeout takes 5 minutes!) and after it correctly reads proper U-Boot
> > > from eMMC and continues booting proper U-Boot. I guess that there is an
> > > issue that SPL's mmc driver changes eMMC state into something which
> > > BootROM does not expect.
> 
> A general question is since BootROM will still using eMMC, why let
> SPL to initialize eMMC? SPL's configuration may not match ROM's expection.

Requirement is ENV access which is stored on eMMC too and without
initializing SPL eMMC driver, SPL cannot access ENV.

Another thing is that loading proper U-Boot via SPL eMMC driver is
sometimes faster than via BootROM eMMC code. I guess this is BootROM
does not full speed.

Also another fact is that SPL on mvebu works in this "hybrid" mode
(initialize and access boot device; plus let BootROM to use it) for all
other bootable storages.

> For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask
> ROM help loading images, and SPL not touch relevant USB/EMMC.

Unfortunately there is no BootROM API for these processors. All issues
which are being resolved in this (and also other) discussions are done
by inspecting BootROM code and trying to understand how it behaves and
how it choose the eMMC boot partition. As this stuff has poor
documentation and even this documentation has documented erratas... So
nobody knows what exactly is and what not supported.

What we need to do is to write mvebu specific SPL code which is
compatible with BootROM.

> Regards,
> Peng.
> 
> > > 
> > > On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
> > > > On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
> > > > > There is issue with that 5 minutes delay. But I think it should be fixed
> > > > > by the patch which I sent earlier, which restore partition config based
> > > > > on mmc->part_config in board_return_to_bootrom(). Could you test it?
> > > > > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
> > > > > Now when mmc->part_config is correctly initialized it should restore
> > > > > configuration and BootROM does not have to get that "Timeout waiting
> > > > > card ready" error.
> > > > 
> > > > Still takes about 5 minutes. The output is below with MMC tracing. I
> > > > confirmed the value of mmc->part_config used for
> > > > restore_emmc_boot_part_config is the same as what is initially
> > > > detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
> > > > zeroed boot0).
> > > > 
> > > > ERROR: Invalid kwbimage v1
> > > > mmc_load_image_raw_sector: mmc block read error
> > > > spl: mmc: wrong boot mode
> > > > Trying to boot from BOOTROM
> > > > CMD_SEND:6
> > > >          ARG             0x03b30a00
> > > >          MMC_RSP_R1b         0x00000900
> > > > CMD_SEND:13
> > > >          ARG             0x00010000
> > > >          MMC_RSP_R1,5,6,7      0x00000900
> > > > CURR STATE:4
> > > > Returning to BootROM (return address 0xffff05c4)...
> > > 
> > > I looked at the BootROM disassembled code and error message
> > > "Timeout waiting card ready" is printed when following mmc command
> > > cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.
> > > 
> > > 0xd is in U-Boot MMC_CMD_SEND_STATUS
> > > 
> > > 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY
> > > which looks like U-Boot's MMC_RSP_R2 with BUSY bit set
> > > 
> > > It looks like U-Boot function mmc_send_status() where that "something"
> > > in cmdarg is mmc->rca.
> > > 
> > > If command does not timeout then BootROM next checks if response has
> > > BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are
> > > truth then BootROM mark call as successful.
> > > 
> > > If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints
> > > "Status Error: " with hex response value and mark call as unsuccessful.
> > > 
> > > I'm looking at the U-Boot code and this BootROM logic looks very similar
> > > to U-Boot function mmc_poll_for_busy(), just without first call
> > > mmc_wait_dat0().
> > > 
> > > BIT(8) is MMC_STATUS_RDY_FOR_DATA
> > > 0x1e00 is MMC_STATUS_CURR_STATE
> > > 0xe00 is MMC_STATE_PRG
> > > 0xfdf94080 is MMC_STATUS_MASK
> > > 
> > > I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing
> > > in BootROM after U-Boot returns control back to the BootROM.

Re: A38x BootROM MMC_CMD_SEND_STATUS timeouts

[Pali Rohár]

On Friday 28 April 2023 10:30:08 Pali Rohár wrote:
> On Friday 28 April 2023 15:39:20 Peng Fan wrote:
> > On 4/2/2023 12:43 AM, Pali Rohár wrote:
> > > Can anybody help with this?
> > 
> > I expected Jaehoon would say some words.

Just a reminder...

> > 
> > > 
> > > On Saturday 25 March 2023 13:25:06 Pali Rohár wrote:
> > > > CCing MMC maintainers (Peng Fan & Jaehoon Chung). Could you help us with
> > > > this issue? Expected usage is following: BootROM reads and execute SPL
> > > > from eMMC (BootROM has its own code for reading eMMC), SPL initialize
> > > > mmc driver and after SPL finish its work it returns control back to
> > > > BootROM and BootROM reads and execute proper U-Boot from eMMC. And issue
> > > > is that after SPL returns control back to BootROM it looks like that
> > > > BootROM is sending MMC_CMD_SEND_STATUS command to eMMC but it timeouts
> > > > (timeout takes 5 minutes!) and after it correctly reads proper U-Boot
> > > > from eMMC and continues booting proper U-Boot. I guess that there is an
> > > > issue that SPL's mmc driver changes eMMC state into something which
> > > > BootROM does not expect.
> > 
> > A general question is since BootROM will still using eMMC, why let
> > SPL to initialize eMMC? SPL's configuration may not match ROM's expection.
> 
> Requirement is ENV access which is stored on eMMC too and without
> initializing SPL eMMC driver, SPL cannot access ENV.
> 
> Another thing is that loading proper U-Boot via SPL eMMC driver is
> sometimes faster than via BootROM eMMC code. I guess this is BootROM
> does not full speed.
> 
> Also another fact is that SPL on mvebu works in this "hybrid" mode
> (initialize and access boot device; plus let BootROM to use it) for all
> other bootable storages.
> 
> > For example i.MX, there is ROM API, SPL use ROM API to ask ROM to ask
> > ROM help loading images, and SPL not touch relevant USB/EMMC.
> 
> Unfortunately there is no BootROM API for these processors. All issues
> which are being resolved in this (and also other) discussions are done
> by inspecting BootROM code and trying to understand how it behaves and
> how it choose the eMMC boot partition. As this stuff has poor
> documentation and even this documentation has documented erratas... So
> nobody knows what exactly is and what not supported.
> 
> What we need to do is to write mvebu specific SPL code which is
> compatible with BootROM.
> 
> > Regards,
> > Peng.
> > 
> > > > 
> > > > On Friday 24 March 2023 02:55:55 Martin Rowe wrote:
> > > > > On Thu, 23 Mar 2023 at 19:01, Pali Rohár <pali@kernel.org> wrote:
> > > > > > There is issue with that 5 minutes delay. But I think it should be fixed
> > > > > > by the patch which I sent earlier, which restore partition config based
> > > > > > on mmc->part_config in board_return_to_bootrom(). Could you test it?
> > > > > > https://lore.kernel.org/u-boot/20230305160416.xc7wlzmkaociwcf7@pali/
> > > > > > Now when mmc->part_config is correctly initialized it should restore
> > > > > > configuration and BootROM does not have to get that "Timeout waiting
> > > > > > card ready" error.
> > > > > 
> > > > > Still takes about 5 minutes. The output is below with MMC tracing. I
> > > > > confirmed the value of mmc->part_config used for
> > > > > restore_emmc_boot_part_config is the same as what is initially
> > > > > detected early in SPL (both are 10 with mmc partconf 0 0 1 1 and
> > > > > zeroed boot0).
> > > > > 
> > > > > ERROR: Invalid kwbimage v1
> > > > > mmc_load_image_raw_sector: mmc block read error
> > > > > spl: mmc: wrong boot mode
> > > > > Trying to boot from BOOTROM
> > > > > CMD_SEND:6
> > > > >          ARG             0x03b30a00
> > > > >          MMC_RSP_R1b         0x00000900
> > > > > CMD_SEND:13
> > > > >          ARG             0x00010000
> > > > >          MMC_RSP_R1,5,6,7      0x00000900
> > > > > CURR STATE:4
> > > > > Returning to BootROM (return address 0xffff05c4)...
> > > > 
> > > > I looked at the BootROM disassembled code and error message
> > > > "Timeout waiting card ready" is printed when following mmc command
> > > > cmdidx=0xd, resptype=0x15, cmdarg=(something)<<0x10 timeouts.
> > > > 
> > > > 0xd is in U-Boot MMC_CMD_SEND_STATUS
> > > > 
> > > > 0x15 is in U-Boot MMC_RSP_PRESENT|MMC_RSP_136|MMC_RSP_CRC|MMC_RSP_BUSY
> > > > which looks like U-Boot's MMC_RSP_R2 with BUSY bit set
> > > > 
> > > > It looks like U-Boot function mmc_send_status() where that "something"
> > > > in cmdarg is mmc->rca.
> > > > 
> > > > If command does not timeout then BootROM next checks if response has
> > > > BIT(8) set and if response mask 0x1e00 matches value 0xe00. If both are
> > > > truth then BootROM mark call as successful.
> > > > 
> > > > If response ANDed with mask 0xfdf94080 is non-zero then BootROM prints
> > > > "Status Error: " with hex response value and mark call as unsuccessful.
> > > > 
> > > > I'm looking at the U-Boot code and this BootROM logic looks very similar
> > > > to U-Boot function mmc_poll_for_busy(), just without first call
> > > > mmc_wait_dat0().
> > > > 
> > > > BIT(8) is MMC_STATUS_RDY_FOR_DATA
> > > > 0x1e00 is MMC_STATUS_CURR_STATE
> > > > 0xe00 is MMC_STATE_PRG
> > > > 0xfdf94080 is MMC_STATUS_MASK
> > > > 
> > > > I'm not mmc expert, but this looks like MMC_CMD_SEND_STATUS is failing
> > > > in BootROM after U-Boot returns control back to the BootROM.