**** BEGIN LOGGING AT Thu Nov 01 03:00:00 2018
Nov 01 07:03:22 <suprothunderbolt> is there a way to still load the universal cape when you've got another overlay loaded?
Nov 01 07:04:08 <suprothunderbolt> I'm having some issues with GPIO inputs that I don't have with the universal cape loaded, and also with the eQEP
Nov 01 07:19:01 <suprothunderbolt> it feels a little dirty but I've "fixed" it. I now just load the universal overlay as my last one
Nov 01 07:37:59 <suprothunderbolt> actually that massively breaks everything else...
Nov 01 08:32:32 <zmatt> suprothunderbolt: well the current idea for letting them cooperate is: universal needs to be first, and the other overlays need to disable those parts of the universal overlay that they conflict with
Nov 01 08:33:45 <zmatt> but that idea doesn't always work out, e.g. I'm not sure what you're supposed to do if the overlay needs gpios
Nov 01 08:34:12 <zmatt> what do you mean with "issues with GPIO inputs" ?
Nov 01 08:34:30 <zmatt> also, if you want to use eQEP, you can just use an overlay for that
Nov 01 08:39:19 <zmatt> oh! I just realized how they dealt with the gpio conflict issue... I'd seen that commit, but only now do I understand what it's for...
Nov 01 08:39:22 <zmatt> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.14/patches/drivers/ti/gpio/0003-hack-gpiolib-yes-we-have-drivers-stomping-on-each-ot.patch
Nov 01 08:39:41 <zmatt> that's disgusting
Nov 01 10:50:32 <drh_> Hi, are there any ROHS or CE Certifications on the Beagleboard X15?
Nov 01 10:51:05 <zmatt> there should be
Nov 01 10:51:19 <drh_> Where would I find them?
Nov 01 10:51:27 <zmatt> good question
Nov 01 10:52:05 <zmatt> hmm
Nov 01 10:52:22 <zmatt> I know that they had to do a pcb revision to pass ce/fcc testing
Nov 01 10:52:52 <zmatt> so, the current revision should be certified
Nov 01 10:53:11 <zmatt> but I don't see the documentation for it in the obvious place for it: https://github.com/beagleboard/beagleboard-x15/tree/master/regulatory
Nov 01 10:53:15 <zmatt> jkridner[m]: ping?
Nov 01 10:53:17 <drh_> I went though the system mannual and I didnt find any
Nov 01 10:53:42 <drh_> Thats a good start
Nov 01 10:54:52 <zmatt> drh_: my suggestion would be just stick around in here, jkridner[m] will probably eventually wake up / notice he got pinged
Nov 01 10:55:08 <drh_> Good idea, thanks again for the heads up
Nov 01 14:42:21 <kremlin> m
Nov 01 22:55:04 <veremitz> p
**** BEGIN LOGGING AT Thu Nov 01 23:09:44 2018
Nov 01 23:42:17 <Guest95398> I need some advise about usb ethernet connection.  show as no cable connected, (it was) and I can browse the file on the BBB
Nov 01 23:55:36 <Snert_> can you pastebin the output the ifconfig command?
Nov 02 00:18:03 <suprothunderbolt> zmatt: just saw your message. So universal first... I'm pretty sure I've tried that but I'll check again.
Nov 02 00:18:58 <suprothunderbolt> also I tried the eqep with an overlay and they didn't work... weirdly I've set the options the same as the universal overlay appear to set them, unless I'm reading it wrong.
Nov 02 00:19:09 <suprothunderbolt> they work with universal.
Nov 02 00:25:46 <zmatt> suprothunderbolt: define "didn't work"
Nov 02 00:25:55 <zmatt> did you also set the pinmux correctly?
Nov 02 00:26:26 <suprothunderbolt> cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position appears but is zero
Nov 02 00:26:48 <suprothunderbolt> I'll double check, just attempting to see if I can reorder things and get the universal one working
Nov 02 00:28:57 <zmatt> well if you can avoid the need for universal that would probably be preferable
Nov 02 00:29:16 <zmatt> universal itself is already quite a hack, blending it and overlays even more so :P
Nov 02 00:30:46 <suprothunderbolt> it appears to be working...
Nov 02 00:31:04 <suprothunderbolt> but I'm open to doing it in a non-hack way :)
Nov 02 00:31:27 <suprothunderbolt> though sys will tell me what params the eqep is using right?
Nov 02 00:54:24 <suprothunderbolt> arg. just dropped connection in case i missed any replies...
Nov 02 01:03:18 <suprothunderbolt> ahh show-pins has shown all. the universal overlay was setting pull up on the eqep pins and the bone_eqep0 overlay wasn't.
Nov 02 01:12:16 <suprothunderbolt> so eqep is working now :) Only the GPIOs i've set in an overlay are an issue. They are grey in show-pins and if I try to access them from python they don't exist.
Nov 02 01:42:53 <suprothunderbolt> they don't exist in /sys/class/gpio either... think i'm misunderstanding this..
Nov 02 01:54:05 <suprothunderbolt> yeah,  I don't know how to make things like GPIO.setup("P9_16", GPIO.IN) work without the universal overlay
Nov 02 01:54:53 <suprothunderbolt> and if I then want to get the value of that GPIO.input("P9_16") it'll tell me I haven't set it up, even if I've exported it so it exists in the /sys/class/gpio and I can get it's value there
Nov 02 01:57:34 <zmatt> suprothunderbolt: you use a gpio-of-helper for that
Nov 02 01:58:18 <zmatt> suprothunderbolt: something like the /gpio-demo node here: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi
Nov 02 01:59:47 <zmatt> this is the one in the universal overlay: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/univ-bbb-EVA-00A0.dts#L2466-L3013
Nov 02 02:00:17 <zmatt> though note that:  1. it does not belong in &ocp, put it in / instead   2. the gpio-name property can be omitted, it defaults to the node name
Nov 02 02:00:55 <suprothunderbolt> zmatt: ah neat, thanks!
Nov 02 02:02:23 <zmatt> I personally also give gpios names that reflect their purpose rather than their pin, and have an udev rule that creates symlinks based on those names, allowing applications to not have to know or care on what pin they're allocated exactly
Nov 02 02:02:55 <zmatt> and I restrict their direction in DT (i.e. no "dir-changeable;")
Nov 02 02:03:16 <zmatt> of course for maximum compatibility with existing software libraries you may not be able to do either
Nov 02 02:03:52 <zmatt> you'd need to experiment to find out
Nov 02 02:05:47 <suprothunderbolt> ahh yeah it would be pretty to have sensible names but if it just works in all the libraries that's nicer
Nov 02 02:06:46 <zmatt> yeah I don't care about the libraries, since with the gpios configured in DT and symlinks created by udev, using them is trivial without any library.  just open "/dev/gpio/yadayada/value" and read or write the value
Nov 02 02:10:50 <zmatt> (to read again without close/reopen, seek to the beginning of the file before reading.  or combine the seek and read by using pread)
Nov 02 02:26:58 <suprothunderbolt> there are for buttons so I was contemplating using the gpio-keys thing instead
Nov 02 02:27:15 <zmatt> yep, makes sense
Nov 02 02:27:42 <suprothunderbolt> so they all appear now in show-pinswith gpio-of-helper but nothing is created in /sys/class/gpio
Nov 02 02:28:20 <zmatt> can you pastebin your DT source for that gpio-of-helper node?
Nov 02 02:30:11 <suprothunderbolt> https://paste.debian.net/1050057/
Nov 02 02:30:46 <zmatt> looks fine to me. did you check kernel log?
Nov 02 02:30:47 <suprothunderbolt> i just copied the sub sections from the universal one to start with
Nov 02 02:31:55 <zmatt> this should cause /sys/class/gpio/gpio{50,51,60} to show up
Nov 02 02:33:23 <suprothunderbolt>  gpio-of-helper ocp:cape-universal: ready is the only bits i see
Nov 02 02:33:37 <suprothunderbolt> i haven't named my thing cape-universal...
Nov 02 02:34:07 <zmatt> that one isn't yours
Nov 02 02:34:23 <suprothunderbolt> yeah, so no other mentions
Nov 02 02:34:29 <zmatt> the universal one is defined in the base dts (with P9.19 and P9.20 in it)
Nov 02 02:34:30 <zmatt> that's odd
Nov 02 02:34:54 <suprothunderbolt> P9.14                             18 fast rx      7 gpio 1.18 << lo  P9_14 (pinctrl_morph_pins)
Nov 02 02:34:58 <suprothunderbolt> when i do show pins
Nov 02 02:35:35 <zmatt> so both the pinmux and the gpio seem to be requested
Nov 02 02:36:55 <zmatt> what does ls /sys/class/gpio show?
Nov 02 02:37:36 <suprothunderbolt> i think i'm using pincntrl_morph_pins in two different overlays... just changing that name so it's a bit clearer
Nov 02 02:37:59 <zmatt> there's no reason to give the node such a verbose name btw
Nov 02 02:38:11 <zmatt> I have no idea why the existing dts does that
Nov 02 02:38:35 <suprothunderbolt> they basically all do, so I think everyone assumes there must be some reason :)
Nov 02 02:39:27 <zmatt> I always use    &am33xx_pinmux { thing_pins: thing { ... }; };    since the label (&thing_pins) must be globally unique while the node name (thing) only needs to distinguish it from other pinmux nodes
Nov 02 02:39:37 <zmatt> more likely everyone just copies it :P
Nov 02 02:41:16 <suprothunderbolt>  ls /sys/class/gpio/ export  gpio12  gpio13  gpio50  gpio51  gpio60  gpiochip0  gpiochip32  gpiochip64  gpiochip96  unexport
Nov 02 02:41:31 <zmatt> so what's the problem? the gpios are there
Nov 02 02:41:34 <suprothunderbolt> all seem to be the numbers they should be
Nov 02 02:42:06 <suprothunderbolt> yeah, so if I try and access them from the adafruit python library
Nov 02 02:42:32 <zmatt> oh I'm sure something breaks. it's adafruit :P
Nov 02 02:43:13 <suprothunderbolt> there the only ones with vaguely readable documentation so they have a pretty huge advantage
Nov 02 02:44:18 <suprothunderbolt> GPIO.setup("P9_12", GPIO.IN)
Nov 02 02:44:26 <suprothunderbolt> ValueError: Set gpio mode failed, missing file or invalid permissions.
Nov 02 02:44:40 <suprothunderbolt> but then again I'm not sure what else it'll be looking for
Nov 02 02:45:18 <zmatt> it's trying to configure the pinmux via the universal overlay
Nov 02 02:45:51 <suprothunderbolt> yeah, and if i just ask for GPIO.input it tells me I haven't called setup yet...
Nov 02 02:47:54 <zmatt> https://pastebin.com/1BUT1Mwn
Nov 02 02:48:01 <zmatt> here's a working python gpio library for you ;)
Nov 02 02:48:37 <zmatt> this assumes direction has been correctly set by DT
Nov 02 02:49:20 <suprothunderbolt> hah true. I rather like the GPIO.add_event_detect parts...
Nov 02 02:49:38 <suprothunderbolt> with call backs and debouncing...
Nov 02 02:50:11 <suprothunderbolt> I might just use the gpio-keys that has everything built in and then in the code I just listen for keys...
Nov 02 02:50:16 <zmatt> yeah that's a few lines more work
Nov 02 02:50:26 <zmatt> that sounds like a good idea
Nov 02 02:51:10 <zmatt> you could probably also make adafruit happy by creating a dummy pinmux helper whose modes don't actually change any pinmux ;)
Nov 02 02:51:45 <suprothunderbolt> i'm happy to create nodes that actually change the pin mux, what ever is easiest
Nov 02 02:54:33 <zmatt> there's a non-zero chance that this might work: https://pastebin.com/raw/Qij3q84w
Nov 02 02:55:07 <zmatt> &ocp is the wrong place for a virtual device like this, but putting it in the right place will no doubt cause adafruit et al to be unable to find it
**** ENDING LOGGING AT Fri Nov 02 02:59:58 2018