#150 Edison Arduino LIBUSB_ERROR_TIMEOUT

[Ferry Toth]

When flashing Intel Edison Arduino with a single btrfs image (> 1GB) I get:
dfu-util: Error during download (LIBUSB_ERROR_TIMEOUT)

When I restart flashing it goes on to a further point and each time I restart it goes further until finally it completes.

I found on github another project where they had the same issue and traced it back to the size of the image (large size requiring a longer timeout). https://github.com/espressif/esp-idf/issues/6999#issuecomment-840421868

As they write, changing the timeout is trivial. But maybe there is a more fundamental solution?

[Tormod Volden]

The fundamental solution is to fix the bootloader on your board to be DFU compliant. The 5 seconds timeout in dfu-util is for USB requests, which always should be replied to immediately. The bootloader should use the DFU mechanism to tell how long dfu-util should wait before the /next/ USB request.

[Ferry Toth]

The boot loader is U-Boot. Are you saying the implementation is U-Boot is incorrect?

[Tormod Volden]

Yes, I cannot be sure unless you provide more information (https://sourceforge.net/p/dfu-util/tickets/new/ should list what I need), but from what I saw in the link you gave it is clearly a DFU standard violation.

[Tormod Volden]

When you run with the verbose options -v -v you should see the Poll Timeout values reported by the bootloader. dfu-util makes sure it waits for that time before sending next request. If the reported timeout is too short, and the device is still unresponsive after the reported timeout, the next dfu-util USB request will timeout and this is shown by the LIBUSB_ERROR_TIMEOUT.

[Ferry Toth]

I'm not sure if the linked issue also uses U-Boot. In the case of Intel Edison-Arduino I have V2023.01. I just tried with dfu_timeout = 10000 which resolves the issue.

So it may be true that U-Boot waits to reply until an erase has completed. Or it may be doing something else, I need to look into that.

[Tormod Volden]

I don't see dfu_timeout documented. There is a CONFIG_DFU_TIMEOUT and a corresponding command parameter, but they are for how long to stay in DFU mode and not about the actual DFU transactions.

[Ferry Toth]

Oh, sorry I changed dfu_timeout in dfu-util dfu.c. I did not change anything in U-Boot yet - don't know where to start.

[Tormod Volden]

I don't know what kind of target media you're using but here is the "offending" code for MTD, and the others are the same, https://github.com/u-boot/u-boot/blob/master/drivers/dfu/dfu_mtd.c#L261

It looks quite broken, already because DFU_MANIFEST_POLL_TIMEOUT and DFU_DEFAULT_POLL_TIMEOUT are set to 0 in dfu.h but also this needs to be a dynamic value, maybe calculated from worst-case flashing+overhead timing, scaled to the amount to be written or erased.

[Ferry Toth]

Intel Edison has mmc.

[Tormod Volden]

Actually I don't know where the dfu->poll_timeout function gets called either, from searching their repo on GitHub.

EDIT: https://github.com/u-boot/u-boot/blob/master/drivers/usb/gadget/f_dfu.c#L182

[Ferry Toth]

https://elixir.bootlin.com/u-boot/latest/A/ident/poll_timeout

[Tormod Volden]

Apparently different board configurations specify different (but still hardcoded) poll timeout values: https://marc.info/?l=u-boot&m=139461850302101&w=2

[Ferry Toth]

Edison doesn't so is likely 0.

[Tormod Volden]

I assume this was fixed with appropriate device configuration.

[Anonymous]

No. I worked around with a patch dfu_timeout = 10000.

[Andy Shevchenko]

Neither for DFU MMC nor for Intel Edsion U-Boot does not support that timeout.

[Tormod Volden]

Did you bring this up with the u-boot maintainers?