OSD32MP157 board stuck in DFU mode after successful flashing

[Farid Azhar]

We are having a problem flashing our new batch of boards based on OSD32MP157F using eMMC to boot.

Most of the boards flash and boot successfully but some boards remain in DFU mode after flashing completed successfully and does not reboot from eMMC.

I verified via UBoot all partitions are created and populated, this confirms eMMC is not empty/virgin.

I flashed with STM32CubeProgrammer v2.18.0 on Windows 11.

Power signal across the BOOT Switch appears to be OK for eMMC boot (010).

I read the OTP registers using UBoot fuse command and find that OTP3/CFG3 word is zero for all the working OK and DFU stuck devices. This confirms no change in OTP3/CFG3 registers.

Any help resolving this problem is much appreciated.

Thanks,

/Farid

[Neeraj Kumar Reddy Dantu]

Farid,

Can you post the boot logs related to the flashing of the eMMC(UART output when flashing is initiated in DFU mode).

From the information you provided, it looks like the interface between OSD32MP1 and eMMC is functional.

As you are able to get to u-boot, the first thing to check is whether the boot mode is correct. If you execute “md.l 0x50020000 1” in u-boot command line, it should tell you what the device thinks the boot mode configuration is(See SYSCFG_BOOTR register description in the Technical Reference Manual – RM0436).

As you have access to u-boot command line, you can run the command “run distro_bootcmd” to see if the board can use the eMMC to boot the rest of the way. If eMMC is flashed correctly for boot and rootfs partitions, it should boot to Linux command line with eMMC rootfile system.

It eMMC is programmed and the board boots correctly after executing distro_bootcmd, there may be an issue is the boot0 and boot1 partitions of the eMMC. Booting from eMMC depends on FSBL being programmed into mmcblk2boot0 and mmcblk2boot1 partitions of eMMC that are apart from the main eMMC partitions. These are marked read only by default, but needed for eMMC boot.

Once you are are in Linux command line, you can program the boot0 and boot1 partitions like shown here: https://octavosystems.com/forums/topic/cloning-emmc-2/.

Best,
Neeraj

[Farid Azhar]

Hi Neeraj,

Thanks for looking into this. I re-flashed the board to capture debug logs, reboot and run following u-boot commands

STM32MP> mmc list

STM32MP> mmc dev 0

STM32MP> mmc dev 1

STM32MP> mmc part

STM32MP> md.l 0x50020000 1

STM32MP> run distro_bootcmd

“mmc part” command confirms all eMMC partitions are created and populated.

“md.l 0x50020000” command confirms boards is in DFU mode (SYSCFG_BOOTR = 0)

“run distro_bootcmd” command confirms board can boot to Linux from eMMC but turns to DFU mode after first reboot.

How do I verify if there an issue with the boot0 and boot1 partitions of the eMMC

Pl see attached logs.

/Farid

[Farid Azhar]

uploading STMCubeProg_Debug_logs.txt

[Farid Azhar]

Don’t know why log file upload is keep failing. Here are the u-boot commands run …

STM32MP> mmc list

STM32 SD/MMC: 0

STM32 SD/MMC: 1

STM32MP>

STM32MP> mmc dev 0

Card did not respond to voltage select!

STM32MP>

STM32MP> mmc dev 1

switch to partitions #0, OK

mmc1(part 0) is current device

STM32MP>

STM32MP> mmc part

Partition Map for MMC device 1  —   Partition Type: EFI

Part    Start LBA       End LBA         Name

Attributes

Type GUID

Partition GUID

1     0x00000400      0x000013ff      “fip”

attrs:  0x0000000000000000

type:   8da63339-0007-60c0-c436-083ac8230908

guid:   4bd0e518-9dc6-40ff-8cbc-c113e0f25daf

2     0x00001400      0x000213ff      “boot”

attrs:  0x0000000000000004

type:   0fc63daf-8483-4772-8e79-3d69d8477de4

type:   linux

guid:   1887a72d-fade-4975-9986-d18e5cc2557f

3     0x00021400      0x004213ff      “vendorfs”

attrs:  0x0000000000000000

type:   0fc63daf-8483-4772-8e79-3d69d8477de4

type:   linux

guid:   3387689d-749f-4a3c-ae3d-319920e6086d

4     0x00421400      0x01c213ff      “rootfs”

attrs:  0x0000000000000000

type:   0fc63daf-8483-4772-8e79-3d69d8477de4

type:   linux

guid:   491f6117-415d-4f53-88c9-6e0de54deac6

5     0x01c21400      0x026213ff      “r******”

attrs:  0x0000000000000000

type:   0fc63daf-8483-4772-8e79-3d69d8477de4

type:   linux

guid:   af1dc67d-56f0-4770-909d-a34fd4e939bd

6     0x02621400      0x06a213ff      “s******”

attrs:  0x0000000000000000

type:   0fc63daf-8483-4772-8e79-3d69d8477de4

type:   linux

guid:   0f5cac76-b991-4558-a859-fabe6b42234d

7     0x06a21400      0x0e94bbff      “k*****”

attrs:  0x0000000000000000

type:   0fc63daf-8483-4772-8e79-3d69d8477de4

type:   linux

guid:   57ec6f42-0527-4f43-924e-55527119698b

STM32MP>

STM32MP> md.l 0x50020000 1

50020000: 00000000                               ….

STM32MP>

 

STM32MP> run distro_bootcmd

switch to partitions #0, OK

mmc1(part 0) is current device

Scanning mmc 1:2…

Found U-Boot script /boot.scr.uimg

3639 bytes read in 20 ms (176.8 KiB/s)

## Executing script at c4100000

Executing SCRIPT on target=mmc1

Saving Environment to nowhere… not possible

switch to partitions #0, OK

mmc1(part 0) is current device

Scanning mmc 1:2…

Found /mmc1_extlinux/extlinux.conf

Retrieving file: /mmc1_extlinux/extlinux.conf

355 bytes read in 21 ms (15.6 KiB/s)

Retrieving file: /splash.bmp

170122 bytes read in 25 ms (6.5 MiB/s)

1:      osd32mp1-k**-emmc

Retrieving file: /uImage

8238952 bytes read in 202 ms (38.9 MiB/s)

append: root=/dev/mmcblk1p4 rootwait rw console=ttySTM0,115200 init=/sbin/init firmware_class.path=/lib/firmware/

Retrieving file: /stm32mp157c-osd32mp1-k**.dtb

56672 bytes read in 22 ms (2.5 MiB/s)

## Booting kernel from Legacy Image at c2000000 …

Image Name:   Linux kernel

Created:      2025-04-03   6:13:55 UTC

Image Type:   ARM Linux Kernel Image (uncompressed)

Data Size:    8238888 Bytes = 7.9 MiB

Load Address: c2000040

Entry Point:  c2000040

Verifying Checksum … OK

## Flattened Device Tree blob at c4000000

Booting using the fdt blob at 0xc4000000

XIP Kernel Image

Loading Device Tree to cffef000, end cffffd5f … OK

Starting kernel …

[    0.000000] Booting Linux on physical CPU 0x0

[    0.000000] Linux version 5.10.10 (root@a315680f380d) (arm-linux-gnueabihf-gcc (Debian 8.3.0-2) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP PREEMPT Thu Apr 3 06:11:47 UTC 2025

[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d

:

:

[   39.395712] systemd-shutdown[1]: Syncing filesystems and block devices.

[   39.401242] systemd-shutdown[1]: Rebooting.

[   39.471191] reboot: Restarting system

INFO:    PSCI Power Domain Map:

INFO:      Domain Node : Level 1, parent_node -1, State ON (0x0)

INFO:      Domain Node : Level 0, parent_node 0, State ON (0x0)

INFO:      CPU Node : MPID 0x0, parent_node 0, State ON (0x0)

=> After running first reboot, board turned into DFU mode

 

[Neeraj Kumar Reddy Dantu]

Farid,

The register read for SYBOOT pins “SYSCFG_BOOTR = 0” indicates that the SoC is seeing 000b boot setting instead of 010b for eMMC. This register read is the reading from the SoC of the physical pin setting for BOOT pins. There is something wrong with the way the boot mode is being set. Can you check for shorts?

The boot from eMMC at u-boot shows good eMMC boot. So, eMMC looks like it is programmed. So, once the SoC sees the correct boot settings, it should be able to boot from the eMMC

Best,
Neeraj

[Author]

Posts