| Message ID | 1427307788-7496-78-git-send-email-sjg@chromium.org |
|---|---|
| State | Accepted |
| Delegated to: | Simon Glass |
| Headers | show |
On 25 March 2015 at 12:23, Simon Glass <sjg@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@chromium.org> > --- > > Changes in v2: None > > test/dm/Makefile | 1 + > test/dm/test-dm.sh | 3 +++ > test/dm/test.dts | 41 +++++++++++++++++++++++++++++++++++++++++ > test/dm/usb.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 95 insertions(+) > create mode 100644 test/dm/usb.c Applied to u-boot-dm/next.
Hi Simon, On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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... U-Boot 2015.04-00280-ge00cb22-dirty (Apr 21 2015 - 00:02:01) DRAM: 128 MiB Using default environment In: serial Out: lcd Err: lcd Net: eth0: eth@10002000, eth5: eth@10003000, eth1: eth@10004000 Running 53 driver model tests Test: dm_test_autobind Test: dm_test_autoprobe Test: dm_test_bus_child_post_bind Test: dm_test_bus_child_post_bind_uclass Test: dm_test_bus_child_pre_probe_uclass Test: dm_test_bus_children Device 'c-test@0': seq 0 is in use by 'd-test' Device 'c-test@1': seq 1 is in use by 'f-test' Test: dm_test_bus_children_funcs Test: dm_test_bus_children_iterators Test: dm_test_bus_parent_data Test: dm_test_bus_parent_data_uclass Test: dm_test_bus_parent_ops Test: dm_test_bus_parent_platdata Test: dm_test_bus_parent_platdata_uclass Test: dm_test_children Test: dm_test_device_get_uclass_id Test: dm_test_eth Using eth@10002000 device Using eth@10003000 device Using eth@10004000 device Test: dm_test_eth_alias Using eth@10002000 device Using eth@10004000 device Using eth@10002000 device Using eth@10003000 device Test: dm_test_eth_prime Using eth@10003000 device Using eth@10002000 device Test: dm_test_eth_rotate Error: eth@10004000 address not set. Error: eth@10004000 address not set. Using eth@10002000 device Error: eth@10004000 address not set. Error: eth@10004000 address not set. Using eth@10004000 device Test: dm_test_fdt Test: dm_test_fdt_offset Test: dm_test_fdt_pre_reloc Test: dm_test_fdt_uclass_seq Test: dm_test_gpio extra-gpios: get_value: error: gpio b5 not reserved Test: dm_test_gpio_anon Test: dm_test_gpio_copy Test: dm_test_gpio_leak extra-gpios: get_value: error: gpio b5 not reserved Program received signal SIGSEGV, Segmentation fault. 0x000009ec in ?? () (gdb) bt #0 0x000009ec in ?? () #1 0x0806a0aa in uclass_destroy (uc=0xb5abd228) at /home/joe/u-boot/drivers/core/uclass.c:109 #2 0x080a29e1 in dm_leak_check_end (dms=0x8106870) at /home/joe/u-boot/test/dm/core.c:89 #3 0x080a46a6 in dm_test_gpio_leak (dms=0x8106870) at /home/joe/u-boot/test/dm/gpio.c:173 #4 0x080a0ed2 in dm_test_main (test_name=0x0) at /home/joe/u-boot/test/dm/test-main.c:103 #5 0x0809e9fb in do_dm (cmdtp=0x80c0250, flag=0, argc=135022648, argv=0xb5abbd40) at /home/joe/u-boot/test/dm/cmd_dm.c:150 #6 0x08065d6b in cmd_process (flag=0, argc=2, argv=0xb5abbd40, repeatable=0x80c5fc4, ticks=0x0) at /home/joe/u-boot/common/command.c:493 #7 0x0804d6fb in run_list_real (pi=0xb5abbc88) at /home/joe/u-boot/common/cli_hush.c:1656 #8 0x0804dce4 in parse_stream_outer (inp=0xbffff0e8, flag=2) at /home/joe/u-boot/common/cli_hush.c:2003 #9 0x0804df1d in parse_string_outer (s=0xbffff513 "dm test", flag=2) at /home/joe/u-boot/common/cli_hush.c:3248 #10 0x0804a855 in sandbox_main_loop_init () at /home/joe/u-boot/arch/sandbox/cpu/start.c:85 #11 0x0804e65b in run_main_loop () at /home/joe/u-boot/common/board_r.c:682 #12 0x0808f082 in initcall_run_list (init_sequence=0x80c1f68) at /home/joe/u-boot/lib/initcall.c:27 #13 0x0804e798 in board_init_r (new_gd=0xb5ab9f14, dest_addr=0) at /home/joe/u-boot/common/board_r.c:916 #14 0x0804a810 in main (argc=Cannot access memory at address 0x0 ) at /home/joe/u-boot/arch/sandbox/cpu/start.c:276 (gdb) f 1 #1 0x0806a0aa in uclass_destroy (uc=0xb5abd228) at /home/joe/u-boot/drivers/core/uclass.c:109 109 ret = device_unbind(dev); (gdb) l - 99 int uclass_destroy(struct uclass *uc) 100 { 101 struct uclass_driver *uc_drv; 102 struct udevice *dev, *tmp; 103 int ret; 104 105 list_for_each_entry_safe(dev, tmp, &uc->dev_head, uclass_node) { 106 ret = device_remove(dev); 107 if (ret) 108 return ret; (gdb) l 109 ret = device_unbind(dev); 110 if (ret) 111 return ret; 112 } 113 114 uc_drv = uc->uc_drv; 115 if (uc_drv->destroy) 116 uc_drv->destroy(uc); 117 list_del(&uc->sibling_node); 118 if (uc_drv->priv_auto_alloc_size) (gdb) Thoughts? -Joe
Hi Joe, On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: > Hi Simon, > > On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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... > > > U-Boot 2015.04-00280-ge00cb22-dirty (Apr 21 2015 - 00:02:01) > > DRAM: 128 MiB > Using default environment > > In: serial > Out: lcd > Err: lcd > Net: eth0: eth@10002000, eth5: eth@10003000, eth1: eth@10004000 > Running 53 driver model tests > Test: dm_test_autobind > Test: dm_test_autoprobe > Test: dm_test_bus_child_post_bind > Test: dm_test_bus_child_post_bind_uclass > Test: dm_test_bus_child_pre_probe_uclass > Test: dm_test_bus_children > Device 'c-test@0': seq 0 is in use by 'd-test' > Device 'c-test@1': seq 1 is in use by 'f-test' > Test: dm_test_bus_children_funcs > Test: dm_test_bus_children_iterators > Test: dm_test_bus_parent_data > Test: dm_test_bus_parent_data_uclass > Test: dm_test_bus_parent_ops > Test: dm_test_bus_parent_platdata > Test: dm_test_bus_parent_platdata_uclass > Test: dm_test_children > Test: dm_test_device_get_uclass_id > Test: dm_test_eth > Using eth@10002000 device > Using eth@10003000 device > Using eth@10004000 device > Test: dm_test_eth_alias > Using eth@10002000 device > Using eth@10004000 device > Using eth@10002000 device > Using eth@10003000 device > Test: dm_test_eth_prime > Using eth@10003000 device > Using eth@10002000 device > Test: dm_test_eth_rotate > > Error: eth@10004000 address not set. > > Error: eth@10004000 address not set. > Using eth@10002000 device > > Error: eth@10004000 address not set. > > Error: eth@10004000 address not set. > Using eth@10004000 device > Test: dm_test_fdt > Test: dm_test_fdt_offset > Test: dm_test_fdt_pre_reloc > Test: dm_test_fdt_uclass_seq > Test: dm_test_gpio > extra-gpios: get_value: error: gpio b5 not reserved > Test: dm_test_gpio_anon > Test: dm_test_gpio_copy > Test: dm_test_gpio_leak > extra-gpios: get_value: error: gpio b5 not reserved > > Program received signal SIGSEGV, Segmentation fault. > 0x000009ec in ?? () > (gdb) bt > #0 0x000009ec in ?? () > #1 0x0806a0aa in uclass_destroy (uc=0xb5abd228) at > /home/joe/u-boot/drivers/core/uclass.c:109 > #2 0x080a29e1 in dm_leak_check_end (dms=0x8106870) at > /home/joe/u-boot/test/dm/core.c:89 > #3 0x080a46a6 in dm_test_gpio_leak (dms=0x8106870) at > /home/joe/u-boot/test/dm/gpio.c:173 > #4 0x080a0ed2 in dm_test_main (test_name=0x0) at > /home/joe/u-boot/test/dm/test-main.c:103 > #5 0x0809e9fb in do_dm (cmdtp=0x80c0250, flag=0, argc=135022648, > argv=0xb5abbd40) at /home/joe/u-boot/test/dm/cmd_dm.c:150 > #6 0x08065d6b in cmd_process (flag=0, argc=2, argv=0xb5abbd40, > repeatable=0x80c5fc4, ticks=0x0) at > /home/joe/u-boot/common/command.c:493 > #7 0x0804d6fb in run_list_real (pi=0xb5abbc88) at > /home/joe/u-boot/common/cli_hush.c:1656 > #8 0x0804dce4 in parse_stream_outer (inp=0xbffff0e8, flag=2) at > /home/joe/u-boot/common/cli_hush.c:2003 > #9 0x0804df1d in parse_string_outer (s=0xbffff513 "dm test", flag=2) > at /home/joe/u-boot/common/cli_hush.c:3248 > #10 0x0804a855 in sandbox_main_loop_init () at > /home/joe/u-boot/arch/sandbox/cpu/start.c:85 > #11 0x0804e65b in run_main_loop () at /home/joe/u-boot/common/board_r.c:682 > #12 0x0808f082 in initcall_run_list (init_sequence=0x80c1f68) at > /home/joe/u-boot/lib/initcall.c:27 > #13 0x0804e798 in board_init_r (new_gd=0xb5ab9f14, dest_addr=0) at > /home/joe/u-boot/common/board_r.c:916 > #14 0x0804a810 in main (argc=Cannot access memory at address 0x0 > ) at /home/joe/u-boot/arch/sandbox/cpu/start.c:276 > (gdb) f 1 > #1 0x0806a0aa in uclass_destroy (uc=0xb5abd228) at > /home/joe/u-boot/drivers/core/uclass.c:109 > 109 ret = device_unbind(dev); > (gdb) l - > 99 int uclass_destroy(struct uclass *uc) > 100 { > 101 struct uclass_driver *uc_drv; > 102 struct udevice *dev, *tmp; > 103 int ret; > 104 > 105 list_for_each_entry_safe(dev, tmp, &uc->dev_head, uclass_node) { > 106 ret = device_remove(dev); > 107 if (ret) > 108 return ret; > (gdb) l > 109 ret = device_unbind(dev); > 110 if (ret) > 111 return ret; > 112 } > 113 > 114 uc_drv = uc->uc_drv; > 115 if (uc_drv->destroy) > 116 uc_drv->destroy(uc); > 117 list_del(&uc->sibling_node); > 118 if (uc_drv->priv_auto_alloc_size) > (gdb) > > > 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. Regards, Simon
Hi Simon, On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Joe, > > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: >> Hi Simon, >> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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? Thanks, -Joe
Hi Joe, On 21 April 2015 at 10:05, Joe Hershberger <joe.hershberger@gmail.com> wrote: > > Hi Simon, > > On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg@chromium.org> wrote: > > Hi Joe, > > > > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: > >> Hi Simon, > >> > >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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. 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? Regards, Simon
Hi Simon, On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Joe, > > On 21 April 2015 at 10:05, Joe Hershberger <joe.hershberger@gmail.com> wrote: >> >> Hi Simon, >> >> On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg@chromium.org> wrote: >> > Hi Joe, >> > >> > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: >> >> Hi Simon, >> >> >> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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. Cheers, -Joe
Hi Joe, On 21 April 2015 at 10:57, Joe Hershberger <joe.hershberger@gmail.com> wrote: > Hi Simon, > > On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Joe, >> >> On 21 April 2015 at 10:05, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>> >>> Hi Simon, >>> >>> On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg@chromium.org> wrote: >>> > Hi Joe, >>> > >>> > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>> >> Hi Simon, >>> >> >>> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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
Hi Simon, On Tue, Apr 21, 2015 at 12:00 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Joe, > > On 21 April 2015 at 10:57, Joe Hershberger <joe.hershberger@gmail.com> wrote: >> Hi Simon, >> >> On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Joe, >>> >>> On 21 April 2015 at 10:05, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>>> >>>> Hi Simon, >>>> >>>> On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg@chromium.org> wrote: >>>> > Hi Joe, >>>> > >>>> > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>>> >> Hi Simon, >>>> >> >>>> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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. I posted a series that handles the issue as you recommended and called it "test: Speed up test timeouts by advancing time". I now notice that the only test that takes any time is the USB Flash test. """ Test: dm_test_usb_flash USB-1: scanning bus 1 for devices... 2 USB Device(s) found """ It takes about 3 seconds. Is that a timeout too? Thanks, -Joe
Hi Joe, On 21 April 2015 at 14:10, Joe Hershberger <joe.hershberger@gmail.com> wrote: > Hi Simon, > > On Tue, Apr 21, 2015 at 12:00 PM, Simon Glass <sjg@chromium.org> wrote: >> Hi Joe, >> >> On 21 April 2015 at 10:57, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>> Hi Simon, >>> >>> On Tue, Apr 21, 2015 at 11:19 AM, Simon Glass <sjg@chromium.org> wrote: >>>> Hi Joe, >>>> >>>> On 21 April 2015 at 10:05, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>>>> >>>>> Hi Simon, >>>>> >>>>> On Tue, Apr 21, 2015 at 8:14 AM, Simon Glass <sjg@chromium.org> wrote: >>>>> > Hi Joe, >>>>> > >>>>> > On 20 April 2015 at 23:24, Joe Hershberger <joe.hershberger@gmail.com> wrote: >>>>> >> Hi Simon, >>>>> >> >>>>> >> On Wed, Mar 25, 2015 at 1:23 PM, Simon Glass <sjg@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@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. > > I posted a series that handles the issue as you recommended and called > it "test: Speed up test timeouts by advancing time". I see it. This is great, thank you! > > I now notice that the only test that takes any time is the USB Flash test. > > """ > Test: dm_test_usb_flash > USB-1: scanning bus 1 for devices... 2 USB Device(s) found > """ > > It takes about 3 seconds. Is that a timeout too? Yes. I'll take a look at how you have advanced time - we should do this for USB too. Regards, Simon
diff --git a/test/dm/Makefile b/test/dm/Makefile index a2e2d23..fd9e29f 100644 --- a/test/dm/Makefile +++ b/test/dm/Makefile @@ -23,4 +23,5 @@ obj-$(CONFIG_DM_I2C) += i2c.o obj-$(CONFIG_DM_PCI) += pci.o obj-$(CONFIG_DM_SPI_FLASH) += sf.o obj-$(CONFIG_DM_SPI) += spi.o +obj-$(CONFIG_DM_USB) += usb.o endif diff --git a/test/dm/test-dm.sh b/test/dm/test-dm.sh index 8ebc392..6158f68 100755 --- a/test/dm/test-dm.sh +++ b/test/dm/test-dm.sh @@ -10,5 +10,8 @@ dtc -I dts -O dtb test/dm/test.dts -o test/dm/test.dtb make O=sandbox sandbox_config || die "Cannot configure U-Boot" make O=sandbox -s -j${NUM_CPUS} || die "Cannot build U-Boot" dd if=/dev/zero of=spi.bin bs=1M count=2 +echo -n "this is a test" > testflash.bin +dd if=/dev/zero bs=1M count=4 >>testflash.bin ./sandbox/u-boot -d test/dm/test.dtb -c "dm test" rm spi.bin +rm testflash.bin diff --git a/test/dm/test.dts b/test/dm/test.dts index 0ab0916..d0c40be 100644 --- a/test/dm/test.dts +++ b/test/dm/test.dts @@ -20,6 +20,9 @@ testfdt8 = "/a-test"; eth0 = "/eth@10002000"; eth5 = ð_5; + usb0 = &usb_0; + usb1 = &usb_1; + usb2 = &usb_2; }; uart0: serial { @@ -186,4 +189,42 @@ fake-host-hwaddr = <0x00 0x00 0x66 0x44 0x22 0x22>; }; + usb_0: usb@0 { + compatible = "sandbox,usb"; + status = "disabled"; + hub { + compatible = "sandbox,usb-hub"; + #address-cells = <1>; + #size-cells = <0>; + flash-stick { + reg = <0>; + compatible = "sandbox,usb-flash"; + }; + }; + }; + + usb_1: usb@1 { + compatible = "sandbox,usb"; + hub { + compatible = "usb-hub"; + usb,device-class = <9>; + hub-emul { + compatible = "sandbox,usb-hub"; + #address-cells = <1>; + #size-cells = <0>; + flash-stick { + reg = <0>; + compatible = "sandbox,usb-flash"; + sandbox,filepath = "testflash.bin"; + }; + + }; + }; + }; + + usb_2: usb@2 { + compatible = "sandbox,usb"; + status = "disabled"; + }; + }; diff --git a/test/dm/usb.c b/test/dm/usb.c new file mode 100644 index 0000000..6ea86d7 --- /dev/null +++ b/test/dm/usb.c @@ -0,0 +1,50 @@ +/* + * Copyright (C) 2015 Google, Inc + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <dm.h> +#include <usb.h> +#include <asm/io.h> +#include <dm/test.h> +#include <dm/ut.h> + +/* Test that sandbox USB works correctly */ +static int dm_test_usb_base(struct dm_test_state *dms) +{ + struct udevice *bus; + + ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_USB, 0, &bus)); + ut_assertok(uclass_get_device(UCLASS_USB, 0, &bus)); + ut_asserteq(-ENODEV, uclass_get_device_by_seq(UCLASS_USB, 2, &bus)); + + return 0; +} +DM_TEST(dm_test_usb_base, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT); + +/* + * Test that we can use the flash stick. This is more of a functional test. It + * covers scanning the bug, setting up a hub and a flash stick and reading + * data from the flash stick. + */ +static int dm_test_usb_flash(struct dm_test_state *dms) +{ + struct udevice *dev; + block_dev_desc_t *dev_desc; + char cmp[1024]; + + ut_assertok(usb_init()); + ut_assertok(uclass_get_device(UCLASS_MASS_STORAGE, 0, &dev)); + ut_assertok(get_device("usb", "0", &dev_desc)); + + /* Read a few blocks and look for the string we expect */ + ut_asserteq(512, dev_desc->blksz); + memset(cmp, '\0', sizeof(cmp)); + ut_asserteq(2, dev_desc->block_read(dev_desc->dev, 0, 2, cmp)); + ut_assertok(strcmp(cmp, "this is a test")); + + return 0; +} +DM_TEST(dm_test_usb_flash, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
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@chromium.org> --- Changes in v2: None test/dm/Makefile | 1 + test/dm/test-dm.sh | 3 +++ test/dm/test.dts | 41 +++++++++++++++++++++++++++++++++++++++++ test/dm/usb.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 95 insertions(+) create mode 100644 test/dm/usb.c