u-boot on custom board will not use boot_device=mmc

MScho.6 · ‎2021-03-04

We have a custom board based on the stm32mp151 that shall boot from emmc. I can flash alright, but when I switch the boot pins, the boot device remains on usb. I can see from arch/arm/mach-stm32mp/cpu.c, that boot_device is set to usb, here is the debug line:

setup_boot_mode: boot_ctx=0x2203 => boot_mode=22, instance=1 forced=3

when I break into u-boot, and manually set boot_device to mmc, it works. Also, it does not seem to pick up the default environment:

CPU: STM32MP151CAC Rev.Z
Model: STMicroelectronics custom STM32CubeMX board
Board: stm32mp1 in trusted mode (st,stm32mp151c-0068-new-linux-mx)
DRAM:  128 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
STM32Programmer key pressed, entering download mode...
WDT:   Not found!
NAND:  0 MiB
MMC:   STM32 SD/MMC: 0
Loading Environment from MMC... MMC Device 1 not found
*** Warning - No MMC card found, using default environment
 
In:    serial@40010000
Out:   serial@40010000
Err:   serial@40010000
setup_boot_mode: boot_ctx=0x2203 => boot_mode=22, instance=1 forced=3
invalid MAC address in OTP 00:00:00:00:00:00
Net:   No ethernet found.
Hit any key to stop autoboot:  0 
STM32MP> printenv boot_device
boot_device=usb
STM32MP> setenv boot_device mmc
STM32MP> env save
Saving Environment to MMC... MMC Device 1 not found
No MMC card found
Failed (1)
STM32MP> run bootcmd
Boot over mmc0!
Saving Environment to MMC... MMC Device 1 not found
No MMC card found
Failed (1)
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:2...
Found U-Boot script /boot.scr.uimg
2943 bytes read in 4 ms (717.8 KiB/s)
## Executing script at c4100000

The boot continues fine from there

MScho.6 · ‎2021-03-05

Hi @Lukas Brückner

thanks, I was able to "fix" the problem with this patch:

--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -483,9 +483,12 @@ static void setup_boot_mode(void)
 		break;
 	case BOOT_FLASH_SD:
 	case BOOT_FLASH_EMMC:
+	case BOOT_FLASH_EMMC_1:
+	case BOOT_FLASH_EMMC_2:
+	case BOOT_FLASH_EMMC_3:
 		sprintf(cmd, "%d", instance);
 		env_set("boot_device", "mmc");
-		env_set("boot_instance", cmd);
+		env_set("boot_instance", "0"); /* hard forcing this to 0 */
 		break;
 	case BOOT_FLASH_NAND:
 		env_set("boot_device", "nand");
 
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -968,9 +968,8 @@ const char *env_ext4_get_dev_part(void)
 #if defined(CONFIG_ENV_IS_IN_MMC)
 int mmc_get_env_dev(void)
 {
-	u32 bootmode = get_bootmode();
-
-	return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1;
+  /* Hard forcing this to 0 for 0068 */
+	return 0;
 }
 #endif

Since the device is coming from tamp and not device tree, this seems to be the only solution :(

View solution in original post

Fee · ‎2021-03-05

Hi,

not quite discussing the problem you have, but I can see that your uboot environments are not set properly. It might hint why your uboot is using the different boot source. The bootpins just configure the boot ROM , which runs fine due to the fact you being able to boot up to uboot.

The environment problems are is discussed in this post:

https://community.st.com/s/question/0D53W00000U9kuYSAR/mmc-device-0-not-found

MScho.6 · ‎2021-03-05

Hi @Lukas Brückner

thanks, I was able to "fix" the problem with this patch:

--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -483,9 +483,12 @@ static void setup_boot_mode(void)
 		break;
 	case BOOT_FLASH_SD:
 	case BOOT_FLASH_EMMC:
+	case BOOT_FLASH_EMMC_1:
+	case BOOT_FLASH_EMMC_2:
+	case BOOT_FLASH_EMMC_3:
 		sprintf(cmd, "%d", instance);
 		env_set("boot_device", "mmc");
-		env_set("boot_instance", cmd);
+		env_set("boot_instance", "0"); /* hard forcing this to 0 */
 		break;
 	case BOOT_FLASH_NAND:
 		env_set("boot_device", "nand");
 
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -968,9 +968,8 @@ const char *env_ext4_get_dev_part(void)
 #if defined(CONFIG_ENV_IS_IN_MMC)
 int mmc_get_env_dev(void)
 {
-	u32 bootmode = get_bootmode();
-
-	return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1;
+  /* Hard forcing this to 0 for 0068 */
+	return 0;
 }
 #endif

Since the device is coming from tamp and not device tree, this seems to be the only solution :(

PatrickD · ‎2021-03-08

Hi,

The 'boot_instance' variable is expected to be the SD/MCC instance, identified in ROM code by BOOT PIN selection and by OTP value (provided to TF-A copied in backup TAMP register)

https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Boot_interface_selection

The mapping instance SD/MCC instance 'mmc' sequence number in U-Boot is forced in board device tree with alias for ST Microlectronics board

./arch/arm/dts/stm32mp157a-ed1-u-boot.dtsi:

aliases {

i2c3 = &i2c4;

mmc0 = &sdmmc1;

mmc1 = &sdmmc2;

};

I propose at upstream (it will be also include in the next OpenSTlinux delivery)

to force the mmc_get_env_dev return value with defconfig (without patching code)

http://patchwork.ozlabs.org/project/uboot/patch/20210301131752.1.I8cbd6f92056fa2d10bf3880746d89ee0779f8e27%3E@changeid/

PS: boot.scr.uimg shoudle be not used in real product: rename mmc0_extlinux directory in bootfs to the correct name for U-Boot generic DISTRO support = extlinux

/bootfs/mmc0_extlinux/extlinux.conf

=>

/bootfs/extlinux/extlinux.conf

Anyway the 'boot_instance' is still invalid (I need to think about this issue, the mapping between U-Boot sequence number and IP instance number)

but this variable is only used in stm32_bootcmd and in this script boot.scr.uimg

1/ this command bootcmd can (should ?) be overidded to a simple boocmd on your product.

CONFIG_BOOTCOMMAND=

"if test ${boot_device} = usb; then stm32prog ${boot_device} ${boot_instance}; " \

"else run bootcmd_mmc0; endif;"

2/ boot.scr.uimg => it is also used for STMicrolectronics to generate a unique "bootfs" for all the boot device / it is not manadatory for the customer and not recommanded by me as executing a script is a security breach for real product.

Regards

Patrick

MScho.6 · ‎2021-03-08

Hi Patrick,

thank you for you answer. We do not include the stm32mp157a-ed1-u-boot.dtsi in our device tree (we have a stm32mp151c anyway) and our alias is set to sdmmc2, since we use sdmmc2 for emmc. Also we did not touch OTP Word 3, so it should be 0 and therefore use sdmmc2, not sdmmc3.

As in https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#OTP_WORD_3

Regarding the bootcmd_stm32mp: I tried to keep the changeset as minimal as possible, also I do not want to break the flash via usb feature. When I forced the bootcmd to boot from emmc (which was my first approach), I had the trouble that when programming with stm32programmer, it would not flash via usb but directly boot from emmc (that is, tf-a & u-boot from serial, then when reconnecting, it directly bootet the kernel instead of flashing emmc).

Thanks and Regards,

Matthias

PatrickD · ‎2021-04-06

For information,

I update the index support and the instance value in the upstreamed serie = stm32mp: stm32prog: Add Kconfig file for stm32prog command

=> [4/4] stm32mp: stm32prog: replace alias by serial device sequence number - Patchwork (ozlabs.org)

Now the boot_instance is change to "dev_seq(dev)" => that handle the case wihout mmc alias

yhispatch is also integrated in the release for OpenSTLinux v3.0 => U-Boot release v2020.10-stm32mp-r1

but with boot_instance = dev->seq

This udpate should solve your issue, when only SDMMC2 available in device tree = mmc0 in U-Boot (no alias) => now boot_instance = 0.

Patrick