Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 26 Jun 2017 05:36 PM by  Brian Frohlich
libusb and mainstream kernel
 4 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Brian Frohlich
New Member
New Member
Posts:6


--
23 Jun 2017 06:08 PM

    Hi,

     

    I am trying to port code from linux 3.xx to the mainstream 4.4.9. 'lsusb' shows me the  the device I am interested in, but I cannot write or read. The application for communicating with the device uses libusb and worked fine in linux 3.xx and recompiled without a problem.

    Anyone been able to communicate with their usb device on DM37xx with the mainstream release?

     

    Thanks.

     

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    26 Jun 2017 07:11 AM
    The only USB controller that functions is the OTG controller. The ISP1763 does not have mainline support in the Linux Kernel.

    We have heard reports of people who have ported the 3.0 ISP 1763 controller to the modern kernels, but I don't have any of the patches or source to do that.

    The USB OTG controller is supported, but you need to enable a gadget (like g_zero) or something to enable the host. I know it seems counter intuitive.

    adam
    Brian Frohlich
    New Member
    New Member
    Posts:6


    --
    26 Jun 2017 10:45 AM

    Adam,

    Thanks for the reply.

    I am using OTG host. lsusb reveals my intended target and libusb seems to write successfully (see attached libusb and usbmon output).

    Any idea why there is no IN data (the device I am connected to will always respond to IN traffic).

     

    Thanks

     

    Brian

     

    Linux 4.4.9

    usblib 2.3

    # lsusb
    Bus 002 Device 003: ID 13b9:0095 <---- my device
    Bus 002 Device 002: ID 0424:2512
    Bus 002 Device 001: ID 1d6b:0002
    Bus 001 Device 001: ID 1d6b:0002

    Opening USB
    Initializing USB
    USB vid 5049 pid 149
    [timestamp] [threadID] facility level [function call]
    --------------------------------------------------------------------------------
    [ 0.019561] [000000e6] libusb: debug [libusb_get_device_list]
    [ 0.020080] [000000e6] libusb: debug [libusb_get_device_descriptor]
    [ 0.020172] [000000e6] libusb: debug [libusb_open] open 2.3
    [ 0.020935] [000000e6] libusb: debug [usbi_add_pollfd] add fd 14 events 4
    [ 0.021331] [000000e6] libusb: debug [libusb_kernel_driver_active] interface 0
    Device free from kernel
    [ 0.021545] [000000e6] libusb: debug [libusb_claim_interface] interface 0
    [ 0.024383] [000000e6] libusb: debug [libusb_set_interface_alt_setting] interface 0 altsetting 1
    [ 0.030059] [000000e6] libusb: debug [add_to_flying_list] arm timerfd for timeout in 200ms (first in line)
    [ 0.030273] [000000e6] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 4
    [ 0.032379] [000000e6] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
    [ 0.032562] [000000e6] libusb: debug [handle_events] poll() 4 fds with timeout in 60000ms
    [ 0.032684] [000000e6] libusb: debug [handle_events] poll() returned 1
    [ 0.032775] [000000e6] libusb: debug [reap_for_handle] urb type=3 status=0 transferred=4
    [ 0.032867] [000000e6] libusb: debug [handle_bulk_completion] handling completion status 0 of bulk urb 1/1
    [ 0.032928] [000000e6] libusb: debug [handle_bulk_completion] last URB in transfer --> complete!
    [ 0.032989] [000000e6] libusb: debug [disarm_timerfd]
    [ 0.033050] [000000e6] libusb: debug [usbi_handle_transfer_completion] transfer 0x24ee0 has callback 0xb6f32b14
    [ 0.033142] [000000e6] libusb: debug [sync_transfer_cb] actual_length=4                <---------- Good write?

    [ 0.033233] [000000e6] libusb: debug [libusb_set_interface_alt_setting] interface 0 altsetting 1
    [ 0.036377] [000000e6] libusb: debug [add_to_flying_list] arm timerfd for timeout in 400ms (first in line)
    [ 0.036651] [000000e6] libusb: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 2
    [ 0.037384] [000000e6] libusb: debug [libusb_handle_events_timeout_completed] doing our own event handling
    [ 0.037506] [000000e6] libusb: debug [handle_events] poll() 4 fds with timeout in 60000ms
    [ 0.437835] [000000e6] libusb: debug [handle_events] poll() returned 1
    [ 0.438049] [000000e6] libusb: debug [handle_events] timerfd triggered
    [ 0.438140] [000000e6] libusb: debug [libusb_cancel_transfer]
    [ 0.439209] [000000e6] libusb: debug [disarm_timerfd]
    [ 0.439361] [000000e6] libusb: debug [handle_events] poll() 4 fds with timeout in 0ms
    [ 0.439453] [000000e6] libusb: debug [handle_events] poll() returned 1
    [ 0.439544] [000000e6] libusb: debug [reap_for_handle] urb type=3 status=-2 transferred=0
    [ 0.439605] [000000e6] libusb: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
    [ 0.439666] [000000e6] libusb: debug [handle_bulk_completion] abnormal reap: urb status -2
    [ 0.439727] [000000e6] libusb: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
    [ 0.439788] [000000e6] libusb: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
    [ 0.439849] [000000e6] libusb: debug [disarm_timerfd]
    [ 0.439941] [000000e6] libusb: debug [usbi_handle_transfer_completion] transfer 0x24ee0 has callback 0xb6f32b14
    [ 0.440002] [000000e6] libusb: debug [sync_transfer_cb] actual_length=0 <----- No response

    cca49cc0 818983770 S Co:2:003:0 s 01 0b 0001 0000 0000 0
    cca49cc0 818984747 C Co:2:003:0 0 0
    ccc38740 818988500 S Bo:2:003:1 -115 4 = 04006901
    ccc38740 818989263 C Bo:2:003:1 0 4 >    <---------- Good write?

    ccc38740 818991888 S Co:2:003:0 s 01 0b 0001 0000 0000 0
    ccc38740 818992071 C Co:2:003:0 0 0
    ccc38740 818993841 S Bi:2:003:1 -115 2 <
    ccc38740 819394628 C Bi:2:003:1 -2    <----- no response
     

     

     

     

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    26 Jun 2017 01:27 PM
    When I first read your article, I read the kernel as 4.9, not 4.4.9.

    There is a bug in the DMA engine that was later fixed in some of the subsequent 4.4.y updates.. I would suggest updating your 4.4.9 to something newer(4.4.74 is the current). I think you'll find that the MUSB driver will work better.

    If you want to just try a couple of the msub related patches, you can try looking at them here:

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/usb/musb?h=v4.4.74

    If you want to use the 4.4 kernel but keep the latest and greatest patches, you can use the git repo:
    git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

    Checkout linux-4.4.y and it will pull down the latest code from the 4.4 branch.

    adam




    Brian Frohlich
    New Member
    New Member
    Posts:6


    --
    26 Jun 2017 05:36 PM

    Adam,

     

    Looks good. I updated the drivers/usb/musb folder using 4.4.47 and it seems we are in business.

     

    Thanks for the help.

     

    Brian

    You are not authorized to post a reply.