**** BEGIN LOGGING AT Sat Jan 23 02:59:58 2016
Jan 23 04:37:26 <yates> where is the real-time clock on the bbb? i.e., where is time stored/kept when the board is powered off?
Jan 23 04:37:50 <yates> the time for debian/linux, that is.
Jan 23 04:50:56 <beltorak> as far as I was aware, the bbb doesn't have that. it needs an NTP to get the current time.
Jan 23 04:53:19 <yates> beltorak: i think you are right. i seem to remember somewhere in the networking scripts an "ifup" causes the time to be read from somwhere and updated
Jan 23 04:53:28 <yates> so the first time you boot, you don't know what time it is?
Jan 23 04:53:40 <yates> ...until a network connection is made?
Jan 23 04:53:59 <beltorak> yeah; seems like it: http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time-using-ntp/
Jan 23 04:54:36 <beltorak> i think the NTP is installed nowadays, so the instructions in that link shouldn't be necessary.
Jan 23 04:55:09 <beltorak> are you doing gpio, debian 8? I'm having serious difficulties....
Jan 23 04:55:41 <yates> beltorak: are you talking to me?
Jan 23 04:55:45 <beltorak> yates: yah
Jan 23 04:56:09 <yates> i did it in a previous project. what is the problem?
Jan 23 04:56:15 <beltorak> sorry about the non-addressed question - it's been quiet, i've been lurking
Jan 23 04:56:22 <yates> ha. np.
Jan 23 04:56:54 <beltorak> well, I can't seem to get the gpio pins to do anything for the life of me. I updated the image to debian 8 cause of a problem with the default image, I figured that would fix it.
Jan 23 04:57:23 <beltorak> I can write values to the gpio files, but that doesn't actually do anything "on the wire" so to speak
Jan 23 04:57:37 <yates> hang on, let me see if i can dig up my self-documentation on this and post it.
Jan 23 04:57:47 <beltorak> that would be sweet
Jan 23 04:57:48 <beltorak> thanks
Jan 23 04:58:59 <yates> you may not be doing something right with the device tree
Jan 23 04:59:07 <yates> which gpio is it?
Jan 23 04:59:19 <yates> is it unused?
Jan 23 05:01:05 <beltorak> i've tried a bunch - currently p8_(10,12,14) - gpio 26,44,68 (not in that order)
Jan 23 05:01:34 <beltorak> I've basically gone through "http://elinux.org/EBC_Exercise_10_Flashing_an_LED"
Jan 23 05:01:41 <beltorak> how do I check that it's definitely "free"?
Jan 23 05:01:41 <yates> http://www.digitalsignallabs.com/kb-debian-bbb.htm
Jan 23 05:02:00 <beltorak> I think I messed something up in the flashing or not overlaying a cape or something....
Jan 23 05:02:11 <yates> see section 3.1 especially
Jan 23 05:02:36 <yates> i just have to look at the bbb schematic and read the reference manual
Jan 23 05:03:33 <yates> see section 3.4 instead of 3.1
Jan 23 05:03:38 <beltorak> well, I think part of the problem is that all the instructions I find are either for the 3.8 kernel, or older (before the device tree) - 4.1 moved some things around
Jan 23 05:05:28 <yates> apparently i was using debian 7.6. i am ignorant of what they do now in the current or other debian versions.
Jan 23 05:09:34 <beltorak> ok; before I removed all the capes from /sys/devices/platform/bone_capemgr/slots, /sys/kernel/debug/gpio would show the gpio pin (?)allocated(?) to P8_xx; but now it says "sysfs" - does that mean anything to you?
Jan 23 05:09:48 <beltorak> for example
Jan 23 05:10:00 <beltorak> gpio-44  (sysfs               ) out lo
Jan 23 05:13:20 <veremit> there's no RTC on any arm board I got
Jan 23 05:13:30 <veremit> no backup, I mean
Jan 23 05:13:55 <veremit> so you have to (1) add one, and battery (2) ntp [most popular] (3) never power off :D
Jan 23 05:18:48 <beltorak> ok; so removing everything from .../slots and running 'config-pin overlay cape-universaln' freezes the bbb; good to know....
Jan 23 05:37:10 <beltorak> ok; so I boot up, .../slots shows only cape-universaln, gpio-68/P8_10 direction and value is "in" "lo"; I do 'echo high > .../direction' and it changes to "out" "hi", but the LED does not light up.... what am I missing?
Jan 23 05:38:33 <beltorak> hi yates; wb.
Jan 23 05:38:39 <yates> yeah, hey.
Jan 23 05:38:55 <yates> i think my nmap hosed my network..
Jan 23 05:39:00 <beltorak> lol
Jan 23 05:39:23 <beltorak> Let me repeat the question for you.
Jan 23 05:39:26 <beltorak> ok; so I boot up, .../slots shows only cape-universaln, gpio-68/P8_10 direction and value is "in" "lo"; I do 'echo high > .../direction' and it changes to "out" "hi", but the LED does not light up.... what am I missing?
Jan 23 05:39:26 <yates> ok
Jan 23 05:39:39 <yates> i just built the latest/greatest from here: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot
Jan 23 05:39:55 <yates> it loads and i see the lights flashing like normal, but i can't get a network connection.
Jan 23 05:39:59 <yates> any ideas?
Jan 23 05:40:28 <yates> an eth, not the rdis
Jan 23 05:40:30 <beltorak> ooo; some 4.1 kernel instructions; sweet
Jan 23 05:40:47 <beltorak> what distro is uboot? something other than deb/angstrom?
Jan 23 05:41:09 <yates> no, it's part of debian/bbb linux
Jan 23 05:41:12 <yates> kinda.
Jan 23 05:41:19 <yates> it's the second-level bootloader..
Jan 23 05:41:23 <beltorak> ok
Jan 23 05:41:36 <beltorak> i remember letting my eyes glaze over the boot sequence for bbb; lol
Jan 23 05:42:17 <yates> beltorak: regarding your question, i think the direction just sets whether the gpio is an input or an output. you then have to set the (output) value of the gpio
Jan 23 05:42:53 <beltorak> yates: yeah, but 'high' or 'low' > direction sets both direction and value; regardless 'cat value' shows "1"
Jan 23 05:43:41 <beltorak> do I run the ./dtc-overlay on my PC, or on the BBB?
Jan 23 05:43:46 <yates> try setting the value to 0 after configuring the directio to out
Jan 23 05:43:56 <yates> no, those are on the bbb
Jan 23 05:44:38 <yates> but wiggling the leds definitely conflicts with the os, so i don't know.
Jan 23 05:44:42 <yates> that's a bad choice.
Jan 23 05:45:15 <beltorak> "wiggling the LEDs"?
Jan 23 05:45:24 <veremit> there should be 4.1 kernels in the newer official images .. try a jessie one ..
Jan 23 05:45:51 <veremit> Ida thought RN woulda put them in the older wheezy too tbh, but who knows.
Jan 23 05:45:55 <beltorak> veremit: I am running the official BeagleBoard.org Debian Image 2015-11-12
Jan 23 05:46:30 <beltorak> yates: I echo "out" to direction, and echo 0 and 1 alternately to the value, nothing changes
Jan 23 05:46:51 <veremit> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2016-01-17
Jan 23 05:46:53 <beltorak> I get the same value our of the value file that I echo into it...
Jan 23 05:47:03 <beltorak> ooo; a newer build
Jan 23 05:47:04 <veremit> yeah kernel is stil in the 3.x series on wheezy
Jan 23 05:47:22 <veremit> if you want bleeding edge, though .. go with the eewiki site .. that's RN's personal
Jan 23 05:47:39 <veremit> but don't expect as much support for beagle things that 'new' lol
Jan 23 05:47:40 <beltorak> I'm surprised I missed that - I swore I downloaded the kernel a couple of days ago, and 2015 was it
Jan 23 05:48:15 <veremit> beltorak: those are semi-official jessie snapshots, not the full official desktio/node/etc wheezy ones
Jan 23 05:48:19 <yates> veremit: i have to build from scratch since i'm goign to be modifying some things. it's for a custom board.
Jan 23 05:48:28 <veremit> if you scroll further down .. you can see you can apt-get kernels ;)
Jan 23 05:48:37 <veremit> yates: yeah you're streets again .. ;)
Jan 23 05:48:42 <veremit> s/again/ahead
Jan 23 05:49:01 <yates> huh? you mean i have my work cut out for me?
Jan 23 05:49:07 <veremit> nope
Jan 23 05:49:12 <veremit> you'e ahead of the game :p
Jan 23 05:49:23 <yates> it doesn't FEEL like it.. :)
Jan 23 05:49:33 <veremit> but custom everything is always gonna be arduous
Jan 23 05:49:38 <veremit> just gotta plug away at it
Jan 23 05:49:52 <yates> yeah, i'm arduing right now.. it hurts.
Jan 23 05:49:56 <beltorak> veremit: ok; understood; I'm just trying to get through "the evil genius guide" with my daughter, so not a whole lot of advanced stuff is needed.... I updated to the 4.1 kernel cause the stock debian 7.x gave me errors when I tried to modify one of the projects to add an additional button
Jan 23 05:49:57 <veremit> :]
Jan 23 05:50:34 <yates> beltorak: re: "wiggling leds". you are trying to configure one of usr0-usr3? those are taken by the kernel
Jan 23 05:50:45 <veremit> beltorak: cool ..  documentation is very .. well .. inconsistent with the rapid development cycle
Jan 23 05:50:50 <beltorak> yates: well, curiously I got those working
Jan 23 05:50:58 <veremit> yates: that's ok .. you can disable them in the device-tree
Jan 23 05:51:07 <beltorak> I even improved the code for the cylon thing it does while flashing
Jan 23 05:51:19 <yates> oh.
Jan 23 05:51:28 <veremit> beltorak: sounds like you're doin ok then :D
Jan 23 05:51:31 <yates> well, then you have the general procedure.
Jan 23 05:51:44 <beltorak> veremit: except that I can't for the life of me get any gpios to work; lol
Jan 23 05:51:55 <yates> those ARE gpios...
Jan 23 05:51:57 <veremit> beltorak: boo :/ it should be ok
Jan 23 05:51:58 <yates> usr0-3
Jan 23 05:52:08 <beltorak> yates: yeah, i mean the external / header board ones
Jan 23 05:52:15 <veremit> I think they're configured as gpio by default no?
Jan 23 05:52:24 <beltorak> veremit: I think so
Jan 23 05:52:38 <veremit> so you can 'echo 1 >/sys/blah/gpio2342342_2342342342'
Jan 23 05:52:38 <yates> which p8/p9 signal exactly are you trying to wiggle?
Jan 23 05:52:41 <beltorak> they are exported under (?)/sys/class/gpio
Jan 23 05:52:46 <veremit> thats the one
Jan 23 05:52:54 <veremit> set 'direction' and 'value'
Jan 23 05:52:59 <beltorak> p8_(10|12|14)
Jan 23 05:53:03 <veremit> you need to .. erm .. 'expose' them ..
Jan 23 05:53:10 <veremit> to sysfs
Jan 23 05:53:13 <veremit> but once that's done
Jan 23 05:53:26 <veremit> echo 'out' > direction
Jan 23 05:53:29 <veremit> echo '1' > value
Jan 23 05:53:36 <beltorak> yeah, they are exposed in sysfs; but no matter what I echo to direction and value, the extrernal LED stays dark
Jan 23 05:53:53 <veremit> ah now I've known that to happen
Jan 23 05:53:55 <beltorak> I think I missed an instruction about an overlay or something, but I can't chase anything solid down
Jan 23 05:54:14 * veremit wonders if zmatt is about ..
Jan 23 05:54:25 <veremit> guessing not
Jan 23 05:54:26 <beltorak> boot log shows the cape-universaln being loaded, and it (seems to) expose almost all the gpios
Jan 23 05:54:28 <veremit> yet.
Jan 23 05:54:40 <veremit> yeah I don't think you hav to do anything special
Jan 23 05:54:47 <veremit> the sysfs nodes wouldn't work if there was a bigger problem
Jan 23 05:54:54 <veremit> but there are some stupid things about those
Jan 23 05:55:00 <yates> beltorak: can you get on the signals with a scope and verify they're indeed not wiggling ? could be a problem with the board itself.
Jan 23 05:55:01 <beltorak> just uncomment the "flash this image" line in the uEnv.txt, right?
Jan 23 05:55:20 <yates> with the cape, that is.
Jan 23 05:55:21 <veremit> beltorak: if you got a 'flasher' image .. No Need :D
Jan 23 05:55:21 <beltorak> yates: sadly, I am waiting on battery for my scope
Jan 23 05:55:36 <beltorak> **multimiter
Jan 23 05:55:42 <veremit> yates: no its more fundamental than that .. sometimes the kernel gpio doesn't work properly
Jan 23 05:55:47 <beltorak> never saw a 12v battery before....
Jan 23 05:55:54 <yates> veremit: ewe.
Jan 23 05:55:57 <veremit> beltorak: yeah they do a half-size AA one
Jan 23 05:56:07 <veremit> but most are PP9 -9V
Jan 23 05:56:09 <beltorak> well, I will try the 2016 kernel and see if that solves my problem
Jan 23 05:56:15 <veremit> had one for my SLR camera
Jan 23 05:56:30 <beltorak> veremit: yeah, i thought it was a 9v when I bought it; lol; forgot to read the fine print
Jan 23 05:56:41 <veremit> beltorak: poop lol
Jan 23 05:56:53 <beltorak> yeah, tell me about it
Jan 23 05:57:23 <beltorak> ...i should probably back up my mods to bonescript before I forget; something something git commit....
Jan 23 05:57:44 <veremit> yup always a good idea
Jan 23 05:58:49 <beltorak> i don't suppose you know if there's a way to ... selectively override bonescript modules? I've been "backing up" the origs and modifying the ones on the BBB. Got it to at least find the right kernel 4.1 paths.
Jan 23 06:00:11 <veremit> kernel cmdline .. capemgr.enable_partnos and capemgr_disable .. iirc
Jan 23 06:00:26 <veremit> syntax obviously is wrong lol
Jan 23 06:00:30 <beltorak> veremit: I think that's something different
Jan 23 06:00:39 <veremit> oh sorry bonescript lol
Jan 23 06:00:44 <beltorak> yeah, lol
Jan 23 06:00:46 * veremit half-asleep
Jan 23 06:02:12 <veremit> there probaly is a way
Jan 23 06:14:22 <beltorak> which image do I download? is "lxqt" a window manager / desktop env?
Jan 23 06:15:52 <beltorak> oh; flasher console; yeah; probably that one
Jan 23 06:18:28 <beltorak> I "dd" the image to the mmcblk0, not any of the partitions, right?
Jan 23 06:28:36 <yates> beltorak: right.
Jan 23 06:28:57 <beltorak> oh good; lol
Jan 23 06:29:26 <yates> i just went over this process with a fine-toothed comb.
Jan 23 06:29:50 <yates> so it's fresh. i'll forget it in a week..
Jan 23 06:30:27 <beltorak> lol - yeah, i know how that goes
Jan 23 06:30:57 <beltorak> it's like how i am with perl - if I put it down for more than a month I forget 90% of what I learned
Jan 23 06:31:14 <beltorak> I think I've learned the same 40 hours 6 times now
Jan 23 06:36:41 <beltorak> .... a bit offtopic, but what's with all these complicated .bashrc / .profile scripts? can't we split those up into /etc/profile.d scripts?
Jan 23 06:48:41 <beltorak> what debian package provides the zeroconf/avahi daemon?
Jan 23 06:48:55 <veremit> search via packages.debian.org .. :)
Jan 23 06:49:54 <beltorak> lol avahi-daemon; go figure
Jan 23 06:49:55 <beltorak> thanks
Jan 23 06:50:30 <veremit> np .. very usefuyl that if you're not conversant in apt-ese
Jan 23 06:51:03 <beltorak> yeah, I run ubuntu on my personal computer; but i generally don't have to set up so much ... basic stuff; lol
Jan 23 06:51:20 <veremit> ah I'm playing with stuff allt he time, everywhere
Jan 23 06:51:32 <veremit> my main distro is gentoo .. and I'm just learning the 'dev' ropes ..
Jan 23 06:51:47 <beltorak> I have a bitbucket repo with a bunch of helpful things that I add to just about any new image; especially the prompt; i like my prompt; i wish /etc/skel/.bashrc didn't hardcode it
Jan 23 06:51:51 <veremit> project isn't in the greatest of health
Jan 23 06:52:08 <veremit> overwrite/augment it ..
Jan 23 06:52:13 <beltorak> no way
Jan 23 06:52:15 <veremit> aka .. patch it :p
Jan 23 06:52:18 <veremit> but yeah
Jan 23 06:52:20 <beltorak> drop that stuff in /etc/profile.d
Jan 23 06:52:27 <veremit> I've just found etckeeper :)
Jan 23 06:52:29 <beltorak> easy to isolate / modify / remove
Jan 23 06:52:40 <veremit> that's what I meant .. lol .. roughly
Jan 23 06:52:45 <beltorak> mmmm.... etckeeper
Jan 23 06:52:53 <veremit> you like?
Jan 23 06:53:08 <beltorak> i like the sound of it; is it a "/etc in a git repo" type deal?
Jan 23 06:53:20 <veremit> still worried about it storing all the keys/shadow though
Jan 23 06:53:22 <veremit> Yes, basically
Jan 23 06:53:34 <veremit> friend suggested the idea . then I found etckeeper online
Jan 23 06:53:53 <beltorak> yeah, I haven't played around with too much of that. I've seen a lot of homegrown solutions - starting way back in the subversion days; lol
Jan 23 06:53:56 <veremit> given I've got a rolling dstro that I share amongst PC's .. would be really handy to save/branch/etc
Jan 23 06:54:02 <veremit> yeah? like ?
Jan 23 06:54:46 <beltorak> i started doing that, but then realized that all my systems have different /etc layouts, so i stick it in subtree in my unix-personalization and symlink in what I require
Jan 23 06:55:14 <beltorak> ((I am forced to use Oracle Linux for work.... and then there's cygwin for my main work machine....))
Jan 23 06:55:18 <veremit> fair enough .. should be possible to script it to an extent, based on baselayout type
Jan 23 06:55:28 <beltorak> yeah, I haven't gotten that advanced
Jan 23 06:55:30 <veremit> eww cygwin and What-oracle linux!?
Jan 23 06:55:35 <beltorak> yeah
Jan 23 06:55:39 <veremit> although .. yeah .. scripting .. I don't do enough, either lol
Jan 23 06:55:43 <beltorak> oracle linux - it's a RHEL spinoff
Jan 23 06:55:48 <veremit> ah
Jan 23 06:55:53 <beltorak> but the only thing that is even remotely easy to install the oracle db on
Jan 23 06:56:05 <veremit> redhat realyl didn't do well outa of its .. well ..
Jan 23 06:56:11 <veremit> that doesn't surprise me
Jan 23 06:56:19 <beltorak> oracle makes a fabulous database, but everything else, and that includes the installer for the database, .... blows
Jan 23 06:56:23 <veremit> you need to get familiar with virtualisation ..
Jan 23 06:56:35 <beltorak> i do virtualize the oracle-db instance
Jan 23 06:56:52 <beltorak> still took a few weeks "in my copious spare time" to figure out how to get the oracle install to go smoothly
Jan 23 06:57:11 <beltorak> still not perfect, there's a script for the sql client that's missing. can't get it to recognize that it has run.
Jan 23 06:57:23 <veremit> ah another one with the "copious free time" phrase lolol that's a favourite with a colleage/friend
Jan 23 06:57:31 <beltorak> yeah
Jan 23 06:57:57 <veremit> once upon a time, the population *had* spare time .. wtf it gone?!
Jan 23 06:58:52 <beltorak> there's a great series on youtube - crash course in world history - where he says that antorpologists thing that the early humans - before agriculture - actually had more leasure time than later civilizations
Jan 23 06:59:13 <beltorak> the problem was that if you wanted to gather 1000 calories of foodstuffs, it took slightly less than 1000 calories of effort
Jan 23 06:59:58 <beltorak> all these cool toys, designed so the universe can hasten its progress to its eventual heat death :)
Jan 23 07:00:11 <veremit> rather :/
Jan 23 07:02:19 <beltorak> interesting; my color prompt can't detect that i'm SSHd in when i "sudo su -"....
Jan 23 07:02:33 <beltorak> probably has something to do with sudo clearing the env
Jan 23 07:02:50 <beltorak> but, now to test the gpio pins
Jan 23 07:03:26 <veremit> yes thats some special debian=fu
Jan 23 07:03:39 <veremit> I couldn't believe wtf it thought it was doing until I started reading some docs
Jan 23 07:03:41 <veremit> very weird
Jan 23 07:05:22 <beltorak> heh; i've been toying with linux since 2001, started with slackware back in the day. learned a lot. nowadays if my network card goes on the fritz I hang my head and reboot :/ lol
Jan 23 07:06:48 <beltorak> networking is one area that needs a serious overhaul in the linux OS; it's very complicated now. something needs to be done to bring all the different tools into the same room and make them work together or something.
Jan 23 07:08:03 <veremit> networking is solid for me
Jan 23 07:08:15 <veremit> but then I don't use systemd or crazy wireless cards
Jan 23 07:08:25 <beltorak> i'm talking more about the interaction of all the tools
Jan 23 07:08:29 <veremit> but systemd-netctl is supposed to be the next wonderful thing
Jan 23 07:08:46 <veremit> yes, its fragmented depending in your 'manager' tool
Jan 23 07:09:02 <beltorak> /etc/networking, network manager, resolv.conf, dnscache, bind (providing the cache),
Jan 23 07:09:36 <beltorak> oh and dhcpclient
Jan 23 07:09:55 <veremit> for me .. tbh .. I'd stick with wpa_supplicant for wireless (hand-crafted)
Jan 23 07:10:02 <veremit> once its set up .. set it , forget it
Jan 23 07:10:07 <veremit> I don't hot plug a llot of stuff
Jan 23 07:10:18 <beltorak> yeah, i'm either using wpa supplicant or wicd - i forget which
Jan 23 07:10:28 <veremit> wicd is horrid
Jan 23 07:10:30 <veremit> don't use that
Jan 23 07:10:34 <beltorak> probably supplicant, cause I remembver keeping my windows partition just so i coudl have the driver
Jan 23 07:10:38 <veremit> I've got networkmanager .. which is a beast.
Jan 23 07:10:43 <veremit> I'm gonna learn connman though
Jan 23 07:11:24 <beltorak> network manager is good for a user space tool, problem is (as i rememvber) the networking doesn't start up till i log in a desktop environment
Jan 23 07:11:46 <veremit> you can set up #system connections#
Jan 23 07:11:47 <beltorak> for that (or a server) you typically use ifupdown (/etc/network/interfaces)
Jan 23 07:11:54 <veremit> I've hard-coded net.enp1s0
Jan 23 07:11:58 <veremit> bloody stupid netnames
Jan 23 07:12:25 <beltorak> and if /etc/network/interfaces doesn't have a net device, the "failsafe" service waits up to two minutes for it to come on line
Jan 23 07:12:48 <beltorak> bit of a pain when I have to take a box offline and boot it locally to troubleshoot
Jan 23 07:13:10 <veremit> ah /etc/network/interfaces is horrid
Jan 23 07:13:17 <veremit> I can see why everyone went systemd there ..
Jan 23 07:13:21 <beltorak> lol
Jan 23 07:13:26 <veremit> I like my /etc/conf.d/net.
Jan 23 07:13:49 <beltorak> yeah, I am really glad to get away from sysvinit; i prefer ubuntu's upstart, but i'll take systemd
Jan 23 07:14:06 <veremit> openrc ftw!! :D lol
Jan 23 07:14:15 <beltorak> lol - i haven't tried that one
Jan 23 07:14:18 <veremit> upstart is quite weird .. but miles better than systemd
Jan 23 07:14:38 <veremit> I think openrc is considered 'old' .. its just .. proper traditional user-dev-centric-linux
Jan 23 07:14:54 <beltorak> I rolled my own sysvinit "framework" just to make writing services easier - handled option parsing and dispatching, printing help, that sort of thing
Jan 23 07:15:11 <veremit> yeah that stuff is a headache ..
Jan 23 07:15:26 <veremit> you post your stuff online? or just keep it for your own use?
Jan 23 07:15:28 <beltorak> but the killer is that for every service I had to find out some way of detecting it's status - pidfile, socket, ps (ick)
Jan 23 07:15:39 <beltorak> well those scripts are .... on an old harddrive somewhere
Jan 23 07:15:49 <veremit> yup. . I wrote an openrc init script .. it mostly works .. but needs better testing tbh lol
Jan 23 07:15:53 <veremit> for an app our company wrote
Jan 23 07:15:58 <beltorak> my current scripts are at https://bitbucket.org/beltorak/unix-personalizations.git
Jan 23 07:16:17 <beltorak> testing shell scripts - there's another thing I need to clean up
Jan 23 07:16:32 <beltorak> it's in ... opt/lib/shell ... somewhere
Jan 23 07:16:48 <veremit> eww nice lol
Jan 23 07:17:05 <beltorak> I think after I put a few weeks into that I found an official bashunit, been meening to check it out
Jan 23 07:17:34 <beltorak> most of my heavy personalizations (like my prompt) are in opt/lib/shell/profile
Jan 23 07:19:32 <beltorak> I'd really like a *.d approach to ~/.bashrc and the like
Jan 23 07:19:54 <beltorak> but everyone seems to dump a lot of stuff into the main file :-/
Jan 23 07:30:24 <beltorak> ok; how do i set the gpio pin mode? I have to write 0x27 somewhere, right?
Jan 23 07:31:04 <veremit> beltorak: yeah I thought that .. years ago
Jan 23 07:31:24 <veremit> I've seen debian configs where you source aliases and such separately
Jan 23 07:31:37 <veremit> so I guess its manual implementation
Jan 23 07:31:55 <beltorak> let me try to uncomment something in uEnv.txt
Jan 23 07:32:08 <veremit> which pin is it?
Jan 23 07:32:22 <beltorak> 68
Jan 23 07:32:55 <beltorak> if I cat /sys/kernel/debug/gpio, it shows gpio-68  (sysfs               ) in  hi
Jan 23 07:33:07 <beltorak> that 'sysfs' should say 'P8_10'
Jan 23 07:33:38 <beltorak> which i think is automatically handled by one of the dtb/dtbo files
Jan 23 07:34:36 <veremit> scratchpad: http://derekmolloy.ie/kernel-gpio-programming-buttons-and-leds/
Jan 23 07:37:16 <beltorak> ah; that's right; I haven't built the /lib/firmware files yet
Jan 23 07:37:31 <veremit> derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
Jan 23 07:37:37 <beltorak> thanks for the link; I like the cucuit diagram
Jan 23 07:38:41 <veremit> althoguh I'm not a big fan of DM .. he's done a lot of work which people do use
Jan 23 07:38:48 <veremit> and he's graceful enough to publish
Jan 23 07:39:12 <beltorak> yeah, I remember now, the 0x27 goes to some file in *_pinmux
Jan 23 07:39:28 <veremit> working in D-T now?
Jan 23 07:39:34 <beltorak> I am definitely greatful he's published it
Jan 23 07:41:29 <beltorak> well, I can't find the pinmux file; I'm missing something else. I'm going to compile the dtb/dtbo's now
Jan 23 07:42:48 <veremit> yo got the magic device-tree-compiler?
Jan 23 07:45:26 <beltorak> uck; this isn't good;
Jan 23 07:45:47 <beltorak> # git clone https://github.com/beagleboard/bb.org-overlays -> fatal: Out of memory, malloc failed (tried to allocate 524288000 bytes)
Jan 23 07:47:14 <veremit> whoah ouch
Jan 23 07:47:15 <veremit> bad bad
Jan 23 07:47:46 <beltorak> yeah, i had the same problem with the 2015 image running (iirc) a script inside that repo
Jan 23 07:48:12 <veremit> nasty
Jan 23 07:57:14 <beltorak> well i checked it out on my laptop and scp'd it to the bone; which script do i run first?
Jan 23 07:57:39 <veremit> oo dunno .. I'm just unpickingn the article and trying to work out pin/gpio mappings
Jan 23 07:57:47 <veremit> where's zmatt when you need him *sigh*
Jan 23 07:57:54 <beltorak> lol
Jan 23 07:58:12 <veremit> he's got a Spreadsheet of wisdom .. I should really bookmark it
Jan 23 07:58:27 <beltorak> ah; it's at the top of the readme
Jan 23 07:58:50 <veremit> and why don't I have a BBB -SRM on this machine :/
Jan 23 07:59:04 <beltorak> BBB -SRM?
Jan 23 07:59:31 <veremit> the System Ref. Manual
Jan 23 07:59:41 <beltorak> ah
Jan 23 08:02:43 <beltorak> yeah. not good. running the ./dtc-overlay.sh got to "Cloning into '/root/git/bb.org-dtc'..." -> fatal: Out of memory, malloc failed (tried to allocate 524288000 bytes)
Jan 23 08:02:57 <beltorak> I think I might have a bad spot of ram....
Jan 23 08:02:59 <veremit> thats 500mb ..
Jan 23 08:03:12 <beltorak> oh you are right
Jan 23 08:03:16 <beltorak> i thoguht it was 50
Jan 23 08:03:45 <beltorak> well, it's doubly bad if it's not there slaving away for me....
Jan 23 08:03:55 <beltorak> :-/
Jan 23 08:04:20 <veremit> you sure you wanna do that as root .. and probably not in emmc
Jan 23 08:05:04 <beltorak> maybe this will help: https://stackoverflow.com/questions/8855317/git-push-out-of-memory-malloc-failed ...
Jan 23 08:06:28 <beltorak> fair enough; lol;
Jan 23 08:06:50 <veremit> or on a bbb *shudder* what ARE you doing?! lol
Jan 23 08:07:00 <veremit> work on ya PC .. push/scp to the bbb :P lol
Jan 23 08:12:19 <beltorak> fixed with git config --global http.postbuffer $((64*1024*1024))
Jan 23 08:12:53 <beltorak> lol - yeah, i probably should; but some of these things expect to write to /lib/firmware, etc
Jan 23 08:13:14 <veremit> you're doin serious dev there :P lol
Jan 23 08:13:19 <beltorak> lol
Jan 23 08:13:44 <beltorak> i doubt there's quite enough horsepower to run minecraft.... but we'll see how far i can push it
Jan 23 08:13:54 <veremit> hehe
Jan 23 08:14:08 <veremit> you need to pick up a pi2 or another multicore arm ;)
Jan 23 08:14:17 <beltorak> lol
Jan 23 08:14:35 <veremit> I like my wandboard :) imx6 are cool .. hehe
Jan 23 08:14:36 <beltorak> yeah, that's what i need, more machines :)
Jan 23 08:14:42 <veremit> a cluster!
Jan 23 08:14:45 <veremit> definitely!
Jan 23 08:15:24 <beltorak> coolest cluster I heard about was the USAF beowolf cluster; *drools*
Jan 23 08:15:25 <veremit> I ahve 2 BBB, three RPis, a B-Pi, O-Pi .. too many dual-core wands to think about
Jan 23 08:15:52 <veremit> 12 dual-core imx6 .. now -there's- a cluster .. but they're for a project lol
Jan 23 08:16:23 <beltorak> wow;
Jan 23 08:17:01 <beltorak> wow, init 6 goes down really quick
Jan 23 08:17:09 <veremit> lol
Jan 23 08:17:26 <beltorak> i have to kill my konsole when I do that
Jan 23 08:17:39 <veremit> heh
Jan 23 08:18:27 <beltorak> ((on the topic of not running around as root, I wonder how long my debian password is going to stay 'temppwd'.... as long as the java cert store password has stayed at 'changeit' perhaps?))
Jan 23 08:20:07 <veremit> lol
Jan 23 08:20:13 <veremit> until you type 'passwd'
Jan 23 08:21:21 <beltorak> hehe; one day, i might get around to that; if I can get some external GPIOs to work
Jan 23 08:21:34 <veremit> yeah I wish I could help more with that
Jan 23 08:22:26 <beltorak> well i jsut got the pins exported
Jan 23 08:22:30 <beltorak> moment of truth
Jan 23 08:23:24 <beltorak> no dice :(
Jan 23 08:24:25 <beltorak> still have control over the USR LEDs
Jan 23 08:29:19 <beltorak> well I am truly out of ideas
Jan 23 08:29:37 <veremit> I think it could be permissions (even as root) or some ***
Jan 23 08:29:41 <veremit> there's some gotcha
Jan 23 08:30:12 <beltorak> but now that I am much more familiar with the workings of the BB /sysfs, I will try (tomorrow) to reflash the stock debian 7.x and work through the problem that prompted me to try to upgrade to begin iwith
Jan 23 08:32:29 <beltorak> well, one more thing to try
Jan 23 08:32:32 <veremit> ok
Jan 23 08:32:44 <beltorak> I can't wrap my head around the pull-up vs pull-down
Jan 23 08:33:03 <veremit> will try prise some wisdom outta someone here about when that *does* work and when it *doesn't*
Jan 23 08:33:09 <veremit> people have made it work .. so there's a way
Jan 23 08:33:16 <beltorak> yeah
Jan 23 08:33:31 <veremit> PU- vs PD- is just like having a virtual resistor to Supply or GND respectively
Jan 23 08:34:20 <beltorak> got that; what effect does it have?
Jan 23 08:34:38 <veremit> its an electrical one really .. just ties the pin to a known value
Jan 23 08:35:37 <beltorak> it's an input thing, right? so if I have a PU on it, that means without any connection that would read '1'?
Jan 23 08:35:45 <veremit> basically, yeah
Jan 23 08:35:53 <beltorak> and I would have to connect it to GND to get it to read '0'?
Jan 23 08:37:11 <veremit> yes .. or anything less than the pull-up resistance
Jan 23 08:37:11 <beltorak> so how is a PD any different than no pull-X resistor connected? does the value float somewhere between 0 and 3.3v?
Jan 23 08:38:40 <veremit> I think it qualifies as 'unknown' .. it doesn't 'float' per-se as there's nothing (theoretically) to define it
Jan 23 08:43:32 <beltorak> ... the pinmux has the wrong value... doesn't reflect what's in the gpio directory
Jan 23 08:44:06 <veremit> no
Jan 23 08:44:12 <veremit> the sysfs seems .. funky .. at beset
Jan 23 08:44:14 <veremit> -e
Jan 23 08:44:21 <beltorak> yeah, it's a bit all over the place
Jan 23 08:44:37 <veremit> it doesn't error when ti doesn't work .. or isn't confugured . or anything
Jan 23 08:44:43 <veremit> so troubleshooting is a complete *****
Jan 23 09:03:33 <beltorak> ok; brain is gel; time for sleep
Jan 23 09:03:37 <beltorak> thanks for the company; gnight
Jan 23 09:03:42 <veremit> no prob, sleep well
Jan 23 09:03:49 <veremit> hopefully tomorrow will be abetter day!
Jan 23 09:46:05 <bigi> help
Jan 23 09:46:42 <bigi> HELP
Jan 23 09:46:45 <tbr> http://www.catb.org/esr/faqs/smart-questions.html
Jan 23 09:46:54 <bigi> HELLO
Jan 23 09:47:37 <tbr> just ask your questions. see link above
Jan 23 16:31:09 <willous> Hello, I have some problems with my BBB revC. When I apply power, it does not do anything. LEDs doesn't blink, no video output, nothing. I had connected it to the CRAMPS running machinkit, I had token it to the school, day before it worked, but in the school did not. Do not know what could go wrong, CRAMPS seems to be ok. Maybe it is the
Jan 23 16:31:56 <willous> ncp439, but in datasheet is written that it is max to 28V. I did apply 5V and 12V to the cramps..
Jan 23 16:33:09 <willous> or TPS65217, I am not really sure.
Jan 23 16:36:51 <tbr> if you applied 12V to the BBB, then it's dead
Jan 23 16:40:32 <willous> so why is there a voltage protection? TPS65217 and NCP349? I did not applied 12V to BBB, only to CRAMPS (cape for 3D printer).. I connected it via USB..
Jan 23 16:41:06 <veremit> wow ouch
Jan 23 16:41:14 <veremit> yeah you fried it .. you got no smoke?!
Jan 23 16:41:30 <veremit> did you check the spec of the tps65217
Jan 23 16:41:36 <willous> no smoke..
Jan 23 16:41:37 <tbr> if the 12V travelled backwards through USB, then it's toast
Jan 23 16:41:40 <willous> no smell
Jan 23 16:41:44 <veremit> aww
Jan 23 16:42:02 <tbr> or is the CRAMPS supposed to get 12V?
Jan 23 16:42:10 <Jonnyw2k> hey is it possible to add PoE to the beaglebone? like one of these: http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=47331#Features
Jan 23 16:43:29 <tbr> Jonnyw2k: if you respin the design and produce it yourself, probably
Jan 23 16:43:38 <tbr> this is what I'd do: https://upload.wikimedia.org/wikipedia/commons/f/f1/ZyXEL_ZyAIR_G-1000_and_D-Link_DWL-P50_20060829_2.jpg
Jan 23 16:44:18 <Jonnyw2k> tbr, that's what I was tempted todo
Jan 23 16:45:11 <Jonnyw2k> was looking at http://www.ebuyer.com/263590-tp-link-tl-poe10r-poe-splitter-tl-poe10r
Jan 23 16:47:55 <willous> so do you think if I change TPS65217 it will work?
Jan 23 16:48:37 <tbr> willous: does the led close to the power port blink briefly if you connect power?
Jan 23 16:49:55 <willous> nope :/
Jan 23 16:50:08 <tbr> without fully understanding what happened, it's either the TPS or the SoC itself. Neither are easy to replace unless you have access to rework and reballing equipment
Jan 23 16:50:55 <tbr> are you powering from USB or from the barrel connector?
Jan 23 16:52:04 <willous> I have acces to hot air soldering station.. barrel connector
Jan 23 16:52:36 <tbr> try powering it over USB, just in case
Jan 23 16:54:41 <willous> still nothing
Jan 23 16:54:43 <tbr> as to the chances if you can revive it by replacing the PMIC, you'd need to discuss this with someone else and also provide more details of what exactly happened.
Jan 23 16:55:34 <willous> I will just replace it and if it won't work I will buy new one.. thanks for help ;)
Jan 23 16:55:38 <tbr> I'd order a new BBB to use with that project and leave the broken one to experiment with
Jan 23 16:56:00 <Jonnyw2k> anybody got a good guide for booting a beaglebone black of usb?
Jan 23 16:56:26 <tbr> if the SoC at any point saw significant voltage, while itself being powered off, then it's likely toast too
Jan 23 16:57:09 <tbr> Jonnyw2k: you mean as in shoving SPL, U-Boot, Kernel, Initrd over USB from a PC into the BBB?
Jan 23 16:58:44 <zmatt> veremit: mmwhat?
Jan 23 17:02:41 <veremit> zmatt .. sysfs acces to gpios .. what are the gotchas?
Jan 23 17:06:31 <Jonnyw2k> tbr, no but if thats possible I would like to know how
Jan 23 17:06:53 <zmatt> veremit: slow
Jan 23 17:07:08 <Jonnyw2k> I meant putting uboot on a usb device then booting from a kernel on a usb pen drive
Jan 23 17:07:25 <zmatt> veremit: require pinmux setup (or gambling on the pinmux still being left at gpio from u-boot)
Jan 23 17:07:54 <tbr> Jonnyw2k: not possible. full stop.
Jan 23 17:08:12 <zmatt> the kernel doesn't know the gpio - pin association (I think this can be specified via DT, it hasn't been)
Jan 23 17:08:15 <tbr> Jonnyw2k: you can have your rootfs on USB storage though
Jan 23 17:08:30 <zmatt> you can have everything except u-boot on USB
Jan 23 17:08:53 <zmatt> the ROM does not a notion of "USB booting", but it ain't what you mean
Jan 23 17:08:57 <zmatt> *does have
Jan 23 17:09:25 <Jonnyw2k> tbr, I've done it before (uboot might have still been on my emmc to be honest)
Jan 23 17:10:35 <zmatt> veremit: so if you export a gpio, the kernel doesn't consider the corresponding pin to be occupied... this can be an advantage, e.g. to check pin levels (assuming GPI still works when deselected on this SoC, it did on the dm814x but haven't checked the am335x)
Jan 23 17:11:08 <tbr> Jonnyw2k: yes, if you put MLO/U-boot on emmc, then it's possible
Jan 23 17:12:38 <zmatt> or a really smart usb stick that can also act as host, to support rndis, dhcp, and tftp to serve the SPL :P
Jan 23 17:13:38 <tbr> you mean, like a second BBB? ;)
Jan 23 17:13:40 <veremit> zmatt.. so there's no default gpio in kernel without dt .. depending on uboot?
Jan 23 17:13:40 <Jonnyw2k> so I can ethernet boot?
Jan 23 17:14:38 <zmatt> Jonnyw2k: yes, if you can manage to build an u-boot SPL capable to downloading the second stage also via ethernet
Jan 23 17:14:50 <zmatt> someone managed to do it for usb boot, so it's doable
Jan 23 17:14:57 <zmatt> (eth is simpler than usb)
Jan 23 17:15:10 <Jonnyw2k> I'm confused if I have no emmc would I be able to do it?
Jan 23 17:15:15 <Jonnyw2k> where is uboot saved?
Jan 23 17:15:23 <zmatt> it wouldn't be saved anywhere
Jan 23 17:15:26 <zmatt> just ram
Jan 23 17:15:40 <zmatt> I've loaded baremetal apps via ethernet, never full u-boot though
Jan 23 17:16:29 <Jonnyw2k> so what "loads" the ethernet/usb drivers?
Jan 23 17:16:40 <tbr> if you don't have an eMMC or any other storage attached, it will be tricky :)
Jan 23 17:17:06 <tbr> you can feed SPL by UART or USB from another machine though
Jan 23 17:17:14 <zmatt> Jonnyw2k: https://github.com/mvduin/bbb-asm-demo  here's a tiny tiny tiny program with brief instructions on how to load it via a variety of ways
Jan 23 17:17:22 <zmatt> all of those ways are supported by the ROM bootloader
Jan 23 17:17:55 <Jonnyw2k> I thought I loaded mine from a USB drive, my eMMC was corrupted at the time
Jan 23 17:18:12 <Jonnyw2k> I might have just corrupted my MLO file
Jan 23 17:18:22 <zmatt> your eMMC filesystem probably?
Jan 23 17:18:47 <Jonnyw2k> my head hurt, so where did it get the uboot from when I did that lol
Jan 23 17:18:49 <zmatt> MLO and u-boot nowadays live between the partition table and the first actual partition
Jan 23 17:19:02 <zmatt> so it's not easy to accidently overwrite those
Jan 23 17:19:05 <Jonnyw2k> oh makes sense
Jan 23 17:19:09 <zmatt> not even by repartitioning
Jan 23 17:19:26 <zmatt> this is explained in my detail in the README of the github project I just linked
Jan 23 17:20:02 <zmatt> now u-boot is more complicated because they didn't manage to fit evreything in 109 KB (the max limit for the executable loaded by ROM)
Jan 23 17:20:09 <zmatt> so they had to resort to 2-stage loading
Jan 23 17:20:50 <zmatt> the first stage (SPL) basically just initializes DDR3 ram, locates and loads the full u-boot, and resumes executiong there
Jan 23 17:21:51 <zmatt> serving SPL via ethernet or USB is a piece of cake, but then the fun starts since SPL then starts looking for u-boot.img and probably lgets stuck there
Jan 23 17:22:12 <Jonnyw2k> ahh ok
Jan 23 17:22:15 <zmatt> SPL supports only a very limited number of mechanisms to locate u-boot.img
Jan 23 17:22:28 <zmatt> however, the project BBBlfs shows that usb *is* one of them
Jan 23 17:23:04 <zmatt> and usb booting means it enumerates as RNDIS network device and then proceeds exactly the same as ethernet booting
Jan 23 17:23:15 <zmatt> i.e. it's like eth boot, but more complicated
Jan 23 17:24:41 <zmatt> so it should be quite doable to change the config options of u-boot to include Eth in SPL (at expensive of FAT perhaps or whatever is necessary to make space)
Jan 23 17:25:21 <Jonnyw2k> I only want todo it once
Jan 23 17:25:37 <Jonnyw2k> I may have ripped my uSD card slot of my board a while ago
Jan 23 17:26:11 <zmatt> then use BBBlfs
Jan 23 17:26:24 <zmatt> http://pastebin.com/x5QzB18E
Jan 23 17:28:39 <Jonnyw2k> zmatt, this makes alot more sense
Jan 23 17:28:59 <Jonnyw2k> I always asumed the "USB" boot in the boot order was a usb flash drive
Jan 23 17:30:51 <yates> i just built the latest/greatest from here: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot. it loads and i see the lights flashing like normal, but i can't get a network connection.
Jan 23 17:30:54 <yates> any ideas?
Jan 23 17:31:18 <yates> (repeating from late last night)
Jan 23 17:32:12 <yates> i tried modifying the /rootfs/etc/network/interfaces file to make eth0 static, and set the /etc/resolv.conf file to known-good dns servers. still no joy.
Jan 23 17:46:45 <zmatt> link does gp up?
Jan 23 17:51:46 <zmatt> *go
Jan 23 18:25:55 <pavel_> hi anyone here ?
Jan 23 18:27:50 <pavel_> hello does anyone read me ?
Jan 23 18:27:58 <veremit> 10-4 good buddy
Jan 23 18:28:05 <veremit> tbr where's your link? :P
Jan 23 18:28:24 <pavel_> my link ?
Jan 23 18:28:40 <tbr> http://www.catb.org/esr/faqs/smart-questions.html
Jan 23 18:29:05 <veremit> thanks bud :D hehe
Jan 23 18:29:08 <veremit> I just scrolled
Jan 23 18:29:30 <zmatt> bbl, shopping
Jan 23 18:29:47 <pavel_> zmatt you are about to buy it ?
Jan 23 18:30:58 <pavel_> I don't have any link, just got my beagleboneblack and read about this chat room, so I came to say HI
Jan 23 18:31:16 <pavel_> lot of people connected but don't see a lot of traffic though
Jan 23 18:32:29 <veremit> pavel_: we're less of a chat channel (although it happens) more technically focussed ..
Jan 23 18:33:52 <pavel_> so looks like I don't know the etiquette here, I just opened my beaglebone and I am new to Linux, do I still post my questions here if I am stuck with something ?
Jan 23 18:36:49 <GenTooMan> You can ask and if anyone alive err awake can answer they likely will
Jan 23 18:37:14 <pavel_> gotcha, thank you Mr. GenTooMan
Jan 23 18:38:53 <GenTooMan> do read the web page although it tends to be a bit behind on some things.
Jan 23 18:39:11 <pavel_> thanks, I am on it
Jan 23 18:52:06 <zmatt> hm, yates vanished again
Jan 23 18:52:41 * zmatt turned out to have adequate supplies, no urgent need to go shopping
Jan 23 20:23:44 <Jonnyw2k> zmatt, so for this usb flasher, do I need to build the binary blobs?
Jan 23 21:51:24 <yates> zmatt: my vanishing was involuntary the last two times. don'
Jan 23 21:51:35 <yates> don't know why but i'm getting cut off.
Jan 23 21:51:48 <yates> maybe a server going down here or there due to the snow/ice storm.
Jan 23 21:52:24 <yates> did you have any thoughts on why my scratch debian build doesn't have netwrok functionaltiy?
Jan 23 21:52:31 <yates> network
Jan 23 21:53:21 <veremit> beltorak
Jan 23 21:53:25 <yates> EvilTelephone: your nick made me think of Electric Light Orchestra: "Evil Woman" and "Telephone Line"
Jan 23 22:03:10 <yates> is the serial interface (UART0) on the BBB really TTL? or is it 3.3V?
Jan 23 22:04:39 <Cats_home> 3.3
Jan 23 22:04:48 <Cats_home> I use a 3.3 adapter
Jan 23 22:05:11 <yates> Cats_home: i have a 3.3V RS232/serial usb
Jan 23 22:05:26 <yates> they are handy
Jan 23 22:05:54 <yates> actually i have that AND a 5V TTL.
Jan 23 22:06:22 <Cats_home> yep
Jan 23 22:06:28 <Cats_home> I got a bunch :)
Jan 23 22:08:09 <yates> yeah, i do too. it's a PITA when you're troubleshooting and realize you need one and have to wait 23 days to get one in.
Jan 23 22:08:21 <yates> s/23/2-3/
Jan 23 22:08:26 <yates> 23 days? sheesh!
Jan 23 22:12:00 <Cats_home> from china ? yes sure
Jan 23 22:12:01 <Cats_home> lol
Jan 23 22:12:17 <Cats_home> got an electronic lab at work, it helps
Jan 23 22:13:36 <yates> that's a downside of being an independent contractor - one has to stock their own "lab"
Jan 23 22:13:56 <yates> i.e., our bonus room..
Jan 23 22:15:11 <Cats_home> man's cave
Jan 23 22:15:36 <Cats_home> ehehe but I got loads of electronic crap home too
Jan 23 22:15:44 <yates> heh
Jan 23 22:15:49 <Cats_home> more like a hobby that turned into work
Jan 23 22:16:14 <yates> always good to have work!
Jan 23 22:17:00 <Cats_home> yep, but that's a choice
Jan 23 22:17:05 <yates> my night job is playing piano/keyboards at church. doesn't pay, but it's fun.
Jan 23 22:17:16 <Cats_home> nice
Jan 23 22:17:33 <Cats_home> my night jobs is kids :)
Jan 23 22:17:44 <yates> lolol!
Jan 23 22:17:45 <Cats_home> I'd prefer playing organ at church sometimes
Jan 23 22:18:00 <yates> oh, you too?
Jan 23 22:18:09 <yates> that's a coincidence
Jan 23 22:18:38 <yates> back in the day i had a B3 and 910 Leslie. now i prefer piano.
Jan 23 22:20:26 <Cats_home> My father has an A100 and dunno the leslie
Jan 23 22:20:37 <yates> oh yeah, that's the era for sure!
Jan 23 22:20:42 <Cats_home> but I moved accross antlantic
Jan 23 22:20:58 <Cats_home> so I got  a Roland piano and a T524 at home
Jan 23 22:21:09 <Cats_home> too few keys on the T
Jan 23 22:21:31 <Cats_home> but tweaked it a lot
Jan 23 22:21:34 <Cats_home> :)
Jan 23 22:21:40 <yates> is that a 44-note dual manual?
Jan 23 22:21:44 <yates> 1-octave pedals?
Jan 23 22:21:50 <Cats_home> yep
Jan 23 22:22:02 <Cats_home> and missing some drawbars for the lower
Jan 23 22:22:21 <PF> Hi, someonw with experience with mcasp device tree config?
Jan 23 22:22:33 <Cats_home> was a cheesy home organ but turned it into monster :P
Jan 23 22:22:54 <Cats_home> PF nope
Jan 23 22:23:06 <Cats_home> don't even know what is mcasp
Jan 23 22:23:16 <PF> multi channel audio serial port
Jan 23 22:23:23 <yates> Cats_home: you may find this interesting.. i just stumbled on it: https://www.youtube.com/watch?v=wJvWinCpk9o
Jan 23 22:23:35 <Cats_home> ah... nope
Jan 23 22:25:12 <Cats_home> yates nice
Jan 23 22:25:17 <PF> i really need some help with device tree config for mcasp...
Jan 23 22:25:53 <EvilTelephone> yates: heh.. not familiar with that.. i'll have to look it up
Jan 23 22:26:09 <yates> EvilTelephone: :)
Jan 23 22:26:51 <PF> i have made some advance in an 6 in 8 out audio cape for beaglebone black, but now i'm stuck with alsa, only recognises me 4 channels
Jan 23 22:28:35 <yates> Cats_home: this looks like it may be close to your T524: https://www.youtube.com/watch?v=wJvWinCpk9o#t=3m26s
Jan 23 22:29:04 <yates> the T-10
Jan 23 22:29:07 <yates> T-100
Jan 23 22:30:16 <Cats_home> yep
Jan 23 22:30:39 <Cats_home> someone gave it to me
Jan 23 22:30:48 <yates> ha!
Jan 23 22:30:55 <Cats_home> but I had to oil the whole thing
Jan 23 22:31:14 <Cats_home> the oil bottle was still in the organ, and fulll
Jan 23 22:31:25 <yates> lol
Jan 23 22:34:24 <yates> my first organ was a Kimball Swinger; i nagged the heck out of my parents until they bought one for me in 6th grade. US$600: similar to this: https://www.youtube.com/watch?v=cuN7SAoVHvA
Jan 23 22:34:34 <yates> i think mine was a 600
Jan 23 22:38:58 <Cats_home> ehehe nice
Jan 23 22:39:09 <Cats_home> time to make lunch !!
Jan 23 22:39:16 <Cats_home> cya
Jan 23 22:39:20 <yates> l8r
Jan 23 23:03:36 <eLumiNate> Help!  I flashed Wheezy, but no Eth over USB from eMMC now.  There's no uEnv.txt on the FAT disk, dunno what to put there?
Jan 23 23:49:43 <khaarbye> does anyone know what degree of power control I can implement on the M4 portion of an x15? Can I for instance power down the A15s, wait for some sensor input and on an event initiate A15 boot?
Jan 23 23:54:42 <beltorak> veremit: hi
Jan 23 23:55:28 <veremit> zmatt : probably.
Jan 23 23:55:53 <veremit> beltorak: damn timezones lol
Jan 23 23:56:12 <beltorak> lol - and i generally don't wake early
Jan 23 23:56:43 <veremit> well .. I'm either awake or asleep .. either or.
Jan 23 23:58:17 <beltorak> I am considering on whether or not to try and figure out why changing the gpio??/{direction,value} has no effect on the status listed in the pinmux, or just start over with a debian 7 image....
Jan 24 00:03:57 <beltorak> at least I have learned a lot about it over the last week
Jan 24 00:06:01 <beltorak> ok; I boot up the board, and no GPIO pins are exported. There are no overlays listed in .../slots.
Jan 24 00:07:04 <beltorak> do I need any overlays, or should i be able to contol the export pins right now? the overlays just set up the pins according to a default, right?
Jan 24 00:10:15 <filt3r> im pretty sure pins are never automatically exported by the kernel, or at least i've never seen it, so you will need some script, etc. which will export the gpios you need to thte sysfs
Jan 24 00:10:26 <filt3r> on boot
Jan 24 00:12:48 <beltorak> filt3r: yeah, I am trying to do it manually just to see if I can do it - I been having issues with it doing the automatic things
Jan 24 00:16:26 <beltorak> what is this folder for? It seems to have lots of information about the pins... /sys/kernel/debug/pinctrl/44e10800.pinmux
Jan 24 00:22:52 <filt3r> it seems to contain information about the pinmux config
Jan 24 00:23:24 <beltorak> yeah, that's what I'm thinking
Jan 24 00:24:45 <beltorak> I've been trying my tests on pin 68 and 26 (p8 10 and 14); pinmux-pins seems to indicate that 68 is assigned to the ethernet?? pin 68 (44e10910.0): 4a100000.ethernet (GPIO UNCLAIMED) function cpsw_default group cpsw_default
Jan 24 00:25:04 <beltorak> what is "cpsw"? is that "cape software"?
Jan 24 00:27:31 <filt3r> http://processors.wiki.ti.com/index.php/AM335x_CPSW_(Ethernet)_Driver's_Guide
Jan 24 00:27:49 <beltorak> ohhh.... i've been confusing pin numbers.... that folder has kernel pin numbers, not gpio pin numbers
Jan 24 00:28:02 <filt3r> ye probably not
Jan 24 00:28:06 <filt3r> give me a sec
Jan 24 00:28:46 <beltorak> http://quabr.com/27477732/misunderstanding-beaglebone-gpio-pinmux
Jan 24 00:29:07 <veremit> beltorak: YES! sorry if I didn't convey that yetserday lol
Jan 24 00:29:08 <beltorak> there's a link in the answer to valvers that i'm reading now
Jan 24 00:29:21 <veremit> hence I was going on about a spreadsheet
Jan 24 00:29:40 <veremit> in the kernel, gpios are numbered linearly . but they have no correlation to pins on the processor even lol
Jan 24 00:29:45 <beltorak> where's that spreadsheet again? I'm just starting to put together some bookmarks
Jan 24 00:29:49 <veremit> so you need a table :)
Jan 24 00:29:58 <veremit> zmatt .. where ARE you :P lol
Jan 24 00:30:01 <beltorak> lol
Jan 24 00:30:05 <veremit> zmatt
Jan 24 00:30:07 <veremit> zmatt
Jan 24 00:30:20 <filt3r> p8_10 should be gpio2_4 and p8_14 should be gpio0_26
Jan 24 00:30:23 <veremit> its on his page somewhere .. but I can't remember the links
Jan 24 00:30:37 <filt3r> so you need to export (2 * 32 + 4) and 26
Jan 24 00:33:03 <filt3r> there is a table in the bbb system reference manual on page 84 for p8 and on page 86 for p9
Jan 24 00:33:43 <beltorak> ..... ok... so that's making a little more sense
Jan 24 00:34:59 <filt3r> https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true this should be the latest one
Jan 24 00:36:30 <veremit> filt3r+++ thats it
Jan 24 00:36:37 <veremit> see I know it when I see it lol
Jan 24 00:36:47 <veremit> but i have nearly been up 20odd hours :/
Jan 24 00:45:51 <beltorak> yikes veremit; you should get some sleep; lol
Jan 24 00:46:08 <veremit> yea .. bit of food then definitely bed lol
Jan 24 00:50:37 <veremit> I think one complication arises, because you don't (or do you) use the same references in the DT file as you do in sysfs?
Jan 24 00:51:08 <veremit> actually .. since the kernel does both .. you'da thought ..
Jan 24 00:51:24 * veremit pulls up the SRM .. since I downlaoded it before ..
Jan 24 00:51:52 <beltorak> veremit: I'm not sure what you mean... can you give me an example?
Jan 24 00:54:42 <veremit> beltorak: don't worry .. pretty sure I'm talkin drivel .. lol
Jan 24 00:54:52 <beltorak> lol
Jan 24 00:56:46 <veremit> where are gpio nodes under sys?
Jan 24 00:57:00 <veremit> ah got it
Jan 24 00:57:08 <veremit> ./sys/class/gpio
Jan 24 00:57:11 <beltorak> ok; so going by the SRM, P8_14 is (kernel) gpio bank 0 position 26 (gpio0[26]) aka gpio 26; P8_10 is (kernel) gpio bank 2 position 4 (gpio2[4]) aka gpio 60....
Jan 24 00:57:15 <beltorak> is that right?
Jan 24 00:58:05 <veremit> sounds roughly right yeah
Jan 24 00:58:18 <filt3r> gpio2_4 is (2 * 32 + 4 =) 68
Jan 24 00:58:27 <veremit> and I can see on mine .. gpiochip0, gpiochip32 ..
Jan 24 00:58:44 <filt3r> echo 68 > export
Jan 24 00:58:50 <filt3r> than you should see a folder gpio68
Jan 24 00:58:52 <veremit> aha .. thats it
Jan 24 00:59:00 <veremit> yes I got gpio50 for some reason lol
Jan 24 01:00:08 <veremit> I *really* must fire up my new BBB
Jan 24 01:00:26 <veremit> the whole idea of getting it was to play with it
Jan 24 01:00:38 <veremit> do a bit of testing
Jan 24 01:00:53 <beltorak> how do i get to the kernel pin number ?
Jan 24 01:01:08 <filt3r> you mean the number you have to export?
Jan 24 01:01:15 <filt3r> just multiply the bank by 32 and add the gpio number
Jan 24 01:01:29 <filt3r> so gpio2_4 is (2 * 32 + 4)
Jan 24 01:01:42 <beltorak> no, the number listed in the first column of /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
Jan 24 01:02:06 <veremit> oh crikey not those too lol
Jan 24 01:02:27 <filt3r> beltorak: what do you need it for?
Jan 24 01:02:49 <beltorak> lol veremit - yeah, that seems to show how the pin is actually being used, since gpio??/{direction,value} is having no effect for me
Jan 24 01:03:31 <veremit> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
Jan 24 01:03:32 <filt3r> if you can export it, thatn the pin should be free to use
Jan 24 01:04:17 <veremit> I suggest picking perhaps a known pin .. and backtracing
Jan 24 01:04:27 <veremit> but .. theoretically .. the numbering should be consistent
Jan 24 01:04:27 <filt3r> but i can tell you how to map it just give me a sec
Jan 24 01:12:58 <beltorak> ok; i found something - http://www.valvers.com/embedded-linux/beaglebone-black/step04-gpio/ - shows a table with the register offset and P? pin number
Jan 24 01:14:18 <beltorak> and that comes from the sitara TRM
Jan 24 01:15:16 <filt3r> ok, so now its gets funny if you can follow: we want to look for gpio2_4, so you open the am335x datasheet and search for gpio2_4, you should land on page 29, then you see that the pin is gpmc_wen in MODE0, now you open the AM335x technical reference manual pdf and search for conf_gpmc_wen, you should land on page 1376, now you should see an addres in the left column 898h, take this address and add 0x44e10000 to it, so you should have 0x44e10898
Jan 24 01:15:16 <filt3r> now search for this address in the output of /sys/kernel/pinmux/44e10800.pinmu.pinmux-functions and you should see that 0x44e10898 is pinmux pin number 38
Jan 24 01:16:38 <Matthew> Hello
Jan 24 01:16:41 <beltorak> thanks filt3r; that's were I was eventually ending up
Jan 24 01:16:52 <filt3r> but the ouput of pinmux-pins does not change
Jan 24 01:16:56 <Matthew> I think I have a problem...
Jan 24 01:17:08 <beltorak> oh
Jan 24 01:17:09 <beltorak> ok
Jan 24 01:17:10 <filt3r> so maybe it's static and just represents the configuration in the devicetree
Jan 24 01:17:19 <beltorak> hmmm
Jan 24 01:17:24 <veremit> filt3r: I belive so
Jan 24 01:17:34 <veremit> which is easy enough to test ...
Jan 24 01:17:40 <filt3r> ye
Jan 24 01:17:44 <filt3r> it did not change for me
Jan 24 01:18:02 <veremit> it definitely doesnt' change on echo > export :D
Jan 24 01:18:03 <beltorak> what about the "pins" file then? is that also statuc?
Jan 24 01:18:28 <veremit> beltorak: I -think- all those files are populated when DT is read/translated
Jan 24 01:18:40 <veremit> if you can get it to load a DT at run-time ..
Jan 24 01:18:42 <veremit> you mgiht see a change
Jan 24 01:18:46 <beltorak> ok; i can inspect that suff later
Jan 24 01:18:56 <beltorak> so that doesn't change with the overlays either?
Jan 24 01:19:13 <veremit> beltorak: depends if they change the pinmux
Jan 24 01:19:30 <Guest87851> ok
Jan 24 01:19:43 <Guest87851> so anyone here who can help me?
Jan 24 01:20:05 <veremit> Its Mr Kridner :) good day sir
Jan 24 01:20:11 <Guest87851> ok
Jan 24 01:20:14 <Guest87851> so...
Jan 24 01:20:20 <Guest87851> I got this: https://www.iogear.com/product/GUH285/
Jan 24 01:20:36 <Guest87851> and then I plugged it into my beaglebone black...
Jan 24 01:20:41 <Guest87851> and then,
Jan 24 01:20:54 <Guest87851> it didn't turn on
Jan 24 01:20:55 <yates> ok, so here is the uart0 output from rcn's "build-your-own" latest bbb image using debian rootfs: http://ur1.ca/og28b -> http://paste.fedoraproject.org/314147/35983871
Jan 24 01:20:57 <veremit> Boom :D
Jan 24 01:21:05 <yates> i just can't get a network connection.
Jan 24 01:21:20 <yates> i.e., i can't ping or ssh into the board.
Jan 24 01:21:22 <yates> does anyone see the problem?
Jan 24 01:21:49 <filt3r> beltorak: ye, so the output of the pinmux-pins and pins file probably shows the current status of the pinmux, but i'm very sure that just exporting the gpio pin does not change the pinmux state
Jan 24 01:22:38 <beltorak> ok; for my future reference, how do I change the current pinmux status? is that controlled by echoing to gpio??/direction?
Jan 24 01:22:43 <yates> i'm wondering if this experimental build uses ipv6 addresses only?
Jan 24 01:23:27 <filt3r> beltorak: probably not, you have to change the devicetree
Jan 24 01:23:32 <filt3r> to change the pinmux
Jan 24 01:23:38 <beltorak> yates: is there suppose to be something about aquiring a network address?
Jan 24 01:23:40 <zmatt> you can also dump the pinmux state using show-pins-v2.pl
Jan 24 01:24:04 <veremit> TADA!
Jan 24 01:24:28 <veremit> yates: I see no net config whatsoever there ...
Jan 24 01:24:30 <zmatt> and you can change it at runtime using DT overlays (official way), cape-universal (blegh), or meddling with the control module yoruself
Jan 24 01:24:50 <veremit> zmatt: where's your spreadsheet?! :p
Jan 24 01:24:56 <veremit> I'ma bookmark it :D
Jan 24 01:25:01 <yates> here is the /etc/network/interfaces file: http://ur1.ca/og28h -> http://paste.fedoraproject.org/314148/59868414
Jan 24 01:25:08 <zmatt> http://goo.gl/Jkcg0w
Jan 24 01:25:09 <beltorak> zmatt: yeah, I'm trying to learn how to do it manually; I can't seem to affect anything connected to the external gpios
Jan 24 01:25:52 <yates> veremit: what would a "net config" look like?
Jan 24 01:25:54 <veremit> zmatt: beltorak was the person I was hoping you could help with gpios :p
Jan 24 01:26:18 <veremit> yates: ip addr ? ip link ? ip .. erm .. what are the new Ip commands? ifconfig -a
Jan 24 01:26:32 <filt3r> ip a
Jan 24 01:26:51 <Cats_home> damn will have to wait long for a x15
Jan 24 01:27:10 <zmatt> beltorak: unused pins are normally muxed to gpio by default, but not always, check to be sure with show-pins-v2.pl ... it's included somewhere in recent images I think, otherwise download from http://gerbil.xs4all.nl/show-pins-v2.pl.gz
Jan 24 01:27:20 <filt3r> but the new ip tool output sucks, its too cramped and it takes me about 3 times longer to find the address than with the older ifconfig tool
Jan 24 01:27:29 <yates> veremit: what about this: "Starting LSB: Raise network interfaces...."
Jan 24 01:27:43 <yates> wouldn't that be part of something like ifup?
Jan 24 01:27:48 <beltorak> zmatt: I'm using a bleeding edge image I think - 2016-01-16 debian jessie
Jan 24 01:29:31 <beltorak> zmatt: thanks for that
Jan 24 01:29:33 <yates> also, it seems like the serial console only works in the rx direction - nothing i type is echoed or received (that i can tell)
Jan 24 01:29:34 <yates> so i can't login.
Jan 24 01:29:35 <yates> i'm using minicom
Jan 24 01:29:35 <filt3r> does it work in uboot?
Jan 24 01:29:36 <filt3r> the TX direction
Jan 24 01:29:43 <yates> i haven't tried it.
Jan 24 01:29:52 <yates> what do you type to interrupt uboot?
Jan 24 01:29:57 <veremit> dunno .. its all different now
Jan 24 01:29:57 <veremit> system-netctl crap
Jan 24 01:29:57 <veremit> I havent less than a clue
Jan 24 01:29:57 <veremit> flow control off?
Jan 24 01:29:57 * veremit snickers
Jan 24 01:29:59 <filt3r> Press SPACE to abort autoboot in 2 seconds
Jan 24 01:30:03 <zmatt> sounds like ifup yes
Jan 24 01:30:25 <yates> veremit: aha! that could be it..
Jan 24 01:30:46 <veremit> Ctrl-A - O
Jan 24 01:30:51 <veremit> serial port
Jan 24 01:30:56 <veremit> then restart, to be sure
Jan 24 01:31:02 <veremit> save, of course
Jan 24 01:31:27 <beltorak> zmatt: so what does that script tell me? is that just what is muxed by default?
Jan 24 01:31:31 <yates> filt3r: are you talking to me?
Jan 24 01:31:42 <yates> aha.
Jan 24 01:31:44 <yates> i see it now.
Jan 24 01:32:29 <veremit> oo I like that script, zmatt
Jan 24 01:32:47 <zmatt> beltorak: it shows the current mux state
Jan 24 01:32:54 <veremit> I guess it does some funky parsing of the /sys/debug files
Jan 24 01:33:27 <zmatt> veremit: no need to guess when you can inspect its source code :P
Jan 24 01:33:37 <beltorak> zmatt: ok; what's the middle column?
Jan 24 01:33:43 <veremit> true .. thats got a lot of blob in it :P
Jan 24 01:34:11 <beltorak> I look over the source, it uses the pins and pinmux-pins files I was looking at above; I couldn't follow it after that
Jan 24 01:34:35 <beltorak> my grasp of perl has slid once again below 10 hours of learning; lol
Jan 24 01:34:54 <veremit> well .. the left has the header pins ;)
Jan 24 01:35:32 <zmatt> the big data table is just for pretty-printing the mux options
Jan 24 01:36:03 <yates> alright, so i've interrupt u-boot. now what?
Jan 24 01:36:17 <filt3r> so its not a hardware issue :D
Jan 24 01:36:20 <zmatt> the actual source code ends at __DATA__
Jan 24 01:36:38 <yates> true.
Jan 24 01:37:12 <zmatt> (this is read into a 2D array in line 67 )
Jan 24 01:37:23 <zmatt> this = the data after __DATA__ sorry
Jan 24 01:38:08 <zmatt> I never claimed it was a pretty script, it was just meant to work and produce pretty output :P
Jan 24 01:38:46 <beltorak> lol zmatt - well it definitely does that
Jan 24 01:40:19 <yates> PrettyScript(TM)
Jan 24 01:40:45 <yates> you need a can of that ^^^^. spray well. voila!
Jan 24 01:41:51 <beltorak> zmatt: since you have come so highly recommended; here's my problem - nothing I do in /sys/class/gpio seems to affect anything. I'm running a (prelimiary?) debian 8 image, but I've also tried the 2015-11 debian 8 image.
Jan 24 01:41:58 <zmatt> do check the "best before" date on the can, otherwise you might spray it onto something and it'll end up being COBOL
Jan 24 01:42:28 <zmatt> beltorak: you've verified the pin is muxed to gpio?
Jan 24 01:42:32 <yates> zmatt: you're belying your age...
Jan 24 01:42:46 <yates> PL/1?
Jan 24 01:42:50 <beltorak> I have an LED wired up to P8_10 and GND. gpio60/direction is out, .../value is 1. LED is not lit.
Jan 24 01:43:00 <zmatt> yates: I just like reading about Ye Olde Times
Jan 24 01:43:31 <zmatt> beltorak: what series resistance value are you using?
Jan 24 01:43:33 <veremit> you probably wont' have enough forward voltage .. have you tried it between v+ and the pin, beltorak ?
Jan 24 01:43:35 <beltorak> your script seems to tell me that P8.10 is in mode 7, muxed to gpio2.4, but I don't know what the other columns are
Jan 24 01:43:41 <zmatt> or that
Jan 24 01:44:08 <yates> beltorak: you need a scope, dude.
Jan 24 01:44:15 <beltorak> zmatt: 220 ohms....
Jan 24 01:44:18 <zmatt> pin number, slew, pull, mux option
Jan 24 01:44:19 <beltorak> yates: yeah, I know
Jan 24 01:44:23 <beltorak> but I'm snowed in
Jan 24 01:44:34 <yates> eastern US?
Jan 24 01:44:35 <filt3r> beltorak: you need to export the gpio, set the direction as output and then set the value to 1
Jan 24 01:44:43 <beltorak> filt3r: already done
Jan 24 01:44:44 <filt3r> if you dont already know that
Jan 24 01:44:48 <veremit> which . he's done :p
Jan 24 01:44:51 <zmatt> filt3r: you can do both steps at once by writing "high" to direction
Jan 24 01:44:56 <zmatt> avoids briefly driving low
Jan 24 01:45:08 <filt3r> oh ok good to know :D
Jan 24 01:45:15 <veremit> I'd reverse the led .. so that the beagle is sinking rather than sourcing current
Jan 24 01:45:26 <beltorak> zmatt: can I halve the resistance? what's the worst that could happen if there is only a LED across P8_10 and GND?
Jan 24 01:45:26 <zmatt> that also
Jan 24 01:45:36 <yates> what veremit said..
Jan 24 01:45:38 <zmatt> beltorak: you might destroy the IO
Jan 24 01:45:46 <beltorak> zmatt: ok; won't do that then
Jan 24 01:46:05 <filt3r> and you sure the led direction is right?
Jan 24 01:46:05 <zmatt> the am335x I/Os are not meant for sourcing or sinking high currents
Jan 24 01:46:18 <filt3r> du you have a multimeter or something to check?
Jan 24 01:46:48 <zmatt> TI should really have published some V/I curves instead of leaving people to try and extract those from IBIS data :/
Jan 24 01:46:49 <beltorak> ok; so I can try putting the LED & 220 ohm resister across P9_4 (VDD 3.3v) and P9_2 (GND) to see if I can get a light?
Jan 24 01:47:11 <beltorak> filt3r: unfortunately not at the moment; the one I bought has a weird battery
Jan 24 01:49:13 <yates> beltorak: you can borrow mine.
Jan 24 01:49:26 <beltorak> yates: lol
Jan 24 01:49:54 <zmatt> https://docs.google.com/spreadsheets/d/1L2Meyzb9H9B8_OMjMM_TemsEmZY2sWzeCeNchJRLKQ0/pubhtml   here are some V/I curves I derived from IBIS, though I'm not sure whether I did it right (and ignore M107, that data is obvious garbage)
Jan 24 01:50:00 <beltorak> so is it fine to either halve the resistance, or wire up the 220 ohm and LED across VDD3v3 and GND?
Jan 24 01:50:24 <veremit> beltorak: connect the led+ resistor to 3v3 and gnd, check it works
Jan 24 01:50:44 <veremit> then connect anode to 3v3 and cathode to resistor, to IO pin.
Jan 24 01:50:53 <veremit> then write a 0 to turn it ON and 1 to turn it OFF
Jan 24 01:51:21 <zmatt> and I think 330 ohm sounds rather smallish?
Jan 24 01:51:47 <veremit> 330 should be ok .. what limit are teh IOs  ? 7ma?
Jan 24 01:51:48 <zmatt> power led uses 4.75 K
Jan 24 01:51:56 <veremit> yeah but they're bright blue badness
Jan 24 01:52:03 <zmatt> true
Jan 24 01:52:08 <veremit> AND they been turned DOWN!
Jan 24 01:52:20 <veremit> they were room lights before!
Jan 24 01:52:31 <zmatt> well that's mostly the user leds I think?  those run off 5V
Jan 24 01:52:33 <beltorak> oh crap - i've been on the wrong header the whole time!!@#$^*O&%^#@$%^O&#@^$IO&#@^%OI
Jan 24 01:52:40 <beltorak> hahahaha
Jan 24 01:52:43 <veremit> beltorak: d'oh!
Jan 24 01:53:52 <zmatt> veremit: I think the real max max is 45 mA (latch up limit)... before that point you will probably run into thermal issues if it's sustained
Jan 24 01:53:55 <yates> ha ha
Jan 24 01:54:07 <yates> [sh]it happens..
Jan 24 01:54:41 <zmatt> veremit: of course voltage will suffer if you connect a too low resistance (see V/I curves)
Jan 24 01:54:43 <beltorak> ok got a light
Jan 24 01:55:39 <yates> you mean via the processor?
Jan 24 01:55:48 <beltorak> trying the (RIGHT) P8 header now....
Jan 24 01:55:50 <veremit> ping pong jkdriner
Jan 24 01:55:55 <beltorak> yates: VDD3v3 -> GND
Jan 24 01:57:39 <zmatt> veremit: I'm still not sure why the IBIS "drive high" lines intersect at just over 3.2V instead of 3.3V
Jan 24 01:57:49 <veremit> zmatt: who knows
Jan 24 01:58:02 <veremit> ok guys .. I gotta bale .. been up waaay too long
Jan 24 01:58:10 <veremit> g'luck beltorak .. you should be close now ;)
Jan 24 01:58:18 <beltorak> veremit: yeah, I think so
Jan 24 01:58:21 <veremit> +1 zmatt as always
Jan 24 01:58:21 <zmatt> hmm, do they actually measure 3.2 V when unloaded?  (too lazy to grab multimeter)
Jan 24 01:58:26 <zmatt> \o/
Jan 24 01:58:31 <veremit> \o
Jan 24 01:58:33 <yates> yay
Jan 24 01:58:38 <yates> yay beltorak
Jan 24 01:58:56 <beltorak> omg it works
Jan 24 01:59:11 <filt3r> nice
Jan 24 01:59:39 <veremit> gz I
Jan 24 02:00:02 <beltorak> ok, progress, now i need to eat something
Jan 24 02:00:10 <beltorak> thanks so much for all the help and info
Jan 24 02:03:07 <yates> veremit: mine works too now.
Jan 24 02:03:21 <yates> thanks for the flow control hint - that was the blocker to my solution
Jan 24 02:03:32 <yates> i had something wrong in my /etc/network/interfaces file.
Jan 24 02:03:49 <yates> this is killer!
Jan 24 02:04:20 * zmatt dumped ifupdown in favor of systemd-networkd
Jan 24 02:05:06 <zmatt> yay voor a proper daemon that reacts to link changes and such rather than a clunky shell script :P   plus dhcp is integrated, no separate daemon needed for that
Jan 24 02:05:39 <yates> does systemd-networkd still use the /etc/network/interfaces file?
Jan 24 02:05:47 <zmatt> no
Jan 24 02:07:25 <yates> not high on the list right now... would be more slicker though.
Jan 24 02:08:20 <zmatt> it uses ini-style files from /etc/systemd/network (and system defaults from /lib/systemd/network), each with a [Match] section indicating when the file should be applied (so 1 file can e.g. implicitly bring up all ethernet interfaces with dhcp unless specifically overriden)
Jan 24 02:08:53 <zmatt> note that networkd is still very immature in the old systemd version that's included with jessie
Jan 24 02:08:57 <zmatt> but I run stretch
Jan 24 02:08:59 <yates> zmatt: (re: our custom board) so i think i know how to disable u-boot's access to the board id eeprom. do i need to do the same with the kernel or some startup code somewhere after linux boots?
Jan 24 02:09:16 <zmatt> just remove the EEPROM from DT
Jan 24 02:09:39 <zmatt> along with anything else that doesn't apply to your board
Jan 24 02:10:28 <yates> do i do that with an overlay, or do i have to modify and recompile the original .dts files?
Jan 24 02:10:36 <zmatt> u-boot only accesses the eeprom in the board.c file I think?  not entirely sure
Jan 24 02:10:52 <zmatt> it should at least, since the eeprom is a board-specific feature
Jan 24 02:11:51 <yates> i'd have to open up the code, but there is a low-level C routine that reads and returns the board info structure. i'm just going to dummy that up
Jan 24 02:12:05 <zmatt> ah
Jan 24 02:12:14 <yates> in u-boot proper, that is.
Jan 24 02:12:46 <zmatt> it will be called early yes, from SPL in fact
Jan 24 02:13:21 <zmatt> since the BBB uses ddr3L memory but a tps65217c rather than tps65217d
Jan 24 02:13:32 <zmatt> so it needs to change the DDR voltage before releasing RAM from reset
Jan 24 02:14:09 <zmatt> (just to save power afaik, since the RAM supports both voltages)
Jan 24 02:14:24 <yates> i was just going to say... i didn't do that in my dram test.
Jan 24 02:15:10 <yates> it's "static int read_eeprom(struct am335x_baseboard_id *header)" near the top of /home/u-boot/board/ti/am335x/board.c
Jan 24 02:15:15 <zmatt> the tps65217c and d are identical except c defaults to ddr3 voltage (1.5V) while d defaults to ddr3l voltage (1.35V)
Jan 24 02:15:51 <yates> i see.
Jan 24 02:16:27 <zmatt> note that changing voltage may only done while reset is asserted to the RAM, and testing and leveling would need to be done if you choose to move to ddr3l
Jan 24 02:17:31 <yates> doesn't uboot do the software leveling procedure? i can't remember.
Jan 24 02:17:33 <zmatt> I don't think they did it from an environment greenness motivation or whatever, ram *can* be quite power hungry
Jan 24 02:17:43 <zmatt> uboot programs the leveling values
Jan 24 02:17:54 <zmatt> those values need to be determined using the TI-supplied program
Jan 24 02:17:56 <yates> oh that's right.
Jan 24 02:18:15 <zmatt> (per pcb / ram speed / voltage)
Jan 24 02:19:24 <yates> if it works with the default values... is it really necessary to do the leveling procedure? (at least RIGHT NOW?)
Jan 24 02:19:32 <yates> our demo is fast approaching and i'm running out of time.
Jan 24 02:19:59 <zmatt> I have no idea... the whole "ram should work first before you do leveling" thing strikes me as very odd
Jan 24 02:21:10 <yates> i'm not saying it _should_ work first, but it apparently does for 2-3 of our boards. my dram test is passing.
Jan 24 02:21:22 <zmatt> well TI says it should work before you can run the leveler
Jan 24 02:21:37 <zmatt> which is bizarre in my opinion
Jan 24 02:22:00 <yates> well i'm confused. why run it at all then? to handle corner cases like temperature/voltage?
Jan 24 02:22:03 <zmatt> if the timings were sufficiently sensitive to require leveling, then leveling would be required to get it to work at all
Jan 24 02:22:13 <yates> circular..
Jan 24 02:22:30 <yates> perhaps they assume you're at nominal voltage and 25C?
Jan 24 02:22:35 <zmatt> possibly, but then I'd be inclined to run the leveler at all four voltage/temperature corners
Jan 24 02:22:52 <zmatt> I'm not sure leveling at ambient will produce optimal values to cover the whole range
Jan 24 02:23:00 <yates> good point.
Jan 24 02:23:07 <zmatt> so I'm as puzzled as you are really
Jan 24 02:23:19 <yates> well, glad i'm in good company!
Jan 24 02:23:27 <zmatt> I also wish they published the source code of that leveler
Jan 24 02:23:54 <yates> yeah, that seems a bit stingy. perhaps they think it's IP since it's the same algo they're going to use in the h/w leveler.
Jan 24 02:23:59 <zmatt> so quick leveling could be done at boot (perhaps even manual incremental leveling)
Jan 24 02:23:59 <yates> or they DO use.
Jan 24 02:24:16 <GenTooMan> what does leveling do?
Jan 24 02:24:16 <zmatt> the hw leveler is implemented, just buggy
Jan 24 02:24:34 <zmatt> GenTooMan: configure delay lines
Jan 24 02:24:53 <zmatt> to compensate for board flight time etc
Jan 24 02:25:09 <yates> well in the uboot code they use default values for version 4 of the EMIF, but run the hw leveler for version 5
Jan 24 02:25:25 <zmatt> yates: yeah they *finally* fixed the leveler :P
Jan 24 02:25:30 <yates> it appears so.
Jan 24 02:26:55 <yates> i think the auto/hw leveling does just that (on the fly adjustment)
Jan 24 02:27:05 <yates> iirc.
Jan 24 02:27:38 <yates> the whole thing is FREAKING complicated!
Jan 24 02:27:41 <zmatt> it is broken in netra (dm816x), centaurus (dm814x), subarctic, probably aegis (didn't check), keystone I, keystone II rev 1.x
Jan 24 02:28:43 <yates> have you run the leveling program?
Jan 24 02:29:01 <yates> is it hard or pretty quick?
Jan 24 02:29:07 <zmatt> on our old dm814x board? an older version yes
Jan 24 02:29:15 <zmatt> you just load it with CCS and wait until it's done
Jan 24 02:29:21 <zmatt> then copy over the values
Jan 24 02:29:27 <yates> and then feed the values back into uboot code?
Jan 24 02:29:29 <yates> right.
Jan 24 02:29:58 <yates> probably shouldn't take more than an hour or two, i guess.
Jan 24 02:30:12 <yates> i'd hate for the thing to lock up during the demo when it gets hot..
Jan 24 02:31:01 <zmatt> keystone / ks2 errata also have more explanation of both what leveling does and what went wrong with the hardware leveler
Jan 24 02:31:18 <yates> do you have a linke to that?
Jan 24 02:32:43 <zmatt> ah ks2 is a different issue, so they fixed leveling in ks2 (but then broke something else)... ks1 is still the broken leveler though... with pictures!    SPRZ331G
Jan 24 02:32:56 <yates> ok.
Jan 24 02:33:15 <zmatt> http://www.ti.com/lit/er/sprz331g/sprz331g.pdf  advisory 13
Jan 24 02:33:37 <zmatt> also advisory 38
Jan 24 02:38:33 <beltorak> ok; got all my test leds working; now to install cloud9 & bonescript
Jan 24 02:46:04 <zmatt> yates: so am335x and relatives allow (and require) fully manual configuration of all delay values (unlike most keystone devices where a manual override applies to all byte lanes)
Jan 24 02:46:23 <zmatt> eh, I mean am335x can configure each value individually
Jan 24 02:47:13 <zmatt> dm814x is much more convenient for exploring it since there you can also *read* the ddrphy registers (they fucked up the integration in am335x causing the regs to be write-only)
Jan 24 02:48:17 <zmatt> the keystones have the best EMIF/DDR3 documentation of all TI SoC though
Jan 24 02:50:13 <zmatt> (unfortunately layout of phy config regs is completely different there)
**** ENDING LOGGING AT Sun Jan 24 02:59:59 2016