[PATCH RFC u-boot-mvebu 0/2] arm: mvebu: Fix eMMC boot
Boot configuration stored in EXT_CSC register is completely ignored by BootROM: https://lore.kernel.org/u-boot/CAOAjy5SYPPzWKok-BSGYwZwcKOQt_aZPgh6FTbrFd3F=...
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(-)
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
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
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=...
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
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=...
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
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=...
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
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=...
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 partitionconfiguration\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 - requiredby 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
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=...
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 partitionconfiguration\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 - requiredby 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
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=...
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 partitionconfiguration\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 - requiredby 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.
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=...
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 partitionconfiguration\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
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.
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
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?
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.
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?
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:
- 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>
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:
- Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
- Issue commands referred to the selected partition
- 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.
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:
- Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
- Issue commands referred to the selected partition
- 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 00CMD_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.
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:
- Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
- Issue commands referred to the selected partition
- 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 00CMD_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);
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:
- Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
- Issue commands referred to the selected partition
- 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 00CMD_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];elsemmc->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;
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:
- Set PARTITION_ACCESS bits in the PARTITION_CONFIG field of the Extended CSD register in order to address one of the partitions
- Issue commands referred to the selected partition
- 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 00CMD_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];elsemmc->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;
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 00CMD_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];elsemmc->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;
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.
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.
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.
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.
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.
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.
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.
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?
- 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.
- 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>
- 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.
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...
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?
- 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?
- 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.
- 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.
participants (3)
-
Martin Rowe -
Pali Rohár -
Peng Fan