[U-Boot] [PATCH v2 77/80] dm: usb: Add tests for the USB uclass

[Simon Glass]

Hi Joe,

On 21 April 2015 at 10:57, Joe Hershberger <joe.hershberger at gmail.com> wrote:
> Hi Simon,
>
> On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Joe,
>>
>> On 21 April 2015 at 10:05, Joe Hershberger <joe.hershberger at gmail.com> wrote:
>>>
>>> Hi Simon,
>>>
>>> On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg at chromium.org> wrote:
>>> > Hi Joe,
>>> >
>>> > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger at gmail.com> wrote:
>>> >> Hi Simon,
>>> >>
>>> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg at chromium.org> wrote:
>>> >>> This adds a simple test for probing and a functional test using the flash
>>> >>> stick emulator, which tests a large chunk of the USB stack.
>>> >>>
>>> >>> Signed-off-by: Simon Glass <sjg at chromium.org>
>>> >>
>>> >> I'm seeing a seg fault when running the dm tests and bisected it to this patch.
>>> >>
>>> >> I'm not sure why it's related, but it appears to seg fault on a GPIO test...
>>>
>>> <--snip-->
>>>
>>> >> Thoughts?
>>> >
>>> > Yes it is broken. I sent a series to fix this recent ('dm: core: Fix
>>> > up test failures') starting with this patch:
>>> >
>>> > http://patchwork.ozlabs.org/patch/462556/
>>> >
>>> > If you are able to test it that would be good.
>>>
>>> I tested the series, but I still have a USB test failure...
>>>
>>> """
>>> Test: dm_test_usb_flash
>>> USB-1:   scanning bus 1 for devices... 2 USB Device(s) found
>>> /home/joe/u-boot/test/dm/usb.c:45, dm_test_usb_flash(): 2 ==
>>> dev_desc->block_read(dev_desc->dev, 0, 2, cmp): Expected 2, got 0
>>> """
>>>
>>> Have you seen that one?
>>
>> No I don't see that. It is saying that it was not able to read 2
>> 512-byte blocks from the testflash.bin file. It should be created by
>> the test script. I just tried it again.
>
> That makes sense... I wasn't creating that file. D'oh!  Working for me now too.
>
>> BTW I'd like to get a sandbox network device that works in a purely
>> emulated way (i.e. without any reference to real hardware). Then we
>> could use it for ping tests, etc. and they would run instantly. At
>> present the network tests are quite slow. What do you think?
>
> The tests are all using fully emulated Ethernet... the issue is that
> the ping test ensures that on timeout an error is returned. Even
> though it is an emulated MAC, the timeout in the network stack is
> still there.
>
> I'll work on a patch that adds a way to change the ping timeout to
> make this faster.

OK thanks for explaining this. Rather than changing the ping timeout,
can you look at changing the time? With sandbox it should be possible
to adjust the time so that timeouts appear to happen instantly. The
arch/sandbox/include/test.h file has some test functions used by
various parts of the stack.

Regards,
Simon