01:49 <set_> BBB!

02:02 <set_> @zmatt: Are you still upset at me for using libgpiod?

03:00 <zmatt> I'm not upset "for using libgpiod", I'm annoying because you keep discarding things that work in favor of things that don't, then ask for help, and then discard the advice

03:01 <set_> Oh.

03:01 <set_> I understand now.

03:01 <set_> Okay.

03:02 <set_> I will try to narrow my sights on what works instead of reinventing ideas into new ways of doing things.

03:02 <set_> Can we agree yet?

07:20 <David21> Hello, Looking for Beagle bone black ver2.1

07:20 <David21> anybody can suggest where i can get it?

20:13 <zmatt> set_: oh I just realized yet another reason you shouldn't use libgpiod ... a program that uses libgpiod to control relay-jp1 or relay-jp2 that "works" (ignoring that it breaks the sysfs gpios) when the overlay-utils version of the BBORG_RELAY-00A2 overlay is installed will cause a short-circuit (and potentially destroy the BBB) when the bb.org-overlays version of the BBORG_RELAY-00A2 is used, and ...

20:13 <zmatt> ...conversely if the libgpiod code "works" with the bb.org-overlays version of the overlay then it'll fry the hardware when used with the overlay-utils version of the overlay

20:14 <set_> Oh.

20:14 <set_> That is not good.

20:15 <set_> Why would the /dev/gpio/relay-jp3/value file cause such an issue?

20:15 <zmatt> it doesn't

20:15 <set_> I am not using the .dtsi file now.

20:15 <set_> But...the files are still there at that location.

20:16 <set_> Oh. I see what you typed now.

20:16 <set_> relay-jp1/2.

20:17 <set_> So, is there a way around such an issue or since it is libgpiod, you are against using your time to tell me?

20:17 <zmatt> normally the kernel would prevent libgpiod from using gpiod that are already in use, that but that's been patched out in rcn's kernels (an action I do not agree with, even though I know why it was done)

20:18 <zmatt> set_: easy workaround: DON'T USE LIBGPIOD

20:18 <set_> I know, I know how you feel. Okay, so, there are still issues w/ it and for the am335x w/ what has been produced in .dtsi/.dtbo files.

20:19 <set_> I will stop using it in case the rcn kernels get altered.

20:20 <set_> I should make myself more aware of the issue pertaining to the source and how it can conflict w/ the images/boards/BBBWs.

20:21 <set_> I need to alter the lib. now on github. Did you see the update for pathlib yet?

20:21 <zmatt> set_: btw, in C_SRC/MyFirst.c you're trying to write to /dev/gpio/relay-jp3/direction .. don't do that, it's read-only

20:21 <zmatt> https://pastebin.com/HdJdnuDD this suffices

20:21 <set_> Oh.

20:21 <set_> Right. I noticed that. It is already an out.

20:21 <zmatt> (or use my sysfs-gpio library)

20:21 <set_> I will change that too.

20:21 <set_> Okay!

20:22 <zmatt> but using open() and write() directly is fine too

20:22 <set_> Oh. Okay.

20:22 <zmatt> which shows the simplicity of using sysfs gpio when the gpio has already been setup by DT (which my overlay does)

20:23 <zmatt> have you installed buster yet or are you still messing with bullseye?

20:23 <set_> Bullseye on this board is staying for now.

20:23 <set_> I have not changed it yet.

20:24 <zmatt> then you'll at least need to install https://github.com/rcn-ee/repos/blob/master/bb-customizations/suite/buster/debian/80-gpio-noroot.rules since we've observed it's missing in bullseye

20:24 <zmatt> to set the permissions right

20:24 <set_> Right.

20:24 <set_> I did it.

20:24 <set_> I think this is where I am able to use your lib. w/out issues, i.e. well that plus the udev rule.

20:24 <set_> You udev rule.

20:25 <set_> your == You

20:25 <set_> That one you showed me in the posts on pastebin.

20:25 <zmatt> yep, my rule creates the symlinks in /dev/gpio/, while the 80-gpio-noroot.rules fixes the permission errors

20:25 <set_> Aw.

20:26 <set_> Okay. See, I knew this was the reason I was able to use this source the way it was used.

20:26 <set_> The symlinks in /dev/gpio/ is how I found out about how to use it in that .C file.

20:27 <set_> I was unaware of active_low at first. Now, I know!

20:27 <set_> I kept reading things. None of it made since. Then, all of a sudden, it hit me. I already read about this once a long time ago.

20:28 <set_> Bam!

20:28 <set_> I like to joke about epiphanies. There was one w/ active_low and value.

20:29 <zmatt> ignore active_low

20:29 <zmatt> you don't need it

20:29 <set_> Okay. So, I will just take out direction and know that using it in MyFirst.c...Oh.

20:29 <set_> Oh.

20:29 <zmatt> like I said earlier, this suffices: https://pastebin.com/HdJdnuDD

20:30 <set_> Now.

20:30 <set_> Okay.

20:31 <zmatt> (writing direction is not only unnecessary but doesn't, or shouldn't, work since this attribute is only writable for bidirectional gpios while the relays are output-only)

20:31 <zmatt> also beware that if you used libgpiod on any of these gpios even once, it'll break them for sysfs access until you reboot

20:32 <rcn-ee> okay, that bb-customizations package for bullseye is now fixed.. Had the flu for this week, so i've not really been aroudn..

20:32 <set_> Oh.

20:32 <set_> No!

20:32 <set_> The flu. Yikes. It is march.

20:32 <set_> Get well soon.

20:32 <rcn-ee> and the snow is melting... i'm allergic to allergies.. ;) i'm good now..

20:33 <set_> Yikes. Allergies. oh. good. Pulling through the sickness is half the battle.

20:34 <set_> I say stop eating out. Those people are sickos.

20:34 <set_> No offense to people doing well in the food industry.

20:35 <zmatt> rcn-ee: any idea why the official BBORG_RELAY-00A2 overlay is so weird? it declares the relays as leds instead of just exporting them as gpios...

20:35 <rcn-ee> yeah, i did that few years ago... led's are one echo off/on..

20:36 <rcn-ee> vs, 3 lines for export, echo, echo..

20:36 <set_> brb

20:36 <rcn-ee> i know we have a udev rule that takes care of the export.. so it's 2 echo's vs 1. ;)

20:36 <zmatt> rcn-ee: gpios are exported automatically if you use gpio-of-helper

20:36 <zmatt> rcn-ee: no you're confusing gpio with pwm maybe

20:37 <zmatt> gpios are automatically exported by the kernel if setup appropriately, and gpio-of-helper takes care of that setup

20:37 <zmatt> e.g. this is my version: https://github.com/mvduin/overlay-utils/blob/master/BBORG_RELAY-00A2.dtsi

20:37 <zmatt> (I've now also tweaked my USES_PIN macro to disable the gpio exported by cape-universal in addition to disabling the bone-pinmux-helper, but of course that needs a fairly recent kernel)

20:38 <rcn-ee> at the time it was quick, and everything was mainline to make it work..

20:38 <rcn-ee> your version would also work well..

20:41 <set_> You guys...

20:42 <zmatt> gpio-of-helper really ought to be mainline... unfortunately mainline has the delusion that the new gpiod is actually a good thing :P

20:43 <set_> what is gpio-of-helper and bone-pinmux-helper and how can I use them to alter pin config(s)?

20:43 <rcn-ee> gpiod is great... till the application stops/exits... and then your pin's return to default state.... and the laser cutter burns the house down.... ;)

20:43 <zmatt> rcn-ee: btw, that udev rule I show in the comments of my overlay is pretty nice too, for using sysfs gpio without hardcoding gpio numbers: https://pastebin.com/raw/TukGTYWD

20:43 <zmatt> rcn-ee: yes, fucking rude

20:43 <zmatt> kernel shouldn't touch my gpio unless I ask it to

20:44 <rcn-ee> it needs to be fixed, so that when the ioctrl is closed, the state it in, DOES NOT change... till then /sys/class/gpio can never be removed, as it doesn't actually replace it..

20:44 <zmatt> that's just one of many problems

20:45 <zmatt> access control granularity is another (sysfs gpio is per-pin)

20:46 <rcn-ee> zmatt: what do you want to do with am6x.. same issue... (but unlike am57xx) it has a working gpio pinctrl...

20:46 <rcn-ee> ah crap... gotta run... (picking up parts for thing this weekend..) back tomorow...

20:47 <zmatt> rcn-ee: here's another reason I don't want to know about gpio numbers: https://pastebin.com/raw/wGBVGNXr

20:47 <zmatt> rcn-ee: what do you mean, what issue? sysfs gpio should work fine on any linux system that has gpios

20:47 <zmatt> the best way to deal with gpiod is by ignoring it exists

20:50 <set_> You guys, I am going to look up gpio-of-helper and bone-pinmux-helper. Sheesh. If anyone has time to make me understand, please try to let me know about these libs.

21:08 <zmatt> set_: they're not libs, they're drivers. don't worry about it

21:17 <set_> Okay.