different dfu alt info on stm32mp13

xogium commented 11 months ago

I'm not sure if I'm doing something wrong, or this is to be expected or not.

When I use snagrecover to attempt a recovery of the stm32mp13 board I'm working with, the resulting accessible dfu alt info are different than if I was to interrupt u-boot and use the dfu 0 command myself.

hardware

I work on the stm32mp135d-based board from Seeed Studio, stm32mp135d-odyssey. Schematics are available here in case it is important to this issue (I don't believe it is).

software versions

snagboot 1.2
dfu-util 0.11
ATF v2.8-stm32mp-r1 (st)
optee_os 3.19.0-stm32mp-r1 (st)
u-boot 2022.10-stm32mp-r1 (st)

output of dfu-util -l when boot sequence is not interrupted

Found DFU: [0483:df11] ver=0200, devnum=78, cfg=1, intf=0, path="3-3", alt=2, name="@OTP/0xf2/1*776Be", serial="0021001A3232510937393835"
Found DFU: [0483:df11] ver=0200, devnum=78, cfg=1, intf=0, path="3-3", alt=1, name="@virtual/0xf1/1*512Be", serial="0021001A3232510937393835"
Found DFU: [0483:df11] ver=0200, devnum=78, cfg=1, intf=0, path="3-3", alt=0, name="@FlashLayout/0x00/1*256Ke", serial="0021001A3232510937393835"

output of dfu-util -l when boot sequence is interrupted and dfu 0 is ran

Found DFU: [0483:df11] ver=0200, devnum=81, cfg=1, intf=0, path="3-3", alt=4, name="mmc1_boot2", serial="0021001A3232510937393835"
Found DFU: [0483:df11] ver=0200, devnum=81, cfg=1, intf=0, path="3-3", alt=3, name="mmc1_boot1", serial="0021001A3232510937393835"
Found DFU: [0483:df11] ver=0200, devnum=81, cfg=1, intf=0, path="3-3", alt=2, name="uramdisk.image.gz", serial="0021001A3232510937393835"
Found DFU: [0483:df11] ver=0200, devnum=81, cfg=1, intf=0, path="3-3", alt=1, name="devicetree.dtb", serial="0021001A3232510937393835"
Found DFU: [0483:df11] ver=0200, devnum=81, cfg=1, intf=0, path="3-3", alt=0, name="uImage", serial="0021001A3232510937393835"

output of u-boot during uninterrupted boot sequence

In:    serial
Out:   serial
Err:   serial
invalid MAC address 0 in OTP 00:00:00:00:00:00
Net:   eth0: eth1@5800a000, eth1: eth2@5800e000
Hit any key to stop autoboot:  0
Boot over usb0!
DFU alt info setting: done

I suspect this has something to do with the boot over usb0 message, but I am not sure. How do I get access to the devices shown by dfu 0 when using snagrecover? Is this possible, or did I misunderstand the tool?

xogium commented 11 months ago

Here's a random thought I just had.

The stm32mp135d odyssey board has the usb-c port acting both for power and as OTG. Presumably this is different from the stm32mp135f-dk board, where the OTG port is a separate usb port (if it is similar to the stm32mp157f-dk2).

That might be why my board directly attempts to boot over usb0 and gets different dfu alt info?

rgantois commented 11 months ago

Thanks for the report, here's what I think is happening. The default bootcmd for STM32MP U-Boot eventually calls the stm32prog command which expects to find a flash layout somewhere in RAM. When using STM32CubeProgrammer, this flashlayout is usually written by the recovery tool before loading U-Boot.

Since Snagboot's design mandates complete separation between the recovery and flashing stages, we do not write this flashlayout file before loading U-Boot. So it goes like this:

You don't interrupt U-Boot -> it runs the default stm32mp bootcmd which looks for the flashlayout -> it doesn't find one so it just keeps the old layout from the recovery stage (the one with FlashLayout...)
You interrupt U-Boot -> you run dfu 0 -> that command reads the value stored in dfu_alt_info -> you get the right altsettings

What I would advise you to do is to simply change the U-Boot bootcmd to run dfu 0 and then whatever other boot command you need.

xogium commented 11 months ago

Thank you for explaining this. This sounds like it does make perfect sense. So you had to do this for some of the stm32mp1 you work with too then? Very good knowledge that...

bootlin / snagboot