Re: Error reading USB camera in BeagleBone with ARM Debian
Joel, On Wed, Oct 24, 2018 at 07:19:01PM +0200, Josep M. Mirats Tur wrote: > Hi Joel, > > The camera I have provides 640x480 as its lowest resolution. > Hope the issue can be solved. If your issue was same as mine - the uvc layer holds spinlock for too long in urb->complete() which prevents musb to schedule next IN transaction on time, it won't be that easy to solve. :( I had a try last year, but the solution caused other problem, then haven't looked at this issue since then. Regards, -Bin. > Regards > > On Wed, Oct 24, 2018 at 5:31 PM Joel Pepper > wrote: > > > > Hi Joseph, Hi Bin, > > > > I am currently investigating a bug with the BeagleBoneBlack (which also > > uses the AM335x) and a Logitech Webcam, which might be connected. > > > > I am using a Logitech C270 and if I set the format to YUYV and the > > framesize to 544x288 or larger (including specifically 640x480), any > > ioctl VIDIOC_DQBUF will hang indefinetely. This might be the underlying > > source of the timeout Joseph encountered. > > > > Joseph, > > > > have you tried setting the camera to the lowest resolution it can go? If > > low resolutions work, but higher ones, like 640x480 don't, we might be > > chasing the same problem. If not, I will look into my problem separately > > and open a new thread. > > > > > > Bin, > > > > my case happened using ISOC transfers, but my preliminary investigation > > has shown lots of ISOC traffic flowing, apparently successfuly from the > > camera to the BBB, which makes me suspect a problem closer to the > > v4l2/musb boundary, but I'm still reading into the code. If you would > > like to investigate that further, the C270 is rather affordable, but I > > will gladly provide any details, usbmon captures etc. that you require. > > > > > > Cheers, > > > > Joel Pepper > > > > On 19.10.2018 20:06, Josep M. Mirats Tur wrote: > > > Hi Bin, > > > > > >> Do you know what is the usb throughput required in your test case? for > > >> example image format, resolution, frame rate? Is the usb data transfer > > >> bulk or isoch? > > > Yes, the image format is 640 x 480 > > > The camera can run up to 30fps, although I do not need it and set up it > > > to 5 > > > The Usb data transfer is "bulk" > > > > > > Regards > > > Josep M. > > > > > > On Fri, Oct 19, 2018 at 8:01 PM Bin Liu wrote: > > >> On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: > > >>> Hi, > > >>> > > >>> Yes, this would be the link: > > >>> http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html > > >> Okay, It is about $160, a bit more than my bugdet... > > >> > > >>> In the meanwhile I'll check my application with other board. > > >>> > > >>> Do you think there might be a problem with the processor frequency? > > >>> I've also crossing e-mails with ORBBEC engineers, and their only > > >>> answer has been to suggest using an ARM processor capable of 1.8GHz > > >>> Beagle is capable of 1GHz > > >>> But I can not see why is this so important as long as USB is well > > >>> synchronized and interrupts and driver work well. (Actually I'm not > > >>> familiar with ARM USB system, is just intuition) > > >> I guess the cpu clock requirement is only to ensure the whole system is > > >> capable to process the usb packets, depending on the image resolution, > > >> fps, and any other data processing. But lower cpu clock shouldn't cause > > >> such problem that the usb controller generates rx interrupt but fifo has > > >> no usb packet. If ARM cannot keep up, which doesn't send IN requests on > > >> time, the camera should just drop data. > > >> > > >> Do you know what is the usb throughput required in your test case? for > > >> example image format, resolution, frame rate? Is the usb data transfer > > >> bulk or isoch? > > >> > > >> Regards, > > >> -Bin. > > > >
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi Joel, The camera I have provides 640x480 as its lowest resolution. Hope the issue can be solved. Regards On Wed, Oct 24, 2018 at 5:31 PM Joel Pepper wrote: > > Hi Joseph, Hi Bin, > > I am currently investigating a bug with the BeagleBoneBlack (which also > uses the AM335x) and a Logitech Webcam, which might be connected. > > I am using a Logitech C270 and if I set the format to YUYV and the > framesize to 544x288 or larger (including specifically 640x480), any > ioctl VIDIOC_DQBUF will hang indefinetely. This might be the underlying > source of the timeout Joseph encountered. > > Joseph, > > have you tried setting the camera to the lowest resolution it can go? If > low resolutions work, but higher ones, like 640x480 don't, we might be > chasing the same problem. If not, I will look into my problem separately > and open a new thread. > > > Bin, > > my case happened using ISOC transfers, but my preliminary investigation > has shown lots of ISOC traffic flowing, apparently successfuly from the > camera to the BBB, which makes me suspect a problem closer to the > v4l2/musb boundary, but I'm still reading into the code. If you would > like to investigate that further, the C270 is rather affordable, but I > will gladly provide any details, usbmon captures etc. that you require. > > > Cheers, > > Joel Pepper > > On 19.10.2018 20:06, Josep M. Mirats Tur wrote: > > Hi Bin, > > > >> Do you know what is the usb throughput required in your test case? for > >> example image format, resolution, frame rate? Is the usb data transfer > >> bulk or isoch? > > Yes, the image format is 640 x 480 > > The camera can run up to 30fps, although I do not need it and set up it to 5 > > The Usb data transfer is "bulk" > > > > Regards > > Josep M. > > > > On Fri, Oct 19, 2018 at 8:01 PM Bin Liu wrote: > >> On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: > >>> Hi, > >>> > >>> Yes, this would be the link: > >>> http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html > >> Okay, It is about $160, a bit more than my bugdet... > >> > >>> In the meanwhile I'll check my application with other board. > >>> > >>> Do you think there might be a problem with the processor frequency? > >>> I've also crossing e-mails with ORBBEC engineers, and their only > >>> answer has been to suggest using an ARM processor capable of 1.8GHz > >>> Beagle is capable of 1GHz > >>> But I can not see why is this so important as long as USB is well > >>> synchronized and interrupts and driver work well. (Actually I'm not > >>> familiar with ARM USB system, is just intuition) > >> I guess the cpu clock requirement is only to ensure the whole system is > >> capable to process the usb packets, depending on the image resolution, > >> fps, and any other data processing. But lower cpu clock shouldn't cause > >> such problem that the usb controller generates rx interrupt but fifo has > >> no usb packet. If ARM cannot keep up, which doesn't send IN requests on > >> time, the camera should just drop data. > >> > >> Do you know what is the usb throughput required in your test case? for > >> example image format, resolution, frame rate? Is the usb data transfer > >> bulk or isoch? > >> > >> Regards, > >> -Bin. > >
Re: Error reading USB camera in BeagleBone with ARM Debian
Joel, On Wed, Oct 24, 2018 at 05:31:25PM +0200, Joel Pepper wrote: > Hi Joseph, Hi Bin, > > I am currently investigating a bug with the BeagleBoneBlack (which also > uses the AM335x) and a Logitech Webcam, which might be connected. > > I am using a Logitech C270 and if I set the format to YUYV and the > framesize to 544x288 or larger (including specifically 640x480), any > ioctl VIDIOC_DQBUF will hang indefinetely. This might be the underlying > source of the timeout Joseph encountered. > > Joseph, > > have you tried setting the camera to the lowest resolution it can go? If > low resolutions work, but higher ones, like 640x480 don't, we might be > chasing the same problem. If not, I will look into my problem separately > and open a new thread. > > > Bin, > > my case happened using ISOC transfers, but my preliminary investigation > has shown lots of ISOC traffic flowing, apparently successfuly from the > camera to the BBB, which makes me suspect a problem closer to the > v4l2/musb boundary, but I'm still reading into the code. If you would > like to investigate that further, the C270 is rather affordable, but I > will gladly provide any details, usbmon captures etc. that you require. I am aware of an issue for 640x480@30fps with some cameras. I am in full-day meetings this week. Once I get time, I will provide more details for the issue I know of to see if you have face the same. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi Joseph, Hi Bin, I am currently investigating a bug with the BeagleBoneBlack (which also uses the AM335x) and a Logitech Webcam, which might be connected. I am using a Logitech C270 and if I set the format to YUYV and the framesize to 544x288 or larger (including specifically 640x480), any ioctl VIDIOC_DQBUF will hang indefinetely. This might be the underlying source of the timeout Joseph encountered. Joseph, have you tried setting the camera to the lowest resolution it can go? If low resolutions work, but higher ones, like 640x480 don't, we might be chasing the same problem. If not, I will look into my problem separately and open a new thread. Bin, my case happened using ISOC transfers, but my preliminary investigation has shown lots of ISOC traffic flowing, apparently successfuly from the camera to the BBB, which makes me suspect a problem closer to the v4l2/musb boundary, but I'm still reading into the code. If you would like to investigate that further, the C270 is rather affordable, but I will gladly provide any details, usbmon captures etc. that you require. Cheers, Joel Pepper On 19.10.2018 20:06, Josep M. Mirats Tur wrote: > Hi Bin, > >> Do you know what is the usb throughput required in your test case? for >> example image format, resolution, frame rate? Is the usb data transfer >> bulk or isoch? > Yes, the image format is 640 x 480 > The camera can run up to 30fps, although I do not need it and set up it to 5 > The Usb data transfer is "bulk" > > Regards > Josep M. > > On Fri, Oct 19, 2018 at 8:01 PM Bin Liu wrote: >> On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: >>> Hi, >>> >>> Yes, this would be the link: >>> http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html >> Okay, It is about $160, a bit more than my bugdet... >> >>> In the meanwhile I'll check my application with other board. >>> >>> Do you think there might be a problem with the processor frequency? >>> I've also crossing e-mails with ORBBEC engineers, and their only >>> answer has been to suggest using an ARM processor capable of 1.8GHz >>> Beagle is capable of 1GHz >>> But I can not see why is this so important as long as USB is well >>> synchronized and interrupts and driver work well. (Actually I'm not >>> familiar with ARM USB system, is just intuition) >> I guess the cpu clock requirement is only to ensure the whole system is >> capable to process the usb packets, depending on the image resolution, >> fps, and any other data processing. But lower cpu clock shouldn't cause >> such problem that the usb controller generates rx interrupt but fifo has >> no usb packet. If ARM cannot keep up, which doesn't send IN requests on >> time, the camera should just drop data. >> >> Do you know what is the usb throughput required in your test case? for >> example image format, resolution, frame rate? Is the usb data transfer >> bulk or isoch? >> >> Regards, >> -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, In any case, I double checked by setting only 1 line in the uEnv.txt file the ouput for cat /proc/cmdline is console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet musb_hdrc.use_dma=0 usbcore.autosuspend=-1 But same troubles as before Regards Josep M. On Fri, Oct 19, 2018 at 8:42 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 02:26:51PM -0400, Alan Stern wrote: > > On Fri, 19 Oct 2018, Bin Liu wrote: > > > > > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > > > Hi Bin, > > > > > > > > I included the following line in the /boot/uEnv.txt file (attached for > > > > your info): > > > > cmdline=musb_hdrc.use_dma=0 > > > > > > I am not sure about the 'cmdline=' part. Anyway, after your board is > > > booted, use command 'cat /proc/cmdline' to check if your setting is > > > correct. > > > > There already was a "cmdline=" entry in the file: > > > > > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > > > > > #In the event of edid real failures, uncomment this next line: > > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > video=HDMI-A-1:1024x768@60e > > > > > > > > #Use an overlayfs on top of a read-only root filesystem: > > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > > > > > ##enable Generic eMMC Flasher: > > > > ##make sure, these tools are installed: dosfstools rsync > > > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > > > > > #jmmt disable dma for musb > > > > cmdline=musb_hdrc.use_dma=0 > > > > The "musb_hdrc.use_dma=0" should have been appended to the earlier > > entry, not added separately. > > right, but this is just a testing to disable cppi dma, other existing > cmdline params seem not related to usb, so I think it is okay to > overwrite. > > Regards, > -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 02:26:51PM -0400, Alan Stern wrote: > On Fri, 19 Oct 2018, Bin Liu wrote: > > > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > > Hi Bin, > > > > > > I included the following line in the /boot/uEnv.txt file (attached for > > > your info): > > > cmdline=musb_hdrc.use_dma=0 > > > > I am not sure about the 'cmdline=' part. Anyway, after your board is > > booted, use command 'cat /proc/cmdline' to check if your setting is > > correct. > > There already was a "cmdline=" entry in the file: > > > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > > > #In the event of edid real failures, uncomment this next line: > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > > > > > #Use an overlayfs on top of a read-only root filesystem: > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > > > ##enable Generic eMMC Flasher: > > > ##make sure, these tools are installed: dosfstools rsync > > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > > > #jmmt disable dma for musb > > > cmdline=musb_hdrc.use_dma=0 > > The "musb_hdrc.use_dma=0" should have been appended to the earlier > entry, not added separately. right, but this is just a testing to disable cppi dma, other existing cmdline params seem not related to usb, so I think it is okay to overwrite. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Bin Liu wrote: > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > Hi Bin, > > > > I included the following line in the /boot/uEnv.txt file (attached for > > your info): > > cmdline=musb_hdrc.use_dma=0 > > I am not sure about the 'cmdline=' part. Anyway, after your board is > booted, use command 'cat /proc/cmdline' to check if your setting is > correct. There already was a "cmdline=" entry in the file: > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > #In the event of edid real failures, uncomment this next line: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > > > #Use an overlayfs on top of a read-only root filesystem: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > ##enable Generic eMMC Flasher: > > ##make sure, these tools are installed: dosfstools rsync > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > #jmmt disable dma for musb > > cmdline=musb_hdrc.use_dma=0 The "musb_hdrc.use_dma=0" should have been appended to the earlier entry, not added separately. Alan Stern
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi Bin, > Do you know what is the usb throughput required in your test case? for > example image format, resolution, frame rate? Is the usb data transfer > bulk or isoch? Yes, the image format is 640 x 480 The camera can run up to 30fps, although I do not need it and set up it to 5 The Usb data transfer is "bulk" Regards Josep M. On Fri, Oct 19, 2018 at 8:01 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: > > Hi, > > > > Yes, this would be the link: > > http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html > > Okay, It is about $160, a bit more than my bugdet... > > > In the meanwhile I'll check my application with other board. > > > > Do you think there might be a problem with the processor frequency? > > I've also crossing e-mails with ORBBEC engineers, and their only > > answer has been to suggest using an ARM processor capable of 1.8GHz > > Beagle is capable of 1GHz > > But I can not see why is this so important as long as USB is well > > synchronized and interrupts and driver work well. (Actually I'm not > > familiar with ARM USB system, is just intuition) > > I guess the cpu clock requirement is only to ensure the whole system is > capable to process the usb packets, depending on the image resolution, > fps, and any other data processing. But lower cpu clock shouldn't cause > such problem that the usb controller generates rx interrupt but fifo has > no usb packet. If ARM cannot keep up, which doesn't send IN requests on > time, the camera should just drop data. > > Do you know what is the usb throughput required in your test case? for > example image format, resolution, frame rate? Is the usb data transfer > bulk or isoch? > > Regards, > -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: > Hi, > > Yes, this would be the link: > http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html Okay, It is about $160, a bit more than my bugdet... > In the meanwhile I'll check my application with other board. > > Do you think there might be a problem with the processor frequency? > I've also crossing e-mails with ORBBEC engineers, and their only > answer has been to suggest using an ARM processor capable of 1.8GHz > Beagle is capable of 1GHz > But I can not see why is this so important as long as USB is well > synchronized and interrupts and driver work well. (Actually I'm not > familiar with ARM USB system, is just intuition) I guess the cpu clock requirement is only to ensure the whole system is capable to process the usb packets, depending on the image resolution, fps, and any other data processing. But lower cpu clock shouldn't cause such problem that the usb controller generates rx interrupt but fifo has no usb packet. If ARM cannot keep up, which doesn't send IN requests on time, the camera should just drop data. Do you know what is the usb throughput required in your test case? for example image format, resolution, frame rate? Is the usb data transfer bulk or isoch? Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, Yes, this would be the link: http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html In the meanwhile I'll check my application with other board. Do you think there might be a problem with the processor frequency? I've also crossing e-mails with ORBBEC engineers, and their only answer has been to suggest using an ARM processor capable of 1.8GHz Beagle is capable of 1GHz But I can not see why is this so important as long as USB is well synchronized and interrupts and driver work well. (Actually I'm not familiar with ARM USB system, is just intuition) Many thanks for your help today Josep M. On Fri, Oct 19, 2018 at 7:41 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 07:33:47PM +0200, Josep M. Mirats Tur wrote: > > Hi, > > > > It seems correct, this is the output of sudo cat /proc/cmdline: > > console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 > > root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait musb_hdrc.use_dma=0 > > It looks correct. So the issue is not related to CPPI dma. > Do you have a link to buy the camera? If I can afford it, I might buy > one to take a look at this problem. > > Regards, > -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 07:33:47PM +0200, Josep M. Mirats Tur wrote: > Hi, > > It seems correct, this is the output of sudo cat /proc/cmdline: > console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 > root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait musb_hdrc.use_dma=0 It looks correct. So the issue is not related to CPPI dma. Do you have a link to buy the camera? If I can afford it, I might buy one to take a look at this problem. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, It seems correct, this is the output of sudo cat /proc/cmdline: console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait musb_hdrc.use_dma=0 So no changes :( Any other suggestion or idea? Thanks Josep M On Fri, Oct 19, 2018 at 7:31 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > Hi Bin, > > > > I included the following line in the /boot/uEnv.txt file (attached for > > your info): > > cmdline=musb_hdrc.use_dma=0 > > I am not sure about the 'cmdline=' part. Anyway, after your board is > booted, use command 'cat /proc/cmdline' to check if your setting is > correct. > > Regards, > -Bin. > > > > Is this format correct? > > I rebooted and checked again but still the same errors from dmesg: > > > > [ 228.863997] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > [ 229.016708] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 > > [ 229.023512] usb 1-1: New USB device strings: Mfr=1, Product=2, > > SerialNumber=0 > > [ 229.032841] usb 1-1: Product: ORBBEC Depth Sensor > > [ 229.038752] usb 1-1: Manufacturer: Orbbec(R) > > [ 249.221761] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 249.228346] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 249.238329] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 249.249025] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > > On Fri, Oct 19, 2018 at 7:00 PM Bin Liu wrote: > > > > > > On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > > > > Bin, > > > > > > > > I'm sorry but I cannot find that menuconfig at the Beagle... > > > > > > Never mind, but add the following to your UBoot bootargs env instead to > > > disable dma. > > > > > > musb_hdrc.use_dma=0 > > > > > > Regards, > > > -Bin. > > > > > > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 > > > > uname_r=4.14.71-ti-r80 > > #uuid= > > #dtb= > > > > ###U-Boot Overlays### > > ###Documentation: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays > > ###Master Enable > > enable_uboot_overlays=1 > > ### > > ###Overide capes with eeprom > > #uboot_overlay_addr0=/lib/firmware/.dtbo > > #uboot_overlay_addr1=/lib/firmware/.dtbo > > #uboot_overlay_addr2=/lib/firmware/.dtbo > > #uboot_overlay_addr3=/lib/firmware/.dtbo > > ### > > ###Additional custom capes > > #uboot_overlay_addr4=/lib/firmware/.dtbo > > #uboot_overlay_addr5=/lib/firmware/.dtbo > > #uboot_overlay_addr6=/lib/firmware/.dtbo > > #uboot_overlay_addr7=/lib/firmware/.dtbo > > ### > > ###Custom Cape > > #dtb_overlay=/lib/firmware/.dtbo > > ### > > ###Disable auto loading of virtual capes (emmc/video/wireless/adc) > > #disable_uboot_overlay_emmc=1 > > disable_uboot_overlay_video=1 > > disable_uboot_overlay_audio=1 > > disable_uboot_overlay_wireless=1 > > #disable_uboot_overlay_adc=1 > > ### > > ###PRUSS OPTIONS > > ###pru_rproc (4.4.x-ti kernel) > > #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo > > ###pru_rproc (4.14.x-ti kernel) > > uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo > > ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel) > > uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo > > ### > > ###Cape Universal Enable > > enable_uboot_cape_universal=1 > > ### > > ###Debug: disable uboot autoload of Cape > > #disable_uboot_overlay_addr0=1 > > #disable_uboot_overlay_addr1=1 > > #disable_uboot_overlay_addr2=1 > > #disable_uboot_overlay_addr3=1 > > ### > > ###U-Boot fdt tweaks... (6 = 384KB) > > #uboot_fdt_buffer=0x6 > > ###U-Boot Overlays### > > > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > #In the event of edid real failures, uncomment this next line: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > > > #Use an overlayfs on top of a read-only root filesystem: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > ##enable Generic eMMC Flasher: > > ##make sure, these tools are installed: dosfstools rsync > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > #jmmt disable dma for musb > > cmdline=musb_hdrc.use_dma=0 >
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > Hi Bin, > > I included the following line in the /boot/uEnv.txt file (attached for > your info): > cmdline=musb_hdrc.use_dma=0 I am not sure about the 'cmdline=' part. Anyway, after your board is booted, use command 'cat /proc/cmdline' to check if your setting is correct. Regards, -Bin. > > Is this format correct? > I rebooted and checked again but still the same errors from dmesg: > > [ 228.863997] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 229.016708] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 > [ 229.023512] usb 1-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [ 229.032841] usb 1-1: Product: ORBBEC Depth Sensor > [ 229.038752] usb 1-1: Manufacturer: Orbbec(R) > [ 249.221761] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 249.228346] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 249.238329] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 249.249025] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > On Fri, Oct 19, 2018 at 7:00 PM Bin Liu wrote: > > > > On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > > > Bin, > > > > > > I'm sorry but I cannot find that menuconfig at the Beagle... > > > > Never mind, but add the following to your UBoot bootargs env instead to > > disable dma. > > > > musb_hdrc.use_dma=0 > > > > Regards, > > -Bin. > > > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 > > uname_r=4.14.71-ti-r80 > #uuid= > #dtb= > > ###U-Boot Overlays### > ###Documentation: > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays > ###Master Enable > enable_uboot_overlays=1 > ### > ###Overide capes with eeprom > #uboot_overlay_addr0=/lib/firmware/.dtbo > #uboot_overlay_addr1=/lib/firmware/.dtbo > #uboot_overlay_addr2=/lib/firmware/.dtbo > #uboot_overlay_addr3=/lib/firmware/.dtbo > ### > ###Additional custom capes > #uboot_overlay_addr4=/lib/firmware/.dtbo > #uboot_overlay_addr5=/lib/firmware/.dtbo > #uboot_overlay_addr6=/lib/firmware/.dtbo > #uboot_overlay_addr7=/lib/firmware/.dtbo > ### > ###Custom Cape > #dtb_overlay=/lib/firmware/.dtbo > ### > ###Disable auto loading of virtual capes (emmc/video/wireless/adc) > #disable_uboot_overlay_emmc=1 > disable_uboot_overlay_video=1 > disable_uboot_overlay_audio=1 > disable_uboot_overlay_wireless=1 > #disable_uboot_overlay_adc=1 > ### > ###PRUSS OPTIONS > ###pru_rproc (4.4.x-ti kernel) > #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo > ###pru_rproc (4.14.x-ti kernel) > uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo > ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel) > uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo > ### > ###Cape Universal Enable > enable_uboot_cape_universal=1 > ### > ###Debug: disable uboot autoload of Cape > #disable_uboot_overlay_addr0=1 > #disable_uboot_overlay_addr1=1 > #disable_uboot_overlay_addr2=1 > #disable_uboot_overlay_addr3=1 > ### > ###U-Boot fdt tweaks... (6 = 384KB) > #uboot_fdt_buffer=0x6 > ###U-Boot Overlays### > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > #In the event of edid real failures, uncomment this next line: > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > #Use an overlayfs on top of a read-only root filesystem: > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > ##enable Generic eMMC Flasher: > ##make sure, these tools are installed: dosfstools rsync > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > #jmmt disable dma for musb > cmdline=musb_hdrc.use_dma=0
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi Bin, I included the following line in the /boot/uEnv.txt file (attached for your info): cmdline=musb_hdrc.use_dma=0 Is this format correct? I rebooted and checked again but still the same errors from dmesg: [ 228.863997] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 229.016708] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 [ 229.023512] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 229.032841] usb 1-1: Product: ORBBEC Depth Sensor [ 229.038752] usb 1-1: Manufacturer: Orbbec(R) [ 249.221761] musb_host_rx 1965: Rx interrupt with no errors or packet! [ 249.228346] musb_host_rx 1965: Rx interrupt with no errors or packet! [ 249.238329] musb_host_rx 1965: Rx interrupt with no errors or packet! [ 249.249025] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 On Fri, Oct 19, 2018 at 7:00 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > > Bin, > > > > I'm sorry but I cannot find that menuconfig at the Beagle... > > Never mind, but add the following to your UBoot bootargs env instead to > disable dma. > > musb_hdrc.use_dma=0 > > Regards, > -Bin. > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=4.14.71-ti-r80 #uuid= #dtb= ###U-Boot Overlays### ###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays ###Master Enable enable_uboot_overlays=1 ### ###Overide capes with eeprom #uboot_overlay_addr0=/lib/firmware/.dtbo #uboot_overlay_addr1=/lib/firmware/.dtbo #uboot_overlay_addr2=/lib/firmware/.dtbo #uboot_overlay_addr3=/lib/firmware/.dtbo ### ###Additional custom capes #uboot_overlay_addr4=/lib/firmware/.dtbo #uboot_overlay_addr5=/lib/firmware/.dtbo #uboot_overlay_addr6=/lib/firmware/.dtbo #uboot_overlay_addr7=/lib/firmware/.dtbo ### ###Custom Cape #dtb_overlay=/lib/firmware/.dtbo ### ###Disable auto loading of virtual capes (emmc/video/wireless/adc) #disable_uboot_overlay_emmc=1 disable_uboot_overlay_video=1 disable_uboot_overlay_audio=1 disable_uboot_overlay_wireless=1 #disable_uboot_overlay_adc=1 ### ###PRUSS OPTIONS ###pru_rproc (4.4.x-ti kernel) #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo ###pru_rproc (4.14.x-ti kernel) uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel) uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo ### ###Cape Universal Enable enable_uboot_cape_universal=1 ### ###Debug: disable uboot autoload of Cape #disable_uboot_overlay_addr0=1 #disable_uboot_overlay_addr1=1 #disable_uboot_overlay_addr2=1 #disable_uboot_overlay_addr3=1 ### ###U-Boot fdt tweaks... (6 = 384KB) #uboot_fdt_buffer=0x6 ###U-Boot Overlays### cmdline=coherent_pool=1M net.ifnames=0 quiet #In the event of edid real failures, uncomment this next line: #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e #Use an overlayfs on top of a read-only root filesystem: #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs ##enable Generic eMMC Flasher: ##make sure, these tools are installed: dosfstools rsync #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh #jmmt disable dma for musb cmdline=musb_hdrc.use_dma=0
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Thanks Alan, > > So, what might be the cause for those transfers that have less data > than expected? > The camera works well since in my desktop PC just works with the same > code compiled at the Beagle. > Could it be a matter of the ARM processor clock frequency? Beagle > features ARM TI AM335x at 1GHz I do not know. Alan Stern
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > Bin, > > I'm sorry but I cannot find that menuconfig at the Beagle... Never mind, but add the following to your UBoot bootargs env instead to disable dma. musb_hdrc.use_dma=0 Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Bin,
I'm sorry but I cannot find that menuconfig at the Beagle...
Does this mean I need to compile and configure a new kernel from Debian sources?
On Fri, Oct 19, 2018 at 6:28 PM Bin Liu wrote:
>
> On Fri, Oct 19, 2018 at 06:17:31PM +0200, Josep M. Mirats Tur wrote:
> > Hi Bin,
> >
> > I was referring to the output of usbmon I attached in the previous
> > message (attached again)
> >
> > I'm sorry but I do not know how to acces the kernel menuconfig to
> > disable the MUSB CPPI DMA, how should I do that?
>
> In kernel menuconfig, go to
>
> Device Drivers --->
> [*] USB support --->
>Inventra Highspeed Dual Role Controller (TI, ADI, AW,
> ...)
> ...
> TI DSPS platforms
> *** MUSB DMA mode ***
> [*] Disable DMA (always use PIO)
>
> Please ensure the last option ("Disable DMA") is checked.
>
> Regards,
> -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 06:17:31PM +0200, Josep M. Mirats Tur wrote:
> Hi Bin,
>
> I was referring to the output of usbmon I attached in the previous
> message (attached again)
>
> I'm sorry but I do not know how to acces the kernel menuconfig to
> disable the MUSB CPPI DMA, how should I do that?
In kernel menuconfig, go to
Device Drivers --->
[*] USB support --->
Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)
...
TI DSPS platforms
*** MUSB DMA mode ***
[*] Disable DMA (always use PIO)
Please ensure the last option ("Disable DMA") is checked.
Regards,
-Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Thanks Alan, So, what might be the cause for those transfers that have less data than expected? The camera works well since in my desktop PC just works with the same code compiled at the Beagle. Could it be a matter of the ARM processor clock frequency? Beagle features ARM TI AM335x at 1GHz Josep M. On Fri, Oct 19, 2018 at 6:15 PM Alan Stern wrote: > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > Hi, > > > > Thanks again for your answer. > > > > I changed to the newest Debian image available for BeagleBone boards: > > The Debian 9.5 - 4.14.71-ti-r80 > > I disabled the usb "autosuspend" by issuing the command > > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > > > I cannot say if now there is data coming from the USB as I cannot > > understand the output > > But I still get errors from the driver when I check the dmesg: > > > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 6596.728656] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > > Your program expects to transfer information from the camera in chunks > of size 20 KB, right? Those -121 errors indicate times when the amount > of data received was less than that. For example, sometimes the camera > only sent 8836 bytes, or 4228, or 14468, or 11396. At least, that's > what the BeagleBone thinks it received. > > Alan Stern > > > Let see if this info suggests you or Bin any actions to check > > Many thanks again > > Josep M. > > > > On Fri, Oct 19, 2018 at 4:24 PM Alan Stern > > wrote: > > > > > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > > > > > Hi Stern, > > > > > > > > > First question: Does you get similar failures if you plug the device > > > > > into a standard PC rather than the BeagleBone? > > > > > > > > > > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > > > > works (using exactly the same code I compile in the Beagle) > > > > > > > > > Second question: Have you tried looking at usbmon traces to see where > > > > > the communication starts to fail? > > > > > > > > > > > > > II tried now, I'm attaching the trace I get, which I cannot understand > > > > > > The usbmon trace shows a few errors in the musb-hdrc driver. Here are > > > the relevant parts: > > > > > > dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0001 0004 4 < > > > dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 > > > > > > This shows the system polling the root-hub port status. The return > > > value indicates that the camera was just plugged into the port, but it > > > also shows that the port is suspended, which makes no sense. The > > > suspend bit remains set in later port-status queries. > > > > > > dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0 > > > dcf39600 1096487621 C Co:1:001:0 0 0 > > > dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 > > > dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < > > > dcf39600 1096547461 S Ci:1:001:0 s a3 00 0001 0004 4 < > > > dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 > > > > > > The shows the system telling the root hub to reset port 1. When the > > > reset is finished, the status shows a reset-status change (which is > > > correct) together with an enable-status change (which is wrong). (It > > > also still shows that the port is suspended!) > > > > > > dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0001 0004 4 < > > > dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 > > > > > > Following the enumeration of the USB camera, the system again checks > > > the port status. The value shows an enable-status change, which is > > > supposed to mean that the port has been disabled. But the port has not > > > been disabled, as we can see from the fact that the enable-status bit > > > is also set. > > > > > > The trace ends at this point. It does not show any communication > > > failures like what you described in the original email message. > > > > > > > > > Should I load different usb modules in the system kernel? Should I > > > > > > modify a given module? > > > > > > > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > > > > try asking the maintainer for that driver. > > > > > > > > Ok, could you please provide me the e-mail address where to write? > > > > > > The maintainer is Bin Liu (CC'ed). And you should also remember to CC > > > the linux-usb mailing list. > > > > > > Alan Stern > > > > > > > Thanks > > > > > > > > > > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern > > > > wrote: > > > > > > > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > > > > > > > Hi > > > > > >
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Hi, > > Thanks again for your answer. > > I changed to the newest Debian image available for BeagleBone boards: > The Debian 9.5 - 4.14.71-ti-r80 > I disabled the usb "autosuspend" by issuing the command > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > I cannot say if now there is data coming from the USB as I cannot > understand the output > But I still get errors from the driver when I check the dmesg: > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 6596.728656] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 Your program expects to transfer information from the camera in chunks of size 20 KB, right? Those -121 errors indicate times when the amount of data received was less than that. For example, sometimes the camera only sent 8836 bytes, or 4228, or 14468, or 11396. At least, that's what the BeagleBone thinks it received. Alan Stern > Let see if this info suggests you or Bin any actions to check > Many thanks again > Josep M. > > On Fri, Oct 19, 2018 at 4:24 PM Alan Stern wrote: > > > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > > > Hi Stern, > > > > > > > First question: Does you get similar failures if you plug the device > > > > into a standard PC rather than the BeagleBone? > > > > > > > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > > > works (using exactly the same code I compile in the Beagle) > > > > > > > Second question: Have you tried looking at usbmon traces to see where > > > > the communication starts to fail? > > > > > > > > > > II tried now, I'm attaching the trace I get, which I cannot understand > > > > The usbmon trace shows a few errors in the musb-hdrc driver. Here are > > the relevant parts: > > > > dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0001 0004 4 < > > dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 > > > > This shows the system polling the root-hub port status. The return > > value indicates that the camera was just plugged into the port, but it > > also shows that the port is suspended, which makes no sense. The > > suspend bit remains set in later port-status queries. > > > > dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0 > > dcf39600 1096487621 C Co:1:001:0 0 0 > > dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 > > dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < > > dcf39600 1096547461 S Ci:1:001:0 s a3 00 0001 0004 4 < > > dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 > > > > The shows the system telling the root hub to reset port 1. When the > > reset is finished, the status shows a reset-status change (which is > > correct) together with an enable-status change (which is wrong). (It > > also still shows that the port is suspended!) > > > > dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0001 0004 4 < > > dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 > > > > Following the enumeration of the USB camera, the system again checks > > the port status. The value shows an enable-status change, which is > > supposed to mean that the port has been disabled. But the port has not > > been disabled, as we can see from the fact that the enable-status bit > > is also set. > > > > The trace ends at this point. It does not show any communication > > failures like what you described in the original email message. > > > > > > > Should I load different usb modules in the system kernel? Should I > > > > > modify a given module? > > > > > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > > > try asking the maintainer for that driver. > > > > > > Ok, could you please provide me the e-mail address where to write? > > > > The maintainer is Bin Liu (CC'ed). And you should also remember to CC > > the linux-usb mailing list. > > > > Alan Stern > > > > > Thanks > > > > > > > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern > > > wrote: > > > > > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > > > > > Hi > > > > > > > > > > I've recently acquired a BeagleBone Green with AM335x processor. I 'm > > > > > connecting a USB device (actually a 3D camera from ORBBEC) to the > > > > > Beagle USB host port. It recognizes well as I can see at the dmesg > > > > > output: > > > > > > > > > > [12411.643517] usb 1-1: new high-speed USB device number 2 using > > > > > musb-hdrc > > > > > [12411.784848] usb 1-1: New USB device found, idVendor=2bc5, > > > > > idProduct=0404 > > > > > [12411.784912] usb 1-1: New USB device strings: Mfr=1, Product=2, > > > > > SerialNumber=0 > > > > >
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, On Fri, Oct 19, 2018 at 05:35:29PM +0200, Josep M. Mirats Tur wrote: > Hi, > > Thanks again for your answer. > > I changed to the newest Debian image available for BeagleBone boards: > The Debian 9.5 - 4.14.71-ti-r80 > I disabled the usb "autosuspend" by issuing the command > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > I cannot say if now there is data coming from the USB as I cannot > understand the output what output? > But I still get errors from the driver when I check the dmesg: > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! This message means RX EP interrupt happens, but the RX FIFO has no data. I don't have any case showing this problem before, so not sure what causes the problem. Can you please try to disable MUSB CPPI DMA to see how it goes? You can disable it in kernel menuconfig. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Hi Stern, > > > First question: Does you get similar failures if you plug the device > > into a standard PC rather than the BeagleBone? > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > works (using exactly the same code I compile in the Beagle) > > > Second question: Have you tried looking at usbmon traces to see where > > the communication starts to fail? > > > > II tried now, I'm attaching the trace I get, which I cannot understand The usbmon trace shows a few errors in the musb-hdrc driver. Here are the relevant parts: dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0001 0004 4 < dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 This shows the system polling the root-hub port status. The return value indicates that the camera was just plugged into the port, but it also shows that the port is suspended, which makes no sense. The suspend bit remains set in later port-status queries. dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0 dcf39600 1096487621 C Co:1:001:0 0 0 dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < dcf39600 1096547461 S Ci:1:001:0 s a3 00 0001 0004 4 < dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 The shows the system telling the root hub to reset port 1. When the reset is finished, the status shows a reset-status change (which is correct) together with an enable-status change (which is wrong). (It also still shows that the port is suspended!) dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0001 0004 4 < dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 Following the enumeration of the USB camera, the system again checks the port status. The value shows an enable-status change, which is supposed to mean that the port has been disabled. But the port has not been disabled, as we can see from the fact that the enable-status bit is also set. The trace ends at this point. It does not show any communication failures like what you described in the original email message. > > > Should I load different usb modules in the system kernel? Should I > > > modify a given module? > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > try asking the maintainer for that driver. > > Ok, could you please provide me the e-mail address where to write? The maintainer is Bin Liu (CC'ed). And you should also remember to CC the linux-usb mailing list. Alan Stern > Thanks > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern wrote: > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > Hi > > > > > > I've recently acquired a BeagleBone Green with AM335x processor. I 'm > > > connecting a USB device (actually a 3D camera from ORBBEC) to the > > > Beagle USB host port. It recognizes well as I can see at the dmesg > > > output: > > > > > > [12411.643517] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > > [12411.784848] usb 1-1: New USB device found, idVendor=2bc5, > > > idProduct=0404 > > > [12411.784912] usb 1-1: New USB device strings: Mfr=1, Product=2, > > > SerialNumber=0 > > > [12411.784951] usb 1-1: Product: ORBBEC Depth Sensor > > > [12411.784986] usb 1-1: Manufacturer: Orbbec(R) > > > > > > However, when I try to read data from the camera using the OpenNi SDK > > > that ORBBEC provides for Arm devices, although I can connect to the > > > camera (in fact it toggles on the IR) I get a timeout and get no data > > > ever. The 'dmesg' output show the errors: > > > > > > [12446.755020] usb 1-1: usbfs: usb_submit_urb returned -121 > > > > > > Other users seemed to have this problem in the past, and it seems > > > related to the EHCI driver itself, > > > > The log message above indicates that the BeagleBone's USB host > > controller uses the musb-hdrc driver. This means it is not EHCI. > > > > > but I've not been able to find a > > > solution and need help urgently to solve this issue. > > > > > > The system version in my BeagleBoneGreen is Debian Debian 8.3 > > > (4.1.15-ti-rt-r43). In fact I've tested several versions including the > > > newest one available for BeagleBone (the debian 9.5 - 4.14.71-ti-r80), > > > but without success. In this case I got a different error from dmesg: > > > > > > Oct 17 16:59:29 arm kernel: [ 215.611056] musb_host_rx 1965: Rx > > > interrupt with no errors or packet! > > > Oct 17 16:59:29 arm kernel: [ 215.617649] musb_host_rx 1965: Rx > > > interrupt with no errors or packet! > > > Oct 17 16:59:29 arm kernel: [ 215.625557] musb_ep_program 916: broken > > > !rx_reinit, ep2 csr 0003 > > > > > > > > > Please I need some clues about this. > > > > First question: Does you get similar failures if you plug the device > > into a standard PC rather than the BeagleBone? > > > > Second question: Have you tried looking at usbmon traces to see where > > the communication starts to fail? > > > > > Should I load different usb modules in the system kernel? Should I > > > modify a
Re: Error reading USB camera in BeagleBone with ARM Debian
On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > Hi > > I've recently acquired a BeagleBone Green with AM335x processor. I 'm > connecting a USB device (actually a 3D camera from ORBBEC) to the > Beagle USB host port. It recognizes well as I can see at the dmesg > output: > > [12411.643517] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [12411.784848] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 > [12411.784912] usb 1-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [12411.784951] usb 1-1: Product: ORBBEC Depth Sensor > [12411.784986] usb 1-1: Manufacturer: Orbbec(R) > > However, when I try to read data from the camera using the OpenNi SDK > that ORBBEC provides for Arm devices, although I can connect to the > camera (in fact it toggles on the IR) I get a timeout and get no data > ever. The 'dmesg' output show the errors: > > [12446.755020] usb 1-1: usbfs: usb_submit_urb returned -121 > > Other users seemed to have this problem in the past, and it seems > related to the EHCI driver itself, The log message above indicates that the BeagleBone's USB host controller uses the musb-hdrc driver. This means it is not EHCI. > but I've not been able to find a > solution and need help urgently to solve this issue. > > The system version in my BeagleBoneGreen is Debian Debian 8.3 > (4.1.15-ti-rt-r43). In fact I've tested several versions including the > newest one available for BeagleBone (the debian 9.5 - 4.14.71-ti-r80), > but without success. In this case I got a different error from dmesg: > > Oct 17 16:59:29 arm kernel: [ 215.611056] musb_host_rx 1965: Rx > interrupt with no errors or packet! > Oct 17 16:59:29 arm kernel: [ 215.617649] musb_host_rx 1965: Rx > interrupt with no errors or packet! > Oct 17 16:59:29 arm kernel: [ 215.625557] musb_ep_program 916: broken > !rx_reinit, ep2 csr 0003 > > > Please I need some clues about this. First question: Does you get similar failures if you plug the device into a standard PC rather than the BeagleBone? Second question: Have you tried looking at usbmon traces to see where the communication starts to fail? > Should I load different usb modules in the system kernel? Should I > modify a given module? It certainly looks like a problem in the musb-hdrc driver. You might try asking the maintainer for that driver. Alan Stern
