uboot-test-hooks: dfu-util

uboot-test-hooks: dfu-util

[Heinrich Schuchardt]

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.

dfu-util is licensed under GPL. Could you, please, add the missing
license information to the uboot-test-hooks repository.

Best regards

Heinrich

uboot-test-hooks: dfu-util

[Stephen Warren]

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/23561bd0ca4f5f62488451826d4a03683ad70e8a

Maybe I can move this binary somewhere else, since not everyone needs that.

> dfu-util is licensed under GPL. Could you, please, add the missing
> license information to the uboot-test-hooks repository.

Ah yes, I'll check in the license file in a second. FYI, the commit
descriptions for the binary do mention the source of the binary:
https://github.com/swarren/dfu-util, although yes that's not enough.

uboot-test-hooks: dfu-util

[Heinrich Schuchardt]

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/23561bd0ca4f5f62488451826d4a03683ad70e8a

I would suggest that you send a patch upstream to make the timeout a
command line option.

You can fork the project within Sourceforge.
https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/

Best regards

Heinrich

>
> Maybe I can move this binary somewhere else, since not everyone needs that.
>
>> dfu-util is licensed under GPL. Could you, please, add the missing
>> license information to the uboot-test-hooks repository.
>
> Ah yes, I'll check in the license file in a second. FYI, the commit
> descriptions for the binary do mention the source of the binary:
> https://github.com/swarren/dfu-util, although yes that's not enough.
>

uboot-test-hooks: dfu-util

[Heinrich Schuchardt]

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/23561bd0ca4f5f62488451826d4a03683ad70e8a

You are not alone with your problem:

https://github.com/motive-ai/dfu-util/commit/c7e3c3c0cae977b6c4638b3af44968f50ec1447a

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?

Cc: Lukasz, Marek

Best regards

Heinrich


>
> I would suggest that you send a patch upstream to make the timeout a
> command line option.
>
> You can fork the project within Sourceforge.
> https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/
>
> Best regards
>
> Heinrich
>
>>
>> Maybe I can move this binary somewhere else, since not everyone needs that.
>>
>>> dfu-util is licensed under GPL. Could you, please, add the missing
>>> license information to the uboot-test-hooks repository.
>>
>> Ah yes, I'll check in the license file in a second. FYI, the commit
>> descriptions for the binary do mention the source of the binary:
>> https://github.com/swarren/dfu-util, although yes that's not enough.
>>
>

uboot-test-hooks: dfu-util

[Stephen Warren]

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/23561bd0ca4f5f62488451826d4a03683ad70e8a
> 
> You are not alone with your problem:
> 
> https://github.com/motive-ai/dfu-util/commit/c7e3c3c0cae977b6c4638b3af44968f50ec1447a
> 
> 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.