**** BEGIN LOGGING AT Wed Jun 21 03:00:03 2017 Jun 21 05:37:12 how to upgrade to latest repository to install latest qt5 packages in beaglebone black Jun 21 09:37:40 Hi Jun 21 09:38:51 i wan to strem a vedio using my beaglebone black Jun 21 09:39:48 my BBB is connected to wifi and i wan to stream a vedio from a python server Jun 21 09:40:18 when i tried some methonds it gives me errors like MPEG-4 and H.264 plugins missing Jun 21 09:42:42 who gives you this error? Jun 21 09:47:57 when i run gst-launch on my beaglebone i get the error Jun 21 09:49:53 i want to run a python server on my pc and stream vedio from the server on beaglebone over wifi Jun 21 09:50:45 shaik: install the gstreamer plugins good bad ugly ffmpeg? Jun 21 09:51:38 i am actually using yocto project to build the BBB image Jun 21 09:52:50 so how to get these plugins Jun 21 09:53:23 shaik: ask the yocto people then Jun 21 10:12:50 good afternoon Jun 21 10:13:07 hi have some doubts regards uart enable Jun 21 10:13:21 in bbb Jun 21 10:13:57 i'm using kernel version 4.4.71 bone 17 Jun 21 10:14:25 linux ubuntu 16.04 Jun 21 10:41:44 anyone around that knows the beaglebone pretty good? :) Jun 21 10:43:07 My question is the following: Jun 21 10:43:26 In my project im using serveral SYSBOOT pins as outputs to drive some IC INPUTS Jun 21 10:44:11 my assumption was that this wouldnt disturb booting from SD card Jun 21 10:44:36 as the INPUTS of some IC should not be asserting a certain value Jun 21 10:45:04 i read that that pullup/down resistors on the beaglebone are weak Jun 21 10:45:57 do i maybe have to add stronger pullup/down resistors externally? Jun 21 10:46:11 if so what size and which pins to boot from SDcard? Jun 21 11:06:28 Hi All, I working on a custom board based on BBB , can i somehow burn the eeprom on board? or i must change the uboot? Jun 21 12:50:23 Hi folks, I am trying to get wl187 chip working on x15, but for some reason sdio interface is failing Jun 21 12:50:55 has anyone tried getting wilink chip on x15 which is connected to mmc3 Jun 21 13:06:03 Guest72596: using the sysboot pins as outputs is not a problem as long as the inputs of the external IC are genuinely high-impedance Jun 21 13:06:34 the pull resistors on the sysboot pins are 100Kohm Jun 21 13:08:09 in case of doubt you can indeed reinforce those with external pulls Jun 21 13:16:03 how do you unlock the root account in the latest image? Jun 21 13:17:06 just use sudo Jun 21 13:19:24 hi Jun 21 13:20:14 need help on enabling UART 1 on beaglebone black in ubuntu 16.04 lts Jun 21 13:20:37 can anyone help me on this Jun 21 13:30:00 sudo does not work with my SSH client Jun 21 13:30:56 it seems that unlocking the root account is best kept secret Jun 21 13:32:48 'sudo does not work with my SSH client' that doesn't make much sense. Jun 21 13:33:00 what is the error message you get? Jun 21 13:40:53 I use winSCP to manage files on the bone, when I login as debian, I don't have all the privileges Jun 21 13:41:32 do you know how to unlock the root account? Jun 21 13:42:28 then just copy the files to the machine and then move them to the right place. Jun 21 13:42:44 also make sure you do not mess up files with windows. it's too easy to do that. Jun 21 13:47:18 using WinSCP logged as debian as opposed to root, I cannot overwrite the /boot/uEnv.txt file to flash the image Jun 21 13:47:54 15:42 < phschafft> then just copy the files to the machine and then move them to the right place. Jun 21 13:47:58 15:42 < phschafft> also make sure you do not mess up files with windows. it's too easy to do that. Jun 21 13:48:11 also I would suggest just to use an editor on that machine to change the file. Jun 21 13:49:11 I prefer to enable root, do you know how to do that? Jun 21 14:01:50 lol... 15:30 < bernard_> it seems that unlocking the root account is best kept secret Jun 21 14:02:00 yes, very well kept... on the beaglebone debian wiki page Jun 21 14:02:26 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#i_take_full_responsibility_for_knowing_my_beagle_is_now_insecure Jun 21 14:03:23 How do I enable root on my personal "open source" beaglebone? It seems that some members of this community decided that we should not do that for our own protection. Bizzare. Jun 21 14:03:31 (or, the secure way is by using ssh public-key authentication) Jun 21 14:04:05 yes, they changed the defaults to be more secure, that's not a bad thing Jun 21 14:04:43 the bad thing is not allowing users to change it back Jun 21 14:05:02 did you just see I pasted a link with instructions on how to do exactly that? Jun 21 14:05:23 and there's a difference between not understanding to change it back and not being allowed to change it back Jun 21 14:05:47 with sudo you have root privileges on your beaglebone, hence you're *allowed* to do anything Jun 21 14:06:05 including changing the default settings to be as insecure as you want Jun 21 14:06:26 perfect, I want it as insecure as it can be. Thank you Jun 21 14:06:54 that's your right of course :) which is why they posted the instructions on the wiki Jun 21 14:07:39 thank you Jun 21 16:45:03 Hi zmatt! I am here again :-) Jun 21 17:13:55 anyone know of support for USB touch LCD display with drivers that work on latest kernel release? Jun 21 17:56:06 zmatt: do you found any solution to the "bus error" issue? Jun 21 18:02:59 he probably bought a ticket ... Jun 21 19:04:28 What is the smallest sdcard image for a beagle bone green without GUI things and for working with the PRU? Jun 21 19:08:52 NTQ: probably something you can crank out with openembedded, based on core-image-minimal :) Jun 21 19:12:52 The Beaglebone serves only as data acquisition device which pulls out data from a FPGA and sends it through network to a client machine. Maybe a browser or some dedicated software running on a laptop. Jun 21 19:13:27 how is that related to the question and given answer? Jun 21 19:13:49 hey zmatt just found some more interesting info on the board Jun 21 19:13:56 apparently it isnt a bbb Jun 21 19:14:11 its a bbgw with the hdmi chip and hdmi device added on Jun 21 19:54:34 All system images I can find are very big, up to 3,6 GB Jun 21 19:54:44 I am looking for something smaller. Jun 21 20:01:16 images are big because they are disk images Jun 21 20:01:47 if you setup the sdcard yourself and compile an os you can shrink it Jun 21 20:07:45 do you have a software background? Jun 21 20:07:58 NTQ: get a console image Jun 21 20:08:08 *thumbs up* Jun 21 20:08:16 http://www.jumpnowtek.com/beaglebone/Working-on-the-BeagleBone-kernel.html Jun 21 20:08:27 i found that guide very helpful if you wanna build one Jun 21 20:08:48 NTQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console Jun 21 20:08:57 hey zmatt, so it turns out i have a bbgw Jun 21 20:09:03 t_brah: my condolences Jun 21 20:09:07 ? Jun 21 20:09:25 hehe, the gw is one of the crappier bbb derivatives Jun 21 20:09:30 LOL Jun 21 20:09:51 well its a bbgw derivitive because i guess thats my life now Jun 21 20:10:18 t_brah: I am a software developer and administrator, so I have some background Jun 21 20:10:51 the most hilarious part about it is that they sacrificed a whole bunch of expansion I/O to hook up the wireless chipset, but they also gave up ethernet and left those pins unused Jun 21 20:11:01 NTQ: fantastic - you know what to do then Jun 21 20:11:16 the fun bit there is that the pins normally used for ethernet also include exactly the stuff you'd need for... the wireless chipset :D Jun 21 20:13:02 so this derivitive board: as we talked about earlier, it lacks an eeprom. they removed all the connectors, and they added a tda998x and a hdmi connector and strung it all together like its found on a bbb Jun 21 20:13:04 so they could have swapped out ethernet for wifi with zero sacrifice of expansion I/O (which is exactly what the bbbw did), and moreover that set of pins is on its own voltage domain that they could have powered at 1.8V thereby avoiding the need for level shifters (the wifi chipset requires 1.8V, not 3.3V) Jun 21 20:13:46 okay, so it's a sort of weird cross-breed of the bbb and the bbgw, minus eeprom Jun 21 20:13:55 yeah Jun 21 20:14:15 i somewhat grok the dts and dtsi files Jun 21 20:14:20 should be straightforward enough to glue together the relevant DT bits Jun 21 20:14:25 yup Jun 21 20:14:36 especially since there are variants for BBB with and without hdmi support Jun 21 20:14:45 so you can stick that diff onto the BBGW Jun 21 20:15:37 im thinking on ripping hdmi stuff out of am335x-boneblack-hdmi-overlay.dts and adding it to the am335x-bonegreen-wireless.dts file Jun 21 20:16:04 ill edit the am335x-bone-common file to remove the eeprom Jun 21 20:16:20 you can also override it with a directive Jun 21 20:16:26 ooooooo i like that better Jun 21 20:16:27 makes it easier to track upstream Jun 21 20:16:30 i didnt know you can do that Jun 21 20:16:52 google food: device tree override>? Jun 21 20:16:58 i can get deets from that? Jun 21 20:17:11 &device { status = "disabled"; }; should suffice Jun 21 20:17:12 what am i doing - im just gonna googler it Jun 21 20:17:17 oh, good Jun 21 20:17:47 if you consider the node to be a real eye-sore you can get rid of it entirely by doing &parent { /delete-node/ child_name; }; Jun 21 20:18:07 the parent node is the i2c0 bus so i cant do that Jun 21 20:18:19 it just deletes the child from that parent Jun 21 20:18:24 ahhhh gotcha Jun 21 20:18:59 my god thats just makes too much sense Jun 21 20:19:05 thanks matt! Jun 21 20:19:42 using status = "disabled"; should be equally effective though, and might be safer Jun 21 20:19:56 yeah i was gonna go with that first Jun 21 20:20:13 iirc you can get trouble with dangling references otherwise or something Jun 21 20:21:43 im gonna copy the am335x-bonegreen-wireless.dts file, and add these overrides in a new dt file. makes more sense Jun 21 20:21:58 or just #include "am335x-bonegreen-wireless.dts" Jun 21 20:22:00 :) Jun 21 20:23:08 copy/paste makes nobody happy Jun 21 20:23:32 omg thats a much better idea Jun 21 20:23:56 thank you zmatt, that is a lot better Jun 21 20:23:57 now if only they had stuck the hdmi stuff into a .dtsi then you'd only need to include that too Jun 21 20:24:13 yeah... its in an overlay Jun 21 20:24:20 ill just rip the relevant bits out Jun 21 20:24:25 it's not an overlay Jun 21 20:24:32 the naming of those dts files is a bit... odd. Jun 21 20:24:41 O__O oh Jun 21 20:24:52 am335x-boneblack-hdmi-overlay.dts is am335x-boneblack.dts minus eMMC Jun 21 20:26:06 if i copy the include up top (for defs) as well as the nxp_hdmi_bonelt_pins nodes i should be okay, right? Jun 21 20:26:36 (and lcdc, and the i2c0 child node... etc) Jun 21 20:26:46 yeah something like that Jun 21 20:26:58 im comparing the sound node between the bbb and bbgw Jun 21 20:27:30 theyre a little different - do i just merge the diffs in sound? Jun 21 20:27:44 bbgw has a sound node? Jun 21 20:28:15 I don't see any Jun 21 20:28:17 yeah its in am335x-bonegreen-wl1835.dtsi Jun 21 20:28:23 oh that Jun 21 20:29:12 hm Jun 21 20:29:25 I think you're going to need to check your hw people on that Jun 21 20:29:56 can i just use the nhdmi stuff then? Jun 21 20:29:57 since we've got a merge conflict here :) Jun 21 20:30:06 well that depends on what's actually correct for your hw Jun 21 20:30:07 screw it - no sound! Jun 21 20:30:41 i.e. is mcasp0 being used for hdmi audio or for bluetooth audio... Jun 21 20:30:48 (or possibly both) Jun 21 20:31:34 note that that afaik the /sound node isn't a special name in any way, it might as well be called /pizza ... so it wouldn't be a problem to have both the sound node from bbgw and the one from bbb Jun 21 20:31:43 the problem however is that they're both using mcasp0 Jun 21 20:32:11 and I'm guessing also fight over some pins, but I'm too lazy to check :) Jun 21 20:39:53 youte 100% right the bbgw uses that node Jun 21 20:40:24 however in the board design i was given all the wl1835 pins for bluetooth have been pulled to ground Jun 21 20:40:44 GPIO pins 1 2 and 4 are also disconnected Jun 21 20:40:47 what the fuck is our ee doing Jun 21 20:41:50 so... looks like i need to override the sound node Jun 21 20:42:56 I wonder if it might be easier to copy the relevant bits... though overriding is certainly also possible Jun 21 20:43:11 ill just copy it over Jun 21 20:43:27 yeah it looks like a lot of cruft otherwise Jun 21 20:46:25 wilink gpio 1/2/4 are typically just connected to test pads, gpio1/2 form a serial debug interface for the wifi Jun 21 20:46:48 grounding the bluetooth pins sounds dodgy... datasheet says "NC if not used" Jun 21 20:47:29 ok, gonna catch a bus Jun 21 21:14:15 Again I need some advices from you, guys. I finished booting the console only jessie image and install build-essentials. Before starting my PRU overlays and need to be sure uEnv.txt is correctly configured. Jun 21 21:16:42 There are several lines with dtbo files which are commented out. That is its content: https://pastebin.com/X7mzPu87 Jun 21 21:23:25 you used the debian standalone console image, yeah? Jun 21 21:25:12 actually, sorry NTQ, nevermind the question Jun 21 21:25:32 NTQ: from what i see in the pastebin, it appears your config is sane Jun 21 21:26:21 t_brah: I later want to add my own overlay. Jun 21 21:26:28 NTQ: the commented out sections are for cape overrides Jun 21 21:26:45 NTQ: does it boot? Jun 21 21:26:53 yes Jun 21 21:27:08 I already apt-getted some packages Jun 21 21:30:54 I am trying to echo the name of my dts file to /sys/devices/platform/bone_capemgr/slots Jun 21 21:31:49 And then it hangs. The OS is not freezed. In a second terminal I can work without problems. Jun 21 21:32:35 And the "echo" command uses 100% of CPU Jun 21 21:32:40 hmm Jun 21 21:32:58 whats your dmesg say Jun 21 21:33:17 SIGKILL, SIGQUIT and SIGTERM are not working Jun 21 21:33:52 can you get your dmesg in a pastebin? Jun 21 21:33:59 give me a second Jun 21 21:34:12 Just installing pastebinit ;-) Jun 21 21:35:06 thats a cool program! Jun 21 21:35:10 thanks Jun 21 21:35:22 (im installing it now) Jun 21 21:35:36 Would be nicer if it would not depend on python ^^ Jun 21 21:35:54 There it is: http://paste.debian.net/972662/ Jun 21 21:42:40 Is there a BBB starter kit you would recommend? Jun 21 21:44:01 t_brah: I have no idea what I could read out of dmesg Jun 21 21:44:32 Looking for a good BBB starter kit, like the adafruit kit Jun 21 21:47:35 nate: https://www.amazon.com/Beagleboard-Beaglebone-Starter-Case-Power-Supply-Micro/dp/B00P6TV9V4/ref=sr_1_2?ie=UTF8&qid=1498081632&sr=8-2&keywords=BeagleBone+Black Jun 21 21:48:19 nate: the only advantage to a starter kit is that it has a lot of useful extras Jun 21 21:48:29 nate: you can find documentation online Jun 21 21:48:38 ayjay_t: I saw that, seems like it isn't worth it Jun 21 21:49:10 just buy a beaglebone black - you will be fine Jun 21 21:49:13 microusb? why on earth do they include that? Jun 21 21:49:30 zmatt: to make money Jun 21 21:49:59 NTQ: the lines 467 - 469 seem of interest Jun 21 21:50:06 zmatt: Could my bus error also come from to less current? At the moment I power my beaglbone only from ma laptops usb port. Jun 21 21:50:42 sounds implausible Jun 21 21:50:49 t_brah: That are the lines which appears when I try to write "prudaq" to /sys/devices/platform/bone_capemgr/slots Jun 21 21:51:58 NTQ: thats why its interesting - it's halting after the third message Jun 21 21:52:04 do you have iotop on the board? Jun 21 21:52:15 I can install it Jun 21 21:52:20 NTQ: you're trying to load uio_pruss while remoteproc-pru is already loaded Jun 21 21:52:40 zmatt: And that's something I can disable i uEnv.txt? Jun 21 21:53:17 which kernel are you using currently? Jun 21 21:53:25 ah I see it Jun 21 21:53:44 try installing the latest 4.4-bone kernel Jun 21 21:53:59 zmatt: What was the command to do that again? Jun 21 21:54:44 sudo apt-get install linux-image-4.4.73-bone18 Jun 21 21:55:08 thank you Jun 21 21:55:16 may need to do sudo apt-get update first (only necessary if you haven't done so already in the last day or so) Jun 21 21:55:40 It's a fresh image from today but I already did an update Jun 21 21:55:59 update-initramfs... Jun 21 21:56:17 apt-get update is just to download the latest package listings Jun 21 21:56:27 I know Jun 21 21:56:29 ok Jun 21 21:56:41 It also updated uEnv.txt Jun 21 21:57:08 rebooting now Jun 21 21:59:43 ew, I just spotted line 11 of your uEnv.txt Jun 21 22:00:05 Still hanging on echoing "prudaq" to that file Jun 21 22:00:33 .... and line 42 ... Jun 21 22:00:34 zmatt: Should it be 0? Jun 21 22:01:28 to be honest I have no idea what the path of least resistance is here... I don't use any of that crap (runtime overlays, cape-universal, u-boot overlays) Jun 21 22:01:52 ^^ Jun 21 22:02:31 I guess it might be easier to just leave cape-universal enabled, don't use an overlay for pinmux, but just load whatever overlay is needed to enable pruss (if any) and use config-pin to setup pinmux Jun 21 22:04:01 u-boot overlays takes a horrible way to do hardware setup, namely overlays, and removes its sole redeeming feature - ability to do dynamic configuration at runtime Jun 21 22:04:23 I just don't understand them Jun 21 22:05:16 So if I use config-pin I can change pin modes during runtime? Jun 21 22:06:01 yeah that's a feature of cape-universal... which itself is also a horrible hack, but at least I can understand it is more convenient for newbies Jun 21 22:08:36 Okay. I will google it Jun 21 22:11:29 btw can you pastebin your current kernel log? Jun 21 22:12:38 and maybe try loading the AM335X-PRU-UIO overlay Jun 21 22:13:15 ohey, it's on line 39 of uEnv.txt Jun 21 22:13:28 maybe we should learn to read Jun 21 22:13:56 and comment out line 37, that one is causing much of the trouble Jun 21 22:15:14 syntax highlighting would have made it much easier to spot these: https://hastebin.com/tuvenigidu Jun 21 22:18:33 give me a moment. Jun 21 22:40:23 yay, I seem to have gotten uio_pruss functional on 4.4.73-bone18 ... at least, my overlay loads without error, /dev/uio* devices show up, and pinmux seems to have been done Jun 21 22:40:32 the patches rcn applied helped :) Jun 21 22:44:59 hm.. With line 39 enabled and 37 disabled it also does not work. Jun 21 22:45:55 Still hanging at "echo prudaq > /sys/devices/platform/bone_capemgr/slots" Jun 21 22:46:42 yeah no, that overlay doesn't work in combination with cape-universal Jun 21 22:46:54 but it's also no longer needed, probably pruss is now already enabled Jun 21 22:47:24 there are two separate things going on here: enabling pruss and doing pinmux Jun 21 22:47:48 enabling line 39 instead of 37 should get pruss enabled with the correct driver Jun 21 22:48:08 iirc your overlay actually only did pinmux, and that's conflicting with cape-universal Jun 21 22:49:00 After disabling cape-universal it also does not work. Jun 21 22:49:31 kernel log? Jun 21 22:49:51 oh actually, hdmi will then probably conflict Jun 21 22:50:10 There is no hdmi on my bbg. Here is the kernel log: http://paste.debian.net/972667/ Jun 21 22:50:15 oh right duh Jun 21 22:51:15 this still has cape-universal enabled Jun 21 22:52:25 hm Jun 21 22:52:40 I changed the line to enable_uboot_cape_universal=0 Jun 21 22:52:55 Do I also have to disable enable_uboot_overlays? Jun 21 22:53:08 probably you need to comment it out rather than changing the value Jun 21 22:53:27 okay? Thats's bad design ^^ Jun 21 22:54:55 fwiw, how I just got it working is quite different... I have this /boot/uEnv.txt : https://hastebin.com/gequwatulo.ini to ensure hdmi is disabled (since I do have a bbb), no u-boot overlays or cape-universal, and then I used this overlay: https://github.com/mvduin/overlay-utils/blob/master/pruss-00A0.dtsi (to build dtbo, clone the repository and do "make pruss-00A0.dtbo") Jun 21 22:55:02 yeah. works now Jun 21 22:55:44 your dts file looks less complicated than mine Jun 21 22:56:10 and nearly half of it is just metadata Jun 21 22:56:50 note that my overlay-utils project uses a perl script to convert a .dtsi file into the horrible syntax required for overlays (and then pipes that into dtc) Jun 21 22:57:34 I don't understand why dtc didn't simply use normal syntax like this for overlays, but oh well Jun 21 22:58:14 Now I get a new error: error while loading shared libraries: libprussdrv.so: cannot open shared object file: No such file or directory Jun 21 22:58:20 But I think that is an easy one. Jun 21 22:58:41 use "ldd" to check for missing shared libraries Jun 21 22:59:23 I know. Now I need to find its package name... Jun 21 23:00:02 which lib? Jun 21 23:00:30 libprussdrv.so Jun 21 23:01:59 oh, what's actually package? that would have to be pru-software-support-package then? Jun 21 23:02:21 sounds promising Jun 21 23:03:17 but did not help. I will find it next time. For today I will go sleeping. Jun 21 23:03:20 nope Jun 21 23:03:23 not in there Jun 21 23:03:28 I'd say just build from source Jun 21 23:03:57 okay Jun 21 23:04:00 next time :-) Jun 21 23:04:04 Thank you for your support Jun 21 23:04:32 or even just link it into your program instead of making it a shared library, it's only one file I think Jun 21 23:04:41 np :) Jun 21 23:05:21 see you next week ;-) Jun 21 23:11:46 oh god, I looked at the source code of prussdrv .... HOW CAN I UNSEE Jun 22 01:38:34 Hello. Noob here. Looking for a Raspberry Pi like solution, possibly the BeagleBone Black. However I can't seem to find the IO speeds. Anyone know? Jun 22 01:38:57 what is your application? Jun 22 01:41:00 Trying to interface with a front side bus and have 350ns to do so. So I would like to get 35-45 bits of data in and about 12bits back out in most cases. Jun 22 01:41:17 In each clock cycle. Jun 22 01:41:42 have you seen the PRU's ? sounds like a good target for them tbh Jun 22 01:42:28 I did not. You have a link to something specific in mind, or I'll just google it? Jun 22 01:42:57 I like the Pi or BBB since low cost and lots of standard features, and the ability for the basic user to code for apps. Jun 22 01:43:32 The Pru's are Real-time cores unique to the Beagle AM335x processor .. so you can run separate code fast in them, and do processing in userspace Jun 22 01:44:18 there's two in the CPU, with access to IOs, memory, etc Jun 22 01:45:15 Interetsing. That may work. And it's on the BBB? Or another solution. Jun 22 02:02:44 they're part of the AM335x that's on the BBB Jun 22 02:03:35 how wide is the bus you're trying to interface with? Jun 22 02:04:46 "35-45 bits of data in and about 12bits back out in most cases. In each clock cycle." ... that sounds rather vague, do you mean the bus is 57 bits wide? Jun 22 02:06:26 in general it does sound like exactly the sort of thing PRU is excellent at, but a really wide interface may get trickier **** ENDING LOGGING AT Thu Jun 22 03:00:01 2017