**** BEGIN LOGGING AT Fri Dec 09 03:00:02 2016 Dec 09 09:53:11 Hi guys. I have a BBB in which i have installed opencv. I am trying to capture images from a program which is using OpenCV. But it return green image when i have 640x480 resolution. If i select 320x240 it captures image but with distorting lines as shown. https://i.stack.imgur.com/yIoQF.jpg Dec 09 09:53:32 I later tried to capture using ffmpeg and wswebcam commands but i get the same issue Dec 09 09:53:42 are you capturing video or single images? Dec 09 09:53:52 single image Dec 09 09:54:00 i skipped few frames too Dec 09 09:54:45 I've too often seen and heard of trouble with cams due to usb autosuspend Dec 09 09:54:57 echo -1 >/sys/module/usbcore/parameters/autosuspend Dec 09 09:55:28 (you might need replug the camera, not sure) Dec 09 09:56:04 if that fixes the problem you can make it the default at boot by adding usbcore.autosuspend=-1 to your kernel parameters ("cmdline=..." in /boot/uEnv.txt) Dec 09 09:57:10 well just ran this command and i am still getting distorted lines Dec 09 09:57:17 let me replug and repeat this Dec 09 09:58:09 you can set autosuspend per device, so probably this global setting is only used as default when you plug a device in Dec 09 10:01:53 per-device setting would be e.g. /sys/bus/usb/devices/2-1.4/power/autosuspend (replace 2-1.4 by the appropriate id of course) Dec 09 10:38:40 zmatt i tried autosuspending per device but same issue :/ Dec 09 10:38:53 disabling autosuspend you mean Dec 09 10:39:14 yep Dec 09 10:39:55 then I'm not sure, try inserting a powered usb hub between the bbb and the camera? (in case it's a power-related problem) Dec 09 10:41:17 we actually tried to connect camera directly to BBB but i got the same issue. plus i am using 2uA power adaptor Dec 09 10:41:27 so i think power is not issue here Dec 09 10:43:01 2A you mean, but the BBB's power supply is not quite the only issue Dec 09 10:43:32 when you say "we actually tried to connect camera directly to BBB", was it before that connected via a self-powered hub or via a bus-powered one? Dec 09 10:45:08 self-poweredhub Dec 09 10:45:49 ok, so not power-related then Dec 09 10:46:10 odd Dec 09 10:47:39 the "distortion" your image shows is also very very strange... it looks like those lines are shifted/rotated horizontally? Dec 09 10:48:11 yep distrotions looks like these particular rows are shifted Dec 09 10:48:20 and they seem regularly spaced Dec 09 10:48:57 does it always give the same type of distortion? (for that resolution) Dec 09 10:49:13 nope it changes its positions Dec 09 10:49:18 hmm Dec 09 10:49:21 most of the time it stays Dec 09 10:50:43 I don't suppose you happen to know whether it uses a bulk endpoint or an isochronous endpoint for capturing single images? :) Dec 09 10:51:00 ehhhh what Dec 09 10:51:01 lol Dec 09 10:52:24 isochronous doesn't use CRC protection on the data, for applications where the risk of corruption is preferable to delays Dec 09 10:52:31 e.g. webcams Dec 09 10:52:57 I was just trying to think where this distortion could come from Dec 09 10:53:00 so in general webcams use bulk endpoints Dec 09 10:53:12 I've never surveyed them Dec 09 10:53:41 welll its logical too for webcams to use bulk endpoint Dec 09 10:53:43 SK_: just to be on the safe side, if you connect the cam to your laptop it works? Dec 09 10:53:59 yep they work perfectly thinkfat Dec 09 10:56:49 just checked, it looks like my laptop's webcam has no bulk endpoints whatsoever Dec 09 10:59:43 so, usb 2 is pretty sensitive... if there are signal integrity problems going on then it would manifest itself as slowdown on non-isochronous endpoints (due to CRC failes and retransmissions) and noise/interference on isochronous endpoints Dec 09 11:00:00 I still wouldn't expect to see *this* though, but honestly I can't produce a mental model yet of what could Dec 09 11:00:46 ok Dec 09 11:01:09 it might be interesting to see what happens if you limit the usb interface to "Full Speed" instead of High-Speed, but I don't know if a cam accept that Dec 09 11:11:57 in case you might want to try it: this is done by adding a Device Tree property: Dec 09 11:11:59 &usb1 { maximum-speed = "full-speed"; }; Dec 09 11:12:05 anyway, I gtg Dec 09 11:12:16 good luck! Dec 09 12:15:41 debug BeagleBoard x15 Dec 09 12:15:48 help Dec 09 12:24:45 hi all. i got a question. if i put a sd card into my bbg wireless, will the bbg boot from sd or mmc? Dec 09 12:24:53 i dont push boot button Dec 09 12:30:40 depends on the boot script in eMMC Dec 09 12:32:07 afaik it prefers to boot from sd is a valid image is present there, but I haven't looked into that in ages since I rarely use cards Dec 09 12:32:18 *if a valid image is present Dec 09 12:32:32 zmatt i failed to find that device tree. upon finding *.dts i had many files. not sure where should i add that property Dec 09 12:33:16 SK_: the default main device tree depends on hardware, e.g. am335x-boneblack.dts for the BBB Dec 09 12:33:34 see also http://elinux.org/BeagleBone_DTBs for a bit more overview of the differences Dec 09 12:35:23 can i type in a command to check wether system was booted from sd or emmc? Dec 09 12:37:58 findmnt / shows which block device is mounted as root filesystem Dec 09 12:39:02 if you have a sufficiently recent kernel then mmcblk0 is always sd and mmcblk1 is always eMMC Dec 09 12:41:16 eMMC is also instantly recognizable since it has two special boot partitions that show up in /dev Dec 09 12:45:25 i have added line in am335x_boneblack.dts Dec 09 12:45:39 should i genereate its output or simple restart will work Dec 09 12:45:40 ?? Dec 09 12:46:55 https://github.com/RobertCNelson/dtb-rebuilder you can use that to rebuild your dtb Dec 09 12:47:27 it also includes the latest dts files for beagleboards and beaglebones Dec 09 13:04:56 thx zmatt Dec 09 13:06:13 i want to use can0 with my bbg wireless. i use virtual cape right now: echo BB-CAN1 > /sys/devices/platform/bone_capemgr/slots Dec 09 13:06:18 is there a better way? Dec 09 13:06:49 do i have to use dtb/dts? Dec 09 13:07:01 you can use cape-universal, overlays ("virtual capes"), or just make a customized main device tree Dec 09 13:07:09 * zmatt prefers the last option Dec 09 13:07:43 ok, is there a nice tutorial somewhere? Dec 09 13:08:09 i bought the book from derek molloy. but itś bbb and debian 7.9 Dec 09 13:08:24 i am a beginner, and i cant really use it Dec 09 13:09:03 good docs, *uptodate* docs, are annoyingly scarce :/ Dec 09 13:10:44 there isn't much difference of course between the bbg-wireless and the bbb, except that you have less expansion header pins available for free use Dec 09 13:11:42 which is quite moronic of them, since they had sacrificed ethernet which frees up a whole set of pins which afaik could have supported the wireless chipset Dec 09 13:12:24 zmatt: which wireless chipset did they use, wilink? Dec 09 13:12:26 so if you need a bbb, you would buy a bbb with wifi-stick and not a bbg-wireless? Dec 09 13:13:00 wl18xx Dec 09 13:13:48 mhm, that needs a sdio interface and a uart, IIRC Dec 09 13:14:04 wl18xx indeed. the beaglebone black wireless actually did reuse the ethernet pins for wifi/bluetooth Dec 09 13:14:11 thinkfat: those are available as mux options on the ethernet pins Dec 09 13:14:55 and they're even in a separate i/o supply domain so they could have run that set of pins on 1.8V and thereby avoid the need for level-translators Dec 09 13:15:21 the black however uses the osd335x so they didn't have that option Dec 09 13:15:29 zmatt: I understand from past experience that TI is more than happy to sprinkle level shifters all over the place Dec 09 13:16:02 BBGw_Rookie: I've never felt any urge to have wifi on a beaglebone to be honest Dec 09 13:16:12 zmatt: in fact I think they make SoCs only as an excuse to sell level shifters Dec 09 13:16:15 but I definitely would not sacrifice ethernet for it Dec 09 13:16:18 thinkfat: lol Dec 09 13:16:28 thinkfat: the SoCs would also very much prefer 1.8V Dec 09 13:17:59 BBGw_Rookie: I actually got two BBEs (BeagleBone Enhanced) which indeed included a usb hub chip and an usb wifi chipset Dec 09 13:18:30 hence no sacrifice of I/O, no sacrifice of ethernet (which they upgraded to gigabit), and it has an extra usb host port :) Dec 09 13:18:43 (haven't had any chance to play with them though) Dec 09 13:31:45 BBGw_Rookie: btw when I said "sufficiently recent kernel" earlier (w.r.t. mmc device numbering stability), apparently that currently means 4.9-rc4-bone2 or later hehe Dec 09 13:33:41 well full speed is not applied to this Dec 09 13:33:56 i builded dts as instructed Dec 09 13:34:02 built* Dec 09 13:34:32 I know that property should work, I've used it myself Dec 09 13:38:02 than i might have not built it correctly Dec 09 13:38:05 let me try again Dec 09 13:41:37 you can also inspect /proc/device-tree (deprecated) or /sys/firmware/devicetree/base (the new location) to see the property shows up Dec 09 13:43:38 afk Dec 09 13:48:57 where should be i looking at Dec 09 13:49:07 sorry but i am doing these stuff for the first time Dec 09 13:50:05 It seems like zmatt was suggesting try the new place, and if it's not there, try the old one. Dec 09 13:50:19 Ragnorok: new/old place? Dec 09 13:50:23 he set a property Dec 09 13:50:55 SK_: uhh, I think something like /proc/device-tree/ocp/usb@47400000/usb@1c00/ ? Dec 09 13:51:05 That's what I get for seeing half a convo. I'll stop now. Dec 09 13:51:20 I'm not using the same kernel/DT as you so there may be small differences in the path Dec 09 13:52:27 alternatively, do: cd -P /sys/bus/usb/devices/usb1 Dec 09 13:54:11 then look for the of_node symlink while climbing upwards... for me it was in ../../ Dec 09 13:55:27 lrwxrwxrwx 1 root root 0 Dec 9 14:52 /sys/bus/usb/devices/usb1/../../of_node -> ../../../../../firmware/devicetree/base/ocp/usb@47400000/usb@1c00/ Dec 09 13:55:43 I don't think I've often seen ls spit out such a long line :D Dec 09 13:59:20 now really afk Dec 09 14:33:12 i have something like this Dec 09 14:33:16 lrwxrwxrwx 1 root root 0 Dec 31 20:54 of_node -> ../../../../../firmware/devicetree/base/ocp/usb@47400000/usb@47401800 Dec 09 15:07:15 SK_: yeah, same thing.... sort of Dec 09 15:07:26 yep Dec 09 15:11:58 (1c00 is the actual "musbmhdrc" core of usb1 while 1800 is the base address for the larger block that wraps around it and its PHY) Dec 09 15:12:48 Hi, can anybody help me in a wireless driver issue ? Dec 09 15:14:52 so much fun, all those wireless beagles Dec 09 15:15:34 well i think we wont get to anywhere Dec 09 15:15:40 should i change my BBB Dec 09 15:15:41 ?? Dec 09 15:16:02 or should i flash new image to my current BBB Dec 09 15:16:06 ?? Dec 09 15:17:06 SK_: ¯\_(ツ)_/¯ Dec 09 15:17:23 SK_: I have no idea what could be the cause of your problems Dec 09 15:18:48 alright bro thanks anyways Dec 09 15:18:57 i will try to reflash new image in BBB Dec 09 15:18:59 I'm fairly certain it's either software or hardware ;P Dec 09 15:19:07 simply a driver change: I've installed a tp-link TL-WN725N(v2) : it is immediately recognized and r8188eu module installed but it is working bad, disconnections and packet loss Dec 09 15:19:26 otherwise i will get new BBB Dec 09 15:19:30 Any ways thanks man Dec 09 15:19:40 :p Dec 09 15:19:48 SK_: did you test it on another linux system? Dec 09 15:19:54 I have compiled a new module 8188eu.ko , removed previous one and loaded manually with modprobe: it works fine Dec 09 15:20:03 (not just another computer) Dec 09 15:20:31 SK_: to exclude the possibility of some driver having issues with this particular cam Dec 09 15:20:50 but at every reboot the previous one is loaded instead, what to do to load the new one automatically ? Dec 09 15:21:18 fred_tv: the module is being overwritten in /lib/modules/ ? Dec 09 15:21:40 not overwritten, it has a different name Dec 09 15:22:06 or do you just mean the wrong one is loaded at boot even though it's no longer in /lib/modules/ ? Dec 09 15:22:56 be sure to run depmod if you manually install modules, and update your initramfs if you use one Dec 09 15:23:19 older one untouched, new one addedd to /lib/modules: how to tell system to use that one instead of old one ? Dec 09 15:24:49 both will claim to support the device so I think the result is probably unpredictable unless you remove the old one (again be sure to run depmod) or alternatively blacklist it in modprobe.d Dec 09 15:24:59 i tested whole scenario on other BBB too... and it is working perfect... no issues Dec 09 15:25:07 SK_: weeeeeird Dec 09 15:27:19 yes depmod -a Dec 09 15:27:34 hmm, I might need to get some sleep soon... I noticed I seem to be dropping frames now and then Dec 09 15:27:53 -a is default if no filenames are provided as arguments Dec 09 15:29:11 where is the list of modules to install at boot ? Dec 09 15:30:11 usually modules are loaded in response to device discovery Dec 09 15:31:13 where "discovery" in this case mostly means reading the DT and asking "can any driver handle this compatible-string?" Dec 09 15:31:23 and....if I overwrite the old one renaming the new one ?... Dec 09 15:31:57 the name isn't really important, depmod scans each module for their tables of "I support these devices" data Dec 09 15:33:17 so, blacklist the older one is the solution ? Dec 09 15:33:31 if for some reason you want to leave the old one installed, yes Dec 09 15:33:57 just echo 'blacklist nameofdriver' >/etc/modprobe.d/pick-some-nice-name.conf Dec 09 15:34:24 and presumably update initramfs (if you use one) Dec 09 15:35:22 how to update initramfs ?? (what a noob :-(((( ) Dec 09 15:36:21 update-initramfs -u Dec 09 15:37:25 ok Dec 09 15:37:32 i'm trying.... Dec 09 15:41:03 yeah, it works !! Dec 09 15:41:48 \o/ Dec 09 15:42:18 and...if I want to remove the old one rather than blacklist it ? Dec 09 15:43:29 then just remove it? Dec 09 15:43:42 (and run depmod, and update ini... oh you get the point) Dec 09 15:43:46 but Dec 09 15:45:11 simply remofe the file and run depmod ? Dec 09 15:45:31 but if the module was part of a normal kernel package (i.e. not manually installed) Dec 09 15:46:02 then whenever you upgrade or otherwise switch kernel version you'd have it installed again Dec 09 15:46:40 how can I chek this ? Dec 09 15:46:40 so blacklisting is probably a more durable solution Dec 09 15:47:35 (a similarly robust solution for a custom-compiled kernel module is using DKMS, which would automatically recompile on every kernel update Dec 09 15:47:38 ) Dec 09 15:49:52 consider I'm always using bone-debian-8.6-console-armhf-2016-10-06-2gb.img from official site..... Dec 09 15:54:09 I don't see it anywhere Dec 09 15:54:33 also, never updating your system sounds like a bad policy Dec 09 16:01:27 yes, removed....., console one is very fast on bbwhite (as I don't need LCD for most applications) Dec 09 16:03:02 yeah the few times I started with a clean slate I also used the console image as starting point Dec 09 16:25:20 got to go Dec 09 16:25:30 still thank you Dec 09 22:18:47 I would like to hack the kernel for an application but am having difficulties. Dec 09 22:19:53 So far I've found multiple sets of instructions as to how but none of them seem to work. Dec 09 22:20:42 MikeP, what kernel (uname -r) are you trying to rebuild/hack? Dec 09 22:21:21 I'm just starting out so I have a blank slate. Any suggestions? Ive got a bbb. Dec 09 22:21:57 MikeP, if you just "starting out".. start with: https://eewiki.net/display/linuxonarm/BeagleBone+Black Dec 09 22:22:10 it's step by step from bootloader, kernel, rootfs... Dec 09 22:23:20 I just did the uname and got back 3.8.13-bone79 Dec 09 22:24:40 Actually I tried that one but it says that several i386 files are not available. Dec 09 22:25:31 MikeP, those directions assume your building from a linux based x86.. if you want to build on the beagle, you can do that.. it jus ttakes hours and hours for the kernel to build.. Dec 09 22:26:10 Oh so you were asking what my build machine is? Dec 09 22:26:24 MikeP, no.. Dec 09 22:28:06 When I run build_kernel I'm told I need to apt-get some files. Dec 09 22:28:18 I attempt to and am told: Dec 09 22:28:32 that's normal, so can't you install them? the linaro toolchain had 32bit dependcies... Dec 09 22:28:37 Package libc6:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package zlib1g:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, Dec 09 22:28:49 like that.. Dec 09 22:28:55 MikeP, what linux system are you using? fedora/ubuntu/debian? Dec 09 22:29:15 debian jessie on a 64 bit core Dec 09 22:30:05 Those scripts are developed on Debian Stretch 64bit... Dec 09 22:30:12 it should tell you to run two commands: Dec 09 22:30:54 yep ... apt-get update and then the install Dec 09 22:32:30 it shouldn't be this hard.. Dec 09 22:32:55 can you pastebin the exact thing that shows up with "./build_kernel.sh" Dec 09 22:33:20 ok.. one moment.. Dec 09 22:34:34 bb-kernel$ sudo apt-get install device-tree-compiler lzma lzop gettext libc6:i386 libncurses5:i386 libstdc++6:i386 zlib1g:i386 Reading package lists... Done Building dependency tree Reading state information... Done Package libc6:i386 is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package zlib1g:i386 is not available, but Dec 09 22:35:03 MikeP, use http://pastebin.com/ ... copy everything from "./build_kernel.sh" -> where it stops... Dec 09 22:35:15 ok.. Dec 09 22:36:56 weird.. it won't paste.. Dec 09 22:37:15 ./build_kernel.sh + Detected build host [Debian GNU/Linux 8.6 (jessie)] + host: [x86_64] + git HEAD commit: [8ed8a408bfea1cac86e829cae689681678f91f9c] Debian/Ubuntu/Mint: missing dependencies, please install: ----------------------------- sudo apt-get update sudo apt-get install device-tree-compiler lzma lzop gettext libc6:i386 libncurses5:i386 libstdc++6:i386 zlib1g:i386 ----------------------------- * Failed dependency check Dec 09 22:37:28 ahh a leading / did me in.. Dec 09 22:38:58 hold on, fireup up a linode vm.. Dec 09 22:42:30 MikeP, you should see this on a fresh install: https://paste.debian.net/901487/ Dec 09 22:44:34 MikeP, and then all of them are installable by default.. https://paste.debian.net/901488/ Dec 09 22:44:45 ok... I'll wipe everything and start over (again) Dec 09 22:45:15 this is a branch new Debian Jessie 64bit build, so i'm guessing hte i386 muilt-arch option got messed up somewhere.. Dec 09 22:46:28 we only need 32bit for ti's sgx/sdk crap.. so if you don't use that.. un-comment these 3 lines: https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.4/tools/host_det.sh#L552-L554 Dec 09 22:47:00 as the linaro gcc-5.x is built for 64bit.. Dec 09 22:54:32 ok I did the previous instructions and got the same result Dec 09 22:54:56 ill look at the git hub link now.. Dec 09 23:00:54 yep... that seemed to fix things.. it's grinding now on the compile.. Dec 09 23:00:58 thanks.. **** ENDING LOGGING AT Sat Dec 10 03:00:00 2016