**** BEGIN LOGGING AT Fri Mar 18 02:59:57 2022 Mar 18 04:24:14 zmatt So I got around today to poking at the PRU on this BBB as discussed yesterday. I did be getting me the python stuff. Cloned the repo. Got pasm sorted. Went to run the basic-test.py and I think I am missing a python module.    from uio.ti.icss import Icss ImportError: No module named uio.ti.icss. I guess I should install that module named Mar 18 04:24:15 Icss? Mar 18 04:39:25 @zmatt was simple silly thing. Executing with wrong version of python:) Mar 18 06:22:11 I do believe that was success. Thanks Zmatt. Even if I don't use the python it really helped me to understand what is going on here. Mar 18 07:12:06 Hi everyone Mar 18 07:12:51 I own a BeagleBone AI, and the operating system runs on the eMMC. Storage is limited to only 15GB. In this sense I want to add a cardSD that I can use only for additional storage space, without running the operating system on it, but I don’t know how to do that. Mar 18 07:13:18 I think is something from u-boot but I don't know how to do that Mar 18 08:20:08 Good morning, Mar 18 08:20:09 I am trying to put the pins can 24 and 26 in the BB AI. Mar 18 08:20:09 Can someone help me? Mar 18 09:46:46 Someone who has experience with sound drivers/codecs/DTS... Mar 18 09:46:55 ? Mar 18 15:38:15 Is there a way to append pins to pinctrl-single,pins? Mar 18 15:39:07 Specifically I want to add on some default pins to the i2c0_pins node that is created by an include "am33xx.dtsi" Mar 18 16:27:31 Konsgnx1: you shouldn't have a desire to do that, since the only pins that should be declared in that block are sda and scl Mar 18 16:27:58 also, am33xx.dtsi doesn't declare any pins Mar 18 16:28:46 and no, there's no DT syntax for appending to a property Mar 18 16:51:13 drats, yea getting around it by having a default pinmux **** BEGIN LOGGING AT Fri Mar 18 18:32:05 2022 Mar 18 21:01:02 Konsgnx1: around what? what are you trying to do? Mar 18 21:01:15 Konsgnx1: pinmux should be attached to whatever device the pinmux is for Mar 18 22:45:42 @zmatt: Are you around today? Mar 18 22:46:35 @zmatt: Are you around today to discuss the lib. you made for SysFS-GPIO? Mar 18 22:48:47 Anyway, I was thinking. Oops! The lib. is near perfect except for this altercation on my part. I tried to change some of your source and received an "abort" error. Things compiled correctly w/ the Makefile but I could not change the $PATH of some of the source. Mar 18 22:49:40 It is almost like there is a force field around it, i.e. some pinmux definitions I am not aware of or something... Mar 18 22:50:13 ?? Mar 18 22:50:31 @zmatt: ! Mar 18 22:50:52 Did you not see all my cries for help already? Mar 18 22:51:08 no? Mar 18 22:51:13 Dang it. Mar 18 22:51:31 I have been going back and forth trying to get your attention for weeks now. Mar 18 22:51:54 Can I show you the error codes if they are of any use? Mar 18 22:52:00 just pastebin it Mar 18 22:52:04 Okay. Mar 18 22:53:22 Okay, okay. Mar 18 22:53:33 Here: https://pastebin.com/KBccPsFQ is the source. Mar 18 22:53:34 And... Mar 18 22:53:58 This is the altering: https://pastebin.com/r1YMMryq . Mar 18 22:54:14 led devices in /sys/class/leds/ are not gpios and cannot be controlled with this library Mar 18 22:54:20 I changed... Mar 18 22:54:21 oh. Mar 18 22:54:43 Why are the LEDs in the .dts file being used as such for the RelayCape? Mar 18 22:55:01 They are GPIO pins in the .dts but called LEDs. Mar 18 22:55:10 dunno, sounds bogus Mar 18 22:55:20 Let me show you, i.e. if you have any time. Mar 18 22:55:24 a relay is obviously not a led and should not be declared as such Mar 18 22:55:55 I know. But, there is a .dts. Just let me show you this .dts file, please. Mar 18 22:56:23 yeah, I see the overlay does that Mar 18 22:57:01 Here: https://pastebin.com/et6gnNxw Mar 18 22:57:03 Oh. Mar 18 22:57:26 So, would I change the .dts file instead of your Makefile and source? Mar 18 22:58:10 All issues aside, I can probably manage to change it. Mar 18 22:58:49 I guess I was at a loss of what to change and when to change it. Mar 18 23:00:55 I mean...this is simply solved by me just using your repo. or the .dts file and other source. Either way, those are fun ways. Mar 18 23:01:12 But! It is more fun to learn something new by changing everything! Mar 18 23:01:38 hold on Mar 18 23:01:46 Oh. Okay... Mar 18 23:02:09 Sir, I am not pressuring you into anything, am I! Mar 18 23:02:10 I mean, you can just remove or disable this bogus dts and then control the gpios just fine Mar 18 23:02:23 Oh. Mar 18 23:02:44 Well... Mar 18 23:03:00 I thought I could b/c of the GPIOs listed as "disabled". Mar 18 23:03:31 So, instead of using the .dts and your lib, I would just use your lib. w/ the correct $PATH. Mar 18 23:04:53 B/c...in the .dts file, those listed "disabled" GPIOs have comments and these darn comments have the required $PATH right? Mar 18 23:06:11 @zmatt: I just reread what you typed. Okay. Thank you. Mar 18 23:06:12 ??? Mar 18 23:06:21 ha. Mar 18 23:06:30 I just reread what you typed. Sorry. Mar 18 23:06:34 I took it the wrong way. Mar 18 23:07:20 I thought you were putting theory over a technical aspect (AS USUAL). I always do this..."anything is up for grabs." Mar 18 23:07:31 My bad, sir. Mar 18 23:08:37 @zmatt: Did you make this lib so alterations could not be handled easily? Mar 18 23:09:07 Anyway, it is just me. No issue. Mar 18 23:09:58 what? Mar 18 23:10:14 I don't know what you're talking about Mar 18 23:13:45 set_: I'm testing a replacement overlay right now, to create properly named gpios Mar 18 23:16:29 Oh. Mar 18 23:16:44 That is all I was saying earlier. I can try to make one. Mar 18 23:16:55 but doing that is optional of course, you can just use the gpios exported by cape-universal instead Mar 18 23:17:00 no, you can't, you have no idea how to Mar 18 23:17:05 Right now, I do not know what I am saying either. Mar 18 23:17:12 You are right. Mar 18 23:17:17 I still need to learn. Mar 18 23:17:29 There is no reason to fall behind for eternity. Mar 18 23:19:11 See now, the place I am at in life, life in general here, has me doing oddball jobs (AS USUAL). But, I like to try new things w/ the Capes and boards. You know...if I can squeeze in time, I will. I want to be able to add a board one day, a Cape, and write a .dts for it. Mar 18 23:19:31 But... Mar 18 23:20:02 It is like everyone I encounter for the TIDA-00320 is either shafting me or not too collective on "my" needs. Mar 18 23:20:58 For RelayCape sake, I turned on a LED w/ the Cape so far w/ the Adafruit_BBIO lib. to test it. Mar 18 23:22:08 I also tried to build this, https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ . Mar 18 23:22:37 But is is getting in the way of building quickly. So, I went back to rcn-ee.com for images and the forums. Mar 18 23:24:10 @zmatt: I do not expect you, as one person, to handle anything. I just wanted to reach out and let others know about "a" perspective. Mine. Mar 18 23:25:04 * set_ is a generalist at best, i.e. even w/ GenTooMan giving me grief. Mar 18 23:25:14 set_: there, added a replacement BBORG_RELAY-00A2 overlay to https://github.com/mvduin/overlay-utils Mar 18 23:25:21 Oh. Mar 18 23:25:30 Hmm. Am I allowed to test it? Mar 18 23:26:05 You have been busy. Mar 18 23:26:30 I just saw your /overlay-utils repo. and it was not that long ago that I looked at it. Mar 18 23:28:19 Bits and pieces! Mar 18 23:28:30 I am learnt-a-did once more. Mar 18 23:28:32 if you also have an udev rule installed for creating gpio symlinks ( https://pastebin.com/MMC6u7pR ) then you'll have a /dev/gpio/ directory in which properly named symlinks will show up for the relays: https://pastebin.com/kBtADpCx Mar 18 23:28:43 hence then you can use "/dev/gpio/relay-jp1" as path in my gpio library Mar 18 23:28:45 Nice. Mar 18 23:29:11 I will go and look. @zmatt: Please bare w/ me here... Mar 18 23:29:31 I know you enjoy assisting and helping out those of us, me, who know little when you can spare the stress. Mar 18 23:30:44 So, I do appreciate it. But, by all means, do not be stressed to the point that it is either helping me or yelling at me. Mar 18 23:31:03 Please kindly tell me to take a break or whatever. Mar 18 23:31:22 Thank you! Mar 18 23:31:29 ? Mar 18 23:31:40 I know. I am feeling feelings. Mar 18 23:31:42 Ha. Mar 18 23:31:58 I should not cry in chat! Mar 18 23:32:07 * set_ stays tough to keep tears away! Mar 18 23:32:48 udev rules! Mar 18 23:33:16 Quite a handy thing when promoting GPIO tasks or any peripheral! Mar 18 23:33:41 You know...do you look at udev rules in the man pages at all? Mar 18 23:34:32 I am asking b/c I am sure they change like anything else in Linux. Keeping updated is half the battle. Mar 18 23:35:23 ? Mar 18 23:36:00 Never mind me. Mar 18 23:36:18 * set_ making BBB sound silly is what I am not trying to do. Sorry. Mar 18 23:36:19 btw, if you do intend to use this overlay (which, like I said, is completely optional) then, like the comment in its source code says, make sure you have a sufficiently recent kernel ( https://pastebin.com/2w2XtJBP ) Mar 18 23:36:22 I like to joke. Mar 18 23:36:36 I saw it. Mar 18 23:37:06 I looked over the comments. I am updated to the latest kernel in 5.10.x from rcn-ee.com. Mar 18 23:37:16 oh that's a very bad idae, why would you do that? Mar 18 23:37:54 B/c...the other image from beagleboard.org/latest-images seemed to be outdated. Mar 18 23:38:00 stick to the default kernel series (4.19-ti in current images) Mar 18 23:38:07 Oh. Okay. Mar 18 23:38:14 various stuff in 5.x is barely working Mar 18 23:38:38 I know. I am testing things w/out complaining b/c I do not search logs (at all). Mar 18 23:38:58 I have gotten quite a bit to work so far. Mar 18 23:39:21 Bots, like that thing you helped me w/ years ago, circa '18, and this Cape. Mar 18 23:39:39 I was surprised that the BBIO lib. still worked for GPIO. Mar 18 23:39:48 I thought people were moving on from it. Mar 18 23:39:59 actually, I'm pretty sure most overlays will fail to work on that kernel series Mar 18 23:40:08 including this one Mar 18 23:40:13 due to backwards-incompatible changes Mar 18 23:40:45 or, well, it means kernel-version-specific overlays are required Mar 18 23:40:46 Hmm. Yea. I get it, sort of. I noticed I had to call a 1 instead of a 0 b/c of something. I never looked it up. Mar 18 23:40:54 uhh no Mar 18 23:40:54 Oh. Mar 18 23:41:26 So, overlays are changing b/c of the DTC or standards? Mar 18 23:41:29 like I said, just stick to 4.19-ti for now... no need to bring more problems onto yourself Mar 18 23:41:36 No issue. Mar 18 23:42:01 they're changing because some kernel dev apparently thought it was okay to make backwards-incompatible changes Mar 18 23:42:08 No fun. Mar 18 23:42:30 Hmm. Now, everyone must read what exactly this .dev did and appear to work w/ it. Mar 18 23:43:10 So, everything you guys did so far to invest time and effort has been slated, i.e. sort of. Mar 18 23:43:38 Anyway, you are right. Mar 18 23:43:42 I should not worry. Mar 18 23:44:36 It is a shame that people did not say, "Hey, I am doing this now!" vote on it! Mar 18 23:46:47 For instance, I was reading some of those Linux logs/email blogs/whatever they are now. I noticed some very koy rhetoric. Just me though. I cannot follow everything. Mar 18 23:47:18 I am still trying to hash out globbing and pathlib'ing in Python3. Mar 19 01:01:50 Testing soon! Mar 19 01:47:18 I, oh. Mar 19 01:47:38 My kernel is too updated. I forgot what you said. Mar 19 01:55:02 Well, the LED turns on. Mar 19 01:55:03 And... Mar 19 01:55:23 pwrite /dev/gpio/relay-jp3/value: Illegal seek Mar 19 02:01:36 Even after the initial and only write to high or on or 1 here, I make the source again w/ everything pointing to the $PATH in question. Notta. It never turns off! Mar 19 02:01:37 Ha. Mar 19 02:01:55 I need to research this more. Mar 19 02:05:01 When the board shutsdown by command, the relay turns off. Mar 19 02:05:02 Nice. Mar 19 02:19:16 So! Mar 19 02:19:31 Now, I need to know the size, offset, and whatever else I can configure! Mar 19 02:19:38 yea boy! Mar 19 02:36:22 @zmatt: I know it is getting late here. Are you sort of using this method on pursuing this source? Mar 19 02:36:32 Oh, here: https://linux.die.net/man/3/explain_pwrite_or_die ? Mar 19 02:39:27 I will make time to adjust things. Mar 19 02:40:41 It seems that pread, which is obviously not used in your source (I cannot find it), turned into pread64 back in kernel 2.x.x. Mar 19 02:40:51 Same w/ pwrite. Mar 19 02:41:26 I use the OpenSource 500 || blah blah blah to handle the source and everything breaks in the Makefile. Mar 19 02:41:31 So, I will try something else. **** ENDING LOGGING AT Sat Mar 19 02:59:56 2022