On 7/15/20 12:14 PM, Heinrich Schuchardt wrote:
On 15.07.20 19:38, Heinrich Schuchardt wrote:
On 15.07.20 17:57, Stephen Warren wrote:
On 7/15/20 4:34 AM, Heinrich Schuchardt wrote:
Hello Stephen,
I have just looked into dfu testing.
Do we still need a custom dfu-util? At least the dfu-util provided by Ubuntu bionic/universe in our Docker image provides the -p parameter.
Yes, it looks like the -p option is supported by the dfu-util in Xenial too (I need to run Xenial due to other dependencies...)
However, this binary has one more patch in it which I need locally at least:
https://github.com/swarren/dfu-util/commit/23561bd0ca4f5f62488451826d4a03683...
You are not alone with your problem:
https://github.com/motive-ai/dfu-util/commit/c7e3c3c0cae977b6c4638b3af44968f...
I saw this explanation in https://github.com/zephyrproject-rtos/zephyr/issues/8734:
"As I explained in the pull request, the problem is not that the timeout in dfu-util is too small (the device should always respond immediately to the DFU request USB transaction) but that the device is not correctly implementing the DFU standard and the bwPollTimeout in the DFU_GETSTATUS response." Cf. https://github.com/zephyrproject-rtos/zephyr/pull/15330/commits
Could it be that we have a similar problem with our U-Boot implementation (drivers/usb/gadget/f_dfu.c)?
The value of DFU_MANIFEST_POLL_TIMEOUT and DFU_MANIFEST_POLL_TIMEOUT varies a lot between the boards:
include/dfu.h:111: #ifndef DFU_MANIFEST_POLL_TIMEOUT #define DFU_MANIFEST_POLL_TIMEOUT DFU_DEFAULT_POLL_TIMEOUT #endif
include/configs/odroid_xu3.h #define DFU_DEFAULT_POLL_TIMEOUT 300
include/configs/corvus.h #define DFU_MANIFEST_POLL_TIMEOUT 25000
Does increasing this value in include/configs/jetson-tk1.h help with your Jetson TK1 board?
I took a look at this and discovered a few things!
1) I can't repro the original timeout issuing I was having, with any of v2016.03, v2016.05, or v2016.07 (i.e. the current upstream versions around when I first checked in the custom dfu-util with the timeout patch). The commit comments indicate it may have been an issue with one of our downstream branches at the time. So, I removed that change and re-ran testing on all the branches that I *currently* test (upstream and downstream) and didn't see any issue. Hopefully it won't show up intermittently.
2) Even though Ubuntu 16.04's dfu-util binary indicates that it supports the -p command-line option, its implementation is missing since the required library wasn't present when Ubuntu built the package. Trying to use the -p feature simply results in dfu-util printing an error message. So, I personally will still need to use a custom binary of dfu-util because of this, but perhaps people on newer OSs won't. I've moved this dfu-util binary into a different git repo so only I'll end up using it.
So, in summary it doesn't look like there is an issue in the current U-Boot DFU code, or at least not one I can detect.