**** BEGIN LOGGING AT Thu Feb 19 02:59:58 2015
Feb 19 04:08:15 * vagrantc wonders if tilcdc is actually what drives hdmi out
Feb 19 04:11:11 <rcn-ee> vagrantc, did you force fbdev in xorg.conf? modesetting should also work, thou it tends to lock up..
Feb 19 04:11:45 <rcn-ee> borrow this xorg.conf: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-HDMI
Feb 19 04:12:12 <rcn-ee> yeah, you need gpio-backlight config..
Feb 19 04:12:55 <vagrantc> aha!
Feb 19 04:13:02 <vagrantc> yeah, not enabled...
Feb 19 04:13:09 * vagrantc runs off to build a kernel
Feb 19 04:14:17 <rcn-ee> That one might be worth it to bug your kernel guys, lots of boards are having gpio-backlight usage..
Feb 19 04:16:43 <rcn-ee> btw, since your rebuilding, also check on CONFIG_TOUCHSCREEN_TI_AM335X_TSC  according to my debian config delta, you guys have that disabled too...
Feb 19 04:18:24 <rcn-ee> nm, i moved it from a module to builtin... that one is fine..
Feb 19 05:16:43 <satish> hi i am unable to control the LED;s in beaglebone black using eclipse CDT environment. i have installed all requirements. pls do send the complete procedure of programming on BBB using c/c++(eclipse). i am using 32 bit windows8
Feb 19 05:17:50 <satish> pls anyone help me out
Feb 19 08:07:27 <zmatt> weird, I'm getting EINVAL from  open( "/tmp", O_TMPFILE | O_EXCL | O_RDWR, 0 );  on bbb even though I'm running debian sid with a very recent kernel
Feb 19 08:10:54 <woglinde> zmatt hm and which argument is not known?
Feb 19 08:10:58 <woglinde> O_TMPFILE?
Feb 19 08:12:29 <zmatt> ah bingo, adding | O_DIRECTORY to the flags fixes the problem... which means the header file contains a wrong definition for O_TMPFILE
Feb 19 08:13:16 <woglinde> yes?
Feb 19 08:14:12 <woglinde>  O_TMPFILE must be specified with one of O_RDWR or O_WRONLY
Feb 19 08:14:13 <woglinde>               and, optionally, O_EXCL.
Feb 19 08:14:29 <woglinde> looks like you did not read the man page?
Feb 19 08:15:08 <zmatt> ehm, I specified it with O_EXCL and O_RDWR.. looks like you didn't read what I said? :P
Feb 19 08:16:29 <zmatt> bingo, ARM has a non-standard value for O_DIRECTORY
Feb 19 08:16:35 <zmatt> x86:
Feb 19 08:16:40 <zmatt> #define __O_DIRECTORY 0200000
Feb 19 08:16:40 <zmatt> #define __O_TMPFILE 020200000
Feb 19 08:16:43 <zmatt> arm:
Feb 19 08:16:46 <zmatt> #define __O_DIRECTORY 040000
Feb 19 08:16:46 <zmatt> #define __O_TMPFILE 020200000
Feb 19 08:17:28 <zmatt> definition of __O_TMPFILE in /usr/include/arm-linux-gnueabihf/bits/fcntl-linux.h is incorrect
Feb 19 08:18:31 <zmatt> ah, the fix was committed to glibc git a couple of days ago, good
Feb 19 08:51:59 <woglinde> hehe okay
Feb 19 08:52:11 * woglinde wonders why it took so long to spot this
Feb 19 10:32:24 <zmatt> I'm not sure how well-known O_TMPFILE is, and I get the impression embedded systems often run older kernels due to non-mainlined patches or general conservativeness
Feb 19 12:30:11 <woglinde> uh wow
Feb 19 12:30:19 <woglinde> thanks simon
Feb 19 12:30:20 <woglinde> http://www.home.unix-ag.org/simon/files/uio-pruss-3.19.mbox
Feb 19 14:20:22 <nomis> woglinde: you're welcome
Feb 19 15:14:20 <antleo__> We need to make a series of buttons that function as the up and down arrows as well as an enter button using the beaglebones gpio can anyone point us in the right direction
Feb 19 15:15:08 <av500> https://www.google.com/search?q=linux+gpio+keys
Feb 19 15:46:05 <antleo_> we need to make an input click on a certain cordinate on the screen. is this posible?
Feb 19 15:50:19 <av500> of course its possible
Feb 19 15:50:21 <av500> its just sw
Feb 19 15:51:22 <woglinde> jo
Feb 19 15:55:51 <antleo_> how can we go about doing it?\
Feb 19 15:58:13 <nomis> antleo_: research the mechanisms mentioned above (maybe add "uinput" in the mix as well), create a plan and then start implementing it.
Feb 19 15:58:33 <nomis> antleo_: if you're stuck feel free to ask again with your specific problem.
Feb 19 15:59:19 <antleo_> uh..can you elaborate? im completely new to this and we are in abit over our heads considering this is due tomorrow
Feb 19 15:59:44 <nomis> antleo_: then you started too late.
Feb 19 16:00:28 <av500> +1
Feb 19 16:00:28 <antleo_> haha trust me we know
Feb 19 16:01:03 <antleo_> we were working on coding our app. we figured this would be easily implimented
Feb 19 16:01:15 <antleo_> apparently not so much
Feb 19 16:01:41 <av500> you need a better figurer
Feb 19 16:02:11 <antleo_> figurer?
Feb 19 16:02:25 <av500> your estimates are way off
Feb 19 16:02:29 <tbr> as you "figured" wrong
Feb 19 16:03:20 <antleo_> ah got ya
Feb 19 16:03:57 <nomis> antleo_: what do you mean by "make an input click"?, I presume you want to invoke a specific function of an application that you don't control the source of yourself?
Feb 19 16:05:46 <antleo_> we built basically a quiz application that has 4 answers.
Feb 19 16:06:02 <antleo_> each answer appears in the same spot
Feb 19 16:06:21 <av500> so you control the app?
Feb 19 16:06:25 <av500> you wrote it?
Feb 19 16:06:28 <antleo_> and we want 4 different buttons, one to select each of our answers
Feb 19 16:06:29 <antleo_> yes
Feb 19 16:06:40 <av500> so why do you need to "click"?
Feb 19 16:06:44 <nomis> antleo_: but you have control over the quiz application? I.e. you could implement a second way of picking an answer (that does not rely on screen coordiantes)
Feb 19 16:06:59 <antleo_> i suppose so yes
Feb 19 16:07:01 <av500> simply add 4 gpio-keys and map them in your app
Feb 19 16:07:22 <antleo_> how would we go about mapping them within java code?
Feb 19 16:07:22 <av500> or query the gpios from your app
Feb 19 16:07:41 <av500> java can handle a keyboard, I am sure
Feb 19 16:07:50 <av500> I saw java apps where I could enter my name
Feb 19 16:08:06 <nomis> antleo_: as av500 says: you could configure a gpio-keys keyboard  via the device tree to deliver 4 distinct key presses. Then open that keyboard-input device in your application and read the events it delivers.
Feb 19 16:08:25 <av500> or just query gpios from sysfs
Feb 19 16:08:26 <antleo_> can you dumb it down for me? so id be setting these buttons to act as a key on the keyboard?
Feb 19 16:08:39 <av500> yes
Feb 19 16:08:44 <av500> why dont you read the links
Feb 19 16:08:55 <av500> [16:15] <av500> https://www.google.com/search?q=linux+gpio+keys
Feb 19 16:09:13 <antleo_> ill do that..thank you
Feb 19 16:09:18 <nomis> antleo_: there is a ready-made driver in linux that converts signals on gpio pins to "input device key presses"
Feb 19 16:09:44 <av500> or again, just query 4 gpios via sysfs
Feb 19 16:09:55 <antleo_> what..? explain?
Feb 19 16:09:55 <av500> thats probybly the fastest way for you
Feb 19 16:10:02 <antleo_> ok
Feb 19 16:10:06 <av500> antleo_: no, I wont explain every step
Feb 19 16:10:55 <antleo_> i meant the driver
Feb 19 16:11:12 <antleo_> was not meaning you sorry was not clear on that
Feb 19 17:09:32 <blaine_> has anyone seen this before? when ethernet is not plugged in, I get random hangs on boot: [  *** ] A start job is running for LSB: Raise network interf...18s / no limit)
Feb 19 17:09:43 <blaine_> could be 1 minute block, or 10 minutes (or indefinite)
Feb 19 17:09:52 <blaine_> when ethernet is plugged in, there's no hang
Feb 19 17:10:03 <blaine_> i did install a wifi chip, and i am currently investigating whether this has anything to do with it
Feb 19 17:10:07 <veremit> dhcp?
Feb 19 17:10:30 <blaine_> veremit: could be, but not sure why it'd cause a system hang for 10 minutes
Feb 19 17:10:44 <blaine_> ok -- that time, with wifi and a hard reset it only took 3 minutes. booted fine once it timed out
Feb 19 17:11:47 <veremit> I've heard of some strange ethernet issues .. but they're more the exception than the norm
Feb 19 17:12:29 <blaine_> veremit: worth mentioning i'm on 3.8.14 -- i dont think i had this issue on vanilla image
Feb 19 17:13:01 <veremit> could try 3.14 ..
Feb 19 17:13:30 <blaine_> seems to be related: https://github.com/RobertCNelson/omap-image-builder/issues/41
Feb 19 17:13:38 <blaine_> usbnet is also broken, perhaps that's related
Feb 19 17:13:41 <blaine_> i wonder if that's what it is
Feb 19 17:14:14 * veremit defers to rcn-ee  .. :p
Feb 19 17:14:24 <blaine_> yeah this definitely seems to be similar
Feb 19 17:15:39 <rcn-ee> blaine_, it happens when you have eth0 defined in /etc/network/interfaces
Feb 19 17:15:51 <rcn-ee> the system waits up to 2minutes to get dhcp..
Feb 19 17:16:03 <rcn-ee> best thing to do, disable eth0 in /etc/network/interfaces and let connman do it..
Feb 19 17:16:08 <blaine_> rcn-ee: sometimes it hangs for 10+ minutes too
Feb 19 17:16:18 <blaine_> rcn-ee: ok cool. what is conman? is it a service tool?
Feb 19 17:16:34 <rcn-ee> it's a connection mananger tool...
Feb 19 17:16:43 <blaine_> interesting. sorry i've never used it.
Feb 19 17:16:46 <veremit> rcn-ee .. do your debian images contain/use connman by default?
Feb 19 17:16:55 <rcn-ee> for jessie it does..
Feb 19 17:17:14 <rcn-ee> for wheezy... nope.. at the mercy of /etc/network/interfaces unless it's the lxde image, then wicd handles it..
Feb 19 17:17:15 <veremit> naa, just wheezy ..
Feb 19 17:17:45 <veremit> ok so that possibility of a **-up on my stupid rtl8192 card.. lol
Feb 19 17:17:48 <blaine_> veremit: i'm actually on 3.18.2 sorry
Feb 19 17:17:50 <veremit> not+
Feb 19 17:18:27 <blaine_> veremit: i have an rt card, but haven't installed the firmware package (but it works fine). do you use the firmware?
Feb 19 17:18:35 <blaine_> rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available
Feb 19 17:18:40 <blaine_> but that doesn't seem to stop it
Feb 19 17:18:50 <veremit> you haven't installed it? firmware-realtek ?
Feb 19 17:18:54 <blaine_> veremit: correct
Feb 19 17:18:57 <blaine_> and it works great
Feb 19 17:19:21 <blaine_> drivers were already on the image of course so it just worked when i plugged it in
Feb 19 17:19:26 <veremit> you probabyl have a dodgy card .. like me ..
Feb 19 17:19:33 <blaine_> veremit: it's the edimax card
Feb 19 17:19:43 <blaine_> the little micro card
Feb 19 17:19:52 <veremit> yeah there's about 6+ manufacturers of the lil devils
Feb 19 17:20:09 <blaine_> veremit: that's good to know, i'll be ordering 5 of them and you may have just saved me time
Feb 19 17:20:17 <blaine_> veremit: so think i should just install the firmware to be safe? could it hurt?
Feb 19 17:20:33 <blaine_> rcn-ee: to wrap up -- you're suggesting i remove eth0 and bring it up manually with connman or similar tool right?
Feb 19 17:20:34 <veremit> I have no idea why they are so choosy in linux
Feb 19 17:21:05 <veremit> but there are definitely "better" and "worse" wireless usb cards
Feb 19 17:21:28 <rcn-ee> correct, unless it's always plugged in, have your own script do it. (or use jessie + connman) ;)
Feb 19 17:21:39 <rcn-ee> otherwise, you'll have that nice log wait..
Feb 19 17:21:50 <veremit> or use ifplugd :p
Feb 19 17:21:53 <blaine_> rcn-ee: ty. i dont mind the wait so much, but sometimes it's indefinite
Feb 19 17:22:10 <blaine_> i honestly don't know if this is the jessie image or not, my coworker built it
Feb 19 17:22:10 <rcn-ee> for even 10 seconds is annoying...
Feb 19 17:22:25 <blaine_> rcn-ee: i 3 reboots ago i had to hard reset after 10 minutes
Feb 19 17:22:42 <rcn-ee> well i made connman default last week for jessie... soo....
Feb 19 17:22:50 <blaine_> oh heh
Feb 19 17:23:00 <blaine_> rcn-ee: ok so is it just a package i install? apt-get install connman
Feb 19 17:23:13 <blaine_> ooh i was searching for 'debian conman' doh
Feb 19 17:24:58 <rcn-ee> there's an ancient version in wheezy: https://packages.debian.org/wheezy/connman (jessie is just as old) i built 1.27 and stuck it in my repo..
Feb 19 17:25:11 <veremit> heh
Feb 19 17:25:15 <veremit> debian IS ancient :p
Feb 19 17:25:40 <veremit> rcn-ee .. you should adopt gentoo ;) hehe
Feb 19 17:26:20 <veremit> although, granted .. we're along way ahead from yocto and angstrom :)
Feb 19 17:26:24 <rcn-ee> at the rate i'm backporting stuff into "jessie" for bb.org, i think i've got our "bb.org jessie" close to gentoo. ;)
Feb 19 17:26:25 <av500> we should do it like the rpi2 and adopt windows
Feb 19 17:26:36 <veremit> eww eww eww
Feb 19 17:26:45 <veremit> you want M$'s money??!
Feb 19 17:26:52 <rcn-ee> it's tainted!
Feb 19 17:26:53 <av500> i want money
Feb 19 17:26:53 <rcn-ee> never!
Feb 19 17:26:59 <veremit> amen rcn!
Feb 19 17:27:03 <av500> so I can buy more tubes
Feb 19 17:27:18 <veremit> pfft av500
Feb 19 17:27:31 <veremit> get a promotion lol
Feb 19 17:27:46 <av500> again?
Feb 19 17:27:50 <veremit> mhmm
Feb 19 17:27:52 <rcn-ee> every time i boot into windows, it just likes to reboot (after installing more updates) of course debian is first in grub... so i guess windows like debian. ;)
Feb 19 17:28:07 <woglinde> veremit is n't still musb which makes wifi cards suffer?
Feb 19 17:28:20 <veremit> woglinde .. not using the beagle with wifi :)
Feb 19 17:28:23 <rcn-ee> it's the hdmi.. gnd plane (when enabled)
Feb 19 17:28:32 <woglinde> veremit oh okay :)
Feb 19 17:28:50 <veremit> woglinde .. just usb/ide interface currently.. and rj45 ethernet ftw
Feb 19 17:29:23 <woglinde> rcn-ee ah right but only bbb on other designs without hdmi its musb?
Feb 19 17:29:43 <rcn-ee> of course! it's always musb... ;)
Feb 19 17:29:52 <veremit> bloody ti musb
Feb 19 17:30:15 <woglinde> or the mentor blob stuff
Feb 19 17:30:17 <veremit> woglinde .. I'm using an allwinner with the wifi .. but my preferred board remains the wand :)
Feb 19 17:30:23 <rcn-ee> ah mentor musb. ;)  sunxi has that ip too, it's not "fully" enabled in mainline, but can't wait for the sunxi crowd to start screaming..
Feb 19 17:30:45 <woglinde> rcn-ee haha
Feb 19 17:31:11 <woglinde> rcn-ee btw. did you see nomis freshup of the pruss for mainline?
Feb 19 17:31:59 <rcn-ee> must have missed that, do you have a linke?
Feb 19 17:32:20 <woglinde> -> 13:30 < woglinde> http://www.home.unix-ag.org/simon/files/uio-pruss-3.19.mbox
Feb 19 17:32:48 <woglinde> okay I am heading home
Feb 19 17:32:53 <woglinde> till later maybee
Feb 19 17:33:18 <veremit> mm time for me to relocate also .. bb
Feb 19 17:33:37 <woglinde> veremit hehe
Feb 19 17:34:11 <woglinde> nomis I believe you need some signed off line
Feb 19 17:34:50 <woglinde> now really off
Feb 19 17:42:20 <veremit> rcn-ee .. got any tips for debugging an early boot kernel crash? I had a quick attempt at netconsole .. but I'm not sure it got that far .. x86_64 platform btw ..
Feb 19 17:43:30 <veremit> grub screen resolution is crap so the dump scrolls anythiing remotely useful off-screen :/
Feb 19 17:43:48 <georgem> veremit: does it have a serial port?
Feb 19 17:44:11 <rcn-ee> unless you have a fast camera, try serial redirect...
Feb 19 17:44:26 <veremit> it might ... on a header I think
Feb 19 17:44:41 <veremit> I'll have to find an adapter cable
Feb 19 17:44:49 <rcn-ee> well, even usb-serial will work too... as long as the driver loads "before" the crash...
Feb 19 17:45:13 <veremit> yeah I don't think anything much is loading :/
Feb 19 17:45:23 <veremit> can't imagine what I've got wrong
Feb 19 17:45:53 <veremit> what's the process with serial?
Feb 19 17:46:26 <georgem> if you have sys-rq configured you might be able to halt it so you can see it before it scrolls off the screen. never tried that but it should work
Feb 19 17:46:48 <veremit> yeah sysrq is locked out .. can't reboot from it
Feb 19 17:47:12 <veremit> without touching the reset pins!
Feb 19 17:52:26 <IrishGringo> is this also a beagle bone Black chat?
Feb 19 17:52:37 <thurgood_> sure
Feb 19 17:53:49 * vagrantc hrms over filesystem errors on the eMMC
Feb 19 17:54:07 <vagrantc> hopefully it's just a software problem
Feb 19 18:18:53 <talin_> hmm, when i came home today, all the 4 leds are pulsing on my bbb
Feb 19 18:19:03 <talin_> what does it mean? it works as usual
Feb 19 18:19:16 <rcn-ee> 4 constant pulese?
Feb 19 18:20:03 <rcn-ee> i mean, all 4 are synced on -- off -- on -- off at a contant rate?
Feb 19 18:23:10 <talin_> rcn-ee, two quick pulses then a 1 second break
Feb 19 18:23:11 <vagrantc> rcn-ee: so, rebuilding the debian jessie kernel with gpio_backlight enabled and loading the module, with the .dtb from dtb-rebuilder for 3.14.x "works" with the lcd7 cape ... no custom xorg.conf needed, although maybe that would improve some performance
Feb 19 18:24:32 <rcn-ee> vagrantc, cool to here... Which driver did xorg pick up modesetting or fbdev automaticly for it?
Feb 19 18:25:24 <rcn-ee> with modesetting, there's till random hardlocks, if you open an image (jpg) via an image viewer app it'll usually freeze up..
Feb 19 18:25:46 <vagrantc> seems to be fbdev
Feb 19 18:26:14 <rcn-ee> okay, fbdev is solid in that case.
Feb 19 18:26:47 <vagrantc> haven't gotten as far as actually logging in. heh. just displaying lightdm so far
Feb 19 18:27:27 <rcn-ee> that's just details, leave that up to the end user. ;)
Feb 19 18:27:28 <ogra_> good enough, sell it !
Feb 19 18:27:32 <talin_> all four leds go like: blink, 0.1s pause, blink, 1s pause, repeat
Feb 19 18:28:19 <vagrantc> buttons work...
Feb 19 18:28:56 * vagrantc is a little worried about all the eMMC errors it's been spewing out, but it seems to eventually correct them
Feb 19 18:31:43 <rcn-ee> talin_, sounds like a pattern from another script...
Feb 19 18:31:52 <rcn-ee> not sure, can you login?
Feb 19 18:32:30 <blaine_> rcn-ee: i disabled 'auto eth0' in network interfaces, still get hangs on boot =\. do i have to do something else?
Feb 19 18:34:16 <rcn-ee> blaine_, do you have systemd enable? "systemd-analyze blame" should give us some hints.
Feb 19 18:34:32 <blaine_> rcn-ee: let me check... once it decides to continue booting :)
Feb 19 18:35:49 <blaine_> INFO: task wpa_supplicant:346 b
Feb 19 18:35:50 <blaine_> locked for more than 120 seconds.
Feb 19 18:35:50 <blaine_> [  240.681914]       Not tainted 3.18.2-bone1 #1
Feb 19 18:35:50 <blaine_> [  240.686506] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 19 18:35:59 <blaine_> so apparently while this is going down, wpa_supplicant gets fed up
Feb 19 18:36:18 <rcn-ee> it's the mmc too...
Feb 19 18:36:36 <blaine_> mmc?
Feb 19 18:36:42 <blaine_> how do you know?
Feb 19 18:37:29 <rcn-ee> that's usually what leads to that message, but we will see when it gets fully booted..
Feb 19 18:37:35 <blaine_> gotcha
Feb 19 18:37:56 <blaine_> it gets up to 60s, then resets. but i can't tell if it actually resets the timer or just gets cut off
Feb 19 18:38:04 <blaine_> rcn-ee: i'm going to plug in ethernet just so it'll boot
Feb 19 18:38:47 <blaine_> ok that didn't do anything. hard reset it is (this was a soft reset, which appears to fail more often then not)
Feb 19 18:39:41 <blaine_> yeah. hard reset unblocked in < 10 seconds
Feb 19 18:39:48 <blaine_> but it's still unpredictable
Feb 19 18:40:14 <Sherring> Hi all, I'm having an issue while mmaping gpio 2 and 3, it's rising SIGBUS. Does anyone knows what can I do?
Feb 19 18:40:24 <blaine_>          11.477s networking.service
Feb 19 18:40:25 <blaine_>           1.902s generic-boot-script.service
Feb 19 18:40:33 <blaine_> rcn-ee: ^^
Feb 19 18:41:14 <blaine_> Sherring: do other gpio pins work?
Feb 19 18:41:41 <Sherring> blaine_: yes, gpio 0 and 1 work just fine
Feb 19 18:43:20 <ell> Hi folks
Feb 19 18:43:42 <Sherring> blaine_: any try to write on other modules, at least on registers of clock control, setdata and cleardata rises the signal
Feb 19 18:44:27 <blaine_> Sherring: what commands? I can try on mine to see if i raise the same
Feb 19 18:45:07 <ell> AFAICT, beagle bone blacks support SPI interfaced TFT LCD modules directly
Feb 19 18:46:08 <ell> I was wondering where I can get more info on what other interfaces it supports? I've found a display from here http://www.densitron.com/displays/Displays.aspx?nCategoryID=56 where the interface is listed as " 	8/9/16/18 bit CPU" - what is CPU referring to here?
Feb 19 18:46:13 <Sherring> blaine_: Ok, let me pastebin it
Feb 19 18:47:23 <rcn-ee> blaine_, can you pastebin.com your /etc/network/interfaces
Feb 19 18:47:38 <blaine_> rcn-ee: i did a hard reset, now it seems to only hang 10sec consistently
Feb 19 18:47:43 <blaine_> after commenting out auto eth0
Feb 19 18:48:21 <blaine_> rcn-ee: http://pastebin.com/vLriDe9i
Feb 19 18:48:23 <Sherring> ell: probably, it is refering to the output bus size of display, since its is unlikely a 9 or 18 bits cpu
Feb 19 18:49:52 <rcn-ee> oh commet out "iface eth0 inet dhcp  " too... Just in case.. also add "allow-hotplug wlan0" after auto wlan0...
Feb 19 18:50:12 <blaine_> ok
Feb 19 18:51:22 <blaine_> rcn-ee: ironically, this has caused it to hang again (prior two boots, after disabling auto eth0 and hard reset, were only 10sec)
Feb 19 18:51:23 <Sherring> blaine_: http://pastebin.com/89VaE4P4 there are a few portuguese messages
Feb 19 18:51:28 <blaine_> so far i'm at 40sec with no signs of slowing down
Feb 19 18:52:05 <blaine_> nao problemo
Feb 19 18:52:32 <blaine_> Sherring: are you just using it for digital i/o?
Feb 19 18:52:39 <ell> Sherring: Sherring: Hmm okay. I wouldn't know how to drive it still. I guess it'd be in the datasheet
Feb 19 18:52:45 <Sherring> blaine_: (y)
Feb 19 18:52:56 <blaine_> Sherring: does it work from command line? that's how i use mine
Feb 19 18:53:40 <Sherring> blaine_: yes. Ah I get it, i was programming in C. Do you happen to have the devmem utility?
Feb 19 18:54:08 <blaine_> Sherring: not sure -- i dont think so
Feb 19 18:54:47 <Sherring> blaine_: ok... it is missing from debian repo, I don't know exaclty why.
Feb 19 18:55:23 <rcn-ee> devmem got denied into debian.. just borrow ubuntu's *.deb and installl it..
Feb 19 18:55:26 <blaine_> Sherring: if you just do an echo into the gpio files does that work for you?
Feb 19 18:55:34 <Sherring> blaine_: try running devmem 0x481AC190
Feb 19 18:55:41 <blaine_> Sherring: i don't have devmem installed
Feb 19 18:56:03 <blaine_> rcn-ee: interestingly, it's like one boot after a networking change takes forever, then everything works
Feb 19 18:56:12 <blaine_> rcn-ee: after the 2min boot now each boot is only 6 seconds in networking
Feb 19 18:56:23 <blaine_> after i applied your two changes
Feb 19 18:56:29 <ell> Did you guys compile your own kernels for the BB?
Feb 19 18:56:47 <Sherring> rcn-ee: thanks!
Feb 19 18:57:28 * vagrantc is testing freshly compiled kernels for the BBB this very minute
Feb 19 18:57:46 <vagrantc> although i try to get all changes i do merged into debian eventually
Feb 19 18:59:40 * walrus_ bows deeply
Feb 19 19:01:41 <Sherring> blaine_: are you having problem booting? hanging on boot, i mean?
Feb 19 19:02:05 <blaine_> Sherring: yeah, with regards to networking
Feb 19 19:02:17 <Sherring> blaine_: mine was taking too long because of dhcp
Feb 19 19:02:23 <blaine_> i have to disable eth0 basically, otherwise it non-deterministically hangs for 2 minutes to 10 minutes +
Feb 19 19:02:35 <blaine_> Sherring: if i have eth0 unplugged that is
Feb 19 19:04:01 <Sherring> blaine_: get it. Try defining it as static in interfaces, i.e. in eth0, change it to iface eth0 inet static
Feb 19 19:04:48 <blaine_> Sherring: actually if I just disable eth0 in interfaces and brin git up normally it seems to work fine
Feb 19 19:04:50 <Sherring> blaine_: i mean, if you didnt got your issue solved already.
Feb 19 19:05:03 <blaine_> Sherring: it's probably dhcp i think
Feb 19 19:05:08 <blaine_> just not sure why it takes, uh, 10 minutes sometimes
Feb 19 19:05:12 <blaine_> and 10 seconds other times
Feb 19 19:05:53 <Sherring> do you unplug power your board between tries or just reset?
Feb 19 19:06:00 <blaine_> Sherring: i always unplug
Feb 19 19:06:06 <blaine_> too much inconsistencies with soft resets
Feb 19 19:06:17 <blaine_> i2c doesn't reset properly for example (so my audio cape gets locked up)
Feb 19 19:06:23 <Sherring> blaine_: right on
Feb 19 19:06:41 <blaine_> Sherring: the hard part though is it would be nice to have dhcp run when i plug in a cable
Feb 19 19:06:45 <blaine_> but not automatically on bootup
Feb 19 19:06:54 <blaine_> if i want to attach eth0, i have to manually bring it up
Feb 19 19:07:54 <Sherring> blaine_: you might just script it up with sysV on login
Feb 19 19:08:23 <rcn-ee> "allow hotplug" should work in that case... (it's the always plugged in where allow-hotplug sometimes just doesnt' come up..)
Feb 19 19:08:43 <blaine_> rcn-ee: ok cool -- and i could just have it cycle eth0 one time on bootup anyway just in case
Feb 19 19:09:16 <rcn-ee> yeap..  That's where jessie/connman just makes it easy. ;)
Feb 19 19:09:25 <blaine_> i should look into that
Feb 19 19:11:22 <blaine_> rcn-ee: allow-hotplug eth0 causes a hang, interestingly enough, when plugged in. not sure about not plugged in
Feb 19 19:11:49 <rcn-ee> yeap, i see that to.. it's not suppost to do that.. ;)
Feb 19 19:12:28 <blaine_> hehe
Feb 19 19:12:43 <blaine_> ok -- when unplugged it boots fine, BUT eth0 is up with no IP. plugging in has no effect (still up with no IP)
Feb 19 19:12:45 <blaine_> so bizarre
Feb 19 19:12:50 <blaine_> so bizarre
Feb 19 19:12:59 <blaine_> oops. up/enter on wrong terminal
Feb 19 19:13:03 <rcn-ee> when you plugin.. it shoudl get dhcp (it'll take 10-15 seconds)
Feb 19 19:13:12 <blaine_> rcn-ee: yes, you're right. eventually it did.
Feb 19 19:13:18 <blaine_> ok this is acceptable for now
Feb 19 19:13:21 <rcn-ee> the cpsw sure takes it sweet time..
Feb 19 19:13:42 <blaine_> that's odd. i wonder why
Feb 19 19:17:37 <Sherring> Hi all, I'm having an issue while mmaping gpio 2 and 3, it's rising SIGBUS. Does anyone knows what can I do? (bump)
Feb 19 19:26:00 <vagrantc> is USB_MUSB_DAVINCI relevent for BBB?
Feb 19 19:28:40 <rcn-ee> nope
Feb 19 19:28:43 <rcn-ee> arm9
Feb 19 19:29:42 <rcn-ee> vagrantc, if it makes it easier here is my full diff against your 3.16.x (last diffed about a week ago)
Feb 19 19:29:50 <rcn-ee> (config wise)
Feb 19 19:29:53 <Sherring> turns out that sigbus was outputing to dmesg "Unhandled fault: external abort on non-linefetch (0x1018) at 0xb6fe8130". Does anyone understand what is it?
Feb 19 19:30:19 <vagrantc> rcn-ee: ah, yes, that could be useful
Feb 19 19:30:32 <vagrantc> rcn-ee: it seems to keep reverting to CONFIG_MUSB_PIO_ONLY...
Feb 19 19:30:50 <rcn-ee> did you force dma builtin?
Feb 19 19:31:10 * vagrantc tried
Feb 19 19:31:17 <rcn-ee> oh and you have to disable the other musb drivers.... which aint going to work for debian..
Feb 19 19:31:53 <rcn-ee> DMA mode on musb is still broken as crazy.. ti's still patching it in v3.14.x but we'll proballly revert back to PIO mode as more users test the usb..
Feb 19 19:31:59 <vagrantc> rcn-ee: i'm going to explore building a bbb-specific kernel and shipping it out of debian with config only changes
Feb 19 19:32:18 <vagrantc> PIO mode is completely broken in 3.16
Feb 19 19:32:53 <vagrantc> for BBB, anyways ... also same when i tried 3.18 ... no idea if any improvements made it into 3.19 or mainline
Feb 19 19:33:19 <woglinde> re
Feb 19 19:33:43 <vagrantc> rcn-ee: where's that diff? :)
Feb 19 19:34:06 <vagrantc> disabling the other MUSB drivers is probably the key here
Feb 19 19:35:20 <rcn-ee> well when ran from my git tree on your config, it's generates a diff. ;) check these 5 configs: https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-3.14.y/tools/config-checker.sh#L1297
Feb 19 19:36:30 <vagrantc> seemed to manage to disable PIO_ONLY ... and have CONFIG_USB_TI_CPPI41_DMA=y enabled... will see if it works
Feb 19 19:37:10 <rcn-ee> btw, also look at add: https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-3.14.y/patches/beaglebone/dts/0004-bbb-force-usb0-to-perhiperal-mode-fixes-http-bugs.el.patch
Feb 19 19:37:20 <rcn-ee> it fixed some random reboot's
Feb 19 19:37:34 <woglinde> rcn-ee is there a kernel tree where musb survivs serval weeks withoud dying?
Feb 19 19:38:19 <rcn-ee> laughs.. your asking too much of musb..
Feb 19 19:38:40 <rcn-ee> Nokia, just spec'ed it to transfer vcards..
Feb 19 19:39:23 <woglinde> rcn-ee okay sorry, that was really a seriuos question
Feb 19 19:39:38 <rcn-ee> should work best in 3.14
Feb 19 19:43:51 <blaine_> rcn-ee: i still get random hangs w/ ethernet disconnected. what a pain right?
Feb 19 19:48:52 <blaine_> this might not be correct, but as soon as the "running for LSB..." hang stops and moves on, i get this message
Feb 19 19:48:54 <blaine_> libphy: PHY 4a101000.mdio:01 no
Feb 19 19:48:55 <blaine_> t found
Feb 19 19:49:10 <blaine_> i'm t hinking that when it hangs, it may be because that error comes too soon or something.
Feb 19 19:49:14 <blaine_> like a race condition
Feb 19 19:52:04 <Milenko> Got my NES controller ports to function
Feb 19 19:52:17 <Milenko> And the power switch is wired to the beagle :)
Feb 19 20:01:31 <walrus_> it's possible updating image a beagleboneblack using other
Feb 19 20:01:52 <walrus_> BBB ?
Feb 19 20:32:42 <rcn-ee> vagrantc, btw, are you going to have a secondary repo (user.debian.org) for your 3.16.x kernel blend, i can add it to my jessie images so users can swap to it..
Feb 19 20:33:17 <vagrantc> rcn-ee: that's what i was thinking ... haven't gotten that far yet
Feb 19 20:34:39 <talin_> hmpf, doing apt-get upgrade isn't a good idea i take it? it re-enabled all the bonescript services etc
Feb 19 20:34:43 <rcn-ee> remember, i've nuked flash-kernel. ;) so i'm hoping the *.dtb's come with linux-image .;)
Feb 19 20:36:15 <vagrantc> rcn-ee: i'm sticking to Debian's methods...
Feb 19 20:36:44 <vagrantc> rcn-ee: for jessie, i'd like to do some major fixes to flash-kernel, or replace it with something better
Feb 19 20:36:53 <vagrantc> er, for jessie+1
Feb 19 20:37:30 <rcn-ee> oh we are good, just checked out 3.16.7: they'll be under: /usr/lib/linux-image-3.16.0-4-armmp
Feb 19 20:37:46 <rcn-ee> (uname -r) so it'll install just fine and be loaded correctly by u-boot. ;)
Feb 19 20:38:07 <vagrantc> ah, oh.
Feb 19 20:38:09 <vagrantc> ok
Feb 19 20:38:17 <rcn-ee> just a brainfart by me.. nothing to see here. ;)
Feb 19 20:38:45 * vagrantc waves
Feb 19 21:28:04 <twoitipoints> hi !
Feb 19 22:20:45 <blaine_> i am randomly having issues with "cfg80211: Calling CRDA to update world regulatory domain" for my wifi chip now
Feb 19 22:20:47 <blaine_> that's a first
Feb 19 22:21:12 <blaine_> i had this problem years ago on a different board. does anyone else have issues with this? It's like every 60 seconds
Feb 20 01:48:50 <GenTooMan> Anyone use a Pico Projector? I have one of these (nice device) and they have an I2C bus that's supposed to be for EDID on a normal HDMI connection. However the Pico uses it to control the project not support EDID or DDC2. Anyhow I was wondering if anyone messed with this too allow one to connect the pico projector to something other than just a beagle bone with the correct firmware.
**** ENDING LOGGING AT Fri Feb 20 02:59:59 2015