SAMD bootloader does not mount with Debian 13.

[robert-hh]

I updated my PCs to debian 13 (trixie) recently. Since then, the UF2 bootloader of the SAMD board does not mount any more. To be more precise: If I repeat the mount attempts (reset board, wait a few seconds, push reset twice) many times, it starts mounting from the 19th attempt on until the PC is rebooted or just some time is expired. The image dumped from the virtual drive always mounts, so the board(s) is fine. When activating bootloader, the file manager shows a drive, and I see a /dev/sdb device, and there is an entry in the /media tree. But the content of the drive cannot be accessed. I assume it is a timing problem. The UF2 bootloader of the MIMXRT devices work fine, the RP2 ones are good as well.

This is just for information, since it is not a MicroPython issue and it is no deadlock: Uploading firmware with JLink works. And one can use bossac to upload firmware. The command line for bossac is:
bossac -p PORT -e -w -v -U -R --offset=OFFSET firmware.bin
The offset is 0x2000 for SAMD21 and 0x4000 for SAMD51. One can create firmware.bin from firmware.uf2 using uf2conv.py.

[dhalbert]

This kind of problem with the SAMD UF2 bootloaders was first seen when using ChromeOS: microsoft/uf2-samdx1#119. See also https://issuetracker.google.com/issues/409576876. Recent versions of ChromeOS on x64 (but not ARM) seem to be better.

The problem seems to be exposed by what fwupd is doing when the device is plugged in: fwupd/fwupd#9189. It's possible to exclude the devices and prevent it. But it's not necessarily true that fwupd is causing the problem -- it's just exposing an inherent issue.

We (Adafruit) have not seen the issue on other than SAMD UF2 bootloaders. I spent a while looking at USB traces comparing the SAMD and non-SAMD bootloaders but I don't have a diagnosis. This may be some kind of race condition, as discussed in the fwupd issue.