swarren at wwwdotorg.org
Fri Jul 17 01:28:17 CEST 2020
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:
> You are not alone with your problem:
> I saw this explanation in
> "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.
> 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:
> #ifndef DFU_MANIFEST_POLL_TIMEOUT
> #define DFU_MANIFEST_POLL_TIMEOUT DFU_DEFAULT_POLL_TIMEOUT
> #define DFU_DEFAULT_POLL_TIMEOUT 300
> #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
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.
More information about the U-Boot